ASN.1
`Communication between Heterogeneous Systems
`
`Olivier Dubuisson
`
`translated from French by Philippe Fouquart
`
`http://asn1.elibel.tm.fr/en/book/
`http://www.oss.com/asn1/booksintro.html
`
`June 5, 2000
`
`Page 1 of 36
`
`

`

`ASN.1
`Communication between heterogeneous systems
`
`by Olivier Dubuisson
`
`ASN.1 (Abstract Syntax Notation One) is an international standard which aims
`at specifying of data used in telecommunication protocols. It is a computing
`language that is both powerful and complex:
`it was designed for modeling
`efficiently communications between heterogeneous systems.
`ASN.1 was in great need of a reference book, didactic as well as precise
`and Olivier Dubuisson’s book meets these demands. The language is compre-
`hensively described from its basic constructions to the latest additions to the
`notation. The description of each of these constructions is wholly accessible
`and accurate. Many case studies of real-world applications illustrate this pre-
`sentation. The text also replaces the language in its historical background and
`describes the context in which it is used, both from the application viewpoint
`and from that of other specification standards which use or refer to ASN.1.
`This book is written by an expert of ASN.1, of its syntax and semantics,
`and clearly constitutes a reference on the language. It is intended for those
`merely interested in finding a complete and reliable description of the language
`and for programmers or experts who may want to look up for the proper usage
`of some constructions. The tools available on the website associated with this
`book will prove useful to both the proficient and the beginner ASN.1 user.
`
`Michel Mauny
`Project leader at INRIA, the French National Institute for Research in
`Computer Science and Control
`
`Olivier Dubuisson is a research engineer at France T´el´ecom R&D, the Research
`& Development centre of France T´el´ecom (formerly known as Cnet), where he is in
`charge of the ASN.1 expertise. He takes part in the language evolution at the ISO
`and ITU-T working groups. He has also developed various editing and analysis tools
`for ASN.1 specifications and assists the ASN.1 users at France T´el´ecom in numerous
`application domains.
`
`Philippe Fouquart graduated from Aston University, UK with an MSc in Computer
`
`Science and Applied Maths in 1997. He worked for Cnet on ASN.1:1994 grammar and
`
`later joined France T´el´ecom R&D in 1999 where he used ASN.1 for Intelligent Net-
`
`work and SS7 protocols. He is now working on Fixed-Mobile Converged architectures
`
`and IP mobility.
`
`ISBN:0-12-6333361-0
`c(cid:176) OSS Nokalva, 2000
`All rights reserved.
`No part of this publication may be reproduced or transmitted in any form or by any means, electronic
`or mechanical, including photocopy, recording, or any information storage and retrieval system, without
`permission in writing from the owner of the copyright.
`
`Page 2 of 36
`
`

`

`Part I
`
`Introduction and History
`of the Notation
`
`Page 3 of 36
`
`

`

`Chapter 1
`
`Prologue
`
`“Mr. Watson, come here; I need you!”
`
`Alexander G. Bell, 10 March 1876.
`
`Melville Bell, teacher of elocution at the University of Edinburgh ac-
`quired a worldwide reputation not only as an expert on correct pronun-
`ciation but also as the inventor of ‘Visible Speech’ [Bel67], a written
`code1 providing a universal alphabet — some may say an abstract no-
`tation —, describing the precise positions and the respective actions of
`the tongue, the throat and the lips while speaking (see Figure 1.1 on
`the following page). This code published in 1867 [Bel67] was initially
`meant to make foreign languages — the abstract syntaxes — pronunci-
`ation easier since it provided a way to link one language to another. It
`finally proved more useful for teaching diction to deaf people.
`In 1862, 15-year-old Alexander Graham, Melville Bell’s son2, uttered
`strange sounds that his father had written in ‘Visible Speech’ while he
`was out of the room — using the speech basic encoding rules, Alexander
`associated a transfer syntax with the abstract syntax his father specified.
`A year later, Alexander and his older brother Melly built a talking
`machine out of a fake skull of gutta-percha filled with cans, rubber, and
`a lamb’s larynx to make up the vocal parts. They then blew through it,
`making it cry out “Ma-Ma! ”.
`
`1The set of characters can be found at http://www.indigo.ie/egt/standards/csur/
`visible-speech.html.
`2A short story of Graham Bell and some photos are available at:
`http://www.garfield.k12.ut.us/PHS/History/US/1877/inv/alex/default.html.
`
`Page 4 of 36
`
`

