[Css-csts] Use of Functional Resource Names in CSTS SFW operations and procedures

[John Pietras]

CSTSWG colleagues ---
At last week's telecon, we discussed various issues regarding the use of Labels in CSTS operations and procedures and arrived at the following decisions:

1.       In response to a subscription or query, Parameter or Event Names will always be reported/returned. There is no option to report/return a Label.

2.       Labels can be used in subscriptions or queries, but we decided that the standard behavior would be that for any label there could be at most only one instance of the parameter associated with the CSTS service instance. This would apply to labels that are individually specified in the list-of-parameters (for the Cyclic Report procedure or procedures using the GET operation) or list-of-events (for the Notification procedure) , labels represented by a list name. or labels represented by a default list. For the great majority of CSTSes that are  expected to use GET, Cyclic Report, or Notification the service will have access to only those parameters and events that are directly associated with their own production or provision. By declaring this to be the standard behavior, the service specifications for such "normal" CSTSes will be able to use these procedures without further derivation or refinement.

3.       Of course, the Monitored Data (MD) service will *not* be constrained to access parameters and notifications associated with its own production and provision. In the case of the MD-CSTS, the behavior of the Cyclic Report, Information Query, and Notification procedures will have to be extended to allow a single label to represent *all* instances of that parameter/event in the whole Service Package of which the MD-CSTS instance is a part. This was deemed to be the best approach because it concentrates all the need to derive procedures in only one service (the MD-CSTS specification).

I took the action to add the necessary rewordings to the CSTS SFW, and Yves sent me a copy of the most-current version to work on.

In working on the draft, I came across a new issue. The GET invocation, Cyclic Report START invocation, and Notification START invocation allow the list-of-parameters and list-of-events (respectively) to contain a single Functional Resource Name. I'm pretty certain that the motivation for this option was driven by the MD-CSTS case: it is certainly a convenient notion to ask for all parameters/events for an instance of a Functional Resource type. However, its usefulness is not quite so obvious for what we are now calling the normal or standard case, where the scope of the parameters/events to be reported is limited to those that are directly associated with the production of provision of the service instance itself.

If we continue to keep the Functional Resource Name as an option for the standard procedures, I think that at a minimum notes should be added to point out that such selections are valid only for Functional Resource instances that are directly associated with the service performing the procedure: any non-associated FR Name will result in a negative result with diagnostic 'unknown Functional Resource Name'.

And if we *do* continue to keep the Functional Resource Name as an option for the standard procedures, it seems reasonable to ask whether it makes sense to allow the Functional Resource Type to be requested. Actually, to me it seems more likely that the user of a "normal" service might know the FR Type than the actual FR Name: the type will be statically associated with the service type (e.g., a return SLE-like CSTS will always have a return carrier FR Type associated with it) but the name is nominally dynamically assigned by Service Management. Note that if we were to allow the FR Type to be added to the options there would still be the possibility that service user could ask for an FR type that is not associated with the service type and therefore would cause a negative result.

Another approach would be to remove the FR Name option from the Framework procedures and let it be added as an extension by the MD-CSTS, which is the service where such a wild-card capability is really useful. I think that I'm leaning toward this option.

I apologize for always coming up with these last-minute stumbling blocks.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130722/0291754b/attachment.htm