[Sis-dtn] [EXTERNAL] [BULK] Fragmentation in BPv7 Orange Book

[Singh, Somendra {Simon} (GSFC-5820)]

Please see my comments below.

Best regards
Simon Singh
CCSDS SOIS Area Director
CCSDS SOIS-AP WG Chair
NASA/GSFC DTN Systems Engineer


From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Lars Baumgaertner via SIS-DTN
Sent: Friday, June 27, 2025 12:54 PM
To: sis-dtn at mailman.ccsds.org
Subject: [EXTERNAL] [BULK] [Sis-dtn] Fragmentation in BPv7 Orange Book

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.


While looking through the PICS tests in the latest BPv7 OB draft, I was a bit confused about the handling of fragmentation in the light of the most recent discussions.


[cid:image001.png at 01DBE76B.C802DF70]

Fragmentation itself is OPTIONAL in #31.
#32 is CONDITIONAL as it only makes sense if #31 is implemented.
#34 is OPTIONAL, so BPAs can choose to do on-path ADU reassembly.

But #33 is MANDATORY, meaning EVERY BPA must support ADU reassembly.
So even if we forbid fragmentation, and the feature at the source node is optional, all BPA that want to be compliant must still implement ADU reassembly logic and act upon it at the receiving end. This is quite a burden, increases attack surface and just seems unnecessary for an optional feature and something which might be forbidden per policy in most deployments anyhow.

Here is my interpretation of PICS.33
Every implementation must support ADU reassembly.
Any node can be a destination for fragmentary bundles and the destination node of  the these fragmentary (such that they have same srcID, Timestamp, Sequence Number, ADU length) is the final chance (actually the only chance if we disregard multicasting) to recover the ADU (which the dest node must before delivering the ADU.)
Any implementation not supporting ADU reassembly is not compliant with RFC 9171.
"Not using fragmentation" recommendation is more like user level agreement, rather than something that is baked into the CCSDS books and we expect that to change in future.


wrt PICS.34
This actually does not make sense since the original bundle is never recovered as per RFC 9171, therefore any intermediate node that assembles ADU will not be able to forward the bundle and this will not be compliant with RFC 9171 forwarding requirements

Wouldn't it make sense to make this OPTIONAL as well since consensus now seems to be not to do fragmentation at all (at least in the short to mid term)?
One could also read the feature description as IF/WHEN doing reassembly (which itself is optional) it should then follow the rfc procedures, but then it would be CONDITIONAL, right?
Or maybe there is another way to read #33 that I missed...

Kind regards and have a nice weekend,
Lars

--
Lars Baumgaertner
Internal Research Fellow (OPS-GAE)
European Space Agency ESA/ESOC
Robert-Bosch-Str. 5, D-64293 Darmstadt

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/20250627/ba9f2590/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 32107 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250627/ba9f2590/attachment-0001.png>