[Css-csts] Issues regarding the new Notification procedure

Thu Dec 13 09:41:07 EST 2007

Dear John,

Please find below my (personal) views.

>1. In the SLE transfer services, some form of NOTIFY operation has
>always been mandatory. Is creating a separate Notification operation
>procedure intended to make notifications now optional for CSTSs, or does
>every service still have to have a NOTIFY capability?
Considering that we decided to go for a Notification procedure, the services
would be free to use or not to use this procedure. The decision would
therefore be left to the service designer. May be we should recommend, in the
guidelines, to carefully consider that procedure when designing a new
service.

>2. If every CSTS will still be required to have a NOTIFY capability (to
>report on production status at a minimum, for example), will that NOTIFY
>always have to be implemented via the NOTIFICATION operation, or can a
>NOTIFY operation still be used to extend another procedure? [NOTE - if
>every CSTS is expected to have some form of NOTIFY capability, that
>needs to be added to the Guidelines.]
The NOTIFY operation is only possible through the implementation of the
Notification procedure (unles an existing procedure is derived that would
make use of that operation - but I do not recommend that approach). The
guidelines should include some statement (see answers 1 and 4).

>3. If every NOTIFY has to be implemented via the new Notification
>operation, then CSTSs that use the NOTIFY only to report the occurrence
>of the standard (non-extension) events will have more operational
>overhead than the existing SLE services - that is, the requirement to
>START and STOP the Notification procedure is more than is required today
>for SLE services, in which the NOTIFY is automatically enabled as soon
>as the service is bound.
I understand from the Heppenheim MoM that the Notification procedure uses:
   START to subscribe to notifications;
   Issue NOTIFY
   STOP
In terms of overhead, the service using the Notification procedure will have
to issue a START to register to the notification types required by the
service. The service could use more than one Notification procedure and
activate them depending on the needs.
To obtain the same behaviour as in SLE, the service should activate the
Notification procedure (standard events) immediately after a successful BIND.
I am not sure this answer your issue, so let me know.

>4. If the NOTIFY operation can still be implemented in a CSTS by
>extending another procedure by adding a NOTIFY to it, should it be
>possible to have both a NOTIFY-extended procedure and a Notification
>procedure in the same CSTS? In such an instance, the NOTIFY in the
>extended operation and the NOTIFY in the Notification procedure would
>both report the standard baseline events, but only the Notification
>procedure NOTIFY would report the events identified in the Notification
>START operation.
According to the concept book, a procedure can be extended by adding a new
operation. In that case the new service would have its own dedicated
procedure outside the toolkit procedure (See Heppenheim MoM, Annex A figure,
"service specific" procedure on the right of the drawing). While this is
allowed, I would not recommend it as it may end up with a specific
implementation of the toolkit.

>4A. A CSTS could be defined such that the NOTIFY in an extended
>procedure could report on more than the standard baseline events, but
>those events would have to be identified either as part of the service
>definition or as part of the Service Management configuration of that
>CSTS. This mode would allow a NOTIFY to be statically configured for the
>duration of the service instance.
Extending a procedure to include the NOTIFY is possible but I don't like and
do not recomment (See answer 4).

>4B. A single CSTS instance could have multiple instances of the
>Notification procedure. Each instance of the Notification procedure
>would report the common baseline events, as well as that procedure's
>unique events, as identified in the START operation for that procedure
>instance. Is there any reason why we would want such a capability? Is
>there any reason why we would want to forbid such a capability?
Nothing prevent such a configuration and we have extensively discussed this
approach to allow it: we agreed that a service may have several instances of
a given procedure.

>5. Whether the NOTIFY is enabled via a dedicated Notification procedure
>or as an extension to another procedure, it will still differ from the
>SLE approach to notifications in that for CSTSs notifications are not
>automatically enabled upon binding, but must wait for the procedure that
>includes the NOTIFY to start. My first thought was that a similar
>capability could be provided for a CSTS if the Association procedure for
>that CSTS were to be extended with the NOTIFY, but we explicitly forbid
>the Association procedure to be extended with additional operations.
I would continue to forbid extension of the Association procedure with
additional operations.

