Computer Networks and ISDN Systems 23 (1992) 393-415 393

North-Holland

An overview of ASN.1
Gerald Neufeld and Son Vuong
Department of Computer Science, Unit,ersity of British Columbia, Vancout'er, B.C., Canada

Abstract
Neufeld, G. and S. Vuong, An overview of ASN.1, Computer Networks and ISDN Systems 23 (1992) 393-415.

In order for communication to occure, it is necessary to specify the type and format of the information to be exchanged.
In general, distributed application protocols use very complex types of information. It is therefore useful to have a formal
tool that permits the precise definition of the types of information exchanged. It is also useful to have a set of rules that
specifies the format of the values for each of the types. Each instance or value of a type must be converted to this format
before transmission. Abstract Syntax One (ASN.1) with its associated encoding rules is an example of a formal tool for
specifying the type and transfer format of type values. This tool has been used extensively within existing OSI application
protocols as well as many new applications. In this paper we present an overview of ASN.1 and its encoding rules. We also
present a summary of programming tools for the automatic processing of ASN.I. A n u m b e r of proposed extensions to
ASN.1 are also discussed

Keywords: external data representation, open systems interconnection, computer communications, abstract syntax, transfer
syntax, Estelle, LOTOS, Formal Description Techniques, heterogeneous environments, languages, compilers.

I. Introduction

Communication between any communicating entities requires a clear specification of the format and
type of the information to be exchanged. In most lower layer communication protocols this information is
relatively simple and so can be completely determined by its specification. For example, with the HDLC
protocol [20], the specification indicates what information a protocol data unit should contain and how it
is to be encoded. An I-frame (a protocol data unit containing data), for example contains a 3-bit send
sequence number, a 3-bit receive sequence number and a poll/final bit. The position of these fields
within the I-frame is fixed. Although it is possible to completely specify the information at such
lower-layer protocols, it is difficult to do so for application layer protocols. The complexity of the data
structures exchanged by distributed applications in a heterogeneous environment requires a general tool.
Such a tool is called an external data representation language.
The interconnection requirements of heterogeneous systems can be viewed in four orthogonal ways.
First, the most common requirement involves the interconnection of different computer environments.
For example, sending an integer value from a machine that represents integers in two's complement to a
machine that represents integers in one's complement. In this case we need a common representation for
integers. A translation procedure on each machine translates the respective internal representations of
an integer into a common integer representation. A second form of heterogeneous interconnection exists
if communicating applications are implemented in different programming languages. To support this
type of heterogeneity, the external data representation language can not be tied to a single programming
language. A third requirement involves the interconnection of different applications systems. For
example, suppose we wish to interconnect two different proprietary mail systems. Although these systems
may have been written in the same programming language and on the same computer and operating
system they may be vastly different in the way in which they represent messages. Finally, we may wish to
interconnect heterogeneous networks. In this case, the form of the data should be able to be altered
without changing the type information. As such the form should be decoupled from the type. Abstract

0169-7552/92/$05.00 © 1992 - Elsevier Science Publishers B.V. All rights reserved

394 G. Neufeld, S. Vuong /ASN. 1

Syntax One (ASN.1) with its encoding rules is an external data representation language defined by ISO
and CCIT/" which supports these forms of heterogeneous interconnection.
Several other external data representation languages for communication systems have been defined
[3,16,34,38]. Most of these are specific to a single programming language or have a single form for
transferring data. For example Sun's eXternal Data Representation (XDR) language is based on the C
programming language. In contrast, ASN.1 has been designed to be independent of any programming
language or operating system. It therefore makes possible the interconnection of programs that have
been implemented in different languages and environments. This independence has both positive and
negative aspects. Certainly, communication between heterogeneous systems is a major goal of Open
Systems Interconnection. However, since ASN.1 does not map directly onto the data types of most
existing languages, it is often necessary to extend the data types using the language's type construction
facilities.
External data representation languages support two components: facilities to describe data in terms of
a set of application specific data types and facilities to define how values of these data types are
represented serially for communication. The first concept is termed abstract syntax and the second
transfer syntax. For example, the data type EmployeeNumber defines an abstract syntax while the
transfer syntax defines the representation of a value of EmployeeNumber as it is transferred from one
computer to another. The rules for representing a value of a data type on the communications line are
called the encoding rules. In earlier representation languages, these two concepts were combined.
Current languages such as ASN.1 make a clear separation between them. This distinction permits
multiple transfer syntaxes to exist, as shown in Fig. 1. It also permits simpler encoding rules if more
assumptions are made concerning the sender and receiver of the information. This is particularly useful
for high-speed networking where the cost of conversion between the internal representation and the
transfer syntax must be kept low.

Gerald W. Neufeld is an assistant professor in the Department of Computer Science at the University of
British Columbia. Neufeld is the director of the Open Distributed Systems Group. His interests include
computer communications, distributed applications and distributed operating systems. He is currently
working on the Raven project; an object-oriented distributed system. Neufeld received a Ph.D. in computer
science from the University of Waterloo in 1987. He received a B.Sc (Honours) and M.Sc. from the
University of Manitoba.

Son T. Vuong received his B.S. in electrical engineering from California State University, Sacramento in
1972, M. Eng. in electrical engineering from Carleton University, Ottawa, Canada in 1977, and Ph.D. in
computer science from the University of Waterloo, Canada in 1982.
In 1974 and 1975 he was with the Canada Center for Remote Sensing working on image processing on
the Image-100 System. In 1978 he spent a term with Bell Northern Research as a Post Graduate Intern
working on routing and flow control for packet-switched networks. In 1981 and 1982 he joined the faculty
.... of the Department of Computer Science at the University of Waterloo. Since 1983 he has been with the
~ ~ Department of Computer Science at the University of British Columbia, Vancouver, Canada, where he was
a founder of the Distributed Systems Research Group and the Protocol Testing Research Group. His areas
of research interest include formal techniques for communication protocols, local area networks, high-speed
networks, and distributed operating systems. For more than twelve years he has been active in research on
protocol engineering, including formal techniques for protocol specification, verification, implementation
and testing.
Dr. Vuong was the Conference Chair of FORTE'89, the Second International Conference on Formal Description Techniques
for Distributed Systems and Communications Protocols, and a Co-Chair of IWPTS'88, the First International Workshop on
Protocol Test Systems. He has served on the Program Committees and International Committees for several symposia on formal
techniques and communications.
 G. Neufeld, S. Vuong / ASN.1 395

o~rn]a~ractSyntax
ication for
is defined I
Ity usingASN.1

EncodingRules
IorASN.1 #1 • • • • •
[ EncodingRules
forASN.1 #n
]
1
i .,ao.,e, Synfax-- I .....
1
I T,ao.,o,S,Oax.o I
Fig. 1. Multiple transfer syntaxesin a heterogeneousenvironment.

There is currently only one standard set of encoding rules for ASN.1. These are called the Basic
Encoding Rules (BER). Originally, ASN.1 and BER were defined by the CCITT for the X.400 Message
Handling System [12] in 1984. In this specification, ASN.1 and BER were combined into a single
language denoted as X.409. Historically, the X.409 specification can be traced back to Xerox Courier [38]
and the NBS Message format [15]. Since then X.409 has been adopted by ISO and separated into two
parts to permit the specification of multiple transfer syntaxes. The notation for defining abstract syntaxes
is called ASN.1 while the set of rules for the transfer syntax is called BER. The ISO version is defined in
documents [22] and [24] respectively, and the CCITT version is defined in documents [6] and [7],
respectively. The ISO version is aligned with the CCITT version. An excellent tutorial and reference
book on ASN.1 can be found in [33].
The relationship between ASN.1 and its encoding rules and the application and presentation layers
may be confusing. The specification of the application specific data types--that is, the abstract
syntax--is defined for the application layer. However, the rules governing the conversion to and from the
transfer syntax are found at the presentation layer. Typically, an implementation of the presentation
layer supports an interface that accepts the value of a data type in its local internal form and converts
that value into its corresponding transfer syntax. It also supports an interface that performs the inverse
operation.
The rest of the paper is outlined as follows. Section 2 presents an overview of the ASN.1 abstract
notation. In particular, the construction of new data types is described. Section 3 details a number of
different transfer syntaxes that can be used. We concentrate on the rules that have already been
standardized but we will also introduce several new encoding rules. The following section introduces
several applications that use ASN.1. Because ASN.1 is a formal notation, it is possible to build automatic
tools for processing both the data types and their values. Section 4 presents a number of these tools for
use in conventional programming languages such as C or special pulse languages such as Estelle or
LOTOS. ASN.1 and its associated encoding rules is still an active area of research and development.
Section 5 concludes the paper by describing a number of proposed extensions.

