[Css-csts] CSTS - ASN.1 Updates (A#04-0609)

Fri Jul 17 07:07:31 EDT 2009

Dear Yves,

In order to have the complete set of PDUs that a CSTS user can receive an implementation must include the TransferBuffer into the PDU definitions. I understand that this is not done in the Specification because TRANSFER-BUFFER is not a real operation - and I am not requesting to do that. However, if an implementation wants to do this it cannot use the tag [1] as in BufferedDataDeliveryPdu because that would be in conflict with BindReturn. I would therefore suggest changing the tag for TransferBuffer in BufferedDataDeliveryPdu to 71 (or to include TransferBuffer into CstsFrameworkPdu even if it is not a proper PDU).

Dear Tim,

We are no longer working with the OSS compiler and I do not have code generated by this complier available anymore. I cannot remember what exactly the concept of a PDU number is, but my interpretation is the following: 

With the new module, you should actually get one top-level PDU for CstsFrameworkPdu. Because the PDU definitions for the individual procedures are not contained in CstsFrameworkPdu they look to the compiler as being PDUs as well (they are not contained in anything else). You have the choice to use either the single CstsFrameworkPdu and ignore all others (which is probably the simplest approach) or to use the procedure specific PDU definitions for those procedures used in your service and ignore CstsFrameworkPdu. In the latter case you might have to handle the fact that you might not know to what procedure the received PDU belongs before decoding it.

Kind Regards,
Martin

-----Original Message-----
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: 17 July 2009 00:29
To: Yves.Doat at esa.int; css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] CSTS - ASN.1 Updates (A#04-0609)

Dear Yves,

Thanks for updating the ASN.1 definitions so that there is a single top-level structure (CstsFrameworkPdu).  

In trying to use the new ASN.1 definitions, I ran into a problem with my "reusable" C source code that encodes abstract messages.  Perhaps the problem is due to my lack of understanding of how ASN.1 works and will go away as I look into it.  Because of the long delays in working across the Atlantic, I would like to mention the problem and see if anyone in our group may be able to provide a comment:

My "reusable" code assumes that all outgoing PDUs will have the same pdu-number (i.e. a top-level pdu-number).  But the C source code that is auto-generated by the OSS ASN.1 compiler doesn't appear to do that.  Instead, many different #define are produced -- E.g. "#define AssociationPdu_PDU 1" and "#define BuffDataDeliveryPdu_PDU 8".

At this point, I still find a specification that incorporates ASN.1 to be more confusing than a specification that shows pictures of the bit formats.  The bit formats can be tedious, but there is no question about what the software is supposed to generate.  I can't say the same for ASN.1 (at least, not yet). 

Best regards,
Tim

-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Yves.Doat at esa.int
Sent: Thursday, July 16, 2009 3:41 AM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] CSTS - ASN.1 Updates (A#04-0609)

Dear all,

I uploaded to the CCSDS Web Site the text file of the new ASN.1 (Syntax
checked) in the directory: "CSS-CSTS/CWE Private/ CSTS Framework an Concept"
with the name: "CSTS asn1 0.20 20090716".

The main change is related to the definition of one CstsFrameworkPdu module (the last one in the ASN.1).
This new module imports all CSTS PDUs defined in the Framework and builds this new PDU.
With this approach you will noticed:
   All PDUs visible in one place;
   Decoding should be eased as it's now concentrated as per the developer
   request;
   Tagging of PDU is now concentrated in a single place and is easier to
   understand.
   The procedure allowed PDUs are now defined in the procedure modules by
   means of subtyping of the main PDU (using "WITH COMPONENTS" feature).
   Note: Considering that it is the first time I use this subtyping, I would
   appreciate if developers could give me feed back.

You will find below the answers to the comments/questions from Martin and Tim with my answers.

I have not yet produced the draft 0.20 of the Framework and I would appreciate to get your ASN.1 comments before I proceed.

Best regards
Yves Doat

================================================
20090606 - Mail from M.Goetzelmann:
(1) The PDU NotifyInvocation is missing in the structure UnbufferedDataDeliveryPdu
YD> The Unbuffered Data Delivery procedure does not have a notification
capability.

(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.
 YD> Removed

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

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.

YD> Considering that in the main part of the document we considered the
Association procedure as a special case, the ASN.1 definition does not follow the same structure as the other procedures.
YD> The tagging is now concentrated in the "CSTS Protocol Data Unit" 
YD> (section
D.2.13). No additional change.

(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.
 YD> The tagging is now concentrated in the "CSTS Protocol Data Unit"
(section D.2.13) and reallocation will be very easy. We can discuss and I am open to any change. See new proposed tagging.

(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.
YD> originally I splitted the incoming and outgoing. It turned out that 
YD> we
ended with many small modules. This points was discussed and it was agreed not to differentiate. No change.

(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
YD> Please have a look to the proposed approach which is based on 
YD> subtyping
of the main PDU for the procedure PDUs.

=============================================
20090701 - Mail from T.Ray
Are there two typos on the second page of the Framework ASN.1 version 0.19?
There are two object identifiers whose names are "protoIdentifiers" and "servicesIdentifiers".  I think their definitions should be extensions of the OBJECT IDENTIFIER "services" rather than "framework".  i.e. {framework 1} and {framework 2} are already used previously; I think you intended to say {services 1} and {services 2} instead.
YD> Corrected

_______________________________________________
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

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