eindhoven university of technology master an architecture ... · university oftechnology is...

Eindhoven University of Technology

MASTER

An architecture of the presentation layer of OSI

Reuterink, J.A.

Award date:1992

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/studentthesis/an-architecture-of-the-presentation-layer-of-osi(6dfa6627-caf9-41d7-820c-a39772a4b6eb).html

Graduation Report

CoachSupervisor

An Architecture of thePresentation Layer of OSI

I.A. Reuterink

Faculty of Electrical EngineeringDigital Infonnation Systems GroupEindhoven University of Technology

Eindhoven, July 1992

ir. M.I.M. van WeertProf. ir. M.P.I. Stevens

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

Abstract

The OSI Reference Model has hecome the framework for all work on network architectures. Toovercome interconnectivity problems, ISO has adopted a layered approach for the OSI ReferenceModel. The complete communication subsystem is broken down into a numher of layers each ofwhich perfonns a well-defmed function.

The Digital Infonnation Systems Group of the facu1ty of Electrical Engineering at the EindhovenUniversity of Technology is researching the sixth OSI layer : the presentation layer. The objectiveof this project is to design the presentation layer in hardware.

All tasks relating to representation of transnlitted data are assigned to the presentation layer. Byusing the services of the presentation layer an application process can communicate with anotherapplication process regardless of the local representation of the infonnation in each of bathcommunicating computers. To perfonn this task the presentation layer has to encode the application data, specified with an abstract syntax, to a negotiated transfer syntax. The combination of anabstract syntax and a transfer syntax is called a presentation context

The design of an implementation of the presentation layer is structured according to the modellingtechnique of Hatley and Pirbhai. This modelling technique distinguishes two parts : a requirementsmodel and an architecture model. In the first part the requirements of the presentation layer aredescribed, independent of the final implementation. In the second part will he descrihed how thepresentation layer is to he structured.

This thesis is meant for the readers who are interested in the presentation layer. The thesisdescrihes all functions the presentation layer has to perfonn for providing its services to theapplication layer as defined in the CCITT recommendations.This thesis is focused on the first step of the Hatley and Pirbhai modelling technique : therequirements model. The designed requirement model contains a complete functional description ofthe presentation layer. The presentation layer is decomposed in three main functions. First. thePresentation Protocol Machine (PPM) which perfonns all tasks to offer its layer's services to theapplication layer. Secondly, the Context Manager which keeps track of the history of usedpresentation context sets and the current defined context set Third, the EncoderlDecoder whichprovides the actual encodingldecoding of the data values to/from the negotiated transfer syntax.Also the functions that interface with the application and session layer and the function thatmanages the resources of the presentation layer are specified.

Next. this thesis is focused on the function Encoder/Decoder. It consists of four main functions.First a "Prepare" function which extracts the parameters that have to he encoded. This functionalso instructs the "Change_encodecdecoder" function which encodingldecoding routines areneeded. This "Change3ncodecdecoder" function contains a library of all supporting abstractsyntaxes and transfer syntaxes and their corresponding encoding and decoding routines. Anothermain funetion is the "Parser". It provides the checking of the accepted data and stores it indifferent ways.

ii

Last but not least, the function "Encodecdecoder-processing" perfonns the actual encoding anddecoding of the accepted data. This task can be perfonned with the encoding/decoding routines thatare given by the function "Change3ncodecdecoder".

In the defined requirements model, found in appendix A, the earlier specified EncoderJDecoder byP.Verllaak [Verll91] is improved and extended according 10 the CCnT recommendations. TheEncoder/Decoder is now able 10 encode/decode all defmed ppdu parameters. Also the "user-data"can be encoded/decoded in several ways dependent of the used presentation context, the selectedfunctional units and the mode the presentation layer operates in. These improvements caused achanging in the interaction between the main functions of the presentation layer. Also the layout ofthe EncoderJDecoder is improved 10 provide an unifonn operation of the encoding and decodingprocess. Besides these improvements the funetional specification of the Encoder/Decoder isextended. Finally, some considerations conceming a hardware implementation of the presentationlayer are given.

Abstract. iii

Contents

Abbreviations vi

List of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. vii

List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. viii

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. The OSI Reference Model 32.1 Introduction 32.2 The OSI layers and their functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Layer Cooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Data transmission between two computers 72.3.2 The interaction between adjacent layers . . . . . . . . . . . . . . . . . . . . 8

2.4 Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11

3. The Presentation Layer in more detail 123.1 Introduction 123.2 Data Representation 133.3 Data Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 Data Encryption 163.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4. The Recommended Abstract- and Transfer Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1 Introduction 194.2 ASN.l 21

4.2.1 ASN.1 types " 224.2.2 Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26

4.3 Transfer Syntaxes 294.3.1 BER 29

4.3.1.1 Identifier octets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.1.2 Length octets 314.3.1.3 Contents octets 324.3.1.4 A BER encoding example 34

4.3.2 Alternative Transfer Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . .. 374.4 Summary .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38

5. The Recommended Presentation Protocol Machine. . . . . . . . . . . . . . . . . . . . . . . . .. 395.1 Introduction 395.2 The Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 405.3 The Presentation layer services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43

5.3.1 Connection establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 435.3.2 Connection release 465.3.3 Context-management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 46

iv

5.3.4 Infonnation Transfer 475.3.5 Resynchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.3.6 The other service primitives . . . . . . . . . . . . . . . . . . . . . . . . . . .. 48

5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 50

6. The chosen strategy for system development . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 516.1 Introduction 516.2 The requirements model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 526.3 The system architeeture model 556.4 The CASE-tooi ProMod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 586.5 Discrepancies between the Hatley and Pirbhai modelling teehnique

and the CASE-tooi ProMod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 596.6 An evaluation of the Hatley and Pirbhai modelling technique and

the CASE-tooi ProMod .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 596.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 60

7. A functional decomposition of the presentation layer . . . . . . . . . . . . . . . . . . . . . . . . 617.1 Introduction 617.2 The context of the presentation layer . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 617.3 The first functional decomposition of the presentation layer . . . . . . . . . . . .. 657.4 The encoder/decoder functional decomposed 70

7.4.1 The prepare functions 707.4.2 The change_encodecdecoder function . . . . . . . . . . . . . . . . . . . .. 727.4.3 The encodecdecodecerror_controller . . . . . . . . . . . . . . . . . . . .. 737.4.4 The parser function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 747.4.5 The encoder_decoder-processing function 76

7.5 The evolution of the architecture of the presentation layer . . . . . . . . . . . . .. 797.6 General implementation considerations 80

7.6.1 Quality of service aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 807.6.2 Interfacing aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817.6.3 Encodecdecoder implementation aspects . . . . . . . . . . . . . . . . . .. 82

7.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . '. . . . . . . . . . . . . . .. 83

8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 84

9. Literature 86

Appendix A : List of ProMod Structured Analysis Report 89

Contents. v

Abbreviations

ACDAPDAIDAISAMSAPIASN.lBERCCDCCIrrCDCFDCSCSPECCMFUCRFUDCDDCSDFDFDICIIDUISOOSIPCIPDUPICIPIDUPPCIPPDUPPMPSAPPSAPIPSDUPSPECSAPSAPISDUSICISIDUSSAPSSAPISSDU

Architeetural Context DiagramArchitectural Flow DiagramArchiteetural Interconnect DiagramArchiteetural Interconnect SpecificationArchitectural Module SpecificationApplication Programming InterfaceAbstract Syntax Notation One.Basic Encoding RulesCOntrolCOntext~agram

COnsultative COmmittee of the International Telegraph and TelephoneContext DiagramControl Aow DiagramContext SetControl SpecificationContext Management Functional UnitContext Restoration Functional UnitData COntext diagramDefined Context SetData Flow DiagramFlow DiagramsInterface Control infonnationInterface Data UnitInternational Standards OrganisationOpen Systems InterconnectionProtocol COntrol InfonnationProtocol Data UnitPresentation Interface Control InfonnationPresentation Interface Data UnitPresentation Protocol COntrol infonnationPresentation 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 InfonnationSession Interface Data UnitSession Service Access PointSession Service Access Point IdentifierSession Service Data Unit

vi

List of figures

Figure 2.1 Operational environments 4Figure 2.2 The OSI Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 2.3 Layer interaction 8Figure 2.4 Relation between layers at an interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 2.5 A space representation of service primitives 10Figure 3.1 The advantage of a common syntax ..... . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 4.1 Presentation: coding and decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20Figure 4.2 The X.209 Data Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30Figure 4.3 X.209 Identifier , 31Figure 6.1 Components of the requirements model 52Figure 6.2 An illustration of a context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 53Figure 6.3 An example of a DFD and a CFD . . . . . . . . . . . . . . . . . . . . . . . .. 54Figure 6.4 The architecture model components 56Figure 6.5 The template of an architecture module 57Figure 6.6 Architecture modellayering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 57Figure 6.7 The ProMod project model 58Figure 7.1 A first possible context diagram of the presentation layer . . . . . . . . . . . . . .. 62Figure 7.2 A second possible context diagram of the presentation layer . . . . . . . . . . . .. 62Figure 7.3 The data flow diagram of the presentation layer . . . . . . . . . . . . . . . . . . . . .. 65Figure 7.4 The encoding of data by the presentation layer 67Figure 7.5 The data flow diagram of the encoder-decoder 70Figure 7.6 An example of the contents of the store sUPP3S 72Figure 7.7 An ASN.l compiler 73Figure 7.8 A value tree according to the abstract syntaxes "Hospitallnfo" and

"PatientHistory" ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 75Figure 7.9 A possible implementation of a tree structure 76Figure 7.10 Simple encoding principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 77Figure 7.11 An example of the contents of the store defmed3s 77Figure 7.12 Full encoding principle .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 78Figure 7.13 A possible structure of modules of the encoder/decoder 80Figure 7.14 A possible communication schematic for the presentation layer . . . . . . . . .. 82

vu

List of tables

Table 3.1 Security mechanisms in the OSI Reference Model 17Table 4.1 The four classes of types 22Table 4.2 ASN.l primitive types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23Table 4.3 ASN.l constructors 24Table 4.4 Character string types 25Table 4.5 Time types " 25Table 4.6 Universa! types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Table 5.1 The Presentation Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 40Table 5.2 The Session Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41Table 5.3 The different PPDU types 42Table 5.4 Mapping between presentation primitives, PPDU's and session primitives 42Table 5.5 The mapping of the mirroring services . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43Table 7.1 Mapping of CP PPDU associated parameters on S-CONNECf parameters. . . . 68Table 7.2 The recommended perfonnance criteria 81

Vlll

Chapter 1

Introduction

Since the 1980's the influence of the computer on society has increased enormously. Computershave made the infonnation exchange faster and the world "smaller": infonnation from the otherside of the world is almost immediately available. Because international standards did not exist inthe beginning of the computer-age each computer manufacturer designed computers in his ownway. This caused differences in computer architectures. In future, these differences will rarelychange because the manufacturers want to avoid incompatibility between their old and newproducts.

In 1979 the International Standards Organisation (ISO) defined the OSI Reference Model whichstandardizes the communication between computers, independent of their architecture. This OSIReference Model divides the complete communication subsystem into a number of layers each ofwhich perfonns a well-defmed function.

Since more than a year the Digital Information Systems Group of the faculty of ElectricalEngineering at the Eindhoven University of Technology is researching the sixth OSI layer : thepresentation layer. This layer is concerned with preserving the meaning of the infonnationtransported. Therefore it provides a common representation for application infonnation while it isin transit between two peer application processes. By using the services of the presentation layer anapplication process can communicate with another application process regardless of the localrepresentation of the information in this entity. Also tasks like compression and encryption shall beperfonned by the presentation layer.The objective of the research project is 10 design the presentation layer in hardware instead ofknowing implementations in software. Two fonner students graduated on this subject. They startedwith the functional description of the presentation layer. However, this specification was notcomplete and not totally according the CCITT recommendations.

In this thesis an improved requirements model of the presentation layer is given. This modelcontains all the functions the presentation layer has to perfonn according to the CCITT recommendations [X.208], [X.209], [X.216] and [X.226]. Besides this improvement of the requirementsmodel it is also extended further as will be described in my thesis.

1

In chapter 2 the OSI Reference Model will he introduced. Chapter 3 descrihes the presentationlayer in more detail. In chapter 4 the recommended abstract syntax and transfer syntax will followand in chapter 5 the recommended presentation protocol machine will he described. Next, inchapter 6, the chosen modelling technique of Hatley and Pirbhai and the CASE-tooI ProMod willhe discussed. In chapter 7 the functional decomposition of the presentation layer will he introducedincluding some consideration conceming a hardware implementation. In chapter 8 the conclusionsand recommendations of my graduation work will he given and in chapter 9 an overview of theused literature will follow. Finally, the complete requirements model of the presentation layer willhe given in appendix A.

Chapter 1: Introduction. 2

Chapter 2

The OSI Reference Model

2.1 Introduction

More than ten years have passed since the International Standards Organisation (ISO) began effortsto create networking standards that would pennit computer "interoperability", i.e. computer applications could communicate with one another regardless of what type of hardware they reside on(see [Zimm80]). The idea is to cure all interconnectivity problems by replacing the user'sproprietary systems with OSI standard products and services.

Despite the communications capabilities that OSI provides, there are some common misconceptionsabout the architecture that users should be aware of. First, OSI doesn't provide a common userinterface like IBM's Systems Application Architecture (SAA). The X/Open organization is workingto establish such an interface for OS!. In addition, there is no application programming interface(API) for OS!. Rather, it provides protocols for applications to communicate. This means that thedevelopers who build OSI applications must also develope APIs 10 Support the application.

Despite these drawbacks, it's important to stress that the OSI Reference Model has become theframeworlc for all worlc on network architectures. A number of factors can given that do promotethe growth of OSI and will likely contribute 10 OSI's acceptance in the 1990s. A few will begiven. First, the need for multivendor connectivity makes OSI undeniable. Users and analysts saidthat the key problem they face today is making diverse hardware and software interoperate[Roch91]. Develloped products based on standards have long benefited both the computing and thecommunications worlds, being more interoperabIe and less expensive and troublesome than theirnonstandard counterparts. Second, if an organisation plans 10 do business with govemments in theU.S., Europe or the Far East, that organisation will be required to use OS!. For a more detailedevaluation of the OSI Reference Model is referred to [Dant90].

To overcome the above stated interconnectivity problems, the OSI has adopted a layered approachfor the Reference Model. The complete communication subsystem is broken down into a numberof layers each of which perfonns a well-defined function.

3

Conceptually, these layers can be considered as perfonning one of two overall functions :

• network-dependent functions• application oriented functions

This in turn gives rise to three distinct operational environments :

• The network environment, which is concerned with the protocols and standards relatingto the different types of underlying data communication networks.

• The OSI environment, which embraces the network environment and adds additionalapplication-oriented protocols and standards 10 allow computers to communicate with oneanother in an open way.

• The real systems environment, which builds on the OSI environment and is concernedwith a manufacturer's own proprietary software and services, which have been producedto meet a particular distributed infonnation processing task.

The above described environments are shown in Figure 2.1.

BCoAComputer mputer

® < ) @-- .. --- .~--- ..--- -_ .. --- .~--- _. ---~ ~r«lIillld

UlcdonI UlcdonI- --~ ......-....-_ .._-... -_ .. --_ ..-...-.. --- -NIIllI'Ork-dlpendlnl ~-dIpendInI

fIndonI UlcdonI

! !I Data netwerk I

Netwerk environment

OSI environment

Real sstems environment

Figure 2.1 : Operational environments.

Both the network-dependent and the application-oriented (network-independent) components of theOS! Reference Model are in turn implemented in the fonn of a number of protocol layers. 1beboundaries between each protocol layer, and hence the functions perfonned byeach layer, havebeen selected by applying several design principles. These will be described in the next section.

The following sections are not more than a overview of the OS! model. For a more detaileddescription is referred to [Tane88], [Hals88] and [Hens88].

Chapter 2: The OSI Reference Model. 4

2.2 The OSI layers and their functionality

The OSI Reference model consists of seven layers, each with it's particular well defmed funetion.Also, each layer has a well-defmed interface between itself and the layer immediately above andhelow it, and as aresult the implementation of a particular protocol layer is independent of allother layers. The OSI model, taken from [Tane88] is shown in Figure 2.2.The lowest three layers (1-3) are network dependent and are concemed with the protocolsassociated with the data communication network heing used 10 link the two communicatingcomputers together. In contrast, the upper three layers (5-7) are application oriented and areconcemed with the protocols that allow two end user application processes to interact with eachother. Layer 4, the transport layer, masks the upper application oriented layers from the detailedoperation of the lower network dependent layers. Essentially, it builds on the services provided bythe latter to provide the application oriented layers with a network independent message interchance service.

5 sesslon pro1Oc:Ol

4 Transport protocol

3

2

physIcaJ connec:tlon1

The principles that were applied to arrive at the seven layers are as follows :

• A layer should he created where a different level of abstraction is needed.

• Each layer should perfonn a well defmed function. Also, layers that use different kindsof technology should he separated.

• Each layer has boundaries only to its upper and lower adjacent layers.

• The function of each layer should he chosen with an eye toward defining intemationallystandardized protocols.


• The layer boundaries should be chosen 10 minimize the infonnation flow across theinterfaces.

• The number of layers should be large enough that distinct functions need not be thowntogether in the same layer out of necessity, and small enough that the architecturedoes not become unwieldy.

Now we will describe the OSI layers which are found by applying the above given principles. Theemphasis will be put on the higher three layers : the presentation layer and its adjacent layers.

The different layers that are found are:

• The Physical Layer; it models the interface of a computersystem to the physical mediumfor the provision of databit transmission. It inc1udes such aspects as physical connectorsfrom the computersystem 10 the medium and the voltage level to be used in databittransmissions.

• The Data Link Layer; it's main task is to take a raw transmission facility and transfonnit into a line that appears free of transmission errors to the network layer. It accomplishesthis task by having the sender break the input data up into data frames, transmit theframes sequentially, and process the acknowledgement frames sent back by the receiver.Another issue that arises in this layer is concerned with traffic control, in order to preventa fast transmitter from drowning a slow receiver.

• The Network Layer; it's concerned with controlling the operations of the sub-net A keydesign issue is detennining how packets are routed from source to destination. Thecontrol of congestion in the network also belongs to the network layer.Besides routing, the network layer deals with relaying, i.e. to allow data transmissionsfrom one sub-network to another. This is the highest layer which contains a link-to-linkprotocol, i.e. it communicates with its immediate neighbours, creating a path over whichsubsequent communication can occur.

• The Transport Layer; It provides a facility to transfer data between session entities in atransparent, reliable and cost effective manner. Thus it accept data fiom the session layer,split it up into smaller units when needed, pass these to the network layer, and ensurethat the pieces all arrive correctly at the other end. This is the lowest layer which contain aend-to-end protocol : it setup and tenninates a communication between two computers.

• The Session Layer; it establishes a logical communication path (session connection)between two application entities, to use it to exchange data and 10 release the connectionin an orderly way. One service of the session layer is to manage dialogue control. Aapplication can request for a simplex or a duplex connection. Using a simplex connection,this layer keep track of whose turn it is. A related service is token management. For someprotocols, it's essential that both sides do not attempt the same operation at the same time.When the session layer has got a lOken for a certain operation, only this side may perfonnthe critical operation. Another session service is synchronization. This service is used toteIl the other side that all data so far is successfully transmitted. This point is set during thecommunication. When a fault occurs only the data after the last synchronization point haveto be repeated.