`

`4
`
`ASN.1 – Communication between Heterogeneous Systems
`
`Figure 1.1: The three organs represented by ‘Visible Speech’:
`lips (Fig. 2 ), the tongue (Fig. 3 ) and the throat (Fig. 4 )
`
`the
`
`Page 5 of 36
`
`

`

`1 - Prologue
`
`5
`
`During the following years, Alexander helped his father teach the
`‘Visible Speech’ code, particularly at institutes for deaf people, but he
`also took to studying vocal physiology. This work incited him to investi-
`gate ways to reproduce vocal sounds so that these could be transmitted
`electronically.
`
`Alexander built up devices in which a first series of blades — the
`encoder — vibrated in resonance with basic sounds emitted by speech;
`these emitting blades drew to resonance a second series of blades using
`an electromagnet — the decoder. In fact, this work was more related to
`experiments of transmitting sounds both ways on a single line using a
`‘harmonical’ system.
`
`In 1874, Alexander invented the ‘phonautograph’3 — another kind
`of receivor — a device that could transcribe sounds into concrete signs:
`when words were pronounced, the ear membrane of a dead person vi-
`brated and moved a lever on a tinted glass.
`
`In July 1874, as Alexander wondered whether such a membrane could
`produce an electrical current whith an intensity that would vary accord-
`ing to the sound waves, he drew out the basics of the telephone in
`principle. It was patented in March 1876 at the U.S. Patent Office un-
`der the reference 174,465; it was modestly entitled “Improvements in
`Telegraphy” [Bro76].
`
`On the 10th of March 1876, after several unconclusive attempts,
`Alexander uttered in his device the historical words, “Mr. Watson, come
`here; I need you!”, which were heard by his workmate Thomas A. Watson
`in the receiver located in a distant room and set up the first phone
`conversation ever in history.
`
`That is how the development of an abstract syntax notation brought
`about this amazing invention that changed the world...
`
`3http://jefferson.village.virginia.edu/∼meg3c/id/albell/ear.2.html
`
`Page 6 of 36
`
`

`

`6
`
`ASN.1 – Communication between Heterogeneous Systems
`
`Before we leave this historical prologue and plunge into the core of
`the matter, we suggest the reader to stop off at this stage for a while,
`and ponder over this allegory of communications between heterogeneous
`systems...
`
`Page 7 of 36
`
`

`

`Chapter 2
`
`Utilitarian introduction to
`ASN.1
`
`Contents
`
`. . . . . . . . . .
`2.1 A diversity of machine architectures
`2.2 A diversity of programming languages . . . . . . . . .
`2.3 Conversion programs . . . . . . . . . . . . . . . . . . . .
`2.4 The triad: concrete syntax, abstract syntax, transfer
`syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`8
`10
`11
`
`12
`
`idea’, he
`‘Just to give you a general
`would explain to them. For of course some
`sort of general idea they must have, if they
`were to do their work intelligently – though
`as little of one,
`if they were to be good
`and happy members of society, as possible.
`For particulars, as every one knows, make
`for virtue and happiness; generalities are
`intellectually necessary evils. [...]
`said
`‘I shall begin at the beginning’,
`the D.H.C., and the more zealous students
`recorded his intention in their note-books:
`Begin at the beginning.
`
`Aldous Huxley, Brave New World.
`
`Adopting an approach somewhat inspired by maieutics, we propose to
`draw out the reasons that lead to the definition of a notation such as
`
`Page 8 of 36
`
`

`

