[Css-csts] RE: Framework ASN.1

Wed Jun 10 10:51:39 EDT 2009

Dear Martin,

Thanks for your helpful response.  At first I was still confused (due to my lack of understanding of ASN.1).  It took me a while (and some help from John Pietras) to realize that "there is no TLV associated with the CHOICE construct itself" (quoted from page 318 of the book "ASN.1 Complete").  Again, thanks!  

Best regards,
Tim

-----Original Message-----
From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de] 
Sent: Saturday, June 06, 2009 2:33 PM
To: Ray, Timothy J. (GSFC-5830); css-csts at mailman.ccsds.org
Cc: Christian Laroque; Martin Karch
Subject: RE: [Css-csts] RE: Framework ASN.1

Dear Tim,

The ASN.1 specification in the SLE books is formulated under the assumption that an implementation would support a single service either as user or as provider, Based on this assumption the specification included two top level structures to list all PDUs sent from the user to the provider ("incoming PDUs") and from the provider to the user "outgoing PDUs". 

This assumption was obviously true in your case, i.e. implementation of a CLTU user application, but was not  suitable for all implementations. If you wanted to implement a provider application that supports more than one service you already could not use this  specification without modification because the service requested can only be known after decoding the BIND PDU. It was therefore necessary to modify the ASN.1 specifications for the specific implementation by defining a top level structure BindPdu in addition to the service specific top level PDUs and removing the BIND PDU from the service specific PDUs. On a new TCP connection, the BindPdu structure had to be applied for the first message and for all following messages the service specific structure selected by the service and version number specification in the BIND invocation had to be used. Such modifications of the ASN.1 specification are compatible with the standard because they have no impact on the data travelling on the wire.

You can apply the same approach to add a top level PDU specification suitable for your implementation. There are several ways in which this can be done:

If you want to support only a single service (e.g. the dummy service) you could provide a new ASN.1 module "DummyServicePDUs", import the structures AssociationPdu and BufferedDataDeliveryPdu, and specify a top level structure 

DummyServicePdu ::= CHOICE { 
    associationPDU              AssociationPdu
,   bufferedDataDeliveryPdu  BufferedDataDeliveryPdu
}

The above structure contains both incoming and outgoing PDUs for the user, which does no harm but generates more ASN.1 handling code than necessary. To avoid that you could alternatively import the necessary PDUs from the module CCSDS-CSTS-COMMON-OPERATIONS-PDUS and define a structure as

DummyServiceUserIncommingPdu ::= CHOICE { 
  associationPDU   AssociationPdu
, startReturn          StartReturn

, stopReturn          StopReturn

, transferBuffer       TransferBuffer

, notifyInvocation    NotifyInvocation

}

This structure still contains all association control PDUs - to avoid this, the current ASN.1 specification would have to be changed (see note 4).

You could also create a general top level PDU that can be used for any service by including all common operation invocations and returns (optionally only those received by the user) into the CHOICE. In that case an incoming PDU that is not supported by any of the procedures in the service would not result in a decoding error. The fact that such a PDU is not permissible would have to be detected by the state machine(s).

And there are more options.

Whatever option you apply,  there is of course one important difference to ASN.1 processing for SLE services. If you use the OSS compiler, for CLTU you would call the decode function for the top level ASN.1 structure and that function would decode everything. Now it will only decode the common operations part. For each extension you will have to call the decode function providing a reference to the top level structure to use. This top level type specification can be identified using the object identifier in the EMBEDDED PDV type.

Notes/Comments on the Current ASN.1 Specification (Framework Issue 0.19)

The following comments and considerations concerning the ASN.1 modules in the Framework specification 0.19 have been triggered by your question:

(1) The PDU NotifyInvocation is missing in the structure UnbufferedDataDeliveryPdu 

(2)  In the structure UnbufferedDataDeliveryPdu the individual PDUs are re-tagged. This is not done for the other procedures and I believe this is not intentional.

(3) The type AssociationPdu should be exported such that it can be included into a general PDU specification type.

The following points are for further discussion - I do not intend to recommend a specific approach:

(4) The current specification of the association control procedure types differs from the specification of other procedures. The association control operations are not specified in the common operations module and imported but in the association control module. Furthermore the PDU tags are not defined at top level but only within the structure AssociationPdu. 

For the SLE service specifications separate handling of the Bind types was essential as these were the only ones for which communality between services was guaranteed. Special handling for the framework can still be justified because of the special role of association control but because all common operations are common, one could also justify handling all common operations and all common procedures in the same way. That would be more in line with the main part of the specification.

Independent of that decision, tagging association control PDUs on top level would allow implementations to include them individually into PDU specifications (see above) without re-specifying the tags. 

(5) The SLE specifications used tags above 100 for the association control PDUs in order to reserve the tags below 100 for service specific PDUs. This does not seem to be necessary for the Framework - tagging of association control PDUs could be aligned with other common operations.   

(6) Splitting of the PDU specification types into "incoming PDUs" and "outgoing PDUs" would allow implementations of provider and user applications to restrict top level PDUs for encoding and decoding to those really needed for the provider or for the user. Personally I do not consider this very important as the only drawback of using types with all PDUs is that ASN.1 compilers would generate more code than needed.

(7) If we want to include a type specification that could be used by all implementations, we could add a type definition CstsFrameworkPdus, that contains a choice of all common operation invocations, returns, and acknowledgements. As noted above, the implication of using such a structure would be that an invalid incoming PDU for a given service would not result in a decoding error but would have to be detected by the implementation of the pertinent state machine(s).    

Kind Regards, Martin  

________________________________

From: css-csts-bounces at mailman.ccsds.org on behalf of Ray, Timothy J. (GSFC-5830)
Sent: Fri 05/06/2009 11:06 PM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] RE: Framework ASN.1

Dear WG members,

Here's another attempt to describe my problem - what is the first step to take to decode an incoming encoded protocol message?  Tcp will bring in a stream of octets.  The Transport Mapping Layer will deliver a group of octets that are known to be an encoded protocol message.  Then what?

Best regards,

Tim 

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Ray, Timothy J. (GSFC-5830)
Sent: Thursday, June 04, 2009 6:27 PM
To: Yves.Doat at esa.int
Cc: css-csts at mailman.ccsds.org
Subject: [Css-csts] Framework ASN.1

Hi Yves,

When implementing the Forward CLTU Service, all incoming messages were decoded into a single top-level C structure (the OSS tool called it 'CltuVersion1Pdu').  

In trying to work with the Framework ASN.1, I can't find an analogous single top-level structure (there are multiple top-level structures - e.g. AssociationPdu, InformationQueryPdu, ThrowEventPdu, DataProcessingPdu, etc).     I suspect that the answer is "each service must define additional ASN.1 (that will provide this top-level structure)".  If so, we will have to define service-level ASN.1 for our inter-operability testing (as far as I know, this hasn't been done yet). 

Best regards,

Tim

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