Re: [dtn] LTP CL for BP v7

[Felix Flentge <[e-mail]>]

FYI,


  *   the upcoming CCSDS Blue Book for BPv7 will probably include a ‘Reliable LTP Convergence Layer adapter’ based on LTP red with bundles encoded as a sequence of CBOR bytes strings in an LTP block (TBC)
  *   this will likely lead to the need for a (or multiple) new client service ID (details are TBD)
  *   the upcoming CCSDS Blue Book for BPv7 will probably not include an ‘Unreliable LTP Convergence Layer adapter’ based on LTP green because this would require additional processing and (attempted) parsing of BP bundles within the LTP CLA (TBC)
  *   IMHO, LTP SDA shall not be used as there is no generic way to determine the length of client data contained in SDA Client Data Capsules which requires the receiver to be able to correctly parse (parts of) each client data according to the specified client service ID at LTP level.

Regards,
Felix

From: dtn <[e-mail]> On Behalf Of [e-mail]
Sent: Tuesday, April 2, 2024 5:00 PM
To: 'Keith Scott' <[e-mail]>; 'John Dowdell' <[e-mail]>
Cc: 'DTN WG' <[e-mail]>
Subject: Re: [dtn] LTP CL for BP v7

Just to amplify a little: ION’s BPv6 and BPv7 implementations share the same LTP implementation.  There may be some small differences in the adapter code (which encapsulates the bundles in LTP blocks) due to the differences in the BP versions, but the functionality is the same for both.

Scott

From: dtn <[e-mail]<mailto:[e-mail]>> On Behalf Of Keith Scott
Sent: Tuesday, April 2, 2024 6:46 AM
To: John Dowdell <[e-mail]<mailto:[e-mail]>>
Cc: DTN WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dtn] LTP CL for BP v7

I might say it differently: "The ION open source (going back probably to the first version that supported BPv7, certainly in open-source-4.1.1) implementation supports the use of LTP convergence layer adaptors whether ION is configured to use BPv6 or BPv7.  The LTP blocks formed by the adaptors may each contain one or more bundles (depending on the bundles' sizes, reliability requirements, and the LTP CLA configuration).  Multiple bundles to be sent reliably to the same destination client ID (e.g. LTP Service Data Aggregation per section 7 of https://public.ccsds.org/Pubs/734x1b1.pdf) may be accumulated into a single red LTP block; if an unreliable bundle is sent, it will be the only bundle in an unreliable (green) LTP block.  Whether using BPv6 or BPv7, ION behaves the same way w.r.t. its implementation of the LTP CLA and LTP CL)."  This might sound like it's not quite what section 7 of the CCSDS book says, but I think that it is in fact conformant.  If using multiple 'red bundles' (bundles that go into red blocks) then SDA is used and the bundles can be concatenated into a single red LTP block.  When sending an unreliable bundle, SDA is NOT used and the bundle goes into a single green LTP block.

    --keith


On Tue, Apr 2, 2024 at 1:02 PM John Dowdell <[e-mail]<mailto:[e-mail]>> wrote:
Many thanks Scott and Keith.

The LTPv2 dev team have kindly made the draft copy of the CCSDS spec available to me for comment but I’ll leave that to them to publish here if they want to.

One last question, just to be sure: does the LTP CLA in the I-D and ION-DTN support BP v7 (RFC 9171), or just v6 (RFC 5050)?

Many thanks
John

On 1 Apr 2024, at 20:44, Keith Scott <[e-mail]<mailto:[e-mail]>> wrote:


Scott pointed out to me that the CL definition and the CL*A* definition (how to carry bundles in the CL protocol) are different, so there might still be a small bit of un-spec'ed work.  And that I forgot to cc: the dtnwg (thx).... :o

    --keith

---------- Forwarded message ---------
From: Keith Scott <[e-mail]<mailto:[e-mail]>>
Date: Mon, Apr 1, 2024 at 8:28 PM
Subject: Re: [dtn] LTP CL for BP v7
To: <[e-mail]<mailto:[e-mail]>>

Though the CCSDS profile of the RFC5326-based LTP specification *is* a published spec (https://public.ccsds.org/Pubs/734x1b1.pdf) that should be suitable for contracting.

I'll also point you at a docker container-based emulation environment here in case that's useful: https://github.com/keithlscott/opennetem. It comes with a test scenario that uses LTP convergence layers.

The replacement for LTPCL is very much on CCSDS' todo list.  There's a draft available to CCSDS dtn working group members but I'm not sure if that's publicly available.  Let me see if that could be made available....

    --keith



On Mon, Apr 1, 2024 at 8:06 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi, John.  A quick answer that can be discussed further if needed: the LTP specification has not changed since RFC 5326, so that expired LTP CL spec should still be usable for software development – though it’s not a published standard that can be cited in a quote or bid, so you’re out of luck if that’s needed.

The successor to LTP, currently under development in CCSDS DTN WG, will not be backward-compatible with LTP, and no CL specification for that protocol exists yet anyway, so at this time it’s not an option.

Scott

From: dtn <[e-mail]<mailto:[e-mail]>> On Behalf Of John Dowdell
Sent: Monday, April 1, 2024 9:34 AM
To: DTN WG <[e-mail]<mailto:[e-mail]>>
Subject: [dtn] LTP CL for BP v7

Dear all

I have been looking for a published specification for LTP CL without success. The only draft I can find is one from Scott that expired some years back. I can see that ION-DTN has a LTP CL function but I’m not quite sure how that works.

I have a need to build a stack that includes at least LTP v1 and BP v7, and hence the need for a working LTP CL. If the upcoming LTP v2 works with that same CL, all well and good but I get the feeling that it won’t.

Can someone help me out here please? LTP CL seems to be on nobody’s current to-do list, neither IETF nor CCSDS, and I need something for the project I’m working on (those of you who know me will know what this is).

Many thanks

John






_______________________________________________
dtn mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dtn
_______________________________________________
dtn mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dtn

_______________________________________________
dtn mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dtn
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer ([e-mail]).