[SIS-CFDPV1] CFDP WG Meeting Huntsville 3/4 - CFDP Simplification (Core CFDP) / Removal of Store-And-Forward Overlay

[Felix Flentge]

Dear All,

I have uploaded an updated draft for CFDP-B6 to CWE at

https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b6_WhiteBook/727x0b6_WhiteBook_Issue1.doc?d=w73ace55f918342129a1389e5e40c7a99

The change log shoule be pretty up to date. In particular, I have tried to make a lot of the CFDP features optional as discussed in Huntsville (please see below). I hope I have found a good way to document this in the draft (in particular, please have a look at the additions to Section 7). The PICS is not (fully) updated, yet.

I intend to go through  the whole document at the CFDP WG meeting in Den Haag. Please have a look before. In particular, if you cannot participate in the meeting, please sent your comments before to the mailinglist.

Regards,
Felix

From: Felix Flentge
Sent: Monday, May 15, 2023 2:32 PM
To: sis-cfdpv1 at mailman.ccsds.org
Cc: Austin Stanton <dstanton at keltik.co.uk>
Subject: CFDP WG Meeting Huntsville 3/4 - CFDP Simplification (Core CFDP) / Removal of Store-And-Forward Overlay

Dear All,

We have discussed ways to make CFDP easier to implement, in particular, to allow for a kind of simple 'core CFDP' implementation, e.g. for use over Bundle Protocol (we would basically just use CFDP Class 1 and use CFDP for formatting PDU). The following proposals are on the table


1)      Removal of the Store-And-Forward Overlay (Annex B) - to our knowledge this has never been used in cross-support scenarios and we would argue that multi-hop file delivery shall make use of BP as network layer protocol - Please let us know if there are any objections.

  *   IMPLEMENTED

2)      It has been proposed to make the following features optional

a)      Link State Change Procedures for Class 1 (maybe mandatory for Class 2)
--> I am against this change: even for Class 1 over bundle protocol it may be required; e.g. consider the case that the bundle storage is full; in this case there is no transmission opportunity; on the receiver side, reception opportunity should at least be stopped when there is no contact


b)      Suspend / Resume for Class 1 (maybe mandatory for Class 2)


  *   IMPLEMENTED

c)      Prompt NAK

  1.  IMPLEMENTED


e)      Keep Alive Procedures

  1.  IMPLEMENTED



g)      User Operations (Proxy Operations, Directory Operations, Remote Status Report, Remote Suspend Operations, Remote Resume Operations)

  1.  IMPLEMENTED


i)       Fault Handler Override

  1.  IMPLEMENTED


k)      Messages to User

  1.  IMPLEMENTED


m)    Flow Labels

  1.  IMPLEMENTED


We also discussed whether a CFDP entity should silently ignore not supported features or signal to the requesting entity via a condition code in EOF/Finished PDU (which would also mean cancelling the transaction).
Please let us know whether you would like to keep some of those mandatory and how an entity should respond to not supported features (which may depend on the not supported feature, e.g. for User Operations it could make sense to cancel, while it may be a bit harsh for a Prompt NAK).

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