Re: [dtn-interest] Hello from Brazil

Hello Lloyd, 

I meant that our approach is aimed at delivering reliably "data" to BP/LTP, as such erasure encoding/decoding have to be performed, not only crc checking. Overall reliability/integrity of reconstructed ltp segments and bundles should be carried out by ltp and bp as you remarked.

T.
_______________________________________
Da: l.wood@surrey.ac.uk [l.wood@surrey.ac.uk]
Inviato: martedì 4 febbraio 2014 13.20
A: Cola, Tomaso de; morgenroth@ibr.cs.tu-bs.de
Cc: dtn-interest@irtf.org
Oggetto: RE: [dtn-interest] Hello from Brazil

"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
http://sat-net.com/L.Wood/dtn

________________________________________
From: dtn-interest [dtn-interest-bounces@irtf.org] On Behalf Of Tomaso.deCola@dlr.de [Tomaso.deCola@dlr.de]
Sent: 04 February 2014 08:30
To: morgenroth@ibr.cs.tu-bs.de
Cc: dtn-interest@irtf.org
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,

Tomaso

------------------------
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 | tomaso.decola@dlr.de
http://www.dlr.de/kn/institut/abteilungen/san

> -----Original Message-----
> From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of
> Johannes Morgenroth
> Sent: Tuesday, February 04, 2014 9:11 AM
> To: dtn-interest@irtf.org
> 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@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-interest
_______________________________________________
dtn-interest mailing list
dtn-interest@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-interest