[Sis-dtn] [dtn] Re: Bundle Transfer Protocol - Unidirectional

Fri Mar 14 17:39:25 UTC 2025

With DVB-S2(x), one may use GSE (see here<https://www.etsi.org/deliver/etsi_ts/102600_102699/10260601/01.03.01_60/ts_10260601v010301p.pdf> for the protocol specification) to transport PDUs from “any” network layer (obviously BP is not envisioned presently) in DVB BB frames. In the past instead MPE was used for the same purpose, to still go with MPEG TS, but its efficiency is lower than with GSE because of the overhead.
In my institute at DLR we have quite some expertise on DVB (-S2, S2x, -RCS2) as we were involved in different aspects of the specifications in the last two decades, so in case you have more specific questions I can try to bridge you to some of my colleagues.

Regards,

Tomaso

From: Rick Taylor <rick at tropicalstormsoftware.com>
Sent: Freitag, 14. März 2025 12:46
To: de Cola, Tomaso <Tomaso.deCola at dlr.de>; Felix.Flentge at esa.int; sburleig.sb at gmail.com; dtn at ietf.org; durst at mitre.org; sis-dtn at mailman.ccsds.org
Subject: RE: [dtn] Re: Bundle Transfer Protocol - Unidirectional

Hi Tomaso,

I’m not 100% sure how one would transport BTPU over DVB (most likely DVB-S2X).

My general thoughts (and they are very rough right now) is that all BTPU messages would be carried over the frames of a single channel, hopefully avoiding the need to add extra layers of complexity between the BPA and the RF interface.   However, I am most definitely not a DVB expert, and would love to collaborate with someone who knows the spec well.

I think a multi-channel-per-priority approach would add unneeded complexity as it would require coordination in the process that selects a channel for a particular message stream., and it stops being BTPU at that point.  That being said, there is no reason why multiple BTPU instances couldn’t run over multiple channels, and the BPA select the correct BTPU-CL for the relevant priority – that would be a deployment decision.

There is a lack of clarity in DTN deployment design when it comes to prioritisation.  In my opinion, the BPA can choose different CLAs based on the priority of a bundle as well as the routing, and a CLA may support prioritisation in its CLP, such that a BPA can rely on a CLA to not invert priority (or something else dumb).  But the CLA must expose it’s multi-priority capability to the BPA, to enable the right decision to be made.

Definitely a partial answer, sorry!

Cheers,
Rick

From: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de> [mailto:Tomaso.deCola at dlr.de]
Sent: 14 March 2025 10:10
To: Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>; Rick Taylor; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; dtn at ietf.org<mailto:dtn at ietf.org>; durst at mitre.org<mailto:durst at mitre.org>; sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: RE: [dtn] Re: Bundle Transfer Protocol - Unidirectional

Hi all,

Just two bits from my side. If we intend interleaved frames something like the following, this should be supported by the CCSDS SDLP existing specifications:

[cid:image001.png at 01DB9510.6276CD90]
Concerning instead the DVB-S2/S2x support in CCSDS, this was done in such a way to keep backward compatibility to the CCSDS protocol stack, i.e. still using the CCSDS transfer frame on top of the DVB-S2 framework. This was the agreement reached in 2009 from the space agencies involved in the coding&synchronization WG.
@Rick Taylor<mailto:rick at tropicalstormsoftware.com>: how do you plan to transport BTPU over DVB, through GSE or differently?

Regards,

Tomaso
From: Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>
Sent: Freitag, 14. März 2025 09:13
To: Rick Taylor <rick at tropicalstormsoftware.com<mailto:rick at tropicalstormsoftware.com>>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; dtn at ietf.org<mailto:dtn at ietf.org>; ''Robert C Durst'' <durst at mitre.org<mailto:durst at mitre.org>>; Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: [dtn] Re: Bundle Transfer Protocol - Unidirectional

Hi Rick,

Thanks for your comments. They helped to clarify the scope. Please find some replies below.

Regards,
Felix

From: Rick Taylor <rick at tropicalstormsoftware.com<mailto:rick at tropicalstormsoftware.com>>
Sent: 12 March 2025 18:48
To: Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; dtn at ietf.org<mailto:dtn at ietf.org>; ''Robert C Durst'' <durst at mitre.org<mailto:durst at mitre.org>>; Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: RE: [dtn] Re: Bundle Transfer Protocol - Unidirectional

Hi Felix,

Thanks for the review, comments inline with [RT].

________________________________
From: Felix Flentge [Felix.Flentge at esa.int]
Sent: 12 March 2025 14:50
To: Rick Taylor; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; dtn at ietf.org<mailto:dtn at ietf.org>; ''Robert C Durst''; Dr. Keith L Scott via SIS-DTN
Subject: RE: [dtn] Re: Bundle Transfer Protocol - Unidirectional
Well,

Before complaining (😉) I have a few questions/comments (in particular, looking at this from a CCSDS point of view):

[RT]. Complaining is good, it shows you care ;)

