[Css-csts] RCF for USLP

[John Pietras]

Holger, Wolfgang, and all,
I've made a pass through the edited RCF book. My responses to the particular questions that Wolfgang raised are interleaved in red in Holger's email below. In addition to those responses I have a number of other comments that were triggered as I read the proposed changes throughout the book. I have also made these comments and proposed changes in the attached marked-up version of Wolfgang's draft:

a.      The NOTE in 1.1 makes reference to a future version of the SLE Reference Model combing Rtn MC Frames and Rtn VC Frames. This should be included in the upcoming update.

b.      1.6.1.5 c) should be "Virtual Channel Frame Count Cycle" to match the term from the AOS book and the term used in this (RCF) book.

c.      1.6.1.5 d) should be "Virtual Channel Frame Count Cycle Use [not Usage] Flag" to match the term from the AOS book and the term used in this (RCF) book. . Note that the AOS book calls it "Usage" (in Fig 4-2) but otherwise calls it "Use", so we should use "Use".

d.      The "additional definitions" term Frame Version Number (1.6.1.8.6) refers to the same thing as Transfer Frame Version Number (1.6.1.18). In the text itself, "frame version number" (without the "transfer" prefix) appears only twice, both times in 3.4.2.7.1 NOTE 1. I suggest adding ""transfer" to the two instances in 3.4.2.7.1 NOTE 1 and deleting 1.6.1.8.6 and the reference to it in annex D.

e.      Editorial comment: there are many instances where phrases along the lines of "TM ... or AOS ..." have been changed to "TM ... or AOS ... or USLP ...". The middle "or"s should be replaced by commas: "TM ... , AOS ... ,or USLP ...". (I have made those changes where I found them in my attached marked-up copy.)

f.       In 2.4.1 and figure 2-1, I suggest that we start recognize that there already is an ROCF service and that there will never be an SLE-R-FSH service. See the changes in the attached marked-up copy.

g.     2.4.1 NOTE 1 has an added sentence that begins "The condition stated above" that is ambiguous - what condition is being referred to? It's confusing because R-S, LDPC, and FECF are discussed in the preceding sentences, but the new sentence mentions only R-S and FECF..

h.      The first two sentences of 2.6.4.4 now read "When an association is released or aborted, the invocation of further operations by the user or the provider is not permitted.  As a consequence, the delivery of frames stops as soon as the RCF-STOP or RCF-PEER-ABORT invocation has been processed by the RCF service provider."

1)     Should "RCF-STOP" be "RCF-UNBIND, since it is the UNBIND that releases the association?

2)     To me "RCF-PEER-ABORT invocation has been processed by the RCF service provider" implies a PEER-ABORT that has been invoked by the user, and therefore the case where the provider self-aborts is not covered by this sentence.

i.       Wolfgang's comment on 2.8 asks if we should move the security considerations to an annex. Interestingly, CCSDS 401.0 still contains none of this material, even though it is updated almost annually. Probably best to get a ruling from Tom G. If we do move it to an annex, we should also address SANA and patent considerations. Regarding patent considerations, none apply to SLE ROCF itself, but CCSDS 131.0 lists patent considerations for LDPC.

j.       In 3.4.2.7.2 NOTE, I suggest prefacing "00', '01', and '1100' with "binary" for clarification.

k.      Regarding the possible need for a PICS Proforma conforming to the current style, I hope that it is not necessary. As precedent, there have been multiple Blue Books that have been updated since the normative PICS Proforma mandate was declared that have not had such an annex added. For time and resource reasons we should argue that the RCF book be "grandfathered" in this respect.

I look forward to talking with you on Thursday.

Best regards,
John

From: CSS-CSTS [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Holger.Dreihahn at esa.int
Sent: Friday, June 19, 2020 3:24 AM
To: css-csts at mailman.ccsds.org; wo_._he at t-online.de
Subject: [Css-csts] RCF for USLP

Dear CSTS Colleagues,
Please find on our CWE the RCF Book Wolfgang updated for USLP support:
https://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/SLE%20Services/RCF%20for%20USLP.doc?Web=1

Please review the changes until our subject meeting on 16th of July. In particular Wolfgang has raised these questions:

  *   Shall the RCF service also in case of USLP be limited to the delivery of a Master Channel or a Virtual Channel? As the TC space link protocol USLP supports the notion of MAP channels. The attached version of RCF would not support the selection of a MAP channel. Shall delivery of a MAP channel be a separate service given that only for USLP frames such selection would be feasible. Also, there is no MAP frame counter and consequently reporting of gaps in the stream of MAP channel frames is not possible while we report such gaps for the frame stream of a VC channel.
I think that we should keep this at the VC frame level and let the user deal with the MAP channels (as they must do for Return Packet Channels). If someone wants and a Return MAP Channel service it should be proposed as a new CSTS.
  *   RCF reports the frame-sync-lock-status. For the case of variable length USLP frames this parameter does not make sense. Shall we simply specify that this parameter is set 'unknown' when variable length USLP frames are to be delivered?
Would it be appropriate to equate 'in-lock' with the DECODE state and 'out-of-lock' with the INACTIVE and SEARCH states?

Looking forward talking to you in July.

Best regards,
Holger

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | S-431
+49 6151 90 2233 | http://www.esa.int/esoc

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/css-csts/attachments/20200713/29008edb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RCF for USLP-JP.DOC
Type: application/msword
Size: 1068544 bytes
Desc: RCF for USLP-JP.DOC
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20200713/29008edb/attachment-0001.dot>