[Css-csts] New DIRECTIVE operation and THROW-EVENT procedure definitions

[John Pietras]

Members of the CSTSWG --

I have just uploaded updated versions of the DIRECTIVE operation and
THROW-EVENT procedure definitions to the CWE/CSS-CSTS/CWE Private/SLE
Toolkit Procedures folder. These updates reflect decisions made at the
January 2007 meeting, as recorded in the MoM for that meeting. 

http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=http%3a%2f%
2fcwe%2eccsds%2eorg%2fcss%2fdocs%2fCSS%2dCSTS%2fCWE%20Private%2fSLE%20To
olkit%20Procedures&FolderCTID=0x012000A2CFA608DF169C4EB988261660CEFAEB

I have come across several issues, have made a preliminary judgment on
how to approach them, and flagged them with comments in the updated
files. Following is a more-detailed discussion of two of these issues.

1. Is there a need for a separate directive-invocation-identification
parameter in the DIRECTIVE operation?

The December 2006 draft version of the DIRECTIVE operation specification
contained a directive-invocation-identification parameter, mirroring the
parameter of the same name from the FCLTU SLE service specification. In
Colorado Springs, we decided that the
directive-invocation-identification parameter is redundant with the
invoke-ID and could be removed (see section 7.5 of the MoM for the
January 2007 CSTSWG).

However, in updating the draft DIRECTIVE operation and THROW-EVENT
procedure specifications, I have come to question whether they are truly
redundant. 
As defined for the FCLTU service, the
directive-invocation-identification parameter is required to start at a
value of zero (0) and increment monotonically. Presumably this was so
that sequencing of thrown events would be tightly controlled, comparable
to the sequencing of spacecraft commands that is enforced via the
cltu-identification parameter of the CLTU-TRANSFER-DATA operation. 

However, the invoke-ID parameter is not required to increment
monotonically. And even if we were to require that behavior for the
THROW-EVENT procedure (or for services that incorporate the THROW-EVENT
procedure), the values of the invoke-ID parameters that appeared in the
DIRECTIVE invocations would not increase monotonically except in the
case where the service consisted of only one instance of the THROW-EVENT
procedure. 

I can think of several solutions, and others might be possible:
a. Retain the separate directive-invocation-identification parameter.
This is a valid option if the full sequence control found in the FCLTU
transfer service is required.

b. Delete the separate directive-invocation-identification parameter,
and rely only on the invoke-ID for uniqueness. This is a valid option if
only uniqueness, but not strict sequence control, is required.

c. Delete the separate directive-invocation-identification parameter,
change the definition of the invoke-ID such that it only needs to be
unique within each procedure instance, and (at least for the
THROW-EVENT) require that it start a zero and increase monotonically
within each procedure instance. This option would provide full sequence
control while eliminating the directive-invocation-identification
parameter.
For this iteration, the directive-invocation-identification parameter
has been retained. Subsequent decisions by the CSTSWG could result in
the elimination of the parameter, but only if the issues identified
above can be resolved.


2. What is the proper response to an unrecognized/invalid
procedure-instance-identifier?

It is possible for the Provider to receive an invocation with an invalid
value for the procedure-instance-identifier parameter. Should the
response of the Provider be to:
a. Ignore it? (probably not);

b. PEER-ABORT? (This would be reasonable, given that using the wrong
procedure instance identifier would indicate a serious breakdown in the
User's CSTS protocol machine);

c. A new diagnostic value to be returned as part of a negative-result
return? (If so, this should be a standard base diagnostic, since the
procedure-instance-identifier parameter is part of the standard
operation headers.

d. An application of the standard 'invalid range' diagnostic? (I would
suggest that this not be done).
For this iteration it is assumed that that an invalid
procedure-instance-identifier parameter value will result in a
PEER-ABORT, and that the recognition and handling of invalid
procedure-instance-identifier parameter values will be covered by a
common specification applicable to all CSTS procedures. Also, a standard
diagnostic (e.g., 'invalid procedure instance') is assumed to be added
to the diagnostics for the PEER-ABORT operation.


Best regards,
John

John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct:   +1-240-542-1155
GST Main: +1-301-474-9696
Fax:      +1-301-474-5970