[Sis-dtn] New Draft: COMPRESSED CUSTODY SIGNALING AND BUNDLE STATUS REPORTING

Fri May 16 14:56:55 UTC 2025

Felix, I think that sounds good. This strategy is used in other CBOR-based
encodings so not bespoke for this situation.

If you would like to include CDDL for the entire structures, I could help
out. I think there is non-normative value in CDDL for helping to interpret
the normative statements. It also makes example data generation and
validation easier and more automated.

From: Felix Flentge <Felix.Flentge at esa.int> 
Sent: Friday, May 16, 2025 10:47 AM
To: Sipos, Brian J. <Brian.Sipos at jhuapl.edu>; sis-dtn at mailman.ccsds.org
Cc: Juan A. Fraire <juan.fraire at inria.fr>; Alice Le Bihan
<alice.le-bihan at insa-lyon.fr>; Jeck, Yanik <yanik.jeck at cgi.com>; Kramp,
Paul-Niklas <paul-niklas.kramp at cgi.com>
Subject: [EXT] RE: New Draft: COMPRESSED CUSTODY SIGNALING AND BUNDLE STATUS
REPORTING

APL external email warning: Verify sender Felix.Flentge at esa.int
<mailto:Felix.Flentge at esa.int>  before clicking links or attachments

Hi Brian,

I have discussed with Yanik (who may still not have access to the CCSDS
mailinglist...) and he came up with the following proposal:

In terms of wording, I think it would be clearer to keep the definition for

the Bundle Sequence Range as is and modify the definition for the Bundle
Sequence instead. 

I.e., we could append an "or a CBOR uint" to describe the Bundle Sequence
Range (field).

This could e.g., look like:

Bundle Sequence Range - A Bundle Sequence Range as defined in 3.3.2 below 

       or 

       A CBOR unsigned integer if there is only a single sequence to be
included, representing the length of that sequence

I suppose, put in CDDL, this could then look like this instead:

seq = [

  seq-id: uint / eid,

  seq-start: uint,

  range: seq-range / seq-incl-len,

  ? blk-source: eid

]

seq-range = [ seq-incl-len, + ( seq-excl-len, seq-incl-len) ]

seq-incl-len = uint .gt 0 ; inclusive length

seq-excl-len = uint .gt 0 ; exclusive length

Regards,

Felix

From: Sipos, Brian J. <Brian.Sipos at jhuapl.edu
<mailto:Brian.Sipos at jhuapl.edu> > 
Sent: 15 May 2025 15:09
To: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >;
sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> 
Cc: Juan A. Fraire <juan.fraire at inria.fr <mailto:juan.fraire at inria.fr> >;
Alice Le Bihan <alice.le-bihan at insa-lyon.fr
<mailto:alice.le-bihan at insa-lyon.fr> >; Jeck, Yanik <yanik.jeck at cgi.com
<mailto:yanik.jeck at cgi.com> >; Kramp, Paul-Niklas <paul-niklas.kramp at cgi.com
<mailto:paul-niklas.kramp at cgi.com> >
Subject: RE: New Draft: COMPRESSED CUSTODY SIGNALING AND BUNDLE STATUS
REPORTING

Felix,

Thanks for consideration of my earlier suggestion. I think the definition of
Bundle Sequence Range in Sec 3.3 is consistent and understandable.

There is one possible compression, saving one byte, in the case where the
array would have a single uint item it can be substituted with the uint
itself. It doesn't affect the information model being encoded, but does add
a small coding / decoding overhead to apply the compression. So it's
completely optional if you think there is that much value in one byte. (This
compressed form would also degenerate to your earlier form of start + length
if there are no excluded intervals)

Put in CDDL, the `seq-range` would include the following (with rule `eid`
taken from RFC 9171 appendix)

seq = [

  seq-id: uint / eid,

  seq-start: uint,

  seq-range,

  ? blk-source: eid

]

seq-range = [ seq-incl-len, + ( seq-excl-len, seq-incl-len) ] / seq-incl-len

seq-incl-len = uint .gt 0 ; inclusive length

seq-excl-len = uint .gt 0 ; exclusive length

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org
<mailto:sis-dtn-bounces at mailman.ccsds.org> > On Behalf Of Felix Flentge via
SIS-DTN
Sent: Wednesday, May 14, 2025 9:11 AM
To: Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org
<mailto:sis-dtn at mailman.ccsds.org> >
Cc: Juan A. Fraire <juan.fraire at inria.fr <mailto:juan.fraire at inria.fr> >;
Alice Le Bihan <alice.le-bihan at insa-lyon.fr
<mailto:alice.le-bihan at insa-lyon.fr> >; Jeck, Yanik <yanik.jeck at cgi.com
<mailto:yanik.jeck at cgi.com> >; Kramp, Paul-Niklas <paul-niklas.kramp at cgi.com
<mailto:paul-niklas.kramp at cgi.com> >
Subject: [EXT] [Sis-dtn] New Draft: COMPRESSED CUSTODY SIGNALING AND BUNDLE
STATUS REPORTING

APL external email warning: Verify sender sis-dtn-bounces at mailman.ccsds.org
<mailto:sis-dtn-bounces at mailman.ccsds.org>  before clicking links or
attachments

Hi,

I have just uploaded Draft H of the 'Compressed Custody Signaling And Bundle
Status Reporting' Orange Book to CWE:

<https://spacecomm.sharepoint.com/:w:/r/sites/SIS/_layouts/15/Doc.aspx?sourc
edoc=%7B10790F7B-6318-4BD0-9D53-8813C83BE941%7D&file=CompressedBundleStatusR
eportingAndCustodySignaling_OrangeBook_Draft_H.docx&action=default&mobilered
irect=true>
CompressedBundleStatusReportingAndCustodySignaling_OrangeBook_Draft_H.docx

We have introduced the following changes:

1)     Based on Brian's proposal to make the reporting even more efficient,
Yanik analysed and designed a new way to encode bundle sequences which may
contain some gaps (see updated Section 3.3). It is not so easy to come up
with some concise language for that, so please let us know if you have
suggestions for improvement.

2)     I took the opportunity to not allow processing of the CREB/CTEB
blocks in fragments:

3.4.1        Extension Blocks specified in this specification shall only be
added and processed in non-fragmented bundles.

NOTE - As later fragmentation of bundles using the extension blocks
specified in this specification may lead to unintended effects such as loss
of expected reporting or custody signals as fragmented bundles are never
re-assembled (RfC 9171 does only specify Application Data Unit Re-Assembly),
it is recommended to set the 'Bundle Must Not be Fragmented' flag at the
source if the application of custody transfer or compressed status reporting
according to this specification is intended.       

3)     The compressed reporting signal (see 5.2.3) has been changed to
include the reporting reason code as integer (and not as an integer
interpreted as bit field). Please note that the Status Report Request Flags
(5.1.4.1) shall actually be processed as a bit field. However, we align the
Bit Number with the reason code integer for consistency. 

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 <mailto:dpo at esa.int> ). 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250516/70046f50/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6541 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250516/70046f50/attachment-0001.bin>