<font size=2 face="sans-serif">Hi Wolfgang,</font>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">I guess this is at the end a tradeoff
or being precise (or the risk of being not) and implementation.</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the very accurate update!</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br><font size=2 face="sans-serif">Holger</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=2 face="sans-serif">http://www.esa.int/esoc</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Wolfgang Hell"
<wo_._he@t-online.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"John Pietras"
<john.pietras@gst.com>, "Holger.Dreihahn@esa.int" <Holger.Dreihahn@esa.int>,
"css-csts@mailman.ccsds.org" <css-csts@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">14/07/2020 15:25</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [Css-csts]
RCF for USLP - a few more important comments - Revision 1</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>Dear John,</font>
<br>
<br><font size=3>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.</font>
<br>
<br><font size=3>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.</font>
<br>
<br><font size=3>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.</font>
<br>
<br><font size=3>Looking forward to our talk on Thursday.</font>
<br>
<br><font size=3>Best regards,</font>
<br><font size=3>Wolfgang</font>
<br>
<br>
<br><font size=3>Am 13.07.2020 um 23:15 schrieb John Pietras:</font>
<br><font size=3 color=#004080 face="sans-serif">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.</font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif">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 *<b>is</b>* 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-<u>PDU</u>s).
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.</font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif">Sorry for any whiplash
that my comments may cause. </font><font size=3 color=#004080 face="Wingdings">J</font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif">Best regards,</font>
<br><font size=3 color=#004080 face="sans-serif">John</font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 face="sans-serif"><b>From:</b> John Pietras <b><br>
Sent:</b> Monday, July 13, 2020 4:36 PM<b><br>
To:</b> </font><a href=mailto:Holger.Dreihahn@esa.int><font size=3 color=blue face="sans-serif"><u>Holger.Dreihahn@esa.int</u></font></a><font size=3 face="sans-serif">;
</font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=blue face="sans-serif"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="sans-serif">;
</font><a href="mailto:wo_._he@t-online.de"><font size=3 color=blue face="sans-serif"><u>wo_._he@t-online.de</u></font></a><font size=3 face="sans-serif"><b><br>
Subject:</b> RE: [Css-csts] RCF for USLP - a few more important comments</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=3 color=#004080 face="sans-serif">Holger, Wolfgang, and
all,</font>
<br><font size=3 color=#004080 face="sans-serif">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 *<b>are</b>* defined
in the RAF specification (which correctly recognizes Turbo, SCCC, and DVB-S2
in addition to R-S, LDPC, and FECF coding), <u>but the RAF book is
not even referenced by the RCF book</u>. [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.] </font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif">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).</font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif">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. </font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif">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:</font>
<br><font size=3 color=#004080 face="sans-serif">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);</font>
<br><font size=3 color=#004080 face="sans-serif">b)
Rework 2.4 to:</font>
<br><font size=3 color=#004080 face="sans-serif">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”;</font>
<br><font size=3 color=#004080 face="sans-serif">2)
Add “annotated valid transfer frames” to `1.6.1.8; </font>
<br><font size=3 color=#004080 face="sans-serif">3)
Change the references to “RAF Channel” to “annotated valid transfer
frames”;</font>
<br><font size=3 color=#004080 face="sans-serif">4)
In Fig. 2-2, change “From RAF Channel” to “From Space Link” and change
“RAF-SLE-SDU” to “SL-DU”;</font>
<br><font size=3 color=#004080 face="sans-serif">5)
In fig 2-3, change “RAF channel” to “annotated valid transfer frames”;</font>
<br><font size=3 color=#004080 face="sans-serif">6)
Remove the wording about the RAF channel (annotated valid transfer frames)
coming from a different SLE Complex. In the diagrams, remove the TU;</font>
<br><font size=3 color=#004080 face="sans-serif">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.</font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif">Best regards,</font>
<br><font size=3 color=#004080 face="sans-serif">John</font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 face="sans-serif"><b>From:</b> John Pietras <b><br>
Sent:</b> Monday, July 13, 2020 11:44 AM<b><br>
To:</b> </font><a href=mailto:Holger.Dreihahn@esa.int><font size=3 color=blue face="sans-serif"><u>Holger.Dreihahn@esa.int</u></font></a><font size=3 face="sans-serif">;
</font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=blue face="sans-serif"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="sans-serif">;
</font><a href="mailto:wo_._he@t-online.de"><font size=3 color=blue face="sans-serif"><u>wo_._he@t-online.de</u></font></a><font size=3 face="sans-serif"><b><br>
Subject:</b> RE: [Css-csts] RCF for USLP</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=3 color=#004080 face="sans-serif">Holger, Wolfgang, and
all,</font>
<br><font size=3 color=#004080 face="sans-serif">I’ve made a pass through
the edited RCF book. My responses to the particular questions that Wolfgang
raised are interleaved in </font><font size=3 color=red face="sans-serif">red</font><font size=3 color=#004080 face="sans-serif">
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: </font>
<br><font size=3 color=#004080 face="sans-serif">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.</font>
<br><font size=3 color=#004080 face="sans-serif">b.
1.6.1.5 c) should be “V<u>irtual</u> C<u>hannel</u> Frame Count Cycle”
to match the term from the AOS book and the term used in this (RCF) book.</font>
<br><font size=3 color=#104160 face="sans-serif">c.
1.6.1.5 d) should be “V<u>irtual</u> C<u>hannel</u> Frame Count <u>Cycle</u>
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”.</font>
<br><font size=3 color=#004080 face="sans-serif">d.
</font><font size=3 color=#104160 face="sans-serif">The “additional definitions”
term Frame Version Number (1.6.1.8.6) refers to the </font><font size=3 color=#004080 face="sans-serif">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.</font>
<br><font size=3 color=#004080 face="sans-serif">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 … </font><font size=3 color=red face="sans-serif">,
</font><font size=3 color=#004080 face="sans-serif">AOS … </font><font size=3 color=red face="sans-serif">,</font><font size=3 color=#004080 face="sans-serif">or
USLP …”. (I have made those changes where I found them in my attached
marked-up copy.)</font>
<br><font size=3 color=#004080 face="sans-serif">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. </font>
<br><font size=3 face="Times New Roman">g. </font><font size=3 color=#004080 face="sans-serif">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.</font><font size=3 face="Times New Roman">.
</font>
<br><font size=3 color=#104160 face="sans-serif">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.” </font>
<br><font size=3 color=#104160 face="sans-serif">1)
Should “RCF-STOP” be “RCF-UNBIND, since it is the UNBIND that releases
the association?</font>
<br><font size=3 color=#104160 face="sans-serif">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.</font>
<br><font size=3 color=#104160 face="sans-serif">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. </font>
<br><font size=3 color=#104160 face="sans-serif">j.
In 3.4.2.7.2 NOTE, I suggest prefacing “00’, ‘01’, and ‘1100’ with
“binary” for clarification.</font>
<br><font size=3 color=#104160 face="sans-serif">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.</font>
<br><font size=3 color=#004080 face="sans-serif">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 </font><font size=3 color=#104160 face="sans-serif">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”.]</font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif">I look forward to talking
with you on Thursday.</font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 color=#004080 face="sans-serif">Best regards,</font>
<br><font size=3 color=#004080 face="sans-serif">John</font>
<br><font size=3 color=#004080 face="sans-serif"> </font>
<br><font size=3 face="sans-serif"><b>From:</b> CSS-CSTS [</font><a href="mailto:css-csts-bounces@mailman.ccsds.org"><font size=3 color=blue face="sans-serif"><u>mailto:css-csts-bounces@mailman.ccsds.org</u></font></a><font size=3 face="sans-serif">]
<b>On Behalf Of </b></font><a href=mailto:Holger.Dreihahn@esa.int><font size=3 color=blue face="sans-serif"><u>Holger.Dreihahn@esa.int</u></font></a><font size=3 face="sans-serif"><b><br>
Sent:</b> Friday, June 19, 2020 3:24 AM<b><br>
To:</b> </font><a href="mailto:css-csts@mailman.ccsds.org"><font size=3 color=blue face="sans-serif"><u>css-csts@mailman.ccsds.org</u></font></a><font size=3 face="sans-serif">;
</font><a href="mailto:wo_._he@t-online.de"><font size=3 color=blue face="sans-serif"><u>wo_._he@t-online.de</u></font></a><font size=3 face="sans-serif"><b><br>
Subject:</b> [Css-csts] RCF for USLP</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=3 face="Arial">Dear CSTS Colleagues,</font><font size=3 face="Times New Roman">
</font><font size=3 face="Arial"><br>
Please find on our CWE the RCF Book Wolfgang updated for USLP support:</font><font size=3 face="Times New Roman">
</font><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="https://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/SLE%20Services/RCF%20for%20USLP.doc?Web=1"><font size=3 color=blue face="Arial"><u>https://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/SLE%20Services/RCF%20for%20USLP.doc?Web=1</u></font></a><font size=3 face="Times New Roman">
<br>
</font><font size=3 face="Arial"><br>
Please review the changes until our subject meeting on 16th of July. In
particular Wolfgang has raised these questions:</font><font size=3 face="Times New Roman">
</font>
<ul>
<li><font size=3 face="Times New Roman">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. </font><font size=3 color=red face="Times New Roman"><br>
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.</font>
<li><font size=3 face="Times New Roman">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?</font><font size=3 color=#004080 face="Times New Roman">
</font><font size=3 color=red face="Times New Roman"><br>
Would it be appropriate to equate ‘in-lock’ with the DECODE state and
‘out-of-lock’ with the INACTIVE and SEARCH states?</font></ul><font size=3 face="Arial"><br>
Looking forward talking to you in July.</font><font size=3 face="Times New Roman">
<br>
</font><font size=3 face="Arial"><br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=3 face="Arial"><br>
Holger</font><font size=3 face="Times New Roman"> <br>
</font><font size=3 face="Arial"><br>
Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=3 color=blue face="Arial"><u>http://www.esa.int/esoc</u></font></a>
<br><font size=3 face="Courier New">This message is intended only for the
recipient(s) named above. It may contain proprietary information and/or</font>
<br><font size=3 face="Courier New">protected content. Any unauthorised
disclosure, use, retention or dissemination is prohibited. If you have
received</font>
<br><font size=3 face="Courier New">this e-mail in error, please notify
the sender immediately. ESA applies appropriate organisational measures
to protect</font>
<br><font size=3 face="Courier New">personal data, in case of data privacy
queries, please contact the ESA Data Protection Officer (</font><a href=mailto:dpo@esa.int><font size=3 color=blue face="Courier New"><u>dpo@esa.int</u></font></a><font size=3 face="Courier New">).</font>
<p><font size=1 face="sans-serif">[attachment "RCF for USLP-JP-WH.DOC"
deleted by Holger Dreihahn/esoc/ESA] </font>
<p>
<p>
<PRE>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@esa.int).
</PRE>