[Css-csts] RE: Updated MD-CSTS on CWE

[John Pietras]

CSTSWG colleagues ---
Tim Ray just called me to ask a question about the latest MD-CSTS update. Specifically, he was asking about the change to the Operational Scenario in which the second instance of the MD Notification procedure, in which I had put three Functional Resource Types (RAF, FCLTU, and MD-CSTS). Tim correctly pointed out that this violates the CSTS SFW Notification and MD Notification procedures, which allow only a single Functional Resource Type to be included in the START invocation, which means that a single Notification procedure instance (or Cyclic Report or Information Query procedure instance) can access the events (or parameters) of only a single Functional Resource Type.

Since this is only an error in the example, I can fix it and in the meantime progress can go on reviewing and prototyping the normative parts of the book.

But as Tim and I discussed this, we both questioned whether it would be so troublesome to allow multiple Functional Resource Types (or Functional Resource Names) in a single START/GET invocation. It would seem that if the service provider has to have the capability to accept the various forms of subscriptions anyway, having multiple FR Types or FR Names shouldn't be an implementation burden.

Indeed, given that the ASN.1 strongly types these different subscription types, it shouldn't be very difficult to even mix the various subscription types (list names, labels, individual parameter/even names, FR Types, and/or FR Names) in a single START/GET operation. However, with regard to mixing subscription types, the WG has already declared that such mixing would be too burdensome (although I don't know if that argument is made from an implementation or operational perspective (or both)).

After Tim and I concluded our conversation and I began to compose this message, it occurred to me that one possible reason for constraining the list-of-parameters to a single list name, FR Type or FR Name would be to attempt to limit the number of parameters returned in a single TRANSFER-DATA invocation or GET return (although this argument doesn't hold for the Notification procedure, because each NOTIFY invocation contains a single notification). If the size of a single TRANSFER-DATA invocation or GET return is a legitimate concern, then I believe that the maximum-number-of-gettable-parameters configuration parameter of the Information Query procedure and the max-number-of-parameters configuration parameter of the Cyclic Report procedure need further clarification. Specifically, when list names, labels, FR Type, and FR Name are used in the subscriptions, are the implementations expected to dynamically evaluate how many instances of parameters are represented by those "group" subscription parameters, and reject the START/GET if the result exceeds the constraint? Or are the maximums only intended to limit the number of items in the list-of-parameters of the START or GET invocation - i.e., do an individual parameter name and a parameter label both count the same toward the maximum, even though the label may result in the reporting of multiple qualified parameters?

Best regards,
John

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Monday, August 19, 2013 1:58 PM
To: CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: [Css-csts] Updated MD-CSTS on CWE

CSTSWG colleagues ---
I have updated the MD-CSTS to make it match recent changes in the CTS SFW. In particular, I have changed the MD-CSTS to conform to the approach in which the normative behavior of CSTS SFW procedures that deal with reported parameters and event  notifications is to return only single value per parameter/event type when a Parameter Label, Event Label, or Functional Resource Type. This normative behavior requires that the MD-CSTS modify the behavior to return values for all instances active in a Service Package.

This update addresses use of Functional Resource Type to subscribe to monitored parameters and notifiable events. To illustrate how Functional Resource Types are used, I modified the Operational Scenario (section 2.5) so that the four production-status notifications for each of the RAF, FCLTU, and MD-CSTS are subscribed to by using the Functional Resource Types of those services.

The updated MD-CSTS specification and a TXT file containing the ASN.1 Object Identifiers module can be found in the zip file on the CWE at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/MonitoredDataCSTS/MonitoredDataCSTS_W-0.16.zip

Best regards,
John


________________________________
NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible.
Spam<https://filter.gst.com/canit/b.php?i=01KeFWK5d&m=34182d09aaae&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01KeFWK5d&m=34182d09aaae&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01KeFWK5d&m=34182d09aaae&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130819/05849d3a/attachment.htm