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

[Martin Götzelmann]

Dear John,
 
Sorry for not responding earlier - I was quite busy with other work.
 
The way that "permanent service instances" are used today in the implementation I know is that at least all specifications contained in the so-called "Service Instance Configuration File" (SICF) remain constant - with exception of the provision period, which is simply ignored. The Service instance provision period is assumed to have started when the service is "loaded" and is assumed to terminate when the service instance is "unloaded". Loading and unloading of the service instance happens according to an external schedule and may happen automatically a schedule execution system or "manually" by an operator. Configuration parameters not in the SICF may also be considered constant.
 
My understanding of permanent service instances is that the complete configuration (with exception of the provision start and stop times) is the same in all service package in which the service instance is used. Different service instances would be used if the configuration is different. To what extent this is intentional and to what extent it might be driven by limitations of the current implementations, I cannot tell.
 
Kind Regards,
Martin
 

________________________________

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 22 October 2008 21:42
To: css-csts at mailman.ccsds.org; smwg at mailman.ccsds.org
Subject: [Css-csts] Questions about "permanent" transfer service iinstances



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

 

 

 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20081118/2c0ebd0a/attachment.html