`8
`
`ASN.1 – Communication between Heterogeneous Systems
`
`ASN.1. This chapter requires no prior knowledge of the 7-layer OSI
`model (the way ASN.1 finds its place in this model is described in the
`next chapter); a few notions about programming languages’ grammars
`may prove useful for the first part.
`This chapter introduces the underlying concepts and fundamental
`principles of ASN.1 used, sometimes implicitly, throughout this book.
`The main concepts of the notation are thoroughly described in Chap-
`ter 5.
`
`2.1 A diversity of machine architectures
`
`History has proved that data information is crucial, especially for cul-
`tural exchanges at first and then for developing an international econ-
`omy. And more and more computing applications of all kinds are ex-
`changing ever more complex data. Only think about banking exchange
`applications or airlines that have to manage bookings, staffs, routes,
`planes, maintenance, etc. or even mail order companies, which need to
`transfer data from their headquarters to their store houses, to make out
`the tremendous complexity of the data structures involved.
`Contrary to common belief, these exchanges, though initially sped
`up by information technologies and then reinforced by the increase of
`telecommunication networks, have not simplified their structures.
`In-
`deed, networks and computers constitute a more and more heteroge-
`neous world: computers can have different internal representation modes
`for the data they store. For example, a great majority uses the ASCII
`encoding1, but some mainframes, such as IBM’s, handle EBCDIC en-
`coding. Most of PCs use 16 or 32-bit memory-word in two’s complement
`arithmetic but some mainframes, sailing out of the mainstream, use 60-
`bit word in one’s complement arithmetic for instance.
`A much more insiduous difference is the following: x86 Intel chips,
`for example, order the bits of a byte from right to left whereas Motorola
`does just the opposite. It makes Danny Cohen [Coh81]2 call Intel a ‘little
`
`1Neither ASCII nor EBCDIC alphabets nor one’s nor two’s complement will be
`described here. They are used only for the sake of illustration. These notions are not
`necessary for understanding this chapter and can be found in [Tan96] for example.
`2It is worthwhile noticing that this article brings us back to 1981, that is, before
`the creation of ASN.1 (see Section 6.3 on page 60). Incidentally, it ends with the
`visionary sentence: “Agreement upon an order [of bits] is more important than the
`order agreed upon”. Isn’t ASN.1 this final agreement, after all?
`
`Page 9 of 36
`
`

`

`2 - Utilitarian introduction to ASN.1
`
`9
`
`The Annotated Gulliver’s Travels
`Illustration by Willy Pogßny (1919) ; Isaac Asimov Editor
`Clarkson N. Potter, Inc., New York (1980)
`
`(courtesy of Random House, Inc.)
`
`Figure 2.1: Battle between big Endians and little Endians!
`
`Endian’ (the number 0 low-weighted byte is on the right-hand side) and
`Motorola a ‘big Endian’3, referring to theological arguments between
`Catholics and Protestants in Swift’s Gulliver’s Travels as to whether
`boiled eggs should be broken at the top or the bottom! (See Figure 2.1.)
`This question does not come up only for eggs:
`[Tan96] mentions the
`case of an unfortunate ‘stegosaurus’ that once transferred from a ‘little
`Endian’ to a ‘big Endian’ machine, ended up with an exotic name and
`a length of 167,772 meters!
`To prevent the ‘big Endians’ manufacturers (or the ‘little Endians’
`manufacturers if you are on the ‘big Endians’ side’) from being ban-
`ished to remote Blefuscu Island4 where communicating with the ‘little
`Endians’ is no longer possible, the latter would have to adopt the for-
`mer’s convention. But we know that, in order to avoid any compatibility
`malfunctions in their own products or even to preserve their position of
`hegemony in the market, few manufacturers would be inclined to sign
`such an armistice. And it is highly unlikely — some of the latter will
`definitely not regret it! — that one day some standard would define once
`for all an international internal data representation mode...
`
`3Another example: the IP protocol is big Endian, the VAX computers are little
`Endians.
`4In Swift’s book, Blefuscu stands in for Louis XIV’s ‘so very Catholic France’ !
`
`Page 10 of 36
`
`

`

`10
`
`ASN.1 – Communication between Heterogeneous Systems
`
`typedef struct Record {
`char name[31];
`int
`age;
`enum { unknown=0;
`male=1;
`female=2 } gender;
`} Record;
`
`type record = {
`name
`:
`string;
`age
`:
`num;
`t gender }
`gender :
`and t gender
`= Unknown
`| Male
`| Female
`
`(a) C code
`
`(b) Objective Caml code
`
`Figure 2.2: Data structure in two computing languages
`
`2.2 A diversity of programming languages
`
`This heterogeneousness of machine architectures goes along with a great
`diversity in programming languages. For example, some data may be
`represented by an array of integers in one language and by a list of
`integers in another. Besides, a language may use its own representation
`in the internal memory: in C language, for instance, the ‘\0’ character
`is added at the end of a string and programmers are free for their own
`defined boolean values because none exists by default.
`For example, a data structure including a name declared as a 30-
`character string, a positive integer for the age, and the gender (male,
`female or unknown) may be represented as in Figure 2.2, in two very
`different ways in C and Objective Caml5.
`Note in particular that:
`
`• the field name ends with a NULL byte in C but not in Objective
`Caml ;
`
`• the name field size is not limited in Objective Caml ;
`• nothing is known about the internal representation of age (one’s
`or two’s complement?...);
`
`• the default values (provided they exist) of the enumerated type
`variables are unknown in Objective Caml.
`
`5Objective Caml
`http://caml.inria.fr.
`
`is a language of the ML family;
`
`it can be downloaded from
`
`Page 11 of 36
`
`

`

`2 - Utilitarian introduction to ASN.1
`
`11
`
`These remarks bring up the following questions:
`
`• do we have to keep the terminating null byte when transferring
`data? Does the C program have to skip out these values? Or is it
`up to the Objective Caml program to add it before transferring?
`
`• How can we transfer the gender of a person without one of the
`three identifiers as a string (which can be arbitraly long) while
`keeping the ‘semantics’ (that is, the common acceptance of the
`identifier)?
`
`The reader should now be convinced of the necessity of a transfer
`notation together with the need of conversion programs to and from this
`notation.
`
`2.3 Conversion programs
`
`Bearing in mind the variety of internal data representations we have just
`described, how does one make n machines ‘converse’ ?
`We could decide, as in Figure 2.3(a) on the following page, that every
`machine knows the internal data representation of its (n−1) neighbors so
`that the data formats is agreed to be the receiver’s or sender’s6. Should
`the dialog take place both ways, this would require n(n − 1) conversion
`programs. This kind of communication has the undeniable advantage of
`translating data only once during the transfer. Although it could have
`been a decisive argument when processing time was a limiting factor, it
`is no longer relevant for today’s data transfer.
`We could also make up a common transfer format that would need
`to be agreed upon among different machines (or even better, standard-
`ized at an international level...). From Figure 2.3(b) on the following
`page it follows that n encoders and n decoders (2n conversion programs
`altogether) would be needed, which is obviously smaller than n(n − 1)
`when n, the number of machines, is greater than 3.
`In addition, if these 2n programs could be automatically generated,
`a significant gain would be obtained in terms of efficiency (no specific
`development) and reliability (no possible misinterpretation during the
`encoder/decoder implementation).
`
`6The NIDL notation from Apollo Computer, which is described in Section 24.2 on
`page 490, is a good example of symmetrical communication.
`
`Page 12 of 36
`
`

`

`12
`
`ASN.1 – Communication between Heterogeneous Systems
`
`ASN.1
`
`(a) symmetrical
`
`(b) asymmetrical
`
`Figure 2.3: Two types of communications
`
`2.4 The triad: concrete syntax, abstract syn-
`tax, transfer syntax
`
`Now that the problematics has been set out, let us draw up a synthesis
`and introduce some definitions.
`We call concrete syntax, the representation, in a given programming
`language, of the data structures to be transferred. It is a ‘syntax’ be-
`cause it respects the lexical and grammatical rules of a language (C for
`instance); it is called concrete because it is actually handled by appli-
`cations (implemented in this very language) and it complies with the
`machine architectures’ restrictions. Two examples of concrete syntaxes
`have been given in Figure 2.2 on page 10.
`In order to break free of the diversity of concrete syntaxes men-
`tioned above, the data structures to be transmitted should be described
`regardless of the programming languages used. This description should
`also respect the lexical and grammatical rules of a certain language
`(guess which language) but should remain independent from program-
`ming languages and never be directly implemented on a machine. For
`these reasons, we call abstract syntax such a description and Abstract
`Syntax Notation or ASN 7 the language whereby this abstract syntax is
`denoted.
`
`7The meaning of 1 in ASN.1 is given in Chapter 6.
`
`Page 13 of 36
`
`

`

`2 - Utilitarian introduction to ASN.1
`
`13
`
`Though independent from programming languages, the abstract syn-
`tax notation should be at least as powerful as any language’s datatype8
`formalism, that is, a recursive notation that allows building complex
`data types from basic types (equivalent to the string, int, enum... C
`types for instance) and type constructors (equivalent to struct, union...
`in C ).
`Many different messages can be exchanged between applications.
`The abstract syntax would then describe in a more condensed way the
`whole set of these messages. For this, the abstract syntax is defined by
`means of a grammar that data to be transferred should respect. Other-
`wise said, one should bear in mind the two levels of grammars [ASU86]:
`first, the grammar of the ‘ASN’ abstract syntax notation itself; second,
`the abstract syntax, which is also a grammar9 and is defined using the
`former.
`This abstract syntax notation must be formal to prevent all ambigui-
`ties when being interpreted and handled by computing tools as described
`at the end of this chapter. Drawing a parallel with language theory, the
`abstract syntax notation can be seen as a BNF (or Backus-Naur Form)
`that allows one to write specific grammars, which are called abstract
`syntaxes in a data transfer context. In a nutshell, ASN.1 is not an ab-
`stract syntax10 but a language to describe them.
`
`Referring now to a more general concept of ‘circulation of immaterial
`streams’, it is only the material component of a piece of information that
`is involved in the communication. It is not the sense that is conveyed
`but its material representation which, in essence, is of a physical nature.
`In other words, the form is conveyed but not the content.
`It is only
`when this representation arrives on the receiver’s side that it takes on
`its full meaning.
`For the same reason, the abstract syntax defines precisely the data
`structure but says nothing about the associated semantics, viz., the
`interpretation of these data by the application (thus by its programmer):
`what meaning should we associate with a TRUE boolean value? What
`
`8We should stress on the word datatype because an ASN.1 specification is only a
`static description of the data; it cannot describe the operations to be applied to these
`data.
`9The language defined by this second grammar is the set of all the values that can
`be transferred.
`10This a very common (though harmless) confusion made by ASN.1 users.
`
`Page 14 of 36
`
`

`

`14
`
`ASN.1 – Communication between Heterogeneous Systems
`
`am I supposed to do if no value is assigned to a field? Many questions to
`remain unanswered because they do not fall within the competence of
`data transfer but are resolved when the data is used by the application11.
`The semantic part is described, if necessary, by means of comments
`within the abstract syntax or using an explanatory text associated with
`it.
`
`We have seen in Section 2.3 on page 11 and in Figure 2.3(b) on
`page 12, the advantages of a data transfer which is independent from
`the machine architectures. As for the data received as byte streams
`or bits, they comply with a syntax called transfer syntax so that these
`streams could be properly recognized by the peer machine.
`Of course, this transfer syntax thoroughly depends on the abstract
`syntax, since it sets up how the data should be transmitted according to
`this abstract syntax. In fact, the transfer syntax structures and orders
`the bytes (the ‘formant’) that are sent to the other machine (this process
`is sometimes called ‘marshalling’). But contrary to the abstract syntax,
`it is a physical quantity and, because of that, it should take into account
`the ordering of the bytes, the weight of the bits, etc.
`Different transfer syntaxes can be associated with a single abstract
`syntax. This is particularly interesting when the throughput increases
`and makes more complex encoding necessary: in such a case, however, it
`is possible to change the transfer syntax without changing the abstract
`syntax.
`If we now come back to the example in Figure 2.2 on page 10, we end
`up with the four syntaxes of Figure 2.4 on the next page (one abstract
`syntax, two concrete syntaxes and one transfer syntax). The dashed
`arrows set out the links that exist between the abstract syntax and the
`concrete syntax.
`From a single ASN.1 data description, we can derive automatically
`as many concrete syntaxes (i.e. in as many programming languages) as
`necessary, and as many procedures implementing the transfer syntax in
`encoders (which encode the data into a bit or byte stream) and decoders
`as we want.
`As described in Chapter 22 (more particularly in Figure 22.2 on
`page 465) it is an ASN.1 compiler that carries out the automatic gen-
`eration for us according to the dotted arrows in Figure 2.4 on the next
`page, thus sparing considerable effort and meanwhile making it possible
`
`11Nevertheless, we will see in Chapter 15 that since 1994, information object classes
`can formalize strong semantic links which can be really convenient for the users.
`
`Page 15 of 36
`
`

`

`2 - Utilitarian introduction to ASN.1
`
`15
`
`Abstract syntax in ASN.1
`Record ::= SEQUENCE {
`name
`PrintableString (SIZE (1..30)),
`age
`INTEGER,
`gender ENUMERATED { unknown(0),
`male(1),
`female(2) } }
`
`Machine A
`Concrete syntax in C
`typedef struct Record {
`char name[31];
`int
`age;
`enum { unknown=0;
`male=1;
`female=2 } gender;
`} Record;
`
`transfer syntax
`
`(bytes or bits)
`
`Machine B
`Concrete syntax in Objective Caml
`type record = {
`name
`:
`string;
`age
`:
`num;
`t gender }
`gender :
`and t gender
`= Unknown
`| Male
`| Female
`
`Figure 2.4: An example of syntax triad
`
`to inter-connect any number of machines (as in Figure 2.3(b) on page 12).
`The compiler should be implemented with some encoding rules, which
`describe the links between the abstract syntax and the transfer syntax12.
`
`12Many standards (including [ISO8822] on the Presentation service definition for
`example) sometimes do not distinguish the notion of a transfer syntax from that of
`encoding rules. We may equally use one or the other in the next chapters whenever
`it remains unambiguous.
`
`Page 16 of 36
`
`

`

`16
`
`ASN.1 – Communication between Heterogeneous Systems
`
`Page 17 of 36
`
`

`

`Chapter 3
`
`ASN.1 and the OSI
`Reference Model
`
`Contents
`
`3.1 The 7-layer OSI model . . . . . . . . . . . . . . . . . . .
`3.2 The Presentation layer . . . . . . . . . . . . . . . . . . .
`3.3 The Application layer . . . . . . . . . . . . . . . . . . .
`3.4 The OSI model in the future . . . . . . . . . . . . . . .
`
`18
`20
`24
`26
`
`ranks of a
`intermediate
`Should the
`monarchy be removed, there would be too
`far from the monarch to the subjects; soon
`afterwards one would see only a despot and
`some slaves: preserving a graduated scale
`from the ploughman to the potentate equally
`concerns all men, whatever their ranks, and
`can be the strongest support of a monarchist
`constitution.
`
`Beaumarchais, Le Mariage de Figaro.
`
`Having described the benefits of ASN.1 a priori, we now come to its role
`in the OSI model. After a short introduction on the 7-layer OSI model,
`we shall discuss in greater length the layers 6 (called Presentation) and 7
`(Application) in the context of which the notions of transfer syntax and
`abstract syntax introduced in the previous chapter will be re-defined.
`
`Page 18 of 36
`
`

`

`18
`
`ASN.1 – Communication between Heterogeneous Systems
`
`7th layer
`
`Application
`
`6th layer
`
`Presentation
`
`7th layer
`
`protocol
`
`protocol
`Interface between
`6th layer
`
`Application
`
`APDV
`
`the 6th and 7th layers
`
`Presentation
`
`PPDV
`
`5th layer
`
`Session
`
`Session
`
`SPDV
`
`4th layer
`
`Transport
`
`Transport
`
`TPDV
`
`3rd layer
`
`Network
`
`Network
`
`Packets
`
`2nd layer
`
`Data link
`
`Data link
`
`Frame
`
`1st layer
`
`Physical
`
`Physical
`
`Bit
`
`Figure 3.1: 7-layer OSI model. Example of information streams
`
`OSI physical support
`
`The main point of this chapter is to put ASN.1 in its historical back-
`ground. ASN.1, however, should not be taken as being limited to this
`very domain: though historically related to the OSI model, we shall see
`in Chapter 7 that ASN.1 is actually used in many applications that are
`not based on this 7-layer model.
`
`3.1 The 7-layer OSI model
`
`Telecommunication networks are modeled by a graded order of hierar-
`chical layers to make standardization and conception easier. The role
`of each layer is to provide services to the layer above, relying on those
`offered by the layer below. The higher the layer, the more services it
`can offer (but the more abstract their definitions are!) and the less im-
`portant the way data are conveyed becomes. The most famous network
`architecture is the Open Systems Interconnection model or OSI model,
`which features 7 layers as shown in Figure 3.1.
`It is standardized at
`ITU-T under the name “Recommendation X.200” and at ISO under the
`reference [ISO7498-1].
`
`Page 19 of 36
`
`

`

`3 - ASN.1 and the OSI Reference Model
`
`19
`
`The OSI model goes from the lowest level of signalling techniques up
`to high level interactions between specific applications1. In the increas-
`ing order, i.e. from bottom to top in Figure 3.1 on the preceding page,
`these seven layers are:
`
`• the Physical layer, in charge of the interface between systems and
`the physical support, deals with the transmission of bits.
`It is
`concerned with the voltage required to represent a single bit, the
`duration of a bit representation in milli-second, the transmission
`both ways if needed and other issues of electrical and mechanical
`matter;
`
`• the Data Link layer ensures the transmission of information using
`error correction and splitting the data into frames (set of bits);
`since the physical layer transmits bit streams without knowing
`its structure, it is down to the Physical Layer to mark up the
`beginning and the end of the frame;
`
`• the Network layer manages the routes (statically and dynamically)
`to be taken by the packets (set of frames) to go from one equipment
`to another;
`
`• the Transport layer ensures that the data are transmitted at the
`right throughput and that they are correctly collected on the re-
`ceiving side. It also makes all technology or equipment changes
`transparent to the Session layer;
`
`• the Session Layer manages the exchange sessions between two ma-
`chines: dialog tokens indicating which is emitting, synchronization
`to carry on a transmission where it was interrupted...;
`
`• the Presentation layer is interested in the syntax of the data to be
`transmitted. It is in charge of encoding them according to given
`rules that have been agreed on beforehand;
`
`• the Application layer is concerned with frequently used application
`protocols such as file transfer, electronic mail, remote login...
`
`The layer n of a machine can speak to the layer n of another providing
`the dialog complies with certain rules and conventions specific to this
`
`1But little interest has been shown so far to include the layers 8 (Financial ) and 9
`(Political ) in the standardized model!
`
`Page 20 of 36
`
`

`

`20
`
`ASN.1 – Communication between Heterogeneous Systems
`
`level. The collection of these rules constitutes the ‘n-layer protocol2’.
`The data transmitted by an application that is running on the first
`machine should go through the layers down to a medium link. A header
`(and an ending mark if required) is added to the data each time it crosses
`a new layer. In other words, the n + 1 layer states out how the gap in
`the n-level data should be filled.
`For each layer of the model, two international standards can be
`found: the first describes the service provided by this layer (and defines
`the terms and the notation it uses), the second describes its protocol,
`i.e. the rules any implementation should respect.
`We shall not proceed further with our overview of the OSI model.
`The interested reader should find enough material to satisfy any avid
`curiosity in [Tan96], [PC93], [Bla91] or [Lar96]. We will go now into more
`detail about the top two layers (called Presentation and Application
`layers) of the OSI model.
`
`3.2 The Presentation layer
`
`The Presentation layer is the sixth layer of the OSI model; it is described
`in the standards [ISO8822] and [ISO8823-1] (among others). It assumes
`that a ‘route’ exists between two machines, that it provides the ade-
`quate quality of service and that all the functions potentially needed are
`available in the low level layers.
`Its main role is to ensure the encoding and decoding of the data.
`As previously seen in Section 2.1 on page 8, the data representation
`(integers, real numbers, strings...) depends on the machine so that a
`common representation is required for exchanging the data. The pre-
`sentation layer provides the data to be transmitted with this structure
`but is not concerned in the semantics of the information.
`To make two speakers converse, we need first to share a common
`knowledge (a dictionary) and second, we have to agree on a language
`before starting a conversation using preliminaries such as:
`
`— Do you speak English? Parlez-vous fran¸cais ? Te parau
`anei ’oe i te reo Tahiti ?
`— Je parle fran¸cais. I speak English.
`— Let’s speak English then!
`
`2Like those of etiquette and precedence to be respected in ceremonies or official
`protocols!
`
`Page 21 of 36
`
`

`

`3 - ASN.1 and the OSI Reference Model
`
`21
`
`Likewise, two systems that communicate should negotiate a common
`encoding (BER, PER...) before transmitting the data. It is the role of
`the Presentation layer to negotiate this encoding and to actually encode
`the information exchanged between the two applications that cooperate.
`For doing so, the Presentation layer makes use of the following con-
`cepts:
`
`• the abstract syntax, which defines the generic structure of the data
`(the various types of data involved) and constitutes the framework
`on which relies the dialog with the Application layer (for example,
`the data include a component of type boolean and another one of
`type integer, which is optional);
`
`• the concrete syntax is local and defines the data representation
`in the local system (for example, a C -language implementation of
`the types above mentioned);
`
`• the transfer syntax defines the data representation exchanged be-
`tween the respective Presentation layers of the two systems thanks
`to their Session layers;
`
`• the encoding rules provide a means of going from the local concrete
`syntax to the transfer syntax and reverse (for example, all the
`data are encoded as triplets (cid:104)data type, data length, data value(cid:105);
`boolean values are encoded on a byte with the value 1 or 0...).
`
`Using these notions, we could say that the Presentation layer pro-
`vides the following services to the Application layer:
`• negotiation3 of the transfer syntax (a means of choosing one at the
`beginning of the dialog and a way to change it);
`• identification of a collection of transfer syntaxes (i.e. several ways
`of representing the abstract syntax);
`• translation, using the encoding and decoding rules of the concrete
`syntax (internal representation mode), into the transfer syntax
`(external representation mode) and reverse;
`• association of a negotiated transfer syntax to the abstract syntax
`adopted within the applications;
`• access to the Session layer’s services.
`3If the transfer is in ‘no connection’ mode, the transfer syntax is not negotiated;
`the sender chooses it arbitrarily.
`
`Page 22 of 36
`
`

`

`22
`
`ASN.1 – Communication between Heterogeneous Systems
`
`Application A
`
`Application B
`
`1.
`
`P-CONNECT
`.request (AS1,AS2)
`
`6.
`
`P-CONNECT
`.confirm (AS2)
`
`3.
`
`P-CONNECT
`.indication (AS1,AS2)
`
`4.
`
`P-CONNECT
`.response (