[Css-csts] Accommodating 3-phase operations

[Yves.Doat at esa.int]

Dear John

If we look at the individual parameters of the standard header, we see:
performer-credential: not suitable to carry the information;
invoker-id: the values of the invocation and the two returns are the same;
Result can be positive or negative result. The information associated to a 
positive result will be carried by the parameter positive-result-return. 
The information associated to a negative result will be carried by the 
parameter diagnostic.
So obviously we do not have a dedicated field for that information and 
this information cannot be carried by the standard header.

As you know all the approach is based on the extension capability of the 
operations, of the procedures and of the service. I propose therefore that 
the DIRECTIVE operation is defined with:

        Parameters                                     Invocation Return
standard-operation-header (confirmed)                   M           M
confirmation                                                        M
....
extension-parameter                                     M           M


In the returns the confirmation parameter would take the values 
first/second responses or initial/final responses
I hope this answer your question. Please let me know if you agree with my 
answer.

Best regards

Yves DOAT
__________________________________________________
Head Ground Infrastructure Baseband Section (OPS-GIB)
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: (49 (6151) 90.2288               Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________




John Pietras <john.pietras at gst.com> 
Sent by: css-csts-bounces at mailman.ccsds.org
14/11/2006 16:15

To
css-csts at mailman.ccsds.org
cc

Subject
[Css-csts] Accommodating 3-phase operations






Members of the CSTSWG:
CCR-44 identifies the need for 3-phase operations, and suggests adding
an acknowledge return as well as a final return. The THROW-EVENT
procedure is specifically identified as at least one instance of a
procedure that would incorporate a 3-phase operation (formerly the
"Control_Directive" operation, now called simply "Directive" in the
latest draft CSTS Procedures Definition Recommendation (v0.5)).

Presumably, the Directive operation would include the Standard Confirmed
Operation Header defined in section 4.2 of the CSTS Procedures
Definition. However, that standard header makes mention only of a single
Return. 

There are several possible ways to address this problem: 

1. Leave the Standard Confirmed Operation Header as currently defined,
and somehow extend it for the Directive operation to change the "return"
into a "final return" and to add an "acknowledge return". This seems a
bit awkward, in that it redefines a major massage type (the return).

2. Define the Standard Confirmed Operation Header as the more-general
case (e.g., with both an Acknowledge Return and a Final Return), and
then limit the definitions of 2-phase operations to only returning Final
Returns. Yasunori Iwana essentially documented this 2-return-column
approach for the Control-Directive operation in his draft CSTS Toolkit
W06 document (in the CSTS Private/JAXA Proposal for CSTS Toolkit
folder). 

3. Continue to define the Standard Confirmed Operation Header as having
a Return, but add the appropriate specifications to mandate that in some
cases two returns are sent, and add sufficient qualification to the
parameters to identify which type of return is being sent. The simplest
way to do this would be to add another possible value ('acknowledged')
to the result parameter. The definitions of 2-phase operations would
exclude the possibility of the result parameter taking the
'acknowledged' value.

My current feeling is that option 3 is the least intrusive on the
current structure of the header and its component parameter definitions.


How the three-phase operations are accommodated (or not) by the standard
headers is of particular interest to me, in that I will be working on
the definition of the Directive operation and the THROW-EVENT procedure
that uses it. There may not be time in tomorrow's telecon to address
this issue, but I hope that we can have an email discussion on the
topic.

I have an additional comment on the definition of the Standard Confirmed
Operation Header as documented in the current CSTS Procedures Definition
draft. The name of the parameter "positive-result-return" is a bit
inappropriate, because "return" is a reserved term and the name of the
larger entity that contains that parameter. How about something like
"positive-result-data"?

I'm looking forward to talking with you tomorrow.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20061116/62ed7d33/attachment.htm