In Conclusion:
Is it really a problem to enforce a START to get the standard events?
As you state extending a procedure to include the NOTIFY operation would
still not mirror the SLE behaviour and in my opinion would only add
complexity.
Extending the Association is (in my opinion) not an option.
The nearer SLE behaviour would be for the service to have the Notification
procedure started immediately after the association is established. This
behaviour can be specified in the service definition.
The possibility of have several instances of the Notification procedure is
allowed and should not be problematic.

Please let me know if my answers are clear to you. We can discuss those
points during our next teleconference.

Best regards
Yves
_________________________________________________
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:                   <css-csts at mailman.ccsds.org>         
             css-csts-bounces at m                                           cc 
             ailman.ccsds.org                                                
                                                                     Subject 
                                        [Css-csts] Issues regarding the new  
             11/12/2007 19:57           Notification procedure               

Members of the CSTSWG --
In Heppenheim, the decision was made to create a Notification procedure
that could have the events to be notified specified in the START
operation for that procedure. The Monitored Data service would use a
separate instance of the Notification procedure instead of having the
NOTIFY operation embedded in the Monitor Cyclic Report Procedure. In
attempting to develop the definition of the Notification procedure, some
issues have arisen. I believe that I missed some of the discussion on
this topic, so I may not understand all of the CSTSWG's intentions and
motivations for creating this procedure. Let me try to explain these
issues.

1. In the SLE transfer services, some form of NOTIFY operation has
always been mandatory. Is creating a separate Notification operation
procedure intended to make notifications now optional for CSTSs, or does
every service still have to have a NOTIFY capability?

2. If every CSTS will still be required to have a NOTIFY capability (to
report on production status at a minimum, for example), will that NOTIFY
always have to be implemented via the NOTIFICATION operation, or can a
NOTIFY operation still be used to extend another procedure? [NOTE - if
every CSTS is expected to have some form of NOTIFY capability, that
needs to be added to the Guidelines.]

3. If every NOTIFY has to be implemented via the new Notification
operation, then CSTSs that use the NOTIFY only to report the occurrence
of the standard (non-extension) events will have more operational
overhead than the existing SLE services - that is, the requirement to
START and STOP the Notification procedure is more than is required today
for SLE services, in which the NOTIFY is automatically enabled as soon
as the service is bound.

4. If the NOTIFY operation can still be implemented in a CSTS by
extending another procedure by adding a NOTIFY to it, should it be
possible to have both a NOTIFY-extended procedure and a Notification
procedure in the same CSTS? In such an instance, the NOTIFY in the
extended operation and the NOTIFY in the Notification procedure would
both report the standard baseline events, but only the Notification
procedure NOTIFY would report the events identified in the Notification
START operation.

4A. A CSTS could be defined such that the NOTIFY in an extended
procedure could report on more than the standard baseline events, but
those events would have to be identified either as part of the service
definition or as part of the Service Management configuration of that
CSTS. This mode would allow a NOTIFY to be statically configured for the
duration of the service instance.

4B. A single CSTS instance could have multiple instances of the
Notification procedure. Each instance of the Notification procedure
would report the common baseline events, as well as that procedure's
unique events, as identified in the START operation for that procedure
instance. Is there any reason why we would want such a capability? Is
there any reason why we would want to forbid such a capability?

5. Whether the NOTIFY is enabled via a dedicated Notification procedure
or as an extension to another procedure, it will still differ from the
SLE approach to notifications in that for CSTSs notifications are not
automatically enabled upon binding, but must wait for the procedure that
includes the NOTIFY to start. My first thought was that a similar
capability could be provided for a CSTS if the Association procedure for
that CSTS were to be extended with the NOTIFY, but we explicitly forbid
the Association procedure to be extended with additional operations.

I am asking the members of the CSTSWG for opinions on these issues. If
there is already a consensus, then my understanding it will help can in
defining the Notification procedure. Please feel free to respond by
email, and perhaps we can discuss these issues a bit at next week's
CSTSWG telecon.

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