2. Abstract notation

In this section we introduce ASN.1 without the encoding rules. In particular we describe data types
and values that can be specified within the language. ASN.I's language supports a notation for defining
Application specific Protocol Data Units or APDUs. ASN.I's notation is similar to most programming
languages in that it contains a set of simple builtin types, a set of rules for constructing programmer
defined types, and a mechanism to set constant values of these types. It should be noted that ASN.1 does
not provide any control structures such as an if or loop statement, as you might find in a conventional
programming language; nor does it contain type compatibility or type inheritance rules as found in some
object-oriented languages. We will first describe the simple data types and the mechanism to set their
396 G. Neufeld, S. Vuong / ASN.1

values. We then describe the facilities for constructing new data types. There are three general
techniques 1: a set of construction rules that combine simple data types, a subtyping mechanism that
restricts an existing type, and a macro facility that permits the creation of new types including the syntax
(abstract notation) for the types. We conclude this section by describing the mechanism used by ASN.1 to
collect types, values and macros related to a single application or component of an application.

2.1. Data types

A data type may be viewed as a set of values. For example, the data type INTEGER is the infinite set of
all possible integer values. An instance of type INTEGER is a m e m b e r of this set. Type assignment is
defined using the template typereference:: = Type, where typereference is the name or reference to the
type Type. For example, the type assignment CourseLimit:: = INTEGER defines a type reference Course-
Limit of type INTEGER.
ASN.1 has several built-in types as do most modern typed languages such as Pascal or Aria. These
types include INTEGER, BOOLEAN, REAL, BIT STRING, ANY, OCTET STRING, ENUMERATED, NULL, and OSJECr
2
IDENTIFIER
The INTEGER type contains the set of all positive and negative integer values. Because ASN.1 is not
concerned with representation of the values, there is no limit on the size of the integer. Such limits are
imposed by the encoding rules for integer (see Section 3). Examples of integers are:
NumberOfCustomers :: = INTEGER
D a y s l n T h e Y e a r :: = INTEGER{ first(1), last(356) }
In the D a y s l n T h e Y e a r example, two additional symbols are defined: "first" and "last". These symbols
do not restrict the size of the integer; they simply provide references to two of an infinite set of values.
Of course, in practice one would want to restrict DayslnTheYear to the values between "first" and
"last". Section 2.4 on subtyping provides more information on this type of restriction.
BOOLEAN is similar to the type boolean in most programming languages. The set of boolean values is a
finite set containing TRUE and FALSE; for example,
SwitchStatus:: = BOOLEAN
In this example, a field in an APDU of type SwitchStatus can contain either of the values TRUE or FALSE.
The REAL is a new type that was added in the addendum to the ISO 8824. Again, it is similar to the
type real or float in conventional programming languages. As in the type INTEGER, it consists of all
possible real number values. The encoding rules determine how the values are represented and what
restrictions are placed on them.
A 8IT STRING consists of any string of bits. Because this definition is separate from its representation,
any length of bit string is valid. Examples are:
G3FaxPage:: = BIT STRING
RainyDaysOfTheMonth :: = BIT STRING{first(1), last(31) }
In this example, a month is represented as a string of thirty-one bits. A one would represent a rainy day
and a zero a day without rain. In the RainybaysOtTheMonth example, the symbols "first" and "last"
represent positions within the bit string. Note the difference between these symbols and those used in
the DaysInTheYear example.
The ANY type is not itself a type but a place holder for any valid ASN.1 type. The particular type used
is determined either by additional standardization or by another specification. The AND DEFINED BY
specification. The AND DEFINED BY construct provides the means of specifying this additional informa-
tion. For example,
MessageContent A N Y D E F I N E D BY contentlndication

i T h e u s e o f t a g s to d e f i n e n e w t y p e s is d e s c r i b e d in S e c t i o n 2.1.
e A S N . 1 is c a s e sensitive. M o d u l e a n d t y p e n a m e s m u s t b e g i n w i t h a n u p p e r - c a s e l e t t e r a n d built-in t y p e n a m e s m u s t b e w r i t t e n in
all u p p e r case. All o t h e r i d e n t i f i e r s m u s t b e g i n w i t h a l o w e r - c a s e letter.
 G. Neufeld, S. Vuong / ASN.1 397

In this case, the actual type is determined by the value of ContentIndication. This value is, in turn,
defined by the application and is determined at run-time.
The OCTET STRING type is the set of all octet (or character) strings. The value of an octet can be any
value from O to 255. The string is not necessarily "null-terminated" so all possible values are valid.
Again, how the length of the string is encoded is the concern of the encoding rules.
The ENUMERATED type consists of a finite set of values that are enumerated as part of the type
definition. For instance,
ResultCode :: = ENUMERATED{okay(0), accessViolation( 1 ), noSuchFile(2) }
defines a type that consists of three values. Only one of these values may be chosen for a particular
instance of the type. One should note the difference between this type and an ~NTEGERtype that includes
references to some subset of the values.
The OBJECT IDENTIVlER type is a simple type that is used when it is necessary to identify an OSI
information object in a universally unique way. Values for this type are obtained from an object identifier
tree in which each node represents an information object. The nodes are labeled numerically. The object
identifier for a node is the node's path name, where the path name is the sequence of numeric labels
starting from the root and terminating at the node. Creating new nodes in the tree is strictly controlled
by registration authorities. This type is used extensively when creating a new application. For instance,
the application itself is identified by an object identifier. ASN.1 itself is identified by an object identifier,
as is each of its transfer syntaxes.
In ASN.1 every type, including simple types, has a numerical identifying tag. When using BER, the tag
of a datatype is always transmitted along with the value of the type. The receiver of the information then
knows which type the value belongs (this assumes no other knowledge by the receiver--see Section 3.3).
It is possible to create a new type just by adding a new tag. For all the builtin types (both simple and
structured), the tags are implicitly defined in the standard. For application defined types, the tags may be
explicitly specified by prepending the actual numeric value for the tag in brackets. For instance, [0]
INTEGER defines a new type whose tag is the number 0. ASN.1 provides qualifiers for tags that determine
the scope of uniqueness. For example, the tag [universal 0] implies that this tag is unique across all
applications. The tag [application 0] is unique within the scope of the application that it is defined in,
while the tag [private 0] is unique within some private domain, such as a country. If no qualifier is
specified, as in the INTEGER example, the tag is context specific to the type in which it is declared. This is
further explained in the Coordinate example in the next section. ASN.1 also permits tags to be qualified
with the keywords IMPLICIT and EXPLICIT. These qualifiers represent information for the encoding rules
concerning the encode of the tag and type. In this case, ASN.1 comes very close to specifying the
representation rather than leaving it to the encoding rules.
As with most programming languages, simple types are not sufficient for any but the most trivial
applications. What is required is the ability to combine these types into larger, more complex, types. In
the following two subsections we describe several general mechanisms for constructing complex types.

2.2. Construction rules

