[Css-csts] Accommodating 3-phase operations

Fri Nov 17 16:47:23 EST 2006

Yves and members of the CSTSWG,

Your proposal to add a parameter (confirmation) outside of the standard
header to signal the acknowledgement vs. final return status, raises
issues that I have not yet seen addressed in the CSTSWG documentation. 

Under your proposal, the acknowledge return could have either a
'positive-result' or 'negative-result' value for the result parameter.
Does it even make sense to have a "negative acknowledgement"? The answer
to this question may depend on what the acknowledge return is truly
supposed to represent. I have read CCR 44 (which establishes the 3-phase
operation) and I do not understand the complete significance that is
intended for the acknowledge return. Using SLE-SM for comparison, the
SLE-SM acknowledge return signals 3 pieces of information:

1) the performer has received the invocation,

2) the invocation is validly formatted and conforms to the protocol for
that operation, and

3) the final disposition can be expected no later than the time
specified in the return.

For CSTS services, I think we can rule out item (3) above, because CSTS
operations should complete on the order of a minute at the latest,
compared with SLE-SM operations (e.g., scheduling a space link) which
might not be completed for days, weeks, or even months.

That leaves us with items (1) and (2). If the acknowledgement merely
confirms receipt of the invocation, then a subsequent negative-result
can have a diagnostic with any of its defined values. On the other hand,
if an acknowledgement is supposed to signify that some level of
validation has been passed (e.g., that the invoke-ID is not a duplicate,
that the service provider is in-service), then a subsequent final return
with a negative result should *not* have diagnostic values that indicate
otherwise (e.g., that the invoke-ID is a duplicate or that the provider
is out of service) since the preceding acknowledgement has implied
otherwise.

I can think of two ways of addressing this issue (there are probably
more ways, but I will put these two on the table to initiate the
discussion).

The first approach would be to use the positive acknowledgement (that
is, a return with the combination of result= positive-result' and
confirmation = 'acknowledge'(or 'initial' or 'first')) to signal
successful validation of all of the associated tests (whatever we define
those to be), and the negative acknowledgement (result =
negative-result' and confirmation = 'acknowledge') to signal failure of
one of those tests. Use of this approach would require that the
specification of the 3-phase operation and/or the procedures that use
that operation specify which diagnostic values are permitted in the
negative acknowledgement, and which are permitted in negative final
resolution (that is, a return with the combination of result=
negative-result' and confirmation = 'final'(or 'second')). [Note that
this is equivalent to what's done in SLE-SM, where if the validation
checks leading to an acknowledgement fail, an invalidMessageResponse is
sent].

The second approach would be to constrain the value of the result in the
acknowledge return to always be result= positive-result, but allow a
single negative final disposition to be sent instead of an acknowledge
return if the failure occurs in the validation leading to the
acknowledgement. This approach does not require the set of diagnostic
values to be partitioned into pre- and post-acknowledgement categories. 

Perhaps these distinctions are addressed and resolved in material that I
have overlooked, or have been resolved in a CSTSWG session that I did
not attend. If so, please accept my apologies. But if this is still an
open issue, I believe that we need to decide between these two
approaches and possibly other variations.

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

________________________________

From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int] 
Sent: Thursday, November 16, 2006 5:12 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
Subject: Re: [Css-csts] Accommodating 3-phase operations

Dear John 

If we look at the individual parameters of the standard header, we see: 

1.	performer-credential: not suitable to carry the information; 

2.	invoker-id: the values of the invocation and the two returns are
the same; 

3.	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/20061117/1aff4cae/attachment-0001.htm