[Css-csts] RCF for USLP - a few more important comments

[John Pietras]

Holger, Wolfgang, and all,
A few hours after I sent my email below, I had an "Aha!" moment where I realized that there is a major shortcoming in the RCF book that I had completely overlooked until now. In a nutshell, there is no way that one can understand from this specification that the frames that are delivered by the RCF service could have been transferred over a link that was encoded with Turbo, SCCC, or DVB-S2 encoding, all of which are explicitly recognized by the RAF Blue Book. This omission has been fundamental to the RCF book and is a consequence of using the SLE Reference Model concept of "RAF Channel" to hide the details associated with how the frames are encoded. The SLE-RM incorrectly models the RCF service as processing the output of RAF production, and therefore assumes that how the transfer frames are filtered, and what those frames look like, is defined "somewhere else". Indeed these details *are* defined in the RAF specification (which correctly recognizes Turbo, SCCC, and DVB-S2 in addition to R-S, LDPC, and  FECF coding), but the RAF book is not even referenced by the RCF book. [For years, I have been hearing (second-hand) of complaints that the SLE books are missing necessary details. I always thought those were references to someone not knowing about ISP-1, but this is another case of a reason that a "newbie" would run into a dead end.]

As it stands, section 2.4 of the RCF book presents an incomplete and inaccurate view of how RCF services are actually implemented. Not only does it state that the RCF processes an "RAF Channel" (which the SLE-RM defines as a stream of RAF-SDUs) that is created by an undefined process, it further reflects the unrealized notion of staging by saying that the RCF service can be performed in a different SLE Complex than the one that produces the RAF Channel (i.e., an SLE Complex that performs the RAF service).

I realize that this poses a dilemma - the RCF book is written in accordance with the SLE-RM, but the SLE-RM is no longer an accurate representation of reality (if it ever was). The net effect is that section 2.4 is misleading and doesn't provide the information necessary for a "clean implementation" of RCF. Furthermore, the SLE-RM book itself is up for reauthorization, so we have the opportunity to fix the problems in either one (RCF or SLE-RM) or in both places.

However, how much of this can be solved in the SLE-RM depends on how much effort we are willing to expend on making that book correct all around. My understanding is that the current notion is to simply trim out what is not actually going to be implemented and combine the Rtn VC Frames and Rtn MC Frames services into a single Rtn Frames service, and state that the rest is for historical record but any other services would be implemented using CSTS. If that is all that is going to be done to the SLE-RM, then I would suggest at a minimum the following fixes to the RCF book:

a)      Add the RAF, SCCC, and DVB-S2 books as references (alternatively, remove the reference to the TM S&CC book and figure out how to make the RCF book independent of the coding scheme);

b)     Rework 2.4 to:

1)     In Fig. 2-1, remove the Return All Frames service line and associated T-U connector, and change the "Return All Frames data channel" label on the line to "annotated valid transfer frames";

2)     Add "annotated valid transfer frames" to `1.6.1.8;

3)     Change the references to "RAF Channel" to "annotated valid transfer frames";

4)     In Fig. 2-2, change "From RAF Channel" to "From Space Link" and change "RAF-SLE-SDU" to "SL-DU";

5)     In fig 2-3, change "RAF channel" to "annotated valid transfer frames";

6)     Remove the wording about the RAF channel (annotated valid transfer frames) coming from a different SLE Complex. In the diagrams, remove the TU;

7)     Add a reference to the appropriate section(s) of the RAF book that describe the RAF Production, in particular (a) how the frames are validated, (b) what constitutes the content of a validated frame for each of the coding scheme, and (c) what constitutes the annotation that is appended to each valid transfer frame.

Best regards,
John



From: John Pietras
Sent: Monday, July 13, 2020 11:44 AM
To: Holger.Dreihahn at esa.int; css-csts at mailman.ccsds.org; wo_._he at t-online.de
Subject: RE: [Css-csts] RCF for USLP

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.

l.       The RAF Blue Book has been updated with references to SCCC and DVB-S2, but this book has not. It seems like it should be. [Note - There is a typo in the RAF book - 2.4.1 NOTE 1 states "SLE Return Space Link Processing and references [2], [3] and require that ...". There appears to be a reference missing between "[3] and" and "require".]


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<mailto:Holger.Dreihahn at esa.int>
Sent: Friday, June 19, 2020 3:24 AM
To: css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>; wo_._he at t-online.de<mailto: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/3525e087/attachment-0001.htm>