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

[Martin Götzelmann]

Dear John,
 
I do not really see how the approach you are proposing can be implemented without changing the FW. The general approach specified there is 
- all procedure instances that can be activated by the user must be specified in advance;
- conceptually the procedure instances are all created at the time the service instance is bound
- procedures are always identified by procedure type and number and the provider is required to check both the type and the number is a user request to verify that it relates to an existing procedure and that this procedure is in the state expected by the other side.
 
I always had a vague feeling of uneasiness with these specifications because I felt that the approach was rather static, but that is what has been agreed and there have been good reasons to do so.
 
To implement your proposal I think that as a minimum the check on the procedure instance number must be handled differently than in the current version of the FW. Beside that, I am afraid that there might be a number of issues related to such a change, which we currently do not yet fully understand. Taking your example: if all procedures have already been created and the user invokes START with no number, which one should the provider pick? If he picks #1 and the user subsequently invokes START with the number 1 is that an error? I assume that all could possibly work if all procedure instances were identical but I believe nothing in FW currently prevents a Service from using pre-configured instances, which would make them distinguishable. To implement your proposal, we might have to insist that all procedure instances are identical. But if all procedure instances of the same type are identical, why do we create them at the time of binding and not let the user "create" them with the first invoked operation? If we would create a procedure instance with the first invocation, then what would the state machine look like? etc.
 
If my memory serves me well, the main reason to have two potential prime procedure instances was that development of two different CSTSes to support a synchronous and a asynchronous forward frame services was considered politically unacceptable. On the meeting everybody seemed to say that these two options would never be used simultaneously for any mission. If that is true, I think the selected solution is appropriate and I would suggest not to introduce more complexity by trying to add more flexibility.
 
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: 08 February 2011 14:36
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] FW: Managed selection of prime procedure type



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


______________________________________________________________________
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/20110208/8ce607fd/attachment.html