[Css-csts] Questions about "permanent" transfer service iinstances

[John Pietras]

CSTSWG and SMWG colleagues-

 

At the end of the CSTSWG meeting in Berlin, the question was raised as
to whether Space Communication Cross Support Service Management
(SCCS-SM) supports "permanent transfer service instances". It was then
explained that the transfer service instances aren't really permanent -
their service instance provision periods are still scheduled, and
binding to a service instance is still impossible outside of its
provision period. This note addresses the ability of SCCS-SM to support
these so-called permanent transfer service instances, and poses a
follow-up question for clarification.

 

According to the various SLE transfer service specifications (and the
forthcoming Cross Support Transfer Service (CSTS) specifications), each
transfer service instance has associated with it a Service Instance
Identifier that is defined (in the ASN.1) as the concatenation of: the
name of the Service Agreement; the name of the Service Package; the name
of the functional group with which the service instance is associated;
and the Service Name Identifier (which itself is the concatenation of
the service name (e.g., "cltu") and an instance number. This Service
Instance Identifier is passed as a parameter of the BIND invocation for
each transfer service instance. Because the Service Instance Identifier
contains the name of the Service Package (which must be unique for each
Service Package), the Service Instance Identifier itself is unique for
each Service Package. However, for simplicity and repeatability of
equipment configuration, a number of SLE implementations fix the value
of the Service Package component of the Service Instance Identifier to
one value, creating a Service Instance Identifier that doesn't change
from Service Package to Service Package - in effect, a static or
permanent Service Instance Identifier.

 

The method by which Service Instance Identifiers are formed in Red-3
SCCS-SM Service Specification conform with the formal naming convention
defined in the SLE transfer service specifications, and therefore does
not currently support this notion of a permanent Service Instance
Identifier. However, ignoring for the moment that permanent Service
Instance Identifiers are not yet formally defined as an option for
transfer service instances, it would be easy to allow a service instance
to blank out its Service Package name component. In addition, SCCS-SM
currently has Complex Management (CM) assign the instance number
subcomponent of the Service Instance Identifier as part of the
scheduling of the Service Package. In order to support permanent Service
Instance Identifiers, this would have to change so that the instance
number is defined as part of the Transfer Service Profile. [The reason
for having the instance number dynamically assigned by CM was that it
would be simpler to ensure the uniqueness of Service Instance
Identifiers in Service Packages. If UM is to now essentially ask for
specific Service Instance Identifiers, then CM will have to validate
that the same service instances are being requested concurrently, and
reject the Service Package requests if there are any repeated Service
Instances.]

 

Is there anything else that is fixed about these permanent transfer
service instances? For instance, are the provider ID and provider port
ID also static with respect to the Service Instance Identifier? In the
Red-3 SCCS-SM service specification these parameters are populated by CM
as part of the process of scheduling the Service Package so that, for
example, Service Instance Identifier "RAF3" might be associated with
provider ID "XYZ" for one Service Package and provider ID "ABC" for a
different Service Package. Is this okay, or is there some notion that
for a particular permanent transfer service instance the provider ID is
always the same? [Note that having the provider ID fixed for a given
transfer service instance essentially ties that service instance to a
particular "port" (e.g., TCP socket) on a Complex. This would mean that
a single Transfer Service Profile might not be usable (for instance)
across multiple ground stations.] 

 

There are a number of other questions that I would like to ask, but they
really depend on how this initial question is answered. So for now I
would very much appreciate your responses to this question. 

 

Best regards,

John

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20081022/1fcd2292/attachment.htm