Abstract Syntax Notation One

From Wikipedia, the free encyclopedia

You have new messages (last change).

In telecommunications and computer networking, Abstract Syntax Notation One (ASN.1) is a standard and flexible notation that describes data structures for representing, encoding, transmitting, and decoding data. It provides a set of formal rules for describing the structure of objects that are independent of machine-specific encoding techniques and is a precise, formal notation that removes ambiguities.

ASN.1 is a joint ISO and ITU-T standard, originally defined in 1984 as part of CCITT X.409:1984. ASN.1 moved to its own standard, X.208, in 1988 due to wide applicability. The substantially revised 1995 version is covered by the X.680 series.

Contents

[edit] ASN.1 in transfer

ASN.1 defines the abstract syntax of information but does not restrict the way the information is encoded. Various ASN.1 encoding rules provide the transfer syntax (a concrete representation) of the data values whose abstract syntax is described in ASN.1.

The standard ASN.1 encoding rules include:

ASN.1 together with specific ASN.1 encoding rules facilitates the exchange of structured data especially between application programs over networks by describing data structures in a way that is independent of machine architecture and implementation language.

Application layer protocols such as X.400 electronic mail, X.500 and LDAP directory services, H.323 (VoIP) and SNMP use ASN.1 to describe the PDUs they exchange. It is also extensively used in the Access and Non-Access Strata of UMTS. There are many other application domains of ASN.1 [1].

[edit] Example

Data structures of FooProtocol defined using the ASN.1 notation:

FooProtocol DEFINITIONS ::= BEGIN

    FooQuestion ::= SEQUENCE {
        trackingNumber INTEGER,
        question       VisibleString
    }

    FooAnswer ::= SEQUENCE {
        questionNumber INTEGER,
        answer         BOOLEAN
    }

END

This could be a specification published by creators of Foo protocol. ASN.1 does not define conversation flows, this is up to the textual description of the protocol. Additionally a specification should define which encoding rules are used for the protocol, e.g. BER, DER, PER, XER, etc.

Let's assume you want to encode a message to a string of bits/octets and send it through the network. Our message (PDU) is:

myQuestion FooQuestion ::= { 
    trackingNumber     5, 
    question           "Anybody there?" 
}

[edit] Example encoded in DER

This particular data structure encoded in the DER format (hence tag-length-value triplets):

30 -- tag indicating SEQUENCE
13 -- length in octets

02 -- tag indicating INTEGER
01 -- length in octets
05 -- value

1a -- tag indicating VisibleString
0e -- length in octets
41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f -- value ("Anybody there?" in ASCII)

So what you actually get in the end is the string of 21 octets:

30 13 02 01 05 1a 0e 41  6e 79 62 6f 64 79 20 74  68 65 72 65 3f

[edit] Example encoded in XER

Alternatively, the ASN.1 data structure represented in XER would look like:

<FooQuestion>
    <trackingNumber>5</trackingNumber>
    <question>Anybody there?</question>
</FooQuestion>

[edit] Example encoded in PER (unaligned)

Alternatively, if Packed Encoding Rules are employed, the following 122 bits (less than 16 octets) will be produced:

01 05 0e 83 bb ce 2d f9  3c a0 e9 a3 2f 2c af c0

(Compare that with 108 bytes of XER encoding above)

[edit] ASN.1 versus other data structure definition schemes

As commonly used for defining messages for communication protocols, ASN.1, with its associated encoding rules, results in a binary encoding.

Other communication protocols, such as Internet protocols HTTP and SMTP, define messages using text tags and values, sometimes based on the Augmented Backus-Naur form (ABNF) notation. The definition also defines the encoding, which is in text.

There has been much debate over the two approaches, and both have their merits; the ASN.1 approach is believed to be more efficient, and with Packed Encoding Rules, certainly provides a more compact encoding. The textual approach is claimed to be easier to implement (through creation and parsing of text strings) and easier to debug, as one can simply read an encoded message. In the case of the Megaco protocol, consensus between the two points of view was not reached and so two encodings, one based on ASN.1 and one on ABNF, were defined.

The ASN.1 XML Encoding Rules (XER) attempts to bridge the gap by providing a textual encoding of data structures defined using ASN.1 notation. Generic String Encoding Rules were also defined for the sole purpose of presenting and inputting data to/from a user.

[edit] Using ASN.1 in practice

One may use an ASN compiler which takes as input an ASN.1 specification and generates computer code (for example in the C programming language) for an equivalent representation of the data structures. This computer code, together with supplied run-time libraries, can then convert encoded data structures to and from the computer language representation. Alternatively, one can manually write encoding and decoding routines.

[edit] Standards

Standards describing the ASN.1 notation (free download from the ITU-T website):

  • ITU-T Rec. X.680 | ISO/IEC 8824-1
  • ITU-T Rec. X.681 | ISO/IEC 8824-2
  • ITU-T Rec. X.682 | ISO/IEC 8824-3
  • ITU-T Rec. X.683 | ISO/IEC 8824-4

Standards describing the ASN.1 encoding rules (free download from the ITU-T website):

  • ITU-T Rec. X.690 | ISO/IEC 8825-1 (BER, CER and DER)
  • ITU-T Rec. X.691 | ISO/IEC 8825-2 (PER)
  • ITU-T Rec. X.693 | ISO/IEC 8825-4 (XER)
  • ITU-T Rec. X.694 | ISO/IEC 8825-5 (XSD mapping)
  • RFC 3641 (GSER)

[edit] See also

[edit] References

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.

[edit] External links

Retrieved from "http://en.wikipedia.org../../../a/b/s/Abstract_Syntax_Notation_One_3262.html"