1.      Regarding the use case of ‘unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame-based link-layer protocol, without requiring IP services’:

a.       This already seems to be addressed by Encapsulation Packet Protocol (https://public.ccsds.org/Pubs/133x1b3e1.pdf) and Space Packet Protocol (https://public.ccsds.org/Pubs/133x0b2e2.pdf); both work perfectly fine on uni-directional links and are fully compatible with all CCSDS Space Data Link Protocols and Space Data Link Security Protocol. Use of SPP over uni-directional links for payload downlink is common practice for all ESA Earth Observation missions (though, no BP yet). Reliability is typically addressed closer to the physical layer (coding & modulation) or at a higher layer (CFDP, LTP).

[RT]. BTPU is not intended to be a replacement for EPP or SPP, I foresee it's major use over DVB and Ethernet, but that being said it should run easily on top of SPP and EPP as required, much like LTP.  It's important to remember that an IETF protocol is nothing more than a peer-reviewed protocol, it is not a mandated replacement for any other technology.  That being said, I can see a very slim profile of BTPU over SPP or EPP being something CCSDS could produce, as BTPU does provide some capabilities that EPP/SPP do not.

[FF] OK, understood. I would like to add that there is actually https://public.ccsds.org/Pubs/131x3b2e1.pdf and https://public.ccsds.org/Pubs/131x31o1c1.pdf  for DVB-S2 and DVB-S2X in CCSDS although this is below the SDLP. I don’t know the rationale for that decision. Some useful information may be in https://public.ccsds.org/Pubs/130x12g2.pdf. BP/Ethernet may be an interesting case. I would see this mainly terrestrial and for maybe telecommunication constellation (which are not so much covered in CCSDS).

a.       High-Performance Reliability Protocol does also include an unreliable mode for uni-directional links and is fully compatible with CCSDS Packet and Frame layers.

[RT] That's good to hear, but I haven't read any HPRP docs, so I can't comment.  However, I would love to read them if you have a link?

[FF] I will need to check with the co-authors. However, I am happy to make it available upon personal request.

So, my questions is why these protocols are not adequate for this use case?

[RT]. I think they are, but BTPU may provide additional capabilities (e.g. multiplexed transfers) that may be desirable, and have applicability outside CCSDS.  Again, BTPU is not a proposed replacement, just another protocol.

[FF] OK, understood. What concerns me slightly is, however, that we define ‘just another protocol’ while we are struggling to get some basic stuff out quickly. Having more protocols can also create some noise for DTN adoption in space (I don’t see any chances for that in LunaNet) and makes interoperability a bit more trickier. However, if there are good terrestrial or telecom constellation use case, why not.

2.       Regarding ‘...supports data repetition as a mechanism to protect against data loss’:
In space communication we typically try to address reliability at coding and modulation layer (where we can better adapt to the specific link characteristics). Simple repetition does not seem to be a very efficient way. It is sometimes done in spacecraft emergencies (‘hammering mode’) but for routine operations, I believe we can do better (increased coding or re-transmission protocol).

[RT] Completely agree.  As I said to Scott B, repetition is not explicitly forbidden in the spec, and therefore is properly documented, and it may have uses over very basic link-layers or in 'data fountain' use-cases.  It's worth remembering that repetition is a per transfer option, so one could repeat segments of one bundle transfer and not others to give finer-grained control.   That said, link-layer mechanisms are probably better and more robust in most cases.

2.       Regarding ‘... supports the disaggregation of flows of bundles of different priority, preventing head-of-line blocking impacting performance.’
Priorities can be implemented on different levels; for me it makes definitely sense to have it at BP level as this can be universal across convergence layers; for CCSDS Space Data Links, it can be based on Virtual Channels; not sure if there is something required in addition but if so, we should try to describe the relation between these priorities at different layers.

[RT] Agreed.  Prioritisation is definitely a BPA task, but CLs ought to support priority when multiplexing transfers, and hence BTPU documents how to do it.  Of course, when a link-layer supports virtual channels, that too can be a perfectly valid mechanism.

2.       EPP/SPP provide the functionality to go from variable-size large data structure to fixed length data structures (HPRP/LTP as well). In addition to padding (via insertion of idle packets), they also allow for aggregation in case there is ‘space left’ in a frame. This is much more efficient then padding. I would assume that the same mechanism (packet service) could be used with BTPU when running over CCSDS Space Data Link Protocols.

[RT]. Yes. When the link-layer supports variable-length "frames" then padding is unnecessary.  It's inclusion is for when the link-layer doesn't.  The aggregation capability is implicit in the Message paradigm, a BTPU CLA is expected to pack messages into frames efficiently, and only use padding when it must.  When the link-layer does the packing, then no further action is required, apart from avoiding degenerate message sizes.

2.       Sequence numbering is provided on CCSDS Space Data Link layer (and I would think also for other frame layer protocols); I am not sure whether an additional segment level sequence numbering is required.

[RT]. The sequence number is a slightly different concept, as it defines the segment index of a particular transfer, rather than an ordering of messages.  Perhaps I should rename the field to 'Segment Index' to clarify.

[FF] OK, although functionality seems similar (ensure correct reconstruction of the binary block).

2.       Cancelling of transfer seems possible for EPP/SPP over CCSDS SDLP by just starting with the next packet (the previous packet is just incomplete but as re-assembly is based on First Header pointer and not length information this is fine).

[RT]. That's great.  In that case, one doesn't need to use the Transfer Cancel - unless one wants to cancel a single Transfer (e.g. Time to live expires) but continue with other Transfers, but that depends on how one layers BTPU over EPP/SPP over SDLP.

2.       BPTU-FEC extension: the topic of Forward Error Correction at higher protocol layers comes up from time-to-time; I currently fail to see the advantages compared to FEC we do at coding & modulation close to the physical layer which seems much more targeted to the specific link. To me, it seems also violating the layering principle a bit (I assume for defining a FEC at a higher level you need to make some assumptions on the lower layer).

[RT]. I actually agree with you.  FEC to me seems like a property of the link-layer, however I have been asked about it so many times by others that I thought I would just type up an entirely optional extension to BTPU describing how one could use FEC on a per-transfer basis, if you really wanted it.  The major sensible use-case is perhaps in the 'data fountain' use-case, where one wants to add excessive redundancy for operational reasons.

2.       What may be missing at CCSDS (TBC) may be the ‘interleaving’ of transfers. However, I am not sure whether this would justify an additional protocol. I don’t see strong use cases (I think this can typically be addressed by sizing the data blocks to be transmitted to sizes adequate for the available data rates + maybe  VC multiplexing).The distinction between emission and transmission is very useful. However, this whole topic could be quite complex as we would need to consider different on-board architectures (Mass-memory units, on-board busses, buffers in terminals).

[RT]. Head of line blocking is one of those things that really needs to be prevented if one is transferring more than one bundle over a link during a contact.  In the BTPU case, with multiple transfers, multiplexing (and cancelling) seems the right way to go.  Having the extra complexity does allow one to do smarter things with resource exhaustion etc, so happy to continue the discussion.

[FF] Yes, definitely worth looking closer into this. We have had similar issues when defining BP QoS Extensions. I think we would benefit from real use cases and the consideration of typical on-board architectures (where eg frame generation is implemented in terminals while bundles are generated in the data handling system and then send via a bus system). It seems a rather complex topic I am hoping to address a bit in upcoming study activities.

2.       Overall, EPP seems to cover at least some of the functionality, it is well specified, fully compatible with the CCSDS stack, baselined for LunaNet and seems less complex then BTPU. EPP does not require the management of multiple transfers or different message types, so seems to be quite straight-forward to be implemented in hardware at high data rates.

[RT]. Yes.  I like EPP/SPP and fully support them.  BTPU is not designed to replace either.  I can imagine a BTPU service running over a EPP/SPP stack that is also carrying IP and TT&C in parallel in a very efficient manner.

[FF] Yes. I don’t see any issues with that.

2.       Summary (sorry, I may have ended up complaining): I currently don’t see a clear use case (at CCSDS) for another protocol doing partially what we can already do with EPP (or SPP for smaller bundles and HPRP in the future if we also want to have a re-transmission option in case we have a bi-directional link). I would propose more of an ‘Adopt – Adapt – Improve’ approach. I am also slightly concerned about the mixing of functions (segmentation, data repetition, priorisation, maybe FEC) which might be better addressed separately (or are also addressed at other layers).

[RT]. And that's fine by me.  As I said at the beginning, I see BTPU of interest outside CCSDS, and maybe in the commercial space sector where AOS or TM exist without the upper layers of the CCSDS stack.  I'm just trying to put another tool in the toolbox, rather than propose a replacement for anything.

[FF] Maybe even more a case where even no AOS/TM exists. Maybe over Cubesat Protocol?

Thanks for the thorough review!

(Aargh - It looks like Outlook has renumbered all the paragraphs - sorry)

Cheers,
Rick

<snip>
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 (dpo at esa.int<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250314/1f28201a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 30758 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250314/1f28201a/attachment-0001.png>