Professional Documents
Culture Documents
1 97
COLIN WILLCOCK
ASN.1 is an established formal notation for defining data structures and message formats.
The new versions of this language standardised in 1994 and 1997 includes a number of
powerful new constructs, which improve and extend the existing notation. This paper pro-
vides an overview of basic ASN.1 notation, and provides a tutorial introduction to the new
features.
62 Telektronikk 4.2000
Box 1 Language Basics
ASN.1 provides the ability to specify both type and value definitions, these are referred to as type notation and value notation respec-
tively. These types and values can be either simple, based directly on the existing ASN.1 built-in types, or be structured, using the
ASN.1 constructors.
• Example of simple value definitions using either built-in types or the defined types above are:
elephantsInTheRoom INTEGER ::= 0 -- using builtin type INTEGER
elephantsOutside NumberOfElephants ::= 10 -- using simple user defined type NumberOfElephants
rainingNow RainInBochum ::= TRUE -- unfortunately almost always true
stateOfJens StudentState ::= tipsy -- enumerated value
heightOfIna ExactHeight ::= {mantissa 16, base 10, exponent 1} -- REAL value definition
bitmap1 BIT STRING ::= ‘10011’B -- the B after the string means it’s a bit value string (i.e. 1 or 0s)
messageData Data::= ‘08985550’H -- the H after the string means it’s a hex value string (i.e. 0-9 A-F)
finnish RudeWord ::= “perkele” -- a character string value uses “ ” as delimiters
Note that all type identifiers must start with a capital letter and all value identifiers must start with a lower case letter. The assignment
symbol is ‘::=’ and the notation requires no statement termination symbol.
ASN.1 also enables the definition of sub-types by the addition of constraints to type definition as shown below.
-- use SEQUENCE OF to define a list or array, i.e. a collection of variables that have the same type, a definite order
-- and a large or unknown number
GirlFriends ::= SEQUENCE OF VisibleString -- type definition
firstLoves GirlFriends ::= {“Janice”, “Lindsea”, “Ally”} -- value definition
Telektronikk 4.2000 63
Box 1 Language Basics, continued
-- ASN.1 also provides SET and SET OF constructors. These are analogous to SEQUENCE and SEQUENCE OF
-- use CHOICE to define a variable selected from a known collection of possible variables
The presented ASN.1 simple and structured types can be arbitrarily nested to build up the required message or data structure. The
required collection of ASN.1 type and value definitions are grouped together using ASN.1 modules; these provide a mechanism for
structuring and referencing.
Automatic tagging is a feature which, when used, frees the speci- If we consider the example shown in Figure 1, the use of the
fier from ever having to explicitly add or even consider tagging ASN.1 extensibility mechanism allows the specification of the
within a message or syntax specification. CallMsg such that the phones running different versions of the pro-
tocol can still communicate with each other. The first version of
The process of manually adding tags is no longer necessary. The the protocol uses the extension marker to indicate that this type is
specifier must simply select AUTOMATIC TAGS as the tag default expected to be extended in some later version. In version 1.1 this
in the module header and the tags will be automatically generated does indeed happen, and the new extension additions (any number
as and when they are needed by a set of language transformations. are allowed) are enclosed in the ‘[[’ and ‘]]’ version brackets. In
the protocol version 2.0 we can see that there is a further extension
MyModule DEFINITIONS AUTOMATIC TAGS ::= addition.
BEGIN
The extension mechanism works by allowing the decoder to skip
ProblemType ::= SEQUENCE { over unknown additions. If we consider the case of Figure 1, the
sometimes INTEGER OPTIONAL, entity in the middle, running protocol version 1.1 will receive
-- [0] magically associated with sometimes messages from the entity to the left which has fewer components
always INTEGER in the sequence than defined in its version of the protocol. Because
-- [1] magically associated with always of the presence of the extension marker the decoder will know that
} the last expected field (cost) is an extension addition and therefore
treat this in a similar way to an optional field, accepting the mes-
END sage and passing it to the application.
2.2 Extensibility In the case where the entity in the middle receives a CallMsg from
Extensibility is a mechanism to provide forward and backward the entity on the right running version 2.0, there will be more com-
compatibility between different versions of an ASN.1 definition. ponents in the message than specified in its protocol specification.
Extensibility can be specified locally by use of the extension Because of the presence of the extension marker, the decoder
marker or globally by using the optional module header field knows that there is a possibility it might receive such a message
EXTENSIBILITY IMPLIED. The extension marker ‘...’ is normally from a later protocol version and although it cannot decode that
used in the definitions of ENUMERATED, SEQUENCE and later part, it can skip over it and continue decoding the parts of
CHOICE types. the protocol it does know.
64 Telektronikk 4.2000
Figure 1 ASN.1 Extensibility
mechanism
Although the ASN.1 extension mechanism enables forward and character set is so large, four octets are normally needed to iden-
backward compatibility from a decoding point of view, the actual tify a particular character, as opposed to a single octet in normal
application which calls the ASN.1 decoder must also be written in ASCII. To allow for this, a new value notation has been added to
such a way that it can handle the presence or absence of extra ele- ASN.1 for these string types, this allows the definition of named
ments after the extension marker. values from the character set. For example:
Telektronikk 4.2000 65
where the type of the message data is dependent on the message release MESSAGE ::= {
type, we could define the following information object class: CODE 3
CRITICALITY reject
-- Definition of Information Object Class }
66 Telektronikk 4.2000
MsgCode msgCriticality MsgData Table 2 Associated table
for ConnectPhaseMsgs
1 reject OCTET STRING object set
2 report INTEGER
3 reject -
4 ignore -
tion class (i.e. could be defined as an information object of this In this example each field may only take the values present in the
class). specified information object set for that field. For example the
field id which is associated with the MESSAGE class field
The full power of information objects and information object sets &msgCode may only have the values in the information object
requires the use of tabular and relational constraints which are set ConnectPhaseMsgs for that field, i.e. 1, 2, 3 or 4.
described in the following section.
Constraints using information object sets can be taken one step
2.6 Constraints further by using component relational constraints. Relational con-
The newer versions of the ASN.1 language provide three new straints provide a way of constraining the contents of one field
forms of constraint specification: user defined constraints, tabular depending on the value of a second field. For example to constrain
constraints and component relational constraints. the values of criticality and data to be consistent with the associated
value of the id field defined within the information object set
User defined constraints are used to informally specify constraints ConnectPhaseMsgs, the connectPhasePDU type definition can
which are too complex to define using any of the other existing be extended as follows:
ASN.1 constructs; they provide a syntax to specify an extended
comment: -- Associated PDU type definition for MESSAGE Information Object
Class with Relational constraint
– Example of user defined constraint
ConnectPhasePDU ::= SEQUENCE{
SMIMStatus ::= OCTET STRING ( CONSTRAINED BY {-- each
octet must have pattern 1010 for bit 2-5 --}) id MESSAGE.&msgCode
({ConnectPhaseMsgs}),
The user defined constraint is specified using the keywords
CONSTRAINED BY; the associated curly brackets contain the criticality MESSAGE.&msgCriticality
specification for the constraint. The contents of the curly brackets ({ConnectPhaseMsgs}{@id}),
is considered to be just a special form of comment.
data MESSAGE.&MsgData
Tabular constraints provide a way of limiting the contents of a ({ConnectPhaseMsgs}{@id}) OPTIONAL
field associated to an information object class to those contained
within a specified object set. For example if we consider the pre- }
viously defined type ConnectPhasePDU we can constrain the
allowed values of this type by applying a tabular constraint to The @id is the relational constraint in this example. It links the
its constituent fields. value of the stated field (id) to the contents of the field containing
the relational constraint, ensuring that the two are consistent with
-- Associated PDU type definition for MESSAGE Information Object the information object set definition, i.e. if the id field has the
-- Class with tabular constraint value 1 then the criticality field is constrained to the value reject
and the data field must be of type OCTET STRING. More gener-
ConnectPhasePDU ::= SEQUENCE{ ally relational constraints can be best visualised with reference to
the table associated with the information object set. The relational
id MESSAGE.&msgCode constraint is equivalent to selecting only the values of one (or
({ConnectPhaseMsgs}), more) rows within the table.
-- constrained to 1,2,3 or 4
2.7 Parameterisation
criticality MESSAGE.&msgCriticality The ASN.1 language now provides a general parameterisation
({ConnectPhaseMsgs}), mechanism which allows for example value and type parameters
for both type and value notation. The formal parameter list is spec-
data MESSAGE.&MsgData ified after the identifier in the definition, and the actual parameter
({ConnectPhaseMsgs}) OPTIONAL list is specified when the definition is referenced.
-- OCTET
Value parameterisation allows the passing of a value of a defined
-- STRING/INTEGER type, this can be used to complete a value definition or provide
constraint values for type definitions, for example:
}
Telektronikk 4.2000 67
-- Value parameterisation in value definitions The allowed values for MyString would be limited to strings that
match the regular expression defined within the constraint. In this
-- Value definition with value parameter case a matching string would start with the five characters “train”,
genericGreeting{ IA5String : name} IA5String ::= {“Hello”, name} followed by any two characters, followed by the two characters
“to”, followed by any string of any length.
-- Use of parameterised value in value assignment
These new string constraints will be very useful in the specifica-
firstString IA5String ::= genericGreeting{ “ World” } tion of new text based protocols, which form a major part of many
-- assign value “Hello World” web based technologies.
-- Value parameterisation in type definitions Another area which at present is under development is encoding
control notation [9]. Currently there is a gap in the formal specifi-
-- Type definition with value parameters cation techniques relative to the definition of encoding rules. This
MyMessage{ INTEGER : maxSize, INTEGER : minSize} ::= means that although the abstract structure of a protocol message
SEQUENCE can be formally defined, the actual format of the bits transmitted
{ on the line or through the air cannot be formally specified. There
asp INTEGER, is a small number of standardised encoding rules (e.g. Basic
pdu OCTET STRING( SIZE( minSize.. maxSize)) Encoding Rules – BER [10], and Packed Encoding Rules – PER
-- limit size to be within bounds [11]) but in many application domains such as radio interfaces,
} these do not satisfy today’s requirements for very efficient trans-
mission of information. The development of advanced encoding
-- Use of Parameterised type definition. MyMessage is instantiated control will extend the use of ASN.1 in protocol specifications
with different actual parameters. which presently use other less formal notations due to the implied
encoding restrictions of the current language.
MyLargeMessage ::= MyMessage{10000, 1}
MySmallMessage ::= MyMessage{10, 1} References
1 ITU-T. Information technology – Abstract Syntax Notation
In addition to value parameters, ASN.1 supports type parameters. One (ASN.1): Specification of basic notation. Geneva, 1998.
Type parameterisation allows the passing of a type into a defini- (ITU-T Recommendation X.680 (1997). ISO/IEC 8824-
tion, for example: 1:1998.)
-- Type parameterisation in type definitions 2 ITU-T. Information technology – Abstract Syntax Notation
One (ASN.1): Information object specification. Geneva, 1998.
-- Type definition with type parameter (ITU-T Recommendation X.681 (1997). ISO/IEC 8824-
GenericMessage{ MsgDataType} ::= SEQUENCE 2:1998.)
{
asp INTEGER, 3 ITU-T. Information technology – Abstract Syntax Notation
pdu MsgDataType One (ASN.1): Constraint specification. Geneva, 1998. (ITU-T
-- this field will be of the type passed in as a parameter Recommendation X.682 (1997). ISO/IEC 8824-3:1998.)
68 Telektronikk 4.2000
9 Willcock, C. New Directions in ASN.1: Towards a Formal Further Reading
Notation for Transfer Syntax. In: G Csopaki, S Dibuz, K Tar- Larmouth, J. ASN.1 Complete. Morgan Kaufmann, 1999. (ISBN 0-
nay (eds.). Testing of Communicating Systems Methods and 12233-435-3) (http://www.oss.com/asn1/larmouth.html)
applications, Volume 12. Kluwer, 1999, 31–40.
Dubuisson, O. ASN.1 – Communication between heterogeneous
10 ITU-T. Information technology – ASN.1 encoding rules: Spec- systems. Morgan Kaufmann, 2000. (ISBN 0-12-6333361-0.)
ification of Basic Encoding Rules (BER), Canonical Encoding (http://www.asn1.elibel.tm.fr)
Rules (CER) and Distinguished Encoding Rules (DER).
Geneva, 1998. (ITU-T Recommendation X.690 (1997).
ISO/IEC 8825-1:1998.)
Telektronikk 4.2000 69