[Sis-dtn] Special use of sequence number in bundle creation time stamp

[Keith Scott]

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.

With an extension block:
No questions or issues of interoperability with "only" 9171- compliant
implementations

No worry about deconflicting duplicate creation timestamps.

Sorry of a perfect user case for an extension block, imho.  New capability
beyond the original spec useful to some group of users...


    Keith


On Wed, Aug 9, 2023, 4:42 PM Felix Flentge via SIS-DTN <
sis-dtn at mailman.ccsds.org> wrote:

> Dear All,
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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
>
>
>
>    1. Use two bits to specify whether the creation timestamp sequence
>    number is used in special way:
>
>
>
>    - 00 – single sequence number - no specific usage
>    - 01 – an individual sequence number is used per source node id
>    - 10 – an individual sequence number is used per destination endpoint
>    id
>    - 11 – reserved (until we find a good usage; maybe individual sequence
>    number per next hop)
>
>
>
> *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!*
>
>
>
>    1. Use of two bits to indicate the maximum length of the sequence
>    number (00 above) or individual sequence numbers (01 and 10 above):
>
>
>    - 00 - sequence numbers are assigned somehow (reset to zero, randomly,
>    ..)
>    - 01 - increasing sequence number up to 2^16-1
>    - 10 - increasing sequence number up to 2^32-1
>    - 11 - increasing sequence number up to 2^64-1
>
> My main questions:
>
>    1. 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).
>    2. 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)
>    3. 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).
>
>
>
> Regards,
>
> Felix
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230809/e470d648/attachment.htm>