[Sis-dtn] SOLO PER TE: [EXTERNAL] [BULK] Fragmentation in BPv7 Orange Book

Mon Jun 30 10:35:55 UTC 2025

 SE RICORDO BENE........   I libri arancioni (come il pel di carota che governa là) sfuggono un po' a tutte le regole  :o) 

Quindi non hai in genere bisogno di aspettare 5 anni per un update.
E poi puoi sempre giocarti un editorial corrigendum, o al più un technical corrigendum.
Ma magari è meglio non dirlo a quelli del WG  :o) 
Per il resto come va?
Ciao
Gippo
   ----- Messaggio inoltrato ----- Da: Tomaso de Cola via SIS-DTN <sis-dtn at mailman.ccsds.org>A: "felix.flentge at esa.int" <felix.flentge at esa.int>; "simon.singh at nasa.gov" <simon.singh at nasa.gov>; "lars.baumgaertner at esa.int" <lars.baumgaertner at esa.int>Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>Inviato: lunedì 30 giugno 2025 alle ore 09:55:50 CESTOggetto: Re: [Sis-dtn] [EXTERNAL] [BULK] Fragmentation in BPv7 Orange Book

Hi Felix, all,

I definitely agree that at this point in time it is now worth taking back to the orange book and make a rework (though light) to address these issues, since this would imply a new CESG review, etc., i.e. 1-2 months delay in the publication. If necessary we can at some point revise the orange book to go for a version 2 of the book, although this is not so usual and typically happens with the 5-years review. Or if we want to issue recommendations/warning this is something we can go with errata/corrige in the same way we did for the LTP reaffirmation to recommend users not to implement mixed colours and other aspects of the spec. But also this I’d say could be done after the publication of the current version.

The main problem I see in general is that as long as IETF does not fix this problem, our blue books cannot really deviate from the existing RFCs as we are supposed to have CCSDS profiles of IETF specifications.

Regards,

Tomaso

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org>On Behalf Of Felix Flentge via SIS-DTN
Sent: Montag, 30. Juni 2025 08:18
To: Singh, Somendra {Simon} (GSFC-5820) <simon.singh at nasa.gov>; Lars Baumgaertner <Lars.Baumgaertner at esa.int>; sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] [EXTERNAL] [BULK] Fragmentation in BPv7 Orange Book

Hi,

A couple of points

   - We should avoid anything which delays the Orange Book further
   - The Blue Book shall clearly indicate that CCSDS-compliant implementations shall not ADU-fragment bundles and are not required to re-assemble those even if this makes them technically non Rfc 9171 compliant. 
   - Whether they need to be able to forward fragments, is maybe TBD although I am against this (in practice, we will probably not get implemented).
   - IMHO, IETF should update/correct RfC 9171 but this seems to be more complex and nobody seems willing to do right now.
   - It would be beneficial if we could get some comment/recommendation/warning about fragmentation in the OB before publication; I think this would be agreeable to the whole WG (and it is ‘just’ an Orange Book) but it might interfere with the CCSDS processes (on the other hand, if CESG/CMC points out that there is a technical problem with fragmentation we might happily change it...).

Regards,

Felix

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org>On Behalf Of Singh, Somendra {Simon} (GSFC-5820) via SIS-DTN
Sent: 27 June 2025 20:10
To: Lars Baumgaertner <Lars.Baumgaertner at esa.int>;sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] [EXTERNAL] [BULK] Fragmentation in BPv7 Orange Book

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.

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 ADUreassembly. 

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).

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). 
 _______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn

|  | Virus-free.www.avast.com |

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250630/9b1c5e2c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 32107 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250630/9b1c5e2c/attachment-0001.png>