<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:Aptos;
mso-ligatures:standardcontextual;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#96607D;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:Aptos;
mso-ligatures:standardcontextual;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:Aptos;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1014957678;
mso-list-type:hybrid;
mso-list-template-ids:-436274816 134807567 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1274747413;
mso-list-template-ids:-1258896968;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#467886" vlink="#96607D">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Hi Felix, all,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Tomaso<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif;mso-ligatures:none">From:</span></b><span style="font-family:"Calibri",sans-serif;mso-ligatures:none"> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Felix Flentge via SIS-DTN<br>
<b>Sent:</b> Montag, 30. Juni 2025 08:18<br>
<b>To:</b> Singh, Somendra {Simon} (GSFC-5820) <simon.singh@nasa.gov>; Lars Baumgaertner <Lars.Baumgaertner@esa.int>; sis-dtn@mailman.ccsds.org<br>
<b>Subject:</b> Re: [Sis-dtn] [EXTERNAL] [BULK] Fragmentation in BPv7 Orange Book<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-GB">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">A couple of points<o:p></o:p></span></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3"><span lang="EN-GB">We should avoid anything which delays the Orange Book further<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3"><span lang="EN-GB">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. <o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3"><span lang="EN-GB">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).<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3"><span lang="EN-GB">IMHO, IETF should update/correct RfC 9171 but this seems to be more complex and nobody seems willing to do right now.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3"><span lang="EN-GB">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...).<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="mso-ligatures:none">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-ligatures:none">Felix<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span style="font-family:"Calibri",sans-serif;mso-ligatures:none">From:</span></b><span style="font-family:"Calibri",sans-serif;mso-ligatures:none"> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>Singh, Somendra {Simon} (GSFC-5820) via SIS-DTN<br>
<b>Sent:</b> 27 June 2025 20:10<br>
<b>To:</b> Lars Baumgaertner <<a href="mailto:Lars.Baumgaertner@esa.int">Lars.Baumgaertner@esa.int</a>>;
<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> Re: [Sis-dtn] [EXTERNAL] [BULK] Fragmentation in BPv7 Orange Book<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Calibri",sans-serif;color:#1F497D">Please see my comments below.<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Calibri",sans-serif;color:#1F497D">Best regards<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Calibri",sans-serif;color:#1F497D">Simon Singh<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Calibri",sans-serif;color:#1F497D">CCSDS SOIS Area Director<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Calibri",sans-serif;color:#1F497D;mso-ligatures:none">CCSDS SOIS-AP WG Chair<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Calibri",sans-serif;color:#1F497D;mso-ligatures:none">NASA/GSFC DTN Systems Engineer<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span style="font-family:"Calibri",sans-serif;mso-ligatures:none">From:</span></b><span style="font-family:"Calibri",sans-serif;mso-ligatures:none"> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>Lars Baumgaertner via SIS-DTN<br>
<b>Sent:</b> Friday, June 27, 2025 12:54 PM<br>
<b>To:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> [EXTERNAL] [BULK] [Sis-dtn] Fragmentation in BPv7 Orange Book<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<table class="MsoNormalTable" border="1" cellspacing="0" cellpadding="0" align="left" width="100%" style="width:100.0%;border:solid black 1.5pt">
<tbody>
<tr>
<td width="100%" style="width:100.0%;border:none;background:#FFEB9C;padding:3.75pt 3.75pt 3.75pt 3.75pt">
<p class="MsoNormal" style="mso-element:frame;mso-element-frame-hspace:2.25pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly">
<b><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;color:black;mso-ligatures:none">CAUTION:</span></b><span style="font-family:"Calibri",sans-serif;color:black;mso-ligatures:none">
</span><span style="font-size:10.0pt;font-family:"Calibri",sans-serif;color:black;mso-ligatures:none">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.</span><span style="font-family:"Calibri",sans-serif;color:black;mso-ligatures:none">
</span><span style="font-family:"Calibri",sans-serif;mso-ligatures:none"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<span lang="EN-GB" style="font-family:"Calibri",sans-serif;mso-ligatures:none"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-size:12.0pt;mso-ligatures:none"><img border="0" width="638" height="570" style="width:6.6458in;height:5.9375in" id="Picture_x0020_1" src="cid:image001.png@01DBE99F.2F1C7E70"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">Fragmentation itself is OPTIONAL in #31.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">#32 is CONDITIONAL as it only makes sense if #31 is implemented.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">#34 is OPTIONAL, so BPAs can choose to do on-path ADU reassembly.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">But #33 is MANDATORY, meaning EVERY BPA must support ADU reassembly.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">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.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#5B9BD5">Here is my interpretation of PICS.33<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#5B9BD5">Every implementation must support ADU
</span><span lang="EN-GB" style="color:#5B9BD5">reassembly. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="color:#5B9BD5">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.)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="color:#5B9BD5">Any implementation not supporting ADU reassembly is not compliant with RFC 9171.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="color:#5B9BD5">“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.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="color:#5B9BD5"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="color:#5B9BD5"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="color:#5B9BD5">wrt PICS.34<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="color:#5B9BD5">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</span><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#5B9BD5"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">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)?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">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?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">Or maybe there is another way to read #33 that I missed…<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">Kind regards and have a nice weekend,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">Lars<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">-- <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">Lars Baumgaertner<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">Internal Research Fellow (OPS-GAE)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">European Space Agency ESA/ESOC<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB">Robert-Bosch-Str. 5, D-64293 Darmstadt<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;mso-ligatures:none">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 (<a href="mailto:dpo@esa.int">dpo@esa.int</a>).
<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;mso-ligatures:none">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 (<a href="mailto:dpo@esa.int">dpo@esa.int</a>). <o:p></o:p></span></p>
</div>
</body>
</html>