[Css-dts] Response the SMWG Action Item #53

[John Pietras]

Members of the SMWG and DTSWG,

At the SMWG meeting in October, the Data Transfer Services Working Group
(DTSWG) raised an issue regarding transfer service instance names, and
indicated that they were going to be proposing a new instance naming
scheme. We realized that the new naming scheme might affect the
persistence of transfer service instances across alterations in service
request scenario. However, because we (the SMWG) did not actually have
the DTSWG proposal to evaluate, I took the action (SMWG AI#53) to review
the DTSWG proposal and report back to the SMWG the possible
consequences. This is my response to that action item.

The discussion of this topic during the October meeting raised an
ancillary concern about the persistence of transfer service instances
across changes of the service request scenario, and whether the transfer
service instance identifier (and thus the service instance itself) would
somehow be constrained by the scenario. That issue is really the topic
of a separate thread of discussion, which I hope to address in the near
future. I hope that it is clear from the discussion below that the issue
of transfer service instance identification need not be controlled by
the scenario under which the transfer service instance executes.

BACKGROUND

A brief summary of the issue raised by the DTSWG is as follows. As part
of the data transfer service (e.g., RAF) BIND operation, the invoker
(MUE) must identify the data transfer service instance to which the
invoker wishes to bind. The valid "service-instance-identifiers" must be
known to both parties (MUE and service provider), and "Service
Management" was given the responsibility for coordinating the transfer
instance identifier between both ends. 

The essential requirement is that the service instance identifier be
unique within the context of the service request. Any number of schemes
could have been devised to meet this requirement. However, P3WG1 (the
precursor of the SMWG) recognized that the GDMO-based method for service
management automatically yields a unique name (the "Distinguished Name"
(DN)) for the transfer service managed object that represents the
transfer service instance, so the logical decision was made to use the
DN of the transfer service management object to also uniquely identify
of the transfer service associated with it. A benefit of using this
approach was that the transfer service instance identifiers never had to
be explicitly exchanged between UM and CM, because they were
automatically derived from other management information.

This naming scheme was adopted for the transfer service specifications
and incorporated in the ASN.1. 

When the direction of SLE-SM was directed away from GDMO to XML, the
disappearance of the DNs meant that service instance identifiers could
not be automatically set to those names. 


DTSWG SOLUTION

The DTSWG has proposed a solution for creating DNs to be used as service
instance identifiers, in the absence of a Service Management "algorithm"
to automatically generate those DNs. The proposed minimal DN has the
form of:

sagr=<Service Agreement identifier>.
      spack=<Service Package identifier>.
      <ForwardReturnService type>=<functional group identifier>.
      <Service Name type><service identifier>

Where <ForwardReturnService type> is defined as either "fsl-fg" or 
"rsl-fg", <Service Name type> is one of a defined set of pre-defined
string combinations (e.g. "cltu=cltu", "raf=onlc", "raf=offl"), and
<service identifier> is a numeric string.
      

EFFECT ON SERVICE MANAGEMENT

What, if any, is the effect of the DTSWG's proposed transfer service
instance identifier scheme on the SLE-SM Service request schema?

The SLE-SM schema has a transferServiceIntanceId element in every
transfer service declaration in the Service Request. One of the
decisions that was made early in the considerations for simplifying
service management was that the identifier attached to each service
instance would itself be unique within the context of the Service
Request. That is, it does not depend on its containment to distinguish
it from other transfer service instances in the same service request. So
as long as the string is unique (which the DTSWG proposed naming scheme
enforces), it is an acceptable identifier for Service Management
purposes. 

So we could simply put the complete DTSWG-defined service instance
identifier in the transferServiceIntanceId. Under this approach, 
Service Management would not perform any semantic validation of the
identifiers. E.g., there would be no checking to ensure that the "sagr"
clause of a service instance identifier actually matches the service
agreement identifier specified in the Service Request (or that the
"sagr" value is even a valid service agreement identifier).

A different approach would be to use the information that is already in
the totality of the service request to create a virtual service instance
identifier. This is essentially how service instance identifiers were
created under the GDMO approach. Under this approach, the <Service
Agreement identifier> and <Service Package identifier> values would be
equal to the contents of the serviceAgreementRef and serviceRequestId
elements of the Service Request, respectively. The <ForwardReturnService
type> is easily derived from the type of the service (which implies its
direction). 

The problem comes in trying to automatically derive the value of the
ForwardReturnService, which is defined in terms of functional groups,
since the Service Requests make no reference to functional groups. From
a Service Management perspective the ForwardReturnService clause of the
service instance identifier is meaningless. There appear to be three
options to work around this problem:

1. Delete the ForwardReturnService clause from the service instance
identifier, so that is would look like: 
sagr=<Service Agreement identifier>.
      spack=<Service Package identifier>.
      <Service Name type><service identifier>

If this option is taken, then the <Service Name type> is automatically
derived from the service instance specification in the Service Request
and the mode information carried in the referenced transfer service
configuration profile, and the <service identifier> is equal to the
content of the transferServiceInstanceId element.

>From a Service Management perspective, option 1 is preferred. It
eliminates meaningless information. 

2. Fix the value of the <functional group identifier> (e.g., always =
"1"). If this option is taken, then again the <Service Name type> is
automatically derived from the service instance specification in the
Service Request and the mode information carried in the referenced
transfer service configuration profile, and the <service identifier> is
equal to the content of the transferServiceInstanceId element.

If the DTSWG is committed to maintaining the form of the service
instance identifier that includes the ForwardReturnService clause, but
otherwise has no use for it, then option 2 should be used.

3. Combine the ForwardReturnService clause and the ServiceName clause to
form the value of the transferServiceInstanceId element. 

This approach should only be used if the ForwardReturnService clause has
some meaning to the proper operation of the transfer service instances.
As this is highly unlikely, this option appears to be a non-starter.

There are more lower-level details that would need to be worked out for
any of these options, but we should first arrive at a consensus as to
which approach we would like to pursue. 


SUMMARY AND CONCLUSION

At the top level, there are two approaches that Service Management can
take to accommodate the service instance identifiers as proposed by the
DTSWG.

The first approach is to just assume that the complete service instance
identifier will be conveyed in the respective transferServiceInstanceId
elements of the Service Request. This is the simplest approach, but it
includes no semantic checking between the service agreement
identification, service request identification, and service type
information in the Service Request. However, we could put facet pattern
restrictions on the transferServiceInstanceId elements to enforce the
format.

The second approach is to create a virtual service instance identifier
that uses the semantically-related information from the service request
as a whole. The advantage to this approach is that it inherently
semantically validates. The disadvantage is that the
ForwardReturnService clause of the service instance identifier format
cannot be derived from information contained in the Service Request.

My recommendation is that the first approach be used because it requires
no change to the DTSWG's proposed format. To Service Management the
service instance identifier will be "just a name". 

Finally, note that in all of these options the transfer service instance
identifier does not include any reference to the service request
scenario under which the transfer service instance executes. Under the
old GDMO-based naming conventions, in which object names were taken from
their containment, a transfer service instance managed object name would
include a clause identifying the containing scenario. We are no longer
constrained to GDMO naming, and indeed we have actively asserted our
desire to decouple our names from such a hierarchical containment
scheme. Thus the service instance
"sagr=12.spack=MEX_default.rsl-fg=1.rcf=onlc5" can be in any or all
scenarios of a service request. The real problem that remains to be
addressed is how to specify that a transfer service instance, whatever
its name may be, can persist across changes of scenario.