<div dir="auto">This seems somewhat complex, and more concerning, deviates from 9171. I suggest that if we want such behavior we define an extension block for it, maybe with exactly the semantics you propose. <div dir="auto"><br></div><div dir="auto">With an extension block: </div><div dir="auto">No questions or issues of interoperability with "only" 9171- compliant implementations</div><div dir="auto"><br></div><div dir="auto">No worry about deconflicting duplicate creation timestamps. </div><div dir="auto"><br></div><div dir="auto">Sorry of a perfect user case for an extension block, imho. New capability beyond the original spec useful to some group of users...</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"> Keith</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 9, 2023, 4:42 PM Felix Flentge via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="m_2884460154249875987WordSection1">
<p class="MsoNormal">Dear All,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I think we have had some initial exchange on the use of the sequence number in the bundle creation timestamp some time ago. Meanwhile, we had a number of side meetings with Jonathan, Simon and others to further discuss the topic of ‘flows’,
compressed bundle reporting and network management.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">We have arrived at a point where we think that it makes sense to allow using the sequence number in the primary header for identifying gaps in sequences of bundles or to even allow for in-sequence delivery.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The basic idea is that the sequence number does not get reset to zero but is incrementing by one until a specified maximum. Further we might use different, individual sequence numbers per source node ID or per destination endpoint ID. Such
a behaviour might be governed by policy or even indicated in the Primary Block’s Processing Control Flags, like<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="m_2884460154249875987MsoListParagraph" style="margin-left:0cm"><span>Use two bits to specify whether the creation timestamp sequence number is used in special way:<u></u><u></u></span></li></ol>
<p class="MsoNormal"><u></u> <u></u></p>
<ul style="margin-top:0cm" type="disc">
<li class="m_2884460154249875987MsoListParagraph" style="margin-left:0cm"><span>00 – single sequence number - no specific usage<u></u><u></u></span></li><li class="m_2884460154249875987MsoListParagraph" style="margin-left:0cm"><span>01 – an individual sequence number is used per source node id<u></u><u></u></span></li><li class="m_2884460154249875987MsoListParagraph" style="margin-left:0cm"><span>10 – an individual sequence number is used per destination endpoint id<u></u><u></u></span></li><li class="m_2884460154249875987MsoListParagraph" style="margin-left:0cm"><span>11 – reserved (until we find a good usage; maybe individual sequence number per next hop)<u></u><u></u></span></li></ul>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>In case 10 with different destination endpoint IDs, the BPA has to guarantee that the same values can only appear with different bundle creation times!<u></u><u></u></b></p>
<p class="MsoNormal"><u></u> <u></u></p>
<ol style="margin-top:0cm" start="2" type="1">
<li class="m_2884460154249875987MsoListParagraph" style="margin-left:0cm"><span>Use of two bits to indicate the maximum length of the sequence number (00 above) or individual sequence numbers (01 and 10 above):<u></u><u></u></span></li></ol>
<ul type="disc">
<li class="MsoNormal">
00 - sequence numbers are assigned somehow (reset to zero, randomly, ..)<span><u></u><u></u></span></li><li class="MsoNormal">
01 - increasing sequence number up to 2^16-1<u></u><u></u></li><li class="MsoNormal">
10 - increasing sequence number up to 2^32-1<u></u><u></u></li><li class="MsoNormal">
11 - increasing sequence number up to 2^64-1<u></u><u></u></li></ul>
<p class="MsoNormal">My main questions:<u></u><u></u></p>
<ol style="margin-top:0cm" start="1" type="1">
<li class="m_2884460154249875987MsoListParagraph" style="margin-left:0cm"><span>Does it make sense to use flags in the primary header for this purpose or is it sufficient to document that sequence numbers can be used in
that way and leave it up to policy to specify certain behaviours? I have a slight preference for using the BPCF as it seems more formal and could ease interoperability (and the sequence number is in the primary header, so why not indicate it there).<u></u><u></u></span></li><li class="m_2884460154249875987MsoListParagraph" style="margin-left:0cm"><span>If we want to use BPCF, what is the way to specify this? Should we / do we need to go IETF or could CCSDS be sufficient (to start with)? Ideally
we would use some of the reserved first 16 bits (e.g. Bit 7 – 10)<u></u><u></u></span></li><li class="m_2884460154249875987MsoListParagraph" style="margin-left:0cm"><span>No matter whether we want to use BCPF or not, I think something should end up in the CCSDS BB as soon as possible. So, maybe there is a chance
for a late RID (if it does not delay the overall publication process). We should start discussing (maybe tomorrow).</span><span><u></u><u></u></span></li></ol>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span>Regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span>Felix<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
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" target="_blank" rel="noreferrer">dpo@esa.int</a>).
</div>
_______________________________________________<br>
SIS-DTN mailing list<br>
<a href="mailto:SIS-DTN@mailman.ccsds.org" target="_blank" rel="noreferrer">SIS-DTN@mailman.ccsds.org</a><br>
<a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn" rel="noreferrer noreferrer" target="_blank">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</a><br>
</blockquote></div>