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

Mon Jul 27 11:12:15 EDT 2009

Dear Martin,

Thanks very much for spelling this out for me.

Best regards,
Tim

-----Original Message-----
From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
Sent: Sunday, July 19, 2009 9:05 AM
To: Ray, Timothy J. (GSFC-5830); Yves.Doat at esa.int
Cc: css-csts at mailman.ccsds.org; Martin Karch
Subject: RE: [Css-csts] CSTS - ASN.1 Updates (A#04-0609)

Dear Tim,

What I was referring to is the tagging approach in ASN.1 encoding which can be IMPLICIT or EXPLICIT. If you look at the start of the modules you will see the line "IMPLICIT TAGS" which specifies that implicit tagging shall be used. The implicit tagging approach results in compacter code in that it avoids tags where they are not necessary to ensure that the encoding is unambiguous.

With IMPLICIT tagging enabled, the encoding of the CHOICE type does not have a tag of its own (even if you enter the tag in the specification) - what is transmitted is just the selected choice. This is different if you enable EXPLICIT tagging, which instructs the encoder to include all tags specified. In that case all tags would be encoded, e.g. the choice of StartInvocation in BufferedDataDeliveryPdu would be tagged as

[0] <length1> [10] <length2> <value of StartInvocation>

With IMPLICIT tagging the same would be transmitted as

[10] <length2> <value of StartInvoocation>

This is only one part of the story - you must not neglect the clause WITH COMPONENTS in the specification. This clause constraints the components of CstsFrameworkPdu that can be used within BufferedDataDeliveryPdu to the ones identified in the bracket, i.e.  StartInvocation,  StartReturn,  StopInvocation, and StopReturn. This implies that BindInvocation and BindReturn cannot be used within BufferedDataDeliveryPdu.

Ambiguities would only exist if we had IMPLICIT tagging and use of the type CstsFrameworkPdu in BufferedDataDeliveryPdu would be unconstrained. However, in this case only the tag [1] would be ambiguos because [0] would always mean BindInvocation. The option of EXPLICIT tagging exists in order to resolve such situation - but in the current specification this is not necessary because the clause WITH COMPONENTS.

Regards, Martin
________________________________

From: Ray, Timothy J. (GSFC-5830) [mailto:timothy.j.ray at nasa.gov]
Sent: Fri 17/07/2009 9:32 PM
To: Martin Götzelmann; Yves.Doat at esa.int
Cc: css-csts at mailman.ccsds.org; Martin Karch
Subject: RE: [Css-csts] CSTS - ASN.1 Updates (A#04-0609)

Dear Martin,

Thanks for trying to help me.  Unfortunately, I'm still confused.

Here is the definition of BufferedDataDeliveryPdu from version 0.20 of the Framework ASN.1:

BufferedDataDeliveryPdu         ::=     CHOICE
{       cstsPdu         [0]     CstsFrameworkPdu (WITH COMPONENTS
{       startInvocation
       ,        startReturn
       ,        stopInvocation
       ,        stopReturn
       })
,       transferBuffer  [1]     TransferBuffer
}

According to my understanding of ASN.1, there are two explicit tag numbers specified in this definition -- [0] and [1].

Meanwhile, all PDUs other than BufferedDataDeliveryPdu are equivalent to CstsFrameworkPdu.  Here is the definition of CstsFrameworkPdu from version 0.20 of the Framework ASN.1:

CstsFrameworkPdu                                ::=     CHOICE
{       bindInvocation                  [0]     BindInvocation
,       bindReturn                              [1]     BindReturn
,       unbindInvocation                        [2]     UnbindInvocation
,       unbindReturn                    [3]     UnbindReturn
,       peerAbortInvocation             [4]     PeerAbortInvocation
,       startInvocation                 [10]    StartInvocation
,       startReturn                             [11]    StartReturn
,       stopInvocation                  [20]    StopInvocation
,       stopReturn                              [21]    StopReturn
,       executeDirectiveInvocation      [30]    ExecuteDirectiveInvocation
,       executeDirectiveAcknowledge     [31]    ExecuteDirectiveAcknowledge
,       executeDirectiveReturn          [32]    ExecuteDirectiveReturn
,       getInvocation                   [40]    GetInvocation
,       getReturn                               [41]    GetReturn
,       notifyInvocation                        [50]    NotifyInvocation
,       processDataInvocation           [60]    ProcessDataInvocation
,       processDataReturn               [61]    ProcessDataReturn
,       transferDataInvocation          [70]    TransferDataInvocation
}

It also specifies explicit tags, and the values [0] and [1] have different meanings here.

So, an incoming message that starts with a tag of [0] or [1] would seem to be ambiguous.

Dear Yves,

Although we had a goal of changing the ASN.1 specification so that there is only one top-level pdu structure, it seems that we have two top-level pdu structures (BufferedDataDeliveryPdu and CstsFrameworkPdu).  To solve this problem, I vote for the second option suggested by Martin in a previous email:
"(or to include TransferBuffer into CstsFrameworkPdu even if it is not a proper PDU)."

Best regards,
Tim

-----Original Message-----
From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
Sent: Friday, July 17, 2009 10:34 AM
To: Ray, Timothy J. (GSFC-5830); Yves.Doat at esa.int
Cc: css-csts at mailman.ccsds.org; Martin Karch
Subject: RE: [Css-csts] CSTS - ASN.1 Updates (A#04-0609)

Dear Tim,

The tag [1] in BufferedDataDeliveryPdu is actually not ambiguous and the tag [0] is not ambiguous either. This is because
(1) a CHOICE is a special case in that it does not have a tag value itself (unless EXPICIT TAGGING is specified) and the value transmitted on the wire is ONLY tagged by the tag of the selected choice, and
(2) the clause "WITH COMPONENTS" constrains the type BufferedDataDeliveryPdu to the choices identified, i.e. startInvocation, startReturn, stopInvocation, and stopReturn.

After expanding everything and considering that the CHOICE does not have a tag value in the encoding, the possible choice values in BufferedDataDeliveryPdu that can be transmitted on the wire are:
[10] StartInvocation,
[11] StartReturn,
[20] StopInvocation,
[21] StopReturn,
[1]  TransferBuffer.

The point I wanted to raise is that you cannot use the tag [1] if you want to include TransferBuffer into the type CstsFrameworkPdu, which you will have to do if you want to use a single top level PDU for everything because the tag [1] would not be unique within the scope of CstsFrameworkPdu. On the other hand you cannot just select another tag value because if another implementation uses the specification in BufferedDataDeliveryPdu the TransferBuffer invocation would have the tag [1].

Sorry for being not clear enough.

Regards, Martin

-----Original Message-----
From: Ray, Timothy J. (GSFC-5830) [mailto:timothy.j.ray at nasa.gov]
Sent: 17 July 2009 16:06
To: Martin Götzelmann; Yves.Doat at esa.int
Cc: css-csts at mailman.ccsds.org; Martin Karch
Subject: RE: [Css-csts] CSTS - ASN.1 Updates (A#04-0609)

Dear Martin,

If the tag [1] is currently ambiguous (it can mean either 'TransferBuffer' or 'BindReturn'), then is the tag [0] also ambiguous (it can mean either 'CstsFrameworkPdu' or 'BindInvocation')?

Best regards,
Tim

-----Original Message-----
From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
Sent: Friday, July 17, 2009 7:08 AM
To: Yves.Doat at esa.int; Ray, Timothy J. (GSFC-5830)
Cc: css-csts at mailman.ccsds.org; Martin Karch
Subject: RE: [Css-csts] CSTS - ASN.1 Updates (A#04-0609)

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 ______________________________________________________________________

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