ASN.1 Summary

8/8/2019 ASN.1 Summary

1/8


2/863Telektronikk 4.2000

Examples of simple type definitions using ASN.1 built-in types are:NumberOfElephants ::= INTEGER -- use INTEGER to define positive and negative discrete values

RainInBochum ::= BOOLEAN -- use BOOLEAN to define binary values

StudentState ::= ENUMERATED { sober, tipsy, drunk, inebriated } -- use ENUMERATED to define values with finite no. of states

ExactHeight ::= REAL -- use REAL to define continuous values

AdultArtImage ::= BIT STRING -- use BIT STRING to define raw data or bit maps

Data ::= OCTET STRING -- use OCTET STRING to define binary data with length a

multiple of 8

RudeWord ::= VisibleString -- use the appropriate string type for character string values

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 NumberOfElephantsrainingNow 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 ::= 10011B -- the B after the string means its a bit value string (i.e. 1 or 0s)

messageData Data::= 08985550H -- the H after the string means its a hex value string (i.e. 0-9 A-F)

finnish RudeWord ::= perkele -- a character string value uses as delimiters

Examples of sub-type definitions are:

HolidayDays ::= INTEGER(0..10) -- The subtype may only take the values 0 to 10

ModelStudent ::= StudentState (sober | tipsy) -- The subtype may only take the values sober or tipsy

SmallImage ::= BIT STRING (SIZE (1..100)) -- The length of the BIT STRING must be between 1 and 100

ASN.1 constructors are used to define structured types and values.

Examples of structured types and values are:

-- use SEQUENCE type to define a record structure, i.e. a collection of variables of known number and definite order

FinnishStereotype ::= SEQUENCE { -- type definition

numberOfRainDeer INTEGER,hasMobilePhone BOOLEAN OPTIONAL, -- field is optional

location ENUMERATED {helsinki, oulu, other}

}

marko FinnishStereotype ::= { -- value definition

numberOfRainDeer 1,

hasMobilePhone TRUE,

location other

}

-- 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

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.

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.


3/864 Telektronikk 4.2000

Automatic tagging is a feature which, when used, frees the speci-

fier from ever having to explicitly add or even consider tagging

within a message or syntax specification.

The process of manually adding tags is no longer necessary. The

specifier must simply select AUTOMATIC TAGS as the tag default

in the module header and the tags will be automatically generated

as and when they are needed by a set of language transformations.

MyModule DEFINITIONS AUTOMATIC TAGS ::=

BEGIN

ProblemType ::= SEQUENCE {

sometimes INTEGER OPTIONAL,-- [0] magically associated with sometimes

always INTEGER

-- [1] magically associated with always

}

END

2.2 ExtensibilityExtensibility is a mechanism to provide forward and backward

compatibility between different versions of an ASN.1 definition.

Extensibility can be specified locally by use of the extension

marker or globally by using the optional module header field

EXTENSIBILITY IMPLIED. The extension marker ... is normally

used in the definitions ofENUMERATED, SEQUENCE and

CHOICE types.

If we consider the example shown in Figure 1, the use of the

ASN.1 extensibility mechanism allows the specification of the

CallMsg such that the phones running different versions of the pro-

tocol can still communicate with each other. The first version of

the protocol uses the extension marker to indicate that this type is

expected to be extended in some later version. In version 1.1 this

does indeed happen, and the new extension additions (any number

are allowed) are enclosed in the [[ and ]] version brackets. In

the protocol version 2.0 we can see that there is a further extension

addition.

The extension mechanism works by allowing the decoder to skip

over unknown additions. If we consider the case of Figure 1, the

entity in the middle, running protocol version 1.1 will receivemessages from the entity to the left which has fewer components

in the sequence than defined in its version of the protocol. Because

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-

sage and passing it to the application.

In the case where the entity in the middle receives a CallMsg from

the entity on the right running version 2.0, there will be more com-

ponents in the message than specified in its protocol specification.

Because of the presence of the extension marker, the decoder

knows that there is a possibility it might receive such a message

from a later protocol version and although it cannot decode that

later part, it can skip over it and continue decoding the parts of

the protocol it does know.

-- ASN.1 also provides SET and SET OF constructors. These are analogous to SEQUENCE and SEQUENCE OF

-- respectively except the collection of variables has no implicit ordering

-- use CHOICE to define a variable selected from a known collection of possible variables

MobilePhone ::= CHOICE { -- type definition

nokia INTEGER,

ericsson INTEGER,

none NULL -- NULL means no associated component

}

myHandy MobilePhone ::= nokia : 8210 -- value definition

markosHandy MobilePhone ::= nokia : 9110

jensHandy MobilePhone ::= none

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 forstructuring and referencing.

Example of an ASN.1 module:

MyModule DEFINITIONS ::=

BEGIN

-- ASN.1 definitions go here

END

Box 1 Language Basics, continued



Although the ASN.1 extension mechanism enables forward and

backward compatibility from a decoding point of view, the actual

application which calls the ASN.1 decoder must also be written in

such a way that it can handle the presence or absence of extra ele-

ments after the extension marker.

2.3 Exception IdentifierThe exception identifier provides the ability to indicate to an app-

lication above the ASN.1 decoder where within the abstract syntax

a decoding error occurred. The exception identifier consists of the

symbol ! followed by either a type and a value of that type or in

the absence of a type, an integer value. The exception identifier

can be associated with any constraint or extension marker, for

example:

dayError INTEGER ::= 1

DateType ::= SEQUENCE {

year INTEGER (1970..2001),

month INTEGER (1..12),

day INTEGER (1..31 ! dayError)

-- if decoding fails on this field send dayError value

} -- to the application

When an exception identifier is present in a specification, the

associated standard or application documentation should state the

required functionality of the application on reception of this value.

2.4 New String TypesThe new string types BMPString, UniversalString and

UTF8String allow the specification of character strings based

on the ISO/IEC 10646 standard [7]. This allows the use of a huge

number of symbols from many languages and nations. Because the

Figure 1 ASN.1 Extensibility

mechanism

-- Protocol Version 1.0

CallMsg ::= SEQUENCE{

msgID INTEGER,called INTEGER,

}



msgID INTEGER,called INTEGER,,[[cost REAL]]

}



msgID INTEGER,called INTEGER,,[[cost REAL]].[[

qos REAL]]

}

character set is so large, four octets are normally needed to iden-

tify a particular character, as opposed to a single octet in normal

ASCII. To allow for this, a new value notation has been added to

ASN.1 for these string types, this allows the definition of named

values from the character set. For example:

LatinCapitalLetterA BMPString ::= { 0, 0, 0, 65}

UniversalString includes the entire ISO/IEC 10646 character set

with each character encoding to four octets. BMPString is a subset

of UniversalString which only includes the characters from the

Basic Multilingual Plane. BMPString characters, because they are

a subset of the full ISO/IEC 10646 character set, can be encoded

into two octets. UTF8String includes the entire character set, but

allows variable encoding lengths for characters, depending on

which part of the character set the character is from. The encoding

is such that the most often used characters are encoded in thesmallest space and the least used characters are encoded in the

largest space [8].

2.5 Information ObjectsInformation objects can be considered a generic table mechanism

which allows the association of specific sets of field values or

types. Information objects replace the macro notation and the

ANY DEFINED BY construct present in older versions of ASN.1

and have the advantage that they are directly machine processable.

Typically information objects are used to model protocols. They

enable in a specification to define that the value of a particular

field will determine the structure of the following fields. For

example given a simple protocol message which consists of a mes-

sage type, followed by indication of what to do if the message

type is unknown by a receiver, followed by the message data,



where the type of the message data is dependent on the message

type, we could define the following information object class:

-- Definition of Information Object Class

MESSAGE ::= CLASS {

&msgCode INTEGER UNIQUE,

-- INTEGER type value field

&msgCriticality ENUMERATED,{ ignore, report, reject }

-- ENUMERATED type value field

&MsgData OPTIONAL

-- Open type field

}

WITH SYNTAX {

CODE &msgCode

CRITICALITY &msgCriticality

[DATA TYPE &MsgData]

}

This defines the information object class MESSAGE, which is likea template for all possible messages within our simple protocol.

This information object class has three fields msgCode,

msgCriticality and MsgData, these represent the three parts of the

protocol messages. The msgCode field is a value field of type

integer in which the message type is stored. The unique keyword

signifies that all instances of this information class will have a

unique value for this field (i.e. message type). The msgCriticality

field is a value field of type enumerated and the last field MsgData

is a type field i.e. a field which can contain a type. The

WITH SYNTAX clause at the end of the definition merely provides

an user friendly syntax for defining instances of this information

class.

Information objects are often best visualised as a table. The table

associated with the MESSAGE information Object class is shown

in Table 1.

Once the overall information object class has been defined, infor-

mation object instances can be specified to represent the con-

stituent messages in the protocol. For instance the information

object definitions below specify the four messages of our simple

example protocol:

-- Information Object Definition

setup MESSAGE ::= {

CODE 1

CRITICALITY reject

DATA TYPE OCTET STRING

}

setupAck MESSAGE ::= {

CODE 2

CRITICALITY report

DATA TYPE INTEGER

}

release MESSAGE ::= {

CODE 3

CRITICALITY reject

}

relAck MESSAGE ::= {

CODE 4

CRITICALITY ignore

}

The information objects can be organised into information object

sets which can represent all the messages in a protocol or subsys-

tem, for instance:

-- Information Object Set Definition

ConnectPhaseMsgs MESSAGE ::= {

setup |

setupAck |

release |

relAck ,...

-- Other messages can be added

}

The associated table for the ConnectPhaseMsgs information

object set is shown in Table 2.

So far we have defined the information object class which pro-

vides a protocol template and then used this class to define infor-

mation objects representing the individual messages in the proto-

col. These information objects have then been brought together

into an information object set which represents the entire set of

protocol messages.

Information objects are just collections of information. Informa-

tion objects cannot be transmitted, for that purpose we need sepa-

rate type definitions. Therefore, we need to relate the information

object definitions to an actual overall ASN.1 type which can be

directly used in message transfer. The associated ASN.1 type defi-

nition for the simple example protocol is:

-- Associated PDU type definition for MESSAGE Information Object

Class

ConnectPhasePDU ::= SEQUENCE{id MESSAGE.&msgCode,

-- INTEGER field

criticality MESSAGE.&msgCriticality

-- ENUMERATED field

data MESSAGE.&MsgData OPTIONAL

-- open type field

}

This definition defines the type ConnectPhasePDU which can

contain any message which conforms to the MESSAGE informa-

Field msgCode msgCriticality MsgData

Type INTEGER ENUMERATED OPEN TYPETable 1 Table template for

MESSAGE object class



MsgCode msgCriticality MsgData

1 reject OCTET STRING

2 report INTEGER

3 reject -

4 ignore -

Table 2 Associated table

forConnectPhaseMsgs

object set

tion class (i.e. could be defined as an information object of this

class).

The full power of information objects and information object sets

requires the use of tabular and relational constraints which are

described in the following section.

2.6 ConstraintsThe newer versions of the ASN.1 language provide three new

forms of constraint specification: user defined constraints, tabular

constraints and component relational constraints.

User defined constraints are used to informally specify constraints

which are too complex to define using any of the other existing

ASN.1 constructs; they provide a syntax to specify an extended

comment:

Example of user defined constraint

SMIMStatus ::= OCTET STRING ( CONSTRAINED BY {-- each

octet must have pattern 1010 for bit 2-5 --})

The user defined constraint is specified using the keywords

CONSTRAINED BY; the associated curly brackets contain the

specification for the constraint. The contents of the curly brackets

is considered to be just a special form of comment.

Tabular constraints provide a way of limiting the contents of a

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

its constituent fields.


-- Class with tabular constraint

ConnectPhasePDU ::= SEQUENCE{

id MESSAGE.&msgCode

({ConnectPhaseMsgs}),

-- constrained to 1,2,3 or 4



data MESSAGE.&MsgData

({ConnectPhaseMsgs}) OPTIONAL

-- OCTET

-- STRING/INTEGER

}

In this example each field may only take the values present in the

specified information object set for that field. For example the

field id which is associated with the MESSAGE class field

&msgCode may only have the values in the information object

set ConnectPhaseMsgs for that field, i.e. 1, 2, 3 or 4.

Constraints using information object sets can be taken one step

further by using component relational constraints. Relational con-

straints provide a way of constraining the contents of one field

depending on the value of a second field. For example to constrain

the values ofcriticality and data to be consistent with the associated

value of the id field defined within the information object setConnectPhaseMsgs, the connectPhasePDU type definition can

be extended as follows:


Class with Relational constraint

ConnectPhasePDU ::= SEQUENCE{

id MESSAGE.&msgCode



({ConnectPhaseMsgs}{@id}),

data MESSAGE.&MsgData

({ConnectPhaseMsgs}{@id}) OPTIONAL

}

The @id is the relational constraint in this example. It links the

value of the stated field (id) to the contents of the field containing

the relational constraint, ensuring that the two are consistent with

the information object set definition, i.e. if the id field has the

value 1 then the criticality field is constrained to the value reject

and the data field must be of type OCTET STRING. More gener-ally relational constraints can be best visualised with reference to

the table associated with the information object set. The relational

constraint is equivalent to selecting only the values of one (or

more) rows within the table.

2.7 ParameterisationThe ASN.1 language now provides a general parameterisation

mechanism which allows for example value and type parameters

for both type and value notation. The formal parameter list is spec-

ified after the identifier in the definition, and the actual parameter

list is specified when the definition is referenced.

Value parameterisation allows the passing of a value of a defined

type, this can be used to complete a value definition or provide

constraint values for type definitions, for example:



-- Value parameterisation in value definitions

-- Value definition with value parameter

genericGreeting{ IA5String : name} IA5String ::= {Hello, name}

-- Use of parameterised value in value assignment

firstString IA5String ::= genericGreeting{ World }

-- assign value Hello World

-- Value parameterisation in type definitions

-- Type definition with value parameters

MyMessage{ INTEGER : maxSize, INTEGER : minSize} ::=

SEQUENCE

{

asp INTEGER,

pdu OCTET STRING( SIZE( minSize.. maxSize))

-- limit size to be within bounds

}

-- Use of Parameterised type definition. MyMessage is instantiated

with different actual parameters.

MyLargeMessage ::= MyMessage{10000, 1}

MySmallMessage ::= MyMessage{10, 1}

In addition to value parameters, ASN.1 supports type parameters.

Type parameterisation allows the passing of a type into a defini-

tion, for example:

-- Type parameterisation in type definitions

-- Type definition with type parameter

GenericMessage{ MsgDataType} ::= SEQUENCE

{

asp INTEGER,

pdu MsgDataType

-- this field will be of the type passed in as a parameter

}

-- Use of Parameterised type definition

SetupMessage ::= GenericMessage{ OCTET STRING}

3 Future DevelopmentsThis paper has described the new features introduced into the

ASN.1 language in the 1994 and 1997 versions of the standard.

To complete the ASN.1 overview this section briefly considers

some of the areas which are currently under development within

the ASN.1 standardisation community and will likely become

additions to the ASN.1 language in the future.

One area where extensions are being worked on is constraints for

string types. The current proposal is to introduce a constraint

scheme which is similar to regular expressions. This would allow

string constraints like:

Possible future string constraints

MyString ::= IA5String(PATTERN train..to.* )

The allowed values for MyString would be limited to strings that

match the regular expression defined within the constraint. In this

case a matching string would start with the five characters train,

followed by any two characters, followed by the two characters

to, followed by any string of any length.

These new string constraints will be very useful in the specifica-

tion of new text based protocols, which form a major part of many

web based technologies.

Another area which at present is under development is encoding

control notation [9]. Currently there is a gap in the formal specifi-

cation techniques relative to the definition of encoding rules. This

means that although the abstract structure of a protocol message

can be formally defined, the actual format of the bits transmitted

on the line or through the air cannot be formally specified. There

is a small number of standardised encoding rules (e.g. Basic

Encoding Rules BER [10], and Packed Encoding Rules PER

[11]) but in many application domains such as radio interfaces,

these do not satisfy todays requirements for very efficient trans-

mission of information. The development of advanced encodingcontrol will extend the use of ASN.1 in protocol specifications

which presently use other less formal notations due to the implied

encoding restrictions of the current language.

References1 ITU-T.Information technology Abstract Syntax Notation

One (ASN.1): Specification of basic notation. Geneva, 1998.

(ITU-T Recommendation X.680 (1997). ISO/IEC 8824-

1:1998.)

2 ITU-T.Information technology Abstract Syntax Notation

One (ASN.1): Information object specification. Geneva, 1998.


2:1998.)


One (ASN.1): Constraint specification. Geneva, 1998. (ITU-T

Recommendation X.682 (1997). ISO/IEC 8824-3:1998.)


One (ASN.1): Parameterisation of ASN.1 specifications.

Geneva, 1998. (ITU-T Recommendation X.683 (1997).

ISO/IEC 8824-4:1998.)

5 ITU. Programming Languages CCITT Specification AndDescription Language (SDL). Geneva, 1993. (ITU-T Recom-

mendation Z.100.)

6 ISO.Information technology Open System Interconnection

Conformance testing methodology and framework Part 3: The

Tree and Tabular Combined Notation (TTCN). Geneva, 1994.

(ISO/IEC 9646-3:1994.)

7 ISO.Information technology Universal Multiple-Octet

Coded Character Set (UCS): Architecture and Basic Multi-

lingual Plane. Geneva, 1993. (ISO/IEC 10646-1:1993.)

8 ISO.Information technology Universal Multiple-Octet

Coded Character Set (UCS): Architecture and Basic Multi-

lingual Plane Amendment 2: UCS Transformation Format 8

(UTF-8). (ISO/IEC 10646-1:1993/ Amd.2:1996.)



9 Willcock, C. New Directions in ASN.1: Towards a Formal

Notation for Transfer Syntax. In: G Csopaki, S Dibuz, K Tar-

nay (eds.). Testing of Communicating Systems Methods and

applications, Volume 12. Kluwer, 1999, 3140.

10 ITU-T.Information technology ASN.1 encoding rules: Spec-

ification of Basic Encoding Rules (BER), Canonical Encoding

Rules (CER) and Distinguished Encoding Rules (DER).

Geneva, 1998. (ITU-T Recommendation X.690 (1997).ISO/IEC 8825-1:1998.)

11 ITU-T.Information technology ASN.1 encoding rules: Spec-

ification of Packed Encoding Rules (PER). Geneva, 1998.


2:1998.)

Further ReadingLarmouth, J.ASN.1 Complete. Morgan Kaufmann, 1999. (ISBN 0-

12233-435-3) (http://www.oss.com/asn1/larmouth.html)

Dubuisson, O.ASN.1 Communication between heterogeneous

systems. Morgan Kaufmann, 2000. (ISBN 0-12-6333361-0.)

(http://www.asn1.elibel.tm.fr)

Documents

ASN.1 Summary