[Css-csts] Forward Frame service optional Throw Event procedure

[John Pietras]

Dear Wolfgang, Holger, Margherita, and Tim
At the wrap-up session for the FF discussion items, we concluded that because the Throw Event procedure will be optional, an "unblessed" user will simply be rejected (not aborted) for trying to invoke the Throw Event's EXECUTIVE-DIRECTIVE. I like this answer and think that it (or something similar) is the proper way to go.

Wolfgang suggested that the support for this approach is stated in section 3.9.4 of the Guidelines. However, on a more careful reading of the section on Optional Procedures in the Guidelines (3.9), I don't think that that section - as currently written - specifically covers the case that we are talking about.

Furthermore, Wolfgang mentioned during the webex session that he was unsure whether or not the Guidelines' mandate to treat an invocation for an unimplemented optional procedure as a failed invocation (instead of a peer-abortable Invalid PDU)  is supported by the Framework itself. So we have two issues: how to cover the issue raised with respect to the Forward Frame service, and whether the proposed solution(s) are sufficiently supported by the Framework. The first issue is - obviously- of immediate importance to the Forward Frame service itself (although it could have wider implications), but the second issue already wider implications for services that have optional procedures, including the already-published Monitored Data CSTS Blue Book.

Let's first look at the issue of the optional  the Throw Event procedure for the Forward Frame service. Section 3.9.1 defines optional procedure as a non-prime procedure for which" an implementation of the service is not required to support the procedure." For me, the key word here is "implementation". To my thinking, an implementation is the particular "make and model" of a FF CSTS provider system (e.g., ESTRACK, DSN, Cortex, Avtec, etc.). In other words, an optional procedure may or may not be built into the implementation in the first place (and is therefore an ICS Proforma concern). So my interpretation of 3.9.4 is that even if an implementation does not build-in the optional procedure as fully specified (in this case, the Throw Event procedure), the implementation must still include enough "stub" software to recognize an incoming invocation with the procedure-identifier for that optional procedure (in this case, an EXECUTE-DIRECTIVE invocation), and treat it as a failed invocation instead of an Invalid PDU -> PEER-ABORT.

All well and good, but I don't think that -as written in the Guidelines - it covers the case that I raised in the Discussion Items last week. In that case, it is not, in general, a case of whether the *implementation* supports the Throw Event procedure -it must in order for there to be an "master user" enabled to use it - but rather how an implementation that *does* support the Throw Event procedure can enable it for only one user and disable it for all others, and (specifically for the question raised in the Discussion Item) what the response should be when the user of an instance that is not so enabled attempts to invoke the Throw Event procedure. This is a case of *instance enablement* rather than implementation, and it's a separate issues, e.g., we could have a service that requires implementations to support at least one instance of a procedure but that allows that (those) instance(s) to be enabled/disabled by a service-level configuration parameter.

