[Css-csts] More RCF errata and a question

[John Pietras]

Wolfgang and Fabienne,

I'm not sure what stage you are in on handing off responsibility of the
SLE books, so I'll address this to both of you.

 

Several issues have arisen regarding NASA SGSS's implementation of RCF.
I was able to trace two of the issues to inaccurately worded informative
material (section 2 and NOTES). Even though these are only informative,
they are being used to interpret the document and therefore should be
corrects.

 

1.       NOTE 3 under section 3.4.2.7.1 states: 

"Depending on the configuration, for a given service instance, the
selection of only one master channel or only one VC from a set of VCs
(where the set may have a single member) or a single master channel plus
a set of VCs is permitted. In case the permitted GVCID list contains a
master channel but no virtual channels from that master channel, the
service user is not permitted to request a virtual channel from this
master channel."

 

This note is being interpreted as saying something to effect that it is
possible to request multiple VCs in the START invocation because it can
be improperly parsed. I believe that the intent was for it to be read
as:

"Depending on the configuration, for a given service instance, selection
is permitted of only one master channel or only one VC from (a) a set of
VCs (where the set may have a single member) or (b) a single master
channel plus a set of VCs. In case the permitted GVCID list contains a
master channel but no virtual channels from that master channel, the
service user is not permitted to request a virtual channel from this
master channel."


In other words, the combinations of VCs and MCs still refer to the
Permitted GVCID Set and not to the GVCID that can be requested in a
START invocation. However, even with that interpretation I believe that
the NOTE is technically incorrect, because it states that that there can
only be one MC listed in the Permitted GVCID Set. There is nothing in
the normative text nor the ASN.1 that enforces this constraint, and the
AOS and TM Space Data Link Protocols both allow multiple MCs to be
multiplexed into a single physical channel. So I think that the
paragraph still needs some tuning. 

Note that another statement about only a single MC being permitted is
made in the fourth paragraph of section 2.1.

 

2.       NOTE 2 under 3.4.2.7.1 states

"The physical channel is not specified directly through the RCF service.
Rather, the selection of physical channel is determined through the
service package, which specifies the RAF service instance that is
consumed by the RFP-FG that is producing the RCF service."

 

This is incorrect because it is not necessary to have an RAF transfer
service instance in the chain that produces the RCF service.  It should
read "... which specifies the RAF channel ...". 

 

 

3.       Finally, there is some surprise and disappointment being
expressed that RCF is limited to just one VC or MC at a time. I seem to
recall some discussion about allowing RCF to deliver multiple VCs and/or
MCs concurrently, but obviously that never came to pass. What were/are
the reasons for keeping limited to on CV/MC at a time? Does it have
something to do with some notion that an eventual CSTS-based service
would have such a capability? If so, would our current view that SLE
services are not going to be so easily replaced by CSTS ones make
changing the RCF service something worth reconsidering? (I'm looking for
comments from anyone on this question).

 

Thanks for your attention and comments.

 

Best regards,

John 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20121112/74aff056/attachment.html