[SIS-CFDPV1] CCSDS 722.1-M-2: CFDP Unitdata Transfer Layers - Final Draft

Mon Sep 23 13:30:49 UTC 2024

Thanks Cheol,

Please see my replies to your comments below.

I have already integrated the changes into the version in CWE.

Regards,
Felix

From: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>
Sent: Monday, September 23, 2024 2:22 PM
To: chkoo at kari.re.kr; Felix Flentge <Felix.Flentge at esa.int>
Cc: sis-cfdpv1 at mailman.ccsds.org
Subject: RE: [SIS-CFDPV1] CCSDS 722.1-M-2: CFDP Unitdata Transfer Layers - Final Draft

Hi Felix, Cheol, all,

I’d suggest to address this point (and any other the rest of the CFPD folks may have) until end of next week, so that afterwards I can do my own review and if everything is ok I’ll issue the area resolution towards the CESG review necessary for starting the agency review.

Thank you all!

Tomaso

From: 구철회 <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>
Sent: Freitag, 20. September 2024 04:13
To: Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>; de Cola, Tomaso <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Cc: sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>
Subject: RE: [SIS-CFDPV1] CCSDS 722.1-M-2: CFDP Unitdata Transfer Layers - Final Draft

Hi, Felix.

Thanks for the hard work. I just have some minor comments to bring similarities of writing across all UT layers.

O SPP UT Layer – on page 3-2
3.3 SPACE PACKET PROTOCOL UT LAYER
(comment) is there any potential needs for aggregation in this UT layer? If so, we can add it.

FF: I didn’t see a need for aggregation for space packets (overhead is quite small). Allowing aggregation would also not be fully backward compatible with the current Magenta Book.

O BP UT Layer - on page 3-5
 3.4.4   A CFDP UNITDATA.request shall generate a Send.request where:
– The application data unit shall be an aggregation of CFDP PDU according to 3.1.4
(comment) to “ ~ shall be able to contain an aggregation of CFDP PDU ~” because original sentence can be interpreted as only aggregated CFDP PDUs are allowed in BP UT layer
(suggestion) change “shall contain” to “shall be able to contain” through whole contents to avoid mandating of the aggregation CFDP PDUs as only allowable option

FF: I would think that 3.1.4 is sufficient. I would propose to change the text of 3.1.4 slightly to:
An aggregation of CFDP PDU shall be a single CFDP PDU or a concatenation of several complete CFDP PDU with the same destination entity ID without any additional data.

O LTP UT Layer - on page 3-6 ~ 3.7
– Red-part bytes is the part of the client service data which has been sent reliably; for CFDP this will be the complete client data
(comment) to “~~ will be the single, complete CFDP PDU or aggregation of CFDP PDUs according to 3.1.4.” to reuse sentences that are repeatedly used in other sentences and the complete client data can be ambiguous because it could be interpreted as entire CFDP data or unit segment of CFDP PDU

FF: In 3.5.1 we are just discussing the requests and indications. That we send an aggregation of CFDP PDU is coming later. I would keep it like it is (or remove the half-sentence completely)

3.5.4   A CFDP UNITDATA.request shall generate a Transmission.request where:
– The client service data to send shall contain an aggregation of CFDP PDU according to 3.1.4.
– Length of red-part shall be set to the size of the aggregation of CFDP PDU.
 (comment) to
– The client service data to send shall be able to contain an aggregation of CFDP PDU according to 3.1.4.
– Length of red-part shall be set to the size of a complete CFDP PDU or the size of aggregation of CFDP PDUs.
   Because aggregation of CFDP PDUs in BP UT Layer and LTP UT Layer is NOT an mandate, but possibility I think.

FF: see above. Being able to handle aggregation of CFDP PDU is mandatory. An implementation may decide to always have only a single CFDP PDU in the aggregation but it should be prepared to receive aggregation with more than one.

 3.5.5   A RedPartReception.indication shall generate a CFDP UNITDATA.indication where:
– The CFDP protocol data unit UT_SDU shall contain the red-part bytes, i.e. a complete aggregation of CFDP PDU according to 3.1.4.
 (comment) to “The CFDP protocol data unit UT_SDU shall contain the red-part bytes, i.e. a complete CFDP PDU or completed CFDP PDUs if aggregation according to  3.1.4. is applied.”

FF: see above.

O UDP/IP UT Layer - on page 3-7
3.6.4 A CFDP UNITDATA.request shall send a single UDP datagram with a single, complete CFDP PDU included in the data part.
(comment) to “A CFDP UNITDATA.request shall initiate sending a single, complete CFDP PDU via UDP datagram.” The theoretical limit of UDP datagram is 65535 (however, technically less than that), i.e. 64k bytes. So if user wants to set the CFDP segmentation as bigger than 64k, this UDP UT layer implementation should support multiple UDP datagram for sending bigger CFDP PDU segmentation size. This sentence can be simplified as written in TCP/IP section.

FF: I disagree. Sending partial CFDP PDUs shall not be allowed, this is why we have one CFDP PDU = 1 UDP datagram.

 (comment) this part also can have “3.6.5 No non-CFDP data shall be sent over a UDP datagram used by CFDP.” instead of “3.6.5  Only CFDP PDU shall be sent to the UDP port of the listening CFDP application.”. It’s your call.

FF: I would keep the current formulation.

O TCP/IP UT Layer on page 3-8
3.7.4 A CFDP UNITDATA.request shall initiate sending a CFDP PDU via a TCP connection.
(comment) to “A CFDP UNITDATA.request shall initiate sending a single, complete CFDP PDU via a TCP connection.” to reuse sentences that are repeatedly used in other sentences

FF: I would maybe re-phrase like : A CFDP UNITDATA.request shall initiate sending the complete CFDP PDU via a TCP connection. (TCP is really different from the other protocols as it is connection-oriented and streaming).

Thanks.
Best,

Cheol

From: Felix Flentge via SIS-CFDPV1 <sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>>
Sent: Tuesday, September 17, 2024 12:24 AM
To: sis-cfdpv1 at mailman.ccsds.org<mailto:sis-cfdpv1 at mailman.ccsds.org>; Tomaso de Cola <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Subject: [SIS-CFDPV1] CCSDS 722.1-M-2: CFDP Unitdata Transfer Layers - Final Draft

Hi,

I have just concluded my final edits of the update CFDP UT Layer Book:

722x1m2_CFDP Unitdata Transfer Layers Magenta Book DRAFT-C.doc (ccsds.org)<https://protect2.fireeye.com/v1/url?k=01554586-5ece2f8e-01503408-ac1f6bdccbcc-28675b83a745346e&q=1&e=d0fdfab3-219b-4fdd-b906-62106b2a63f5&u=https%3A%2F%2Fcwe.ccsds.org%2Fsis%2F_layouts%2F15%2FWopiFrame.aspx%3Fsourcedoc%3D%257B4A0292CA-C9F5-4B5D-A39F-789C158465B5%257D%26file%3D722x1m2_CFDP%2520Unitdata%2520Transfer%2520Layers%2520Magenta%2520Book%2520DRAFT-C.doc%26action%3Ddefault%26CT%3D1726499472306%26OR%3DDocLibClassicUI>

I have done the changes as discussed during the last meeting. I hope that it is now very clear that only LTP red is expected to be used (see 3.5). For BP, I had to switch back to refer to the current (BPv6) CCSDS Blue Book (I have been too optimistic regarding the publication of the BPv7 version). However, there is a note that the same principles will apply for BPv7 (see 3.4, I think this is the best we currently can do).

I would like to submit it to the editor’s queue on 30 September (@Tomaso de Cola<mailto:Tomaso.deCola at dlr.de>: please let me know how the process exactly works). So, if you have any final comments, please let me know before.

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>).
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/20240923/c523778a/attachment-0001.htm>