eindhoven university of technology master an architecture

Eindhoven University of Technology

MASTER

An architecture for an OSI-protocol (layer 6)

Verhaak, P.C.H.M.

Award date:1991

Link to publication

DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

https://research.tue.nl/en/studentTheses/5ec016b6-d403-4587-b4e6-a32775b62b06

Coach:Supervisor:

£6300

r':() <"/...)('(v

An architecture for anOSI-protocol (layer 6)

P.C.H.M. Verhaak

Faculty of Electrical EngineeringDigital Information Systems Group

Eindhoven University of Technology

Eindhoven, december 1991

ir. M.J.M. van WeenProf. ir. M.P.J. Stevens

The department of Electrical Engineering of the Eindhoven University of Technology does not accept anyresponsibility regarding the contents of student project- and graduation reports.

Abstract.

At the Digital Infonnation Systems Group of the Department of Electrical Engineering at theEindhoven University of Technology research has started on the development of the sixth layer of theOSI reference model: the presentation layer.

This thesis contains a full review of the presentation layer, as well as the manner this layer can bemodeled using the method of Hatley and Pirbhai.

The presentation layer is concerned with the preserving of the meaning of the data to be exchangedbetween two peer application entities, not with the bit pattern. To maintain the meaning of the data,the presentation layer uses two kind of syntaxes: the abstract syntax and transfer syntax. The abstractsyntax is used to describe the data types to be transferred between two application entities. The transfersyntax is used by the presentation layer to perfonn a translation of the data, described by an abstractsyntax. The pairing of an abstract syntax and transfer syntax is called a presentation context. Whichpresentation contexts are being used during a connection, is negotiated between the peer applicationand presentation entities. The resulting sets of active presentation contexts is called the defined contextset (DCS).

The presentation layer can be modeled using three major subprocesses: the presentation protocolmachine, the context management and the encoder/decoder. The presentation protocol machine takescare of the communicating aspects of the presentation protocol, the context management keeps trackof the DCS during a connection, and the encoder/decoder encodes or decodes data into or from abitstream using the correct abstract and transfer syntax.

In tum the encoder/decoder process can be modelled roughly utilising three subprocesses: a parserprocess, a deparsing process and a process which contains a microprocessor. The parsing processparses the data from the application layer and puts the result into a value tree. The deparsing processperfonns the reverse task. The micro processor accomplishes the actual encoding or decoder procedure,that is from the value tree into a bitstream or vice versa. This encoding or decoding procedure of themicro processor is executed using a routine which is made according the proper abstract and transfersyntax.

Development of the presentation protocol machine and the context management is still being done byM.e.A. Hurkmans and will be reported in his thesis.

Abstract. iii

Contents.Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. vii

List of figures. ix

List of tables. xi

1. Introduction 1

2. The OSI reference model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 32.1 Layer hierarchy and functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Layer interaction. 4

2.2.1 Interaction between peer entities. 42.2.2 Interaction between adjacent entities. . . . . . . . . . . . . . . . . . . . . . . . . .. 5

2.3 Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 62.4 Summary. 8

3. The task of the Presentation Layer. 93.1 Data representations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 93.2 Data compression. 113.3 Network security and privacy. 113.4 Summary. 12

4. The abstract syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1 Abstract Syntax Notation 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 The ASN.l Primitive types. ..... . . . . . . . . . . . . . . . . . . . . . . . . .. 144.1.2 The ASN.l Constructors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.3 The ASN.l quasi-primitive types. . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1.4 OPTIONAL and DEFAULT. 174.1.5 Tagging. 174.1.6 Value notations in ASN.l 19

4.2 The principle of abstract syntaxes in the Presentation Layer. 194.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5. The Transfer syntax. 215.1 Basic Encoding Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21

5.1.1 The Identifier octets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.2 The length octets. 235.1.3 The contents octets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 245.1.4 Example of B.E.R. 25

5.2 Other transfer syntaxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.3 The defined context set. 275.4 Summary. 29

Con~n~. v

6. The presentation protocol machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 316.1 The Presentation Service primitives. 316.2 The session service primitives. 326.3 The services of the presentation layer. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33

6.3.1 Connection establishment and release. 346.3.2 Context management 356.3.3 Data transfer. 36

6.4 The Presentation Protocol Data Units. 366.5 Summary 37

7. Formal description method. 397.1 The requirements model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 397.2 The architecture model. 42

7.2.1 The architecture modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 427.2.2 The components of the architectural model. 43

7.3 The CASE tool ProMod. 447.4 Summary 45

8. Modelling the Presentation Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 478.1 The context diagram of the presentation layer. 478.2 The flow diagram of level 1. 498.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 50

9. ModelIing the encoder/decoder. 519.1 The alternatives for an encoder/decoder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52

9.1.1 Alternative 1. 529.1.2 Alternative 2. 559.1.3 Alternative 3. 569.1.4 Choosing an alternative. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 56

9.2 The model of the encoder/decoder. 569.2.1 The value tree and parser/deparser. 579.2.2 The encoder/decoder micro processor. 589.2.3 The testing for the context set. 60

9.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 60

to. Conclusions and recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6110.1 Conclusions. 6110.2 Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 62

11. Literature. 63

Appendix A: ProMod structured analysis report. 63

vi Contents.

Abbreviations.

ACDAFDAIDAISAMSAPDUASN.lBERceoCCITICDCPOCSCSPECDCDDCSDFDFDFUICIIDUISOMSPOSIPCIPCDLPCDRLPDUPICIPIDUPPCIPPDUPPMPSAPPSAPIPSDUPSPECSAPSAPISDUSICISIDUSSAPSSAPISSDUTLV

Abbreviations.

Architectural Context DiagramArchitectural Flow DiagramArchitectural Interconnect DiagramArchitectural Interconnect SpecificationArchitectural Module SpecificationApplication Protocol Data UnitAbstract Syntax Notation OneBasic Encoding RulesControl Context DiagramInternational Telegraph and Telephone Consultative CommitteeContext DiagramControl Flow DiagramContext SetControl SpecificationData Context diagramDefined Context SetData Flow DiagramFlow DiagramsFunctional UnitInterface Control informationInterface Data UnitInternational Standards OrganisationMini SpecificationOpen Systems InterconnectionProtocol Control InformationPresentation Context Definition ListPresentation Context Definition Result ListProtocol Data UnitPresentation Interface Control InformationPresentation Interface Data UnitPresentation Protocol Control informationPresentation Protocol Data UnitPresentation Protocol MachinePresentation Service Access PointPresentation Service Access Point IdentifierPresentation Service Data UnitProcess SpecificationsService Access PointService Access Point IdentifierService Data UnitSession Interface Control InformationSession Interface Data UnitSession Service Access PointSession Service Access Point IdentifierSession Service Data UnitType, Length, Vale

vii

List of figures.Figure 2.1 The 7 layered OSI model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3Figure 2.2 Encapsulation of POUs. 4Figure 2.3 OSI Layer Components 5Figure 2.4 The seJVice primitives of a confirmed seJVice. . . . . . . . . . . . . . . . . . . . . . . . . . .. 7Figure 2.5 The seJVice primitives of a indication seJVice. . . . . . . . . . . . . . . . . . . . . . . . . . .. 8Figure 3.1 The place of the presentation layer in the OSI-mode1 . . . . . . . . . . . . . . . . . . . . .. 9Figure 5.1 The X.209 Data Elements. 22Figure 5.2 X.209 Identifier. 22Figure 5.3 Length octets. 23Figure 5.4 Encoding of bitstring 24Figure 6.1 Model of the Presentation layer. 31Figure 6.2 The two types of presentation seJVice. 31Figure 7.1 Components of the requirements model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 40Figure 7.2 An example of a context diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 40Figure 7.3 An example of a flow diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41Figure 7.4 The template of an architecture module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 42Figure 7.5 The architecture model components. 43Figure 7.6 The ProMod project model. 44Figure 8.1 Context flow diagram variant 1. 47Figure 8.2 Context flow diagram variant 2. 47Figure 8.3 The context diagram of level 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 49Figure 9.1 Inputs and outputs for the encoder/decoder. 51Figure 9.2 Two-phases encoder/decoder. 51Figure 9.3 Memory allocation of the application data. 52Figure 9.4 An example of a type tree. 53Figure 9.5 Value table for John Smith's personnel record. 54Figure 9.6 Encoding with a type tree. 55Figure 9.7 The data flow diagram of the encoder/decoder. . . . . . . . . . . . . . . . . . . . . . 56Figure 9.8 The value tree witch additional information. . . . . . . . . . . . . . . .. 57Figure 9.9 The actual structure of the value tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Figure 9.10 The compiling process of transfer routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

List offigures. ix

List of tables.Tabe14.1 The ASN.l primitive types. 14Tabe14.2 The principal ASN.l constructors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Tabe14.3 The ASN.l quasi-primitive types. . . . . . . . . . . . . . . . . . . . . . . . . 16Tabel 4.4 The four types of tags. 17Tabel 4.5 The tags of the UNIVERSAL types. . . . . . . . . . . . . 17Tabel 6.1 The OSI Presentation Service Primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Tabel 6.2 The OSI Session Service Primitives. . . . . . .. 33Tabel 6.3 Mapping of PSDUs on SSDUs. 33Tabel 6.4 The presentation-PPDU's with their primitives. 37Tabel 6.5 Mapping of PPDUs on SSDUs. 37

List of tables. xi

1. Introduction.

Nowadays the need for communication between different computers is a must. For example access todifferent databases is needed allover the world. However the problem arises that in general the datarepresentation of two computers is not the same. It is possible that the receiving computer obtain allthe correct data, pertlaps with the help of error detecting codes and the right protocols, but does notunderstand the data.

To solve this problem ISO designed in the seven-layered OSI reference model the sixth layer or thePresentation Layer. The Presentation layer takes care of the conversion between the different kinds ofdata representations in order to allow two different computers to communicate in a correct manner andto understand each other.

In general the presentation layer is concerned with the meaning of the information transported fromone computer to the other. All problems relating to the presentation of transmitted data, includingconversion, encryption, and compression is placed in this layer.

During my graduation period at the faculty of electrical engineering of the Eindhoven University ofTechnology, my task was to start research on the presentation layer. The purpose of this research isto come to an hardware/software architecture for the Presentation Layer. Therefore, first a thoroughstudy on the OSI model was needed, in particular the presentation layer. Next, to model thepresentation layer, I used the method of Hatley and Pirbhai, described in the book "Strategies for RealTime System Specification" [HATL,'87]. This method is the real-time variant of the SASD methodof Yourdon.

My work in the modelling of the presentation layer has been the determination of the different partsin which the presentation layer can be divided, and the manner an encoder/decoder process of thepresentation layer can be modelled.

This thesis is meant for the readers, who are a little familiar with the OSI model, and who want toknow exactly what the tasks of the presentation layer are, as well as the way these tasks are performedby the presentation layer according the recommendations of the CCrIT. The thesis contains a fullreview of the presentation layer, and a possible model for the presentation layer according the methodof Hatley and Pirbhai.

This thesis is divided into two parts. The first part (chapter 2-6) contains a review of the presentationlayer. In chapter 2 the OSI model is explained briefly, to rehearse the different parts of the OSI modeland the communication between the different layers. In chapter 3 the task of the presentation layer isdescribed to give the reader insight in the different services the presentation layer can provide. Inchapter 4 the use of abstract syntaxes, in particular ASN.I, is explained. An abstract syntax is usedby the application layer to describe the data to be exchanged in a formal way. In chapter 5 the transfersyntax, in particular BER, is depicted. The transfer syntax is used by the presentation layer to transferthe data described by an abstract syntax. The presentation protocol machine, used to handle thedifferent service requests, and to negotiate which abstract syntaxes and transfer syntaxes will be usedduring a connection, is described in chapter 6.

Introduction. I

The second part (chapter 7-10) consists the mcxlelling of the presentation layer. Chapter 7 gives thereader a brief review of the method of Hatley and Pirbhai, which is used to model the presentationlayer. In chapter 8 is given the communication of the presentation layer with the other OSI-Iayers, aswell as the different subprocesses of the presentation layer in which the presentation layer can bedivided. In chapter 9 the model of a sub-process of the presentation layer is presented: the encoderdecoder. Finally in chapter 10 the conclusions are given.

2 An architecture for an OSI-protocol (layer 6).

2. The OSI reference model.

To standardize and structure the design of modem computer networks, the International StandardsOrganization (ISO) designed the OSI Reference Model. The OSI model consists of seven layers, eachwith it's particular well defined function. These seven layers together make up a stack where eachhigher layer uses the services of the lower layer to talk with the corresponding layer of anothercomputer system. A communication system consists of two of these stacks communicating over OSI.The OSI model, taken from [TANE,'89l, is shown in figure 2.1.

Bit

Frame

Packet

PPDU

TPDU

APDU

physical connection

::: ::'------",<----' Transport protocol '-----.~----'

~ ~

'---~r----,":"""""""""""""sessioo'prOiocoi"""""'" :'---~r-----' SPDU

3

2

7

4

5

6

Figure 2.1 The 7 layered OSI model.

2.1 Layer hierarchy and functionality.

Layer n on host A carries out a conversation with layer n on host B. The rules and conventions usedin this conversation are collectively known as the layer n protocol. The entities comprising thecorresponding layers on the different machines are called peer processes.

In reality, no data are transferred directly from layer n on one machine to layer n on another machine.Instead, each layer passes data and control information to the layer immediately below it, until thelowest layer is reached. Below layer 1 is the physical medium through which the actual communicationoccurs. In figure 2.1 virtual communication is shown by dotted lines and physical communication bysolid lines.

Between each pair of adjacent layers there is an interface. The interface defines what primitiveoperations and services the lower layer offers to the upper one.

The different layers are:

• The Physical Layer, which takes care of transmitting raw bits over a physical communicationchannel.

The OSI reference model. 3

• The Oata link Layer, which task is to take a raw transmission facility and transfonn it into aline that appears free of transmission errors to the netwoIX layer. It is also concerned withtraffic control, in order to prevent a fast transmitter from drowning a slow receiver.

• The NetwoIX Layer is concerned with controlling the operations of the sub-net. It creates apath over which subsequent communication can occur. Besides routing, the netwoIX layerdeals with relaying. This is to allow data transmissions from one sub-netwoIX to another.

• The Transport Layer function is to accept data from the session layer, split it up into smallerunits when needed, pass these to the netwoIX layer, and ensure that the pieces all arrivecorrectly at the other end.

• The Session Layer allows users on different machines to establish sessions between them.

• The Presentation Layer is concerned with the syntax and semantics of the infonnationtransmitted. It also provides data compression and data encryption.

• The Application Layer contains a variety of protocols that are commonly needed.For example: a) file transfer and job management

b) message handling servicesc) job transfer and remote job management.

2.2 Layer interaction.

2.2.1 Interaction between peer entities.

Consider layer (N+1), at a transmitting station who wishes to communicate with his peer entity. Thiscan be achieved by sending Protocol Oata Units (POU) to his peer entity. Since there is no physicalconnection between these peer entities, layer (N+ 1) has to use the services of layer (N), and translateshis (N+1) POU into a (N) Service Oata Unit (SOU). This is done to create a virtual connectionbetween peer entities.

Layer (N) at the transmitting station receives the (N) SOU from the (N+1) layer, and adds "header"infonnation to the data (see figure 2.2). The header is called Protocol control infonnation (PCI) andis used to instruct the peer layer (N) entity. The important point to understand is that at the receivingsite, the layer entities use the PCI created by the peer entity at the transmitting site to implementactions. The (N) PCI together with the (N) SOU fonn the (N) POU and is translated into a (N-l) SOU.

n-2

In-1

I~ ~-nsDU-'l \PCI PCI nPDU ~

~ n-1 PDU ~

~""'I----------- n-2 PDU -------I~~

Figure 2.2 Encapsulation of POUs.

4 An architecture for an OS/-protocol (layer 6).

The (N-l) layer acts the same as the (N) layer described above, and this process is repeated until thedata reaches the bottom layer: the physical layer. When the data is received by the destination receiver,each layer receives POU and strips off the correct PCI. Eventually layer (N+1) of the receiving stationreceives the correct (N+l) POU.

2.2.2 Interaction between adjacent entities.

As seen above a (N) layer communicates with both the (N+l) and (N-l) layer. Figure 2.3 depicts thesituation as we zoom in on a particular (N) layer with it's adjacent layers.

In general, each layer entity is concerned with three areas:

• Service. The set of services it offers to its (upper layer) user.

• Protocol. The functions it performs, in conjunction with a corresponding layer entity in aremote end-system.

• Use of services. The services provided by its subordinate layer and used to carry out the(higher layer) services which it provides.

N-l

N

PDU

LAYERSN+l

Etc.

Figure 2.3 OSI Layer Components

A layer (N) entity (=service provider) receives from it's layer above (=service user) Interface OataUnits (IOU). These consist of both SOU, mentioned above, and Interface control information (IOU).IOU is passed exclusively between two adjacent layers to control the communication.

We review the five components which are involved in the layers' communications process.

• SDU (service data unit). Consists of user data and control information created at the upperlayers which is transferred transparently by layer N+l to layer N, and subsequently to N-l.The SOU identity is preserved from one end of an (N)-connection to the other.

The OSl reference model. 5

• PCI (protocol control infonnation). Infonnation exchanged by peer (the same) entities atdifferent sites on the network to instruct an entity to perfonn a service function (that is,headers and trailers).

PDU (protocol data unit). The combination of the SOU and PC!.

• ICI (interface control infonnation). A temporary parameter or parameters passed between Nand N-I to invoke service functions between the two layers. The primitive typically perfonnsthis function.

• IDU (interface data unit). The total unit of infonnation transferred across the layerboundaries; it includes the PCI, SOU, and la. The IOU is transmitted across the serviceaccess point (SAP).

Summarised: • (N) to (N) remote entities use:

pa for controlUser data (SOU)POU combines the pa and SOU

• (N+1) to (N) adjacent entities use:

ICI for controlUser data (SOU)IOU combines the ICI and SOU

Each layer has one ore more Service Access Points (SAP) identified by a Service Access PointIdentifier (SAPI). Services are available through these (N) SAP which are placed on the boundarybetween the (N+1) and (N) layer.

2.3 Service Primitives

When a layer wants service from a lower layer, it must identify which service, for exampleconnection establishment. For this purpose OSI has supplied Service Primitives and SAPs.

Four kind of primitives, are invoked to and from the layer through the SAPs (some sessions do notrequire all primitives):


Request: Primitive by service user to invoke a function.

Indication: Primitive by service provider to:a) invoke a functionb) indicate a function has been invoked at a service access point(SAP) at the peer entity.

Response: Primitive by service user to complete a function previously invoked by anIndication at that SAP.

Confirm: Primitive by service provider to complete a function previously invoked by aRequest at that SAP.

We take as an example a confirmed service (fig. 2.4), for example connection establishment

(1) A Service Request primitive is initiated by the service user of layer n.

(2) The peer layer n entity gives a Service Indication Primitive to it's service user.

(3) To confirm the Service Indication Primitive the peer service user of layer n gives a ServiceResponse Primitive,

(4) which appears as a Service Confirmation Primitive on the other side to the layer N serviceuser.

n serviceprimitiverequest.

n serviceprimitiveconfirm.

n serviceprimitiveresponse

n serviceprimitiveindication.

Host ALayern

Host BLayern

····:··:· .· .· .· .:.... :~ ••••••••••~ ••••••••••••••••• I

····:···· .: ~ :, ,.- ,Transport through the lower layers.

Figure 2.4 The service primitives of a confirmed service.

In case of an unconfirmed service, for example an user abort, (3) and (4) are omitted.

The OSl reference model. 7

It's also possible that only a Service Indication Primitive appears, usually used to abort aconnection.(see figure 2.5)


Host ALayer n


Host BLayern

Figure 2.5 The service primitives of a indication service.

2.4 Summary.

In this chapter, the OSI reference model is described where a communication system is divided into7 layers, each with a particular task. We have seen that each layer has a virtual connection with hispeer, used to carry out a certain protocol. To establish a connection, each layer has to use the servicesprovided by the layer below. Peer layer entities exchange information through PDUs. This is done bythe sending of SDUs to his lower layer through SAP.

To make a universally applicable model of the presentation layer, we have to use the OSI referencemodel. On this manner the model of the presentation layer can be easily fitted between the applicationand session layer.


3. The task of the Presentation Layer.

As seen before the presentation layer is the sixth layer of the OSI model and is placed between theapplication layer and the session layer.

Application layer

PSA~ PIDU's

Presentation layer

SS~ SIDU's

'-'

Session layer

Application layer

IiPPDU's

...................................:~::. Presentation layer.....

IiSession layer

I 1'-- "'1 rFigure 3.1 The place of the presentation layer in the OSI-model

In the past the Presentation Layer was only used to allow ASCII machines communicate with EBCDICmachines or to permit visually-oriented programs (for example full screen editors) to work with avariety of terminals.

Now the Presentation Layer's role is to provide the proper means of transferring information so thatthe original meaning may be preserved during the transfer together with data encryption and datacompression

Now the job of the presentation layer is on one side to encode structured data from the internal formatused on the sending machine to a bit stream suitable for transmission, and on the other side to decodethe bit stream to the required representation at the receiving machine.

3.1 Data representations.

The lower five layers are only interested in transporting raw bits from one end of the connection tothe other. The presentation layer is concerned with the syntax of the information which is being sent.It's possible that the user, despite of all the effort which is taken in protocols of the lower layer, stillis not able to communicate because he does not Wlderstand the bits.

Most programmes do not exchange random binary bits, but they use things like the names of people,a data or the amount of money. These things are represented by characters, strings, integers, floatingpoint numbers, and data structures composed by primitive types. In the programming language pascalthe data structures are called "records" and in C "structures".

The task of the Presentation Layer. 9

There are different kinds of data representations: a machine can have EBCDIC or ASCII as thecharacter code. A machine can use two's complement arithmetic on 16 or 32-bit integers or 60-bitone's complement. The numbering of bytes can be from left to right. the big endian computers (forexample with the MOTOROLA 68000, 68020 and 68030 microprocessor), or from right to left, thelittle endian computers (with the INTEL 8088, 80286 and 80386 microprocessors).

These different kind of data representations can cause errors.Example:

Bank A wants to transmit a certain amount of money, 10 dollars, represented by integers to bank B.

Bank A is a little endian computer and uses 4 bytes for the representation of integers.Bank B is a big endian computer and uses also 4 bytes for the representation of integers.Bank A sends respectively an [10] [0] [0] and [0] which bank B receives in the correct order.

Bank A

Bank B

3 2 1 0

mSb~lSb

o 1 2 3

mSb~lSb

Now bank B thinks that he receives lOx224 or 176,772,166 dollar.

Unfortunately manufacturers rarely change their conventions to avoid having their newproducts to be incompatible with their old ones. So it is unlikely that there will be universalstandards for internal data representations.

To solve this problem conversion must be made somewhere, for example in the PresentationLayer. There are different solutions for this problem:

(1) the sender could do so the conversion of the data(2) the receiver could do the conversion(3) both the sender and receiver could convert to and from a network standard format.

Each solution has it's advantages and disadvantages.

Solutions (1) and (2) are faster and easier, (3) is relatively slow and complex. This is becausethe data has to be converted twice in solution (3) instead of once in case of solutions (1) and(2). If, for example, a one's complement machine is talking to another one's complementmachine, they can speak one's complement in case of (1) and (2). For solution (3) it ispossible that conversions are needed on both ends because it is possible that the networkstandard format specifies that two's complement must be used.

The solution (3) does require less conversion routines. In solutions (1) and (2) every machinemust be aware of the internal format used by every other machine in the network. When an


APDU (Application Protocol Data Unit) is build by the application layer, it builds it in thefonn that the receiver expects. With 0 different types of machines in the network 0 x (0.1)different conversion routines must be written, instead of just 20 for solution (3). If a newmachine appears in the network, only one conversion routine has to be written for only thatnew machine in case of solution (3), while for solution (1) and (2) new conversion routineshave to be written for all existing machines.

The OSI model uses the third solution and here the network standard fonnat of datarepresentation is called Abstract Syntax Notation 1 (ASN.l).

3.2 Data compression.

The cost of using a network depends on the amount of data sent. It is possible to reduce thebill by compressing the data before sending them.

Data compression is closely related to data presentation. One way to transmit a 32-bit integeris to simply encode it as 4 bytes in some representation and sent it on its way. However, ifit is known that 95 percent of the integers transmitted are between 0 and 250, it may be betterto transmit these integers in a single unsigned byte, and to use the code 255 to signify thata true 32-bit integer follows. While it is true that once in a while five bytes will be neededinstead of four, the gain from being able to use one byte most of the time, offsets this loss.This can be done in the Presentation layer.

3.3 Network security and privacy.

In networks data can travel from one place to another without physically seeing or feeling it.Therefore it is possible that a unauthorized person is wiretapping, or is secretly copying yourdata without knowing it if your data is not protected. Some kind of encryption is needed tomake the data unintelligible to all but their intended recipient.

Protecting data is not the only issue in networking. There are at least 4 security services:

• Protecting data from being read by unauthorized persons.

• Preventing unauthorized persons from inserting or deleting messages.

• Verifying the sender of each message.

• Making it possible for user to send signed documents electronically.

Encryption can be used to achieve all these goals.

In theory encryption can be done in any layer, but in practice encryption is possible in threelayers: The physical layer, the transport layer and the presentation layer.

The task of the Presentation Layer. 11

If encryption is done in the physical layer it is called link encryption. Every bit is encryptedby leaving the machine and decrypted by entering a computer. This method is veryinflexible.If encryption is done in the transport layer the entire session is encrypted. Finallyto let encryption take place in the presentation layer is the best and most flexible solution.

3.4 Summary.

In this chapter is described the function of the presentation layer. Its primary function is topreserve the meaning of the application data during the communication process. This can bedone by converting the data to a mutually understood format.Other functions of the presentation layer are encryption and compression of the applicationdata.


4. The abstract syntax.

Peer application processes exchange infonnation by the use of the presentation services. The unit ofexchange is known as infonnation unit, or simply as data. When an application entity wants toexchange infonnation units with his peer, it has to use the services of the presentation layer. Beforethe presentation layer can service the request of the application layer, it has to know the structure ofthe data which the application layer will sent The description of a data type or structure is called anabstract syntax. The word "abstract" is used because we do not want to describe a data type on bitlevel.

For example an application wants to access a students data-base from a peer application entity. In thatcase a lot of data has to be sent in the fonn of records. The structure of the data, a students record,to be sent between the peers, defined by the application layer, is as follows:

STUDENT:NAMEINITIALSID_NUMBERGENERATIONFEMALE

{characters }{characters }{an integer}{an integer}{a boolean: TRUE means female; FALSE means male}

The way the data structure is described is called an abstract syntax notation. The abstract syntaxnotation must be flexible and standard enough for many applications. Many programming languagesuse abstract syntax notations to define their variables, for example Pascal:

type Student = recordNAME: string;INITIALS : string;ID_NUMBER : integer;GENERATION : integer;FEMALE : boolean

end;

The abstract syntax notations of Pascal and C are not standard and not flexible enough. There aremany dialects. For example, not every Pascal compiler supports the "string" notation which is usedin our example. Besides, they are not always able to describe all data types and structures.

Which abstract syntaxes to be used is negotiated by the peer application layers. This negotiationprocess will be explained in chapter 6.

4.1 Abstract Syntax Notation 1.

The ISO and CCITT have developed a presentation syntax to be used by application layer protocols.The widely used specification is ISO 8824 which is aligned with the Blue Book recommendationsX.208 of the corr and is titled: Abstract Syntax Notation I (ASN.1). The notation was intended

The abstract syntax. 13

primarily for human consumption. Being a formal language, it is also well suited for automatedprocessing.

Each piece of information exchanged between users has a type and a value. The type is a class ofinformation such as numeric, boolean, alphabetic, etc. The value is an instance of the type, such asan number or a piece of alphabetic text. In order for machines to know how to interpret data, theymust know the type first. -

ASN.l describes an abstract syntax for data types and values, and is similar to the data definitionstatements found in languages such as Pascal, Ada and C.

ASN.l is defined by a context-free grammar. With this grammar we can build an ASN.l compiler,which can check if the syntax notation is correct For a full description of this grammar we refer tothe CCITf blue book recommendations X.208, appendix II [VIII.4,'88]. We will now give a shortreview of ASN.1.

4.1.1 The ASN.l Primitive types.

The primitive types of ASN.l (see table 4.1) are build into the language and form the building blocksof more complex types. The names of these types are reserves words, and, like all ASN.l reservedwords, are always written in upper case letters.

Tabel 4.1 The ASN.l primitive types.

Primitive Type Meaning

INTEGERBOOLEANBIT STRINGOCTET STRINGREALANYNULLOBJECf IDENTIFIEROBJECf DESCRIPTORENCRYPTEDENUMERATED

Arbitrary length integer.TRUE or FALSE.List of 0 or more bits.List of 0 or more bytes.A real number.Union of all types.No type at all.Object name (e.g., a library).Human readable object name.The result of encryption.Distinct identifiers.

Integers identifies signed whole numbers. They do not have a maximum size.

• Booleans identifies logical data (TRUE or FALSE).

• Bit strings are ordered lists of bits and each bit string has 0 or more bits, with no maximum.The value of type BITSTRING is written between single quotes, followed by the letter B(binary) or H (hexadecimal). Example: 'OIOOI'B or '2A'R

• Octet strings are ordered lists of octets, which is OSI jargon for bytes. They are used torepresent octet-oriented data, like characters.


• Reals are all numbers capable of being specified by the formula M x BE, where M, calledmantissa, B the base and E the exponent, are all integers. B can take the values 2 or to. Alsothe values PLUS-INFINITY and MINUS-INFINITY are allowed.

• ANY is the union of all types. If a field of a record is declared of type ANY, it can later befilled in by any valid type.

• NULL is no type at all. It could be a valueless place holder in which there are severalalternatives but none of them apply. When a field of a record is assigned the value NULL, ithas no value. When it is transmitted, the NULL fields do not have to be sent.

• The OBJECf IDENTIFIER consists of multiple words, usually enclosed by braces, used toidentify an abstract syntax, encoding rule and protocol to be used by the application. It isintended for consumption by machines. The OBJECf DESCRIPTOR is a human readablestring identifying an abstract syntax.

• ENUMERATED denotes a simple type where its values are given as distinct identifiers. It isassociated with an integer. For example in case of two possible objects: screw and nut, screwcan be identified with the integer 1 and nut with the integer 2.

• ENCRYPTED is a type whose value is the result of an encryption of another type.

4.1.2 The ASN.l Constructors.

The primitive types can be combined to build more complex types. In ASN.l we use the constructorslisted in table 4.2.

Tabel 4.2 The principal ASN.l constructors.

Constructor

SEQUENCESEQUENCE OFSETSET OFCHOICEEXTERNAL

Meaning

Ordered list of various types.Ordered list of a single type.Unordered collection of various types.Unordered collection of a single type.Anyone type taken from a given list.Refer to another, not included, type.

• SEQUENCE is used to combine a collection of types to form a new type, just like in Pascal.The fields of a SEQUENCE may be any types, including constructed types.

• SEQUENCE OF is employed to build arrays of a single type. This single type may be anytype, inclUding constructed types to create an array of records. The SEQUENCE OF do nothave any boundaries. SEQUENCE OF is comparable with a "file of' type in Pascal.

• The SET constructor is similar to SEQUENCE, except that the order of the components is notguaranteed to be the same in the receiver as broadcasted by the transmitter. Analogous SETOF is similar to SEQUENCE OF, with the difference that the elements have no inherentordering.


CHOICE is utilized when a data structure can hold anyone from a collection of alternativetypes. It allows a data structure to hold more than one type.

The EXTERNAL type allows one abstract syntax to refer to something from a different one,without having to textually include the other one.

We can now give the student record from the example above in ASN.l:

Student ::= SEQUENCE {name OCfET STRING,initials OCfET STRING,id_number INTEGER,generation INTEGER,remale BOOLEAN

4.1.3 The ASN.l quasi-primitive types.

In addition to the primitive types and the constructed types, the ASN.l standard also discusses somepredefined types that are useful in many applications (see table 4.3).

Eight different string types are defined. Each one is a different subset of OCfET STRING.

Tabel 4.3 The ASN.l quasi-primitive types.

NumericString PrintableString TeletexStringVideotexString VisibleString IA5StringGraphicString GeneralString

GeneralizedTimeUniversalTime

The NumericString only includes the ten digits 0 through 9 and the space.

The PrintableString includes the upper and lower case letters, the ten digits, space, and 11characters: ()'+-.,/:=?

The TeletexString, VideotexString, VisibleString, IA5String, GraphicString and GeneralStringare defined in ISO 2375. They are provided for the teletex character set, the videotextcharacter set , various international versions of ASCII, and some graphic character sets.

GeneralizedTime consists in general of the time in the following notation:[4 digit year] [2 digit month] [2 digit day] [hour] [minutes] [seconds].For a complete study of the format allowed: see the CCIIT Blue Book RecommendationX.208.

• UniversalTime embraces the time of the format YYMMDDhlunm. As for GeneralizedTimefor a complete review we refer to the CCIIT Blue Book Recommendations X.208.

16 An architecture for an as/-protocol (layer 6).

4.1.4 OPTIONAL and DEFAULT.

In some cases it is possible that a data field is not used and stays empty. In this situation the data fielddoes not have to be transmitted. To handle this situation, ASN.l allows fields to be declaredOPTIONAL.

Alternatively, a data field can be declared DEFAULT, followed by the value to be used by the receiverif the particular data field is not transmitted.

4.1.5 Tagging.

The purpose of tagging is closely related to the encoding rules and transfer syntaxes described inchapter 5. Whenever the value of an item is transmitted, its type is sent as well. The type field is infact a code and is used to identify the value. We also call the type field a tag.

ASN.l uses 4 different types of tags, also called classes (see Table 4.4).

Tabel 4.4 The four types of tags.

UNIVERSALAPPLICATIONPRIVATEcontext specific

Each tag consists of one of the reserved words of table 4.4 (in case of context specific no reservedword is used), followed by an integer. Tags are written between brackets.

The UNIVERSAL tags are used for the reserved primitive and quasi-primitive types defined in theASN.l standard. They are application-independent and are listed in table 4.5. The tag numbers identifythe different kind of primitive and quasi-primitive types, and are useful when such a type istransmitted. This subject is described in chapter 5.

Tabel 4.5 The tags of the UNIVERSAL types.

Tag Meaning Tag Meaning

123456789101112-15

BOOLEAN typeINTEGER typeBIT STRING typeOCTET STRING typeNULL typeOBJECT IDENTIFIER typeOBJECT DESCRIPTOR typeEXTERNAL typeREAL typeENUMERATED typeEncrypted typeFuture recommendations

16171819202122232425262728-..

SEQUENCE & SEQUENCE OF typeSET & SET OF typeNumericStringPrintableStringTeletexStringVideotexStringIASStringUniversal TimeGeneralized TimeGraphic StringVisible StringGeneral StringFuture recommendations


Suppose that a SEQUENCE 'Numbers' consists of 4 fields, all of them declared as INTEGER and alloptional:

Numbers ::= SEQUENCE {value1 INTEGER OPTIONALvalue2 INTEGER OPTIONALvalue3 INTEGER OPTIONALvalue4 INTEGER OPTIONAL

Assume only two of them are transmitted. How does the receiver know which two they are? Thisproblem is solved by giving the integers an extra context specific tag to identify the different fields.

Now the receiver can identify the different fields by looking at the context specific tags. Furthennore,if the receiver can tell which item it is getting by looking at the context specific tag, there is no needto send the UNIVERSAL type tag. ASN.I provides a way to have the type infonnation suppressedwhen extra tagged types or fields are sent To suppress this infonnation, the person writing the abstractsyntax can add the reseIVed word IMPLICIT after the extra tag.

Numbers ::= SEQUENCE {value1 [0] IMPLICIT INTEGER OPTIONALvalue2 [1] IMPLICIT INTEGER OPTIONALvalue3 [2] IMPLICIT INTEGER OPTIONALvalue4 [3] IMPLICIT INTEGER OPTIONAL

If IMPLICIT is not included after a tag, both the tag and the type are sent, as a kind of run-timechecking.

The APPLICAnON tag is used by many OSI application layer protocols to denote types used in thoseprotocols. The PRIVATE tag is applied by the users to denote their own types.

With this knowledge we can now rewrite a student record with the right tags:

Student ::= [PRIVATE 1] IMPLICIT SEQUENCE {name [0] IMPLICIT OCTET STRINGinitials [1] IMPLICIT OCTET STRING,id_number [2] IMPLICIT INTEGER OPTIONAL,generation [3] IMPLICIT INTEGER,female [4] IMPLICIT BOOLEAN DEFAULT FALSE

At the data transfer phase the transmitter and receiver are aware of the abstract syntax of the studentsrecord identified by the [PRIVATE 1] tag. The PRIVATE tag is used because the record is made bythe user. The tag of SEQUENCE does not have to be sent because the structure of the students recordis mutually known. Therefore we use IMPLICIT after the SEQUENCE.

The data fields within student are all identified by context specific tags. We take as example the firstdata field name. Knowing the tag, the receiver knows what data is being sent, so the OCTET STRINGdefinition can be omitted by the transmitter. Therefore again IMPLICIT is used. The data field


id_number is declared OPTIONAL and does not have to be sent by the transmitter. Finally the booleandata field female is declared together with the DEFAULT value FALSE. In case the transmitter doesnot send the female data field, the receiver knows that the value FALSE is meant

4.1.6 Value notations in ASN.l

ASN.l also provides a way to define values of the types we have written. When the SEQUENCE,SEQUENCE OF, SET or SET OF constructors are used, we notate the corresponding data fieldsbetween accolades. When such a constructed type within a constructed type is placed, nesting ofaccolades is possible. The data fields of a structure are separated by commas. If a name is associatedwith a data field (which is usually the case) this name has to precede the actual data value. Octetstrings are given between quotation marks. An example of the students record is given below.

{ name "Jones",initials "M.S.E."-,id_number 227634 ,generation 85 }

This notation, defined within the ASN.l standard, is only used to describe the value of a type on aformal way. It is designed to illustrate possible values of a data type declared in ASN.1. It is, however,also possible for automated processing.

4.2 The principle of abstract syntaxes in the Presentation Layer.

When all the data types needed by an application are defined in ASN.l, they are put together in amodule (or a library) and passed on to the presentation layer of the two communicating systems.

(1) When an application wants to transmit a data structure it can pass the data values to thepresentation layer, along with the name of the data structure (for example "student"). Using the abstractsyntax of student as a guide, the presentation layer then knows what the types and sizes of the fieldsare, and thus knows how to encode them for transmission.

(2) At the other end of the connection, the receiving presentation layer looks at the first encoded tagof the data structure, and thus knows how many bits belong to the first field, how many to the second,their types and so on. Armed with this information, the presentation layer can do any necessaryconversions from the external format used on the wire to the internal format used by the receivingcomputer.

4.3 Summary

In this chapter we have seen how data structures, exchanged by application entities, can be describedusing an abstract syntax notation. The abstract syntax notation 1, described in the recommendationsX.208 of the CCITI, was studied in full detail. We have seen that ASN.l allows us to universallydescribe all possible data structures. We will apply this knowledge in the next chapter to encode thedata values, described by an abstract syntax, into a bitstream, according to certain encoding rules.


5. The Transfer syntax.

There are three fonns of representation (encoding) of the contents of an infonnation unit when it issent between peer entities:

Source:Destination:

Transit:

The encoding in the real storage on the transmitting end-system.The encoding which will be used by the receiving end-systems to store theinfonnation in its own real storage.The encoding understood by both end-systems and used when the infonnation is intransit over a session connection.

As seen before it is possible that the transit encoding may be either the source, or the destinationencoding (or both in the special case of similar systems communicating), but it is often the case thatit is neither of these.

On behalf of application processes, peer presentation entities exchange infonnation over a sessionconnection, encoded in a precise representational fonn understood by the peer presentation entities:the transit coding. A commonly understood transit encoding is known as a transfer syntax. Thepresentation layer translates the data, described by the abstract syntax, into a bitstream according tothe transfer syntax. The fonnat of the bit-stream is defined by this transfer syntax.

There are many transfer syntaxes possible: each will use different encoding rules to transfer the datainto a bitstream. The decision which transfer syntaxes to be used, is negotiated by the peer presentationlayers and will be explained in chapter 6.

5.1 Basic Encoding Rules.

As for ASN.l, the ISO and CCITI have developed a transfer syntax to be used by the PresentationLayer. The widely used specification is ISO 8825 which is aligned with the Blue Bookrecommendation X.209 and is titled: Specification of basic encoding rules for abstract syntax notationone (ASN.l). X.209 describes the actual encoding rules for the values of types, in contrast to X.208,which is concerned with the abstract structure of the infonnation. The Basic Encoding Rules areabbreviated with B.E.R.

The guiding principle behind the ASN.l transfer syntax is that each value transmitted, both primitiveand constructed ones, consists of three components, which appear in the following order:

Identifier Length Contents

The transmitted value is called a data element. The identifier distinguishes one type from another andspecifies how the contents are interpreted. The length specifies the length of the contents. The contents(also called value) contains the actual infonnation of the element. The data element is also identifiedby the tenn TLV (Type-Length-Value). The transfer data element is illustrated in figure 5.1. It canconsist of a single TLV or a series of data elements, described as multiple TLV. The element consistsof an integral number of octets, written with the most significant bit (MSB or bit 8) on the left andthe least significant bit (LSB or bit 1) on the right.

The transfer syntax. 21

Om elernerd

~

ErE(al Single Element

Oataelemerd

r.....-----------A......--------- ,Oataelemerd Data elernel'd

IderdHier Length Identifier Lenglh CordenlS

(b) Mullibla Elementa

Note (1) The IdentHier field ia also called 1he 1ypll.No1e (2) The Cordenllfield ia also called 1he value.

Figure 5.1 The X.209 Data Elements.

5.1.1 The Identifier octets.

The identifier is coded as depicted in Figure 5.2 and contains the value and type of the tags, alsocalled class (see section 4.1.5).

For tags with a number ranking from zero to 30 (inclusive), the identifier comprises a single octet(figure 5.2.a). For tags with a number greater or equal to 31, the identifier comprises a leading octetfollowed by one or more subsequent octets. (figure 5.2.b).

In case of a single-octet identifier distinguishes bits 8 and 7 the four classes. Bit 6 identifies the formsof the data element. Two forms are possible. A primitive element (bit 6 =0) has no further internalstructure of data elements. A constructor element (bit 6 = 1) is recursively defined in that it containsa series of data elements. The remaining five bits (5 to 1) contain the tag number.

IderdHier OCIet

~8 7 6 5 4 321

EEI"_·~~Class

bH 8bH 7o 0 O,>versato 1 Application1 0 Conlllxt-specilic1 1 Private

F: Form of 1he elemerd

bH6o prml1lve 1ypll1 oonstrucl8d 1ypll

(a) Single-oc:tet identHier

last 0CI8I

+

Leading OCl8t 2nd OCl8t 3n:t octet

~ ..---..A--..... ..---..A--.....67654321

EEl' ',,'~[II~1(b) MoAtibIe 0CI8I iden1iIier • number of lag

Figure 5.2 X.209 Identifier.


In case of a multiple identifier is the leading octet filled as the single-octet identifier, with thedifference that bits 5 to 1 are filled with the value 111112, If bit 8 of a subsequent octets is coded witha I, it indicates that more octets will follow. If bit 8 of a subsequent octet is coded with a 0, itindicates the last octet. In bit 7 to 1 of the first subsequent octets, followed by bits 7 to 1 of eachfurther octet, up to and including the last subsequent octet of the identifier octets the unsigned binaryinteger equal to the tag number is encoded. Bit 7 of the first subsequent bit is the most significant bit.Figure 5.2.b illustrates the use of the multi-octet identifiers.

5.1.2 The length octets.

The length specifies the length of the contents. It may take one of three forms: short, long, andindefinite. The short and long form are also called the definite form.

Length OCl8t

~8 7 6 5 4 3 2 ,

B -. ~(a) Deljn~e short length octet

~876 5 4 3 2 ,

last octet2nd octetleading octet

~~8765432' 6 7 6 5 4 3 2 ,

I, number 0' slbsequenl

oct8lll

(b) Delinite long length octets

Figure 5.3 Length octets.

The short form (figure 53.a) is one octet long and is used when the length is less than 128. Bit 8 isalways 0 and bits 7 to 1 indicate the length of the contents. Bit 7 is the most significant bit. Forexample, a contents field of 38 octets long is described by the length field as oolooll~.

The long form (figure 53.b) is used when the length is greater than or equal to 128. It consists of aninitial octet, followed by one ore more subsequent octets. The initial octet is encoded as follows: Bit8 is always 1, and bits 7 to 1 indicate the number of subsequent octets in the length octets. Bits 7 to1 is a unsigned binary integer with bit 7 as the most significant bit. In bits 8 to 1 of the firstsubsequent octet, followed by bits 8 to 1 of each further octet up to and including the last subsequentoctet is encoded the number of octets in the contents octets. It's a unsigned binary integer, with bit8 of the first subsequent octet as the most significant bit. For example, a contents field of 201 octetslong is described by the length field as 1000ooo12 110010012,

The indefinite form is used when data is passed from the application layer to the presentation layerin small units. If the presentation entity has limited buffer space, it may be forced to start transmissionbefore it finds out how much data there is. To handle this situation, a length code1~ is usedto indicate that the data field is of a variable length. The data field is then terminated by end-ofcontents octets. The end-of contents octets consists of two zero octets and can be considered as theencoding of a value whose tag is universal, whose form is primitive, whose number of the tag is zero,and whose contents is absent, thus:


End-of-contents0016

ContentsAbsent

Unfortunately, the transparency problem, which arises when between the length code 10000000:2 andthe two end-of contents octets two value octets appear which are equal to the two end-of contentsoctets, is not solved by the CCIIT.

The defInite form is always used if the encoding is primitive; the indefInite form is always used whenthe encoding is constructed and not all data is available immediately. When the encoding is constructedand all data is available immediately, either the defInite form or the indefinite form can be used as asender's option.

5.1.3 The contents octets.

The contents (value) is the substance of the element, Le. the actual information. It is described inmultiples of eight bits and is of variable length. The encoding of the data fields depends on the typeof data it presents.

Booleans are encoded in a single octet with FALSE as 0 and TRUE as any other value.

Integers are encoded in two's complements and consists of one or more octets. A positive integerbelow 128 requires 1 byte, a positive integer below 32768 requires two bytes, and so forth. The mostsignifIcant byte is transmitted first To ensure that an integer value is always encoded in the smallestpossible number of octets, in case of an encoding in more than one octet, the bits of the first octet andbit 8 of the second octet may not all be ones and may not all be zero.

Bit strings are send as they are. The only problem is to indicate the length. The length field tells howmany bytes belong to the value, not how many bits. This is solved by using an initial octet, followedby zero, one or more subsequent octets. In the initial octet is encoded, as an unsigned binary integerwith bit 1 as the least signifIcant bit, the number of unused bits in the final subsequent octet. Thenumber is in the rank from zero to seven. In the subsequent octets the bits of the bit string are placed,with bit 8 of the fIrst subsequent as most significant bit. (see figure 5.4)

~~87654321 87654321

==~ IIIL1111111[

Initial octet slbsequent octet 1 Iasllllbsequenl oewt

~8 7 6 5 432 1

(lilliE]Figure 5.4 Encoding of bitstring

Each octet of the octet strings are just consecutively transmitted, commencing with the first octet upto the last octet The quasi-primitive string types are encoded as octet strings.

SEQUENCE, SEQUENCE OF, SET and SET OF types are transmitted by first sending the type oftag for the sequence or set itself (which is of course constructed), then the total length of the encodingof all the fields, followed by the fields themselves. The fields of a sequence must be sent in order,but the fields of a set may be sent in any order. If any two or more fields of a set have the same type,they must be tagged extra so that the receiver can tell which is which.


The NULL value is indicated by having a null contents field (zero bytes long). The fact that the lengthfield is 0 indicates that a NULL value is being sent. No numerical value is actually transmitted.

The encoding of a CHOICE value is the same as the encoding of the actual data structure beingtransferred. If a particular choice is between an INTEGER and a BOOLEAN, and the data structureat hand is an INTEGER, then the rules for INTEGER apply.

ENUMERATED values are encoded as the integer value with which it is associated. The encodingof reals are described in ISO 6093.

5.1.4 Example of B.E.R.

The structure of the hypothetical students record is formally described below using ASN.1.

Student ::= SEQUENCE {Name OCfET STRING,Initials OCfET STRING,Id_number INTEGER,Generation INTEGER,Female BOOLEAN

The value of F.K.L. Jonson Students record is formally described below using ASN.l.

NameInitialsId_numberGenerationFemale

"Jonson","F.K.",264521,1988,TRUE }

The representation on octets of the record value given above (after applying the basic encoding rules)is shown below. The values of the identifiers, lengths, and the contents are shown in hexadecimal, twohexadecimal digits per octet. The tags, marked with a number, are explained below.

The transfer syntax.

Student30 (I)

LengthIA

Contents

Name Length Contents04 (2) 06 4A 6F 6E 73 6F 6E ("Jonson")

Initials Length Contents04 04 46 2E 4B 2E ("F.K.")

Id_number Length Contents02 (3) 03 04 09 49 (264521)

Generation Length Contents02 02 07 C4 (1988)

Female Length Contents01 (4) 01 FF (TRUE)

25

(1): We have to decode SEQUENCE, which is a constructed type.

bit 8765432100110000 =3<\i

Bits 8 and 7 are both zero because SEQUENCE has a universal class.Bit 6 is 1 because it is a constructed type.Bits 5 to 1 carry the binary representation of the decimal number 16, which is the tag number ofSEQUENCE.

(2): We have to decode the OCfET STRING type.

bit 8765432100000100 =04tt

Bits 8 and 7 are both zero because OCfET STRING has a universal class.Bit 6 is 0 because OCfET STRING is a primitive type.Bits 5 to 1 carry the binary representation of the decimal number 4, which is the tag number ofOCTET STRING.

(3): We have to decode the INTEGER type.

bit 8765432100000010

Bits 8 and 7 are both zero because INTEGER has a universal class.Bit 6 is 1 because INTEGER is a primitive type.Bits 5 to 1 carry the binary representation of the decimal number 2, which is the tag number ofINTEGER.

(4): We have to decode the BOOLEAN type.

bit 8765432100000001

Bits 8 and 7 are both zero because BOOLEAN has a universal class.Bit 6 is 1 because BOOLEAN is a primitive type.Bits 5 to 1 carry the binary representation of the decimal number I, which is the tag number ofBOOLEAN.

5.2 Other transfer syntaxes.

At this moment, only one set of encoding rules has been specified for ASN.l. The Basic Encodingrules, defined by X.209 are standard and can be applied universally. It allows to encode data using auniform recursive approach. In the B.E.R. almost all fields have a variable-size encoding, with arequirement to use exactly the minimum number of bytes necessary to convey the value. This enablesflexibility, in the sense that there is no limits in data size: for example, the B.E.R. supports arbitrarywide integers.


Unfortunately, the use of type and length fields introduces unnecessary overhead on the network, sincein many cases the receiver knows what data are being sent to it In addition, the conversion processof ASN.l BER are highly CPU consuming because of the ASN-I encoding, because they are basedon bytes and variable-size representation [HUIT, '89]. Therefor the final information transferred throughthe network is highly redundant, which is not acceptable for several "high speed" applications. Ifgigabit/s networks appear tomorrow, the speed of demanding applications like fast transactions ormultimedia conferencing is likely to be limited by the processing power of the end systems. The bulkof the CPU consumption of communication protocols is not used by the protocol itself, but rather tothe interaction with the operating system.

Fortunately, the OSI presentation protocol incorporates a negotiation phase. An application may usea set of several abstract syntaxes. For each of these abstract syntaxes, several transfer syntaxes can beproposed by the calling presentation entity. The responding entity will choose the most appropriatesyntax and then the chosen syntax will be used. The negotiating phase will be fully explained in thenext section. A faster transfer syntax is defined in [BESS, '89] and [HUIT,'89].

Most implementations have a very conservative negotiation procedure by supporting only the ASN.IB.E.R., but nothing forbids us to realize more intelligent implementations, for example by proposing:

•

•

•

•

the ASN.I B.E.R., in order to guarantee interoperability.

a faster transfer syntax to improve the overall efficiency by reducing the overhead oftransmitted information and to provide a high speed coding and decoding mechanism, usedfor high speed transactions.

a compressed encoding, for use on low speed networks.

a transfer syntaxes for encryption, used for top secret information.

5.3 The defined context set.

Only when a presentation entity knows the abstract syntax of an information unit, together with theassociated transfer syntax, it can transform information units into a bitstream. An abstract syntax canbe associated with a transfer syntax chosen from a set of transfer syntaxes. A single transfer syntaxmay also be suitable for encoding information units from a number of different abstract syntaxes. Apresentation entity may know many abstract and transfer syntaxes, and must be aware of thepossible correct pairings.

During an application activity, many information units may be exchanged. These information unitsmay be all of the same type, Le. defmed by the same abstract syntax. But it is also possible that anumber of abstract syntaxes are required to define the different types of information units that are tobe transferred. Therefore peer presentation entities should be able to handle many different abstractsyntaxes during a connection.

The presentation layer can be implemented in many ways. A simple presentation entity may be ableto know and handle only a single transfer syntax, and may be limited in the range of information unittypes that can be transferred. Another may have many transfer syntaxes available.

During connection establishment peer application entities must negotiate which abstract syntaxes aresupported. Similar, peer presentation entities must agree on a specific transfer syntax to be used for


the infonnation units, defined by a particular abstract syntax. This is because it cannot be assumed thatall transfer syntaxes which are supported by one presentation entity are also available to its peer. Anabstract syntax, together with the transfer syntax is called the presentation context set. Thenegotiation of the different presentation context sets, which are supported during the connection,between the peer application and presentation entities is done as follows:

• When the application entity invokes the presentation primitive to open a connection (PCONNECf request), it has to provide, among other parameters, one parameter in which thelist of abstract syntaxes to be used is specified. Every entry in the list of abstract syntaxes isa data type and carries an identification number.

• The presentation layer will examine this list and enriches this infonnation (for each abstractsyntax) with a list of possible transfer syntaxes, before sending it over the networlc by usingthe session services. This enrich process is done by proposing a number of transfer syntaxesfor each abstract syntax. Each couple of an abstract syntax and transfer syntax also becomesan identification number.

• The presentation entity then uses session services to pass the complete list of abstract syntaxesand their respective sets of transfer syntaxes to its peer.

• On the other side, the presentation entity will locally check this infonnation, provided by thesession layer, which transfer syntaxes are supported.

• Then it will send the request to the local application entity which, in tum, will check the listof supported abstract syntaxes.

• After this double check, an answer will be sent back to the remote partner, together with anew list of the locally supported abstract and transfer syntaxes.

• The initiating presentation entity is now aware of the active presentation contexts. It infonnsthe application entity that it can go ahead and use infonnation units according the agreedabstract syntaxes.

• Each infonnation unit to be exchanged between peer application entities, will be delivered tothe presentation layer together with the identity of the associated abstract syntax. Theinfonnation layer will be encoded into a bitstream by the presentation layer according theproper presentation context. The bitstream carries, as well as encoded infonnation, the identityof its presentation context. The receiving presentation entity can then perfonn the appropriatetransfonnation of the received infonnation before passing the infonnation unit (together withthe identity of the associated abstract syntax) to the receiving application process.

The list of negotiated presentation contexts is known as the defined context set. In case where noabstract syntax list is available from the application layer, the peer presentation entities will assumethat a mutually understood default presentation context is available. In this case, the encoding anddecoding will be perfonned according the default presentation context.

Once the presentation context set has been defined, and the dialogue between the two applicationentities is started, one of the presentation entities can decide to change something in the definedcontext set. This implies either removing already defmed presentation contexts, or adding newpresentation contexts, or both. In order to do that, the presentation layer provides the P-ALTER-

28 An architecture for an OSI-protoco[ (layer 6).

CONTEXT seIVice primitive. The context alteration seIVice is achieved, similar to the connectionestablishment

5.4 Summary.

In this chapter it is described how an information unit, described by an abstract syntax notation, canbe encoded to a bitstrearn according a transfer syntax. A closer look is taken at the basic encodingrules, described by the recommendation X.209 of the CCITI, especially used for ASN.l. But the BERis not the only existing transfer syntax: work is being done on defming other transfer syntaxes.

With the combination of an abstract syntax and a transfer syntax, the encoding of an information unitis clearly specified. This combination is called the presentation context. A set of active presentationcontexts is called the defined context set (DCS). The DCS is negotiated between the peer applicationand presentation entities.


6. The presentation protocol machine.

The presentation protocol machine (PPM), placed within the presentation-entity (figure 6.1),communicates with the application layer through a presentation selVice access point (PSAP) usingpresentation-selVice primitives. Presentation selVice primitives will cause or be the result ofpresentation-protocol-data-unit (PPDU) exchange between the peer PPM's. The PPDUs are exchangedusing the Session selVice provide by the session layer.

presentation primitives

PSAP

presentation primitives

PSAP

SSAP

session primitives

SSAP

Figure 6.1 Model of the Presentation layer.

6.1 The Presentation Service primitives.

Presentation selVices primitives are divided into two sets. The first set provides the representationalfunctions, the second set of selVices is concerned with providing a mechanism to allow the applicationprocesses to use the selVices of the session layer (figure 6.2). They are called mirroring selVices.

PPDUs.....................................~

ss-provider

Figure 6.2 The two types of presentation selVice.

The presentation protocol machine. 31

All the Presentation Service Primitives are listed in table 6.1. No PPDUs are exchanged by the peerpresentation protocol machines when the mirroring services are invoked by the application layer. Theyare marked with an asterix in table 6.1.

Note: R means REQUESTI means INDICAnONS means RESPONSEC means CONFIRMM means Mirroring service

Tabel 6.1 The OSI Presentation Service Primitives.

OSI presentation primitive R S C M Meaning

P-CONNECT X X X X Establish a presentation connection

P-RELEASE X X X X • Connection releaseP-U-ABORT X X User-initiated abort releaseP-P-ABORT X Provider-initiated abort release

P-DATA X X Nonnal data transferP-EXPEDITED-DATA X X Expedited data transferP-TYPED-DATA X X Out-of-band data transferP-CAPABILITY-DATA X X X X Control infonnation data transfer

P-TOKEN-GIVE X X • Give a token to the peerP-TOKEN-PLEASE X X • Request a token from the peerP-CONTROL-GIVE X X • Give all the tokens to the peer

P-SYNC-MAJOR X X X X • Insert a major sync pointP-SYNC-MINOR X X X X • Insert a minor sync pointP-RESYNCHRONIZE X X X X • Go back to a previous sync point

P-ACTIVITY-START X X • Start on activityP-ACTIVITY-END X X X X • End of activityP-ACTIVITY-DISCARD X X X X • Abandon an activityP-ACTIVITY-INTERRUPT X X X X • Suspend an activityP-ACTIVITY-RESUME X X • Restart a suspended activity

P-U-EXCEPTION-REPORT X X • Report of a user exceptionP-P-EXCEPTION-REPORT X • Report of a provider exception

P-ALTER-CONTEXT X X X X Context addition and deletion

These presentation services are in fact offered by the session layer and are propagated through thepresentation layer without change. With other words, these presentation services 'mirror' those offeredby the session. When a mirroring service is used by the application layer, it causes a mapping of theparameters of the associated presentation service primitive to or from the equivalent session serviceprimitives which carry the same name. The actual work: is done in the session layer, where also theexchanging of associated session protocol data units (SPDUs) takes place.

6.2 The session service primitives.

The Presentation Layer communicates with the Session Layer by means of Session Service Data Units(SSDU). They are listed in table 6.2 Most session primitive carry the same name as the presentation


primitives. They are the "mirrored" services of the presentation layer. The mapping of those mirroringpresentation services on the session service is given by table 6.3.

Tabel 6.2 The OSI Session Service Primitives.

OSI session primitive R S C meaning

S-CONNECT X X X X Establish a connection

S-RELEASE X X X X Connection releaseS-U-ABORT X X User-initiated releaseS-P-ABORT X Provider-initiated abort

S-DATA X X Normal data transferS-EXPEDITED-DATA X X Expedited data transferS-TYPED-DATA X X Out-of-band data transferS-CAPABILITY-DATA X X X X Control infonnation data transfer

S-TOKEN-GIVE X X Give a token to the peerS-TOKEN-PLEASE X X Request a token from the peerS-CONTROL-GIVE X X Give all tokens to the peer

S-SYNC-MAJOR X X X X Insert a major sync pointS-SYNC-MINOR X X X X Insert a minor sync pointS-RESYNCHRONIZE X X X X Go back to a previous sync point

S-ACTIVITY-START X X Start an activityS-ACTIVITY-END X X X X End an activityS-ACTIVITY-DISCARD X X X X Abandon an activityS-ACTIVITY-INTERRUPT X X X X Suspend an activityS-ACTIVITY-RESUME X X Restart a suspended activity

S-U-EXCEPTION-REPORT X X Report of a user exceptionS-P-EXCEPTION REPORT X Report of a provider exception

Tabel 6.3 Mapping of PSDUs on SSDUs.

PSDU SSDU

P-RELEASE S-RELEASEP-TOKEN-GIVE S-TOKEN-GIVEP-TOKEN-PLEASE S-TOKEN-PLEASEP-CONTROL-GIVE S-CONTROL-GIVEP-SYNC-MINOR S-SYNC-MINORP-SYNC-MAJOR S-SYNC-MAJORP-P-EXCEPTION-REPORT S-P-EXCEPTION-REPORTP-U-EXCEPTION REPORT S-U-EXCEPTION-REPORTP-ACTIVITY-START S-ACTIVITY-STARTP-ACTIVITY-RESUME S-ACTIVITY-RESUMEP-ACTIVITY-INTERRUPT S-ACTIVITY-INTERRUPTP-ACTIVITY-DISCARD S-ACTIVITY-DISCARDP-ACTIVITY-END S-ACTIVITY-END

6.3 The services of the presentation layer.

The services of the presentation layer are divided into three phases:

•••

connection establishment and release.information transfer.context management.


The services in the first two phases fonn the kernel functional unit (FU) of the presentation layer,while the third fonns the optional context management FU.

6.3.1 Connection establishment and release.

Connection establishment.

Connection establishment is a confinned service provided by the P-CONNECf service primitive. Itprovides the means by which an application entity establishes a connection with its peer. Whenestablished, the connection will have an DCS which may, in its minimal fonn, be composed of onlya default presentation context. The way a DCS is achieved is described in chapter 6.

The associated parameters of the P-CONNECf primitive are:

•

•

•

•

•

••

••

•

Calling-presentation-address

Called-presentation-address

Responding-present.-address

Presentation context def. list

Present. context def. result list

Default context nameDefault context result

Presentation requirementsUser data

Result

(PSAP address of the initiating application process, only inrequest and indication)(PSAP address of the intended responder application process,only in request and indication)(PSAP address of the responding application process, only inresponse and confinn)(List of entries to establish a DCS; each entry has twocomponents:• presentation context identifier• abstract syntax name.)(list of entries, expanded with a field where the result ofnegotiation for each entry of the DCS is placed: acceptationor rejection)(abstract syntax name of the default context)(the result of the negotiation of the default context set:acceptation or rejection)(selects a functional unit (FU) of the presentation layer)(the application infonnation that must be transported to thepeer application process and is subjected to therepresentational manipulation, accompanied by a presentationcontext identifier from the list provided in the PCDLparameter)(The result of the connection establishment, only in responseand confinn)

Other parameters are only used in the session layer. They are:

• Quality of service• Initial synchronization point serial number• Initial assignment of tokens• Session connection identifier• session requirements

When a P-CONNECf request service primitive is received by a PPM (the initiator), all associatedparameters are checked. The PPM chooses a list of transfer syntaxes for each entry in the presentationcontext definition list (PCDL) parameter, and expands the entry. The newly constructed PCDL,


together with other parameters necessary" for the peer presentation entity I are put in the connectpresentation (CP) PPDU. TItis PPDU contains the presentation data values and proposed parametersnecessary for the operation of the presentation connection.

Subsequently the initiating presentation entity constructs from this CP PPDU a S-CONNECf-requestSSDU, and sends it to the Session layer to initiate the establislunent of a connection. On the other sidethe responding presentation entity receives a S-CONNECf-indication and reconstruct from this SSDUthe CP PPDU.

The CP PPDU is examined by the peer PPM and chooses a single transfer syntax for each entry inthe expanded PCDL. If a choice is impossible for any entry, then connection establislunent will failat this point and a connect presentation reject (CPR) is sent to the initiating PPM. If the choice wassuccessful, a P-CONNECf indication primitive is issued to the responding application process(identified by the called presentation address). The PCDL parameter contains a copy of the oneprovided with the P-CONNECf request.

The application layer provides a P-CONNECf response which is received by the responding PPM.If the connection is acceptable (because the abstract syntaxes are known), the presentation contextdefinition result list (PCDRL) containing the supported abstract syntaxes is expanded with thesupported transfer syntaxes. SUbsequently the PCDRL is placed in the connect presentation accept(CPA) PPDU and is sent. If the connection is not acceptable, a CPR is issued.

The initiating PPM receives the CPA or CPR PPDU and the appropriate response is issued to theinitiating application entity. In case of receiving the CPA PPDU, the DCS is known by both entities.

Disorderly release.

An application start the disorderly release of a presentation connection by invoking the P-U-ABORTprimitive. Any information may be lost as a result of use of this service. It can be used at any timeby the initiator of the connection and by the responder, any time after issuing the P-CONNECfresponse. The P-U-abort is an unconfirmed service. When P-U-ABORT request is issued by theapplication layer, the initiating PPM sends an abnormal release, user initiated (ARU) PPDU to the peerPPM. The responding PPM in tum will give a P-U-Abort indication to the peer application entity.

If an event happens in the underlying layers or in either of the peer presentation entities where theservice is disrupted, then the peer presentation entities use a P-P-ABORT indication to both applicationprocesses. Any information in transit can be lost. When the lower layers initiates an abort, an abnormalrelease, provider initiated (ARP) PPDU is sent to both presentation entities. Both presentation protocolmachines will then issue a P·P-abort indication to their application entities.

Orderly release.

Orderly release of a presentation connection is achieved by using the P-RELEASE primitive. Thepresentation connection is released as a result of the release of the underlying session connection, Itis transparent or mirroring confirmed service.

6.3.2 Context management

We now consider the service primitive that makes up the optional context management FU: P-ALTERCONTEXT. TItis primitive adds new presentation context(s) to, or removes existing presentation


contexts from, the DCS. It provides a confinned service, because negotiation is used, and has anumber of associated parameters.

•

•

•

•

presentation context addition list

presentation context deletion list

result list

user data

(list with new presentation contexts to be added tothe DCS)(list with presentation contexts to be removed fromthe DCS)(list of context sets with a result field, where eachentry is the result of negotiation of the newly addedcontext sets)(data written according to an abstract syntax of theDCS)

The procedure to alter the DCS is similar to connection establishment. When the initiating PPMreceives the ALTER-CONTEXT request, it sends to the responding PPM the alter context (AC) PPDU.When the responding PPM has done all the appropriate actions, the alter context acknowledge (ACA)PPDU, containing all the necessary parameters, is sent back to the initiating PPM.

6.3.3 Data transfer.

A transmitting application process initiates an infonnation unit exchange by use of P-DATA requestThe tag of the infonnation (the presentation context identifier) indicating the abstract syntax of thatinfonnation unit, is examined by the presentation entity. The infonnation is encoded according thecorrect transfer syntax and sent by the PPM in the transfer data (TO) PPDU. The responding PPMreceives the TD PPDU and the responding presentation entity perfonns the appropriate transfonnation.Subsequently the infonnation unit is delivered by the intended application entity.

Other types of data transfer are possible:

The P-TVPED-DATA service offers the same service as P-DATA, but is only used by applicationprocesses to exchange infonnation against the current setting of data tokens. The PPDU used is thetransfer typed data (TID) PPDU.

P-EXPEDITED-DATA guarantees that a infonnation unit arrives by the peer entity, before theprimitive that is sent after the P_EXPEDITED-DATA primitive. It is a confinned service and the PPMuses the transfer capability (TC) PPDU, and the transfer capability confinn (TCC) PPDU for theconfinn back to the initiating PPM. The infonnation units to be transferred by the P-EXPEDITEDDATA service must be according the default context set.

p-CAPABnJTY-DATA is only used when control data is transferred between the peer applicationentities. This service uses the transfer expedited data (TE) PPDU.

6.4 The Presentation Protocol Data Units.

It is of course impossible to describe all the presentation service primitives and presentation protocoldata units with their associated parameters in detail. A complete description of all presentation servicestogether with the parameters can be found in the blue book X.216 recommendations of the CCITT.For a full description of the presentation data units, together with the associated parameters andprocedures we refer to the blue book X.226 recommendations of the CCITT. There also the fullspecification of the PPM, existing of only 7 states, can be found.


All possible PPDUs, exchanged by the peer PPM are listed in table 6.4. There are 14 PPDU's definedin the presentation layer which are arranged in 5 groups. The PPDUs are exchanged by the peer PPMusing the session service. In table 6.5 the mapping of the PPDUs on the session service primitives islisted.

Tabel 6.4 The presentation-PPDU's with their primitives.

PPDU name R I S C

6.5 Summary

CP Connect Presentation X XCPA Connect Presentation Accept X XCPR Connect Presentation Reject X X

ARU Abnonnal release, User initiated X XARP Abnonnal release, Provider initiated X

TD Transfer Data X XTE Transfer Expedited Data X XTID Transfer Typed Data X XTC Transfer Capability X XTCC Transfer Capability Confinn X X

AC Alter Context X XACA Alter Context Acknowledge X X

RS Resynchronize X XRSA Resynchronize Acknowledge X X

Tabel 6.5 Mapping of PPDUs on SSDUs.

PPDU SSDU

CP S-CONNECTCPA S-CONNECTCPR S-CONNECT

ARU S-U-ABORTARP S-U-ABORT

TD S-DATATE S-EXPEDITED-DATATID S-TYPED-DATATC S-CAPABILITY-DATATCC S-CAPABILITY-DATA

AC S-TYPED-DATAACA S-TYPED-DATA

RS S-RESYNCHRONIZERSA S-RESYNCHRONIZE

The task of the presentation protocol machine is to handle the different service request from theapplication layer, and to exchange the appropriate PPDU's with the peer PPM. To do this it has toperform a negotiating process with the peer presentation entity to come to the defined context set. Alsothe so called "mirroring" services of the presentation have been described, together with a list of itsmapping. Finally the transport of the PPDUs, using the services of the session layer, is explained,together with a list of the mapping of the PPDUs on the session service data units.


7. Formal description method.

Implementing the presentation layer is a complicated job. To make a proper design, it is important todescribe the design in a standard and formal manner. They must be standard because, other peoplemust be able to understand the design, and perhaps continue or change the work that has been done.On the other hand the design must be formal because it is the only way to cope with ambiguities.

Nowadays a number of methods and tools have been created to aid in every phase of systemdevelopment. The modelling we used to analyze, and later on design and implement the presentationlayer is described by OJ. Hatley and LA. Pirbhai in the book "Strategies for Real-Time SystemSpecification" [HATL,'87]. It is a variation on the method described by E. Yourdon. We also used aComputer-Aided Software Engineering (CASE) tool called PROMOD, which more or less supportsthe Hatley & Pirbhai-method.

The Hatley & Pirbhai method consists of two parts, a requirements model and an architectural model.The requirements model describes what has to be designed (it contains demands and constraints), thearchitectural model describes how the requirements can be met. The design is made with manyiterations vertically (within one model), and horizontally (between the two models).

7.1 The requirements model

The requirements model is not a physical design. It represents what has to be designed, not how todesign it. It must leave as much space as possible to the designers choice how to implement thesystem. The requirements model consists of the following components:

• Data Context Diagram (DCD)• Data Flow Diagrams (DFDs)• Process Specifications (PSPECs)• Control Context Diagram (CCD)• Control Flow Diagrams (CFDs)• Control Specifications (CSPECs)• Stores• Requirements dictionary• Timing specifications

In figure 7.1 the relations of the components of the requirements model are shown.

The requirements model is based on the use of flow diagrams (FDs). A flow diagram is a graphicalmodel of signal flows (both data flows and control flows) and processes acting on those flows. FDsconsists of data flow diagrams (DFD) and control flow diagrams (CFD). In a DFD, the processestogether with the data flows (solid arrows) are shown, while in a CFD the processes with the controlflows (dashed arrows) are depicted. The designer decomposes the system and its functions into ahierarchical structure of processes. In this manner the requirements of the system is described.

Formal description method. 39

cco

Data Context Control ContextDiagram Diagram

Timingi • i~

Specification~

Data Flow Control FlowDiagrams

~ -. Diagrams

! !Process ControlSpecifications Specifications

IRequirements Dictionary

I

Figure 7.1 Components of the requirements model.

On the top-level is placed the context diagram (CD), existing of only one process. This processrepresents the system that has to be designed. The CO describes the communication between thesystem to be designed and the outer world (shown as terminators) and contains the OCO as well asthe CCO.

The top level process is functionally decomposed into smaller (sub) processes. The decomposition of(sub) processes continues until, at the lowest level, a number ofprimitive processes exists. A primitiveprocess is described by a process specification (PSPEC) in an unambiguous way. This can be donefor example using structured English or a arithmetic formula. Each process that is not a primitiveprocess is described by a FO.

A CD consists of a OCO and a CCO, just like a FD consists of a OFD and a CFD. Figure 7.2 showsan example of a context diagram, figure 7.3 displays an possible example of a FD belonging to theCD of figure 7.2.

~----. ~

LJES~, ., '\.~)--8-,-'

Figure 7.2 An example of a context diagram.


Figure 7.3 An example of a flow diagram.

In the flow diagrams, the processes are depicted as circles. They are part of the hierarchical structuredescribed above. A process indicates the transfonning of ingoing flows into outgoing flows. Nonprimitive processes are described by a FD one level lower in the hierarchy; primitive processes aredescribed by a PSPEC.

A data flow, depicted as a directed solid arc, is a pipeline through which data of known compositionflows. It may consist of a single element or a group of elements. For example a data flow mayrepresent a single bit, a bit stream, but also the traffic-flow on a road). A control flow, depicted asa directed dashed arc, carry control infonnation. Just like the data flow, it can contain one or a groupof elements. The difference between data and control flows are difficult to describe and depends onthe interpretation of the designer. Both data and control flows are described in de requirementsdictionary. Here the definitions and the functions of all the data and control flows are listed.

A store is represented by two horizontal lines with the name of the store in between. There are twokind of stores, data and control stores. They can be used to save data and control flows that may beneeded in a later time slot

Control flows can flow between processes, and from or to a bar. This bar indicates the interfacebetween the CFD and the control specification (CSPEC) that corresponds to this level. In a CFD, onlyone CSPEC may appear. All bars in a certain CFD refer to the same CSPEC. The CSPECs areoptionally; they need not to be inserted when no process activators are required.

A terminator, visible as a square, represents an entity outside the context of the system. It shows thecommunication of the system with the outer world.

The last part of the requirements model is the time specification. Because time is needed in all levelsof the design, these are globally available, otherwise there would be to many flows in the diagram,which would make them unreadable.The model itself includes the assumption that it is indefinitely fastwith respect to the internal data and control flows. Time specifications are only needed forcommunication with the outer world.

All DFDs and CFDs together constitutes a model of the requirements of a system, not a representationof the implementation of the system. The model is highly idealized; the processes are assumed to bedata triggered and infinitely fast. Whenever enough data is available at the input of a process toperfonn its task, it will perfonn that particular task immediately. However, some processes are nottriggered by data, but by control. This means that the activation of a process is described in a CSPECor PSPEC.


7.2 The architecture model.

The architectural model is created to model the system's design, to show the configuration of physicalmodules that perfonn all the required data and control processing. The requirements are mapped intoan architecture model taking all the design constraints into account. The purpose of the architecturemodel are:

• show physical components that make up the system.• define the infonnation flow between these physical components, and• specify the channels on which this infonnation flows.

7.2.1 The architecture modules.

The architecture model assigns the processes of the requirements model to physical modules thatconstitute the system, and establishes the relationships between them. The definition of the physicalmodules adds four more perspectives to the two addressed by the requirements model (process modeland control model). These are input processing, output processing, user interface processing andmaintenance or self-test processing, as shown in figure 7.4.

User Interface Processing

InputI

Process ModelI

OutputProcessing Processing

I Control modelI

requirements template

Maintenance, Self-Test, andRedundancy Management

Processing

Figure 7.4 The template of an architecture module.

The input and output processing blocks represent the additional processing needed for eacharchitecture model to communicate with the other modules and to transfonn the infonnation to andfrom a usable internal fonnat.The user interface block is a special case of the input and output processing blocks. This block isseparated because there are many special considerations, for example human factors, that affect theuser interface.The maintenance and self-test block represents modules required to perfonn self-monitoring,redundancy management and data collection for maintenance purposes.


7.2.2 The components of the architectural model.

The architectural model is a hierarchical layering of modules that are defined by successive applicationof the architecture template to each of the blocks in the model.

The architectural components are:

• Architectural Context diagram (ACD)• Architectural Flow Diagram (AFD)• Architectural Module Specification (AMS)• Architectural Interconnect Diagrams (AIDs)• Architectural Interconnect Specifications (AISs)• Architectural Dictionary

The relations between these components are shown in figure 7.5.

Architecture ContextDiagram

iJr Jr

Architecture Flow Architecture interconn.Diagrams 4--- --. Diagrams

1 1Architecture Module Architecture interconn.

Specification Specification

...

IArchitecture Dictionary I

Figure 7.S The architecture model components.

The architectural context diagram (ACD) establishes the information boundary between the systembeing implemented and the environment in which the system has to operate. It is the highest leveldiagram for any system.

The architecture flow diagram (AFD) is a networlc representation of a system's physicalconfiguration; it documents the information flow between all the architecture modules. The AFD alsorepresents the allocation of processes and flows from the data and control flow into architecturalmodules.

The architecture interconnection diagram (AID) is a representation of the communication channelsthat exists between the architecture modules. An AID always corresponds to an AFD. The AID showsthe same architecture modules as its AFD, but it also shows redundant units if they exist. Thecomponents of an AID are architecture modules and communication channels, including possibleredundancy.

The architecture module specification (AMS) is written for every module in the architecture modelto state the allocation of data flow, control flow, and processing performed by that module.


The architecture interconnection specification (AIS) establishes the characteristics of thecommunication channels on which infonnation travels between architecture modules. It describes thetransfonnation medium as well as the infonnation fonnats. An AIS is written for every communicationchannel on an AID, but they may be simplified.

The architecture dictionary consists of a listing of all the data and control elements that flowbetween the architecture modules and external entities. The architecture dictionary is an enhancementof the requirements dictionary. The additions are the names of the architecture modules between whichthe infonnation flows, and the names of these communication channels.

7.3 The CASE tool ProMod.

ProMod is a CASE-tool which supports the Hatley & Pirbhai method for the most part. It enables thedesigner to generate a detailed specification for system development. Using Promod the designer fonnsthat specification in three logical steps (figure 7.6)

ProgramDesign

ProblemStatement

User'sWhishes

RequirementsAnalysis &Detin~ion

SystemModel

Systemdesign

ISystemSpec~ication

ProgramS~ication

Figure 7.6 The ProMod project model.

1. Using an elementary system of structured analysis, the designer creates a basic graphic modelof the requirements system.

2. With ProMod, utilizing infonnation contained in the graphic model, the designer develops asystem architecture made up of modules arranged hierarchically and with strictly definedinterfaces.

3. Using a simple pseudo code, the designer refines algorithms and data as ProMod preparescross references for data, functions, user-selected attributes, etcetera, and prepares logicallystructured documents.

This results in a detailed system specification and a wide variety of valuable reports. At each step inthe development process ProMod automatically analyzes the accumulated infonnation to ensureconsistency and completeness. This feature prevents propagation of an error from step to step andensure matching module interfaces.

The three principal phases in the system development that are supported by ProMod are:

• Requirements analysis and definition.• System design• Program design

The first phase, requirements analysis and definition, corresponds to developing a requirements modelaccording to Hatley & Pirbhai and was used to analyze the presentation layer. The other two phaseswere not used.


The reason ProMod was used, is that ProMod in fact is a database which can be easily altered to thedesigners wishes. This is very useful because in the analyzing phase many changes had to be made.Also the creation of the different data- and control- flow diagrams is very easy; ProMod takes careof making similar diagrams.

Promod checks the flows automatically (both data and control) and the process on consistency andcompleteness, which on paper of course is impossible. The report ProMod automatically produces, iscomplete and easy to understand. Finally, working with several people on the same project, ProModis a good tool for adjusting the interfacing of the processes made by different designers.

However, ProMod is not entirely compatible to the method of Hatley & Pirbhai. It demands aspecification of all processes instead of only a specification for primitive processes. These processspecifications are called mini specifications (MSPs).

7.4 Summary

In this chapter a method is described to design the presentation layer with the help of a structuredmethod. This method can be found in the book "strategies for Real-Time System Specification" by D.J.Hatley and LA. Pirbhai.

Also the CASE-tool ProMod is described which supports the Hatley & Pirbhai method. ProMod is akind of database, in which a design can be described, analyzed and checked. ProMod is a useful helpfor describing the presentation layer.


8. Modelling the Presentation Layer

This chapter discusses the design of the presentation layer. The basis of the design of this model arethe carr Blue Book Recommendations of the presentation layer, especially recommendations X.216and X.226 [VIII.5, '88]. We will first consider the context diagram of the presentation layer, togetherwith the modelling of the primitives. Next the flow diagram of level 1 will be explained, includingthe PPM and the encoder/decoder.

8.1 The context diagram of the presentation layer.

Modelling the presentation layer can be done in two different ways (figure 8.1 and 8.2).

PSDU

SSDU

Figure 8.1 Context flow diagram variant 1.

ApplicationLayer A

PSDU

-'--~!~:,,

-.

PSDU'

,

PICI'... , .....

---PSDU'

Figure 8.2 Context flow diagram variant 2.

Modelling the Presentation Layer. 47

When one computer system is considered, the presentation layer has to communicate with theapplication layer and the session layer (figure 8.1). On the other hand, considering a connection, thepresentation has only to act as an medium for the peer application entities. These two considerationsresult in two different kinds of context flow diagrams (figure 8.2).

We have chosen for the first solution because this is the closest approximation of the reality. We wantto design a single presentation layer for a computer system, which transmits and receives primitivesto or from the application layer and session layer. The second solution supports the idea of aconnection, and includes a transmitting and receiving presentation entity, which communicates witheach other using PPDUs. However, the fact that, for a connection, the presentation layer has to usethe seIVices of the session layer can not be displayed explicitly in that model.

In both diagrams, the communication of the presentation process with the terminators takes place withboth interface control information (pICI or SICI) and seIVice data units (PSDU or SSDU). The ICIcontrol flow indicates that a certain primitive is active. Meanwhile, the SDU data flow carries thedifferent parameters that belong to the primitive. For example PICI can be a P-CONNECf primitive,while PSDU carries the parameters that belong to P-CONNECf. In tum, P-CONNECf can carry oneof the four different kind of the primitives: request, indication, response or confirm. In therequirements dictionary this appears as:

pici =

p_connect=

psdu =

[ P30nneetI p_releaseI p_u_abortI P_alter30ntextI p_dataI ... etcetera ]

["request"I "indication"I "response"I "confirm" ]

[ P30nneccparI p_release_parI p_u_abort-parI p_aIteccontexc.parI p_data_parI ... etcetera ]

( "caIIinures_adr" )+ ( "caIIed_pres_adr" )+ ( pres_contexcdeClist )+ ... etcetera

The complete definition of the data- and control flows can be found in the requirements dictionary ofthe presentation layer model, placed in appendix A. In the same appendix also the context diagramof the presentation layer can be found.


8.2 The flow diagram of level 1.

The flow diagram of level 1 is shown in figure 8.3. Because we want to buffer the PSDU, SSDU, PICIand SICI, the external data flows (communicating with the application and session layers) are calledp_sdU3 and s_sdu3. The external control flows are called p_ici3 and s_ici3.

Figure 8.3 The context diagram of level I.

In figure 8.3 we can distinguish the presentation protocol machine (PPM), the encoder/decoder anda filter dcs.

• The presentation protocol machine (PPM) is the process carrying the set of functions whichtake care of the communicating aspects of the presentation protocol (input/output events,actions and predicates), using the services offered by the Session layer. The Protocol machinesis by means of state/event tables described by the CCITT X.226 standard. Also predicates andactions are described, unfortunately in a rather vague way. This vague text implies a furthereffort to understand its meaning. The work. of analyzing the state tables of the PPM and to fitit in processes and control specifications is done by M.C.A. Hurk.mans and will be describedin his thesis.

• The supported context set store (supp3S) contains a list of context sets which can be handledby the encoder/decoder . This list is provided by the encoder/decoder and used by the PPMto negotiate the defined context set with the peer entity.

• The default context set (defaulccs) store contains the default context set. This store is filledby the PPM.

Modelling the Presentation Layer. 49

The store manage_dcs is basically the memory to keep track of the DCS during the lifetimeof a connection.

The test_cs is a store, provided by the filter_dcs process and available to the encoder/decoder.The encoder/decoder has to test the p_user_data or ss_user_data to be sure it belongs to thetesCcs.

The filter_dcs process manages the various sets of contexts defined in a presentationconnection and saves them in the store manage_dcs. The process also provides the test contextset.

The processes psdu_buffer and ssdu_buffer take care of splitting or merging the p_user_dataand ss_usecdata, from or in the presentation- and session- service data units p_sdu3 ands_sdu3. The p_usecdata and ss_user data is intended for the encoder/decoder, or is comingfrom the encoder/decoder.The process also acts as a buffer for the external p_sdu3, s_sdU3, p_icCe and s_ici3, sothat they are always available to the PPM as p_sdu, s_sdu, p_ici and s_ici.Finally, the process ssdu_buffer recognizes the different Presentation Protocol Data Units(PPDU) from the session primitives. (PPDUs are always mapped on session primitives). Incase a PPDU arrives, this is indicates to the PPM through the control flow s_ici.

The encoder/decoder. It is the process which is capable of understanding in which contextdata are being referred to, and to code/encode data into/from a bitstream using the correetabstract and transfer syntaxes. The process is described in the next chapter, but can also befound in the appendix A.

8.3 Summary.

In this chapter is described how the knowledge of the preceding chapters is combined in a model forthe presentation layer. The presentation communicates with both the application- and session- layer.The presentation- and session primitives are modeled by the control flows p_ici3 and s_ici_e, whilethe associated parameters are carried by the data flows p_sdu3 and s_sdU3.

The total model of the PPM can be found in the thesis of M.e.A. Hurkmans, whereasthe encoder/decoder process can be found in the next chapter.

Because of the method used to describe the presentation layer, the whole design in full detail can befound in the structured analysis report of ProMod in Appendix A.


9. Modelling the encoder/decoder.

In chapter 8, figure 8.3, we have seen that, in order to build a presentation model, we have to use anencoder/decoder. The encoder/decoder is used to transform the user data of the Presentation Layer Userto a bitstream according to a known transfer syntax, and vice versa. In figure 9.1 the inputs andoutputs for the decoder/encoder are depicted. The picture is taken from [CANE, '88]. The actual datastructure, together with the identification of the data structure is in fact the p_user_data from figure8.3, the bitstream is the ss_usecdata, and the ASN.l definition of data structures is from theapplication layer.

Actual Id. of ASN.1data data definition ofstructure structure data structure

Encoder

Bitstream

Actual Id. of ASN.1data data definition ofstructure structure data structure

Decoder

Bitstream

Figure 9.1 Inputs and outputs for the encoder/decoder.

There are two main phases during the encoding (decoding) process [CANE,'88] (figure 9.2); onedealing with the syntactic analysis of the abstract syntax, and one dealing with concrete encoding(decoding). These two phases can be seen as the compilation and execution phases of a programminglanguage. The difference is that a piece of code written in ASN.l is only composed of the typesdeclaration part. This means that the first phase will not give an object code, but an internalrepresentation of objects, the rules of which are discussed later in this thesis.

ASN.l definition

ASN.l checker

Dals 81ruc:lureDals 81ruc:lureEnooder

bilslream

Decoder

bilslream

"'0

ig:Dals 81ruc:lure Id. I\)

Figure 9.2 Two-phases encoder/decoder.

The first phase is needed to ensure the correctness of the ASN.l data type definition that form anabstract syntax. This phase can be schematically represented by a box that takes as input an abstractsyntax definition, and gives as output an internal representation of the abstract syntax, that will be usedduring the second phase. The first phase can be done off-line, and not during a connection.

Modelling the encoder/decoder. 51

The second phase relates to the concrete encoding of data. This phase can be also represented by abox that takes as input the reference to an internal representation of the abstract syntax, the actual datastructures associated with the abstract data types, and the identifier of the data structures to beencoded/decoded. Output of this phase is the bitstream that will be transferred through the network.

As seen in section 5.1, using the basic encoding rules, the encoder has to produce three fields(identifier, length, contents) for each ASN.l data type, during the encoding phase. The identifier fieldis encoded using the ASN.l definition, while the length and contents fields are encoded by referringto the actual data structure. The problem is how and where the encoder can get the data values. Theactual data structure is application dependent, and an application implementer, in theory, can choosewhichever way to store data values. This problem can be solved in the model by placing the datastructure in a value tree. Where this value tree actually is placed, can be chosen freely. For examplein a associated memory within the hardware of the presentation layer, or perhaps in the memory ofthe computer system where the hardware of the application layer belongs to. (see figure 9.3)

Computer system

Layer 7

Layer 4

Layer 3

Layer 2

Layer 1

Figure 9.3 Memory allocation of the application data.

In figure 9.3 the hardware of the presentation layer is placed outside the computer system, but thememory allocation of the application data is placed within the computer system. The hardware can beseen as a kind of chips which increases the performance of the communication system. It can, forexample, handle the presentation protocol and do the necessary conversion.

9.1 The alternatives for an encoder/decoder.

To build an encoder (decoder) according to the off-line 'compiler', three alternatives were developed.They will be explained in the next three sections.

9.1.1 Alternative 1.

The first alternative consists of a creation of two data stores: a type tree and a value tree. The typetree and value tree include type and value definition in a form more suitable for processing.

A type tree is essentially a parse tree for a type definition. The tree has a hierarchical structureconform its abstract syntax. The leaf nodes of the tree correspond to primitive types; the interior nodesof the tree represent constructor types. A node is labelled with the kind of type it represents. Where


Name,EmployeeNumber,[I] Date,[2] Name,[3] IMPLICITSEQUENCE OF ChildinfonnationDEFAULT {} }

the definition of one type incorporates a reference to another defined type, the corresponding tree nodepoints to another type table. Figure 9.4 depicts type tables containing defmition of thePersonnelRecord, Childinfonnation, EmployeeNumber and Date types which are give below and aretaken from Appendix I of the X.209 recommendations.

PersonnelRecord ::= [APPLICATION 0] IMPLICIT SET{titlenumberdateOfHirenameOfSpousechildren

Childinfonnation ::= SET{ Name,dateOffiirth [0] Date}

Name ::= [APPLICATION I] IMPLICIT SEQUENCE{givenName VisibleString,initial VisibleString,familyName VisibleString}

EmployeeNumber ::= [APPLICATION 2] IMPLICIT INTEGER

Date ::= [APPLICATION 3] IMPLICIT VisibleString

Personell RecordApplication 0 (SET)null

Namesee subtreenull

null[1]date of hire

null[3]children

nullvisible stringnull

nullvisible stringgivenname

NameApplication 1 (Sequence)null

null nullvisible string visible stringinitial familyname

Datesee subtreenull

employeenumberApplication 2 (Integer)null •

DateApplication 3 (visible string)null •

Namesee subtreenull

childinformationSETnull

Namesee subtreenull

childinformationsee subtree

(sequence of)(default: () )

null

null[0]date of birth

Datesee subtreenull

Figure 9.4 An example of a type tree.


{givenName "John", initial "P", familyName "Smith"},"Director",51,"19710917"{givenName "Mary", initial "T", familyName "Smith"},

A value tree is similarly a parse tree, but for a value definition. Leaf nodes represent primitive typesand contain actual integers, boolean, bit or octet string values; interior nodes represent constructortypes; each node is labelled with the kind of type it represents. Figure 9.5 depicts a value tree for thevalue of John Smith's personnel record, which is formally described below using ASN.l.

{titlenumberdateOtHirenameOfSpoucechildren

{{ {givenName "Ralph", initial "T", familyname "Smith"},dataOfBirth "19571111"},

{{givenName "Suzan", initial "B", familyname "Jones"},dateOfBirth "19590717"} }}

given initialname "PO"John"

familyname"Smith"

title"Director"

givenname"Mary"

Initial"p"

given Initial family given initia familyname"'" name name "6" name"Ralph "Smith" "Suzan" "Jones"

Figure 9"5 Value table for John Smith's personnel record.

To convert abstract syntaxes into type trees, a compiler is needed, which, as seen before, can be placedoutside the presentation layer. The compiler checks the type definition for consistency and outputs typetrees which are placed in a data store inside the encoder/decoder.

A parser process within the application layer is needed to convert the data, provided by the applicationlayer, into a value tree. Also a deparser process is necessary to construct the data, consumable for theapplication layer, from the value tree.


An encode process is needed, which converts a value table into a bitstream, for example according thebasic encoding rules. This process is guided by the type tables describing the type of the value to beencoded. Finally a decode process is needed, which converts a bitstream, encoded for exampleaccording the basic encoding rules, into a value table. This processes is also guided by the type tablesdescribing the type of the value to be decoded.

Now the parse process, followed by the encode process perfonn a translation from application datato a bitstream. The decode process followed by the deparse process realizes the inverse. The processes,together with the data flows, are depicted in figure 9.6.

Application data

Figure 9.6 Encoding with a type tree.

A similar construction of an encoder/decoder with an type tree and a value tree in software andhardware can be found in [POPE,'84], [CLEG,'87], [CLEG,'89] and [GAUD,'89].

New abstract syntaxes using the same encoding rules can be defmed by the external compiler whichloads the new type tree in the data store. However, when we want to use another transfer syntax, anew encoder and decoder process must be defined in the model. Another disadvantage is that thetranslation of the application data into a data tree is time and memory consuming.


The second alternative consists of a value tree, together with the necessary parse and deparse processesand a microprocessor which, together with a microprogram, acts like an encoder/decoder. Actually theencoder, and decoder process together with the type tree are combined in one microprocessor and amicroprogram.

The program includes the encoding and decoding routines to translate application data into a bitstreamand vice-versa and can be made by an external compiler. New transfer syntaxes and new abstractsyntaxes are easily implemented by changing the program. This is similar to the changing of theprogram of a digital signal processor, when a different fJIter is realized. A disadvantage is that, as inalternative I, the translation of the application data into a data tree uses considerable time andmemory.



The reason that in alternative 1 and 2 a value tree was used, is that for the basic encoding rules thelength field is transmitted before the contents field. So the whole record has to exist in a memory,before it can be transmitted. This causes much processing power and memory in the parse or deparseprocess, especially when the record uses many constructed types and carries many field. Fortunately,when using the basic encoding rules, it is possible to use the construction of end of data field (seesection 5.1.2). Using this construction it is possible to encode and decode "on the fly" without usinga data tree. Only a micro processor with "on the fly" programming is needed.

This alternative uses minimal memory space, and has a good perfonnance. It is, however, notuniversally applicable.

9.1.4 Choosing an alternative.

An ideal encoder/decoder must be universally applicable, must use very little memory space and mustbe indefinite fast. This can be approximated by combining alternative 2 and 3. In that case (usingalternative 2) we are able to encode/decode universally, and (using alternative 3) encode/decode fastwith almost no memory. In fact, alternative 3 is a special case of alternative 2. A data tree, consistingof only the primitive type "ANY", together with the right micro program can act as alternative 3. Soalternative 2 is chosen, which also includes alternative 3.

9.2 The model of the encoder/decoder.

In this section the processes of the encoder/decoder are further explained. The data flow diagram ofthe encoder/decoder is depicted in figure 9.7.

Figure 9.7 The data flow diagram of the encoder/decoder.


The control flow diagram and the sub-processes are not depicted. This section will only give a briefdescription of the encoder/decoder model. The complete model of the encoder/decoder can be foundin the structured analysis report, produced by ProMod (appendix A).

9.2.1 The value tree and parser/deparser.

To create a value tree, a parser process is provided. This process scans the data available from theapplication layer and puts it in the data store "value tree", which in fact is a tree structure. We willexplain this process with the help of an example: the John Smith's personnel record of section 10.1.In figure 9.8 the same data tree is depicted, where each node and leave has a number, and where eachnode contains accolades and commas.

6

givenname"Mary"

10

initial"p"

11

given initial family given initia familyname -r name name "8" name"Ralph 17 "Smith" "Suzan" "Jones"

16 18 22 23 24

Figure 9.8 The value tree witch additional information.

The numbers denote the order in which the nodes were defined. The accolades and commas denotethe symbols of the ASN.l value notations, used to construct the tree by scanning on these symbols.With each node of the tree are two labels associated. It contains the name of a data value and thevalue of the data field.

To create the tree from application data (the parsing process), we use the store last_address, indicatingthe last node used, and the following processes:

Initial: When a new record has to be parsed, the initial process is started. It createsthe root of the value tree.

This process makes a new node, and attaches it to the node which is identifiedin the store last_address. It is used when a opening accolade is scanned.


create_righcsibling: This process makes a new node, and attaches it to the parent node which isidentified in the store last address. It is used when a comma is scanned.

goto_parent: This process sets last_address to the parent node of the node which isidentified by last_address. It is used when a closing accolade is scanned.

The actual memory representation is given in figure 9.9.

2 nul null null null3 1 null null 6null 2 Illivenname John 4null 2 inniaJ P 5null 2 amitynarnE Smith nullnull 1 title Director 7null 1 number 51 8null 1 ~teof hire 111770917 II10 1 nul nul 13null II ~ivenname Mary 11null II inniaJ P 12null II amilYnarnE Smith null14 1 nul nul null15 13 nul nul 2016 14 nul nul IIInull 15 ~ivenname RalPh 17null 15 inniaJ T 18

1811- paren type V8Jue r.l~l

T ...1,23456789

treelist 1011121314

available 1516171819

naddress

dllid

Figure 9.9 The actual structure of the value tree.

To create a data field, consumable for the application, from the value tree (the deparsing process),we use the following processes:

initial: This process is used at the beginning a deparsing process. It returns the datavalues of the root.

This process is described above.

This process returns the value of the left child of the node identified bylast address.

This process returns the value of the right sibling of the node identified bylast address.

The deparsing process is achieved by using these processes, starting from the root, left downward,touching every leaf. It can be compared with the process of drawing the contour of your hand fromleft to right.

9.2.2 The encoder/decoder micro processor.

A complex encoding like the basic encoding rules can be implemented either "manually" or by usingsome automated "interface generator". Manual programming may in some cases result in betterperfonnances, but it is time consuming and errors can be made easily: any misreading of the ASN.Ilanguage result in coding errors, which are often difficult to detect. It is also difficult to makemodifications. For these reasons, most developers use "interface generators" [HUlT,'89] (figure 9.10),


Interface compileri.I

ASN.l decriplion of datastructures transfer switch -

~ (abstract synl8X8S)

I II AAematwe IASN.l SER e~~ng

Application layer

daIa value

Presentation Layer

" AAemalwe coding routinee ----------------- .-

..I ASN.l SER ----------------- ~codino routines

1S~st,.am

Figure 9.10 The compiling process of transfer routines.

which will automatically "compile" an ASN.l specification, producing the coding and decodingroutines. The interface generator or compiler is put outside the presentation layer.

With this environment, introducing a new transfer syntax is equivalent to changing the code generationpart of the interface compiler, in order to generate not only the ASN.l BER encoding and decodingroutines, but also possible alternative transfer syntaxes based upon the new syntax. The choice of usingeither set of routines will be perfonned by the presentation layer. This will differ from connection toconnection, depending on the result of the presentation negotiation.

The encoder/decoder microprocessor runs the encoder/decoder routines, made by the interface compilerand available at the encoder_decoder_microprogram store. The Microprocessor is able to convertthe value tree to a bitstream, used in the session layer as ss_user_data, and to decode the bitstream intoa value tree. The encoder_decoder_microprogram can also contain a "on the fly" encoder/decoderroutine, using the indefinite length fonn in the coding scheme of TLV of the B.E.R. In that case thevalue tree exists of only the ANY type.

The process change_encoder_decoder contains a store with all the encoding and decoding routinesto handle the context sets which are supported by the presentation layer. The list of supported contextsets are made available to the PPM by the store suppys as seen before. When the encoder/decodermust be updated, because new abstract syntaxes and transfer syntaxes and thus new context sets aredefined, the whole set of encoding/decoding routines can be overwritten by a new set ofencoding/decoding routines. The routines are updated by the data flow update_microyrograms. Thechange3ncoder_decoder process will then load the new set of supported context sets in the storeSUPP3S.

The process change_encoder_decoder provides also the encoder_decoder_microprogram store with thecorrect encoding/decoding routines. Which routine is loaded, depends to which context set thep_usecdata or ss_usecdata belongs. The checking to which context set the data belongs is done bythe processes check_extracty _user_data and check_extract_ss_user_data. These processes will beexplained in the next section.

Only one combined encoder/decoder microprocessor is available because the presentation layer caneither transmit or receive, and is not able to do both tasks.


9.2.3 The testing for the context set.

The checking of the p_user_data, to detect if the data belongs to the test3s or defaulCcs, is done bythe process check_extract.J>_user_data. If the check was negative, the PPM will be warned that thedata is not according the supported context sets. If the check was positive, thechange3ncoder_decoder process will be told which routine has to be loaded in the storeencoder_decoder_microprogram. When this is done, the process will remove the headers from thep_user_data, indicating to which context set the p_data_belongs, and send the remaining lex_data tothe parser.

The checking of the ss_usecdata and the extracting, with as result a bitstream, is done by the processcheck_extract_ss_user_data and is similar to the check_extract-p_usecdata, except that the processwill remove the headers from the ss_user_data, and send the bitstream to theencoder_decoder_micro-processor.

9.3 Summary.

In this chapter is described how we can model the encoder/decoder. Three possible alternatives weregiven, and we have tried to combine two of them in the fmal model. This model of theencoder/decoder process and his subprocess, such as the parser and the data3heckers, were explained.However, because of the formal method, used to describe the presentation layer, the whole design infull detail can be found in the structured analysis report of ProMod in Appendix A.


10. Conclusions and recommendations.

10.1 Conclusions

The presentation layer protocol and its services are described in the Blue Book recommendations ofthe CCITf X.216 [VIII.4:SS] and X.226 [VIII.4:S9]. The recommendations are written in a veryformal way which is difficult to understand for unexperienced readers. The recommendation do notrefer to a possible implementation of the presentation layer.

The Presentation layer is used to preserve the representation of the data values, exchanged by peerapplication entities. This is done by converting the data values to a commonly known data format. Tosupport this method the CCITf has developed ASN.I and B.E.R.. ASN.I is used to describe the datatypes which application entities want to exchange. ASN.l is described in the X.20S recommendations.The B.E.R. are used to transform the data values, described in ASN.I, into a bitstream. The B.E.R.are described in the X.209 recommendations which also do not refer to a possible implementation ofthe presentation layer.

The presentation layer is able to use different abstract syntaxes (described in ASN.l) and transfersyntaxes (for example the B.E.R.). It is possible to define other (faster) transfer syntaxes than theB.E.R., which may support compression or encryption. The couple of an abstract syntax and transfersyntax is called presentation context. The set of presentation contexts, supported during a connection,is negotiated by the peer presentation entities. This negotiating process is described in the presentationprotocol.

Using the CCITf blue book recommendations [VIII.4:SS] [VIII.S,'SS], we have managed to modelthe Presentation Layer and the many Presentation Service Data Units (PSDUs) and Session ServiceData Units (SSDU's). The modelling of the presentation layer is done corresponding the formalmethod of Hatley and Pirbhai [HATL, 'S7]. To record the model, we have used the CASE-toolProMod, which is a very helpful instrument in the development of the requirements model of thepresentation layer.

After determining the different components of the presentation layer, M.C.A. Hurkmans and I agreedthat Mr. Hurkmans models the Presentation Protocol Machine, and I design the encoder/decoder.

The criteria of the encoder/decoder were that they were universally applicable and fast. Therefore, inthe design, a type tree and a microprocessor is placed which must run a microprogram. The value treeis a tree structure of the application data and is accomplished by parsing the application data. Themicroprogram must contain encoder/decoder routines to transform the value tree, into a bitstream, andvice versa. The routines of the microprocessor can be made by a compiler, placed outside thepresentation model.

Utilising a microprocessor with a microprogram, the encoder decoder is not a pure hardware process.

The model of the encoder/decoder is able to handle multiple context sets, which can always beupdated.

Conclusions and recommendations. 61

Because the basic encoding rules uses the TLV (type, length, value) encoding scheme, the whole datarecord has to be known, before it can be transmitted. The data is therefore put in data tree, which canbe implemented with an associated memory or a memory within the computer system.

However, using the indefinite form of the B.E.R., we are able to perform an "on the fly"encoding/decoding scheme, using almost no memory to store the application data values. This "on thefly" encoding/decoding scheme can be placed as a routine in the microprogram.

Finally, having put the model in the CASE-tool ProMod, ProMod does not detect any errors in themodel, so the model is assumed to contain no inconsistency errors.

10.2 Recommendations.

Because the CCIlT only describes one transfer syntax, more research has to be done on defining otherand better transfer syntaxes, supporting for example compression and encryption. However, thesetransfer syntaxes will not automatically become "a standard".

Now having build a model for the encoder/decoder, a computer system can be specified where themodel can be tested (for example if the computer system uses big or little endian notation, ASCII orEBCDIC and one's or two's complement integers). The model can be realised without knowing exactlyhow the computer system, where the model is to be used for, is being made. But to test the model,the microprogram must be made by the interface compiler according a specific computer system.

When this specification has been done, the presentation layer can be simulated and tested using forexample IDASS. Eventually a presentation chip can be made.


11. Literature.

[BESS, '88] Besson, M., Doghri, A., and Huitema, C."High perfonnance heterogeneous transmission using the OSI presentation protoco1.",Proc. of Third Int. Con/. on Computer and Information Sciences, Cesme, Turkey, 29Oct- 2 Nov., 1988, pp.l-12.Commack, NY: Nova Science Publishers, 1989.

[BLAC, '89] Black, U.D.Data Networks: concepts, theory, and practice.,Englewood Cliffs, New Jersey, USA: Prentice-Hall, Inc., 1989.

[CANE, '87] Caneschi, F. and Merelli, E."Standardizing the presentation layer: Why and What", Proc. Seventh Int'l, Con/. onDistributed Computing Systems, Berlin, 21-25 Sept. 1987, pp.35-39.Washington, DC: IEEE Comput Soc. Press, 1987

[CANE, '88] Caneshi F. and Merelli, E."An Architecture for an ASN.I Encoder/Decoder", International Conf. onCommunication and Data Communication, 1987.North-Holland: Elsevier, 1988.Network Protocols and Standards, pp.297-303, 1988.

[CLEG, '87] Cleghorn, C., Gallouzi, S. and Ural, H."On the use of invertible execution of ASN.1 encoding rules", Proc. of CIPSEdmonton '87:lntelligence Integration., Canada, 16-19 Nov. 1987, pp.216-222.Edmonton, Canada: Canadian Inf. Processing Soc., 1987.

[CLEG, '89] Cleghorn, C. and Ural H."ASNST: An abstract syntax notation-one support tool", Dept. of Computer Science,Ontario, Canada.Comput. Commun., Oct 1989, vol 12, no. 5, pp.259-265.

[HATL, '87] Hatley, OJ. and Pirbhai LA.Strategies for Real-Time System Specification.,New York: Dorset House Publishing: 1987.

[GAUD, '89] Gaudette, P., Trus, S. and Collins, S."An object-oriented model for ASN.l", Proc. of First Con/. on formal DescriptionTechniques,Amsterdam, 6-9 Sept., 1988, pp.121-135.North-Holland; Elsevier, 1989.

[HENS, '88] Henshall,1. and Shaw, A.OSI Explained. End to End Computer Communication Standards.,Chichester, England: Ellis Horwood, 1988.Computer Communications and Networking

Literature. 63

[HUIT. '89] Huitema. C. and Doghri. A."Defining faster transfer syntaxes for the OSI Presentation Protocol"ACM Computer Communication Revieuw. Oct. 1989. vol19, pp.44-55.

[KNIG. '88] Knightson, K.G.• Knowles, T. and Larmouth, J.Standards for Open Systems Interconnection.•New York, St.Louis, San Francisco. Colorado Springs, Montreal. Oklahoma City, SanJuan, Toronto: McGraw-Hill Book Company, 1988.

[POPE, '84] Pope, A.R."Encoding CCIIT XA09 Presentation Transfer Syntax"ACM Computer Communication Revieuw. Oct 1984, vol14, noA. ppA-lO.

[RIKK. '90] Rilckert de Koe, 0.,OSI-Protocollen. Lagen 1 tIm 4. Een in/eiding tot en een beschrijving van de OSIstandaarden.•Deventer, Antwerpen: Kluwer technische boeken B.V.• 1990.

[TANE, '89] Tanenbaum, A.S.Computer networks., second edition,Englewood Diffs, New Jersey, USA: Prentice-Hall, Inc., 1989.

[VillA, '88] CaIT Blue Book, Volume VIII, Fascicle VIllA,"Data Communication Networks. Open systems Interconnection (OSI). Model andNotation, Service Definition." Recommendations X.200-X.219Melbourne. IXth plenary assembly: 1988.

[VIII.5, '88] CaIT Blue Book. Volume VIII, Fascicle VIII.5."Data Communication Networks. Open systems Interconnection (OSI). ProtocolSpecifications, Conformance Testing." Recommendations X.220-X.290Melbourne, IXth plenary assembly: 1988.


eindhoven university of technology master an architecture

Documents