Extending EASE with new ASN.1 encoding rules
Introduction
Estelle [1] is a formal description technique (FDT) developed by ISO, and based on an extended state transition model. Estelle only specifies dynamic behaviours of protocols. It is viewed as a set of extensions to ISO Pascal, level 0, which models a specified system as a hierarchical structure of communicating automata which may run in parallel, and may communicate by exchanging messages and by sharing, in a restricted way, some variables. Abstract Syntax Notation One (ASN.1) [2], developed by ISO, has been widely used for specifying data types and values of communication protocols, more particularly at the application and presentation layers of the ISO reference model. It specifies notations for the definitions of abstract syntaxes, enabling an application information to be defined. A variety of types, from simple types such as integers and bit strings to structured types such as sets and sequences, as well as complex types defined in terms of others, can be defined using ASN.1.
Application layer protocol data units (PDUs) are specified in ASN.1. ASN.1 works in conjunction with basic encoding rules (BERs) [3], which enable representation of data to be interpreted. Any application protocol specification is not complete until it includes PDU type definitions and operations for manipulating, comparing, and assigning ASN.1 values. At present, ASN.1 and encoding/decoding rules, are not supported by Estelle. Hence, two standardised languages are required to specify an application protocol. It is important to note that at present no internationally standardised FDTs, including Estelle, supports protocol specification using ASN.1 notations. Development of an application layer protocol could be a long and error-prone endeavour; and so there is a huge demand for research into more efficient methods for fast implementation of application protocol [4], [5], [6]. The availability of appropriate FDT tools is essential for protocol development; without which, implementation of application protocol is a time-consuming task. In general, FDT and ASN.1 tools have been developed independently and do not support each other. FDT tools currently available worldwide are listed in Ref. [7]; no tool supporting Estelle and ASN.1 specifications simultaneously, was reported.
These prompted us in 1992 to develop a software tool that integrates Estelle and ASN.1 specifications to produce an integrated specification for an application layer protocol, from which an automatic implementation can be generated [8]. The software tool was completed by the end of 1994, and came to be known as EASE (Estelle and ASN.1 software environment) [9]. Despite the fact that EASE is a new tool, it is already outdated because of the recent changes made to ASN.1. The 1994 standard included many changes to ASN.1 syntaxes [10] and additions of encoding rules [11]. Building a complete compiler that supports the full ASN.1:94 standard is a huge task; many researchers and developers only implement a subset of the standard that meets their requirements, and others use tools for building certain stages of such a compiler.
For EASE to keep in line with the new 1994 standard [10], [11], it is a big task and requires a major rewrite; the only two encoding rules that could be added without implementing the full 1994 ASN.1 syntax are the canonical encoding rules (CER) and the distinguished encoding rules (DER). This paper describes how EASE has been extended to include CER and DER. An evaluation of the work done is then presented. Finally, some of the issues involved in building an ASN.1 compiler that complies with the 1994 standard are discussed, in order to provide researchers and developers with some pointers in developing such a compiler.
Section snippets
The 1994 ASN.1 standard
In 1994, the ASN.1 standard was extended in two directions; new constructs were added to the language [10] and new encoding rules [11] were introduced. Until recently, the universal way for encoding ASN.1 values was by means of BER [3]. Several studies have been conducted on the performance of BER [12], [13]. Its efficiency has been criticised, particularly for real-time applications [14]. New encoding rules were introduced: DER [11], CER [11] and packed encoding rules (PER) [11]. These
CER and DER
CER and DER differ from each other in the set of restrictions that they place on BER. BER allows a one-to-many mapping between an ASN.1 value and its encoded representation, while CER and DER allow a one-to-one mapping. CER and DER use subsets of BER encoding; they place a series of constraints on BER. CER is used where there is a need to encode values which are so large such that they cannot be fit into memory. DER is used where the encoding is small enough to fit into memory, and where there
Packed encoding rules
PER is used in circumstances where the major concern is the minimization of the size of encodings. Encoding the tag and the length of each data value causes the greatest overhead of BER. In many cases, the tag and length encodings are redundant and can be dropped. Consider the following ASN.1 type:
Id::=SEQUENCE SIZE (6) OF INTEGER (0..9)
When encoding a value of type Id, it is not necessary to precede each INTEGER value with its tag, because a receiver knows that it is dealing with INTEGER from
Overview of EASE
EASE [9] comprises an Estelle specification library, an ASN.1 translator, an ASN.1 translator run-time library, the pet–dingo compiler [15], [16], and the pet–dingo run-time libraries [15], [16]. Most of the EASE software were written in the C++ programming language [17], except the ASN.1 translator was written in the C language. Fig. 1 depicts the relationship between the different components, user input files and generated output files of EASE.
EASE uses the abstract data type (ADT) approach
Limitations of EASE
EASE suffers from the following limitations:
- •
EASE does not support the full 1994 ASN.1 standard. It only supports ISO 8824-1, and does not support ISO 8824-2, ISO 8824-3 and ISO 8824-4.
- •
It does not support the new encoding rules such as the CER, DER and PER.
- •
It does not handle ASN.1 recursive types.
- •
Sometimes there are naming conflicts of mapped names. Manual intervention is required to include the DINGO generated C++ header files to the ASN.1 compiler generated C++ files and vice-versa.
- •
Some
Implementing the new encoding rules
CER and DER for the simple types: BOOLEAN, BIT STRING, OCTET STRING, Character string and Generalised Time; and the structured types: SEQUENCE, CHOICE, SET, SEQUENCEOF and SET-OF have been implemented. However, it is too lengthy to describe all of them in this paper. Instead, to illustrate the implementation of the encoding rules, one example of a simple type and one example of a structured type are discussed; these are the BIT STRING and the SEQUENCE types, respectively.
BIT STRING
The ASN.1 simple types are mapped to C++ classes for implementation; these C++ classes are implemented in the ASN.1 translator library shown in Fig. 1. Fig. 2 shows part of the BIT STRING C++ class. The value of the BIT STRING is stored in an array of char called barray, its length is stored in the data member blen, while the number of octets in the array barray is stored in bsize. segmentSize is a constant (1000) used for comparing the number of octets required to hold the BIT STRING, to
Encoders for BIT STRING
CER encodes the BIT STRING in two different ways depending on the length of the BIT STRING. The definite length form is used if the encoding of the contents is less or equal to 1000 bytes, otherwise the indefinite length form is used. DER encodes the BIT STRING in only one way, i.e. the definite length form.
Fig. 3 shows the TLV BIT STRING CER encoder member function (CEnc( )). If the number of octets required to hold the BIT STRING exceeds 1000, then it must be encoded as a constructed encoding
Decoders for BIT STRING
The TLV BIT STRING CER decoder shown in Fig. 5 decodes the tag, the length and the contents of the BIT STRING. The tag is first decoded and its validity checked. When CER encodings are decoded, the tag can be expected to be primitive or constructed depending on the length of the BIT STRING. The tag can only be primitive for DER encodings. If the tag is valid, the length and the contents are decoded; otherwise an error is flagged.
Fig. 6, Fig. 7, Fig. 8 show the CER content decoder for the BIT
Sequence
All ASN.1 structured types are encoded using indefinite length encoding by CER and definite length encoding by DER. This applies to the SEQUENCE type encoding and in addition, both CER and DER do not encode the values of the SEQUENCE components having a default value. This example of the implementation of the SEQUENCE type shows that components with default values are not encoded. It also shows the use of standard tags.
The ASN.1 specification for a SEQUENCE type having a component with a
Encoders for SEQUENCE
By default, the ASN.1 compiler produces a V-only encoder/decoder for the ASN.1 structured types; TLV encoders/decoders are only produced for those types with the EHB compiler directive specified before their ASN.1 type definitions as shown in Fig. 9. It is noted that unlike the ASN.1 simple types, the encoders/decoders for the structured types are not member functions of their C++ classes, they are simply defined as non-member C++ functions (these encoders/decoders cannot be inserted as member
Decoders for SEQUENCE
Fig. 14 shows the TLV CER decoder for the SEQUENCE type specified in Fig. 9. The decoder obtains the encoded data and its length by creating a local buffer b, and initializing b with the EncodedPDU parameter. The tag is decoded and checked for validity (i.e. Universal class, Constructed form and Sequence tag code). The length is then decoded, followed by the contents. Error handling is done through the C library routines setjmp( ) and longjmp( ). If an error is encountered during decoding, a
Evaluation of the work
The result of the work done is that EASE can now produce BER, CER and DER encoders/decoders not only for the ASN.1 types, but also for most ASN.1 structured types that have a general purpose usage. This enhances the ability of EASE for automating the implementation of application protocols from their specifications, using any one of the implemented encoding schemes.
Also, the generated BER, CER and DER encoders/decoders can be used (together with the generated C++ classes which implement the
Parsing the ASN.1:94 syntax
The commonly used parser-generator tools such as YACC [20] and BISON [21] cannot be easily used for parsing the ASN.1:94 syntax. An attempt to use BISON produced 537 shift/reduce conflicts and 1347 reduce/reduce conflicts. An example of a shift/reduce conflict occurred when the following ASN.1:94 production rules (abstract description of the ASN.1 syntax) were parsed:
IntegerType→INTEGER;
IntegerType→INTEGER LBRACE NamedNumberList RBRACE;
Conclusions
In 1994, the ASN.1 standard was extended in two directions; new constructs were added to the language and new encoding rules were introduced. The new encoding rules are CER, DER and PER. These new rules were introduced in order to improve the efficiency of encoding ASN.1 values. For EASE to keep in line with the new 1994 standard, it is a big task and requires a major rewrite. The only two encoding rules that could be added to EASE without implementing the full 1994 ASN.1 syntaxes are CER and
Acknowledgements
The pet and dingo software made available to us for this work by the U.S. Department of Commerce, NIST, and the financial support of the Australian Research Council under the grant A49601203 and La Trobe University for this project are hereby acknowledged.
References (23)
- et al.
On tools supporting the use of formal description techniques in protocol development
Computer Networks and ISDN Systems
(1993) - et al.
The pet and dingo tools for deriving distributed implementations from Estelle
Computer Networks and ISDN Systems
(1993) - et al.
High performance ASN.1 compiler
Computer Communications
(1994) - ISO, Information Processing–Open Systems Interconnection—Estelle: A Formal Description Technique Based on an Extended...
- ISO, Information Technology–Open Systems Interconnection—Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC...
- ISO, Information Processing–Open Systems Interconnection—Specification of Basic Encoding Rules for ASN.1, ISO/IEC...
- et al.
Semi-automatic implementation of communication protocols
IEEE Transactions on Software Engineering
(1987) - et al.
- et al.
Semi-automatic implementation of protocols using an Estelle-C compiler
IEEE Transactions on Software Engineering
(1988) - et al.