[Css-csts] Possible impacts to Association Control procedureresulting from 2-state services

[Ray, Timothy J. (GSFC-583.0)]

John,

I agree with your basic idea and don't have a problem if the response to an "out of sequence" UNBIND is changed from PEER-ABORT to acceptance.

Tim



-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Monday, March 31, 2008 9:34 AM
To: css-csts at mailman.ccsds.org
Cc: Martin Götzelmann
Subject: [Css-csts] Possible impacts to Association Control procedureresulting from 2-state services

Members of the CSTSWG --

Last week, Martin Götzelmann and I had email conversation (copied to the CSTSWG mail list) on the thread "Inconsistent specification of states for services with stateless prime procedure". I tend to agree with Martin's approach of having a 2-state service (for services with stateless prime procedures) in addition to the currently-defined 3-state service (which will now apply only to services with stateful prime procedures). However, I think that there will be consequences for the Association Control (AC) procedure. 

In Crystal City we agreed that an explanation should be added that identifies the AC procedure state table as also representing the service instance state table. But now that the service instance can have two different state tables (depending on the prime procedure), I think instead that the AC procedure definition should focus only on the procedure itself, and cover the state of the service itself separately. The state table of the service would then be defined in terms of a combination of the states of the AC and prime procedures, and there would be two service state table types - one for stateless prime procedure and one for stateful prime procedure.

As an exercise, I have attempted to simplify the AC procedure definition from the v0.12 Procedures Definition so that is only represents the procedure itself, and not the state of the service. I have uploaded the result as a PDF (SimplifiedAssnControlProc-0.12-JVP.pdf) to the Working Materials folder on the CWE at 
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Working%20Materials/SimplifiedAssnControlProc-0.12-JVP.pdf

The simplified AC state table now has just the two states of the AC procedure itself (unbound and bound). WITH ONE EXCEPTION, this change does not appear to change the state table of the service instance as constructed from the states of the AC and prime procedures. That one exception is this: currently, if an UNBIND is attempted when any of the stateful procedures is in the active substate, the AC peer aborts the service instance. But if the AC state machine is now defined separately, it will successfully inform the constituent procedures to unbind and then UNBIND with a positive result (instead of peer-aborting).

When I look at the net result of both approaches, they appear to be the same: all of the procedures do whatever cleanup is necessary and then terminate, and the AC procedure and the overall service transition to the unbound state. The only difference is that one approach arrives at the unbound state via a peer abort, and the other via a successful UNBIND. Is there any reason to insist that it be a PEER ABORT?

The uploaded file also tags various typographical errors and suggested wording changes that are independent of the narrowing the focus of the AC procedure definition to just the procedure itself.

If we do follow this approach, then we have to decide where to formally document the state of the service instance in both possible forms (stateful and stateless prime procedure). I have attempted to do that as part of the Guidelines. I have uploaded (also) to the Working Materials folder of the CWE a PDF of a proposed CSTS States section of the Guidelines ("CSTS States_W-0.04-080331") at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Working%20Materials/CSTS%20States_W-0.04-080331.pdf

This new Guidelines section specifies the core state tables for three types of CSTSes: (1) CSTSes with stateless prime procedures; (2) CSTSes with prime procedures that are stateful because they have START & STOP operations; and (3) CSTSes with prime procedures that are stateful because they are based on the EXECUTE-DIRECTIVE operation.

Whether the Guidelines is the appropriate "home" for this service state table material may be debatable. But I would like to get opinions as to whether this is a good approach for defining the states of the CSTSes. If the material is more appropriate to the Procedures Definition/Framework (is the Procedures Definition document being renamed "Framework"?) then it can be moved there.

I'm looking forward to comments on these thoughts and proposals.

Best regards,
John 


John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct:   +1-240-542-1155
GST Main: +1-301-474-9696
Fax:      +1-301-474-5970

> -----Original Message-----
> From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
> Sent: Thursday, March 27, 2008 6:19 AM
> To: John Pietras; css-csts at mailman.ccsds.org
> Subject: RE: [Css-csts] Inconsistent specification of states for services
> with stateless prime procedure
> 
> Dear John,
> 
> I do not recall that the issue you are addressing was discussed
> explicitly. In my view, the statement in section 2 is a logical
> consequence of the decision that procedures that include only one
> invocation of a single two-way operation are to be considered state-less,
> which to me means that there is no state we can talk about.
> 
> We have said that the state of the prime procedure determines the sub-
> states of the bound state of the service. If the prime procedure has no
> state then it seems logical to me that the bound state of the service has
> no sub-states.
> 
> My understanding was that section 2 would replace the Annex A and that
> Yves has therefore not updated it. However, I am not certain and Yves
> would need to comment on this.
> 
> Kind Regards,
> Martin
> 
> -----Original Message-----
> From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-
> bounces at mailman.ccsds.org] On Behalf Of John Pietras
> Sent: 26 March 2008 19:17
> To: css-csts at mailman.ccsds.org
> Subject: [Css-csts] Inconsistent specification of states for services
> with stateless prime procedure
> 
> Members of the CSTSWG ---
> 
> There is an inconsistency between what the v0.12 draft of the Procedures
> Definition and the Draft 6 update of Section 2 (Description of the CSTS
> Specification Framework, written by Martin) have to say about the states
> of services that have stateless prime procedures.
> 
> Section 3.1.5 of the v0.12 Draft Procedures Definition states that CSTSes
> always have the 'ready' and 'active' substates of the 'bound'
> state. In Annex A the last sentence of bullet (b) states "For a stateless
> type of prime procedure, the transition to service state 2.2
> ('active') will occur after invocation of its operation", and the last
> sentence of bullet (c) states "For a stateless type of prime procedure,
> the service continues in this [active] state until the last on-going
> operation is returned."
> 
> However, in the Draft 6 update of Section 2, the third paragraph states
> "If the prime procedure is stateful the state bound has two sub-states
> ready and active. ...  If the prime procedure is stateless then the
> service state bound has no sub-states."
> 
> Was this discrepancy discussed at Crystal City, and if so what was the
> outcome? That is, does a service with a stateless prime procedure have
> ready and active substates (as stated in the v0.12 Procedures
> Definition) or does the service simply stay in the 'bound' state until it
> is unbound?
> 
> Thanks.
> 
> Best regards,
> John
> 
> John Pietras
> Global Science & Technology, Inc. (GST)
> 7855 Walker Drive
> Suite 200
> Greenbelt, Maryland, USA
> 20770-3239
> Direct:   +1-240-542-1155
> GST Main: +1-301-474-9696
> Fax:      +1-301-474-5970
> 
> 
> _______________________________________________
> Css-csts mailing list
> Css-csts at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts