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

[Holger.Dreihahn at esa.int]

Hi Wolfgang,
Some comments from me. One is another argument why we could ignore the MAP 
ID (like we ignore the AOS REPLAY FLAG) of the TM header.

May main comment is about implementation wrt. backward compatibility. So 
far the range constraints were simply driven by the largest range (which 
was AOS), but now we have choices for each type of supported TM. That is 
very precise, but requires replication of ASN.1 types in an implementation 
supporting several versions. This replication is according to my 
experience a bit delicate to implement. It is much easier to just widen 
the constraints.

I guess this is at the end a tradeoff or being precise (or the risk of 
being not) and implementation.

Thanks for the very accurate update!

Best regards,
Holger



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



From:   "Wolfgang Hell" <wo_._he at t-online.de>
To:     "John Pietras" <john.pietras at gst.com>, "Holger.Dreihahn at esa.int" 
<Holger.Dreihahn at esa.int>, "css-csts at mailman.ccsds.org" 
<css-csts at mailman.ccsds.org>
Date:   14/07/2020 15:25
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. J
 
Best regards,
John
 
From: John Pietras 
Sent: Monday, July 13, 2020 4:36 PM
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 - 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; 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
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).
[attachment "RCF for USLP-JP-WH.DOC" deleted by Holger Dreihahn/esoc/ESA] 



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/css-csts/attachments/20200716/8807d44a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RCF for USLP-JP-WH-HD.DOC
Type: application/msword
Size: 1094656 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20200716/8807d44a/attachment-0001.dot>