• The Presentation Layer; it negotiates of an appropriate transfer syntax(es) which is (are)suitable for conveying the type of user data messages 10 be exchanged. This layer alsotransforms user data from it's specified abstract syntax form into the selected transfersyntax form and visa versa. In this way two computers with a different architecture cancommunicate with each other. So the presentation layer must contain an encoder/decoder.Another important function in this layer is the context management. This function storesfor all the synchronization points (see session layer) the agreed abstract - and transfersyntax coupIe. Furthermore, the presentation layer provides data compression and dataencryption. In the next chapter I will describe this layer in more detail.

• The Application Layer; This is the highest OSI layer. It permits application processes 10access OSI capabilities. The purpose of the layer is 10 serve as a window between correspondent application processes so that they may exchange information. This layer contains avariety of protocols that are commonly needed.For example:

• Electronical mail. This OSI standard (X.400) was updated in 1988 to includenot only passing messages but the capability for transmitting voice, EDIdocuments, image, fax and audio.

• File Transfer and Access Management. FrAM is used for fIle transfer overnetworks.

• Directory Services. This services standardized as X.SOO is used to locate peopleand systems on the network quickly.

• Virtual Terminal Protocol. This protocol enables end-users to access remoteOSI networks in a standard fashion. For example : the UNIX market currentlyrecognizes 30 different types of terminals.

2.3 Layer Cooperation

2.3.1 Data transmission between two computers

Figure 2.3 shows an example of how data could he transmitted in the OSI model.The sending process has some data it wants 10 send to the receiving process. It gives the data tothe application layer, which then attaches control information (which may he nuIl) to the front of itand gives the resulting item to the presentation layer. The presentation layer may transform thisitem in various ways, and possibly add its own control information to the front, giving the result tothe session layer. The presentation layer is not aware of which portion of the data given 10 it bythe application layer is the control information and which is true user data. This is also true for theother layers. As can he seen in Figure 2.3, each layer adds a header to the accepted data except thedatalink layer which adds also a trailer to the accepted data. This trailer has a CRC (cyclicredundancy check) function.


5end Ing Process ~elvlng Proe

,!/~

~llcatlo ~1'cetlo

leyerApp I I cat Ion protoco I ~AH ldata ~ '.)Ier"

Pr_nt.tl~PHI ~

Pr_ntat'Presentatlon protocol dat.

leyer I.yer

5easlon 5easlon5ess I on protoco I HHI dat. ~

••y.... ,.y....

Tr.nspor Tr.nsportTransport protoco I ~-hH I dat. ~

I.yer ,.y....

NlttlOOr"I< Nlttworl<Netwerk: protoco~ I _te ~

'.yer ley....

Dat. I In Date I1 n

~I dat. IDT~'.yer leyer

Physlce I Physlc.'

I.yer ~ bIts H leyer

'" .......1 ..... tr....I-l- -tt> '"/ ,Figure 2.3 : Layer interaction.

Then the datalink 1ayer sends the data to the physical layer, where they are actually transmitted tothe receiving machine. On that machine the various headers are tripped off one by one as themessage propagates up the layers until it finally arrives at the receiving process.

The key idea throughout is that although actual data transmission is vertical in Figure 2.3, eachlayer is programmed as thought it were really horiwntal.

2.3.2 The interaction between adjacent layers

In section 2.3.1 we described the principles of the datatransmission between two computersaccording to the OSI Reference Model. In this section we will focus on aspecific layer and willdescribe the data interaction between its adjacent layers (the layer above and below).

In general, each layer entity can be distinguished in three areas:

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

• Protocol. The offered services will be executed according to the rules of the protocolspecification of the certain layer.

• Use of services. The services that are provided by its subordinate layer (N-1) and are usedto carry out the services which it provides.


PDU z

LAYERSN+1

N

N·1

EIc.

Figure 2.4 : Relation between layers at an interface.

Each layer consists of entities which are active elements. Nothing is said about the implementationof them. They can be a software (such as a process) or a hardware entity (such as an intelligent1/0 chip). Entities in the same layer on different machines are called peer entities. Let's look at aspecific layer, for example layer N, in Figure 2.4.

The entities in layer N implement a server used by layer N+1. In this case layer N is called theservice provider and layer N+I the service user. In order to provide it's service, layer N may usethe services of layer N-1. Services are available at SAP's (service access points). Each layer hasone or more SAP's. Thus, in Figure 2.4 the layer N SAP's are the places where layer N+ I canaccess the services offered. Each SAP has an address that uniquely identifies it This address iscalled SAPI (service access point identifier). For correct exchange of infonnation between twoadjacent layers, these layers have to be agreed upon a set of rules concerning the interface.

At a typical interface, see Figure 2.4, an IDU (Interface Data Unit) passes from layer N+1 througha SAP to the layer N entity. Such a data unit consists of a SDU (Service Data Unit) and an ICI(Interface Control Infonnation). Layer N will handle the SDU as one block of infonnation, in factthe information block is created in Layer N+l out of layer N+2 data and control infonnation ofN+1 layer. The accepted ICI is passed between layer N+1 and N as (a) temporary parameter(s)passed between the two adjacent layers to invoke service functions between them. Dependent ofthis infonnation, layer N will add to the accepted SDU also its own specific control infonnation :PCI (Protocol Control Infonnation). This PCI will be exchanged between the two layer N peerentities to instruct the remote entity to perfonn a service function. Every OSI layer could add suchinfonnation to the accepted SDU for the same reason. The combination of a SDU and a PCI iscalled a PDU (Protocol Data Unit). Next, a specific IC! is added to the PDU as (a) temporaryparameter(s) passed between the layers N and N-l to invoke service functions between them.


2.4 Service Primitives

As seen in above section, offering a set of services to its (upper layer) user is the task of all OS!layers. The user services provided by a layer are specified by a set of service primitives. Theservices associated with a layer can be of three types :

• confirmed• unconfirmed• indication

Normally, a particular transfer starts by the user of the layer passing a request primitive acrossthe layer interface. This, in turn, results in an associated PDU being generated by the local protocolentity within the layer and this being passed, using the services provided by the underlying layer,to the peer protocol entity in the remote system. Then, on receipt of the PDU, the peer protocolentity in the remote system creates an associated indication primitive and passes this up 10 thepeer user. In the case of an unconfirmed service this completes the transfer, but with a confirmedservice this is followed by the peer user issuing a response primitive. Again, this results in anassociated PDU being generated by the local protocol entity wbich is the sent back to theoriginating protocol entity, using the services provided by the underlying layer. On receipt of this,the originating protocol entity then creates a confirmation primitive and passes this up to the userto complete the transfer. An example of a space representation of a confirmed service is given infigure 2.5. So, depending on the type of service (confirmed or unconfirmed) of a certain serviceelement it consists of two or four primitives in their setBut there are also service elements with only one primitive : the indication primitive. A layer issending such a primitive when an error occurs in bis own layer or in one of the lower layers.Because there is no user initiating such a service there is no request primitive.

User COrrespondent userLayer N + 1 MrYIce

Request ConfInn pOYId8d Responulndlcatlon

....................................................J .Protocol entlty Peer Protocol entlty

(service layer)(service Iayer) l8IVIc8UI8d

, , I : .: ! \V : i

·_··..•..·_..T· • • ••..••••.._ ••••••• _............ • ···_·_ ···_··.._· ·····f·.._··· ••,IJ': ,!/:.........,: v I

Layer N

Layer N-1, , q ," ,• L __ __ ...

t__ .. .. .. __ __ ... .. ... ... J

Protocol messagedata units

Figure 2.5 : A space representation of service primitives.


2.5 Addressing

As explained above, in the OSI Reference Model a SAP (with an unique SAPI) Can be seen as anaddress. In general, we distinguish two parts of addressing, i.e. for identifying :

• a physicallocation of the computer within the network. in which the required applicationis currently resident;

• a application layer protocol entity to which the application is currently said to be attaehed.

The first part of addressing is the responsibility of the network. layer entity (OSI layer 3). It has toestablish a route to the end-system, perhaps by consulting an OSI addressing and routing database.The second part of addressing starts with the assumption that the network. layer provides an peerto-peer addressing capability. The basis of addressing in the higher layers is service user selectionthrough SAP's. So, the addresses used in the OSI environments comprise a concatenation of anumber of subaddresses (SAP's).The address of an application is made up of :

Application address = PSAP + SSAP + TSAP + NSAP

where PSAP is the service access point subaddress between the application layer protocol entity towhich the application is attached and the presentation layer, SSAP is the service access pointsubaddress between the presentation layer and the session layer, and so on.

The two above layers, addressed with PSAP and SSAP, use the datacommunication service whichis provided by the layers below. These lower layers are concemed with establishment and controlof datacommunication between computersystems. The NSAP contains the physical network.-wideaddress of the system in which the application is resident. The PSAP,SSAP and TSAP addressesare then used within the system to deterrnine the specific application layer protocol entity to whichthe user application is currently attached.

2.6 Summary

This chapter described the OSI Reference model which is forrnulated by the International StandardOrganisation (ISO). The idea is to cure all interconnectivity problems by replacing the user'sproprietly systems with OSI standard produets and services. The principles that were applied toarrive at the seven layers, each with a particular task, are discussed with the emphasis put on thethree higher layers : the presentation layer and its adjacent layers. The layer cooperation in the OSIReference Model is discussed for peer entities and for adjacent layers. The key idea is thatalthough actual data transmission is perfonned between adjacent layers, each layer is programmedas thought it were horiwntal. Each layer offers a set of services to its upper layer. To providethese services it has to perfonn functions in conjunction with a corresponding layer entity in aremote end-system. The services are send to SAP's (Service Access Points), which identifycommonly the application address.


Chapter 3

The Presentation Layer in more detail

3.1 Introduction

The presentation layer has evolved considerably since the start of the OSI work more than 10 yearsago. In the beginning it was mainly conceived of as the place where conversion could be done toallow computers with an ASOI character code-table to communicate with computers with anEBCDIC character code-table (these last tables are used by the larger IBM-computers). Later itevolved to a layer that should permit visually-oriented programs, like full-screen editors, to workwith a variety of terminals. As a result of this evolution, it was decided to assign all tasks relatingto representation of transmitted data inc1uding conversion, compression and encryption to thepresentation layer. After this evolution it could be remarked that the term "presentation layer" hasbecome something of a misnomer. The name "Representation layer" would be better.

As seen in chapter 2 is the presentation layer the lowest layer which is not interested in movingbits reliable from computer A 10 B. For its operations it assumes areliabie transmission. Thepresentation layer is only concemed with preserving the meaning of the information transported. Itprovides a common representation for application information while it is in transit between peerapplication processes over an OSI data communication channel, i.e. asession connection. The peerapplication processes exchange information by the use of presentation services (the several serviceswhich are provided by the presentation layer will be described in chapter 5 of my thesis). Therepresentation of the contents of an information unit is the responsibility of the presentation layer.Thus by using the services of the sixth OSI layer an application layer can communicate with itspeer entity regardless of the local representation of the bits in this peer-entity.

In the following sections the different functions of the presentation layer will be described.

12

3.2 Data Representation

Since the introduction of computers there are specimen with different intemal representations fordata. When nothing is done about it, these differences will cause trouble with data transfer.When a computer transmits a sequence of integers and uses an encoding of 16 bits binary for aninteger and the receiving computer uses a 32 bits binary encoding, it's obvious that a commonagreed encoding is needed. Such a problem also occurs when a sequence of charaeters istransmitted between a computer with an ASCII charaeter code-set and another with an EBCDICcharacter code-set.

But there are several more reasons that can be cited for misunderstanding during data transfer. Forexample most microcomputers use two's complement arithmetic, but a few others use an one'scomplement arithmetic. Due to the difference in representation, a bit pattem FFFO (hexadecimal)will print as -16 on the two's complement computers and as -15 on the one's complementcomputers. Another example is the existence of big endian and little endian computers. The bigendian computers, like the Motorola 68030, 68040 and the larger mM mainframes, number theirbytes from left to right. The little endian computers, like the Intel 80386, 80486 and DEC VAXchips, number their bytes from right to left. Suppose that two communicating computers use 4bytes 10 represent an integer and the little endian computer sends the integer "I". The big endiancomputer will recognize the integer as 1*231 = 2147483648. One may think that the solution to thisbig/little endian problem is rather straight forward : you just have to change the positions with aconversion program. It's however not that simpie. For example, binary fields have to be converteddifferently than boolean fields, which must be converted differently than scientific notation fields.

The described differences in computerarchitectures will rarely change, because the manufacturerswant 10 avoid incompatibility between their old and new products.

It will be clear that to solve above problems a conversion will have to be made somewhere. Manyways have been proposed 10 deal with this problem :

• The sending computer could do the conversion of data• The receiving computer could do the conversion of data• Both the sender and receiver could convert to and from a network standard format

In the first two conversion possibilities every computer must be aware of the intemal format usedby every other computer in the network. In the first option the sender converts the data from itsintemal format into the format of the receiver. In the second , the contrary have to be done. In thelast given conversion possibility on both ends a conversion is needed : to and from networkstandard format. An illustration of the above possibilities is given in Figure 3.1.

An advantage of the first two conversion possibilities is that only one conversion is required. However, a disadvantage is that with n different types of computer-architectures in the network, n*(n1) different conversion routines must be written. Also when a computer with a new architecturewill be instalied in the network all conversion-routine-libraries of the existing network computershave 10 be adjusted. The third conversion possibility requires only 2*n conversion routines: going10 and from the common known syntax. Also, none conversion-routine-library has to be adjustedwhen a computer with a new architecture will be installed in the network. However, a disadvantageis the performing of two conversions per transmission : at the sender and receiver sides.

Chapter 3: The Presentation layer in more detail. 13

Figure 3.1 : The advantage of a common syntax.

ISO has chosen for the third conversion option and has devised a standard notation called "Abstract Syntax Notation 1" or ASN.I for short [X.208]. Abstract means that the notation is not implementation-dependent. ASN.I 's Ianguage supports a notation for defining Application specificProtocol Data Units (APDU's). So, the application Iayer of OSI represents all datastructures thatare used by the several applications in ASN.l. The suffix indicates that it's ISO's first recommended notation, but that additional standards may appear in the future. The reason for introducingnew notation standards may he that not all existing applications could he descrihed by ASN.1. Forexample, assigning a certain colour 10 a line or box isn't possible in ASN.I .

For now, both presentation Iayers of the communicating computers know the common representation of the data that is given from the application Iayers. Now the presentation Iayers have toencode/decode the data that is specified in ASN.I . These rules for encoding/decoding ASN.Idatastructures are formulated in [X.209]. The format of the bitstream is called the transfer syntax.Until now only one transfer syntax is recommended : the Basic Encoding Rules or BER for short.

The combination of an abstract syntax and a transfer syntax is called a Presentation Context Infuture when more abstract syntaxes and transfer syntaxes are standardized, the presentation entitieshave 10 negotiate about the presentation context to he used. Ourlng the presentation-link setup therequesting presentation entity can associate more than one transfer syntaxes to a certain abstractsyntax. Also it's possible that different abstract syntaxes use the same transfer syntax. Theresponding presentation entity will accept at most one transfer syntax per abstract syntax. At amoment only one presentation context can he active which is identified by a presentation contextidentifier. The identification of the abstract syntax and transfer syntax is done with an abstractsyntax name and a transfer syntax name.

The recommended abstract syntax notation ASN.I and the transfer syntax BER will he expandedupon in chapter 4. In chapter 5 of my thesis the protocol of the presentation Iayer will he descrlbedas defined in [X.216] and [X.226].


In the next two sections of this chapter two other functions of the presentation layer will heexpanded. For these functions standards are not yet fonnulated.

3.3 Data Compression

Because network operators expect to he paid for their efforts, data compression is perfonned toreduce the costs for data transfer over networks. Although these costs are not linear with theamount of data sent, it's c1ear that it can he reduced by compressing the data hefore sending them.

The existing data compression techniques are based on one of the three approaches :

• The finiteness of the set of symbols• 1be relative frequencies with which the symbols are used• The context in which asymbol appears

Within ASN.l data the following types of redundancy can he found :

• Character distribution

In a character string, some characters are used more frequently than others. Thus we can reduce theaverage of bits needed per character.

• Character repetition

A character string will frequently have repeated blanks. Also, integer values for a hollow matrixcontains repeated zeros. In all these cases, the infonnation can he usually encoded in a morecompact way.

• High-usage-pattems

Certain sequences of characters will appear with relative high-frequence. Therefore, they can herepresented with relatively fewer bits.

• Positional redundancy

Certain sequences of characters appear consistently at a predictable place in each bloc of data. So,representing them can he done with fewer bits.

The reason for using a compression method is 10 reduce the duration of a communication session.This duration will he reduced by a factor (~) :

~t i RIJ = with eorrpress on =2. (_t) +a~ t wi thout eorrpression Re

With: a =average compression ratio~ = data rate of the transmission networkRç =compression speed


The factor "2" accounts for compression at one site and decompression at the other side; ooe couldpossibly argue that the two operations will be performed in parallel. Suppose a compression ratio <X

of 0.5 aod a compression rate Re of 150 kbit/s. For public X.25 networks with an average data rateR. between 1 aod 9 kbit/s, the reduction factor ~ will be between 0,51 and 0,62. So, when ~ isaImost equal to <X usage of compression is justified.This is no longer true for local area networks and ISDN, where an end 10 end data transmissionrate above the 1 Mbps is not uncommon. Compression would not be envisaged since ~ is greaterthan 1 for compression algorithms implemented in software. When implementing such algorithmsin hardware, they could be used for data transmission rates up 10 100 Mbps.

The interesting reader can fmd numerous data compression teehniques in the literature [Held83]. Acomparison of existing compression methods is given in [Lam86].

3.4 Data Encryption

Another commonly mentioned function of the presentation layer is the encryption of data. Thisencryption is done to achieve security of the millions of bits of data that daily move betweencomputers. It makes the data unintelligible to all but their intended recipient.

Without any security an unauthorized person cao copy the data for example by wiretap and therebyhas a notion of the information of the data. This is an example of a passive threat, i.e. a violationof security which do not result in modification of any information and where the system operationis not altered. Active threats are those which cause system operation to be effected, information tobe modified, or services to be interrupted.

In the OSI Reference Model, the need for providing security is weIl recognized. The ISO defines abasic set of security functions that are believed to be important from the viewpoint of providingsecure communication between the peer entities in the OSI Reference Model.

The functions which ISO defines to provide secure interchange of information between communication entities are :

• Authentication

The verification of the identity of an entity by its peer. This can be done by using digital signatures. These signatures allow asender to logically sign a data unit before transmitting it, and for areceiver to verify the signature associated with the receiveddata.

• Access Control

Providing protection against unauthorized use of resources (for examplea data base). Access control mechanisms enforces access rights of an entity whose identity hasalready been authenticated. It ensures that the entity does not access an unauthorized resource.

• Confidentially

Protection of all user data during data transfer against unauthorized disclosure. Encryption providessuch confidentiality of information during transfer or s1orage.


• Integrity

Protection of user data contained within a single data unit from being modified, or user datacontained in a stream of data units from being modified, inserted, deleted, or replaced. To verifythis integrity a hash function can be used.

As seen, encryption is used as a mechanism for providing confidentiality of infonnation. However,it may also be used in conjunction with other mechanisms to support the other security functionsdescribed. The several encryption techniques will not be explained here, because it's not in thescope of my thesis.

