[Css-csts] Accommodating 3-phase operations

Tue Dec 5 03:19:48 EST 2006

Dear John,
I finally found a little bit of time for preparing an answer to your mail
with my understanding. For my reasoning I add at the beginning some history
and constraints that I listed to help me to come to my answer at the bottom
of the mail.

THROW-EVENT PROCEDURE
That procedure is derived from the needs to execute directive that affect the
complex management. The execution of such directives may take a certain time
(predictable or unpredictable). The reason of having a 3-phases-operation is
to ensure that not only the acknowledgement of the reception is provided, but
also the acknowledgement of the processing results of the directive. The
processing may end with a positive or a negative result.

APPROACH IN THE DRAFT BOOK AND PROCEDURES:
We have two types of common headers: confirmed header operations and
unconfirmed header operation. In the context of the 3-phases-operation, we
are only concerned with the confirmed header operation.

All confirmed operations use the confirmed header operation.
This implies that all confirmed operations can have a positive or negative
answer and we shall not restrict that possibility.
In case of positive answer, the answer may carry additional information.
In case of negative answer, the answer carries a diagnostic (one of the
common diagnostics or one of the extended diagnostics) and possibly
additional information.
From the approach discussed in the WG one cannot exclude negative answers to
a confirmed operation. During the discussions we were very clear that any
information defined at the level of the common hear is available to all
operations. One cannot descope part of the information defined there.

3-PHASES-OPERATION
In the 3-phases-operation each answer can be positive or negative.

The first answer may be positive or negative.
If the first answer is positive:
- the answer may carry additional information;
- a second answer is to be expected.
If the first answer is negative:
- one of the standard diagnostics is to be used;
- alternatively an extended diagnostic is to be used;
- the answer may carry additional information;
- a second answer is not to be expected.

The second answer may be positive or negative.
If the second answer is positive:
- the answer may carry additional information.
If the second answer is negative:
- one of the standard diagnostics is to be used
   formally speaking, the second answer could carry the diagnostic
‘duplicate-invoke-id’,
   the ‘out-of-service’ diagnostic could occur if between sending the first
and the second answer, the provider becomes out-of-service,
- alternatively an extended diagnostic is to be used;
- the answer may carry additional information.

As you can see from the above description and due to the inheritance of the
common header it is not possible to enforce a positive response.

YOUR QUESTION: How to handle diagnostics between the two answers?
The question you are raising: do we have to use the same diagnostics for both
answers or can we have distinct diagnostics is valid. We should look into the
possibility to have two diagnostic extensions: one set for the first answer
and one set for the second answer. I propose you work-out the procedure in
that direction identifying the diagnostics for the first and second answers.
We will then check for consistency with the rest of the document.

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>                                                         To 
             Sent by:                   Yves.Doat at esa.int                    
             css-csts-bounces at m                                           cc 
             ailman.ccsds.org           css-csts-bounces at mailman.ccsds.org,  
                                        css-csts at mailman.ccsds.org           
                                                                     Subject 
             17/11/2006 22:47           RE: [Css-csts] Accommodating 3-phase 
                                        operations                           

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                                       To 
                                              css-csts at mailman.ccsds.org     
                                                                          cc 
 14/11/2006 16:15                                                            
                                                                     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
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts