1. E.1 What is ASN.1?

ASN.1 is the acronym for Abstract Syntax Notation One, a language for describing structured information; typically, information intended to be conveyed across some interface or communication medium. ASN.1 has been standardized internationally. It is widely used in the specification of communication protocols.

Prior to ASN.1, information to be conveyed in communication protocols was typically specified by ascribing meanings to particular bits and bytes in protocol messages, much as programmers, before the advent of high level languages, had to deal with the bits and bytes of storage layout.

With ASN.1, the protocol designer can view and describe the relevant information and its structure at a high level and need not be unduly concerned with how it is represented while in transit .Compilers can provide run-time code to convert an instance of user or protocol information to bits on the line.

ASN.1 comes into its own when the information being described is complex. This is because the language allows arbitrarily complex structures to be built up in a uniform way from simpler components, and ultimately from a few simple information types. ASN.1 is, in effect, a data definition language, allowing a designer to define the parameters in a protocol data unit without concern as to how they are encoded for transmission. He merely states a need for an Integer followed by text, followed by a floating point number, etc. They can be named and tagged such that two integers can be differentiated as meaning "file size" or "record number", for example.

Given any ASN.1 description of a message, a representation can be derived mechanically by applying a set of encoding rules. While many such sets could be imagined, initially only a single set, the Basic Encoding Rules (BER), were standardized as a companion standard to ASN.1 itself. Subsequently two subsets of the basic rules have been approved. These are the Canonical and the Distinguished Encoding Rules. These are exact subsets of the BER, but where it has choices the subsets restrict these to a single possible encoding. In addition, a completely new set of encoding rules has been devised in response to the criticism that BER is highly inefficient, e.g., three bytes to encode a boolean. These are called the packed encoding rules

The "One" was added to the ASN name by ISO to leave open the future possibility of a better language for expressing abstract syntaxes. However, an "ASN.2", should it ever be considered necessary, will have to be significantly more powerful than ASN.1 to be worth inventing.

1. E.1.1 Abstract Syntax

To illustrate the concept of abstract syntax consider, for example, ameteorological station, which reports on the prevailing atmospheric conditions to a monitoring centre. At the monitoring centre, the information is input to a weather forecasting program.

With abstract syntax the concern is solely with the information conveyed between the application program running in the computer at the weather station and the application program running in the computer at the monitoring centre.

For different reasons, both programs need to "know" what information is included in a report. The application in the weather station needs to know so that it can create reports from the appropriate sensor readings. The application in the centre needs to know because it must be able to analyze reports and make weather forecasts.

This knowledge, which is essential for the programs to be written, is that of the abstract syntax; the set of all possible (distinct) reports. The designer of the abstract syntax also defines the meaning of each possible report, and this allows the developers of the programs at each end to implement the appropriate actions.

It would be very unusual for a designer to define the abstract syntax of a message type by explicitly listing all possible messages. This is because any realistic message type will allow an infinite number of distinct possibilities, integer as a simple example of this. Instead, the abstract syntax will generally be structured. The set of possible messages and their meanings can then be inferred from knowledge of the possibilities for each of the components of the structure.

Using ASN.1 (Abstract Syntax Notation 1): A Data Description Language*

Abstract Syntax Notation 1 (ASN.1) is used to describe the structure of data to be transferred between the Application Layer and the Presentation Layer of the Open Systems Interconnection (OSI) (next generation networking protocol).

ASN.1 is meant to provide a mechanism whereby the Presentation Layer can use a single standard encoding to reliably exchange any arbitrary data structure with other computer systems, while the Application Layer can map the standard encoding into any type of representation or language that is appropriate for the end user. ASN.1 does not describe the content, meaning, or structure of the data, only the way in which it is specified and encoded.

These properties make it an excellent choice for a standard way of encoding scientific data. Since ASN.1 does not specify content, specifications can be created as new concepts need to be represented. As it is an International Standards Organization (ISO) standard, the new specification can take advantage of various tools built to work with ASN.1 in general. It removes from scientists the role of specifying ad hoc file formats, and focuses them instead on specifying the content and structure of data necessary to convey scientific meaning.

Data Specification

There are two aspects to ASN.1--the specification of the data and the encoded data itself. The specification describes the abstract structure of the data and the allowed values various fields may take. Frequently scientific data is presented with no formal specification. There may be some documentation describing the data file, but very often it is incomplete or not entirely accurate, since it is usually written about the file rather than as a integral step toward building the file.

The ASN.1 specification is formal language, which means it can be automatically and thoroughly checked for errors and inconsistencies in form by machine before any data is collected.

Further, it can be used by a computer to validate that any data presented correctly reflects that specification. This is essential in eliminating the random errors and oversights in generating data files that plague scientific data now.

A utility program, AsnTool, was built at NCBI with the AsnTool libraries to do this sort of checking and validation while developing ASN.1 specifications. (For information on obtaining AsnTool, see the end of the article.)

