[Css-csts] Possible approaches for interoperability among different transfer service capability sets

[John Pietras]

Members of the CSTSWG ---

We still have some issues regarding the scope of the Monitored Data
Cross Support Transfer Service (MD-CSTS) with respect to supporting
different sets of procedures in an interoperable fashion. Here is my
summary of the situation.

At the CCSDS meeting in Heppenheim in October, the CSTSWG discussed the
Monitored Data CSTS (MD-CSTS) White Book. Key features of that version
of the MD-CSTS were:
1. The ability for the user to configure the service to cyclically 
   (periodically) report any subset of a predefined set of monitored 
   parameters, at a defined 
   reporting period. 
   a. The subset of parameters to be reported, and the reporting period
for 
      that subset, are defined in the START invocation that starts that 
      particular reporting procedure (i.e., "loop" of the overall CSTS).
   b. Multiple subsets can be reported at different reporting periods by

      STARTing different procedure instances (each with its own
reporting 
      period.
   c. For the first version of the MD-CSTS, the predefined set of
monitored 
      parameters, and the syntax for expressing them, is bilaterally-
      defined: the declaration of the parameters to be reported are
carried 
      in a set of opaque octet strings by the START invocation, and the 
      identification of the reported parameters are carried in a set of 
      opaque octet strings by the TRANSFER-DATA invocation. Future 
      derived services could specify explicit, standard sets of
monitored 
      parameters and syntaxes, but the CSTSWG wants to make the first 
      version more generic.

2. The ability of the user to configure the service to notify the user
of 
   the occurrence of any of a subset of a predefined set of events. 
   a. The subset of events to be reported are defined in the START 
      invocation that starts the notification procedure. (only one 
      notification procedure can be instantiated per MD-CSTS instance).
   b. For the first version of the MD-CSTS, the predefined set of
notifiable 
      events, and the syntax for expressing them, is bilaterally-
      defined: the declaration of the events to be notified are carried 
      in a set of opaque octet strings by the START invocation, and the 
      identification of the event that occurred is carried in an opaque
octet 
      string by the NOTIFY invocation. Future derived services could
specify 
      explicit, standard sets of monitored parameters and syntaxes.

3. The ability of the user to query the current value of any of the same

   predefined set of monitored parameters that can be selected from for 
   cyclic reporting (see 1, above). As with the cyclic reporting of  
   parameters, for the first version of the MD-CSTS, the predefined set
of 
   monitored parameters, and the syntax for expressing them, is
bilaterally-
   defined.

In Heppenheim, some members of the CSTSWG  said that they would like to
implement a simpler service, at least at first. That simpler service
would consist of only the cyclic reporting aspect (i.e., item 1 above).
NASA, on the other hand, desires a monitoring service with the full
suite of capabilities outlined above. 

The CSTSWG briefly discussed two approaches in Heppenheim: (a) somehow
defining the notification and query procedures to be optional; or (b)
defining two services right from the beginning: a base service (cyclic
reporting only) and a separate full service (all three features) that
would be derived from the base service. 

The proponents of the two-separate-services approach cited the fact that
there are no existing CSTS concepts for declaring procedures to be
optional, and they were averse to introducing such optional mechanisms.
I was given the action to go away and think about the ramifications of
both approaches.

Subsequently, I briefly discussed this issue with others within NASA,
and the NASA preference remains for some sort of single service that can
cover all options. In the CSTSWG telecon on 19 December, I stated that
NASA did not want to have to support two different implementations of a
monitoring service in its user (e.g., SOC) and provider (ground station)
systems to support interoperability. Several other CSTSWG members
counter-argued that because the full service would be derived from the
base service, they really wouldn't be two separate services. 

I pointed out that even though one would be derived from the other, that
inheritance would be limited to specification sharing and possibly code
sharing at best, but that as far as operations are concerned a (base)
MD-CSTS and an Extended MD-CSTS would operate like separate services.
I.e., there's no cross-compatibility between the services. Each of the
service types has its own service type ID, and there's currently no way
for one service type implementation to recognize that it is at all
related to another service type through derivation. The problem is
exacerbated by the CSTSs' global "abort upon anything that doesn't
strictly belong to this service type" approach (taken from the SLE
services), which (currently) prevents a parent-CSTS instance from having
a different, more benign behavior to an extended message coming from a
peer child-CSTS instance. 

