[Css-csts] multiple instances of BDD procedure

[Martin Götzelmann]

Dear John,
 
Your observation is of course completely correct but I think this true in general in that all specifications for all procedures are only applicable to a single instance of that procedure. For instance, in the Data Processing Procedure all statements concerning sequence control and sequence preservation of operation invocations apply to a single procedure instance only. 
 
If a service allows more than one procedure instance then I think the service designer needs to specify whether there is a need to coordinate the instances and if so, how this is done. I feel this issue is comparable to case of FSP where the specification allows several service instances but then defines how the data from different services are multiplexed and how service provisioning may be controlled by a (single) service instance with "directive invocation capability". While sequence preservation is enforced for a single service instance it is not for the complete set of instances feeding a single FSP production engine. Maybe that is something the guidelines should address.
 
I think that approach should also be applied to the definition of management parameters. If a service allows multiple procedure instances, it should specify how management parameters have to be dealt with. For some services a single set applicable to all procedure instances my be the obvious approach while for others specification per procedure instance might be more appropriate. I think the MD CSTS has taken yet another approach in that management parameters (e.g. parameters, parameter lists, etc) are defined at service level but then the set that applies to a given procedure instance is selected in the START invocation. At runtime, therefore, the parameters in-effect might actually be specific to a procedure instance.
 
My understanding has always been that the Service Instance in the FW view is only a container for the procedure instances and as such I think it has to be talked about. With the possible exception of association control, I did not have the feeling that the FW intends to say anything about the service level behaviour, but I have not re-read the text. Maybe one can add more words in the introductory sections to further clarify this (maybe even under scope)?
 
Kind Regards,
Martin
 
 
________________________________

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 02 February 2011 21:43
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] multiple instances of BDD procedure



CSTSWG colleagues ---

When I have read through the Buffered Data Delivery (BDD) definition in the past, I have tended to think in terms of a single BDD instance per service instance. Of course, however, it is possible to have multiple instances of any procedure (including BDD) in a service. Reading through the BDD specification with this in mind exposes some issues.

 

The first issue involves sequence preservation. The statement "it is ensured that data units and notifications are always delivered without discarding data" is true for a single BDD instance, but not necessarily for a service that uses multiple instance of BDD. As an example, consider a CSTS version of RCF that allows the user to select multiple VCs by allowing separate BDD instances per VC. For this example, assume that VC1 generates 10 frames for every frame in VC0: i.e., VC1 has a frame at T0, T1, T2, etc., and VC0 has a frame at T0, T10, etc.  Also assume that both BD instances have transfer buffers of size 3 and latency limits sufficiently long to allow the VC0-instance transfer buffer to fill before the release timeout (i.e., 30 time units). Clearly, the VC0 frames for T0 and T10 will be delivered after the VC1 frames for T0 through T27. So while sequence preservation can be guaranteed within the transfer associated with a single BDD procedure instance, it can't be guaranteed across the whole service instance. 

 

Understanding that this behavior is on a per-procedure instance basis is clouded by the "Service Provider" terminology that is used throughout the FW. Use of this term makes it ambiguous as to whether the requirement applies  to the particular procedure instance or across the service. 

 

The above example also introduces the second issue - are the managed parameters for a procedure to be specified on a per-instance basis, are they common across all instances of a service instances, or is there a mix? I would guess that all BDD instances would be either real-time of complete, but should each BDD instance be able to have its own transfer buffer size or latency limit? The simple answer is to make all procedure instances use the same managed parameter values, but I think that it is worth asking the question (and making clear in the FW whatever we decide is the answer).

 

Best regards,
John  


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20110207/939752d6/attachment.htm