[Css-csts] more Framework spec issues (prime)

Tue Apr 6 10:44:05 EDT 2010

Dear Martin,
I agree with your comments regarding points 2 and 3, but disagree on point 1 (i.e. what is the Provider's response if a User attempts to start a second 'prime' procedure instance?).  You state "If the configuration of a service instance contains more than one prime procedure instance this is a configuration error and the service instance should not even load."     Nothing prevents a buggy implementation from doing things that violate the protocol.   My point is that it is better to define a consistent Provider response, and that requires adding something to our Framework specification.
Best regards,
Tim

From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
Sent: Friday, March 26, 2010 10:27 AM
To: Ray, Timothy J. (GSFC-5830)
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] more Framework spec issues (prime)

Dear Tim,

What follows is my interpretation of the Framework (or maybe what I think is or should be in there - I have not taken the time to verify that all specifications are really present).

Point 1
The FW requires that all the procedure instances that can be present in a service instance are agreed in advance and that all procedure instances are instantiated on both sides at the time the service instance is bound. This implies that the procedure instance identifier of each instance is pre-defined as well. The user cannot assign a procedure instance number when starting a procedure and just declare any procedure instance to be prime. Only one of the configured procedure instances can be the prime instance and can have an instance number 0.  If the configuration of a service instance contains more than one prime procedure instance this is a configuration error and the service instance should not even load.

Point 2
What you describe is the specified behaviour. It might look weird in some cases but I think these are very few exceptions. In the great majority of the applications there is a "main dataflow" - this is true for all SLE services and would also apply to the TD CSTS and the RUFT/RAD CSTS.The model may not be so suitable for the MD CSTS but even there one can imagine a basic set of data you always want to see and you consider the service active if these data are flowing. There is probably not a single model that fully fits for all applications.  We have been discussing a number of alternatives over a long time and the group settled on the concept of a prime procedure as this seemed to be the "best compromise" to members.

Point 3
Point 3 is exactly the same as point 2 because the type of the procedure is irrelevant for the question whether it is prime or not. There for the prime BDD procedure will be stopped the non-prime UDD procedure will continue and the service state will change from active to ready. This corresponds to the following situation for SLE RAF: START starts TM transfer (prime BDD) and the service state changes to active. SCHEDULE-STATUS-REPORT starts status reporting (non-prime UDD). STOP just stops TM transfer but status reporting continues and the service state changes from active to ready.

Kind regards and a nice weekend,
Martin

________________________________
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Ray, Timothy J. (GSFC-5830)
Sent: 24 March 2010 19:50
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] more Framework spec issues (prime)
Hello all,
Here are a few more questions/issues regarding the Framework specification.

1.      Suppose a user starts a prime BDD procedure followed by a start-invocation for the UDD procedure indicating that it is also the prime procedure.  What is the provider response?  (Currently, I think the specification results in the provider accepting both 'prime' procedures, but I don't think that is what we want).

2.      Suppose a service starts a prime BDD procedure, then a non-prime BDD procedure, then stops the prime BDD procedure.  Does the 'stop' of the prime BDD procedure cause all other instances of BDD to be stopped or terminated?   Currently, I think the specification results in the prime BDD being stopped (and the non-prime BDD continues running) and the service-state switches from 'active' to 'ready'.  It doesn't quite seem right to say the service is 'ready' (i.e. not 'active') if lots of data is being transferred.

3.      Suppose a service starts a prime BDD procedure, then a non-prime UDD procedure, then stops the prime BDD procedure.  Does the 'stop' of the prime BDD procedure cause the UDD procedure to be stopped or terminated?
The current definition of 'prime' procedure may be potentially troublesome.  If I have time I will try to explain in more detail.  Basically, the problem is that once the prime procedure instance is stopped, that none of the other active procedure instances can become the prime.
Best regards,
Tim

______________________________________________________________________
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/20100406/7c1521af/attachment.htm