[Css-csts] RCF for USLP - a few more important comments - Revision 1
John Pietras
john.pietras at gst.com
Wed Jul 15 20:02:06 UTC 2020
Dear Wolfgang,
Here are some comments on those items for which there will still be some discussion tomorrow. All of the following are of course suggestions intended to spark and advance further discussion:
1. Section 1.1, NOTE – Regarding whether or not there will be an update to the CSRM, it’s my understanding that there will be some minimal update, I assume that even a minimal update will combine the two RCF service. For now the NOTE addresses the current CSRM, but if the CSRM *is* updated in the near future and before the RDF update goes into effect, we will need to modify the NOTE accordingly.
2. Regarding 1.6.1.5 (c) and (d), If these terms are in the NOTE under 3.6.2.5.2 then I think it’s helpful to keep them in 1.6.1.5. However, ignoring the VC frame count cycle raises a question for me – since the authors of the AOS book must have thought it important to be able to extend VC frame count, why does the RCF service ignore this? The RCF service could instead use an “effective VCFC” (EVCFC) that consists of the 28-bit virtual counter formed by the VC Frame Count Cycle + the VCFC. Norte that the flag bit can be ignored because if the Cycle field is not used it is set to all zeroes. (See also 3.6.2.5.2)
3. Section 2.4.1:
a) first paragraph. Figure 2-1 is already not strictly inherited from the CSRM in that it combines the MC and R-VC flavors of the RCF, ROCF, and RFSH services. We could get around this by stating that the figure is derived from the CSRM. If we do that, we can also delete the ROCF and RFSH lines with a statement to the effect that this derived diagram shows only those aspects of the CSRM diagram that are pertinent to the RCF service (if this is done, the ROCF informative reference in annex F can be deleted). Also, delete the Return All Frames Service line and T-U box, which represents RAF-SLE-PDUs arriving from a different SLE Complex, which is in fact not supported.
b) Second paragraph – delete the phrase (b) regarding the RSLP-FG being in a different SLE Complex.
c) NOTE 1: The wording of this NOTE and the presence of the TM S&CC book but absence of the SCCC and DVB-S2 books in the Referenced Documents, implies that only R-S, LDPC, and FECF are used to encode the frames. Turbo, SCCC, and DVB-S2 are ignored. References to SCCC and DVB-S2 should be added to 1.7, and Turbo, SCCC, and DVB-S2 are addressed also. However, these are really normative statements, and it seems almost too nonconsequential to cover them in an NOTE is an informative section. One possible fix would be to add a short normative annex stating the requirements on the RF Production, where these rules for flagging frames as “good” can be levied. This section could also call out the paragraphs of the CSRM that apply.
This NOTE also refers to “RAF service production” without ever defining what that is. Section 2.6.3, Underlying Services, also refers to “SLE RAF service production” and references the CSRM. However, the CSRM offers definitions that are more directly appropriate to RCF “the production of the Return MCF service” in 5.6.1.3 of the CSRM and “the production of the Return VCF service” in 5.6.1.4 of the CSRM. In both of these sections, RCF service production is defined the functions of both the Return Space Link Processing SLE-FG and the Return Frame Processing SLE-FG, which is consistent with our definition of service production as consisting of everything from the aperture up to the provision of the service itself. I recommend changing “RAF service production” to “RCF service production” in 2.4.1 NOTE 1 and 2.6.3, and referring to 5.6.1.3 and 5.6.1.4 of the CSRM as appropriate.
4. Figure 2-2: I suggest changing the label “From RAF Channel” to “From Space Link” and changing the label “RAF-SLE-SDU” to “SL-DU”. This is consistent with the definition of service production as consisting of everything from the aperture up to the provision of the service itself.
5. Section 2.6.3, Underlying Services – As noted above, this section refers to “SLE RAF service production” and references the CSRM. However, the CSRM more directly defines “the production of the Return MCF service” in 5.6.1.3 of the CSRM and “the production of the Return VCF service” in 5.6.1.4 of the CSRM. I recommend changing the references in 2.6.3 from “RAF service production” to the RCF sections of CSRM. That also avoids the implied dependency of RCF on RAF. Also, I suggest deleting the “or by a different SLE Complex”. If desired, a Note could be added to explain that although the CSRM theoretically supports staging of the RCF service over two Complexes, the actual service as defined in this Recommended Standard has all RCF service production and provision performed in the same SLE Complex. We can discuss the details.
6. 2.6.4.4 – I think that a local abort should also be mentioned. Let’s discuss.
7. 3.6.2.7, NOTE 2 – I didn’t think of this the first time, but it might be better to change the sentence to “The contents of TM, AOS, and USLP Transfer Frames … may be protected …”. That more accurately reflects the fact that the transfer frames themselves (i.e., including the TF Primary Header and TF Trailer) are protected.
8. 3.9.2.4 – In response to your question regarding whether RCF will be used for variable-length frames, I suggested that for variable-length frames it might be possible to interpret the CLTU Reception state (section 5.3 of the TC Sync and Channel Coding blue book) being in the DECODE state as the indicator of the “frame sync” being “in-lock”. However, I guess the bigger question is whether we will have variable-length frames on the return link in the first place. As of now, we don’t have a “VLF Sync and Channel Decode” FR (essentially, the Receiving End of the TC Sync and Channel Coding Sublayer) in the FR Reference Model, and the TC Sync and Channel Coding blue book is, as of now, specified only for space-to-ground and space-to-space.
Looking forwards to talking with out tomorrow.
Best regards,
John
From: Wolfgang Hell [mailto:wo_._he at t-online.de]
Sent: Tuesday, July 14, 2020 9:25 AM
To: John Pietras <john.pietras at gst.com>; Holger.Dreihahn at esa.int; css-csts at mailman.ccsds.org
Subject: Re: [Css-csts] RCF for USLP - a few more important comments - Revision 1
Dear John,
Many thanks for taking a thorough look at the RCF specification extended and modified for the support of USLP. The attached version of the RCF book contains my responses to your comments and, where applicable, further updates of the book as triggered by your comments. As you will see, I have accepted most of your updates. Where I'm reluctant is dropping the FSH service (item f in your email). As long as we do not have an update of the SLE RM, we should stick to what that book states, even though I agree that it is very unlikely that such service will ever be specified. But other CCSDS publications (in this case the Security Protocol) also address this service and also I would not like to modify the ASN.1 module "CCSDS-SLE-TRANSFER-SERVICE-SERVICE-INSTANCE-ID" (A2.4) which is common to all SLE service specifications.
For the other discussion items I concur with your view including your suggestion to get feedback from Tom Gannet regarding the potential need for a Security, SANA, and Patent annex and a PICS Proforma annex. I very much hope that we do not need any of those.
I certainly agree with your observation that for the most part the RCF book stays silent about service production - and that is because a) we had agreed that the SLE books specify the services, but not the underlying service production and b) as you also observe, the production to be performed for RCF is to discard any incoming frames that are not annotated a 'good' and/or outside the selected ERT window and therefore very simple. I have not heard complaints that the SLE books are not precise enough, but this may be attributable to the fact that at the time I was involved in the implementation to some extent the specification evolved in parallel with the implementation and therefore everybody involved had a lot of background knowledge. If you think it would be helpful we could add an informative annex outlining the annotation of the frames to be digested by the RCF service.
Looking forward to our talk on Thursday.
Best regards,
Wolfgang
Am 13.07.2020 um 23:15 schrieb John Pietras:
No sooner did I hit “send” that I realized that there is one more disconnect between the figures in section 2.4 and the way we’ve actually implemented the RCF (and ROCF) services(). If we agree that RAF Service Production constitutes the reception, frame sync and channel decoding, and annotation of the frames (and for offline instances is represented by the Offline Buffer), then we really don’t have RCF Service Production that is common to multiple instances of the RCF transfer service, unless we define it as the almost-trivial function of discarding errored frames so that only valid frames are presented to each instance of RCF Service Provision. Note that the Functional Resource Reference Model treats this slightly differently, by having each RCF TS Provider receive all annotated frames and each instance discarding the errored frames (we did that so that RAF and RCF instances could share the same Frame Buffer). If we want to keep the RCF Service Production in the RCF “model” in section 2.4 it’s okay, since 2.4 is conceptual and not normative.
Also, I want to walk back my suggestions for changing “RAF Channel” to “annotated valid transfer frames” and deleting “RAF-SLE-SDU” in my comments below. Upon re-reading the SLE-RM, it looks like the RAF Channel *is* the stream of “annotated transfer frames”, so RAF Channel and RAF-SLE-SDU are okay (I think) for figure 2-1 and 2-3 after all (I was mistakenly thinking of “RAF-SLE-PDUs). If we assume that RCF Service Production (or RCF Service Provision) does the discarding of the errored frames (i.e., the RAF-SLE-SDUs with the frame quality set to “good”) then it’s consistent.
Sorry for any whiplash that my comments may cause. ☺
Best regards,
John
From: John Pietras
Sent: Monday, July 13, 2020 4:36 PM
To: Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>; 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: RE: [Css-csts] RCF for USLP - a few more important comments
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<mailto:Holger.Dreihahn at esa.int>; 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: 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/20200715/3752da6b/attachment-0001.htm>
More information about the CSS-CSTS
mailing list