Although data encryption is commonly mentioned as a typical presentation layer task, almost allOSI layers could perfonn this task.From the viewpoint of the user the encryption of data in the presentation layer gives the mostflexible solution. Because in the CCITI recommendations [X.216] and [X.226] all mention of theencryption task was omitted, it is not officially a task of the presentation layer. However, also therecommendations of the other OSI layers do not mention this task.

An overview of all security mechanisms for the OSI Reference Model is given in table 3.1.

Table 3.1: Security mechanisms in the OSI Reference Model.

Security Mechanisms in the OSI Reference Model

Operation Systems Human user, User Authentication, Access& Applications Control, Transaction Security

Application Layer Appl. Authentication, Acces Control,Encryption, Sign's

Presentation Layer Data Encryption

Session Layer

Transport Layer Data Encryption, Sign's, System AccessControl

Network Layer Data Encryption, Sign's, System AccessControl

Data Link Layer Data Encryption

Physical layer Data Encryption


3.5 Summary

The presentation layer evolved to a layer which consists all tasks relating to representation oftransmitted data. By using the services of the presentation layer an application layer can communicate with it's peer entity regardless of the local representation of the bits in this peer entity. Forperfonning this task CCIrr defined an abstract syntax and a transfer syntax.

Another task for the presentation layer is compression of the transmitted data. Compression isperfonned 10 reduce the costs for data transfer over networks. This task isn't defined yet in theCCIrr recommendations [X.216] and [X.226].

Another task which isn't defined in the recommendations is data encryption. Although it's acommonly mentioned function of the presentation layer, data encryption can he perfonned inalmost every OSI layer. From the viewpoint of the user the encryption of data in the presentationlayer gives the most flexible solution.


Chapter 4

The Recommended Abstract - andTransfer Syntax

4.1 Introduction

To provide communication between two computers, all OSI layers have 10 establish a peer-to-peerconnection. As seen in chapter 2 and 3, the presentation layer is the lowest layer which is notconcemed about a reliable data transfer. It assumes it. The peer application layers are using theservices of the presentation layer : the representation of the sending data. These services providethe possibility to interconnect computers with different hardware designs. The peer applicationlayers can also use the services of the presentation layer to compress or to encrypt the sendingdata.

Abstract Syntax Notation One (ASN.l) is an extemal data representation language defmed by ISOand COlT which support the forms of heterogeneous interconnection caused by the differenthardware designs of computers. ASN.l has been designed to be independent of any programminglanguage or operating system. When using ASN.1, the used datastructures are described in anabstract way, i.e. implementation independent. But a defmed datatype is still represented in a localway. For example as a 16 bits word. Therefore ISO formulated a transfer syntax to define howvalues of these data types are represented serially for communication. A standardized transfersyntax is the Basic Encoding Rules or BER for short.

Originally, ASN.l and BER were defined by the CCITI for the X.400 Message Handling System[X.400] in 1984. In this specification, ASN.l and BER were combined into a single languagecalled X.409 [X.409]. ISO adopted X.409 and separated it into two parts to permit the specificationof multiple transfer syntaxes. The ISO version is defined in IS08824 and IS08825 and is the sameas the CCITI version defined in [X.208] and [X.209].

As indicated in Figure 4.1, the presentation layer will encode the data fiom the local format, specified in ASN.l, into some common form before transmission, a transfer syntax, and will deco<1e thereceived data from the common form to the local format after reception.

19

Local format( Abstract S.) Local format

• •computer A computer B

t / "- tI Code I loeCOd,• (TransferS. ) •

"- /Odets

Figure 4.1: presentation : coding and decoding.

Thus the specification of the application specific data, i.e. the abstract syntax, is defined in theapplication layer and the rules governing the conversion to and from the transfer syntax are foundat the presentation layer.An example of an abstract syntax, a record of "Hospitallnfo", defined in Pascal is given below.

Type HospitalInfo = recordPatientnumber : integer;Name : string;Age : integer;Male : boolean;OinicalPicture : PatientHistory;

END;

Type PatientHistory = recordIllness : string;TreatinLdoctor : string;TreatinLdate : string;Admision_date : string;Medicine : string;

END;