For the Forward Frames service, a service-level configuration parameter (throw-event-procedure-enabled, comparable to the FSP's throwing-of-events-enabled Service Management parameter) will be defined. Then, in keeping with the spirit and philosophy of Guidelines section 3.9.4, any attempt to invoke an EXECUTE-DIRECTIVE for the Throw Event procedure*will result in a negative result acknowledgement with diagnostic 'unsupported option'.


So now let's return to the broader issue of whether the Framework supports the whether or not the Guidelines' mandate to treat an invocation for an unimplemented optional procedure as a failed invocation (instead of a peer-abortable Invalid PDU).  I've done a bit of checking into this myself, and unfortunately have not found unambiguous support for it. It would certainly help if the definition of the 'invalid procedure instance identifier' PEER-ABORT diagnostic (3.6.2.2.1.2 (k)) were clarifies that "unknown" procedure does not mean an optional procedure for a service, and the definition of the 'unsupported option' diagnostic for the Standard Confirmed Operation Header (3.3.2.7 (c)) *does* include a procedure that is optional for the service but excluded from the particular implementation.

But there is still a fundamental problem with trying to support this through the Framework, and that is that the Framework is limited to Procedures and Operations, and is therefore very limited in what it can say about a procedure that is *absent* from a service. We could consider modifying the state tables to address what happens when the procedure is *not* implemented (very ugly, and somewhat paradoxical) or creating a generic state table for unimplemented optional procedures to be used in place of those procedures (also pretty ugly).

Therefore, I think that it ultimately falls on each service specification that has optional procedures to specify this behavior, and to the Guidelines to address how to define such behavior in service specifications. Section 3.9 of the Guidelines provides a start, in that it declares the intention. But there is no specification in the Guidelines for how this is to be documented in the service specifications themselves. So unless an implementer happens to read section 3.9 of the Guidelines in addition to the service specification and the Framework, they will not unambiguously know that the invocations should be rejected but not peer-aborted.

Unfortunately, the published MD-CSTS Blue Book and optional Information Query and Notification procedures, both of which are subject to this ambiguity. Somewhere in that book should be the (equivalent of) following requirements:

a.       If the implementation of the service does not implement the optional  Information Query procedure, the service shall respond to a GET invocation containing a procedure-type of Information Query with a negative result return with diagnostic 'unsupported option'.

b.      If the implementation of the service does not implement the optional  Notification procedure, the service shall respond to a START invocation containing a procedure-type of Notification with a negative result return with diagnostic 'unsupported option'.

c.       If the implementation of the service does not implement the optional  Notification procedure, the service shall respond to a STOP invocation containing a procedure-type of Notification with a PEER-ABORT with diagnostic 'protocol error'.

With regard to an unimplemented Notification procedure, I am unclear as that what the response to a STOP invocation should be. Where the Notification procedure *is* implemented, a STOP invocation that does not follow a successful START invocation results in a PEER-ABORT for 'protocol error'. Should we continue that philosophy when the procedure is not implemented, too? Or should just simply reject all incoming 2/3 phase invocations for unimplemented procedures and continue the service instance?

Fortunately, the Tracking Data CSTS has no optional procedures, so it is unaffected by this particular issue. But once we decide how to handle this situation, we should probably correct (via Technical Corrigendum) the Monitored Data book.

In the interest of moving the Forward Frame book forward to the spring first draft release, I'm going to include the following "strawman" information in that book:

1.       Define a throw-event-procedure-enabled service configuration parameter, registered under the forwardFrameExtendedServiceParameters  tree. This will have the value true for FF service instances in which the Throw Event procedure is both implemented and enabled for the instance user. If the Throw Event procedure is either unimplemented, or implemented but not available for the instance user, the value will be false.

2.       Add the following requirements to section 3:

a.       Replace the refined Throw Event procedure in table 3-1 with the extended and refined Master Throw Event procedure (derived from the Framework Throw Event procedure).

b.      If the implementation of the service does not implement the optional  Cyclic Report procedure, the service shall respond to a START invocation containing a procedure-type of Cyclic Report with a negative result return with diagnostic 'unsupported option'.

c.       If the implementation of the service does not implement the optional  Cyclic Report procedure, the service shall respond to a STOP invocation containing a procedure-type of Cyclic Report with a negative result return with diagnostic 'unsupported option'.

d.      If the implementation of the service does not implement the optional  Information Query procedure, the service shall respond to a GET invocation containing a procedure-type of Information Query with a negative result return with diagnostic 'unsupported option'.

e.      If the implementation of the service does not implement the optional  Notification procedure, the service shall respond to a START invocation containing a procedure-type of Notification with a negative result return with diagnostic 'unsupported option'.

f.        If the implementation of the service does not implement the optional  Notification procedure, the service shall respond to a STOP invocation containing a procedure-type of Notification with a negative result return with diagnostic 'unsupported option'.

g.       If the implementation of the service does not implement the optional  Throw Event procedure, the service shall respond to an EXECUTE-DIRECTIVE invocation containing a procedure-type of Throw Event with a negative result return with diagnostic 'unsupported option'.

3.       In the Master Throw Event section:

a.       Refine the behavior to be able to access the configurable parameters of the directly-underlying production FRs, but *not* to access the any dynamically-configurable parameters of any of the procedures of the service itself (i.e., those of the Sequence-Controlled Frame DP and Buffered Frame DP procedures).

b.      Extend the behavior to control the response to EXECUTE-DIRECTIVE invocations on the basis of the throw-event-procedure-enabled service configuration parameter (i.e., invocations get rejected if throw-event-procedure-enabled = false).

c.       Extend the procedure state table to reflect the influence of the throw-event-procedure-enabled service configuration parameter (i.e., invocations get rejected if throw-event-procedure-enabled = false).

Note that my adjustments address the two issues that have been raised in this email:

a.       How to handle the invocations for an optional procedure that is not implemented. Since this has already been identified in 3.9.4 of the Guidelines, I believe that there is remaining work to be done in the Guidelines to ensure that the intended behavior (rejection, not abort) is unambiguously conveyed in CSTS specifications, and

b.      How to handle implemented procedures that may be enabled or disabled on a service-instance basis. The Guidelines do not address this issue, and given our decision to allow service to go beyond the Guidelines when necessary, it does not necessarily need to be addressed explicitly in the Guidelines.

Of course, this is just a strawman approach, subject to discussion and approval. We have the telecon next month, but I would very much appreciate any feedback on these ideas as soon as possible so that I don't wander too far down any wrong paths.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20171113/903af9ff/attachment.html>