[Css-csts] FW: Managed selection of prime procedure type

[John Pietras]

CSTSWG colleagues ---

The disposition of CSTS FW Red-1 RID NASA-TJR-06 states:

"Proposed approach:

1. The service is defined allowing more than one procedure instance to
be prime;

[2]. The prime procedure identification (among the candidates one
identified by the service) is done by SM;

[3]. To change prime procedure, the user shall unbind and bind again
with a different SM configuration."

 

I did not participate in the discussion that led to this decision, but I
am happy with the main point - that more than one procedure type can be
designated as the type that can be used for the prime procedure
instance. However, instead of having the selection managed and requiring
a separate service instance to be established for every prime procedure
type that the user might wish to use, I wonder if the WG considered what
I think is a simpler approach - to let the user dynamically identify the
prime procedure instance by whether or not an instance number is
specified in the procedure-instance-identifier of the first operation
invoked in the context of the procedure instance. This would eliminate
the need to create multiple service instances if the user might need to
use different prime procedure types. Given that the only reason to
designate a procedure instance "prime" is to set the state of the
service (that is, it has no effect on the functionality of the procedure
instance), this seems to me to be something reasonable to consider. 

 

For example, assume that two procedure types, ProcA and ProcB, can host
the prime instance, and other secondary procedure types can be
specified. Both ProcA and ProcB are stateful and set their state via
START/STOP. The service also allows up to N secondary instances of ProcA
and M secondary instances of ProcB. The user STARTs ProcA with no
instance number before STARTing ProcB. ProcA is dynamically designated
the prime instance. Any time after starting the prime instance of ProcA,
the user can START and use the secondary instances using instance
numbers 1-N.  Any time after starting the prime instance of ProcA, the
user can START any of the secondary instances of ProcB using instance
numbers 1-M. If the user attempts to send any ProcB PDU (including the
START invocation) with no instance number, the service is peer-aborted
because ProcA has already taken the prime procedure instance "token".
The user can STOP the ProcA prime procedure (which also moves the state
of the service instance to 'bound.ready'), at which point ProcA could be
used again as the prime procedure instance, or ProcB could be started as
the prime procedure instance.

 

The record of the discussion regarding this RID notes that there was a
concern about additional burden on Service Management. This approach
places no additional burden on SM.

 

As Yves has already discovered and noted in the status for this RID, the
current disposition (having the prime procedure type selected via SM)
has no effect on the FW, but it will on the Guidelines and Concept. The
variation that I propose also has no effect on the FW, but will have an
effect (a different one, of course) on the Guidelines and Concept.

 

Does anyone else see a benefit (as I do) to this modified approach, and
would the WG be willing to consider it instead of the SM-controlled
selection approach?

 

Thank you.

 

Best regards,

John

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