[Css-csts] SLE RAF permitted-frame-quality-set managed parameter

[John Pietras]

CSTSWG and CSSMWG colleagues ---
The NASA Space Network Ground System Sustainment (SGSS) Project has uncovered an ambiguity (and possible error) in the SLE RAF specification, CCSDS 911.1-B-3. This ambiguity/error is likely the result of something in the Space Communication Cross Support Service Management (SCCS-SM) specification (910.11-B-1) so I'm also including the CSSMWG on this message.

The ambiguity is as follows: Table 3-1 of the RAF specification lists the parameter permitted-frame-quality-set as a parameter that is set by Service Management. This parameter did not appear in the Blue-1 and Blue-2 versions of the RAF specification, but was added to B-3 to be consistent with the SCCS-SM specification, which has a permittedFrameQualities parameter as part of the configuration profile information for RAF transfer service instances. The concept of the permitted-frame-quality-set (permittedFrameQualities) parameter is that it would be set via Service Management to constrain which frame qualities (good-frames-only, erred-frames-only, or all-frames) could be requested in the requested-frame-quality parameter of RAF-START invocations for that service instance. However, as pointed out by the SGSS team member, there is no diagnostic for a failed RAF-START to indicate that the requested-frame-quality parameter contains a value that is not consistent with permitted-frame-quality-set.

I believe that the RAF service was not originally intended to allow Service Management to limit the values of frame quality that could be requested via the RAF-START operation. However, in Service Management we created such a managed parameter. Before the 2010 update of the SLE books, the Tables 3-1 of those books contained most but not all managed parameters that had been documented in SCCS-SM. When Wolfgang updated the SLE books in 2010, he wanted to make the managed parameters in the Tables 3-1 consistent with the SCCS-SM specification, and I supplied him with a list of the parameters that were missing, including the one related to limiting the options for the value of the permitted-frame-quality parameter. For whatever reason, the fact that this constraint was never enforced by the RAF service in terms of a defined negative result and diagnostic value somehow slipped by all of us.

So there are two possible approaches, from which we have to pick one:

1.       The first possible approach is that the RAF service DOES NOT allow Service Management to pre-constrain the frame qualities that a user can request via the requested-frame-quality parameter. That is, all RAF instances will always allow the user to request all frames, good frames only, or erred frames only. If this is the approach selected, then the permitted-frame-quality-set parameter needs to be removed from table 3-1 of the RAF specification and the permittedFrameQualities parameters need to be removed from the SCCS-SM specification.

2.       The second possible approach is that is that the RAF service DOES allow Service Management to pre-constrain the frame qualities that a user can request via the requested-frame-quality parameter. If this approach is selected, then the permitted-frame-quality-set parameter stays in table 3-1 of the RAF specification and the permittedFrameQualities parameters stay in the SCCS-SM specification, but a diagnostic needs to be added to the negative result for the RAF-START operation to indicate that the requested frame quality is not supported by the configuration of the service instance.

My guess is that the correct approach is (1) - that is, that the DTSWG/CSTSWG did not intend for an RAF service instance to be constrained by management as to which qualities could be requested. But I don't know for certain and so I am asking the opinion and knowledge of other members of the WGs to please contribute to the conversation. Does anyone know of an RAF implementation that supports the such a constraint? Martin Goetzelmann - does the RAF API say anything one way or the other on this topic?

Thank you all for any comments that you can provide.

Finally, If the decision is to take approach (2) - that is, to keep permitted-frame-quality-set/permittedFrameQualities as a manage parameter - then the allowed values for permittedFrameQualities in tables 5-81 and 5-94 of SCCS-SM must be modified in a future Technical Corrigendum to remove the value 'undefined'. This value was added to the possible values to support the delivered-frame-quality  'undetermined' value, but this value is unnecessary since the 'all frames' value is used to also specify that frames can have the  'undetermined' quality value (see the NOTE in section 3.6.2.6.1 of the RAF spec), and in fact it has been removed from the permittedFrameQualities parameter in E-06.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130115/5eee9037/attachment.htm