Re: [dtn-interest] Hello from Brazil

<> Tue, 04 February 2014 12:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1E2751A03A5 for <>; Tue, 4 Feb 2014 04:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YLL113bff537 for <>; Tue, 4 Feb 2014 04:24:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CC8611A0383 for <>; Tue, 4 Feb 2014 04:24:30 -0800 (PST)
Received: from [] by id 9A/56-07302-DFBD0F25; Tue, 04 Feb 2014 12:24:29 +0000
X-Originating-IP: []
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12708 invoked from network); 4 Feb 2014 12:24:29 -0000
Received: from (HELO ( by with AES128-SHA encrypted SMTP; 4 Feb 2014 12:24:29 -0000
Received: from ([]) by ([]) with mapi; Tue, 4 Feb 2014 12:24:28 +0000
From: <>
To: <>, <>
Date: Tue, 4 Feb 2014 12:20:03 +0000
Thread-Topic: [dtn-interest] Hello from Brazil
Thread-Index: AQHPHoZPmkhThX/4VUak7A4zrwb+f5qe8IwAgAAMloCABEZAgIAADjIAgAFh04CAABO3IIAAQrJ4
Message-ID: <>
References: <> <5EE81C5C4CFFF4418C5EAD12F49D64EE4C19CD73@IMCMBX01.MITRE.ORG> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US, en-GB
Content-Language: en-GB
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dtn-interest] Hello from Brazil
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Feb 2014 12:24:35 -0000

"beyond error detection"?

there still needs to be an endtoend check to ensure that bundles have not been corrupted in transit.

the lack of reliability checking in the bundle protocol itself (and in LTP) requires the 'optional' security mechanisms, even if security per se is not desired.

Lloyd Wood

From: dtn-interest [] On Behalf Of []
Sent: 04 February 2014 08:30
Subject: Re: [dtn-interest] Hello from Brazil

Hello Johannes!

The approach we used actually goes beyond error detection (e.g., CRC). We developed a packet-layer coding strategy, as part of a shim layer placed between LTP and CCSDS-native layers, responsible for error detection and correction. To this end, some redundant packets are generated to improve the reliability of communication. Further to this, the "shim layer" actually implements a real protocol, whereby a header is appended to each encapsulated LTP segment. This header contains information for encoding/decoding functions and also implements a CRC-32 to avoid that bit errors are propagated to the upper layer once the decoding is completed.
We preferred not to integrate the erasure coding functions within the bundle protocol to avoid additional complexity from an implementation point of view and to handle packet erasures as much closer to the link layer as possible in order to avoid more severe performance degradation in case of erasure propagation upwards in the protocol stack (e.g., the case where a bundle protocol is composed of several LTP segments). Ultimately this approach was also pursued to avoid that we have to resort to LTP ARQ mechanisms which can be very time-consuming in deep-space networks or in general over long links with non-negligible packet error rate.

Best Regards,


Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 |

> -----Original Message-----
> From: dtn-interest [] On Behalf Of
> Johannes Morgenroth
> Sent: Tuesday, February 04, 2014 9:11 AM
> To:
> Subject: Re: [dtn-interest] Hello from Brazil
> Hello Tomaso!
> Am 03.02.2014 12:04, schrieb Prof. Marcelo:
> > "how the bundle protocol works to identify if the packet was ok?"
> You are right. That is not part of the RFC 5050 or RFC 4838.
> But with some imagination the Bundle Security Protocol is adequate to check
> for transmission errors. Each BAB provides data checking and invalid bundles
> going to be dropped. If the standard ciphersuite BAB-HMAC is too complex
> for your needs, you can define a CRC-like ciphersuite which does not require
> any key.
> Kind regards,
> Johannes Morgenroth
> _______________________________________________
> dtn-interest mailing list
dtn-interest mailing list