[Sis-dtn] Notes from yesterday's telecom

[Felix Flentge]

Hi,

I have uploaded the Custody presentation to CWE under 'Draft Documents/Compressed Bundle Reporting':
https://cwe.ccsds.org/sis/docs/SIS-DTN/Draft%20Documents/Compressed%20Bundle%20Reporting/Compressed%20Custody%20Signalling.pptx?d=w1144cf3aeff947a691490b30cabeda08

Regarding your point below of including additional information in the custody signal (upcoming contacts, etc): this is certainly an option which could be studied in more detail. However, I would keep this currently out of the Orange Book. The current target I to have something which is at least as good as the ACS we had for BPv6 (as missions love to use this). What we could do though is to improve the signal code themselves a bit. Currently, we see the following cases:

  *   Custody Accepted (node keeps a copy of a bundle and applies re-transmission in case no other nodes signals custody)
  *   Custody Already Accepted (node already has a copy of that bundle and accepted custody, eg if re-transmission has been too early --> this allows to adjust re-transmission timers)
  *   Custody Rejected but bundle will be forwarded (--> this allows to adjust re-transmission timers)
  *   Custody Rejected and bundle dropped

One way to encode this would be to use positive integers for accepted custody and negative integers for rejected cases. I would probably not include reason codes for the time being to keep it simple (and rely on Network Management to eg detect depleted storage). Alternative would be to have ranges for the cases above, eg 'Custody Rejected / Bundle Dropped) would be -12 to -23 with different reason codes.

Regards,
Felix

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Keith Scott via SIS-DTN
Sent: Friday, July 26, 2024 10:14 AM
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] Notes from yesterday's telecom


SIS-DTN Telecom 20240725

deepspace mailing list meeting yesterday
o   See https://deepspaceip.github.io/
o   Presentation on using Segment Routing version 6 (SRV6<https://deepspaceip.github.io/meetings/ietf120/ietf120-deepspaceip-srv6-store-forward.pdf> )as a replacement for / alternative to BP



Simon's putting together an issues list on GitHub

Everybody needs to send their GitHub ID to Simon



IETF DTN WG meeting (in 1.5 hrs?)
o   Will have a rechartering discussion
o   Will likely bring in work from deepspace mailing list





ESA: Custody Mechanisms



Stuff:
o   Bundle Sequence Number
o   Bundle Sequence ID (may be zero)
o   Xxx



Custody Transfer Extension Block
o   1
o   2
o   3



Custodians remove any previous CTEB and generate a new one with new sequence number and ID



Sequence of signals:

CBOR array [start, length, ident]



Could use more 'codes' to signal things like: "this node is NOT taking custody but is going to forward the bundle".  This signal would allow the current custodian to commute a NEW retransmission timeout (based on the custodian's notion of where the bundle would be forwarded given the contact plan -- could do a better job if provided with information about which outgoing contact the bundle would be scheduled to but that would probably blow the 'compressed' notion out of the water since you'd need one entry per bundle -- probably better to just say 'I'm forwarding this'?)













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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240726/a601f17b/attachment-0001.htm>