[Css-csts] SLE RAF permitted-frame-quality-set managed parameter
Fabienne.Delhaise at esa.int
Fabienne.Delhaise at esa.int
Thu Jan 24 05:23:20 EST 2013
Dear John,
My preference in this matter is that all RAF instances will always allow the
user to request all frames, good frames only, or erred frames only (i.e. the
Service Management shall not be allowed to pre-constrain the frame qualities)
>Does anyone know of an RAF implementation that supports the such a
constraint?
I do not know any
Kind regards,
Fabienne
From: John Pietras <john.pietras at gst.com>
To: "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>, "CCSDS SMWG ML
(smwg at mailman.ccsds.org)" <smwg at mailman.ccsds.org>
Date: 16/01/2013 00:20
Subject: [Css-csts] SLE RAF permitted-frame-quality-set managed parameter
Sent by: css-csts-bounces at mailman.ccsds.org
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
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
More information about the Css-csts
mailing list