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

Tue Apr 6 11:32:23 EDT 2010

Dear Tim,

Fair enough, but I do not believe the provider can accept two prime procedures ( unless it is itself buggy of course ;-)

If we assume that the provider is correctly implemented then there are two possibilities:
a) its own configuration is incorrect because it specifies two prime procedure instances (with a procedure instance number of 0) and in this case it should not even start the service instance;
b) its own configuration is correct and contains only one procedure instance with a procedure instance number of zero - in that case it should not be able to match the procedure instance identifier in the second request with any of the configured procedure instances and reject the START invocation (or whatever operation starts the procedure).

>From section 3.3.2.6.2.1 of the FW, I derive that a request for a procedure with an unrecognised instance id should be rejected with the diagnostic 'invalid procedure instance identifier'. This code seems to cover all occasions where something is wrong with ID.

I concede however that the cases identified in that section might not be very clear. My understanding is the following:
- invalid procedure type says that the service version supported by the provider does not support the procedure type identified:
- invalid procedure identification : the term procedure identification might be a left over, as it does not appear anywhere else in the document
- invalid procedure instance number: this probably means that the instance number is not known to the provider, but that is not really "invalid"
- invalid procedure type (prime or secondary): It seems to me that this is the same as an unknown procedure instance identifier because the number 0 identifies a prime procedure

When the provider is not able to identify a service instance to which a user wants to bind the diagnostic code is "no such service instance" (see 3.4.2.2.2). We might consider to call the equivalent code for procedure "no such procedure instance" and elaborate a bit the cases in which this code should be used.

Kind Regards, Martin

________________________________

From: Ray, Timothy J. (GSFC-5830) [mailto:timothy.j.ray at nasa.gov] 
Sent: 06 April 2010 16:44
To: Martin Götzelmann
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] more Framework spec issues (prime)

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/f15dedaa/attachment-0001.html