There are several structured types provided by ASN.1 that can be used to combine these simple types
into more complex types. These types include SEQUENCE, SET, SEQUENCE OF, SET OF and CHOICE.
SEQUENCE and SET are similar in that they both are used to group together a named collection of
types, including simple and structured types. The difference between the two is that in SEQUENCE the
order of the types is important, as in records in Pascal or structures in C. For example:
PersonnelInfo:: = SEQUENCE{ Personnellnfo:: = SET{
age INTEGER~ age INTEGER,
married BOOLEAN} married BOOLEAN}
defines two types containing the same information. In the first case, PersonnelInfo is a sequence of two
398 G. Neufeld, S. Vuong / ASN..1

types INTEGER and BOOLEAN. When this sequence is transmitted over a communications line the order of
these types must be maintained. That is, the integer is transmitted first, followed by the boolean. The
second case is a SET rather than a SEQUENCE. When a set is transmitted the order of the types is
undefined. Hence the boolean value may arrive before the integer value. This is a problem when there
are two or more fields with the same type. In this case, it is not possible to distinguish between them.
The solution used is to mark the type with a tag. This tag is sent along with the value of the type,
permitting the receiver to distinguish which field was received; for example,
Coordinates:: = SET{
X [0] INTEGER
y [1] INTEGER}

In this case, the receiver will see the tag 0 or 1 and, based on this tag, will determine whether it was the x
or the y coordinate. The tags in this example are only unique within the context of the set Coordinates.
This situation also arises inside a sequence when optional members are specified.It is also possible to
omit a m e m b e r altogether. This is accomplished by placing the OPTIONAL keyword after a type; for
example,
Name:: = SEQUENCE{
first OCTET STRING,
middle OCTETSTRING OPT|ONAL,
last OCTET STRING}

indicates that the m e m b e r "middle" is optional. In this case, when an instance of N a m e is transmitted, it
may or may not contain a middle name. The receiver must be able to detect that the m e m b e r is present
or missing and handle the value correctly. This often results in the use of tags to distinguish the various
members.
ASN.1 also provides facilities to combine types using the SEQUENCE OF and SET OF types. The
SEQUENCE OF type is similar to an array in programming languages. That is, it implies an ordered
sequence of values of the same type. However, unlike arrays there is no restriction on the number of
elements in the sequence. The SET OF type is used to define an unordered set of values of the same type.
Again, there is no restriction on the number of elements in the set.
Finally, ASN.1 provides a facility to define a type from a set of types. This is accomplished via the
CHOICE type. This type is somewhat similar to variant records in Pascal or union type in C. For example:
Colour:: = CHOICE{
red Red,
green Green,
blue Blue}
In this example, an instance of Colour can be either one of red, green or blue. As in the case of
OPTIONAL and SET, care must be taken to ensure that the type can be distinguished from other types.
Hence, a type within a CHOICE often requires a tag.
Now that we have definitions for the builtin simple types and tools for creating new constructed types,
we can define a library of types useful for most applications. Thus, each application does not have to
create these types over again, possibly in incompatible ways. Such a set of useful types has already been
standardized and is included in the ASN.1 standard. Many of these types are defined as variations on an
octet string. The general template is
[UNIVERSAL X ] IMPLICIT OCTET STRING
where x is the tag value. A few of these string types are: NumericString, which restricts the octet string
to include only numbers; PrintableString, which is a severe restriction on the possible values of an octet;
IA5String, which includes only those octets that are defined by the IA5 standard. Many others exist such
as VideoString, GraphicString and GeneralString. Several other non-string types have also been defined.
 G. Neufeld, S. Vuong /ASN. 1 399

They include; U T C T i m e and GeneralizedTime, which provide a standard way to represent time;
EXTERNAL, for a field whose type is unspecified or defined elsewhere; and ObjectDescriptor, which
defines human readable text that describes an information object.

2.3. Data values

It is possible in ASN.1 to establish a reference to a particular value of a type. This is somewhat similar
to constant or manifest definitions in conventional programming languages. The value reference can then
be used wherever a value is required. For example,
Priority:: = INTEGEa { lOW(0), m e d i u m ( 1 ) , high(2) }
defines a type reference Priority for the type defined on the right-hand-side. Using ASN.1 value notation
we can define a reference to a particular value. For instance,
defaultPriority Priority:: = medium
establishes "defaultPriority" as a value reference to an instance of Priority. In this case, the instance has
the value, medium. In general, the ASN.1 value notation is defined as
ralueReference typeReference :: = value
where valueReference is the reference to the value 3, and typeReference identifies the type from which
the value is chosen. A common use of value notation is in defining value references for object identifiers.
For instance, a particular application may be assigned a particular object identifier value. Another
frequent use of this facility is in defining values for operations for a particular application as well as the
values for the errors returned. Section 2.7 describes a simple application that uses value notation in this
manner.

2.4. Subtypes

Subtypes are a refinement on a parent type. There are several kinds of restrictions including alphabet,
size and value. For example:
TouchTone:: = I A 5 S t r i n g ( F R O M ( ' l ' ]'2' ]'3' ]'4' ]'5' 1'6' ]'7' ]'8' ]'9' ]'0' I ' * ' [ ' # ' ) )
In this example the subtype TouchTone is restricted to the alphabet designated in the parent type,
IA5String; that is, the digits 0 through 9 and the special characters ' * ' and ' # ' .
It is also possible to limit the size of a parent type. For example, in the case of
D a y s l n T h e Y e a r := INTEGER(1..356)
the type identified by D a y s l n T h e Y e a r is restricted to the fixed set of positive integers from 1 through
356. Size limitations can also be applied to structured types. For example, an array of 64 elements can be
defined as
Array:: = SEOUENCE SIZE(1..64) OF INTEGER
Subtypes can also be applied to the value of a type. For example, in the following definition:
Smallprime :: = INTEGER( 2 1315)
Smallprime is restricted to the integer values 2, 3 or 5, respectively.
It is also possible to combine these mechanisms. For instance, in the following examples:
Days:: = ENUMERATED(SUn(I), m o n ( 2 ) , tue(3), wed(4), thu(5), fri(6), sat(7))
Weekend:: = Days(sat ]sun)
LongWeekend :: = Days(INCLUDES Weekend Imon)

3 Value references must begin with a lower case letter.

400 G. Neufeld, S. Vuong / A S N . 1

LongWeekend is a subtype of the enumerated type Days. It is a value range restriction, including only
the values sat, sun, and mon.

2.5. Macros

Macros are the third general mechanism for defining new types and values. What sets macros apart
from the other two methods is that they also provide a new syntactic definition for the type. As such, they
are used to extend not only the builtin and useful types of ASN.1 but also to extend the syntax of the
ASN.1 language. The new notation is defined using an extended BNF, creating an extremely flexible tool
for the protocol designer. Several problems arise, however, from this-flexibility. First, this flexibility can
easily be abused. Even within OSI standards themselves, macros have not been used consistently.
Second, there can be a great temptation to create many new statements making the job of the protocol
implementor much more difficult. The implementor must then not only learn and understand the syntax
and semantics of the base ASN.1 language but also the syntax and semantics of the extension, the
semantics of which is often not well defined. And third, it is very difficult to create automatic compiler
tools for macros since macro definitions extend the syntax of the language without the corresponding
semantics. The semantics are either provided as comments or as English language text.
As stated, a macro is used to define new types. The name of a macro can be used anywhere a type or
value reference is valid. One of the main uses of macros is to define parameterized types. Macros are
also extensively used in R O S E [9], X.400 [12] and X.500 [39] in defining operations, associations and
schema. The example we will present is an instance of parameterized types. In this example, we wish to
create a pair of types
SEQUENCE{ Typel, Type2}
where Typel and Type2 can be any valid ASN.1 type. The new syntax for this type could be
PAIR FIRST = Type1 SECOND = Type2
For example,
TI:: = PAIR FIRST = INTEGER SECOND = VisibleString
should generate
SEQUENCE{INTEGER, VisibleString}
or for example,
T2:: = SET{BOOLEAN, P A I R FIRST = INTEGER SECOND = T1}
should generate
SET{BOOLEAN, SEQUENCE{INTEGER,
SEQUENCE{INTEGER, VisibleString}}}
Before we can use this macro we need to define it. This is clone as follows:
PAIR MACROH ~ BEGIN
TYPE NOTATION:: =
"FIRST" "= " type(localTypel)
"SECOND" "= " type(localType2)
VALUE NOTATION H
.... = "value(localValuel localType 1)","
"('"'FIRST
"SECOND.... = "value(localValue2 localType2)
< VALUE SEOUENCE{IocalTypel localType 2}:: =
{localValuel, localValue2} >
,,),,

END
 G. Neufeld, S. Vuong / ASN.I 401

From this example we can identify two major components: the type notation and the value notation. The
type notation specifies the syntax of the new type PAIR in an extended BNF notation. In this example, a
type is syntactically defined as containing the literal "FIRST" followed by the literal symbol " = ". This is
followed by any valid ASN.1 type. The type is identified by the keyword "type". Ignoring the symbols
within the parentheses for a moment, this is followed by the literal "SECOND" and the literal " = ", and
again by any valid ASN.1 type. The symbols localTypel and localType2 are formal parameters that will
be replaced by the actual ASN.1 types when the macro is invoked. For example, if we invoke the macro
as
PAIR FIRST = INTEGER SECOND = BOOLEAN

then localTypel will take on the value INTEGER and localType2 the value BOOLEAN.
The second component in the macro specifies the value syntax for the PAIR type. The literals are
similar to that of the type notation. The "value" keyword is followed within parentheses by two symbols
localValuel and localValue2. The symbol localValue 1 is a variable that holds the value specified in the
invocation of the macro, while localTypel indicates that the actual value of localValuel must be an
instance of the actual type of localTypel. The same is true for localValue2 and localType2. For instance,
in the value
aValue P A I R F I R S T = I N T E G E R S E C O N D = B O O L E A N :: = ( F I R S T ~ 5 , S E C O N D = F A L S E )

localValuel contains 5 and localValue2 FALSE. In exactly one place in the macro definition, the reference
name VALUE must be assigned to a data value. The result of the invocation of the macro is precisely this
value. In our example, this would be
SEQUENCE{INTEGER, B O O L E A N } :: = { 5 , F A L S E }

Another common use of macros is to define a new type whose value is an integer or object identifier.
Two of the most common of these kinds of macros are the OPERATOR and ERROR macros. These macros
are used when defining the interface to an application service. The interface is based on remote
operations, which is very similar to remote procedure calls. The OPERATOR macro defines a type that
includes an argument, result or error. The ERROR macro defines an error that can be returned. The
following macro definitions are simplified versions for these two types. The full definitions can be found
in [91.

OPERATOR MACRO~: = BEGIN

TYPE NOTATION :: = Argument Result Errors
VALUE NOTATION :: = v a l u e ( V A L U E INTEGER)

Argument :: = " A R G U M E N T " t y p e

Result :: = " R E S U L T " t y p e
Errors :: = " ERRORS'"'{"ErrorNames"}"
ErrorNames :: = ErrorList IEmpty
ErrorList :: = type IErrorList ',"type
END

ERROR MACRO:: = BEGIN

TYPE NOTATION :: = e m p t y I " P A R A M E T E R " t y p e
VALUE NOTATION :: = v a l u e ( V A L U E I N T E G E R ) .
END

In both of these macros a value of integer is returned as a result of an invocation. In the OPERATOR
macro two additional p r o d u c t i o n s - - E r r o r N a m e s and E r r o r L i s t - - a r e required to define the list of
possible errors that may be returned.
These macros are used to syntactically define the interface to an application. The OPERATION macro
also defines the operation code as an integer and the ERROR macro defines an error return value as an
integer. As one can see, this definition is not sufficient to define the actual semantics of an operation or
402 G. Neufeld, S. Vuong / ASN.1

error return. The actual semantics are defined in textual form in the Remote Operations standards
X.219 and X.229 [9]. These documents indicate that a remote operation is sent from one machine to
another as a sequence of values defined as:

OperationAPDU:: = SEQUENCE{
invokelD INTEGER,
operation iNTEGER,
argument ANY DEFINED BY operation OPTIONAL}

The result is returned as a sequence:

Result APDU:: = SEQUENCE{

invokelO INTEGER
sequence{ operation OPTIONAL,
result ANY DEFINED BY operation
)OVnONAL)
and an error is returned as a sequence:

ErrorApdu:: = SEQUENCE{
invokelD INTEGER,
error INTEGER,
parameter ANY DEFINED BY error OPTIONAL}

Section 2.7 presents an example of a simple telephone directory application that uses these macros to
define its interface.

2.6. Modules

Within an application, it is useful to group the collection of all the types and macros defined for the
application into one or more modules. This is analogous to the module concept in Modula II or packages
in Ada. It is a convenient mechanism for naming a specific group of definitions. Like Modula II, it is
then possible to import and export type and value references to other modules. For example:

ModuleDefn D E F I N I T I O N S : : = B E G I N
IMPORT other Module type and value references
EXPORT definitions
... set of definitions...
END

With this mechanism, it is possible for an application to be defined as a number of module definitions
rather than a single one. The usefuIness of this structuring mechanism can easily be compared to a
conventional programming language where having to define the entire application code within a single
module would certainly be onerous. If one module is required to use a type defined in another module,
the IMPORT statement is used. This statement typically lists the modules and their types that are to be
referenced. Only types that have been exported from the module in which they are defined can be
imported.

2. 7. A simple distributed application

In this section we present a simple but complete example of an application protocol. The application
is a telephone directory consisting of a telephone database and a set of operations on the database. The
telephone database consists of a set of entries, one entry per person. The amount of information
maintained in an entry is quite minimal, containing the name of the person, a set of telephone numbers,
 G. Neufeld, S. Vuong / ASN.1 403

an indication of the kind of position the person holds at the organization and, optionally, the room
n u m b e r of the office.
In this application, a single server accepts the operations made by multiple clients. Both the clients
and the server use this interface to define what the server supports and what the clients will send. T h r e e
operations are defined:a lookup operation that accepts a n a m e as an a r g u m e n t and returns a set of
entries that match the name; an add operation that adds new persons to the database; and a remove
operation that removes a person defined in the database.
T h e abstract syntax for the T e l e p h o n e directory application is defined as follows:

PhoneDirectory DEFINITIONS:: = BEGIN

- this is a set of ASN.1 definitions that describe types, operations and

- their arguments for a simple remote telephone directory service.

- operations supported by directory service.

lookup OPERATION ARGUMENT n a m e RESULT M a t c h e d E n t r i e s

ERRORS {noSuchName, service Error}
::=]

add OPERATION ARGUMENT Entry RESULT N o n e

ERRORS {insufficientSpace, serviceError}
::=2

remove OPERATION ARGUMENT N a m e RESULT N o n e

ERRORS {noSuchName, serviceError}

::=3"
- result types returned by operations
MatchedEntries :: = SET OF Entry
None :: = NULL

- Entry in directory

Entry:: = S E Q U E N C E {
name Name,
phone SET Of NumericString,
position ENUMERATED{faculty(0), staff(l), student(2)},
office PrintableString OPTIONAL
}
- Structure of a name.

Name:: = SEQUENCE{
lastName PrintableString,
CHOICE{
initial [0] PrintableString,
firstName [1] PrintableString}
}
- errors r e t u r n e d by operations

noSuchName ERROR PARAMETER None:: = 1

insufficientSpace ERROR PARAMETER None:: = 2
serviceError ERROR PARAMETER None:: = 3

END
404 G. Neufeld, S. Vuong / ASN.1

There are several error possibilities as defined by the ERROR macro. In this example, no information is
returned other than the integer error value. As noted before, the OeERATION and ERROR macros do not
tell the whole story of what actually is transmitted. In the case of an operation, the OperationAPDU is
transmitted, with the value of the operation field set to one of three possibilities (i.e., 1 for lookup; 2 for
add; and 3 for remove) and the argument field set to the appropriate type depending on the kind of
operation. If the operation is lookup or remove, then the argument type becomes Name; otherwise the
operation is add and the argument field becomes Entry. Similarly, the result is returned in a ResultAPDU
or, if an error occurred as a result of the operation, in an ErrorAPDV.

3. Transfer syntaxes

As mentioned in the Introduction, the values for a particular abstract syntax must be converted to a
transfer syntax for transmission. The rules describing the format of the types are called the encoding
rules. ASN.1 permits many different transfer syntaxes. However, currently there Is only one official
standard, the Basic Encoding Rules or BER. In this section we present an overview of the Basic
Encoding Rules. We also introduce several other encoding rules that could be used with ASN.1.

3.1. Basic encoding rules

Every ASN.1 type, whether simple or constructed, has a tag. This tag is used to identify a value of a
type. To accomplish this, the tag is transmitted with the value. The receiver obtains both the tag and the
value and can therefore interpret the value as belonging to a particular type. Because the size of a value
is not determined by the type, a length must also be included. As a result, each value transmitted is
composed of a 3-tuple consisting of an identifier for the tag, the length of the value and the value itself
as illustrated in Fig. 2.
If the type is a structured type, then the value itself will contain other types. For instance, SEOVENCE
OF INTEGER would contain a tag for the sequence, a length that includes the entire sequence of integers

IdentIifieLengi
I
r ~/~Val
I.LL_~.uv'Ve~~~alu
I

rOe 'rl Lonoth I

Fig. 2. Recursive identifier-length-value format.

Identifier Length Value

INTEGER

Identifier Length Value

io°,, I
SEQUENCE • IL of two integer valuos 5 and 10 " I

Fig. 3. E x a m p l e encodings.
 G. Neufeld, S. Vuong / ASN.1 405

Class: identities one of four classes

Form: indicates primitive (bit=O) or constructor (bit=l)

Tag: distinguishes between types of the same

class

It Class Bit 8 Bit 7

I1'"11
Universal 0 0
Application 0 1
Context-specific 1 0
Primitive 1 1

Fig. 4. Tag part.

Tag Bit value Data Type

00000 End-Of-Contents
00001 BOOLEAN
00010 INTEGER
00011 BIT STRING
4 00100 OCTET STRING
17 10001 RFT
23 10111 UTC Time
24 11000 Generalized Time
Fig. 5. Some UNIVERSAL tags.

and a value consisting of a sequence of identifier-length-value tuples, one for each integer in the
sequence.
Figure 3 illustrates this example. H e r e we can see that the tag for an integer is two 4, the length is one
octet and the value is two. A sequence of integers is also illustrated. In this case the tag identifier for the
sequence is 1A and the length of two integers is six.
The basic encoding rules also describe the format of each of the three components. As illustrated in
Fig. 4, the identifier is composed of three fields: a 2 bit class field, a 1 bit primitive/constructed field and
a 5 bit tag field. The class field identifies one of the four classes of the tag. These classes were discussed
previously in Section 2.3. The primitive/constructed field indicates that the value for the type is a
primitive or constructed value. If it is primitive, then the value contains the actual information; otherwise
the value is a constructor and the receiver must interpret the value as containing Identifier-length-value
triples. The reason this bit is required is that some types--OCTET STRING for e x a m p l e - - c a n be either
primitive or constructor. In this case, it is not possible to determine which form is present simply from
the tag.
All types in ASN.1 must have a tag. The builtin simple types and the structured types have predefined
tags as specified by ASN.1. The types such as PrintableString also have tags defined in ASN.1. All these
tags are universal; that is, the types can be used by any application. The class bits for these tags are 00.
Figure 5 presents a few of the tags as specified in ASN.1.
In the illustrations, the maximum size of a tag value must fit into the five bits. If a tag value is larger, a
long form of encoding is used. In this case the five bits of the tag are set to all ones indicating that the
octets that follow will contain the tag value. An arbitrary number of octets can follow. For these octets all
but the last octet has its left-most bit set to one. The last octet in the sequence has its left-most bit set to
zero. This syntax supports an arbitrary length of tag.
The length component indicates how long the value is. The length does not Include itself or the
identifier. This component has three forms: a short form, a long form, and an indefinite form. The short
form is used when the size of the value is less than 128 octets. In this case, the length component itself is
one octet long with the left-most bit set to zero and the remaining seven bits containing the value length.
If the length is greater than 127 octets, the long or indefinite form is used. In the long form, the left-most

4 All identifiers, lengths and contents are are given in base 16 unless otherwise indicated.
406 G. Neufeld, S. Vuong / ASN.1

i--
Length of Value in
octets
Short Form
1 octet ~
max size ot'''''' I
O-127
octets Length of Value in numberof
octets
Long Form I I
maxN°CtetSsize '1''''''11'''''''1 '''''''1
128-21°°s
' - - J I: "1

Length of length in numberof

Octets
Fig. 6. Length part.

for constructors only -

permits output of contents without knowning
total length
Length End Of Content indicator
...contents ]1
**l
oo,, [ oo,, I
Fig. 7. Indefinite length part.

bit of the first length octet is set to one indicating long form. The remaining seven bits contain the length
of the length i.e. the number of octets following the first length octet, it is these octets that contain the
actual length of the value as illustrated in Fig. 6.
The indefinite length form is used when it is not known at the time a value is converted to its transfer
syntax what its length is without considerable extra processing. For example, if we had a SET OF Entry as
defined in the Telephone Directory abstract syntax, then to calculate the length of the set we would have
to scan the entire set adding up the lengths of each Entry which itself is variable length. Instead, we
could just indicate when generating the length for the set that the length is indefinite, and proceed to
transmit however many values exist for the set. When the end of the set is reached a special
end-of-content indicator is sent, permitting the receiver to property process the SET type. The indefinite
length form is given in Fig. 7.
The indefinite length form can only be used by constructor encodings.

Examples of encoding

The ASN.1 type definition Person:: = PrintableString, with a value 'Jones", would be encoded in
primitive form as follows: the PrintableString tag is 13 (PrintableString is defined as [UNIVERSAL 19]
IMPLICIT IA5String),the length is 5, and the content is 4A6F6E6573. The same value could be encoded as
a constructor as: PrintableString tag 33, length of 9, content composed of two octet strings with tag 04,
length 3 and content 4A6F6E (for "Jon"), and length 02 and content 6573 (for "es") respectively.
The following examples demonstrate how tags affect the encoding. We also illustrate the effect of the
IMPLICIT directive from ASN.1 to BER. When using implicit, the tag given in the abstract syntax
subsumes the tag defined by the standard. In all these examples we use the value "Jones" for the
PrintableString type.
type Type1:: = [APPLICATION3] IMPLICITPrintableString
encoding [APPLICATION 3] Length Contents
436 0516 Jones
 G. Neufeld, S. Vuong / ASN.1 407

type Type2:: = [2] Type1

encoding [2] Length
A216 0716
[APPLICATION 3]
Length Contents
4316 0516 Jones
type Type3:: ~--- [APPLICATION7] IMPLICITType2
encoding [APPLICATION 7] Length
6716 0716
[APPLICATION 3] Length Contents
4316 0516 Jones
type Type4:: = [2] IMPLICITTypel
encoding [2] Length Contents
8216 0516 Jones

3.2. Telephone directory encoding example

A possible example of encoding could be an entry in the telephone directory application. The
encoding for a value of an entry in the directory would be:
value smithEntry Entry:: = {{"Smith", "Joe"}, {2458}, faculty, 238A}
encoding Entry Length Contents
3016 33 Name Length Contents
3016 12 PrintableString Length Contents
1316 05 Smith
[2] Length Contents
8216 05 PrintableString length Content
1316 03 Joe
SET OF Length Contents
3116 06 NumericString Length Contents
1216 04 2458

ENUMERATED Length Contents

1016 01 faculty(0)

PrintableString Length Contents

1316 04 238A
3.3 Packed encoding rules

As one can see from the previous discussion, the amount of administrative data (identifier and length)
compared to the actual data (content) transfered can be rather high. This is particularly true if the size of
the data is small and an explicit tag is used. For example, the type [1] INTEGER, would have four octets of
administrative data and one byte of actual integer data if the size of the value is less than 128. Clearly,
care must be taken when using tagging to reduce the amount of information. However, even with implicit
tagging, our example would produce two octets of administrative data versus one octet of actual data.
The problem of the administrative data arises in two cases; if the speed of the transmission line is low,
the amount of extra information just adds to the length of the transmission and in high speed
applications the processing of each identifier and length may place a prohibitive cost on the transmitter
or received 5. It is possible, however, to compact the encoding if greater demands concerning the type
and format are made on the receiver.

5 Encoding and decoding tends to dominate the cost of the protocol stack. In the EAN X.500 implementationthe cost of the
presentation layer is approximately70 percent of the entire protocol stack.
408 G. Neufeld, S. Vuong / ASN.1

Within CCITT and ISO work is progressing towards Packed Encoding Rules. These rules will reduce
the amount overhead on every data value transmitted. These rules can be applied to applications where
the type and format of the information is predictable. For instance, the identifier is predictable in the
case of (non-optional) members of SEQUENCE, SEQUENCEOF and SET OF 6. In this case, one can simply
omit the identifier. It is therefore encumbant on the receiver to know the type of data expected. The
length of a value can also be omitted if we assume that the receiver knows what types to expect. For
instance it is not always necessary to include a length for SEQUENCE or SET OF if the length is known by
the application.
Finally, the encodings of common data types can be optimized. Short form INTEGER and BOOLEAN, for
example, do not require a length. Actually, no length is required for SEQUENCE either. The end is
determined when the last member is parsed. Of course, the receiver must know which is the last member.
In cases when the last member is optional, the End-Of-Content flag can be used. This also applies to SET.
Some examples of this type of encoding are (using the types defined in the previous section):
Type2 [2] Length Content
A216 0516
[APPLICATION3] Length Content
Jones
T~pe3 [APPLICATION7] Length Content
6716 0516
[APPLICATION3] Length Content
Jones

3.4. Other encoding rules

Many other types of encoding are possible. For example, it is possible to encode ASN.1 values into a
transfer syntax that only uses the ASCII character set. In this case, it is possible to transmit data over
7-bit ASCII transmission lines. This type of encoding is also useful for debugging incoming APDUs in
BER format. That is, the APDUs can be displayed on a screen in ASCII format. This can also be useful
in generating test APDUs.
Another area where a different transfer syntax can be used is when storing information defined in
ASN.1 on disc. In our telephone directory, for example, each entry would be stored permanently on disc.
It is certainly possible to store the entries in BER format. However, for efficiency reasons one would like
to store them in a format that requires minimum processing when fetching the entry from disc. The
reason for this is that the operation of reading an entry into RAM is by far the most common operation.
Hence optimizing this operation would seem prudent.
One possible way to accomplish this is to take the internal (RAM) representation of the Entry and
write it to disc. This internal representation could be defined by the C type structures automatically
generated by a ASN.1 compiler. If we could write the entire internal representation of an Entry, then we
should be able to read it back in. In this case, a single read operation would provide us with the entire
Entry in RAM ready for processing rather than having to parse the BER transfer syntax, allocating data
structures and copying data. The problem with this mechanism, however, is that the pointer values
written may not be the same when read in. A solution is to store the offset from the beginning of the
entry area rather than the full address by running through the Entry data structure and subtracting the
beginning of the area from each pointer value. When the Entry is read in, the address of the beginning of
the area must be added to each offset-a minimum of overhead in comparison to a complete BER parse
and construction of the internal data structures 7. This type of encoding is used by the EAN X.500
Directory system[27] for storing the entries within the directory information base.

6 CHOICE and ArqV can not be used in this case.

7 It may be necessary to copy the internal structures to a single contiguous area before doing the subtraction. However, since the
number of read operations greatly out-number the write operations, this is still a reasonable solution.
 G. Neufeld, S. Vuong /ASN. l 409

34
og
null

null

04
03
JON
null

04
02
ES
null
null
Scheme 1.

The design of new transfer syntaxes continues to be an active area of research and development.
Other transfer syntaxes--specially designed for high-speed processing--have been reported in [18].

4. Automatic processing

It would certainly be a great advantage to an application programmer if an automatic process existed

which would convert the types in an abstract syntax into types used by a specific programming language.
It would also be very useful if a set of encoding and decoding routines was generated that could be called
by the programer to convert a value of a type to and from a particular transfer syntax. Without these
tools, the programmer would have to create the programming language types by hand as well as write the
source code for the encoding and decoding r o u t i n e s - - a difficult and error prone task. In this section we
will discuss several automatic tools for creating programming language structures and their correspond-
ing encoding and decoding routines. We will also briefly discuss the use of ASN.1 in formal description
languages standardized by ISO and the possibility of specialized hardware support for ASN.1.

4.1 List based representations

One of the most obvious ways of representing values of ASN.1 types is via a list based scheme where
each node in the list corresponds to a value. In effect the list is really a tree rooted at the value of the
"top-most" types. For instance, the top most type of an entry in the telephone directory is a SEOUENCE.
The EAN X.400 Messaging System [26] uses this mechanism as does I S O D E [37]. In EAN, values are
represented in a C language structure called an E N O D E 8 as defined below.
typedef struct ENODE
{
unsigned long id; / * identifier for type * /
long length; / * length of the value * /
unsigned char • primitive; /* to primitive content * /
struct ENODE • constructor; /* to constructor content * /
struct ENODE • next / * to next value * /
}ENODE;

s I S O D E has a similar structure called a PE or Presentation Element.

410 G. Neufeld, S. Vuong / ASN.1

Only one of the fields, primitive and constructor, is set. That is, if primitive is NULL, then the value is a
constructor and the constructor field points to the corresponding ENODE.
There also exists a set of routines to allocate a node and assign it an identifier, to free a node, to
compare two nodes, to make a copy of a node etc. There are also routines for constructing sets and
sequences. For example Set_add Set_find. Routines also exist for building primitives.
The following is an example of a constructor octet string with values "Jones", using ENODE structures
(see also Scheme 1). The advantage of the ENODE list structure is its relative simplicity. A single C
structure can be used to represent all possible ASN.1 types. No special tools are required other than the
library of routines to manipulate the nodes. This type of structure is also useful within a protocol testing
environment since, within such an environment one wants a much greater control over the values of the
APDUs.- in particular, the generation and reception of invalid APDUs. The ENODE structure is suitable
for both these functions [32]. The disadvantage is that the type structure is lost since all types are
represented as ENODEs. For example, from a programmer's perspective it would be better to view an
Entry as defined in the Telephone Directory abstract syntax in a way that is similar to type definitions of
the implementation language, i.e., a C structure for Entry containing fields corresponding to fields in the
ASN.1 Entry definition. Doing this effectively requires a compiler for ASN.1 that generates the
corresponding C structures as well as the encoding and decoding routines for each of the structures.
Such a tool is described in the following subsection.

4.2 C data structures

A considerable amount of work has been done in implementing the ISO BER and ASN.1 compilers
[17,28,31,36,37]. This subsection describes an implementation of BER, called the E D library and an
ASN.1-C compiler, called CASN1. The ED library contains a number of primitive encode and decode
routines. These routines are used to compose encoders and decoders for composite ASN.1 types. A
primary design goal of the system was to make the encoding and decoding of complex types as efficient
as possible. To this end, the E D library routines translate data values directly between C data structures
and the BER transfer syntax thus eliminating the overhead in converting data into an intermediate form
such as the E N O D E structure. A specialized memory management technique is also used which
significantly improves the encoding and decoding speed [28].
The ED library is a BER implementation based on ISO BER and its addendum. CASN1 is also based
on ISO ASN.1 and its addendum. CASN1 translates a ASN.1 module definitions into C definitions and
generates the BER encode and decode routines for non-simple types. CASN1 deals with all ASN.l-type~
except macro definitions; however extensions to the ASN.1 syntax rules for O P E R A T I O N and E R R O R
definitions have been added.
An ASN.1 to C compiler translates type and value definitions in ASN.1 to their corresponding C
language data type and values. This is usually reasonably straightforward as given in Table 1 below. Some
ASN.1 types do not have matching C types. Hence it is necessary to add programmer defined types. For
example, OCTET STRINGS can not be represented by C strings. The OCTS structure was defined for this
purpose.
typedef struct OCTS {
struct o c r s * next; / * to next OCTS node * /
long length; / * size of octet string * /
void *contents; / * pointer to contents * /
} ocrs;
The whole octet string can be broken into chunks and linked together via the OCT structure. This can be
useful when the entire octet string is not known initially.
Similarly, SEQUENCE OF and SET OF types have no corresponding built-in C language type. To
accommodate these types, we have defined a polymorphic list structure that can be used to represent
these values.
 G. Neufeld, S. Vuong / ASN.1 411

Table 1
ASN.1 type and the corresponding C types

ASN. 1 Type C Type

BOOLEAN unsigned char
INTEGER int
ENUMERATED enum
REAL float
BIT S T R I N G BITSS
OCTET STRING OCTS
NULL int
ANY unsigned char *
OBJECT IDENTIFIER OID
SEQUENCE{... } struct{... }
SET{... } struct{... }
S E Q U E N C E OF LIST *
SET O F LIST *
CHOICE{... } int choice union{... }
UNIVERSAL TIME TIME
EXTERNAL BITS

typedef struct LIST {

int count; / * number of items in list * /
LIST _ ITEM * top; / * pointer to first item * /
LIST _ ITEM * next; / * current item pointer * /
} LIST;

#define SET LIST

#define SEQUENCE LIST
#define OF(type)
typedef struct {
void * item;
s t r u c t LIST_ ITEM * next;
} LIST ITEM;

Telephone directory C language interface

To illustrate how the compiler operates, the following is the result of running the Telephone Directory
abstract syntax through the CASN1 compiler.
/ * this is a set of ASN.1 definitions which describe types, operations and * /
/ * their arguments for a simple remote telephone directory service.*/
/ * operations supported by directory service */
/ * Structure of a name.*/
typedef struct T12 { / * CHOICE * /
int choice; / * indicate the choice of data */
#define T12_ initial_ tag 0xa0000000
#define T12 - firstName tag 0xa0000001
union{ / * choices */
OCTS * initial; / * CONTEXT 0 PrintableString */
OCTS firstName; / * CONTEXT 1 Printablestring */
data;
412 G. Neufeld, S. Vuong / ASN.1

}
} T12;
IDX* Encode_T12( );
T12* Decode_T12( );
typedef struct Name { / * SET/SEQ * /
OCTS * lastName; / * PrintableString * /
T12* r l l ; / * T12(constructor) * /
} Name;
IDX * Encode_Name( );
Name* Decode_Name( );
/ * Entry in directory * /
typedef enum T l l {faculty = 0, staff = 1, student = 2} T l l ;
IDX * Encode_T11( );
Tll D e c o d e _ T l l ( );
typedef struct Entry { / * SET/SEQ * /
Name * name; / * Name(constructor) * /
SET ov(ocrs*) phone; /* NumericString(recursive) * /
T11 position; / * Tll */
OCTS * office; /* PrintableString * /
} Entry;
IDD* Encode_Entry( );
Entry * Decode_ Entry( );
typedef int None; / * NULL * /
IDX * Encode_None( );
None Decode_None( );
/ * result types returned by operations * /
typedef SET OF(Entry) MatchedEntries;
IDX* Encode_ MatchedEntries( );
MatchedEntries Decode - MatchedEntries( );
/ * define OPERATIONs' name and id * /
#define lookup 1
#define add 2
#define remove 3
#define ERROR'S name and id * /
#define noSuchName 1
#define insufficientSpace 2
#define serviceError 3
To save space we have not included the code for each of the encode and decode routines. However, for
each of the types there exists a routine that was generated by the compiler to encode the values in the
internal C data structures into BER transfer syntax or to decode a PDU into its equivalent internal form.
Other approaches to encoding and decoding BER transfer syntax exist. Another common mechanism
is to use an interpretive approach. In this scheme, a compiler generates a type tree instead of specific
routines for encoding and decoding. A decode interpreter accepts the type tree and an BER data stream.
It decodes the bits into an internal format based on the structure information contained in the data
stream and the type tree. The advantage of this approach is that the type tree tends to require much less
memory than the generated encode and decode routines. The disadvantage is that the interpreter is
 G. Neufeld, S. Vuong / ASN.1 413

tends to be slower. It is also more difficult for the interpreter to operate with programming language
specific data types that match the ASN.1 data types. As a result interpeters often use a generic structure
such as ENODEs.
Another problem that arises in encoding and decoding is dealing with very large messages; that is,
message that can not be kept in their entirety in RAM. In such cases it is desirable to only decode a
portion of the protocol data unit. For instance, in a X.400 message only the header portion maybe
decoded while the body portion is left. Several solutions to this problem exist [28,29], however this still
remains an interesting area of work.
Finally, automatic processing of macros is problematic because of their ability to dynamically extend
the language. Most solutions to this problem is to simply add often used macros--such as OPERATION
and ERROR--to the base language. However, work is being done to process macros automatically [1].

4.3 ASN.1 and FDTs

Within the context of OSI communication protocols, formal description techniques (FDTs) have been
developed for the description of protocols and services. FDTs defined by ISO and CCITT include
LOTOS [21], SDL [11], and Estelle [25]. Using these FDTs, formal specification of the protocol is
possible, resulting in a clearer description. These FDTs, however, are used for defining lower layer
protocols; in order to be useful at the application layer, ASN.1 data typing must somehow be
incorporated into them.
Several methods can be applied [4]: substitution, combination or translation. In substitution, ASN.1 is
used instead of an FDT [2]. However, since ASN.1 does not have any control structures, it is necessary to
extend the notation. This is a major undertaking. Using combination, the ASN.1 notation is simply
incorporated into the existing data typing facility of the FDT [17]. Clearly this results in duplication of
functionality. In the translation approach, no extension of ASN.1 or the FDT is required. In this case,
ASN.1 is translated into the constructs required by the FDT. A description of the design and problems
encountered in the case of LOTOS is found in [4] and, for the case of Estelle, in [5].
As ASN.1 becomes a standardized language with a large community of users, it is clearly important to
define its formal semantics. There have been efforts to express the semantics of ASN.1 in the abstract
data type language ACT-ONE, which is a sublanguage of the LOTOS FDT using formal, mathematical
semantics. This effort is implicit in the translation approach mentioned above [4], which aims at
exploiting support tools available for each environment. The formalization of the relationship between
ASN.1 and ACT ONE will allow the designers to use existing data descriptions, with their encoding
rules, in LOTOS process descriptions, and also the identification of LOTOS, i.e. ACT ONE data types
which can be compiled into ASN.1 types. A formal semantics for ASN.1 also facilities rigorous
discussions of features and ambiguities within the language and suggestions for improvements. An effort
to develop a complete ACT ONE semantics for ASN.1 is discussed in [35].

5. Extensions and conclusions

ASN.1, with its encoding rules is still a major area of research and development. We have already
mentioned the need for a variety of encoding rules that are more appropriate for a particular
environment. Many areas of ASN.1 itself are also being investigated. For example, many of the macro
definitions are used for defining generic types. It would therefore be more appropriate to have a generic
type facility built into the language itself. A considerable amount of work is continuing within ISO, such
as object classes (which can be used as a replacement for macros), constraint specification, new encoding
rules as well as others [40].
As we have seen, ASN.1 is a powerful tool for defining the data types (its abstract syntax) of an
application protocol. By using this notation we can be independent of any particular programming
language or system and can define very complex application APDUs.
414 G. Neufeld, S. Vuong / ASN.1

W e also have s e e n that A S N . 1 is i n d e p e n d e n t o f t h e e n c o d i n g rules used for t r an sl at i n g A SN .1 v a l u e s

into a bit-serial f o r m a t (the t r a n s f e r syntax). By using a t r a n s f e r syntax, such as d e f i n e d by B E R , the
a ppli c a t i o n can be i n d e p e n d e n t o f any p a r t i c u l a r m a c h i n e i n t e r n a l r e p r e s e n t a t i o n .
A S N . 1 and its e n c o d i n g rules have b e e n u s e d by m a n y O S I applications such as m e s s a g i n g (X.400),
and dir ect o r y service (X.500). It has also b e e n used by less g e n e r a l p r o t o c o l s such as t h e inter-library
loan p r o t o c o l [19]. It will c o n t i n u e to be used in m a n y areas including I S D N .

References

[1] F. Alexandre and P. Malisse, An ASN.1 macro parser prototype, presented at the IFIP WG 5.5 Symposium on Message
Handling Systems and Application Layer Communication Protocols, Zurich Switzerland October, 1990.
[2] Formal methods applied to protocols (FORMAT): a framework for the underlying concepts of communication protocols,
Report no. 4 to the Alvey Directorate, UK, February 1987.
[3] Apollo's Network Computing Architecture (NCA) Data Representation Protocol.
[4] G. v. Bochmann and M. Deslauriers, Combining ASN.1 support with the LOTOS language, in: E. Brinksma, G. Scollo and
C.A. Vissers, eds., Protocol Specification, Testing and Verification. XI June 1989 (North Holland, Amsterdam, 1990).
[5] G. v. Bochmann, D. Ouimet and G. Nedfeld, Implementation support tools for OSI application layer protocols, submitted for
publication, 1990.
[6] CCITT Recommendation X.209, Specification of Basic Encoding Rules for Abstract Syntax Notation One(ASN.1), Geneva,
1987.
[7] CCITT Recommendation X.208, Specification of Abstract Syntax Notation One (ASN.1), Geneva, 1987.
[8] CCITT Recommendation X.226 (ISO 8823 proof F), Presentation Protocol Specification for Open Systems Interconnection for
CCITT Applications", Geneva, 1987.
[9] CCITT, Remote Operations: Part 1 Model, Notation and Service Definition (X.219) and Protocol Specification (X.229).
Version 6, Geneva, 1988.
[10] CCITT Recommendation X.409, Presentation Transfer Syntax and Notation, Message Handling System, CCITT Red Book,
Vol VIII, Fascicle VIII.7, Geneva, 1985.
[11] CCITT Recommendation Z.100, Specification and description language, COM X-R15-E, 1987.
[12] CCITT X.400 Message Handling System, 1984.
[13] CCITT, Working document on ASN.1 extensions (Version1, Salford, June 1989), CCITT SG VII Q19/VII and
JTC1/SC21/WG6 Presentation Rapporteur's Group.
[14] D. Chapman, A tutorial on Abstract Syntax Notation One (ASN.1), Transmission No. 25, Open Systems Data Transfer,
Omnicom information service, Omnicom, Inc., ISSN 0741-286X, December 1986.
[15] D. Deutsch, R. Resnick and J. Vittal. Specification for message format for computer based message systems, Bolt Beranek and
Newman, Report No. 4765R, April 1982.
[16] M. Herlihy and B. Liskov, A value transmission method for abstract data types, ACM Trans. Program. Languages Systems 4 (4)
(1982) 527-551.
[17] T. Hasegawa, H. Horiuchi, T. Kato, K. Suzuki and Y. Urano, Automatic Ada program generation from protocol specification
based on Estelle, 9th International Conference on Computer Communications, Tel Aviv, October 1988, pp. 181-185.
[18] C. Huitema and A. Doghri, "Defining faster transfer syntaxes for the OSI Presentation Layer", ACM Comput. Comm. Rev. 19
(5) (1989) 44-54.
[19l Interlibrary Loan Service Definition (DP 10160) and Protocol (DP 10161).
[20] ISO 3309, High Level Data Link Control International Standards Organization.
[21] ISO 8807, LOTOS--A Formal Description Technique Based on the Temporal Ordering of Observational Behavior, 1989.
[22] ISO 8824, Open Systems lnterconnection--Specification of Abstract Syntax Notation One (ASN.1), International Standard for
Information Processing System, 1987.
[23] ISO DP 8824, Proposed Draft Addendum 1: Extensions to ASN.1, International Standard for Information Processing System,
1987.
[24] ISO 8825, Specification of Basic Encoding Rules for Abstract Syntax Notation One, International Standard for Information
Processing System, Open Systems Interconnection (ASN.1), 1987.
[25] ISO 9074, Estelle: a formal description technique based on an extended state transition model, 1989.
[26] G. Neufeld, EAN: a distributed message system, in: Proc. Canadian Information Processing Society National Meeting, (Ottawa,
May, 1983), pp. 144-149.
[27] G. Neufeld, Design of the EAN X.500 Directory System, in preparation, 1990.
[28] G. Neufeld and Y. Yang, The design and implementation of an ASN.1 to C compiler, IEEE Trans. Software Eng. 16 (10)
(1990) 1209-1220.
[29] J.S. Pascual, A tool for encoding and decoding big ASN.1 messages, in: S.T. Vuong, ed., Formal Description Techniques, II
(North-Holland, Amsterdam, 1990), pp. 19-24.
 G. Neufeld, S. Vuong / ASN.1 415

[30] C. Partridge and M. Rose. A comparison of external data formats, in: E. Stefferud, O.J. Jacobsen and P. Schicker, eds.,
Message Handling Systems and Distributed Applications, IFIP 1989 (North Holland, Amsterdam, 1989) pp. 233-245.
[31] A. Pope, Encoding CCITT X.409 presentation transfer syntax, ACM Commput. Comm. Rev. 14 (4) (1984) 4-10.
[32] IDACOM/UBC Protocol Testing Internal Document. ASN.1 Utility Library For the OSI Protocol Testing Environment,
March 1990.
[33] D. Steedman, Abstract Syntax Notation One: the tutorial and reference, Technology Appraisals Ltd., Grove House, 551
London Road, Isleworth, TW7 4DS, United Kingdom.
[34] Sun Microsystems, Inc., XDR: External Data Representation Standard, (RFC1014) in Internet Working Group Request for
Comments, No. 1014, Network Information Center, SRI International, Menlo Park, CA, June 1987.
[35] M. Thomas, From 1 notation to Another One: An ACT ONE semantics for ASN.1, in: S.T. Vuong, ed., Formal Description
Techniques, II (North-Holland, Amsterdam, 1990) pp. 517-532.
[36] U.S. Department of Commerce, User Guide for the NBS Prototype Compiler for Estelle, Final Report, Report No.
ICST/SNA-87/3, U.S. Department of Commerce, National Bureau of Standards, October 1987.
[37] Wollongong Group, ISODE, The ISO Development Environment: User Manual, Version 6.102 Vols. 1 and 4, The
Wollongong Group, 1129 San Antonio Rd. Palo Alto, CA, USA, February 1990.
[38] XEROX Corp, Courier: the remote procedure call protocol, XSIS-038112, December 1981.
[39] CCITT Recommendation X.500: The Directory - - Overview of Concepts, Models and Services, December 1988.
[40] ISO 8824 Proposed Draft Amendments and Committee Drafts (Parts 1-4), October 1991.