Other members of the CSTSWG agreed that this was a legitimate criticism
of the two-service approach, and we decided to continue the discussion
after the holidays.

After the telecon, it occurred to me that if the CSTSs supported the
feature of substitution, then perhaps NASA might be willing to support
the two services approach. That is, if substitution existed in CSTSs,
then ESA entities could implement the base service, and NASA entities
could implement the derived services, and their instances could still
interoperate. A base-service user (e.g., an ESA SOC) could bind to and
interoperate with an extended-service provider (e.g., a GN ground
station) because the provider would recognize the base service as being
of its parent class, and the user would not START any of the extended
(notification or query) procedures. Similarly, an extended-service user
could bind to and interoperates with a base-service user, albeit with
only the base (periodic reporting) procedure.

Of course, adding substitution into the CSTS specifications would
require additional concept and guideline development, which will involve
some amount of effort. A key aspect would be to develop a way for an
instance of a particular service type to recognize when the service type
of a BIND invocation is for a service that is either a parent or child
service type, and act accordingly. E.g., if the BIND invocation
indicates that the user is implementing a service that is derived from
the type that is implemented by the provider, have the provider return a
negative result with diagnostic "unsupported operation or procedure" for
any operation invocation that's not recognized, instead of peer-aborting
(as is currently the case).

Subsequently, Tim Ray and I met to discuss various CSTS topics, and we
discussed the Monitored Data CSTS issues. Tim proposed an alternative
solution, which  I think boils down to a variation of supporting
optional procedures. Under this approach, there is only one service, but
specific options can be defined. The BIND operation would be modified to
allow the initiator (the entity that sends the BIND invocation - usually
the user) to specify which options (capability set?) the initiator would
like to use. The responder to the BIND (usually the provider) then
returns a positive result return, modified to include which of the
options selected by the initiator the performer will support.  Normally,
both the user and provider will know well ahead of time what common
subset both will use, but this options/capability set identification is
useful in synchronizing the two associated CSTS service entities. (Note
that the capability list will have to be designed so that a service
entity can recognize that there are capabilities being asked for that it
doesn't understand without causing that entity to go belly-up, but
that's certainly doable).

Under this options approach, if, down the road, someone wants a
variation on a service that's backward-compatible with an existing
service, it becomes a new version of the existing service, not an new
(derived) service, and the specification of the new service must at
least recognize all of the previous options. 

Note that under the options approach, there can still be purely derived
services, with no backward compatibility between parent and child
service types. However, since the service type that serves as a parent
for a derived type might itself further evolve, it's important that
derived services be referenced not only to a specific parent service
type, but to a specific version of that parent service type.

So, to summarize, as I see it the current approaches on the table for
providing two or more levels of service for a class of cross support
transfer services (e.g. and in particular, multiple levels of a
monitored data service) are:

1. Create multiple separate types of the service through derivation,
without any form of cross-compatibility between the types. This approach
is essentially supported by the existing CSTS toolkit (a plus) but it
will result in every CSTS user and provider to implement multiple
services of the same class in order to ensure interoperability across
the various networks that support the multiple types. (This approach
remains undesirable to NASA.)

2. Introduce support for substitution, so that implementations of
different services that are related by derivation can "know" that they
are dealing with "family" and interact at some common level.
Cross-compatibility is possible among different services as long as
those services have some parent-child derivation relationship.

3. Introduce support for optional capabilities, and a way of negotiating
those capabilities. Cross-compatibility is possible among
implementations of different set of options, and among different
versions of the that service.

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