Above abstract syntax cou1d be used to defme the following values:{ Patientnumber 13,

Name Anderso~

Age 45,Male True,eteetera.

Chapter 4: The recommended Abstract· and Transfer syntax. 20

Other examples of abstract syntaxes are :

• floating point nomber• sequence of cbaracters from the ISO IA5 charaeter set (see

Table 4.4)• integer fol1owed by floating point nomber• integer fol1owed by boolean fol1owed by sequence of

characters from ISO 1A5 character set

An abstract syntax is assigned with an identifier, an abstract syntax name. In the above givenexample the abstract syntax name could be "Hospitallnfo". Similarly a transfer syntax has an associated transfer syntax name. A pair of abstract syntax and transfer syntax is known as a presentation context.

As mentioned, only ASN.I and BER are fonnulated as an international standard. In future moreabstract syntax notations and transfer syntaxes are expected to be available. New abstract syntaxnotations could be introduced when not all applications could express their functionality usingASN.1. For example, such applications could use built-in types 10 define dimensions, colours, linethickness for a graphical object Alternative transfer syntaxes could be fonnulated because they aremore efficient than BER or because they provide other tasks like compression or encryption. In thestandards [X.216] and [X.226] is fonnulated that the two presentation entities have to negotiateabout the using presentation context before data will be transmitted. So, when new transfersyntaxes are standardized the presentation entities have to negotiate about the using presentationcontext before data can transmitted. The specific protocol, within this negotiation process, of thepresentation layer will be expanded in chapter 5.

In the fol1owing two sections the fonnulated standards ASN.I and BER will be described. Also afew alternative transfer syntaxes will be discussed.

4.2 ASN.l

ASN.l is a data description language associated with the OSI presentation layer. It can be used todefine the Application Protocol Data Units (APDU) that will be send to/from the presentationlayer. The principle is the same as that adopted with most high-level programming languages fordefining the data types associated with the variables used in a program: as each variabIe isdeclared, the data type associated with it is also defmed. Then, when a value is assigned 10 thevariabIe, its syntax is of the defined type. ASN.l doesn't provide any control structure such as a"while" or "ir' statement that can be find in the common programming languages.

The advantage of ASN.l is that it is standardized and implementation independent. For example,an integer defined in the programming language C shall be represented with a nomber of bitsdepending of the computer the program operates on. ASN.l has been designed to be independentof any programming language or operating system. Therefore the interconnection of programs, thathave been implemented in different languages and environments is possible. Besides ASN.l acommonly known transfer syntax is necessary. In section 4.3 the standardized transfer syntax BERwill be explained. The major goal of OSI with ASN.I is the communication between heterogeneous systems. However, this independence bas also negative aspects. Because ASN.l does not mapdirectly onto the data types of most existing programming languages, it's often necessary to extendthe data types of ASN.l using the type construetors facilities.


The complete grammar of ASN.l is given in appendix n of [X.208]. With this specification it'spossible 10 build a lexical scanner for ASN.l. With this lexical scanner the syntax of an ASN.lrecord could be checked.

4.2.1 ASN.l types

In order 10 correctly interpret the representation of a data value, it is necessary 10 know the type ofthe value being represented. For example : the patientnumber value "13" is of type integer. Thepurpose of specifying a value is to distinguish it from other possible values. Each value is specifiedby its type. ASN.l supports a number of type identifiers that may be member of four classes (seealso table 4.1) :

• UNIVERSALTypes of this class are the generalized types such as integer and can be used by everyapplication.

• CONTEXT-SPECIFICThese types are related to the specific context in which they are used.

• APPLICATIONThese types are common to a complete application entity.

• PRIVATEThese types are user definable.

Table 4.1: Tbc four classes of types.

UNIVERSAL

CONTEXT-SPECIFIC

APPLICATION

PRIVATE

The type identifier of the first class, the universal class, may be primitive (simpIe) or constructed.Primitive types specify the values on the lowest level, i.e. they cannot be decomposed anymore.The primitive types ASN.I is composed of are (see also Table 4.2) :

• INTEGERIt contains a set of all positive and negative whole numbers, including zero (as a single value).

• BOOLEANIt distinguishes two values : True or False.

• BIT STRINGIt consists of any string of bits : zero, one or more.

Chapter 4: The recommended Abstract- and Transfer syntax. 22

• OCfET SlRINGIt consists of a ordered sequence of zero, one or more octets, each octet being an orderedsequence of eight bits.

• REALIt consists of all possible real number values :

M * BE with M = mantissaB = baseE = exponent

• ANYIt doesn't specify a specific type, but is restrieted to the set of types which can be definedusing ASN.l.

• NULLIt consists of a single value, also called null. It is commonly used where several altematives arepossible, but none of them apply, i.e. it represents an empty value.

• OBJEcr IDENTIFIERIt is used to identify an OSI infonnation object in a universally way. Such a value is unique, i.e.distinguishable from all other such values.

Table 4.2: ASN.l primitive types.

INTEGER

BOOLEAN

BIT STRING

OCTET STRING

REAL

ANY

NULL

OBJECT IDENTIFIER

OBJECT DESCRIPI'OR

ENCRYPTED

ENUMERAlED

• OBJEcr DESCRIPTORIt consists of human-readable text providing a brief description of an infonnation object.


• ENUMERATEDA type whose values are given distinct identifiers as part of the type notation.

A type identifier of the UNIVERSAL c1ass may also of the constructed type. For such types theprimitive types of Table 4.2 can he used to build more complex datastructures. A constructor typeis a type defined by reference to one or more other types, which may he primitive or constructed.The Irnown ASN.l construetors are (see also Table 4.3) :

• SEQUENCEIt defmes a fixed, ordered list of elements. Some of these elements may he declared optional, Le.the associated typed value may he omitted by the entity constructing the sequence. Each value ofthe new type is an ordered list of values, one from each component type.

• SEQUENCE OFIt defmes a fixed or unbounded, ordered list of elements, all of the same ASN.l type.

• SETThis type defines a fixed, unordered list of elements of ASN.l types, some of which may hedec1ared optional.

• SET OFThis type defines a fixed or unbounded, unordered list of elements, all of the same type.

• CHOlCEThis type defines a fixed, unordered list of elements, selected from a previously specified set oftypes.

• EXTERNALThis type defines an element by referring to an element in another abstract syntax without having10 inc1ude the latter.

Table 4.3: ASN.l constructors.

SEQUENCE

SEQUENCEOF

SET

SET OF

CHOICE

EXTERNAL

Now we have definitions for the built-in (simpIe) types and tools for creating new constructedtypes. It's possible to define a library of types useful for most applications. Thus, each applicationdoesn't have to create these types over again. In the ASN.l standard a set of useful types is inc1uded. The first set of types are different subsets of OCfETSTRING, the last set defines differenttypes of time formats (See Table 4.4 and 4.5).


• NumericStringIt contains the digits (0..9) and the space.

• PrintabieStringIt consists of (A..Z), (a..z), (0..9), space and ('()+,-./:=?).

• TeietexStringIt contains the teletex character set.

• VideotexStringIt contains the videotext character set.

• VisibieStringIt contains the printing characters from the ASCII set.

• IASStringIt consists of the octets that are defined by the IA5 standard : ASCIIcharacters and carriage contmis.

• GraphicStringIt contains various international versions of ASCII.

• GeneralStringIt contains a superset of GraphicString with control characters.

Table 4.4: Character stringtypes.

NumerieString

PrintableString

TeletexString

VideotexString

VisibleString

IASString

GraphicString

GeneralString

Table 4.S: Time types.

GeneralizedTime

UniversalTime


• GeneralizedTimeIt embraces the time in the format YYYYMMDDhhmrnss.

• UniversalTimeIt embraces the time in the format YYMMDDhhmrn.

Final1y, it's possible to decIare a data field OPfIONAL, i.e. the data field does not have to hetransmitted. Also a data field can he declared DEFAULT, followed by the value to he used by thereceiver if the particular data field is not transmitted.

After tbe above discussion of the known ASN.I types its now possible to convert the given Pascaldescription of "Hospitallnfo" in section 4.1 into ASN.1 :

Hospitallnfo ::= SEQUENCEPatientnumher NumericStringName PrintableStringAge INTEGERMale BOOLEANClinicalPicture PatientHistory;

PatientHistory ::= SETIllnessTreatin~doctor

Treating_dateAdmission_dataMedicine

OCI'ETSTRINGOCI'ETSTRINGUniversaITimeUniversalTimeBITSTRING

Both abstract syntaxes could he of the constructed type SEQUENCE or SET. Because of thedifferent encoding (see section 4.3.1.4) of the types SEQUENCE and SET is chosen for these twotypes.

4.2.2 Tagging

Every described ASN.I type, whether simple or constructed, is indicated with a tag. Such a tag isused to identify a value of a type. To provide this identification, a tag is transmitted with the value.However sending the kind of type by its name in characters is effective, it's not efficient. Thus instead of sending it's name a specific code will he transmitted together with the data value. Tagswill he written in square brackets, like [I]. The square brackets will not he transmitted. Thistagging is closely related to the Basic Encoding Rules that will he descrihed in section 4.3.1.

As seen in section 4.2.1 there are four classes of types. Each class will he specified duringencoding (see section 4.3.1.1). For each of these classes tags are specified :

• UNIVERSALThe ASN.l standard formulated the tags for the types of the "Universal class". These types arethe primitive-, character string-, time- and the constructor types (see Table 4.2, 4.3, 4.4 and 4.5)and can he used by every application. The specific tags in this c1ass are given in Table 4.6.


• CONTEXT-SPECIFICContext-specific tags are used 10 distinguish the members of a set Numeric tags starting withzero will be assigned to the elements if their only constraint is distinctness.

For example :

PatientHis10ry ::= SETIllnessTreatin!Ldoc1orTreatin!LdateAdmission_dataMedicine

[0] OCTETSTRING[1] OCTETSTRING[2] UniversalTime[3] UniversalTime[4] BITSTRING

With help of the context-specific tags [0], [1], [2], [3] and [4] the set members are alwaysdistinctable.

Table 4.6: Universa! types.

I Tag nr. I TypeI1

Tag nr. Type

1 BOOLEAN 16 SEQUENCE&SEQUENCEOF

2 INTEGER 17 SET & SET OF

3 BIT STRING 18 NumericString

4 OCTET 19 PrintableStringSTRING

5 NULL 20 TeletexString

6 OBJECT 21 VideotexStringIDENTIFIER

7 OBJECT 22 IA5StringDESCRIPTOR

8 EXTERNAL 23 UniversalTime

9 REAL 24 GeneralizedTime

10 ENUMERATED 25 GraphicString

11 ENCRYPTED 26 VisibleString

12-15 Future recom- 27 GeneralStringmendations

28 Future recom-mendations


In this example every patient which is treated in the hospital by a doctor will always getmedicine and in admission. Lets update the SET "PatientHistory" in :

PatientHistory ::= SETIllnessTreatin~doctor

Treatin~date

Admission_dataMedicine

[0] OCfETSTRING[1] OCfETSTRING[2] UniversalTime[3] UniversalTime OPTIONAL[4] BITSTRING OPTIONAL

With the keyword "OPTIONAL" is declared that these last two data items mayor may not hetransferred. With the context-specific tags it is now possible for the receiver to discern the values.

However. since this tag designates the position of the field in the datastructure. it follows that theUNIVERSAL tags are superfluous when constructor types are used. ASN.1 provides a way ofsuppressing the type infonnation when context-specific tags are used by adding the wordIMPLICIT. If IMPLICIT is omitted both tags are transmitted as a kind of run-time checking.How the defined data will he transmitted could he seen in section 4.3.1.4.Rewriting the given "PatientHistory" gives :

PatientHistory ::= SETIllnessTreating_doctorTreatin~date

Admission_dataMedicine

[0] IMPLICIT OCfETSTRING[1] IMPLICIT OCfETSTRING[2] IMPLlOT UniversalTime[3] IMPLlOT UniversalTime OPTIONAL[4] IMPLlOT BITSTRING OPTIONAL

• APPLICATIONAD application-wide tagged type will he used to defrne a data type that frnds wide. scattered usewithin a particular presentation-context and that must he distinguishable (by means of itsrepresentation) from all other data types used in the presentation context.For example :

HospitalInfo ::= [APPLICATION 0] IMPLICIT SEQUENCEPatientnumher NumericStringName PrintableStringAge INTEGERMale BOOLEANClinicalPicture PatientHistory

PatientHistory ::= [APPLICATION 1] IMPLICIT SETIllness [0] IMPLlOT OCfETSTRINGTreating_doctor [1] IMPLlOT OCfETSTRINGTreatin~date [2] IMPLICIT UniversalTimeAdmission_data [3] IMPLlOT UniversalTime OPTIONALMedicine [4] IMPLlOT BITSTRING OPTIONAL

When the receiver gets data according to abovc datastructure. it detennines it by the[APPLICATION] tags. For example. when [APPLICATION 0] is accepted the receiver knows itgets data according the "Hospitallnfo" abstract syntax. For the same reason as above the tags


SEQUENCE and SET can be defined IMPLICIT.

• PRIVATETags of this class are used on an enterprise-specific basis. By using the [PRIVATE] tags theuser denote their own types. The tags are used in the same way as the APPLICATION tags.

4.3 Transfer Syntaxes

In the above sections ASN.I has been explained. ASN.I is an abstract syntax notation whichmeans that although a data element is defined to be a specified type, this does not imply that it hasa fixed representation. For example a variable of type INTEGER in one computer may have adifferent syntax in terms of the number of bits and position of the sign-bit than an INTEGER typein another computer. So even thought the various data elements making up a PDU are of the sameabstract type, their syntax may be different (other possible causes of different intemal syntaxes aregiven in section 3.2). Thus the values for a particular abstract syntax must be converted inaccordance to the mIes of a transfer syntax for transmission. The rules that describe the format ofthe types are called the encoding ru/es. Although ASN.l permits many different transfer syntaxes,at the moment there is only one standardized, the Basic Encoding Rules BER.

In the following two sections BER will be explained and some other proposed encoding mIes willbe introduced.

4.3.1 BER

The BER represent a value of each type as a data element comprising three fields :

• IdentifierThis field defines the ASN.I type and specifies how the contents field have 10 be interpreted.

• LengthThis field defines the number of octets in the contents field.

• ContentsThe contents field defines the contents which may be another data element for the stmcturedtype.

The data element is also identified by the term TLV (Type,Length,Value) and can be comprised ofa single or multiple elements. So it can consist of a single or a multiple TLV scheme.In Figure 4.2 an illustration is given of the possible data elements. The data element consists of anintegral number of octets written with the most significant bit (MSB) on the left side, i.e. the bigendian notation (see section 3.2).


rr-----------A --------------....,

(11) MuIlIlIe E__

NotI (1) The ldInIIlIer lIeId la aI80 C8118d 1he lp.NotI (2) The Conlllntllleld la aI80 C8118d 1he V81ue.

Figure 4.2: The X.209 Data Elements.

4.3.1.1 Identifier octets

The identifier octets are the tags to identify a type of a value. Dependent of the number of the tag,one or more identifier octets are used. As seen in section 4.2.1 there are four classes of types :

• UNIVERSAL• APPLICATION• CONTEXT-SPECIFIC• PRIVATE

As mentioned, all types in ASN.1 must have a tag. The built-in simple types, character string typesand the structured types have predefined tags as specified by ASN.1. All these types are UNIVERSAL, i.e. types that can be used by any application.

As illustrated in Figure 4.3 the identifier is composed of three fields:

• Bit 8 and 7 of the most significant identifier octet is used for specifying one of the four classesof the used type

• Bit 6 specifies whether the element is a primitive or a constructed type• A tag field which can contain five or more bits depending on the nomber of the tag.

As illustrated in Figure 4.3a, in a single-octet identifier, a tag can be specified when its nomber isless then 25-1=31. If a tag va!ue is larger, the long form has to be used (Figure 4.3b). In the longform, bit 5 10 1 of the most significant identifier octet are set to 1. If bit 8 of a subsequent octet isset to a 1, it indicates that more octets will follow. The last octet is indicated with bit 8 set to O.For example, the identifier octet of an integer (as can be seen in Table 4.6 it has tag number 2)which is a primitive type of the universa! class will be encoded as : OOOOOOI~.


ldInIIIier 0CIIt

~• 7 ti 5 .. 3 2 1

ED_d"~ca..bit, blt7o 0 unJYi'üïo 1 AppIcalIon1 0 ConIexl-tp8Clllc:1 1 PrtvG

F: Form oIlhe element

bit,o1

~O*t 2nd 0CIIt 3Id O*t !utO*t

~ .---A--- .---A--- .---A---• 7 , 5 .. 3 2 1

ED' 11 11 ~[JI[JI [JI[JI-+-+...+-+-

Figure 4.3: X.209 Identitier.

When the tag-number is 152 of a constructed type of the c1ass Application the identifier field willbe encoded as: 01111111 I()()()()()()I 000110002

Thus bit 7 to I of the first subsequent octet, followed by bits 7 to I of the second subsequent,followed in turn by bits 7 to I of each fiuther octet. up to and including the last subsequent octetin the identifier octets shall be the encoding of an unsigned binary integer equal to the tag number,with bit 7 of the first subsequent octet the most significant bit. Also have 10 be applied that bit 7 toI of the first subsequent octet shall not all be zero.

4.3.1.2 Length octets

In the BER standard, two forms of length octets are specified:

• the definite form• the indefinite form

The sending presentation entity shall use the definite form if the encoding is primitive. It will useeither the definite or the indefinite form, as asender's option, if the encoding is constructed and alldata is immediately available. When the data is not all available the indefmite form shall be used.

The length octets indicates how long the contents field is. This length does not inc1ude itself or theidentifier octets. For the definite form, the length octets shall consist of one or more octets andshall represent the number of octets using the short or the long form. The short form can only beused if the number of octets in the contents field is less than or equal to 127 (2'-1). In that casethe length component is one octet long with the most significant bit (bit 8) set to 0 and theremaining seven bits containing the value length as an unsigned binary integer. For example :L=41 can be encoded as 001010012•


In the long fonnat, the length octets shall consist of an initial octet and one or more subsequentoctets. The initial octets shall be encoded as follows :

• bit 8 is set to I to indicate the long fonn• bit 7 to I of the first length octet shall encode the number of subsequent octets in the length

octets, as an unsigned binary integer• the value 111111112 shall not be used (for future extension)• bit 8 to I of the first subsequent octet, followed by bit 8 to I of the subsequent octet up to and

inc1uding the last subsequent octet shall be the encoding of an unsigned binary integer equal tothe number of octets in the contents octets with bit 8 of the first subsequent octet at the mostsignificant bit. For example L=273 shall be encoded as 10000010 00000oo1 00010001 2

The indefmite length fonn is used when it's not known at the time the value is converted to itstransfer syntax what its length is. This can be caused by the presentation layer when it has notenough memory to fit all data. In this situation, it is forced to start transmission before the numberof data octets is known. For the indefinite fOnTI the length octets indicate with the codeI~that the contents will be tenninated by two end-of-contents octets. Such a end-of-contents octetsshall consist of two zero octets. In practice it's possible that contents octets appear in the samefonnat as the end-of-contents octets. This problem is not solved yet by CCITI.

4.3.1.3 Contents octets

This field contains the actual infonnation and its encoding depends on the type of the data value.The contents field shall contain the encodings of values of one or more ASN.I types dependingwhether its primitive or constructed. The standardized BER discusses all known ASN.l types andhow to encode them. In this section the ASN.I types will be discussed that were used in the"Hospitallnfo" datastructure example. For a complete discussion of the other ASN.I types isreferred to [X.209].

Encoding of a BOOLEAN valueIt is a primitive type. The contents octets shall consists of a single octet:

OOOOOOOO2non-zero

if Falseif True

Encoding of an INTEGER valueThe encoding of such a type shall be primitive. The contents octet consists of one or more octets.When it consist of more than one octet, the bits of the first octet and bit 8 of the second :

• shall not all be ones• shall not all be zero

These rules ensures that an integer value is always encoded in the smallest possible number ofoctets. The encoding of the contents octets is a two 's complement binary number equal to theinteger values and consisting of bit 8 to I of the first octet, followed by bit 8 to I of the secondoctet, followed by bit 8 to I of each octet in turn up to and include the last octet of the contentsoctets.


The bits in the contents octets shall be nwnbered with 0 for the Least significant bit (LSB) of thelast octet and ending with bit 8 of the first octet. In this way the value of the contents octets shallbe encoded. For exarnple C=545 shall be encoded as 00000010 001000012•

Encoding of a BITSTRING valueThe encoding of such a value can be primitive or constructed as asender's option. The contentsoctets for the primitive encoding shall contain an initial octet followed by zero, one or moresubsequent octets. Thus the initial octet shall be encoded as an unsigned binary integer with bit 1as the least significant bit which represents the nwnber of unused bits in the final subsequent octet.This nwnber shall be in the range zero to seven otherwise an octet less can be used. Thisconstruction is necessary because the length fields indicate how many octets (=8bits) the contentsoctets consists of and not how many bits. If the bitstring is empty the initial octet shall be zero andthere shall be no subsequent octets.

The contents octets for a constructed encoding shall consist of the complete encoding of zero, oneor more data values. Each such an encoding includes identifier, length and contents octets and mayinclude end-of-contents octets if it is constructed. This fonn of encoding shall be used when it'snecessary 10 transfer part of a bitstring before the entire bitstring is available (= indefmite length).

Encoding of an OCfETSTRING valueFor such a value it is also possible to encode it as a primitive or constructed type. The constructedencoding is used when it is necessary to transfer part of an octetstring before the entire octetstringis available and shall consist of the complete encoding of zero, one or more data values. Eachencoding includes identifier, length and contents and may include end-of-contents octets if it isconstructed and the length field is indefmite.

Encoding of a SEQUENCE valueThe encoding of a sequence value shall be constructed. The contents octets shall consist of thecomplete encoding of one data value oom each of the known ASN.l types in the order of theirappearance in the defmition, unless the type was referred as "OPI10NAL" or "DEFAULT". Theencoding shall appear for values of these types at the point corresJX)nding to the appearance of thetype in the ASN.l definition.

Encoding of a SET value :The encoding of a set shall be constructed. The contents octets shall consist of the completeencoding of the data value from each of the types listed in the ASN.l definition of the set type, inan order chosen by the sender, unless the type was referenced with "OPI10NAL" or "DEFAULT".When using these types the encoding of a data value may, but need not, be present. When usingthe SET type the order of data values is not significant and places no constraints on the orderduring transfer.


4.3.1.4 A BER encoding example

In this section the abstract syntaxes "Hospitallnfo" and "PatientHistory" will be used 10 illustratethe encoding according 10 the standardized BER. For the surveyability these abstract syntaxes aregiven below once again.

Hospitallnfo ::= [APPLICATION 0] IMPLICIT SEQUENCEPatientnumber NumericStringName PrintableStringAge INTEGERMale BOOLEANCIinicalPieture PatientHis10ry

PatientHistory ::= [APPLICATION I] IMPLICIT SETIllness [0] IMPLICIT OCTETSTRINGTreatinLdoc1Or [I] IMPLICIT OCTETSTRINGTreatinLdate [2] IMPLICIT UniversalTimeAdmission_data [3] IMPLICIT UniversalTime OPTIONALMedicine [4] IMPLICIT BITSTRING OPTIONAL

Suppose, the data values according 10 the IHospitalInfo" and the IPatientHistory" abstract syntaxesare fonnally described below using ASN.1.

{

}{

}

PatientnumberNameAgeMaleClinicalPicture

IllnessTreating_doctorTreatinLdateAdmission_dataMedicine

13,Anderson,45,True,PatientHistory

Gastritis,Peterson,92040114009205081600Hitradoa

This ASN.I notation provides an implementation independent way to describe data values. Thusthe used '{', ',' and '}' symbols will not be inc1uded in the accepted data when the presentationlayer is implemented. They are only used for modelling the datastructure. The way above datavalue will be given from the application layer to the presentation layer is implementationdependent.

The result of the encoding of the given data values of the IHospitalInfo" and IPatientHistory"abstract notations according 10 the Basic Encoding Rules is shown below. The values of theidentifiers, lengths and the contents are shown in hexadecimal, two hexadecimal digits per octet.The encoding of some identifier octets of the "Hospita1Info" and IPatientHis1Ory" abstract syntaxesshall be worked out below. These identifier octets are marlced with a number.


Hospitallnfo Length Contents60(1) 4D

Patientnumber Length Contents12a> Ol OD

Name Length Contents13(3) 08 41 6E 64 65

72 73 6F 6E

Age Length Contents~4> Ol 2D

Male Length ContentsOl Ol Ol

PatientHistory61(5)

Length Contents38

lllness80(6)

Treatin1Ldate82(7)

Admision_date83

Medicine84

Length Contents09 4761 737472

69746973

Length Contents09 0850657465

72 73 6F 6E

Length ContentsOA 393230 34 30

31 31 34 30 30

Length ContentsOA 3932303530

3831 363030

Length Contents08 4869 74 72

6164 6F 61

The flnal encoded bitstream, that will be transInitted to the session layer, looks like :

6040 12 Ol 00 130841 6E 64 65 72 73 6F 6E 02 Ol 20 Ol Ol Ol 61 38 8009 47 61 737472697469 73 81 09 085065 74 65 72 73 6F 6E 82 OA 39 32 3034 30 31 31 34 30 30 83 OA 39323035 30 38 31 363030840848697472 61 64 6F 61

(I) Encoding of the identifier octet of the SEQUENCE value

bit 876543210l1~ =~

Bit 8 and 7 deterrnine the APPLICATION class.Bit 6 deterrnines that "HospitalInfo" is constructed.Bit 5 10 1 carry the tag number 0 that is declared with [APPLICATION 0].


(2) Encoding the identifier octet of the NumericString value

bit 876543210001001~

Bit 8 and 7 detennine the UNIVERSAL c1ass.Bit 6 detennines that NumericString is primitive.Bit 5 10 1 carry the tag number 18.

(3) Encoding the identifier octet of the PrintableString value

bit 87654321000100112

Bit 8 and 7 detennine the UNIVERSAL class.Bit 6 detennines that PrintableString is primitive.Bit 5 10 1 carry the tag number 19.

(4) Encoding the identifier octet of the INTEGER value

bit 876543210000001~

Bit 8 and 7 detennine the APPLICATION class.Bit 6 detennines that INTEGER is primitive.Bit 5 10 1 carry the tag number 2.

(5) Encoding the identifier octet of the SET value

bit 87654321011000012

Bit 8 and 7 detennine the APPLICATION class.Bit 6 detennines that SET is constructed.Bit 5 10 1 carry the tag number 1 that is declared with [APPLICATION 1].

(6) Encoding the identifier octet of the OCfETSTRING value

bit 876543211~ =8~

Bit 8 and 7 detennine the CONTEXT-SPECIFIC c1ass.Bit 6 detennines that OCTETSTRING is primitive.Bit 5 10 1 carry the tag number 0 that is dec1ared with [0].


(7) Encoding the identifier octet of the UniversalTime value

bit 87654321l00000l~

Bit 8 and 7 detennine the CONTEXT-SPECIFIC c1ass.Bit 6 detennines that UniversalTime is primitive.Bit 5 10 1 carry the tag number 2 that is declared with [2].

4.3.2 Alternative Transfer Syntaxes

In section 4.3.1 the BER for ASN.l was discussed. It can be seen that using BER the overhead(identifier and length octets) compared 10 the aetual data (contents octets) transferred can be ratherhigh. However this overhead provides the flexibility of BER : most types can be defined indefinite,i.e. there is no limit in data size. An example of this flexibility is the possibility of BER ofsupporting arbitrary wide integers. Another factor that influences the overhead is that BER is basedon bytes. This high overhead causes that the discussed BER transfer syntax is not favourable forhigh-speed networlcs. An illustration of this high cpu-consuming of BER is given in [Huit89]. Itshowed that the encoding according to BER introduced a delay of a factor 5 to 20 over directmemory copying. This is caused by the extended encoding of BER for each data value.

The transmission efficiency of BER could be increased if the receiver knows some characteristicsof the sending data. When the receiver knows the type and fonnat of the infonnation, the identifieroctet can be omitted during transmission. For example :

Hospitallnfo ::= SEQUENCEPatientnumber NumericStringName PrintableStringAge INTEGERMale BOOLEANOinicalPicture PatientHistory;

The members of SEQUENCE (also SEQUENCE OF and SET OF) don't have to consist anidentifier octet when all members are non-optional and the receiver knows that the data isaccording the "Hospital_info". Also the length of the contents octets is not always necessary whenthe receiver knows what type of data expected. For example the SEQUENCE or SET OF typedon't have to be encoded with a length field when the length is known by the communicatingapplications. Above considerations could be implemented in a new standardized transfer syntax.

Another way of increasing the transmission efficiency is to optimize the encoding of the commonASN.l types. For example, no length octets will be necessary when variables of type INTEGERwill always be encoded with a fixed number of octets. This way of optimizing restricts theflexibility of the original BER standard.

Alternative transfer syntaxes are discussed in [BESS88] and [HUIT89]. These faster transfersyntaxes are using the above described possibilities for increasing the transfer efficiency. In[BESS88] a transfer syntax is described which reduces the encoding and decoding procedures by afactor 5 to 20. In [HUIT89] a transfer syntax is described that can be 25 to 2500 times faster thanASN.I-BER.


Other tasks of the presentation layer need also other transfer syntaxes. Such syntaxes have toprovide the compression and encryption of the sending data. Presently, no transfer syntaxesproviding compression or encryption are being standardized. For more detail of these twopresentation layer tasks see section 3.3 and 3.4.

4.4 Summary

ASN.l is an extemal data representation language defmed by ISO and CCITI which supportsheterogeneous interconnection between computers. The used datastructures are described withASN.I types in an abstract way, i.e. independent of any programming language or operatingsystem. In future more abstract syntaxes are expected to become available.

When defining data in ASN.I it is still represented in a local way : for exarnple as a 16 bits word.Therefore ISO defmed a transfer syntax to define how values of an ASN.I type are representedserially for cornrnunication. For now, BER is tbc only standardized transfer syntax. BER encodesthe datastructures described in ASN.I according a TLV scheme. Other alternative transfer syntaxesare described in literature. They are focused on transmission efficiency, compression andencryption.


Chapter 5

The Recommended Presentation ProtocolMachine

5.1 Introduction

Chapter 2 showed that each OSI layer has to establish a peer-to-peer connection to provide its ownservices. For establishing such a conneetion each layer contains a Protocol Machine which is infact a set of protocols governing peer-to-peer communication. Such a Protocol Machine perfonnsall tasks to offer its layer's services to the layer above. These tasks could require an exchange ofProtocol Data Units (PDU's) hetween two peer-entities or may only invoke service primitives ofthe lower layer.

This chapter will he focused on the Presentation Protocol Machine or PPM for short. In chapter 3the several tasks of the presentation layer were discussed. To perform these tasks, the presentationlayer has to :

• negotiate about the transfer syntax used• transfonn to and from the negotiated transfer syntax

In chapter 4 the recommended ASN.l and BER were discussed. For now, BER is the onlystandardized transfer syntax. In future when more transfer syntaxes will he available, the twopresentation entities have to negotiate about the transfer syntax to he used. This negotiation issupported by the PPM. The transfonnation to and oom the negotiated transfer syntax is a funetioncontained within a presentation entity, but has no impact on the PPM design. In chapter 7 thisfunction, called encoder/decoder, will he discussed.

In the following sections the concemed service primitives of the presentation layer will hediscussed. In section 2.3.2 the creation of PDU's was discussed. The different exchangedPresentation PDU's, that provide the presentation services, and the mapping of these PPDU's onthe session service primitives will he explained.This chapter shall give an overview of the recommended PPM hecause a detailed description is notnecessary for understanding the given architecture of the presentation layer in chapter 7.For more detail is referred to [X.216], [X.226] and [Hurk.92].

39

5.2 The Service Primitives

In this section the concemed service primitives of the presentation layer will be discussed. Theseprimitives could be invoked by an application entity through a Presentation Service Access Point(PSAP). The presentation layer service primitives fall into two categories :

• Services that require the exchange of PPDU's between the two presentation entities. In this casean established presentation connection is required.

• Services that only call session services through Session Service Access Points (SSAP's) without aPPDU being generated.

AD overview of all presentation service primitives is given in Table 5.1.In this Table the following types, which were explained in section 2.4, are distinguished :

e =Confinned serviceNe = Non confinned servicePI =Provider initiated service (only an indication service primitive will be given 10 both

higher adjacent layers, see section 5.3.2)oe = Optional confinned

Table S.l: The Presentation Service Primitives.

Presentation primitive Type of Mirroring Purposeservice service

P-CONNECT C No Connection establishment

P-RELEASE C No Connection releaseP-U-ABORT NC No User-initiated abortP-P-ABORT PI No Provider-initiated aOOrt

P-ALTER-CONTEXT C No Context addition and deletion

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

P-TOKEN-GIVE NC Yes Give a token lo the peerP-TOKEN-PLEASE NC Yes Request a loken oom the peerP-CONTROL-GIVE NC Yes Give all the lokens lo the peerP-SYNC-MINOR oe Yes Insert a minor sync pointP-SYNC-MAJOR C Yes Insert a major sync pointP-RESYNCHRONIZE C YIN Go back lo a previous sync pointP-ACTIVITY-START NC Yes Start an activityP-ACTIVITY-END C Yes End of activityP-ACTIVITY DISCARD C Yes Abandon an activityP-ACTIVITY-INTERRUPT C Yes Suspend an activityP-ACTIVITY-RESUME NC Yes Restart a suspended activityP-U-EXCEPTION-REPORT NC Yes Report of an user exceptionP-P-EXCEPTION-REPORT PI Yes Report of a provider exception

Chapter 5: The recommended presentation protocol machine. 40

Each of the given presentation service primitives has its own parameters.For example: The P-CONNEcr.request and P-CONNEcr.indication service primitives contain thecalling-presentation-address, called-presentation-address parameters and the user-data parameterwhich contains the accepted data from the application layer.

A full description of these presentation services primitives and their corresponding parameters isfound in [X.216].

All the offering services of the presentation layer are provided with help of the service primitivesof the lower layers. Thus the presentation layer invokes the session layer services through SessionService Access Points (SSAP's) to establish its own services. This means that all presentationservice primitives and PPDU's have to he mapped on the session service primitives. In Table 5.2these session service primitives are given.

A full description of these session services primitives and their corresponding parameters is foundin [X.215].

Table 5.2: The Session Service Primitives.

Session service primitive Type of PurposeService

S-CONNECT C Connection establishment

S-RELEASE C Connection releaseS-U-ABORT NC User-initiated releaseS-P-ABORT PI Provider-initiated ahort

S-DATA NC Normal data transferS-EXPEDITED-DATA NC Expedited data transferS-TYPED-DATA NC Out-of-band data transferS-CAPABILITY-DATA C Control information data transfer

S-lUKEN-GIVE NC Give a loken to the peerS-lUKEN-PLEASE NC Request a loken oom the peerS-CONTROL-GIVE NC Give all lokens to the peerS-SYNC-MINOR oe Insert a minor sync pointS-SYNC-MAJOR C Insert a major sync pointS-RESYNCHRONIZE C Go back to a previous sync pointS-ACTIVITY-START NC Start an activityS-ACTIVITY-END C End an activityS-ACTIVITY-DISCARD C Abandon an activityS-ACTIVITY-INTERRUPI' C Suspend an activityS-ACTIVITY-RESUME NC Restart a suspended activityS-U-EXCEPTION-REPORT NC Report of an user exceptionS-P-EXCEPTION REPORT PI Report of a provider exception


The first category services, that require the exchange of PPDU's between the two presentationentities, can be distinguished in five facilities:

• Connection Establishment• Connection Release• Context Management• Infonnation Transfer• Resychronization

The presentation layer uses for these facilities 14 different types of PPDU's, which are shown inTable 5.3.

Table 5.3: The different PPDU types.

PPDUType Meaning

CP Connect PresentationCPA Connect Presentation AcceptCPR Connect Presentation Reject

ARU Abnormal release, User initiatedARP Abnormal release, Provider initiated

AC Alter ContextACA Alter Context Acknowledge

TD Transfer DataTE Transfer Expedited DataTTD Transfer Typed DataTC Transfer CapabilityTCC Transfer Capability ConfinnRS ResynchronizeRSA Resynchronize Acknowledge

Table 5.4: Mapping between presentation primitives, PPDU's and sessionprimitives.

Presentation primitive PPDU's Session primitive

P-CONNECT CP,CPA,CPR S-CONNECTP-U-ABORT ARU S-U-ABORTP-P-ABORT ARP S-U-ABORTP-ALTER-CONTEXT AC,ACA S-lYPED-DATAP-DATA TD S-DATAP-lYPED-DATA TTD S-lYPED-DATAP-EXPEDITED-DATA TE S-EXPEDITED-DATAP-CAPABILITY-DATA TC,TCC S-CAPABILITY-DATAP-RESYNCHRONIZE RS,RSA S-RESYNCHRONIZE


Table S.S: The mapping of the mirroring services.

Presenlation primitive Session primitive

P-RELEASE S-RELEASE

P-TOKEN-GIVE S-TOKEN-GIVE

P-TOKEN-PLEASE S-TOKEN-PLEASE

P-CONTROL-GIVE S-CONTROL-GIVE

P-SYNC-MINOR S-SYNC-MINOR

P-SYNC-MAJOR S-SYNC-MAJOR

P-RESYNCHRONIZE S-RESYNCHRONIZE

P-ACTIVITY-START S-ACTIVITY-START

P-ACTIVITY-RESUME S-ACTIVITY-RESUME

P-ACTIVITY-END S-ACTIVITY-END

P-ACTIVITY-INTERRUPT S-ACTIVITY-INTERRUPT

P-ACTIVITY-DISCARD S-ACTIVITY-DISCARD

P-U-EXCEPTION-REPORT S-U-EXCEPTION-REPORT

P-P-EXCEPTION-REPORT S-P-EXCEPTION-REPORT

The relationship between the presentation primitives. these PPDU's and session primitives is shownin Table 5.4. In the next section the relationship between these presentation service primitives andthe several PPDU's will be discussed.

The second category contains presentation services which are derived directly from those madeavailable by the session layer. Then the PPM does not define corresponding PPDU's in respect ofthese services. Instead, the protocol specifies a direct mapping between related presentation serviceprimitives and corresponding session service primitives. These services are called mirroringservices and their mapping is given in Table 5.5.

5.3 The presentation layer services

5.3.1 Connection establishment

This facility provides a service which is used 10 establish a connection between two communicating presentation entities, and as a consequence between the supported application entities. Theprocedure uses following PPDU's:

• CP PPDU


• CPA PPDU• CPRPPDU

An application layer cou1d request for a presentation connection establishment by sending a PCONNEcr.request service primitive to the PPM.. Then tbe PPM will initiate tbe establishment bysending a CP PPDU containing tbe user-data values in encoded forrn and tbe proposed parametersnecessary for tbe operation. The initiating presentation entity cou1d encode a certain user-data valuemore tban once 10 allow tbe transfer of the same user-data values using a number of differenttransfer syntaxes. When none of tbe abstract syntaxes of tbe received user-data values, eachencoded witb a certain transfer syntax, are supported by tbe responding PPM, tbe responding PPMwill send a CPR PPDU, within this PPDU tbe provider reason : "user-data-not-readable".Otberwise it will send a CPA PPDU. If the initiating PPM receives a CPR PPDU, refusing thepresentation connection, tben it shall issue a P-CONNEcr.confirrn service primitive witb a resu1tparameter "usecrejection",i.e. an rejection of the peer application process. In case of accepting aCPA PPDU a P-CONNEcr.confirrn service primitive witb a resu1t parameter value of "acceptance" shall be send 10 tbe application layer through a PSAP. A presentation connection is successfully established provided negotiation in respect of each of the following is successful :

• defined context set• defau1t context• presentation functional units• presentation protocol version

Presentation Context negotiation

When in future more transfer syntaxes are available, tbe two peer PPM's have to negotiate abouttbe defining Presentation Context : abstract syntax and transfer syntax, before any inforrnationtransfer can be perforrned. This negotiation is achieved as follows:

• An application process inforrns tbe PPM of one or many abstract syntax(es) tbat it wishes tobound into Presentation Context(s).

• The initiating PPM provides for each abstract syntax a list of transfer syntaxes it is capable ofsupporting for the establishing presentation connection.

• The session services shall be used to pass tbe complete list of abstract syntaxes and tbecorresponding sets of transfer syntaxes to its peer. This presentation context definition list shallbe mapped on tbe session service parameter "SS_user data".

• The peer PPM indicates to its application process tbose abstract syntaxes it cannot support usingone of tbe proposed transfer syntaxes, marked tbem as refused : "provider-rejection".

• The peer application entity will check tbe list of supported abstract syntaxes. Those abstractsyntaxes that cannot be supported shall be marked "user-rejection".

• The responding PPM selects one item of tbe transfer syntax list as tbe transfer syntax 10 be usedon the presentation connection for each accepted presentation context, i.e. each abstract syntaxwill be combined witb one transfer syntax when none is rejected. This resu1ts in a list ofpresentation contexts, which is retumed 10 tbe initiating PPM.

• The initiating PPM is now aware of tbe presentation contexts in force. It will inforrn tbeinitiating application entity tbat it can go ahead and use tbe inforrnation transfer servicesinvolving tbe requesting abstract syntaxes.


Each presentation context is identified by the presentation context identifier provided by theinitiated PPM. The result list of the negotiation phase is called the Defined Context Set or DCS forshort.

When at connection establishment no abstract syntax(es) are known, that will he used by theapplication layer in future, the peer PPM's will assume the availability of a mutually understoodDefault Presentation Context.

Default Context negotiation

The Default context will he identified with a Default Context Name. If the Default Context Nameis present in the P-CONNECf.request service primitive and the responding PPM does not supportthe named default context, it shall send a CPR PPDU with a provider reason parameter value of"default context not supported" and a default context result parameter of value "provider-rejection".If the responding PPM supports the named default context but receives a P-CONNECf.responseservice primitive oom the peer application entity with a default context result parameter of value"user-rejection", then it shall send a CPR PPDU with a default context result parameter of "userrejection". When no CPR PPDU is received, the initiating PPM assumes that the requested defaultcontents are acceptable.

Functional Units negotiation

As mentioned in section 5.2, the presentation layer services can he divided in two sets. The firstset contains presentation services that require the exchange of PPDU's hetween the two presentation entities. The set contains the following types of services :

• Connection establishment• Connection release• Context management• Information transfer

The selection of these services is arranged in the three functional units (FU's) that the presentationlayer contains. The first FU is the kemel, which is critical to the operation of the presentation layerand therefore always selected. It supports user-data transfer in accordance with the nes defined atconnection establishment The two other FU's are the context management (CM) FU and thecontext restoration (CR) FU, they are optional and their use is negotiabIe. The CM FU permits thepresentation user, the application layer, to add or delete presentation contexts to/OOm the nes atthe moment during a presentation connection. The CR FU can only he selected when the CM FUis selected too. With this FU selected, it is possible to restore an earlier defined contents in theoeS.

Protocol version negotiation

Duting connection establishment, the initiating PPM provides in a CP PPDU a list of versions thatis capable of supporting. The responding PPM will select one of the proposed versions within aCPA PPDU. In none is acceptable the responding PPM sends a CPR PPDU with a list of versionsthat is capable of supporting.


5.3.2 Connection Release

The connection release can be norrnal or abnorrnal. Norrnal release of the presentation connectiontakes place concurrently with the release of the underlying session connection. PPDU's are notexplicitly defined. but implicitly given by the description of Table 5.4.

Abnorrnal release is used at any time 10 force the release of a presentation-connection. It isinvoked by the P-U-ABORT service primitive or in response to a protocol error or a reception ofan invalid PPDU. Abnorrnal conneetion release uses following PPDU's:

• ARU PPDU• ARPPPDU

When a PPM receives a P-U-ABORT.request primitive and either a presentation-connection hasbeen established or a CP-PPDU has been send. and neither a CPR PPDU has been received. itshall send an ARU PPDU and the presentation-connection shall be released.

When it receives an unexpected session service primitive. an unrecognized or unexpected PPDU.an PPDU containing an invalid PPDU parameter value. an unrecognized or unexpected PPDUparameter. it shall issue an P-P-ABORT.indication service primitive and send an ARP PPDU. ifpossible. The presentation-connection shall be released.

When a PPM receives an ARU PPDU it shall issue a P-U-ABORT.indication service primitive andthe presentation-connection shall he released. When it received an ARP PPDU. it shall issue a P-PABORT.indication service primitive.

5.3.3 Context-Management

This facility is used to modify the Defmed Context Set and uses the following PPDU's :

• AC PPDU• ACA PPDU

With this service it's possible to negotiate about the definition of one or more new presentationcontext sets 10 be added to the DCS. Also is it possible be negotiated about one or more definedpresentation contexts of the DCS to he deleted. When a PPM receives a P-ALTER-CONTEXT.request service primitive. the PPM will generate an AC PPDU. The responding PPM will send anACA PPDU that carries a result parameter for each proposed item in the corresponding AC PPDU.A result parameter could contain one of the following values :

• "acceptance"• "user-rejection"• "provider-rejection"


5.3.4 Infonnation Transfer

While user-data, i.e. information accepted from the application layer, may be transferred as part ofalmost any presentation service primitive, this facility is specifically used to convey user-datavalues originating from the following presentation primitive services :

• P-DATA• P-TYPED-DATA• P-CAPABILITY-DATA• P-EXPEDITED-DATA

These service primitives are similar to the corresponding session service primitives. The difference,however, is that the user information is encoded using an applicable context from the oes, exceptfor P-EXPEDlTED-DATA. This facility uses the following PPDU's:

• TD PPDU• TTDPPDU• TE PPDU• TC PPDU• TCC PPDU

The relationship between the presentation service primitives and the used PPDU's is shown inTable 5.4. In this Table it is seen that P-CAPABILITY-DATA exchanges two different types ofPPDU's. The PPM will exchange a TC PPDU when it accepts a P-CAPABILITY.request and aTCC PPDU when it accepts a P-CAPABILITY.response.

The P-DATA service primitive offers the normal information user-data transfer service, giving arepresentation-independent information exchange capability between peer application processes.

The P·TYPED-DATA service primitive is a specialized service element offering the same serviceas the P-DATA service primitive, but only used by application processes to exchange informationagainst the current setting of the data tokens (see "Token management", section 5.3.6).

P-EXPEDITED-DATA is just like the first two a non confirmed service primitive. It guaranteesthat a P-EXPEDlTED-DATA primitive with corresponding parameters will arrive at the peer-entitybefore any subsequently issued primitive. The user-data of this primitive will always be encodedaccording the default context.

The last primitive, P-CAPABILITY, offers the only confirmed service. This service is onlyinvoked when control data is transferred between the peer-application entities. This service isbasically implemented by the session layers.

5.3.5. Resynchronization

The resynchronization procedure has influence on the DCS when the context restoration functionalunit has been selected. This procedure allows the user to restore a connection to a synchronizationpoint which is set in the past. If an accepted P-RESYNCHRONlZE presentation service primitive


will invoke a S-RESYNCHRONIZE session service primitive or will initiate the generation of aRS PPDU or RSA PPDU is dependent of the seleeted FU's of the presentation layer.

With the PPDU's a list of resulting presentation context is exchanged. With this list the applicationlayers are informed of the contents of the resulting OCS after completion of the resynchronizationprocess. The initiating presentation entity shall update its OCS when it received the RSA PPDU.The responding presentation entity shall update its DCS when it received the RS PPDU. Dependentof which functional units are selected, the procedure has a certain outeome. Because of the scopeof this thesis only an overview of this facility is given. More detail about the P-RESYNCHRONI·ZE service primitive is La. found in [Hurk92].

5.3.6 The other service primitives

Section 5.2 showed that not all the provided presentation service primitives are really concerningthe presentation layer. The service primitives which are not concemed are called mirroring serviceprimitives. These primitives provide four facilities :

Synchronization and Resynchronization

This facility consist of the following three confirmed service primitives:

• P-SYNC-MINOR• P-SYNC-MAJOR• P-RESYNCHRONlZE

The first two primitives are associated with the synchronization process that may be used during asession. When transmitting large quantities of data, it is advisable to divide the data into a numberof identifiabie units so that, should a fault develop during asession, only the recent data transferred are effected. To perfonn such a function, a number of synchronization points may be insertedinto sequential blocks of data before transmission. These points may only be inserted when theuser has got the specific minor or major token (see Token Management). A major synchronizationpoint is normally associated with complete units of data (dialogue units) being exchanged betweentwo users. The minor ones are normally associated with portions of a dialogue unit. For example,during sending a book to another computer a major synchronization point could be set after eachchapter and a minor synchronization point within a chapter after each sending page. When the p.RESYNCHRONlZE service primitive is used, all the tokens will be given back to the owner at themoment of the specified synchronization point

Token Management

This facility consist of the following three non confinned service primitives:

• P-TOKEN-GlVE• P-TOKEN-PLEASE• P-CONTROL-GlVE


With this service prlmitives the position of the following tokens is defmed:

• data tokenIt controls the communication in a half-duplex environment

• release tokenThe application entity which owns this lOken may initiate an orderly release of the sessionconnection.

• minor tokenThe application entity which owns this lOken may initiate minor synchronization orresynchronization services.

• major/activity lOkenThe application entity which owns this lOken may initiate major synchronization or activities.

A token becomes available whenever the corresponding service is negotiated. During the connection establishment phase an available lOken may be assigned by the initiating user to itself or to theother user. Also, it may let the responding user 10 make the assignment. With P-TOKEN-GIVE orP-TOKEN-PLEASE a token may be reassigned by an user. All available tokens may be reassignedsimultaneously using the service S-CONTROL-GIVE.

Activity Management

This facility contains the following service prlmitives :

• P-ACTIVITY-START• P-ACfIVITY-END• P-ACfIVITY-DISCARD• P-ACfIVITY-INTERRUPT• P-ACfIVITY-RESUME

The concept of activity is used to distinguish different logical pieces of work associated with asession. Although a complete session may comprlse a number of activities, only one activity maybe in progress at a time. In this way, an activity can be interrupted and then resumed either on thesame session connection or on a different one. Each activity is therefore made up of a number ofdialogue units. For example, each dialogue unit could be the transmitting of a chapter of a hookand an activity could be the transmitting of the whole hook. Ourlng the session connection severalhooks could be send.

Exception Reporting

This facility contains the following presentation service prlmitives :

• P-U-EXCEPTION-REPORT• P-P-EXCEPTION-REPORT

This facility is used by the users of the session layer 10 exchange occurring errors messages to itspeer entity.


5.4 Summary

The application layers could invoke several presentation service primitives. Some of them areconfirmed, others are not. These offered services fall into two categories. One category of servicesthat require the exchange of PPDU's hetween the two presentation entities. The other categorycontains services that only invoke session services without any PPDU generated. For the firstcategory, the PPM has to establish a peer-to-peer connection 10 provide these services. For anestablishment a negotiation in respect with the defmed context set, the default context, presentationfunctional units and the presentation protocol version has 10 he successful. For providing thesecond category of services the session layer has to establish a peer-to-peer connection. In bothcases the invoked presentation service primitives or generated PPDU's are mapped on the sessionservice primitives.


Chapter 6

The chosen strategy for system development

6.1 Introduction

Although the specifications of the presentation layer are published in the CCIlT recommendations[X.2l6] and [X.226], the designing of the presentation layer is a very complex task. For understanding these recommendations also knowledge conceming the OSI Reference Model, ASN.l andBER is necessary. Besides the amount of these specifications, they are also sometimes described ina vague way. Therefore it is useful to describe the presentation layer in a standard and formalmanner with a structured modelling technique. Such a technique will help the designer to finddiscrepancies and incompleteness in his/her thinking.

The components that make up the presentation layer, both hardware and software components, arehighly interrelated, and in order to successfully fulfl1 their intended functions, they must integrateweIl. The system specification process, therefore, must define the system as a whoie, as weIl as itspartitioning into hardware and software components. It must define what problem the system is tosolve (it's requirements) and how that system is to be structured (it's architecture or designstructure). The last step in the designing traject is the actual implementation of the design structure,the hardware construction and software coding.

The modelling technique we choose for analyzing, designing and implementing the presentationlayer is described by D.J. Haltley and LA. Pirbhai in the book "Strategies for Real-Time SystemSpecification", see [Hatl87]. This method is an extension of the method described by E. Yourdonand consists of two parts, a requirements model and an architecture model. The tooI we used todevelop the presentation layer according to the Hatley and Pirbhai modeIling technique is theCASE-tooI (Computer Aided Software Engineering) ProMod because it supports the technique forthe most part. This tooI will also be described in this chapter.

51

6.2 The requirements model

The first step in designing a system is defining it's requirements. This means that we first establishwhat the desired endproduct is, before describing how to produce it. So, describing the requirements of the presentation layer will be independent of the final implementation.

The requirements model is based on the use of flow diagrams. A flow diagram is a graphicalmodel of signal flows (both data flows and control flows) and processes acting on those flows. Fordefining the complete requirements of the presentation layer (or any other system) we use thefollowing items :

• Context Diagrams• Data Context Diagram (DCD)• Control Context Diagram (CCD)

• Flow Diagrams• Data Flow Diagram (DFD)• Control Flow Diagram (CFD)

• Specifications• Process Specification (PSPEC)• Control Specifications (CSPEC)

• Stores• Data stores• Control stores

• Timing Specification• Requirements dictionary

The overall strueture of the requirements model in shown in Figure 6.1.

Data COntext COntrol COntextDIagram Diagram

TimingÎ • I~ ~Jr • SpecIfIcatlon

~ JrData Flow Contral FlowDiagram8

~ ~Diagrams

! ~Prooess COntraiSpecifieations Specifieations

•I Requirements Dictionary I

Figure 6.1 : Components of the requirements model.

Chapter 6: The chosen strategy for system development. 52

Each design using the Hatley and Pirbhai modelling technique will start with two context diagrams : a data- and control context diagram. Context diagrams are special cases of data and contmlflow diagrams. They selVe a special and important mIe in the model. They identify the extemalentities (typically, other systems, operators, and so on) with which we require the system tocommunicate, and state the major purpose of the system in the form of a single system process.Context diagrams are of major importance because they summarize the centra! requirement 10accept certain inputs, perform some actions on these inputs according 10 the stated system purpose,and 10 generate certain outputs. The extemal entities are represented by terminators. These arevisible as squares. An example of a DeD and a CCD is given in Figure 6.2.

~,---~

, \

, '\,~)"8/

CCD

I-,oa'''f",1 -',terminator

2

terminato1

Deo

Figure 6.2 : An illustration of a context diagram.

Flow diagrams consist of data flow diagrams (DFD) and contro) flow diagrams (CFD). In aDFD the processes together with the data flows (solid arrows) are shown, while in a CFD theprocesses with the control flows (dashed arrows) are depicted. A DFD contains processes, dataflows, and data stores, but not terminators. A control flow diagram consists of the same processesas defmed in the corresponding DFD, control flows, contml stores and maybe one or more contmlbars (see Contml Specification). The pmcesses and data/contml flows are similar 10 those on thedata context diagram. An example of a DFD and a CFD is shown in Figure 6.3.The designer decomposes the system and its functions into a hierarchical structure of processes bydecomposing the DFD and CFD. In this manner the requirements of the system are described.The difference between data and contml flows is difficult to describe and depends on theinterpretation of the designer.

Using the Hatley and Pirbhai modelling technique the designer has to specify the processes andcontrol bars which are used in the DFD's and CFD's. The Process specitications (PSPEC) specifyin concise terms each detail of the system 's functional requirements. Control flows generated insidePSPEC's through tests on data flows are called "data conditions". They flow on CFD's, not DFD's,where they are treated as any other contml tlows.

The Contro) specitications represent the fmite state machine behaviour of the system. Theirpurpose is exaet1y the same as that of PSPEC's: precisely to show how their outputs are generatedfmm their inputs. Contml flows can flow between processes for contmlling each others process,and oom or 10 a bar. This bar indicates the interface between the CFD and the contml specification (CSPEC) that corresponds to this level.


Figure 6.3 : An example of a DFD and a CFD.

In a CFD, only one CSPEC may appear. All bars in a certain CFD refer to the same CSPEC.The CSPECs are optionally; they need not to be inserted when no process activators are required.

The last component in a DFD or CFD is the dataIcontrol store. Data stores represent data storedfor later use by a process, and are indicated by pairs of parallel lines with names between them. Acontrol store is used for storing control information.

The time specification defines the limits on response time allowed between events at the systeminput terminals and the resulting events at the system output terminals. Thus the timing specifications are only needed for communication with the outer-world of the presentation layer.

The requirements dictionary completes the requirements model. It contains an alphabetical listingof all the data and control flows on the DFD's and CFD's along with their definitioDS.

The requirements model is built as a layered set of DFD's and CFD's with associated PSPEC'sand CSPEC's. Each successive level of diagrams and specifications expresses a refmement of thehigher-level diagrams. The model is highly idealized; the processes are assumed to be datatriggered and infinitely fast. Whenever enough data is available at the input of a process to performits task, it will perform that particular task immediately. However, some processes are not triggeredby data, but by control. This means that a control flow will trigger the process or it will beactivated by a control bar.


6.3 The system architecture model

After completed the requirements model we captured the system requirements, i.e. which functionsthe system should perforrn, but no attention is paid for the question how the system will fulfilthose requirements. This means that the system is not completely specified.The means for capturing this system mechanization is the architecture model, whose principalpurposes are :

• 10 show the physical entities that make up the system.

• to defme the inforrnation flow between these physical entities.

• to specify the channels on which this inforrnation flows.

The following tasks are distinguished when constructing an architeeture model :

• The architeeture context diagram (ACD) establishes the inforrnation boundary between the systembeing implemented and the environment in which the system has to operate. !t's the highest leveldiagram for any system.

• The architecture flow diagram (AFD) shows the physical configuration of the system in terrns ofits architeeture modules and all the infonnation flow (data and control).

• The architecture interconnect diagram (AID) shows the physical interconneet of the systemcomponents, in terrns of the channels by which inforrnation flow between the architecturemodules.

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

• The architecture interconnect specification (AIS) captures the characteristics of the channels bywhich inforrnation flows between the modules.

• The architecture dictionary (AD) is an enhancement of the requirements dictionary. It capturesthe allocation of all the data and control flows to architecture modules and the channels on whichthey flow.

The relations between these components are shown in figure 6.4.


ArchIt8ctuI8 ContIlDdDl8g1'llm

iJ,. J,.

ArchIt8cture Flow An:hl1lilcture Intercom.Diagrema ~

~Dilgrema

~

1 1Archltecture Module Archit8cture intercoM.

SpecIfication SpecIlIcatIon

...... r

I An:hl1lilcture DIctIonary IFigure 6.4 : The architecture model components.

Similar with the requirements model, the system architecture model mostly consists of more thanone layer. The architecture model consists of a layered set of AFD's and AID's and theirassociated AMS's and AIS's. Each successive layer refines the configuration defmed by the higherlevel diagrams.

In developing the architecture model, we allocate the requirements model to architecture modulesand add the following :

• input processing

• output processing

• user interface processing

• maintenance, self-test, and redundancy processing

The template of an architecture module is given as figure 6.5.

The input and output processing blocks represent the additional processing, beyond that of therequirements model, needed for each architecture module to communicate with the other modulesand to transform the information to and from an intemally usabIe form.

The user interface is a special case of the input and output processing blocks. It needs to be separated from the input and output processing blocks. because there are many special considerations,such as human factors, that effect the definition of the user interface. These considerations do notapply to the definition of the interfaces between two architecture modules or between the systemunder development and other entities (systems) in the environment.


User Interface Processing

IInput Process Model I

OutputProcessing Processing

I Contral model Irequlrementa .....

Maintenance. salf-Test. andRedundancy Management

Processing

Figure 6.5 : The template of an architecture module.

The maintenance and self·test block represents all modules required to perform the self-monitoring, redundancy management, and data collection for maintenance purpose.

As said, the architecture model is a hierarchica1layering of modules that are defined by successiveapplication of the architecture template to each of the blocks in the model, as illustrated in Figure6.6.

~I""""t.. flDdelProcess rngl-----------------I Process 1ng

User Interface ProcessIng

Output

Process Model

Control Model

Malntenance J Self-test J

Redundancy ManagementProcessIng

Input

User Inter~e.ce ProcessIng

IProcess Mode I IInput ICOntrol Model I Output

ProcessIng ......--._1 ProcessIng

"1~r'lIICe_ "I~-

~..... -...-ncy "n-.~"'t Flr""oe_rng

Us.... Inter~e.ce Processing

IProcess Mode I IInput ICOntral Model I OUtput

Processing.......--._.

Processing

"1nt.e...r'lIICe. "I~-

~.............-ncy .....

ao--nt. A"'aee.elng

Figure 6.6 : Architecture model layering.


6.4 The CASE-tooI ProMod

1 2

:t='I =

1 - collected knowledge2 - requlrements analysls3 - suggestecI solutions

4 - analysis and system architeeture5 - a1gorlthms6 - program analysis

Figure 6.7 : The ProMod project model.

As said in the introduction, we choose the modelling technique described by Hatley and Pirbhai[Hatl87] for analyzing, designing and implementing the presentation layer. The ProMod CASE-tooIis chosen because it supports the chosen method for the most part. In Figure 6.7 is seen that theProMod project is divided in three logica! steps during obtaining the specifications of the system :

• Requirements analysis & definition• System design• Program design

In Figure 6.7 is a1so seen that the system analyst and the designer together completes the desiredprogram specification.

For creating a requirements model of the presentation layer only the first distinguished ProModstep is important. This phase has as aim to create a structured model of the presentation layerwhich contains all technica! requirements expressed in a consistent way. This phase formallybegins with the user's ideas. In our case, the designing of a hardware architecture for thepresentation layer, the foundation is layed by the CCITI recommendations X.216 and X.226.Using this tooI to create and manipulate flow diagrams and to create entries in a data dictionary, avisualization of the presentation layer is made. In this phase ProMod is used as :

• a pattem of thought• a "language" for expressing requirements• a procedura! scheme


For creating an architecture model for the presentation layer the second phase "System Design" ofProMod is used. The purpose of this phase is to develop a solution to the problem described in thedata flow diagrams. The solution is expressed in a system architecture that optimizes characteristicsof:

• independencies between modules; that is, a minimum number of interfaces• a high degree of cohesion within individual modules• portability• visibility of strueture and ease of alterations

The strueture of a System Design made with ProMod consists of :

• modules• functions• subsystems• data types

For more information about the CASE-tooI ProMod is referred to [PROM89].

The last step of ProMod in designing a system will not be explained because it's not in the scopeof this thesis.

6.5 Discrepancies between the Hatley and Pirbhai modelling technique and theCASE-tooI ProMod

As said in the introduction, the CASE-tooI ProMod supports the Hatley and Pirbhai modellingtechnique for the most part. This means not complete. The fiTSt item of the Hatley and Pirbhaimodelling technique (see section 6.2) which isn't supported by ProMod is the Timing Specification. Also the modelling technique uses an architecture template which doesn 't exist in ProMod asseen in the above section. This tooI distinguishes the developed system in modules and functions.Another difference is that ProMod requires for every flow diagram a PSPEC instead of only forthe most decomposed flow diagrams.A restriction of ProMod is that bidirectional flows can't be merged or splitted and they are notsupported trom a CSPEC bar to a parent-diagram. Also these flows were sometimes oot recognizedwhen they flow to a textual CSPEC bar or to a store. When a data- or control flow overlap,ProMod may not recognize one of them as existing during analysis

6.6 An evaluation of the Hatley and Pirbhai modelling technique and theCASE-tooI ProMod

Using the Hatley and Pirbhai modelling technique makes it possible to design a complex system indistinguishable phases. These phases reduce the complexity of the designing system. Per phase thecomplexity will also be reduced by defining different functions, modules, stores etc..The Hatley and Pirbhai modelling technique increases through above mechanism the surveyabilityof the whole design.


As said in above section, ProMod is not entirely compatible with the used modelling technique.An advantage of ProMod is that it can easily manipu1ate the defined functions, modu1es, specifications and data. Creating data and control flow diagrams, data and control specifications, datadictionaries, modu1es and functions is also easily to do. ProMod checks the defmed flows andprocesses on consistency and completeness wbich is a great help. Also a wide variety of reportscan be generated by ProMod. This possibility makes ProMod suitable for designing a complexsystem with more than one designer.

A drawback of ProMod is the disability for a designer 10 switch between different windows. Now,with version PI.7a the designer bas to save bis current window when he wants for example verifya certain data declaration. Because of this disability the surveyability of the project is easily lostAnother drawback is that the designer has 10 manage bis own database manually with the ProModutilities 10 prevent an enormous database. Also data declarations not used anymore has to beremoved manually. These ProMod utilities require a large amount of extemal memory and can notbe interrupted, after executing, without damaging the original project database. This also appliedfor the several analyzing functions of ProMod. Also a disadvantage of ProMod is that the values ofthe declared variables are not checked during analyzing. For example, when a control flow called"INIT" cou1d have two values "ok" or "false", these values are not checked in the designedPSPEC's and CSPEC's.

6.7 Summary

Using a modelling technique during the designing phase of a complex system, like the presentationlayer, is a great help for the designer to find discrepancies and incompleteness in bis/her thinking.Furthermore designing the presentation layer in this way makes it possible to work with a coupleof engineers on one project There are several common known modelling techniques.

The modelling technique described in the book "strategies for Real-Time System Specification byD.J. Hatley and LA. Pirbhai is used for the specification of the requirements of the presentationlayer. This corresponds with the first part of the technique : the requirements model. Theimplementation dependent part of the technique is the architecture model. The CASE-tooI which isused with the Hatley and Pirbhai technique is ProMod. Not the whole technique is supported byProMod but with this CASE-tooI it's possible to acquire a requirements model wbich is suitablefor further development.


Chapter 7

A functional decomposition of thepresentation layer

7.1 Introduction

The previous chapter discussed the Hatley and Pirbhai modelling technique and the CASE-tooIProMod that are used during the design-phase of the presentation layer. They helped to finddiscrepancies and incompleteness in the presentation layer design. In the next sections the firstlevels of the requirements model of the presentation layer, which is based on the CcnT recommendations [X.216] and [X.226], will be discussed. Next, some considerations concerning animplementation of the presentation layer will be made.

7.2 The context of the presentation layer

The first step in designing a system is defining it's requirements. This means that we first establishwhat the desired system should do, before describing how to produce it.As mentioned in chapter 6, each design using the Hatley and Pirbhai modelling technique will startwith a data and control context diagram which will serve a special role in the requirements model.They identify the extemal entities, in this case the application and session layer, that will communicate with the presentation layer. With these context diagrams is stated also the major purposein the form of a single system process. However, designing a context diagram for the presentationlayer can be done in different ways. A first possible combined context diagram (data and controlflows together) is given in Figure 7.1.

This context diagram expresses the services the presentation layer is offering to the applicationlayers. In the OSI model is described that the presentation layer invokes the session serviceprimitives to provide its own services. This mechanism is not included in this context diagram. Thesession layers are only used as a transport medium that is implemented in the given presentationfunction. Thus, Figure 7.1 does not illustrate the presentation layer context in the way described insection 2.3.2. Therefore, Figure 7.1 is not a very good starting point for a hardware implementationof the presentation layer.

61

Computer A

ApplicatienLayer

Figure 7.1: A first possible context diagram of thepresentation layer.

Computer B

P-SDU

Another possible presentation layer context diagram is given in Figure 7.2.

P-SDU

S-SDU

ApplicationLayer

SessionLayer

P-SDU

S-SDU

Figure 7.2: A second possible context diagram of the presentationlayer.

Modelling the context diagram in the way of Figure 7.2 expresses the communication of thepresentation layer with its adjacent layers : the application layer and the session layer. This contextdiagram approximate the reality very c1osely.

Chapter 7: A functional decomposition of the presentation layer. 62

The CCITf recommendations X.216 and X.226 descrilJe the presentation layer also in the way ofFigure 7.2. The PPDU exchange is established by a virtual path between the two presentationentities, i.e. they are mapped on the session service primitive parameters.This model is a good starting point for designing the presentation layer in hardware.

In both Figures, the control flows are indicated with P-ICI or S-ICI: the Presentation and SessionInterface Control Infonnation. The data flows are called P-SDU or S-SDU : Presentation orSession Service Data Units. The OSI tenns SDU and ICI were introduced in section 2.3.1.

P-ICI carries presentation service primitives and the control flow S-ICI session service primitives.These last kind of service primitives are specified in a context diagram because all the presentationservices will be mapped on them. Both kind of service primitives and their mapping were specifiedin chapter 5. The values of the P-ICI and S-ICI control flows are given below. The completedescription of these control flows could be found in appendix A of this thesis.

P-ICI = [ P-CONNEcrlP-RELEASEI P-U-ABORTI P-P-ABORTI P-ALTER-CONTEXTI the rest of the given presentation service primitives,

see Table 5.1 ]

with for example :

P-CONNEcr = [ "request" I "indication" I "response" I "confinn" ]

S-ICI = [ S-CONNEcrIS-RELEASEI S-U-ABORTI S-P-ABORTI the rest of the given session service primitives,

see Table 5.2 ]

with for example :

S-U-ABORT = ["request" I "indication"]

In the above given example is seen that the P-CONNEcr service primitive is confinned and the SU-ABORT service primitive is not. These two primitives are chosen out of the list of possibleservice primitives 10 illustrate a confinned and a non-confinned service primitive.


When the presentation layer accepts control infonnation via P~ICI or S-ICI, it will also mostlyaccept the correspondent parameters P-SDU or S-SDU with it. 80, when the presentation layer willaccept a P-CONNEcr.request service primitive, it will also accept the P-CONNECf.parameters.These parameters are necessary for a proper operation of the presentation layer and the other OSIlayers. The values of the data flows P-SDU and S-SDU are given below. The complete descriptionof these data flows could be found in appendix A of this thesis.

P-SDU = [ P-CONNEcr-parametersI P-RELEASE-parametersI P-U-ABORT-parametersI P-P-ABORT-parametersI ... ]

with for example :

P-CONNEcr-parameters =++++

( "calling-pres-adr" )( "called-pres-adr" )( "respondinures_adr" )(" pres_contexcdeClïst" )

S-SDU = [ S-CONNEcr-parametersI S-RELEASE-parametersI S-U-ABORT-parametersI S-P-ABORT-parametersI ... ]

with for example :

S-U-ABORT-parameters =

The several presentation and session service primitives and their parameters will not be furtherdiscussed in this thesis because their meaning is not necessary for understanding the rest of thischapter. A complete description of the P-ICI, S-ICI, P-SDU, S-SDU and the other data and controlflows that were used to describe the presentation layer, inclusive the several levels of thefunctional decomposition are given in appendix A.


7.3 The first functional decomposition of the presentation layer

In the previous section two possible context diagrams of the presentation layer were given. Asmentioned, the chosen way of defming the context diagram of the presentation layer is like Figure7.2. The data flow diagram of the first level of the presentation layer is given in Figure 7.3.

ppdu_or_

••••. an_pIr

updau_.Icro_progr Iin

a

Figure 7.3: The data flow diagram of the presentation layer.

Figure 7.3 shows that the presentation layer could be decomposed in six different functions :

• PSDU_BUFFER• SSDU_BUFFER• DIRECfION_ARBITER·PPM• FILTER.DCS• ENCODER_DECODER

Only the data flows between these six functions are ShOWD. The displayed data flows "p-sdu-e" and"p-sdu" carry the presentation service primitive parameters (the "_e" indicates that the data flow isan external flow, i.e. it interfaces with an adjacent layer).

The "s-sdu-e" and "s-sdu" data flows carry the session service primitive parameters. The abovedescribed four data flows correspond with the flows that were discussed in section 7.2. The serviceprimitives "~ici~'" "p-ici", "s-ici-e" and "s-ici" are not ShOWD in this figure because they arecontrol flows and thus will be displayed in the control flow diagram of the presentation layer.


As could be seen in Figure 7.3, another data flow is coming from the outer-world : "update_micro...,programs". This flow carries new micro-programs for the encoding and decoding process andnew supported abstract syntaxes and transfer syntaxes. The function "encodecdecoder" will besignalled with the control flow "update" that new micro-programs are available. Both flows werenot given in the discussed context diagrams of section 7.2 for simplicity reasons.Before the interaction between the above functions will be explained, they will be described below.

The SDU ButTers functions

As shown, the presentation layer interfaces with its adjacent layers through the functions "psdu_buffer" and "ssdu_buffer". The "psdu_buffer" accepts the presentation service primitives and theircorresponding parameters from the application layer or the "ppm". The "ssdu_buffer" is able toaccept session service primitives and their corresponding parameters from the session layer or the"encodecdecoder". Both buffers store the accepted data when the receiving side is not ready.The main functions for both buffers are:

• recognition of the accepting service primitives if they are acceptable or not• recognition of the accepting service primitive parameters if they are acceptable or not• buffering the acceptable service primitives and their parameters

When an error occurs during recognition, this will be signalled to the "ppm" by the error_controllerthat is contained in both buffers. When an error occurs in the "psdu-buffer", a P-P-ABORT.requestpresentation service primitive will be generated and transmitted to the "ppm" via the control flow"p_ici" (not seen in Figure 7.3). When an error occurs in the other buffer: "ssdu-buffer", a S-UABORT.indication session service primitive will be generated by the erroccontroller and send tothe "encodecdecoder" via the control flow "s_ici" (not seen in Figure 7.3). The error_controllercontained in the buffer that recognizes the error, will convert the original error message into arecommended one. These original error messages could be important for maintenance of thepresentation layer design in future. Such a recommended error-message will be transmitted via thedata flow "erroctype" to the "ppm". A full decomposition of both buffers could be found in theProMod Report in appendix A.

The direction arbiter function

Before an adjacent layer may use the resources of the presentation layer, the buffer which storedthe accepted data has to request for the presentation layer usage to the function "direction_arbiter".This arbiter contains a semaphore function, i.e. or the application layer may use the services of thepresentation layer or the session layer may. It also contains a counter which indicates the nwnberof jobs (a service primitive with its parameters) a certain adjacent OSI layer has transmitted andare in progress in the presentation layer. While this counter is not zero, it would be unpossible forthe other adjacent layer to posses the resources of the presentation layer. This "direction_arbiter" isnecessary because the requirements model of the presentation layer is designed for uni-directionaluse. This is according to the description in the CCIrr recommendations. In future it may bepossible that the implementation of the presentation layer contains more than one "ppm" and"encoder/decoder".


The PPM function

The presentation protocol machine (ppm) provides a peer-to-peer connection between tbe twopresentation entities. Therefore it controls tbe provision of tbe presentation layer services and theprotocols tbat define each service. It will generate PPDU's or session service primitives witb tbeircorresponding parameters de~ndent of tbe accepted presentation service primitives. Tbe behaviourof tbe "ppm" was earlier discussed in chapter 5. The "ppm" is described in the CCITI recommendation [X.226] witb several state tables, event lists, actions and predicates. A requirements modelof tbe "ppm" is already designed by [Hurlc92].

The Filter.des function

The "filter.dcs" function manages tbe several stores that contain various sets of contexts. Thesecontexts are defined during tbe peer-to-peer COIUlection between tbe two presentation entities.Besides tbe "defined_cs" store which contains tbe current applying defmed context sets, it willmanage tbe store "manage_dcs". This store holds tbe history of used context sets at certainsynchronization points and for several activities. Tbe "ppm" instructs tbe filter what to do. Tbeseinstructions could place a ncw content in tbe store "defined_cs". Tbe fIlter also have to instruct tbe"encoder_decoder" to check whetber tbe user_data parameter values, tbe data accepted by tbeapplication layer, belong to one of tbe context sets contained in tbe store "defined_cs".

The Encoder decoder function

This function performs tbe encoding and decoding of all tbe data tbat has to be mapped on thesession parameter "ss_user_data". In Figure 7.4 is shown which data shall be encoded/decoded bythis function : Presentation PDU's (PPDU's) tbat consist of a presentation SDU (PSDU) and apresentation PCI (PICl).

PDU

Figure 7.4: The encoding of data by the presentation layer.

Chapter 7: A funetional decomposition of the presentation layer. 67

The PSDU is created in the application layer out of application data and control infonnation of theapplication layer. The presentation layer will handle the PSDU as one block of infonnation called"user-data". Secondly the generated presentation PCI (PPCI) (by the "ppm") has to be encoded/decoded. As said in chapter 2, the PPCI will be exchanged between the two presentation layers toperfonn presentation services. The PICI shall not be encoded/decoded. Such infonnation is addedto the PDU as (a) temporary parameter(s) passed between the application layer and the presentationlayer and will be mapped by the "encodecdecoder" function on aspecific session ICI (SIC!). Alsogenerated PPDU types will be mapped on session service primitives by the "encodecdecoder" (seealso Table 5.4). An example of such a mapping is given in Table 7.1.

Table 7.1: Mapping of CP PPDU associated parameters ontoS-CONNECT parameters.

CP PPDU associated parameter S-CONNECf parameter

Mode selector SS-user-data

Protocol version SS-user-data

Calling-presentation-selector SS-user-data

Calling-session address Called SSAP address

Called-presentation-selector SS-user-data

Called-session-address Called SSAP address

Presentation context definition list SS-user-data

Default context name SS-user-data

Quality of services Quality of service

Presentation requirements SS-user-data

User session requirements SS-user-data

Revised session requirements Session requirements

Initial synchronisation point serrial Initial synchronisation point serrialnumber number

Initial assignment of tokens Initial assignment of tokens

Session connection identifier Session connection identifier

User-data SS-user-data

As could be seen, the CP PPDU would be mapped on the S-CONNNEcr service primitive and itsassociated parameters on several S-CONNEcr session parameters.

The "encodecdecoder" function will also check whether the "user_data" (if exist) belongs to acontext set contained in the store "defined3s". Last but not least the "encodecdecoder" has toprovide an up-to-data "supp_cs" store which contains all supported abstract syntaxes and transfersyntaxes. The function "encoder_decoder" will be discussed in the next section in more detail.


The interaction between the explained functions is as follows :

Before the presentation layer could operate, the store "suPP3s" has to be filled with the supportedabstract syntaxes and transfer syntaxes by the "encodecdecoder". When, after completing this task,a presentation service primitive is accepted with its correspondent parameters by the "psdu_buffer",the "psdu_buffer" will send a request for permission to the "direction_arbiter". When no jobs fromthe session layer are in progress in the presentation layer, the "direction_arbiter" will answer therequest positive. The "psdu-buffer" can now send the accepted primitive and its parameters to the"ppm", otherwise they will be buffered. When the "ppm" accepts this presentation service primitivefrom the "psdu-buffer", it will mapp it on a PPOU or a session service primitive depending on theaccepted primitive. The associated parameters will be mapped on the correspondent PPDU or session service primitive parameters. Next the "encodecdecoder" will encode all parameters that bas tobe mapped on the session parameter "ss-usecdata". When the encoding process is ready, theencoded parameters will be send by the "encoder_decoder" together with the uncoded parametersto the "ssdu-buffer". This transmitted data correspond with the format the session layer requires.The mapping to this session format is also performed by the "encodecdecoder".

When the presentation layer accepts data fiom the session layer the above procedure will be folIowed in the reversed way.

It bas to remarked that the defined data units SOU and ICI by the OSI model do not 100%correspond with the used SOU and la flows in the designed requirements model. In the requirements model an ICI control flow carries a service primitive and a data flow SOU its correspondingparameters. Not all the parameters in our SOU data flow have to encoded. This is in contrast withthe OSI model (see Figure 7.4). The same contrast is found between the recommendation [X.226]and the OSI model. In this recommendation also not all PPOU parameters should be encoded. Therequirements model is not changed according to the OSI model because the presentation layer wasalready specified in this way and such an changing would not improve the specification of thepresentation layer.

A full description of the requirements model, inclusive the defmed data!control flows/stores can befoood in appendix A of this thesis.


7.4 The encoder_decoder functional decomposed

ppdu.or.sesslon.par

deflDlt_cs

def Ined." ."coder_decoder-----

ppdu.or.IIBI' on.per

Figure 7.5: The data flow diagram of the encoder-decoder.

Figure 7.5 shows the functional decomposition of the function "encoder_decoder". As seen, sixdifferent functions cao the distinguished :

• PREPARE-PPDU-PARAMETERS• PREPARE-SS-USER-DATA·CHANGE-ENCODE~DECODER

• ENCODER-DECODER·ERROR-CONTROLLER• PARSER• ENCODER-DECODER-PROCESSING

Only the data flows are given in Figure 7.5. The control flow diagram of the "encoder_decoder"could he found in appendix A. These functions will he descrihed in the following sections. Alsothe interaction hetween the functions will he explained.

7.4.1 The Prepare functions

The "prepare...,ppdu...,parameters" function gets the PPDU's and session service primitives with theircorresponding parameters from the "ppm". It will select the parameters which have to he enco<ledby the function "encoder_decoder_processing". This last function provides the encoding/decoding


of all parameters that have 10 be mapped on the session service parameter "ss-user-data". Theseparameters correspond with a transmitted PPDU or a session service primitive by the "ppm". Otheraccepted parameters (that not have 10 be encoded) by this function will be mapped 1 : 1 on correspondent session service primitive parameters and will be used as control information for thesession layer.

In chapter 5 the mapping of the several PPDU types on their corresponding session service primitive was given in Table 5.4. The accepting parameters that not have to be encoded will be stored inthe "prepare_ppdu...,parameters" function until the other parameters arrived again, but now encodedby the function "encodecdecoder_processing".

When instead of a PPDU a session service primitive, generated by the "ppm", arrived at the"encodecdecoder" with its corresponding parameters, only the "user-data" (if exist) will beencoded. After encoding it will also be mapped on the session service primitive parameter "ss-userdata".

The function "encoder_decoder...,processing" function encodes all parameters that will be mappedon the session parameter "ss-user data". All these parameters will be encoded according 10 theBasic Encoding Rules for ASN.l, except the "user-data" parameter. This "user-data" shall beencoded according to the type "simple encoding" or "full encoding". Because of these variants ofencoding, the "prepare_ppdu_parameters" function has to instruct the function "change_encodecdecoder" which encoding and decoding routines have to be used. This instruction contains theppdu type and the context identifier for each transmitted "user-data" value. Also the "prepare_ppdu_parameters" function will determine the kind of encoding which has 10 be used for the"user-data". Therefore it checks whether the "user-data" belongs to one of the context setscontaining in the defmed or default context set.

Whether the PPDU parameter will be encoded according 10 the "simple encoding" or the "fullencoding" mechanism is dependent of the used presentation context, the selected functional unitsand the mode the presentation layer operates in.

When the presentation layer operates in the "normal" mode and the default context is used, the"user-data" parameter will be simple-encoded. This parameter will also be encoded in this waywhen the DCS contains only one member and the context management functional unit is notselected. This implies that the simple encoding cannot be used for the "user-data" parameter of theCP-PPDU when the DCS is used.

The "user-data" parameter shall be of the type "fully-encoded-data" when the presentation layeroperates in the "normal" mode and the default context is not in use and :

• the DCS contains more than one member or• the context management functional unit has been selected

When the default context is not in use, a CP PPDU or CPC PPDU shall be encoded according tothe full encoding mechanism.

When the data values of all selected parameters are parsed and encoded, they will be merged in the"prepare_ppdu...,parameters" function with the stored parameters, i.e. the parameters that not had to


be encoded. Next, all the parameters will be mapped on the corresponding session selVice primitiveparameters.

When the presentation layer operates in the "X.4lO" mode, it supports the procedures specified inthe earlier defined CCIlT recommendation X.410-1984. With this mode of operation, there is noneed to negotiate a defmed context set or a default context. "User-data" conceming this applicationis asswned to be of the ASN.I type OCfETSTRING. When the presentation layer operates in thismode communication is possible with presentation layers that are designed according 10 aboverecommendation.

Except for the session selVice primitives S-DATA.request and S-DATA.indication, the data valuesof the type "user-data" shall be encoded according to the Basic Encoding Rules for ASN.l. For theother two selVice primitives, the data values of the type "user-data" shall be encoded as thecontents octets of the primitive encoding of a value of type OCfETSTRING according 10 theBasic Encoding Rules for ASN.l. This means that this encoded data will not contain identifieroctets and no length octets. These two kinds of encoding in the "X.410" mode could be signalledto the function "change_encodecdecoder" when necessary.

Above the operation of the "prepare_ppdu-parameters" is explained.The "prepare_ss_usecdata" operates almost the same as the "prepare_ppdu_parameters" function,but now in the reversed way, i.e. the PPDU parameters inclusive the "user-data" has to be decoded.The differences between the two functions will not be explained because they are not necessary forunderstanding the operation of the "encodecdecoder.

7.4.2 The Change_Encoder_Decoder function

This function contains a library of all supporting abstract syntaxes and transfer syntaxes and theircorresponding encoding and decoding routines. This function has to perfonn three tasks :

• All the supporting abstract syntaxes and transfer syntaxes have to be filled into the store"supp_cs". With this infonnation the "ppm" is able to negotiate about the defined contexts. Auexample of the contents of the store "supp_cs" is given in Figure 7.6

Presentationcontext identifier

Abstract syntax name list of all supporting transfersyntax names

1 HospitalInfo Basic, Fast, Safe

3 PatientHistory Basic, Fast, Safe

Figure 7.6: An example of the contents of the storesupp_cs.

• The store "type_definition" has to be filIed. This store is used by the parser during the lexicalscarming of the encoded and decoded data.


• According to the accepted PPDU type and the abstract syntaxes of the "user-data" with thecorresponding transfer syntax(es), the right encoding and decoding routines are filled into thestore "encodecdecodecmicroprogram".

The function "change3ncodecdecoder" assurnes an ASN.I compiler which will convert allapplication layer supported ASN.I abstract syntaxes, i.e. descriptions of data struetures, of allaccepting PPDU parameters into encoding and decoding routines according to the list of supportingtransfer syntaxes of the presentation layer (see Figure 7.7). This ASN.l compiler is placed outsidethe presentation layer as an interface with the application layer via the data flow "update_microprogram".

ASN.1 compiler L. I ASN.1 supported abstract syntaxes II'" (Wka Hospitallnfo, PatientHistory)

ASN.1 BER I A1temative Iencoding

NieS Application layer

Change_encoder_decoder library

~l A1temative coding routines ---.List of allsupportingabstract and

...1 ASN.1 BER 1----·transfer

"1 coding routinessyntaxes

I

.+.Figure 7.7: An ASN.l compiler.

The data flow "update_microprogram" will carry new encoding and decoding routines when newabstract syntaxes are introduced by the application layer. The introduction of a new transfer syntaxis equivalent to changing the code generation part of the ASN.l compiler. Out of the acceptedlibrary of encoding and decoding routines the list of supported abstract syntaxes with their transfersyntaxes is extracted. This list looks similar to the contents of the store "supp_cs" (see Figure 7.6).

7.4.3 The encoder_decoder_error_controller function

This function provides the error-handling when an error occurs in the "encoder_decoder" function.It generates a ARP PPDU which will he transmitted to the "ppm" when an error occurs and itconverts the specific error message from a function of the "encodecdecoder" to a recommendederror message. The original error messages, with its errocsource, could he important for themaintenance of the presentation layer in future.


7.4.4 The Parser function

This function accepts the parameter(s) that have to be encoded or decoded. It checks the uncodeddata on correct syntax and will extract the encoded data with the help of the store "type_defmition". After lexical scanning by the parser it will fill the stores "parameters" and "value_tree". Thefirst store will contain all PPDU parameters, except the "usecdata".The designed parser is thus capable of handling encoded and decoded data. Assurne a CP PPDU istransnlitted to the parser. When the parser accepts uncoded data, the store "parameters" couldcontain :

type = protoeol_versionvalue = 1

When it handles data encoded according to BER for ASN.l, the "parameters" store could look like

typelengthvalue

=2 (the identifier for an integer, which is the ASN.l type of "protoeolversion")= 1 (the value is one byte large)= I

Of course, the store "parameters" will also contain the other accepted PPDU parameters, except the"user-data".

The store "value_tree" contains the values belonging to objects of one or several abstract syntaxes.These values will be stored in a value tree. Both stores could contain encoded or decoded data,depending on which adjacent layer has transmitted the data.

Let's illustrate the building of a tree by the parser with encoded data of the abstract syntaxes"HospitalInfo" and "PatientHistory", that were defmed in chapter 4. In section 4.3.1.4 the result ofthe encoding according to BER for ASN.I of values of these abstract syntaxes was given. Now theaddresses of the used memory allocations are added. Let's assume the start address is '0000'.address

HospitalWo0000 60

0002

0005

OOOF

0012

0015

0017

Lenglh Contents4D

Patientnumber Lenglh Contents12 Ol OD

Name Lenglh Contents13 08 416E 64 65

72 73 6F 6E

Age Lenglh Contents02 Ol 2D

Male Lenglh ContentsOl Ol Ol

PatientHistory Lenglh Contents61 38

Dlness Lenglh Contents80 09 4761 7374

72 69 74 69 73


0022

002D

0039

0045

Treating,..doctor Length Contents81 09 085065 7465

72 73 6F 6E

Treating,..date Length Contents82 OA 393230 34 30

3131 343030

Admision_date Length Contents83 OA 393230 35 30

3831 36 30 30

Medicine Length Contents84 08 4869 74 72

6164 6F 61

Suppose these encoded data will be accepted by the parser. The created value tree will get ahierarchical structure according 10 the abstract syntax of the "user-data". The leaf nodes correspondwith primitive types. the interior nodes represent constructed types. Such a value tree is suitable forparallel processing: the corresponding octets of each line could be packed as a separate token andbe decoded individually in parallel. However the parent-child relationship between the differentnodes should be preserved. Therefore a labelling mechanism is used. To calculate the label of acertain node the following rules are applied:

• The start label of the first tree-node will be FFFF• lf one is walking downwards on the value-tree. the label number is the address of the first byte

of the current node.• lf one is walking to the right of the value-tree. the label number is computed by inserting a "1"

as the most significant bit to the address of the first byte of the current node.

An implementation of an "encodecdecoder" in hardware using this kind of labelling is introducedby [Murat90]. When above encoded data is accepted by the parser. a value tree as shown in Figure7.8 will be created with a label for each tree-node.

0000

0015 8017 8022 802D 8039

Figure 7.8: A value tree according to the abstract syntaxes "HospitaIInfo" and"PatientHistory" •

Such a value tree could be stored in memory like Figure 7.9.


T

treelist

lavaliabie I

,,

)

FFFF 0000 80 4D0000 0002 12 01 00e002 0005 13 08 41 6E &;tR~5

7':> 701 R7

e005 OOOF 02 01 20eooF 0012 01 01 018QI2 0015 61 380015 0017 80 09 4761737472

697469738017 0022 81 09 08 5065 74 65

7273 676E8022 002D 82 OA 39323034 30

31313430308020 0039 83 OA 393230 35 30

38 31363030tlW8 U04b 84 08 48 69 74 72

61 64 67 61

label begin type leng1hackfr8Ss

Figure 7.9: A possible implementation of a tree structure.

v&lue

In this section the operation of the "parser" was discussed with help of the encoded data of theabstract syntaxes "Hospitalinfo" and "PatientHistory". This procedure also apply 10 acceptinguncoded "user-data" descrihed with ASN.l. Then the stores "parameters" and "value_tree" will notcontain the length field.

7.4.5 The encoder_decoder_processing function

This function performs the encoding or decoding of PPDU-parameters inclusive "user-data" or onlythe "user-data" that are contained in the stores "parameters" and "value_tree". The right encodingand decoding routines are filled in the store "encodecdecodecmicroprogram" by the function"change_encoder_decoder", which is instructed by the "prepare_*" functions. When the encoding/decoding task is completed, the encoded/decoded data will he redirected to the prepare functionwhere it came from.

As mentioned earlier, the "user-data" of an abstract syntax could he encoded in different ways.This depends on the mode the presentation layer operates in, the contents of "defined_cs" andwhether the context management functional unit is selected. The rules that are applied fordetermining the kind of encoding were explained by the discussion of the "prepare_*" functions.They signal to the "change3ncoder_decoder" function which encoding/decoding routines have tohe filled in the "encodecdecodecmicroprogram" store. Next the different encoding variants willhe explained.


Encoding of data values in "normal" mode.

Simple encoding

When this kind of encoding is selected the contents of the simple-encoded data shall be theconcatenation of the bitstrings, resulting from the encoding of the data values according to theappropriate transfer syntax. In terms of the Basic Encoding Rules, shall the encoding of the "userdata" value be the contents octets of the simple-encoded data value. TIlis means that this encodedvalue won't consist identifier octets and no length octets (see Figure 7.10). The transfer syntax thatwill be used for this simple-encoding shall either produce octet-aligned encodings or self-delimitingbitstrings.

appropriate

original data

User-data

Simple-encodeddata

concatenation of------'> the bitstrings

transfer syntax

Figure 7.10: Simple encoding principle.

Full encoding

When selecting this encoding variant the encoded "user-data" parameter value could consist of asequence of several different abstract syntaxes with for each abstract syntax its correspondingtransfer syntax(es). These combinations of syntaxes causes a list of presentation context identifierswith the correspondent "user-data", These identifiers are contained in the store "defmed3s" (seeFigure 7.11 for an example of the contents of this store).

Presentation contextidentifier

Abstract syntax name negotiated transfersyntax name

1 Hospitallnfo Basic

3 PatientHistory Past

Figure 7.11: An example of the contents of the store defined_cs.

The fuIl encoding shall be the application of the Basic Encoding Rules for ASN.l. The variousidentifier tag options for the data-values are :

• single ASN.l type• octet-aligned• arbitrary


Each of these types has a specific identifier tag which will be added at the front of the encoded"user-data" parameter. The type that will be used is deterrnined with the mIes below.

• If the list of data values contains exactly one data value which is a single ASN.l type encodedaccording to the BER for ASN.l then the option "single-ASN.l-type" shall be used.

• If the encodings of the data values are each an integral number of octets and the above given ruledoesn't apply, then the option "octet-aligned shall be used. In this case the contents octets of theOCfETSTRING shall be the concatenation of the bitstrings resulting from the encoding of thedata values contained in the "user-data" parameter value according to that appropriate transfersyntax.

• If neither of the above two rules apply, the option "arbitrary" shall be used. The contents octetsof the BITSTRING shall be the concatenation of the bitstrings resulting frorn the encoding of thedata values contained in the "user-data" parameter value according to the appropriate transfersyntax.

The general encoding mechanism is shown in Figure 7.12.

Original data

User-data corresponding withseveral presentation contextidentifiers

Appropriatetransfer syntax per-----:>

presentation contextidentifier

Full-encodeddata

Sequence of encoded userdata values, each encodedwith appropriate transfersyntax

Figure 7.12: Full encoding principle.

Encoding of presentation data value in "X.410" mode.

When the presentation layer operates in the X.4l0 mode, two encoding variants are possible :

• "user-data" encoded according to BER for ASN.l• "user-data" encoded as the contents octets of the primitive encoding of a value of type

OCfETSTRING according to the Basic Encoding Rules for ASN.l. This means that thisencoded data will not contain identifier octets and no length octets.

The "prepare_*" functions will instruct the "change_encodecdecoder" which variant will be usedwhen the presentation layer operates in the "X.4lO" mode. The last function will provide theproper contents of the store "encoder_decodecmicroprograms".


7.5 The Evolution of the architeeture of the presentation layer

In Figure 7.3 and Figure 7.5 the functions of the presentation layer were specified. It shall be clearthat such a functional specification would not be realized at once. It is more an evolution process.When I started my graduation work. the encoder/decoder of the presentation layer was earlierspecified by P. Verhaak [Verh91]. However, this functional specification was not complete and nottotally according the CCITT recommendations.

First, the encoding mechanism had to be improved. Till then it was not possible 10 encode anddecode the ppdu parameters, except the "user-data". To realize this possibility, which is required bythe CCIlT recommendations, it was necessary to improve the earlier designed flow diagrams ofthe presentation layer (two of the improved diagrams were shown in Figure 7.3 and Figure 7.5).Also the different types of encoding/decoding for the "user-data" were not specified.

Now, the designed encoder/decoder is able to encode/decode the ppdu parameters according toBER for ASN.l. Also the different encoding principles for the "user-data" for the two modes thepresentation layer could operatein are specified.

Above described and other improvements were made to meet the requirements of the CaTTrecommendations [X.216] and [X.226]. Also, the requirements model is extended further according10 above recommendations. In appendix A a full specification of the presentation layer could befound.

As said in chapter 6, the second phase of the Hatley and Pirbhai modelling technique is called "thearchitecture model". In this phase it is necessary to decompose the specified presentation layer inseveral modules. Each module could contain the earlier specified functions that are used by one ormore other modules. To accomplish a good starting point for a hardware design, I decided to redesign the "encoder-decoder". In the old version both a "parser" and "deparser" function existed. Inthat case all uncoded "user-data" was stored in a data tree before encoding. The accepted encoded"user-data" (accepted from the session layer) was not stored in such a data tree before decoding,but after the decoding was perfonned. So, the function "encoder-decoder-processing" (see Figure7.5) had to read (before encoding the "user-data") or build (after decoding the "user-data") a valuetree. Thus the operation of the "encodecdecoder_processing" was not unifonn. Therefore is chosenfor another layout of the "encoder-decoder" as can be seen in Figure 7.5. All the accepted "userdata" (uncode or encoded) will be parsed and stored in a value tree. Next the function"encodecdecodecprocessing" will always read the "user-data" out of the value-tree. By using sucha value tree for encoded and decoded data the encoding and decoding process could be perfonnedin parallel. The now specified functions perfonn their tasks in a unifonn way. This modificationprovides a better mapping on hardware of the functions "parser" and"encodecdecodecprocessing". A possible strueture of modules of the encoder/decoder is given inFigure 7.13. Each of the modules contains one or more functions that were specified earlier in therequirements model. When possible the modules are called the same as the specified function. Inthe other cases the modules contain composed functions that are used by more than one othermodules. With help of the requirements model in appendix A the functions could be found that arecontained in each module. It has to be remarked that more research has to be done before acomplete architecture model of the encoder/decoder and finally the presentation layer could bedesigned.


Figure 7.13: A possible structure of modules of the encoder/decoder.

7.6 General implementation considerations

7.6.1 Quality of service aspects

In this section severa! genera! system requirements for an implementation of the presentation layerwill be discussed. Of course, the implementation must be correct: it must conform to the ccnTrecommendations X.216 and X.226. and internet correctly with its local environment Second, theimplementation of the presentation layer should be efficient: it should provide low delays and highthroughput These and other performance requii"ements can be specified by the application layer forthe using presentation layer connection. Defming these performance requirements is importantbecause they must be satisfied by the final implementation of the presentation layer. In Table 7.2 aclassification of performance quality of service parameters is shown.

In CCITI Recommendation X.215 tbe above parameters are explained.

Future extensions may establish a use of the quality of service parameters in determining thetransfer syntax to be used.


Table 7.2: The recommended performance criteria.

Phase Perfonnance criterion

Speed Accuracy IReliability

Presentation Presentation Presentation connection establishment fail-connection connection ure probability (misconnection/presentationestablishment establishment connection refusal)

delay

Data transfer Throughput Residual error rate (corruption,duplicati-transmit delay on/loss)

Presentation connection resilenceTransfer failure probability

Presentation Presentation Presentationconnection connection connection releaserelease release delay failure probability

7.6.2 Interfacing aspects

As can he seen in Figure 7.5 tbe functions "psdu_buffer" and "ssdu_buffer" of the presentationlayer are interfacing witb its adjacent layers. Tbe OSI Reference Model caUs tbe interfaces hetweentwo adjacent layers Service Access Points (SAP's) tbat are identified witb SAPI's (SAP identifiers). However, tbe recommendations do not detennine tbe implementation of such a SAP.A SAP could he irnplemented as :

• a certain address where the data is sent to or several addresses where tbe data is sent to (amemoryblock).

• a software procedure for requesting certain services or a genera! software procedure forrequesting all available services per layer.

As seen above, a SAP could he implemented eitber in software and hardware. Tbe kind of implementation of the "psdu_buffer" and "ssdu_buffer" is dependent of tbe choice which presentationlayer functions will he implemented in software and which in hardware. AD example of a possiblecommunication schematic for tbe presentation layer is given in Figure 7.14.

In order to reduce the bandwidtb of datatransfer hetween tbe presentation layer and its adjacentlayers, the datapassing could he done by sending only tbe start address and the amount of bytes tohe read. So, only these two types of data could he transmitted to/from tbe presentation layerthrough FIFa queues. Tbe queue witb pointers could he stored in memory of the host, i.e. tbecomputer where the presentation layer operates on, or in memory of tbe presentation layer. Tbeimplementation is also dependent of tbe choice which presentation layer functions will heimplemented in software and which in hardware.


Applicatien layerapprlC8lion Iayer0UlpUt queue ---.

presentatlon Iayer...___Input queue

Presentatien layerpresentatlon Iayeroutput queue ~ t::=:j

_ion Iayer ~ t::::::JInput queue

Sessien layer

Figure 7.14: A possible communication schematic of the presentation layer.

7.6.3 Encoder_decoder implementation aspects

In the ISO text there is no explicit mention of the "encodecdecoder". The encoding/decodingseems 10 be a function which could be easily centralised in a single component (see Figure 7.5).Nowadays, the trend is to design software based ASN.l encoder/decoders. A lot of ASN.lcompilers have been designed (see La. [Naka88] and [Neuf89]). Such compilers use target language (most commonly C) data structures to represent the ASN.l data types and values. In literatureno descriptions were found about complete implementations of the presentation layer. However, afew software implementations ([Bess88],[Cane87],[Pope84]) and one hardware implementation([Murat90]) of the "encoder _decoder" are known.

When implementing the "encodecdecoder" in hardware its processing rate could be increased (see[Murat90]). One way of accomplishing such processing rates is to introduce a fonn of parallelprocessing during the encoding/decoding process. To implement such an "encodecdecoder" it isadvisable to use the same design for both the encoding and decoding process and construct theentire architecture by using a number of similar units. However, when implementing the"encodecdecoder" in hardware it is difficult 10 change its design when the implemented scheme ismodified. Therefore it is recommended to make the architecture programmabie. Programmability isimportant for any ASN.l encoder/decoder for three reasons :

• Changes in the abstract syntax or modifications in application layer protocol defmitions.• Changes in transfer syntax. For example for compression, encryption etc.• Use of the ASN.l encodecdecoder in different environments: It will work on APOU's which

contain different types of abstract syntaxes used in numerous different applications. Each of thoseapplications may run on different type of computer with a different type of operating system andquite naturally may be implemented with one of the numerous different programming languages[Murat90].


7.7 Summary

The developing phase of the presentation layer, according to the Hatley and Pirbhai modellingtechnique, will start with defining a context diagram. Such a context diagram will serve a specialrole in the requirements model. However, it could be designed in many ways. The chosen contextdiagram influences the whole further designing of the presentation layer.

Next, the first level of decomposition of the presentation layer and the "encodecdecoder" wasshown and explained. The designed "encoder_decoder" is able 10 encode/decode the ppduparameters according 10 BER for ASN.l. Also the different encoding principles for the "user-data"for the two modes the presentation layer could operate in, are specified. Besides these and otherimprovements the specification of the presentation layer is extended. The layout of the"encodecdecoder" is improved to proyide a better mapping of this function on hardware. Alsosome considerations were made concerning a hardware implementation of the presentation layer.


Chapter 8

Conclusions

8.1 Conclusions

In my graduation period several tasks are completed. First the functional interfaces with theadjacent layers of the presentation layer were specified. Also a "direction-arbiter" was introducedwhich manages the resources of the presentation layer. Next, the overall strueture of the presentation layer was improved according to the CCITI recommendations X.216 and X.226 ([X.216],[X.226]) including an improved specification of the important stores "supported_contexcset" and"defined30ntexcset". Also the earlier designed Encoder/Decoder by P.Verhaak [Verh9l] is furtherimproved and extended according to above recommendations. The functional layout of theEncoder/Decoder is changed to provide an uniform operation of the encoding and decodingprocess. This uniform operation makes this process more suitable for a hardware implementation.When possible the designed functions consist of the same functional building blocks. Finally, therequirements model is improved to provide a better maintenance-possibility in future.

8.2 What next?

The Encoder/Decoder is specified completely according to the modelling technique of Hatley andPirbhai and the CASE-tooI ProMod. Although ProMod did not detect any errors in the definedrequirements model, it is not a guarantee for a 100% correct specification. Next, the interactionbetween the several specified functions is not checked by ProMod. Therefore it would be advisableto simulate the complete requirements model before designing the presentation layer in hardware.ProMod does not contain such a simulate function. For example the description language VHDLcould be used to perform such a task.

The second design step of ProMod, called "system design", which corresponds with the architecture model of the Hatley and Pirbhai modelling technique could be used for determining theseveral distinguishable modules of the presentation layer. For each module it has to be determinedwhether it will be implemented in hardware or software. This choice per module will be made withcriteria as performance and flexibility. Hardware solutions will be in favour over software solutions

84

conceming the perfonnance criteria. However, when flexibility is important the software solutionwill become in favour.

Because the last design step of ProMod called "program design" is not suitable for the designing ofa hardware architecture maybe other tools like IDaSS could be used 10 deve10p the presentationlayer.

Doling the designing of the presentation layer several other choices have 10 be made. TI1epresentation layer could be implemented as one IC, a "plug-in" card or maybe partly in softwareon the host-eomputer. Does it use its own memory or memory of the host-computer and how doesit interface with the other OSI layers through the SAP's ? These answers will he influenced by thepresentation layer system-requirements and the chosen hardware/software border.

The most suitable module for a hardware solution is the Encoder/Decoder because the encoding/decoding task seems the most time-consuming task. It should he implemented with one ormore microprocessors for the reasons described in section 7.6.3. To avoid influence on the hostprocessor(s) perfonnance the encoder/decoder microprocessor(s) could be implemented "on-board".Whether the other functions shall be implemented in hardware or software is dependent of thecertain function and the chosen hardware/software border.

Conc1usions. 85

Chapter 9

Literature

[Bess88]

[Cane87]

[Dant90]

[Hals88]

[Hatl87]

[Held83]

[Hens88]

[Huit89]

[Hurk92]

Besson, M., Doghri, A., and Huitema, C."High performance heterogeous transmission using OS/ presentation protocol",Proc. of Third Int. Conf. on Computer and Inforrnation Sciences, Cesme, Turkey,29 Oct.-2 Nov., 1988, pp. 1-12.Commack, NY: Nova Science Publishers, 1989.Caneschi, F. and Merelli, E."Standardizing the presentation layer. Why and what"?", Proc. Seventh Int. Conf.on Distributed Computing Systems, Berlin, 21-25 Sept. 1987, pp. 35-39.Washington, DC: IEEE Compul Soc. Press, 1987.Danthine, A.10 Years with OS/, Inforrnation Network and Data Communication, lIl,Elsevier Science Publishers, IFIP, 1990.Halsall, F.Data communications, computer networks and OS/,Avon, The Bath Press, 1988.Hatley, D. and Pirbhai, I.Strategies jor Real-Time System Specification.New Vork: Dorset House Publishing, 1987Held, G. and Marshall, T, R.Data Compression, John Wiley and Sons, 1983.Henshall, J. and Shaw, A.OS/ Explained: End-to-end computer communication standards.Chichester: Ellis Horwood, 1988.Computer Communications and Networking.Huitema, C. and Doghri, A."Defining jaster transjer syntaxes jor the OS/ presentation protocol", Comput.Commun. Rev., Oct. 1989, vol. 19, no. 5, pp. 44-45.Hurkmans, M.C.A.A Requirements Model oj the OS/ Presentation Layer.Faculty of Electrical Engineering, Digital Inforrnation Systems Group, EindhovenUniversity of Technology, February 1992.

86

[Lam86]

[Murat90]

[Naka88]

[Neuf89]

[Pope84]

[Prom89]

[Roch91]

[Tane88]

[Verh91]

[X.200]

[X.208]

[X.209]

[X.216]

[X.226]

[XAOO]

Lam, M, S. and Komo, J,1.A comparison of data compression algorithms, IEEE 1986.Murat, B. and Behcet, S.,An ASN.l Encoder/Decoder and its performance,Protocol Specification, Testing and Verification,Elsevier Science Publishers B.V., IFIP, 1990.Nakakajawi, T.,al,Development and Evaluation ofApricot (tools for Abstract Syntax Notation One),Pro. 2nd Int Syrnp. on InteroperabIe Infonnation Systems, pp. 55-62, 1988.Neufelt, G.W.,Abstract Syntax Notation One and its applications,Forte 89 Tutorial Notes, Dec 5-8 1989, Vancouver.Pope, A.R."Encoding CC/1T XA09 presentation transfer syntax",Comput. Commun. Rev., Oct. 1984, vol. 14, no. 4, pp. 4-10.ProMod Computer Aided Software Engineering,User Manual, Version V1.7a,GEI Gesellschaft fur Electronische Infonnation Verarbeitung,december 1989.Rochester, J.B.Open Systems !nterconnection,lIS Analyzer, Vol. 29, no.8, Rockville, United Communication Group,August 1991.Tanenbaum, A.S.Computer Networks. 2nd Ed..New Jersey: Prentice Hall Int., 1988Verhaak, P.An architecture for an OS! protocol (layer 6).Faculty of Electrical Engineering, Digital Infonnation Systems Group, EindhovenUniversity of Technology, December 1991.!nformation Processing Systems - Open Systems Interconnection - ConnectionOriented Presentation SelVice Definition, International Standards Organization,1988. Geneva: CCITT, Volume VIII, fascic1e VIllA, X.200, 1989.Infonnation Processing Systems - Open Systems Interconnection - Specification ofAbstract Syntax Notation One (ASN.l), International Standards Organization, 1987,ISO 8824.Geneva: CCnT, Volume VIII, fascic1e VIllA, X.208, 1989.Infonnation Processing Systems - Open Systems Interconnection -Specification of Basic Encoding Rules for ASN.l, International Standards Organization, 1987, ISO 8825. Geneva: CCITT, Volume VIII, fascic1e VIllA, X.209, 1989.Infonnation Processing Systems - Open Systems Interconnection -Connection Oriented Presentation Service Definition, International StandardsOrganization, 1988, ISO 8822. Geneva: CCITT, Volume VIII, fascic1e VIllA,X.216, 1989.Infonnation Processing Systems - Open Systems Interconnection -Connection Oriented Presentation Protocol Specification, International StandardsOrganization, 1987, ISO 8823. Geneva: CCITT, Volume VIII, fascic1e VIII.5,X.226, 1989.Message Handling Systems,System and service overview, CCITT Recommendation XAOO, 1988.

Chapter 9: Literature. 87

[X.409]

[Zimm80]

Message Handling Systems: Presentation Transfer Syntax and Notation, CCITIX.409, Red hook, fascicle VIII.7, Torremolinos, 1984.Zimmennan, H.The ISO model of Architecture for Open Systems lnterconnection,IEEE Trans. Commuo., COM-28,4 , April 1980, pp 425-432.

Chapter 9: Literature. 88

eindhoven university of technology master an architecture ... · university oftechnology is...

Documents