The requirement for a separate specification also means that interested parties can examine and evaluate the structure of the data independent of any particular database or data file. One can understand the limits and strengths of a specification separately from the quality or amount of the data itself. Data structures that prove to be useful can be re-used in a variety of ways--by large public databases, by small private databases, in various software tools, and in assorted data files.

Finally, a separate specification means software to construct, decode, and validate any AS.1 specified object can be built fully or semi-automatically from the specification. Data encoded according to that specification can then be processed with relatively little manual programming for those aspects of the application dealing directly with ASN.1. This is the purpose of the AsnTool routines.

Commercial Tools

A number of commercial and public domain tools are available for working with ASN.1 and for automatically building data handlers of various sorts. They are focused on the use for which ASN.1 was originally intended, the exchange of data between layers of the OSI. As such they tend to automate the process more that AsnTool does, because the domain of use is more limited. The fact that they determine the internal data structures to use and write all the code to handle them themselves is not a big problem in this case.

When ASN.1 is used for scientific data description, however, other uses will be made of the encoded data than may have originally been envisaged by the designers of these products. For example, a scientist will often want an application which scans through a large complicated data structure and extracts certain fields for use, or even just counts occurrences of certain values. A tool that automatically generates large elaborate data structures and lots of code to parse the stream, generate the structures, and store them in memory is inappropriate for such an application. Further, a scientific application may well wish to manipulate that data in a different language than the tool is written in, such as FORTRAN, PROLOG, or LISP. These applications may well wish to store the whole data structure from the stream, but they will not wish to use the data structure provided by the tool.

Encoding

ASN.1 can be used to encode data in two ways, an ASCII human readable form called "value notation" or "print form," a binary encoding. ASN.1 has separate standards documents for the syntax (specification rules) and the binary encoding rules (BER, or "Basic Encoding Rules"). This was done on purpose to allow various encoding rules for the same abstract syntax. The BER is, at this writing, the only official ISO encoding for ASN.1, but several other encodings which are faster or take less space, are under consideration by ISO. Currently the only binary encoding AsnTool supports is BER.

The value notation, or ASCII form of the data, is not really an official ISO standard. It was meant to provide a human readable form of ASN.1 data for development or explication, but not as a standard for data exchange. Nonetheless, value notation is quite robust for data exchange. These rules are listed in appendix 1.

While we do not recommend the ASCII form of ASN.1 encoded data for large amounts of data, it is useful for developing and testing data representations or for easily generating ASN.1 values from other data files or local databases without specialized tools. Since the value notation and binary encoded forms of data are completely and reliably interconvertible using AsnTool, there is no problem doing this.

ASN1

Abstract Syntax Notation One (ASN.1) is a standardized notation used for describing the data structures carried by messages exchanged between communicating parts. It is developed and maintained by ITU-T as ITU-T X.680 to X.683 (ISO/IEC 8824-1 to 4).

ASN.1 is a mature notation with a long record of reliability and interoperability. It supports the exchange of information in any form (audio, video, data.); it has full and direct support of international alphabets. ASN.1 is well integrated with other standardized languages and notations such as SDL and TTCN.

Although ASN.1 is used in applications as diverse as parcel tracking, power distribution and biomedicine, its most extensive use continues to be in telecommunications. Examples of its use include protocol standards for Intelligent networks, UMTS^TM, Voice over IP, Interactive television and HiperAccess.

1. ASN.1 Abstract and Concrete Syntax

ASN.1 has an abstract syntax as defined in the ITU-T X.680 series of recommendations, and has several alternative concrete syntaxes as defined in the ITU-T X.690 series. The abstract syntax is the form that would normally appear in a protocol standard and is used to describe Protocol Data Units (PDU) and other data structures at the level of human readability. The concrete syntax defines the specific set of encoding rules used in an implementation to convert the abstract form to the actual stream of bits that is sent over a communication media. Typical encoding rules are Basic Encoding Rules (BER) and Packed Encoding Rules (PER).

The separation between abstract and concrete syntax brings substantial benefits during protocol standard development. Full attention is initially given to the semantics of data, their relations and their range or size limits, while details of concrete syntax are deferred for later consideration.

2. ASN.1 Extensibility

An advantage of ASN.1 is that it offers concepts that support extensibility of protocol data structures. That in turn allows older and newer versions of protocols to interwork. This feature is lacking in many other data description notations, despite being essential to any system which is expected to survive for some time.

3. ASN.1 Benefits for Protocol Testing

Tools are available to translate ASN.1 specifications into over 150 programming languages including C, C++, and Java. Since ASN.1 specifications can be checked by tools, this approach is in all aspects superior to the traditional way of specifying bit tables.

Most protocol standards in ETSI are accompanied by related test specifications. ASN.1 data definitions can be directly imported into test suites written in TTCN. This speeds up test suite development, but more importantly it aids the implementation of actual test tools.