[Css-csts] FW: add 'Blocked' and 'Unblocked' operations?

Tue Oct 18 03:24:38 EDT 2005

Dear Tim,
 I finally had time to read and answer your mail.

The first comment I have is related to the BOUND and UNBOUND states. From
your mail I understand that you consider those states to be relevant to the
operations ("Foundation Layer"). In my opinion the BOUND and UNBOUND States
are relevant to the entire service. The BIND operation contains among others
the 'service-type' and the 'version-number' of the service. I agree that a
service uses a one or more procedures that in turn use one or more
operations. However I do not see with the existing definitions how to
dissociate the operations from the procedures and from the services.

In your mail you state that a procedure is started once the service is bound.
In my opinion, the procedure of a service is started only when the user is
bound and invokes it.

You are proposing to define two new operations BLOCKED and UNBLOCKED
(RUNNING, INTERRUPTED and HALTED). While I understand their purpose I note
that the semantic you are defining is already covered in the existing
services by means of 'notifications'.
I note that in the existing definitions of the production interrupted and
halted do not trigger transition to different states.

The Return services (xxx-SYNC-NOTIFY) define the 'interrupted' behaviour in
section 3.7.2.3 for RAF:
   ‘loss of frame synchronization’—the delivery of frames has been
   interrupted ...
   there shall be no explicit notification when the frame synchronizer
   transitions from ‘out-of-lock’ to ‘in-lock’; rather, the next invocation
   of RAF-TRANSFER-DATA shall implicitly indicate the occurrence of that
   event;
   Note: The behaviour is the same for 'halted'.

The forward services define the same behaviour with however a difference. As
the user cannot notice that the service resumed (no TRANSFER-DATA), a
specific notification will ensure that the user is synchronised with the
provider.

Considering that the behaviour defined in your mail seems to be defined in
the existing services I am not convinced that we should change it and
introduce new operations and new states. Would you have time to check in the
existing definition if the defined behaviour is in line with your
expectations?

Best regards.

Yves
OPS-GIB
ESA/ESOC
Robert-Bosch str.5
D-64293 Darmstadt
Tel.: (+49)-6151-902288

                      Tim Ray                                                                                                                  
                      <tim.ray at nasa.gov>              To:      css-csts at mailman.ccsds.org                                                      
                      Sent by:                        cc:                                                                                      
                      css-csts-bounces at mailma         Subject: [Css-csts] FW: add 'Blocked' and 'Unblocked' operations?                        
                      n.ccsds.org                                                                                                              

                      21/09/2005 21:43                                                                                                         

Hello all,

Please allow me to clarify a few things about my previous email (forwarded
below):

1) THE BIG PICTURE:  I’m trying to find a more elegant way to handle
Production outages within the Data Processing procedure.
2) One possible solution is to add Blocked and Unblocked operations.  I’m not
entirely sold on this particular solution, but it seems worth considering.
(if you read this whole email, you will see that my own consideration of this
solution led to another potential solution)
3) Although these new operations would be available to all procedures, I only
see them being used by the Data Processing procedure, and…
4) the Blocked operation would only be initiated from the Started state.

The rest of this email attempts to elaborate on the above ideas…

Our layered approach:
Services
Procedures
Operations (what I might call the “Foundation Layer”)

Although we haven’t decided on “option B” (that Martin presented last Friday
morning), let’s see how Blocked/Unblocked might fit into that option:

The state of the “Foundation Layer” is either Unbound or Bound.
Once the Foundation Layer is Bound, the appropriate procedures are started.
Some procedures will probably be stateless.  Other procedures will have
states, and will have their own state table logic (separate from the
Foundation Layer’s).
The Data Processing procedure could be specified as having 3 states – Bound,
Started, and Blocked.  “Blocked” would mean that the Provider cannot
currently accept a Confirmed-Data-Transfer-Invocation from the User.  (Keep
in mind – this “Blocked” state is within the Data Processing Procedure;
therefore, its definition applies only to the Data Processing procedure).

Now, suppose that production is interrupted at the Provider side.  The Data
Processing procedure would enter the Blocked state.  It would use the Blocked
operation to synchronize with the User (i.e. to ensure that both sides
transition to the Blocked state).  (The Blocked-Invocation message might
include a field called ‘Reason For Blockage”, which could be set to indicate
Production-Interrupted).

Now, suppose that production becomes operational again.  The Data Processing
procedure would not be blocked anymore, and would enter the Started state.
It would use the Unblocked operation to synchronize with the User (i.e. to
ensure that both sides transition to the Started state).

One potential problem – if the Provider can signal “Production Interrupted”
followed (later) by “Production Halted”, how can we handle this elegantly?
i.e. if a production outage can be either short-term or long-term then a
single Blocked state may not be sufficient.  Perhaps instead of adding 1 new
state to the Data Processing procedure, we should add 2 new states –
Interrupted and Halted – the resulting states might be:
            Running -- a successful Start operation causes this state to be
entered
            Interrupted -- a short-term outage causes this state to be
entered and an INTERRUPTED operation to be initiated by the Provider
            Halted -- a long-term outage causes this state to be entered and
a HALTED operation to be initiated by the Provider
NOTE:  When Production becomes operational again, the Provider would issue a
RUNNING operation and both sides would return to the RUNNING state.  The
RUNNING operation could occur from either the Interrupted or Halted state.

Best regards,
Tim Ray
NASA/Goddard

From: Tim Ray [mailto:tim.ray at nasa.gov]
Sent: Tuesday, September 20, 2005 2:06 PM
To: css-csts at mailman.ccsds.org
Subject: add 'Blocked' and 'Unblocked' operations?

Hello all,

Does it make sense to consider adding two confirmed operations (Blocked and
Unblocked) to our generic SLE spec?

The Blocked operation would be used to indicate that incoming data transfers
are blocked.  The return would always indicate a positive result.

The Unblocked operation would be used to indicate that incoming data
transfers are no longer blocked.  The return would always indicate a positive
result.

Note that both the Blocked and Unblocked operations would originate at the
Provider side.

Perhaps these operations (or something similar) would allow us to specify the
reporting of (and recovery from) Production outages more elegantly?

Best regards,
Tim Ray
NASA/Goddard

 _______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts