[Css-csts] Comments about the Association Control state table

Thu Mar 27 11:30:08 EST 2008

Dear John,

Just to avoid a possible misunderstanding - I was not suggesting that the attempt to bind to a service instance outside the provision period should *always* return the diagnostic 'invalid time'. As far as I am aware in the current implementations you can get either 'no such service instance' or 'invalid time' depending on the implementation and on operational practices (how long before start of the provision period is the service instance created and how long after the end is it deleted?) The state tables in the SLE books simply do not address creation and deletion of service instances. I do not know whether that is deliberate or not but in essence it means that the behaviour in this case is a local implementation matter.

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: 27 March 2008 16:58
To: Martin Götzelmann
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] Comments about the Association Control state table

Martin,
Thank you for reminding me of the 'invalid time' diagnostic. Some years ago, I attempted to describe how the various parameters of the SLE BIND invocation and return are used to authenticate and enforce access control. That description became Annex E of the Cross Support Concept - Part 1: SLE Service Green Book (CCSDS 910.3-G-3). In it, I had erroneously written "At the scheduled start time for the service instance identified by the serviceInstanceIdentifier, the Responder listens for a BIND invocation at the responder port identified in the responderPortIdentifier." Clearly that's inconsistent with the BIND 'invalid time' diagnostic, but no one had ever noticed the error. This is where my (mis)understanding came from.

So I agree with you that the service instance can exist and be unbound for an arbitrary time before the start of the service instance provision period, but I am not sure that it necessarily begins at the time that the service instance is scheduled. It seems to me that a legitimate (and even likely) implementation approach would be to have one or more "CSTS processors" that are configured for their current or next upcoming service instances by a controller system that is driven by the schedule. In any case, I concede that from a practical perspective a service instance exists for as long as the CSTS processor is configured to support that service instance at the designated provider port. 

I also agree that the 'invalid time' diagnostic covers the case where the service instance is in the 'unbound' state when the service instance provision period ends - any subsequent attempt to BIND will fail with the 'invalid time' diagnostic. 

However, the state table and/or the definition of the BIND operation do not currently correctly represent the behavior of the service instance when the UNBIND is invoked with unbind-reason 'end'. In such a case, subsequent BIND invocations are supposed to fail. I think the easiest way to fix this would be to add the BIND diagnostic 'service instance ended', defined as "the service instance has been permanently unbound via the UNBIND operation with an 'end' unbind-reason". Then the inability to rebind will be following an 'end' UNBIND will be captured in the state table via the -BindReturn.

Note that in the v0.12 Procedures Definition, table 5-5 lists a "end" predicate that is not actually used anywhere in the state table. Perhaps this was supposed to have been a part of the specification of the proper behavior following an 'end' UNBIND that was never completed in the state table. 

Best regards,
John

> -----Original Message-----
> From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
> Sent: Thursday, March 27, 2008 7:00 AM
> To: John Pietras
> Cc: css-csts at mailman.ccsds.org
> Subject: RE: [Css-csts] Comments about the Association Control state table
> 
> Dear John,
> 
> The specifications you are addressing have obviously been copied from the
> SLE Books.
> 
> Is it really the case that a service instance does not exist before the
> service instance provision period starts? As service instances are agreed
> in advance by service management, "something" must exist before that time.
> Maybe what exists is only the agreement that there will be a service
> instance but I feel conceptually one could consider a service instance to
> be created by service management and to exist as soon as it is scheduled.
> Also in a real implementation a service instance will have to be created
> before the start of the provision period in order to be ready to receive a
> BIND invocation when the provision period starts. In fact the BIND
> diagnostics include the code 'invalid time' specified as "the BIND
> operation was invoked outside the service instance provision period of the
> service instance identified by the service-instance-identifier parameter"
> (also copied from the SLE books).
> 
> Where we do have a problem is with the association control procedure if we
> insist that this procedure is created only when the service instance has
> been bound ... If we keep the specification that procedures are
> instantiated only after binding we will have to say that the association
> control procedure is different and we will have to add corresponding words
> to section 2 and maybe to association control procedure specification as
> well.
> 
> Concerning the events in detail:
> 
> [Ad 1] The event 'start of service instance provision period' is only
> needed for provider initiated binding. In fact is included in the RAF book
> but not in the CLTU book. As provider imitated binding is no longer
> supported, I think we should remove this event.
> 
> [Ad 2] Due to the arguments stated earlier, I would not have a problem
> with "[ignore]", but maybe "-> terminate" is clearer provided we find a
> precise definition of what "terminate" means. I guess "terminate" would
> apply also when the provider is in the bound state (following the PEER-
> ABORT). We would also have to consider how to express termination of the
> service instance when the user unbinds with the reason set to 'end'.
> Obviously one would first have to complete the bind operation and then
> terminate ... There might be more cases to consider and I wonder whether
> the added clarity is worth the added complexity of the state table.
> 
> Best 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 20:39
> To: css-csts at mailman.ccsds.org
> Subject: [Css-csts] Comments about the Association Control state table
> 
> I have two comments about the effects of the service instance provision
> period on the Association Control procedure state table.
> 
> First, in the v0.12 Procedures Definition version of the state table,
> for the Incoming Event 'start of service instance provision period', the
> action is listed as [ignore] when the provider is in the 'unbound'
> state. It is my understanding that the service instance and its
> Association Control procedure instance do not exist until the start of
> the service instance procedure period, so that the procedure and service
> cannot even *be* in the unbound state in order to ignore the event. I'm
> not sure how this could be represented in the state table. Perhaps the
> "[ignore}" can be changed to "Not applicable", accompanied by a note
> along the lines of "The 'start of service instance provision period'
> initiates the service instance and Association Control procedure and
> places them in the 'bound' state".
> 
> Second, for the Incoming Event 'end of service instance provision
> period', the action is again listed as [ignore] when the provider is in
> the 'unbound' state. It's my understanding that when the service
> instance provision period ends the service instance and the Association
> Control procedure terminate. I believe that "[ignore]" should be
> replaced by "-> terminate".
> 
> Please provide comments on my comments. Is my understanding correct, and
> if so do my suggestions make sense?
> 
> 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

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