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

[John Pietras]

Martin,
Thanks for your response. My apologies for not making my question to you more obvious.

I will take this as confirmation that it was incorrect to put this as a managed parameter in Service Management, and the error was compounded by copying it into Table 3-1 of the RAF service specification.

CSSMWG colleagues --- I'm going add removal of the permittedFrameQualities parameter from the RafTransferServiceProfile data set to the list of corrections to be made as part of the Technical Corrigendum to B-1 that we are planning to create.

Best regards,
John

From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
Sent: Wednesday, January 30, 2013 6:07 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org); CCSDS SMWG ML (smwg at mailman.ccsds.org)
Subject: RE: SLE RAF permitted-frame-quality-set managed parameter

Dear John,

I just noticed that your e-mail includes a question to me - sorry for the delay in answering.

I checked once more and I can confirm that the RAF API specification has no knowledge of a permitted-frame-quality-set . In the recent update I have made to align the API with RAF B-3, I have only checked for implications on the interface to the user. As the permitted-frame-quality-set is not gettable and the START diagnostics had not changed this change did not make it into the proposed API Update.

Regards, Martin

From: css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org> [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 16 January 2013 00:19
To: CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>); CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>)
Subject: [Css-csts] SLE RAF permitted-frame-quality-set managed parameter

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/20130130/94eedf85/attachment.htm