eindhoven university of technology master a requirements ... · a requirements model of the osi...

Eindhoven University of Technology

MASTER

A requirements model of the OSI presentation layer

Hurkmans, M.C.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/a-requirements-model-of-the-osi-presentation-layer(d88fa078-9b7f-41fe-9fc8-aa9aad8e669e).html

A Requirements Model ofthe 051 Presentation Layer

M.e.A. Hurkmans

Faculty of Electrical EngineeringDigital Systems Group

Eindhoven University of Technology

Eindhoven, February 1992

Professor: Prof. Ir. M.PJ. StevensCoach Ir. M.J.M. van Weert

The faculty of Electrical Engineering of Eindhoven University of Technology does notaccept any liability regarding the contents of student project- and thesis-reports.

/"r_, i .f( t' r;;.

J J

Abstract

The OSI reference model was bom in 1979 out of the need for compatibility betweencommunicating systems. Now. it bas seIVed as a major standard for communication systems forseveral years already. and new implementations are being introduced to the market on a regularbasis. The faculty of Electrical Engineering of Eindhoven University of Technology has put mucheffort in studying and implementing the different layers of the model. After much of the energy hasbeen aimed at the lower layers. more attention has recently been focussed on one of the higherlayers in the reference model. the presentation layer.

The task of the presentation layer entails securing correct interpretation of transmitted data by thecommunicating end-systems. Incompatibility between the systems is introduced by the fact that thedata representations supported locally do not correspond. eg. ASCII versus EBCDIC character sets.This problem strikes out the efforts by lower layers 10 establish error-free communication. sincecorrectly transmitted information is ultimately interpreted erroneously anyway. The presentationlayer must resolve these differences byencoding data to/from a common representation from/to thelocal format. Due to the complexity introduced by this responsibility the presentation layer isusually designed on a software basis. However. the objective of this project. initiated by the DigitalSystems Group of the faculty of Electrical Engineering. is to establish a fully functionalpresentation layer in hardware.

Before the layer can actually be implemented it is essential to first specify the functionality of thepresentation layer. The specification is accomplished according to the guidelines suggested byHatley & Phirbai. They promote a two-stage design trajectory. The first phase inc1udes definitionof a specification better known as the requirements model. This model purely regards functionalaspects without referring to any possible hardware solutions later. This leaves the designer as muchfreedom as possible. The second phase involves the transition from the requirements model to a realhardware implementation.

In this thesis-project a requirements model of the presentation layer is created. based on the CCITTrecommendations. specifically X.216 and X.226. The recommendations have been carefullyanalyzed. This mainly required c1assification of the seIVices provided by the layer and detailedinvestigation of the protocols in question. Additionally. the overall coding scheme has beenanalyzed in more detail. conceming application of abstract and transfer syntaxes to define datastructures and subsequently code them.

This has resulted in a detailed specification of the presentation layer. The requirements modelmainly distinguishes a protocol machine. which embodies the communication aspects of thepresentation layer. a Defined Context Set management process. which controlls theencoding/decoding context. and a core user-data encoder/decoder process. The protocol machinehas been establised as a combination of cooperating state machines. The controllers are primarilybased on the state tables in X.226. This does not only facilitate preventation of errors but alsostimulates conformance to the standards. The Defined Context Set management process has notbeen decomposed yet but its function is c1early specified in terms of the tasks it should implementto support the protocol machine. Less attention was paid to the encoding and decoding processesof user data. The reader is referred to research performed earlier in this project for a morecomprehensive treatment.

ii

Contents

Abbreviations iii

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. iv

List of Tables v

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

2. An Introduction to the OSI Reference Model 32.1 Layers and Hi~rarchy 3

2.1.1 Layer Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 42.1.2 The OSI Stack 5

2.2 Layer Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 62.2.1 Interaction between Peer Entities . . . . . . . . . . . . . . . . . . . . . . . . . .. 72.2.2 Interaction between Adjacent Entities 72.2.3 Accessing Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 82.2.4 Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9

3. Overview of The Presentation Layer 103.1 Imp1ementing Syntaxes 11

3.1.1 The Defined Context Set 113.1.2 The Default Context Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 123.1.3 Functional Units 12

3.2 Presentation layer services 133.2.1 Connection Establishment 133.2.2 Connection Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 153.2.3 Context Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 153.2.4 Information Transfer 16

3.3 Session Layer Services 173.3.1 Synchronization 173.3.2 Resynchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 183.3.3 Token Management 193.3.4 Activity Management and Exception Reporting. . . . . . . . . . . . . . . .. 19

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22

4. Abstract Syntax and Transfer Syntax 234.1 Abstract Syntax Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 24

4.1.1 ASN.l Types 244.1.2 Character String Types 264.1.3 Tagging . . . . . . . . . . . . . . . . . . . . .. 26

4.2 The Transfer Syntax 274.2.1 Practical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 274.2.2 Basic Encoding Rules 29

4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30

iü

5. The presentation protocol machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 315.1 Introduction 315.2 Connection Establishment 325.3 Connection Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 345.4 Context Management 355.5 Inforrnation Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 365.6 Resynchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 375.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38

6. Forma! description methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 396.1 The requirements model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 406.2 The Architecture Model 42

6.2.1 The Architecture Module .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 426.2.2 Structure of the architecture model 43

6.3 The CASE tooI ProMod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 446.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 46

7. Specification of the presentation layer 477.1 Context Diagram 477.2 Genera! Structure 49

7.2.1 The SDU Buffers 517.2.2 The Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 527.2.3 Model of the Encoder/Decoder 55

7.3 Modelling the Protocol Machine 567.3.1 Implementing X.226 State Tables 577.3.2 The Error-Trapping System 60

7.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 61

8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 628.1 What next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 62

9. Literature 64

Appendix A. Service Protocols 66

Appendix B. ProMod Structured Analysis Report 72

iv

Abbreviations

•

ACACAARPARUASN.lBERCCDCOTICDCFDCMCPCPACPRCRCSCSPECDCDDCSDFDFDICIIDUISOOSIPCIPDUPICIPIDUPPCIPPDUPPMPSAPPSDUPSPECSAPSDUSICISIDUSSAPSSDUTCTCCTDTETIDRSRSA

Alter ContextAlter Context AcknowledgeAbnonnal Release ProviderAbnonnal Release UserAbstract Syntax Notation One.Basic Encoding RulesControl Context DiagramInternational Telegraph and Telephone Consultative CommitteeContext DiagramControl Flow DiagramContext ManagementConnect PresentationConnect Presentation AcknowledgeConnect Presentation RejectContext RestorationContext SetControl SpecificationData Context diagramDefined Context SetData Flow DiagranlFlow DiagramsIntetface Control infonnationIntetface Data UnitInternational Standards OrganisationOpen Systems InterconnectionProtocol Control InfomlationProtocol Data UnitPresentation Interface Control InfonnationPresentation Interface Data UnitPresentation Protocol Control infonnationPresentation Protocol Data UnitPresentation Protocol MachinePresentation Service Access PointPresentation Service Data UnitProcess SpecificationsService Access PointService Data UnitSession Intetface Control InforrnationSession Intetface Data UnitSession Service Access PointSession Service Data UnitTransfer CapabilityTransfer Capability ConfirrnTransfer DataTransfer ExpeditedTransfer Typed DataResynchronize SessionResynchronize Session Acknowledge

v

List of Figures

Figure 2,1 Hi(!rarchic organization of OS1. 4Figure 2,2 Two communicating OSI end-systems. . . . . . . . . . . . . . . . . . . . . . . .. 6Figure 2,3 Peer-to-peer communication. 7Figure 2,4 Assembling OSI data units. . . . . . . . . . . . . . . . .. 8Figure 3,1 Restoration of the Defined Context Set. 19Figure 3,2 Inf1uence activity management services on DCS. . . . . . . .. 22Figure 4,1 The X.209 Data E1ements. 29Figure 5,1 Exchange of PPDUs in context establishment. . . . . . . . . . . . . . . . . . . . . . . .. 32Figure 5,2 Exchange op PPDUs in context management. 35Figure 5,3 Collision of two CONTEXT-MANAGEMENT procedures. . . . . . . . . . . . . . .. 36Figure 5,4 Exchange of PPDUs in resynchronization. . . . . . . . . . . . . . . . . . . . . . . . . . .. 37Figure 6,1 Relation between components of the requirements model. . . . . . . . . . . . . . . .. 40Figure 6,2 Data and Control Context diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41Figure 6,3 Data and Control Flow Diagrams. 41Figure 6,4 The template of an architecture module. 43Figure 6,5 The architecture model components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 44Figure 6,6 The ProMod project model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 44Figure 7,1 Context diagram with peer-to-peer communication. 48Figure 7,2 Service provision in the Context Diagram. 48Figure 7,3 Realistic Context Diagram. 49Figure 7,4 Block diagram of the presentation layer. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 50Figure 7,5 First level Data Flow Diagram. 51Figure 7,6 Example of DCS administration. 53Figure 7,7 Block-diagram of protocol machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 58Figure 7,8 Generallayout of protocol machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59

vi

List of Tables

Table 3,1 Presentation service primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13Table 3,2 Connection establishment service , 13Table 3,3 Connection release service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 15Table 3,4 Context management service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16Table 3,5 Infonnation transfer services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16Table 3,6 Session service primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17Table 3,7 Resynchronization service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 18Table 3,8 Token management seices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 19Table 3,9 Activity management service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20

vii

1Introduction

Infonnation plays an evennore important mIe constituting a vita1 pillar society rests on. One merelyhas to consider the increasing volumes of traffic in the banking and trading business, in order todraw the inevitable conclusion that Wall Street anno 1950 is a definite relic.First television entered society, enabling the viewer to reach the vast outskirts of the world andsetting infonnation exchange in motion. Then the computer was invented, allowing to locally storeand manipulate infonnation. Fina1ly, the introduction of computer-networks which combined bothaspects of infonnation-flow and computer-power, sounded the rapid accelaration to todaysinfonnation-society .

However, there still was much incentive for impmvement. As incompatibility between computerslimits software exchange, network incompatibility limits exchange of infonnation. This pmblem waswidely recognized and standards were developed to lift these limitations. This resulted in theadoption of the Open Systems Interconnection (OSI) reference model.The OSI model aims to standardize communication, thus allowing communication betweencomputer-systems manufactured by different companies on a worldwide sca1e. It separates thecommunication-process in distinctive elements gathering similar aspects into one managebiepartition. The OSI model defines 7 of these partitions, arranged as layers in a hiërarchica1 stack.

The first implementations of OSI based communication-systems have a1ready appeared on themarket [Mant88]. Many more are to follow. The lower layers are a1ways implemented in hardwaredue to the straightforward and relatively simple nature of their task. The higher layers may beimplemented using either hard- or software. The latter is usua1ly the case, having significantdrawbacks in tenns of speed and complexity.

This thesis will develop a hardware specification for one of the higher layers of the OSI model, thepresentation layer. Emphasis will be put on specification of the protocol machine. This will berea1ized using the SASD method of Yourdon, with the rea1-time variant described by Hatley &Phirbai.

Chapter 2 shall first introduce the reader to the basic OSI model philosophy and tenninology.Chapter 3 then will present an overview on the presentation layer. Emphasis will be centered 10 thegenera! purpose and services available. Chapter 4 will provide insight into the Abstract Syntax

1

CHAPTER J. JNTRODUCTJON 2

Notation used by the presentation layer. Also, this chapter will explain how data are encodedthrough application of the BER transfer syntax. Subsequently, the presentation layer will besubjected to a thorough investigation of the protocols in chapter 6. Issues like interaction betweentwo systems with protocol data units are brought to attention. The next chapter shall comment onthe specification method used to model the presentation layer. Briefly, a CASE tooI called ProModwill be illustrated. Fina1ly, the last chapters describe in full how a hardware specification wasestablished.

2An Introduction to the OSI Reference Model

Until recently, interworking usually was limited to equipment provided by one manufacturer, thusseverely limiting compatibility and exchangebility. Most companies therefore were obliged topurchase their systems from a single manufacturer or implement their own private standards.Together with the rise of worldwide networks and a growing need for unrestricted information flow,this led to astrong demand for a common standard.

The International Standards Organization (ISO) is responsibie fordeveloping international standards.To meet the needs outlined above, ISO developed the OSI reference model. The OSI referencemodel bas been developed with the aim to facilitate system-independent communications betweencomputer systems, which may be located in various countries and supplied by differentmanufacturers. A model that, according to ISO, can act as a reference during devellopment of newcommunciations services, enables different users to communicate and enables a steady evolutionby allowing flexibility for advancements in technology to be implemented.

This chapter will present a brief introduction to the concepts surrounding the OSI model. It willdescribe issues like layered structure, primitives etc. Commonly used abbreviations, names anddefinitions will also be explained. This chapter does not add any information to that already givenin the ISO standards, but may serve to refresh the readers knowledge of OSI terminology used insubsequent chapters. For a more elaborate discussion the reader is referred to applicable OSIstandards such as [X.200] or to books such as [Hens88] and [Tane88].

2.1 Layers and Hiërarchy

To provide functionality over a wide range of applications, ISO designed a model consisting ofseven discrete partitions, each assigned 10 aspecific function. The rationale bebind this constructionwas to improve insight and isolate the specific problems of the various partitions. There are sevenpartitions, arranged in a hiërarchical relationship, which are referred to as layers. These seven layerstogether constitute a stack where each higher layer uses the services of the lower layer. A realcommunication-system consists of two of these stacks communicating over OS!. The layers in topto-bottom fashion shown in figure 2,1.

3

CHAPTER 2. AN INTRODUCTION TO THE OSI REFERENCE MODEL

7 Application layer

6 Presentation laye

5 Session layer

4 Transport layer

3 Network layer

2 Data Link layer

1 Physicallayer

Figure 2,1 Hiërarchic organization of OS!.

2.1.1 Layer Functionallty

4

As mentioned before, alllayers perform distinct functions. This paragraph will briefly describe eachlayer and its functions.

o The application layer is the top layer that provides the interface between the system-dependentend-user and the system-independent communication service. All lower layers in the systemexist to support and facilitate the services provided by the application layer.The layer incorporates a variety of system-independent functions, some of which arestandardized. These include:

a) file transfer and job managementb) message handling servicesc) job transfer and remote job management

o The principal function of the presentation layer is to provide a common representation for theapplication information while it is being transmitted between two computer systems. Thisfeature is necessary because two systems might not share the same standards for interpretationof information. A classic example can be illustrated considering a system sending characters inASCII code to a destination. As long as the destination also employs the ASCII standard, allcharacters are interpreted correctly. However, when either one utilizes EBCDIC characterencoding, the other will interpret the characters erroneously. Apparently a commonrepresentation is needed here.Summarizing, the function of the presentation layer consists of providing , by negotiationbetween the two computer systems, a common representational format for data while it is intransit. In addition, this layer might provide data compression and encryption features.

o As yet, the layers considered all related to creation and management of information fortransmission. The session layer bears the task to actually establish and control communicationbetween two end-users. It divides the model between the 'high-level' upper layers and the with'real-time' communications occupied lower layers.The session layer provides dialogue control options by allowing insertion of synchronizationpoints in the application infomlation. These points define that all previous data transfer has beensuccesfuI. If an error occurs with possible loss of information, the flow can be restarted fromthe last synchronization point. Additionally, it supports activity management, allowing activities

CHAPTER 2. AN INTRODUCTION TO THE OSI REFERENCE MODEL 5

to be started, halted, suspended, restarted etc. under (indirect) control by the application layer.Use of this seIVice allows the application to order and manage its work.Although the lower layers provide full-duplex operation, this layer also enables half-duplexcommunication. For this purpose it supports schemes 10 handle tokens.

o The 'real-time' communications environment starts at the transport layer. Communicationnetworks can differ in various aspects. These are frequently related to the underlying physicalmedium. Some protocols for example are supplied with extensive error-tracking and recoveryschemes where others support virtually no means for this purpose. The combination of aspecific communication method and physical medium is called a sub-network. Basically, thetransport layer is to provide error-free transmission seIVice to the upper layers and isolate themfrom the recurrent progress in hardware technology.lts basic function is to setup and tenninate network connections required by the session layerand handle flow control during transmission. The layer has the authority to assign multipleconnections to one process for high throughput or use multiplexing to reduce costs. Atestablishment, it also detennines what type of connection to provide, eg. error-free point-1opoint communication versus broadcasting.

o The network layer, in contrast to the previous discussed layers, is the first layer, which is notconcemed with end-to-end communication. Rather, it communicates with its immediateneighbours, creating a path over which subsequent communication can occur.Besides routing, the network layer deals with relaying, ie. the use of an intennediate computersystem to allow data transmission from one sub-network to another (possibly dissimilar) subnetwork. Note that relaying mayalso be implemented in lower layers. This mainly depends onthe degree of incompatibility between the networks.Thus, communication between two computer systems can he provided to the transport layer,even when these two systems are not connected to the same sub-network.

o The data link layer guarantees error-free data transmission hetween two network layers. It isalso concemed with flow control, in order to prevent a fast transmitter from drowning a slowreveiver.

o The physical layer constitutes the interface to the physical medium for data bit transmission.Typical issues are output voltage, physical connectors, timing of bits etc.

2.1.2 The 051 Stack

Communication between two computer systems implies communication hetween two end-systems,both consisting of a stack as illustrated in figure 2,1. The OSI model defines communication to heachieved by the cooperation of two equallayers, one in each end-system. This implies that eachlayer of the OSI stack in one end-system communicates with its equivalent layer in the other endsystem. The active elements in each layer are referred to as entities. Two entities in the same layeron two different end-systems are called peer entities. These two peer entities combined perfonn thefunctions attributed to the layer by exchanging messages according to a protocol devised for thatlayer.

Communication is initiated by a user requesting aselVice from the application layer. Theapplication layer then needs to exchange messages with its peer, e.g. open a remote fIle. Toestablish this exchange, the application layer must use the selVice of the presentation layer. The

CHAPTER 2. AN fNTRODUCTfON TO THE OSf REFERENCE MODEL 6

presentation layer at its turn wants to execute its own functions by communicating with its own oflayers using the service from the lower layers.

Each time, the messages are encapsulated by the messages of the lower layer until after seven layersthe concatenated message is transmitted to the destination end-system. Here, the combined message'crawls' up the stack of layers again, each layer identifying and seizing its message and forwardingthe remains to the upper layer. Eventually, the core of the message is presented to the end-systemapplication entity.

app11cat1on agentsEND-SYSTEM A

presentatlonlayer

use andprov1s1onof services

layerentlties

real phys1cal med1um

END-SYSTEM B

Figure 2,2 Two communicating OSI end-systems.

Figure 2,2 shows the two end-systems and two directions of communication. First, there is thevirtual communication with each entities peer. Secondly, the figure expresses the interactionbetween layers in one end-system. The application layer is a special case because the 'user' of thatservice is not a higher layer entity but a system-dependent application agent, an interface betweenthe real user and the OSI model. The OSI model as illustrated in the figure implies that OSI mayonly be accessed through the application level and that information always traverses all sevenlayers.

2.2 Layer Interaction

The previous paragraphs have attempted to present an overall context within which layer interactionshould be observed. As stated, peer entities exchange messages with each other to accomplish thefunctionality requested by their 'user'. Additionally, it was shown that entities must communicateup and down the OSI stack 10 establish message exchanges between peers.

To facilitate generic treatrnent of the communication mechanisms, a layer will be referred to as (N)layer, the actual name being arbitrary. The associated service is called (N)-service and it's user isa (N)-user. This notation is practiced in all references to layers.

CHAPTER 2. AN lNTRODUCTlON TO THE OSl REFERENCE MODEL 7

2.2.1 InteractIen between Peer Entltles

Consider figure 2,3. The (N)-layer in end-system A receives a request for service from its user. Asexplained in the previous section, the (N)-entity then constructs a control message (a) according toits protocol for transfer to its peer on end-system B. However since the only communication pathis the physical medium, the (N)-layer must invoke the (N-l)-service. The (N-I)-entity satisfies thisrequest by cooperating with its peer on the remote end-system B. It constructs a control message(b) and inc1udes the control message from its user as data. This process is repeated until thephysicallayer is reached.

When the assembIed message is received at the destination end-system the package is disassembled,each layer detecting and stripping its control message as the package ascends through the OSI stack.This way a virtual communication path between peer (N)-entities is acquired.

OSl staek end-system A

request

OSl stack end-system B

lndicatlon

+ (N)-layer entlt1es +~

- - - - - - (~)- - - - - -r---- - --,, (N-l)-layer entlt1es T-.-- (bI -r---- ------------ ---1ce , (N-2)-layer entlt1es T-~ -r---- ------------ ---1I physlcal medium I

? ?

(N-l) -user

(N-l)-servl

Figure 2,3 Peer-to-peer communication.

From the outline above it can be conc1uded that three issues are involved with each layer entity:o The service. The set of services the layer offers to the user. The specification of all servicesprovided by a layer constitutes a layer service definition. The (N)-user may not always requirethe use of all services provided by the layer underneath. The service elements of a layer areusually arranged in a number offunctional units (FU). The (N)-user may now select the set ofservices it needs by requesting the appropriate FU.

o The protocol. All services are executed according 10 the rules of the protocol specijication.A control message assembIed for exchange with a peer entity is known as a Protocol Data Unit(PDU). The part of the protocol which is concerned with realizing a particular service is calleda service element.

o Use of services. The services provided by its subordinate layer and used to carry out theservices which it provides.

2.2.2 InteractIen between Adjacent Entities

The preceding paragraph explained how a virtually direct communication is established betweenpeers. It was outlined how to achieve this objective through requesting service from the subordinatelayer. This section will explain how this is realized.

CHAPTER 2. AN INTRODUCTION TO THE OSI REFERENCE MODEL 8

When a layer wants service from a lower layer, it must identify which service. For this purpose OSIhas supplied service primitives. Each service element has a set of associated service primitives. Ifa (N)-user requests service from a certain service element it must do so by issueing the relatedprimitiv. If necessary the (N)-user can inc1ude a PDU as 'user data', which is to be conveyed toits peer. In the (N)-entity this 'user data' is known as Service Data Unit (SDU).

The part of an entity that generates and decodes PDUs, interprets events in relation 10 activities andpolices the mIes defined in the protocol specification is known as a Protocol Machine (PM). Whenthe (N)-entity receives a request for service through a primitive, the PM constructs its own ProtocolControllnformation (PCI) and adds this to the received SDU. Together these constitute a newPDU.

As described in the previous paragraphs, this process repeats itself down the stack. As theassembIed data reaches the destination, the peer (N)-entity receives the exact PDU that was sent,strips the PCI and indicates to the (N)-user that a service has been perforrned, also forwarding theresidual SDU. The process of assembling data units is illustrated in figure 2,4.

(N+l)-layer

(N-l)-layer

Figure 2,4 Assembling OSI data units.

Besides already discussed data units, two more elements show up in the figure 2,4. The lnteifaceControllnformation (ICI) is needed to assist the lower layer in perforrning its function (eg. thenumber of bytes in the SDU), but is no part of the SDU itself. The lnteiface Data Unit (IDU)merely identifies a unit passing the border between two layers.

2.2.3 Accesslng Entltles

Services are available through Service Access Points (SAP). Each (N)-entity has a (N)-SAP andeach (N)-SAP has an address, that uniquely indentifies it. An (N)-user can only access the serviceprovided by an entity by addressing the right (N)-SAP. It is apparent that (N)-SAPs are located atthe boundary between the (N)-user and (N)-entity.

CHAPTER 2. AN lNTRODUCTlON TO THE OSl REFERENCE MODEL

2.2.4 Service Prlmitives

9

Finally, primitives must be elaborated upon. It has already been mentioned that each serviceelement has a set of service primitives associated. So far these inc1uded:

o request service primitiveo indication service primitive

The request primitive is issued by the (N)-user. The (N)-entity responds by creating a POU tocommunicate with its peer entity. Finally, this results in the issuance of an indication primitive tothe (N)-user. It seems that with the last action, the process is completed. However, sometimes theperformed service is critical and the initiating (N)-user must be notified of the success or failureof the desired operation, ie. conjirmed service as opposed to unconfirmed service. Two additionalprimitives have been added to facilitate this requirement:

o response service primitiveo confirm service primitive

The (N)-user at the destination end-system now sends a response primitive with associatedparameters to the (N)-entity. Next, the (N)-entity on the destination end-system constructs a POU.The (N)-entity at the source end-system receives the POU and issues a confirm primitive to the (N)user.

It appears that service elements have either two or four primitives in their set depending on whetherthe service is unconfirmed or confirmed. Some service elements however have only one primitive,the indication primitive. This service indicates that an error has occured in one of the lower layers,an (N)-service provider. Because there is no user initiating a service, there is no request primitive.All different service primitive suits belonging to the various layers are treated in the coinciding OSIstandards.

2.3 Summary

This chapter dwelled on the basic aspects of the OSI reference model. Much terminology waspresented and the construction of the reference model was shown.The purpose of the seven layers has been c1arified, with emphasis put on the higher layers. Thepresentation layer, which is of primary importance in this thesis, implements a protocol which atall times preserves the meaning of transmitted data.Peer-to-peer communication is the principal mechanism used to accomplish this task. The protocolrules and definitions are also known as the protocol machine. Protocol information is communicatedthrough POUs.The functionality presented by a layer is defined in terms of services. Each service is madeaccessible with service primitives, identifying a specific service. Service may be confirmed(handshake) or unconfirmed.

3Overview of The Presentation LayerThe presentation layer has suffered a long history of uncertainty about its function [Cane87]. Whenthis layer was first conceived it was merely thought of as a simple device used to perform thenecessary conversions permitting ASCII systems to communicate with EBCDIC systems. Later itevolved to a layer that should permit visually-oriented programs, like full-screen editors, to operatewith a variety of terminals. Finally, all tasks relating to representation of data during transit wereassigned to the presentation layer. These include representation, encryption and compression.

Unlike the lower five layers which deal with connection management and transmit raw bitsregardless of their meaning, the presentation layer is concemed with just that. It provides a commonrepresentation for application information while it is in transit between peer application processes.This way the receiving end-system can reconstruct the information regardless of the localrepresentation at the transmitting end-system. Of course both end-systems must understand thecommon representation. It follows that with each transfer of information, three representations andtwo conversions are involved:

local representation of application information at transmitting end-systemJ,

commonly understood representation while in transitJ,

local representation of application infoffilation at receiving end-system

The unit of data handled by the presentation layer is referred to as an information unit. Thepresentation layer is merely concemed with representation of information units and not with anyrelationship between them. That task is left to the application processes themselves.

In order for an application process to communicate, it must first convey the type of information sentto the presentation layer. In other words, it must notify the presentation layer of the syntax of theinformation unit, eg. a record structure. The information unit's structure is formally defined by theabstract syntax. 'Abstract' identifies that it is not related to any actual implementation-dependentstorage facility, eg. 'integer' does not refer to 16 or 32 bit storage.Examples of abstract syntaxes are:

10

o integero sequence of characterso integer followed by sequence of characters

The last example shows that more complex abstract syntaxes can he built from 'primitive' syntaxes.The information unit denoted by the last example consists of two elements, each of which arelogically indivisable. Such elements are named presentation data values. Generally, an abstractsyntax defines a set of one or more presentation data values.ISO has developed and standardized a formal method of defining abstract syntaxes, called AbstractSyntax Notation I (ASN.I) [X.208].

Given that both presentation layers know the abstact syntax of the information unit, they need amethod to de/encode the unit for transmission. The transfer syntax defines the common encodingof information units in transit. The transfer syntax must convey encoding for all elements of theabstract syntax.

The local encodings of the abstract syntax depend on the different end-systems. For example:An information unit, descrihed by an abstract syntax as 'integer', contains value 1. The transmittingend-system may locally encode and store integers in Big-endian format. The receiving end-systemuses a Little-endian format for integers. Transmission therefore involves conversion from Bigendian at the transmitter to the transfer syntax and decoding to Little-endian at the receiver. Theencoding of the transfer syntax may he in either one of these forms or some other form.

From the example one can draw the condusion that more transfer syntaxes may he associated withan abstract syntax. Vice versa, more abstract syntaxes may he encoded by one transfer syntax. Todistinguish different abstract syntaxes and transfer different syntaxes, both can he assignedidentifiers, the abstract syntax name and transfer syntax name.

It is cmcial that both end-systems know which abstract and transfer syntaxes are associated withan information unit. Additionally, only one combination of syntaxes can he active on an informationunit at a time. This pairing of an abstract syntax with a transfer syntax is known as a presentationcontext.There is a standard for encoding mIes as weIl, commonly known as BER [X.209]. Both syntaxeswill he expanded upon in chapter 4.

3.1 Implementing Syntaxes

The introduction explained the purpose of the presentation layer and thus basically whatfunctionality it must implement. This fairly theoretical treatise is now linked to a more practicalviewpoint in the next sections. Thereafter focus will he directed to how the functions are madeavailable to the application layer by means of services and primitives.

3.1.1 The Defined Context Set

During the course of a given presentation connection, the abstract and/or transfer syntaxes used mayvary in order to support changing presentational needs. This property of the average connectiongives rise to the definition of a Defined Context Set (DCS), which constantly reflects abstract andtransfer syntaxes currently used by a connection to encode user data.

11

CHAPTER 3. OVERVIEW OF THE PRESENTATION LAYER 12

The DCS is maintained by both the transmitter and receiver and may be negotiated by services tobe explained below. It contains pairings of an abstract syntax name together with an associatedtransfer syntax name. To facilitate identification the presentation contexts are distinguished by socalled context identifiers.

In the following paragraphs it will become evident that the DCS plays a key role in serviceprovision and that many services are enhanced to ensure proper maintenance of the DCS.

3.1.2 The Default Context Set

The previous paragraph may have led to an impression that user data is always encoded using thepresentation contexts in the DCS. However, there are some exceptions. User data contained inexpedited data transfers is always encoded using the default context set. User data is also encodedaccording to the default context, regardless of the service, if at any point in time the DCS is empty.

In contrast to the DCS the default context set only contains one presentation context. Also, thedefault context cannot be renegotiated after connection establishment whereas the DCS can benegotiated at any time.

3.1.3 Functional Units

A presentation layer entity can principally be divided in two sets of services. The first set relatesto provision of the representational services and involves peer-to-peer communication. The setcontains four types of services which include:

o Connection establishmento Connection releaseo Context managemento Information transfer

They are arranged in three functional units (FUs):o The first two and last item constitute the kemel FU. The kemel FU is critical to theimplementation of the presentation layer and is therefore always automatically selected. Itpermits transfer of user data in accordance with the DCS defined at connection establishment.

o The context management service may optionally be employed by selecting the contextmanagement (CM) FU. This functional unit permits the user to add or delete presentationcontexts to/from the DCS at any moment during a connection.

o The context restoration (CR) FU is optional with the restraint that the CR FU can only beselected together with the CM FU. The CR FU is important with regard to the behavior of thesecond set of services listed below. Basically, it allows restoration of a DCS to contents definedearlier during the connection.

The second suit provides a mechanism for the application layer to access the services of the sessionlayer by acting as a gateway. This usually does not entail any exchange of PPDU's. Thepresentation layer merely maps the (p)-service primitive to the same (S)-service primitive and doessome housekeeping. These 'presentation services' include:

o Activity managemento Exception reporting

CHAPTER 3. OVERVIEW OF THE PRESENTATION LAYER

o Synchronizationo Resynchonizationo Token management

3.2 Presentatien layer services

13

Table 3,1 shows the primitives associated with the first set of services. They can all directly controland/or influence the performance of the presentation layer. The following sections will explain eachservice in detail. Appendix A offers complete lists of parameters and their use for each service.

Table 3,1 Presentation service primitives.

Service

Connection establishment

Connection release

Information transfer

Context management

Service primitives

P-CONNECT

P-RELEASE

P-U-ABORT (U = user)

P-P-ABORT (P = provider)

P-DATA

P-TYPED-DATA

P-EXPEDlTED-DATA

P-CAPABILITY-DATA

P-ALTER-CONTEXT

Type

confirmed

confirmed

unconfirmed

indication only

unconfirmed

unconfirmed

unconfirmed

unconfirmed

confirmed

3.2.1 Connection Establishment

Table 3,1 shows which primitives are involved in setting up a connection. The negative and positiveresponse primitives refer 10 a specific parameter which will he explained later in this section.

Table 3,2 Connection establishment service.

P-primitive ~

P-Connect.request

P-Connect.response

P-Connect.response+

S-primitive ~

S-Connect.req/ind

S-Connect.resp/conf

S-Connect.resp/conf

P-primitive

P-Connectindication

P-Connect.confirm

P-Connect.confirm

The connection establishment procedure is initiated by the application layer which issues a PCONNECT request. The procedure involves the exchange of two different sets of parameters.

The first set consists of parameters which are mapped straight to the S-CONNECT primitive, sincethe presentation layer cannot exchange PPDUs with a peer without a prior established sessionconnection setup by the session layer. These parameters therefore are necessary for the applicationlayer to indirectly control the session connection and have little meaning to the presentation layer.The parameters are as follows:

CHAPTER 3. OVERVIEW OF THE PRESENTATION LAYER

Quality of serviceInitial synchronization point serial numherInitial assignment of tokensSession connection identifier

14

Alternatively, the second set of parameters are concerned with setting up the presentation layerconnection, these parameters are important with regard to the connection establishment procedureand will return in chapter 5 when the protocol machine is discussed:

o The Calling and Called Presentation Address are both PSAP addresses. The CalledPresentation Address is mapped by the presentation layer to obtain a Called Session Addressidentifying the SSAP to which the supporting session connection must he established. TheResponding Session Address is returned on the response and confirm, only if a PSAP addressother than the Called Presentation Address should he used to re-establish a presentationconnection.

o The Presentation Context Dejïnition List is optional and lists of one or more items, each ofwhich consists of a context identifier and an abstract syntax name. The context identifiers aredetermined by the initiator and are used in all further references to presentation contexts. Thisparameter appears on the request and indication.

o The Presentation Context Dejïnition Result List is only present when the previous parameteris inc1uded. It is a list denoting the acceptance or rejection of each entry proposed in thePresentation Context Definition List. Each value represents either 'acceptance', 'user-rejection' ,or 'provider-rejection'. This parameter only appears on the response and confirm.

o The optional Default Context Name identifies the default context set to he used. Thisparameter is optional, however, if it is not present some a-priori agreement is assumed. Theresponse is embodied in the Default Context Result. Rejection of the default context proposedresults in termination of the connection.

o The Mode parameter may take the value 'normal' or 'X.41O(l984)'. The latter mode isimplemented to establish compatibility with ccn! X.400 protocol-based messaging systems.This mode highly restricts presentation encoding which leads to the absence of presentationcontexts.

o The Presentation Requirements parameter enables negotiation of optional functional unitsprovided by the presentation layer.

o In User Session Requirements the (p)-user may convey its demands for session layer FUs.This parameter does not have any immediate hearing to the presentation layer, but is importantwith respect to the typed data FU provided by the session layer.

o User Data is incorporated when the initiator wants to convey data to its peer. Since this isinformation that originates from above the application layer it is subject to representationalconversion. It is encoded using the Presentation Context Definition List if present, otherwisethe default context is used. This parameter may appear by (p)-user option on therequest/indication and response/confirm. If either (p)-user or (P)-provider do not support theutilized presentation context the connection may he terminated or the user data may he ignored.


o The Result parameter is only inc1uded in the response and confinn primitives. It denotes theresult of the connection establishment procedure tak.ing the values of 'acceptable', 'userrejection' or 'provider-rejection'. The contents of the parameter lead to transmission of eitheran aclrnowledge of reject PDU.

The connection establishment procedure inc1udes a host of parameters. An elaborate treatment ofthese parameters is beyond the scope of this paper and the interested reader is recommended torefer to the appropriate standards. The parameters discussed above provide insight into the issuesrelevant to establishment of a connection between two end-systems. However, explanation of theparameters concerned does not reveal their interaction in tenns of the negotiation of the DefinedContext Set, Default Context Set and functionality. This topic will be discussed in chapter 5.

3.2.2 ConnectIon Release

Connection release can be eithernon-destructive with the P-RELEASE primitive or destructive withP-U-ABORT or P-P-ABORT. Destructive means that any infonnation still in transit may be lost.Table 3,3 lists all primitives and the order in which they are used to complete a tennination service.

Table 3,3 Connection release service.

P-primitive ~ S-primitive ~ P-primitive

P-Release.request S-Release.req/ind P-Release.response

P-Release.response S-Release.resp/conf P-Release.confinn

P-User-Abort.request S-User-Abort.req/ind P-User-Abort.indication

P-Provider-Abort.request S-User-Abort.req/ind P-Provider-Abort.ind

S-Provider-Abort.ind P-Provider-Abort.ind

The P-RELEASE primitive does not thoroughly involve the presentation layer. The connection isreleased as a result of the tennination of the session connection undemeath. The presentation layermerely passes a P-RELEASE on to aS-RELEASE primitive in the session layer. Therefore, thereis no peer-to-peer communication involved.

3.2.3 Context Management

If at connection establishment the Context management FU is selected, the presentation layerprovides a service to add or delete contexts from the DCS. This service must be invoked with theP-ALTER-CONTEXT primitive. It is a confinned service since negotiation is involved (tabIe 3,4)and uses the following parameters:

o The Presentation Context Addition List and Presentation Context Addition Result List aresimilar to the corresponding parameters in the P-CONNECT primitives. In this case howeverthe parameters pertain to addition of contexts, which is negotiated between the two end-systems.

o The (p)-user may employ the Presentation Context Deletion List to convey a list of one ormore context identifiers, which is to be deleted from the DCS. Subsequently, the peer (p)-userreturns a response in the Presentation Context Deletion Result List.


o The optional User Data must confonn to certain mIes depending on the phase of theprocedure. The request/indication primitives require user data to confonn to the DCS as itappeared before the ALTER-CONTEXT.request primitive was issued. User Data inresponse/confinn primitives must confonn to the new updated DCS. Ifeither DCS is empty, thedefault context is applied.

Table 3,4 Context management service.

P-primitive ~

P-Alter-Context.request

P-Alter-Context.response

3.2.4 InformatIon Transfer

S-primitive ~

S-Typed-Data.req/ind

S-Typed-Data.req/ind

P-primitive

P-Alter-Context.indication

P-Alter-Context.confinn

User infonnation may be transferred as User Data parameter in almost any service primitive.However, there are several special service primitives dedicated to the transferral of user infonnation.Four of these services exist. Only one of them may be issued by the (P)-provider on its initiative,P-TYPED-DATA. The others are invoked by the (p)-user. The primitives are arranged in table 3,5.P-DATA contains one parameter, User Data. It is subject to representational conversion usingwhichever presentation context is contained in the DCS.

The P-TYPED-DATA primitive contains the same single User Data parameter which is encodedaccording to the DCS. The P-TYPED-DATA service is a special service which allows the exchangeof data against the current setting of the token. This functionality is only available when the typeddata FU has been selected in User session requirements during the connection establishmentprocedure. If not selected, it acts as the regular P-DATA service.

Figure 3,S Infonnation transfer services.

P-primitive ~

P-Data.request

P-Typed-Data.request

P-Expedited-Data.request

P-Capability-Data.request

P-Capability-Data.response

S-primitive ~ P-primitive

S-Data.req/ind P-Data.indication

S-Typed-Data.req/ind P-Typed-Data.indication

S-Expedited-Data.req/ind P-Expedited-Data.indication

S-Capability-Data.req/ind P-Capability-Data.indication

S-Capability-Data.resp/conf P-Capability-Data.confinn

P-EXPEDlTED-DATA offers a User Data parameter which is always encoded according to thedefault context. Expedited data is a special type of data. It is guaranteed to arrive at the destinationbefore any subsequently issued primitive. This implies that successive expedited data SDU aredelivered to the receiving end-system in the same sequence in which they were issued by thetransmitter. Expedited data is requested by the application layer -- the presentation layer merelyconveys it to the session layer. The amount of data is bound 10 a maximum of 14 octets.

CHAPTER 3. OVERVIEW OF THE PRESENTATJON LAYER 17

Finally, the P-CAPABILITY-DATA offers the only confirrned data transfer service. The User Dataparameter is inc1uded. It is another service basically implemented by the session layer. It allowslimited amounts of data ( 65539 octets max) to be transmitted outside activities (discussed later).User Data encoding complies with the contents of DCS.

3.3 Session Layer Services

Figure 3,6 Session service primitives.

Service

Synchronization

Resynchronization

Token Management

Activity Management

Exception Management

Service primitives

P-SYNC-MINOR

P-SYNC-MAJOR

P-RESYNCHRONIZE

P-TOKEN-GIVE

P-TOKEN-PLEASE

P-CONTROL-GIVE

P-ACTIVITY-START

P-ACTIVITY-END

P-ACTIVITY-INTERRUPT

P-ACTIVITY-RESTART

P-ACTIVITY-DISCARD

P-U-EXCEPTION-REPORT

P-P-EXCEPTION-REPORT

Type

confirrned

confirrned

confirrned

unconfirrned

unconfirrned

unconfirrned

unconfirrned

confirrned

confirrned

unconfirrned

confirrned

unconfirrned

indication

The other set of presentation services which has not been expanded upon yet relates to the 'bridge'function of the presentation layer. Their primary objective is to make specific session servicesavailable to the application layer. Table 3,6 lists the service primitives involved and their attributes.

Usually these services do not bear any consequences and they are directly mapped onto theirrespective session layer primitives. However, if the CR FU (Context Restoration Functional Unit)has been selected during connection establishment, certain administrative actions must be realized.Each upcoming sections will explain one specific session service and the impact it has on thebehaviour of the presentation layer. Appendix A contains lists with relevant parameters and theirusage for each of the successive services.

3.3.1 Synchronization

The synchronization service basically provides a mechanism for the application layer 10 set certainmarkers during the course of a connection. These markers, after confirrnation, ensure that all dataare transferred successfully. In the event of an error, the transmission only has to be restored to thelast synchronization point. Then the transfer can be picked up again.Since the presentation layer is only concerned with data conversion these markers do not have anyimpact on the functionality of this layer. However, this changes when the optional CR FU isselected. Now the presentation-user may change the DCS at any moment during a connection. TheCR FU instructs the protocol machine not only to restore the connection to the last sync point, but


to also restore the DCS to its original settings. Consequently the DCS must be preserved whenevera synchronization point is set in order to be able to completely reconstruct the status of theconnection. Many individual sync points can be established during a connection.

The P-SYNC-MINOR primitive defines a new sync point. If the CR FU is active, the sync pointis tied 10 the current DCS. Three parameters are used, two of which are important for thepresentation layer. The first parameter, Synchronization Point Serial Number is the number of thesync point to be set. The second parameter is User Data. The two parameters appear on both therequest/indication and response/confirm.

Where the first primitive simply added a new sync point, the P-SYNC-MAJOR primitive replacesall previously defined sync points by a single new one. lts two parameters are the same as listedpreviously, with the exception that the Synchronization point serial number only appears on therequest/indication.

3.3.2 Resynchronization

Synchronization can be extremely valuable, especially during long sequences of data transfer. ltsusefulness however can only be achieved with one added service. The resynchronization serviceallows the user to restore a connection to a sync point. This is also the first service where the CRFU (when selected) can be really brought into gear.

Table 3,7 Resynchronization service.

P-primitive ~

P-Resynchronize.request

P-Resynchronize.response

S-primitive ~

S-Resynchronize.req/ind

S-Resynchronize.req/ind

P-primitive

P-Resynchronize.indication

P-Resynchronize.confirm

The primitive involved is P-RESYNCHRONIZATION (tabie 3,7). Since resynchronization is a (S)service, its parameters are identical to those of the S-RESYNCHRONlZE, except for thePresentation Context ldentification List parameter, present only on the indication and confirmprimitives. Each item in this list is a context identifier. The list indicates to the (P)-users thecontents of the resulting DCS after completion of the resynchronization procedure at an end-system.

The specific behaviorofthe P-RESYNCHRONIZATION primitive mainly depends on the selectedfunctional units. Note that this also inc1udes the CM FU (Context Management). Individualresynchronization requests can also be influenced by the different types, which can be assigned bythe Resynchronize Type parameter appearing on both request and indication and containing either'abandon', 'restart' or 'set'. Resynchronization has no impact on the presentation layer, only whenno optional functional units have been selected.

Figure 3, I illustrates how a resynchronization procedure can be activated. The sync point is firstset with the P-SYNC-MAJOR primitive. Following P-SYNC-MAJOR, the DCS is adjusted usingthe ALTER-CONTEXT service. Finally, resynchronization restores the DCS to its original contents.

Obviously, P-RESYNCHRONlZE is rather complex. lts operation depends completelyon the FUsand the resynchronize type. All primitives contain a Synchronization Point Serial Number definingwhich DCS to restore. AIso, Tokens and User Data parameters may be incorporated as determinedby the (p)-users.


P-RESYNCHRONIZE.indicatîon(restart,3)

P-ALTER-CONTEXT.request

P-SYNC-MAJOR.indication(2)P-SYNC-MAJOR.response..................

...............................

..........

P-SYNC-MAJOR.confirm

P-ALTER-CONTEXT.responseDCS = S2 .

P-RESYNCHRONIZE.requesl(restarl,3)

DCS = S1 .P-SYNC-MAJOR.request(2) ........................

P-ALTER-CONTEXT.indication

P-ALTER-CONTEXT.response

P-RESYNCHRONIZE.confîrm(reslarl,3)

P-RESYNCHRONIZE.response(restart,3)

DCS = S1 .

Note: P-SYNC-MAJOR carries Synchronizatîon Point Serial NumberP-RESYNCHRONIZE carries Resynchronize Type as weIl

Figure 3,1 Restoration of the Defined Context Set.

3.3.3 Token Management

Token management is the purest form of the 'liaison' function of the presentation layer. Besideschecking and converting the optional 'user data' in the applicable primitive parameters, thepresentation layer is constrained to merely forwarding them to the corresponding session primitiveparameters. Table 3,8 lists what which these services are.

Table 3,8 Token management services.

P-primitive ~ S-primitive ~ P-primitive

P-Token-Give.request

P-Token-Please.request

P-Control-Give.request

S-Token-Give.req/ind

S-Token-Please.req/ind

S-Control-Give. req/ind

P-Token-Give.indication

P-Token-Please.indication

P-Control-Give.indication

The parameters and their contents are not relevant to the presentation layer and will therefore heomitted from this discussion.

3.3.4 Actlvlty Management and Exceptlon Reportlng

Activity management is a service provided by the session layer and enables its user to organize itswork by defining activities. During the course of a connection these activities may interrupted,restarted, discarded (aborted) or ended. New activities may he initiated at any time when noactivities are in progress.


This piece of functionality delivered by the session layer can only be invoked by the applicationlayer and there the 'bridge' function of layer 6 again becomes evident.The behavior of the presentation layer regarding activity management bears much resemblence tosynchronization/resynchronization procedures. The 'bridge' function does not impose any effectsupon management of the presentation services, unless the CR FU is selected. In that case a complexadministration must enhance the presentation layer to assure preservation of the correct context sets.Fortunately, the administration is limited to keeping track of sync points and linking them to theproper activities and remembering the DeS at these moments. The presentation layer must alsoremember the DeS before or between activities to facilitate context restoration when the currentactivity is being put on hold, quit or ended. The latter set is referred to by the standards as interactivity DCS.

The standards are not entirely unambiguous about the requirements on the administration. Theystate that the inter-activity DeS must be saved, but they do not directly mention the fact that syncpoints must be linked to activities in order to restart an interrupted activity successfully. Obviouslythe last argument requires a significant enhancement of the administration of the DeS. Table 3,9lists the primitives implementing activity management.

Table 3,9 Activity management service.

P-primitive ~

P-Activity-Start.request

P-Activtiy-End.request

P-Activity-End.response

P-Activity-Interrupt.request

P-Activity-Interrupt.response

P-Activity-Restart.request

P-Activity-Discard.request

P-Activity-Discard.response

S-primitive ~ P-primitive

S-Activity-Start.req/ind P-Activity-Start.indication

S-Activity-End.req/ind P-Activity-End.indication

S-Activity-End.resp/conf P-Activity-End.confirm

S-Activity-Interrupt.req/ind P-Activity-Interruptind

S-Activity-Interrupt.resp/con P-Activity-Interrupt.confirm

S-Activity-Restart.req/ind P-Activity-Restart.ind

S-Activity-Discard.req/ind P-Activity-Discard.ind

S-Activity-Discard.resp/conf P-Activity-Discard.confirm

P-ACTIVITY-START:This primitive starts a new activity. It is an unconfirmed service with a few parameters, theActivity ldentifier and optionally, User Data. Starting an activity implies a number of actionsto be taken:

o Additions and deletions of presentation contexts are localized within the activity and arevalid as long as the activity is not interrupted, ended or discarded.o Synchronization points will be tied to the activity and are valid as long as the activityis not interrupted, ended or discarded.

When an activity is initiated, the DeS is saved as the inter-activity DeS.

P-ACTIVITY-END:A non-destructive method to end an activity in progress is furnished by the P-ACTIVITY-ENDprimitive. It is a confirmed service containing a Synchronization Point Serial Number to be usedby the session layer on both request and indication and an optional User Data parameter.Selection of the CR FU implies that the inter-activity DeS is restored to its full glory and that


the current activity identifier is removed from the DCS administration together with all relatedsync points.

P-ACfIVITY-DISCARD:This is the destructive counterpart of the previous primitive. It is confirmed and communicatesone Reason parameter on request/indication. It is similar to ACfIVITY-END in other aspects.

P-ACfIVITY-INTERRUPT:This also destructive service contains the same parameters as ACfIVITY-DISCARD. However,instead of deleting, it merely interrupts an activity. Therefore, it implies the same actions as theprevious two primitives except that the current activity identifier is not eliminated.

P-ACfIVITY-RESUME:The most intricate primitive restarts an interrupted activity. It is an unconfirmed service andcarries a number of parameters. Important ones inc1ude Activity Identifier, üld ActivityIdentifier, Synchronization Point Serial Number and User Data.Selection of the CR FU may effect the DCS as follows:

o Ifthe üld Activity Identifier designates an interrupted activity, then the DCS is restoredaccording to the Synchronization Point Serial Number and all higher sync points aredeleted.o If the synchronization point serial number isn't specified in the administration, then theDCS is unchanged.

Figure 3,2 presents an example of activity management. It illustrates how the DCS evolves overa sequence of primitives. Note that the synchronization point (minor) is localized to the currentactivity.

DCS = Sl, IA-DCS = SO

Activity Start

DCS = Sl, IA-DCS = SI

Context Alteration

Minor Synchronization

Context Alteration

Aetivity End

DCS = S3, IA-DCS = S3

Activity Resume

Activity Interrupt

Connection Establishment

DCS = SO, IA-DCS = SO

Context Alteration

DCS = S2, IA-DCS = S3.................

.- .

...........

.......... DCS = S3, IA-DCS = S3

Note: IA-DCS is Inter-Activity Defined Context Set

Figure 3,2 Influence activity management services on DCS.


The last segment of selVice to he elaborated upon is exception management. As far as thepresentation layer is concerned, its support is comparable to the token management primitives.Briefly, the selVice involves reporting protocol errors in the session protocol machine. As expected,it follows that exception management is another typical session selVice.

3.4 Summary

This chapter introduced the purpose of the presentation layer and which selVices it provides toachieves its functionality towards the application layer. The presentation selVice is such thatapplication entities may transfer their information without concern about how the information musthe presented to preselVe its meaning. The (P)-provider is responsible for encoding/decoding theinformation, using a set of presentation contexts collected in the DeS. The presentation layer is alsoresponsibIe for maintaining the Des over a connection.

4Abstract Syntax and Transfer Syntax

The presentation layer transfers infonnation units to its peer as User Data. Encoding complies withthe presentation contexts as defined in the DCS. In the previous chapter, presentation contexts wereexplained to consist of two principal elements: the abstract syntax and transfer syntax. User dataconveyed to the presentation layer always confonn to the priorly negotiated set of abstract syntaxes.Encoding takes place according to the appropriate transfer syntax, which is linked to each abstractsyntax. This chapter will attempt to provide a more practical view on the use of abstract andtransfer syntaxes to convey user infonnation.

The Abstract Syntax Notation I has been mentioned as a fonnal method to describe an arbitrarydata structure. This structure is assigned an abstract syntax name. An example of such a datastructure could be the following ( for now the structure is denoted using Pascal):

type EmployeeName = recordName: string;Address: string;Male: boolean;

end;

type EmployeeData = recordPersonal: EmployeeName;IdNumber: integer;Position: string;

end;

Let's assume 'EmployeeData' will be the abstract syntax name referring to this data structure. Whena connection is being established, the application layer can communicate the wish to transmitemployee records by submitting a Presentation Context Identifier List to the presentation layer,containing the abstract syntax name 'EmployeeData' representing the employee data structure. Next,the presentation layer links every transfer syntax which could be used to encode the abstract syntaxname, in this case 'EmployeeData' , in a proposal for a Defined Context Set.

23

CHAPTER 4. ABSTRACT SYNTAX AND TRANSFER SYNTAX 24

Explanation of the complete negotiation procedure will be procrastinated until the next chapter.However, the result of negotiation is that ultimately the DeS at both end-systems contains'EmployeeData' with an appropriate transfer syntax name associated. Note that the transfer syntaxdoes not pertain to a structure but to a genera! method of encoding.

Upon information transfer the application layer passes the information to the presentation layertogether with the presentation context identifier. The presentation layer recognizes the latter asbelonging to the structure of 'EmployeeData' and thus knows how to encode the data. At thereceiving end, the exact opposite action occurs. The receiver identifies the data by the the includedtag (explained later). Next, the data is decoded to the local format and forwarded to the applicationlayer with the presentation context identifier.

The next paragraphs elaborate on the description of data structures using ASN.l and the transfersyntax BER which have already been defined by ISO. ISO recognizes that in the future moreabstract and transfer syntaxes may become available. The need for these arises when one considersthat different applicatations may demand very different primitive elements and constructiontechniques. For example, graphics information might be expressed in points, colours, line markingsetc. while construction mechanisms like infill, invert, rotation etc. might be used to assembiepictures. Obviously, this example bears litt1e similarities with the 'EmployeeData' example holdingintegers and characters.

4.1 Abstract Syntax Notation 1

The complete definition of ASN.l is incorporated in the eenT Blue Books X.208, which is arewritten version of the XA09 [XA09] standard, originaHy developed byeenT in order to definethe fairly complex datastructures transferred as part of their message-handling systems [Pope84].It is the first of a series of abstract syntax notations.

ASN.I is a formal language providing flexible statements to define a data structure in terms oftypes and values. Emphasis is put on flexibility although future abstract syntaxes may support aneven larger number of specific data structures eg. B-trees.

Basically, each elementary piece of information consists of a type and a va/ue. The type may benumeric, character etc. The value is an instance of the type in question, eg. a number is a value oftype numeric. The basic building blocks of ASN.l are primitive types. They identify elementaryinformation pieces. Subsequently, these can be combined using constructors. In the next section,a brief review of ASN.I is presented explaining this and more. For a fuH treatise the reader isreferred to the eenT Blue Book recommendations X.208, appendix 11 [X.208].

4.1.1 ASN.1 Types

The primitive types, also referred to as simple types, describe the nature of presentation data values.The can be combined to construct more complex types. ASN.l defines a large set of primitive datatypes which can be used.

o INTEGER: Identifies a signed integer of arbitrary size.o BOOLEAN: Classifies value as logical ( 'true' or 'false' ).o BIT STRING: This is a string of 0 or more bits.o OCfET STRING: Also a string but now containing 0 or more bytes.


o REAL: Identifies a floating point number with binary or decimal base including +00 and -00.o ANY: Denotes a union of all types. It can later be substituted by any type.o NULL: No type at all. It represents an empty value.o OBJECf IDENTIFIER: Intemally identifies an abstract syntax to be used by an application.o OBJECf DESCRIPfOR: Brief human-readable description identifying an abstract syntax.o ENCRYPfED: Classification as the encrypted version of another type.o ENUMERATED: Pertains to a set of integers. Each integer denotes a distinct object.

These primitive types do not provide sufficient means to describe more complex data structures likethe 'EmployeeData' example. To realize that requirement structured types are introduced. They arealso known as constructors and they allow two or more primitive types to be combined in variousmanners in order to form a new type. The available constructors are:

o SEQUENCE: Combines a collection of types. Any type is allowed, inc1uding constructedtypes. It is comparable to the record structure in Pascal.o SEQUENCE OF: Builds (unbounded) arrays of one type. Any type is allowed includingconstructed types to build arrays of data structures.o SET: This constructor is similar to SEQUENCE except that the order of the components isnot guaranteed to be maintained during transit.o SET OF: Again this constructor is unordered version of SEQUENCE OF.o CHOlCE: Identifies a list of possible types. Upon transmission the value may be of any ofthe types contained in the list. It is similar 10 the 'union' structure in C.o EXTERNAL: Allows an abstract syntax to refer to an element in another abstract syntaxwithout having to inc1ude the latter.

Finally, sometimes fields may be optional. To handle this situation, ASN.l allows fields 10 bedeclared as such with the keyword OPTIONAL. Altematively, a field can be declared DEFAULTfollowed by the value to be used by the receiver if the particu1ar data field is not transmitted.Use of the OPTIONAL clause may lead to anlbiguity regarding the fields in the data structure. Thiswill be demonstrated in an example in the next section.

Given the presented primitive types and constructors, the 'EmployeeData' abstract syntax can nowbe rewritten as follows:

EmployeeData ::=

EmployeeName ::=

SEQUENCE{PersonalIdNumberPosition}

SET{NameAdressmale}

EmployeeNameINTEGER OPTIONALSTRING OPTIONAL

OCTET STRINGOCTET STRINGBOOLEAN DEFAULT TRUE

CHAPTER 4. ABSTRACT SYNTAX AND TRANSFER SYNTAX

4.1.2 Character String Types

26

ISO has standardized some useful character string types which are commonly used. Eight of thesetypes pertain 10 different subsets of OcrnT STRING. They are specialized for specific applications.Additionally, two types define different time formats:

o NumericString: Contains digits and spaces.o PrintableString: Excludes all non-printable characters, leaving upper and lower case letters,digits and eleven characters O'+-..I:=?o TeletexString: Teletex character set.o VideotexString: Videotext charater set.o VisibleString: Printing characters from the ASCII set.o IA5String: ASCII character and carriage controls.o GraphicString: Contains various international versions of ASCII ( eg. chinese). setso GeneralString: Superset of GraphicsString with control characters.o GeneralizedTime: Represents time in notation YYYYMMDDhhmmss.o UniversalTime: Represents time in notation YYMMDDhhmm.

4.1.3 Tagging

A datastructure is defined by primitive types and constructors. In the previous sections they weregiven names like INTEGER and SEQUENCE. When a value is transmitted, its type iscommunicated also. However, sending the type by its name in characters is not likely to be veryeffective. Therefore tagging is introduced. The type is established as a code, thus identifying thevalue. A type field is also called a tag. Tags are always enclosed in brackets. The four differentclasses of tags defined in ASN.l are:

o UNIVERSAL: This kind of tag is a general identifier used for the reserved primitive types,character string types, and constructors defined in ASN.l. They are integer numbers, eachuniquely identifying the transmitted type or constructor. The assignments can be found in theASN.l standards.

o context specific: At reception of User Data it might not always be clear with which fields inthe datastructure values are associated. This can be illustrated with the following example.Consider an abstract syntax with a structure:Numbers ::= SEQUENCE

{valuel INTEGER OPTIONALvalue2 INTEGER OPTIONALvalue3 INTEGER OPTIONALvalue4 INTEGER OPTIONAL}

Next, assurne that only two values are transmitted. How can the receiver discern which valuesthey are? This potential problem is resolved by adding a context specific tag to identify thespecific fields. Since this tag designates the position of the field in the datastructure, it followsthat the UNIVERSAL tag is superfluous. The UNIVERSAL tag can be classified as dismissedby adding the word IMPLICIT. If IMPLICIT is omitted both tags are transmitted:


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

27

o APPLICATION: This tag can be added by OSI application layer protocols to denote typesused in those protocols.

o PRIVATE: This c1ass of tag may be implemented by the user.

With this information 'EmployeeData' can be further enhanced. This leads to the followingdefinition:

[0] IMPLICIT EmployeeName[1] IMPLICIT INTEGER OPTIONAL[2] IMPLICIT STRING OPTIONAL

OCTET STRINGOCTET STRINGBOOLEAN DEFAULT TRUE

EmployeeData ::=

EmployeeName ::=

[APPLICATION 0] IMPLICIT SEQUENCE{PersonalIdNumberPosition}

[APLLICATION 1] IMPLICIT SET{NameAdressmale}

When the destination receives presentation data values it determines their nature by the tags. In thiscase the data is perceived as 'EmployeeData' data by [APPLICATION 0] tag. The APPLICATIONtag is used because it is assumed that the abstract syntax name is application specific. The tag ofSEQUENCE and SET can be IMPLICIT since both transmitter and receiver know the structure ofthe 'EmployeeData' abstract syntax. Some of the data fields within 'EmployeeData' have beenidentified by context specific tags. Therefore, they are defined as IMPLICIT to exc1udeUNIVERSAL tags.

4.2 The Transfer Syntax

When the presentation layer has attributed the information units to an abstract syntax, it is readyto perform the transformation using an associated transfer syntax. The latter will be the subject ofthe next sections. However, prior to entering upon the technical issues, it might be interesting torepeat the possible objectives of transfer syntaxes in general.

4.2.1 Practical ConsideratIons

Data representation has been described as the main accomplishment of a transfer syntax. Presently,only one transfer syntax has been standardized for ASN.1. The Basic Encoding Rules 1, defmed


in X.209, provide a flexible and universal encoding standard. The flexibility is expressed forexample in terms of the size of some types of presentation data values, which can be defined asindefinite. However, this introduces overhead which reduces efficiency.

Two considerations have led to design of other encoding schemes, increasing efficiency.First, the fact that BER requires a lot of processing power does not make it a favourable candidatefor high-speed networks. Eg. a lOOMbit/s network may receive 1 byte every 80ns maximum.However, 800s is the time a 25MHz 80386DX processor needs for a simple 32-bit memory fetch.Obviously, the system cannot afford to waist several dock cycles doing calculations or scanningfor the end of a data field. Simple experiments using software to encode arrays of integers,performed by [Huit89], showed that encoding introduced a delay of a factor 5 to 20 over directmemory copying.Secondly, in many applications the elaborate BER encoding options are excessive and can bereplaced by much less complex encoding methods.Faster transfer syntaxes have been designed and tested in [Bess88] and [Huit89]. They are basedon two principles: Obsolete information is avoided in the encoding, and the use of fixedrepresentations is preferred when possible. Preliminary benchmarks have revealed a 25 to 2500times speed increase.

Besides data representation compression is another possible application. Usually, the cost of usinga network depends on the number of bytes sent. Often these costs rise linearly with the amount oftraffic. Compression techniques have been advocated for several years now as a means 10 reducesize. Better results in compression push technology to general acceptance, leading to applicationof these techniques to gain the benefits from saving valuable storage space to reducing transmitteddata. The advantages are substantial. Less bytes to be transmitted in less time, also relieving thenetwork.In general, data exhibits the following types of redundancy:

OCharacter distribution. In a typical character string, some characters are used morefrequently than others. In fact, these characters constitute approximately one quarter of theASCII set. Therefore, compression may concern a reduction of the number of bytes percharacter.oCharacter repetition. This may pertain to repeated characters in a character string, or asequence of zeros in a SET OF INTEGER construct.o High-usage patterns. Certain collections of successive characters will appear with relativelyhigh-frequence. This usually applies to character strings or sets.o Positional redundance. Certain sequences of characters appear consistently at a predictabIepIace in each block of data.

The compression method used must be weighed against the additional memory requirements andCPU consumption. Presently, no transfer syntaxes implementing compression are beingstandardized.

Finally, data encryption is commonly mentioned as a typical presentation layer task. Althoughencryption can he implemented in various layers, eg. the data link layer, the higher layers arepreferred for flexibility from the viewpoint of the user. Typically, encryption must ensure thatnobody besides the destination can read the information. The objectives can be extended topreventing anybody from deleting, inserting, or changing data, verifying the sender etcetera. Atpresent, data encryption is not incorporated in transfer syntaxes. However, at this moment someeffort is directed to implement safety measures and encryption at other layers.


4.2.2 Basic Encodlng Rules

The Basic Encoding Rules (BER) provide an algorithm that specifies how a value for any datastructure (type) defined using ASN.l is to he encoded for transmission. Use of the algorithm inreverse enables the receiver to decode the incoming bitstream into a value of that type. The transfersyntax is standardized in the ccnT blue hooks X.209 [X.209].

The BER standard employs a TLV structure (Type-Length-Value). Therefore, each presentation datavalue encoded is represented by the following elements:

o One or more octets define the type of the presentation data value. Typically, this will he atag of the UNIVERSAL class, but it may also he a context specific, APPLICATION, orPRIVATE tag.

o One or more octets describing the length of the value, or specifying an 'indefinite' length inwhich case the receiver must check for the end. The 'indefinite' length may he usefull whenthe length of value is not known until transmission. Obviously, the possibly indefinite 'Iength'field causes the inefficiency of BER.

o One or more octets identifying the value. For primitive types these values do not contain anyfurther structure. This changes when the type is a constructor, in which case the value itselfconstitutes a set of TLV components. The latter causes overhead and therefore reducesefficiency.

Figure 4,1 illustrates the structure of data elements sent. The contents of the type, length and valueoctets are sujected to stringent rules defined in X.209. For more information the reader isrecommended to refer to [X.209].

Data element

Identifier Lenglh Content~

(a) Single Element

Data element

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

Data element Data element

ldentWier Lenglh Contents 1lldentifier Length ldentWier Lenglh Contents

(b) Muhible Elements

Note (1) The IdentWier field is also called the type.Note (2) The Contents field is also called the value.

Figure 4,1 The X.209 Data Elements.


4.3 Summary

30

This chapter explained the process of data representation. The first step to be taken is the definitionof a data structure in terrns of an abstract syntax. The application layer then passes its data confonnto the established structure. ASN.1 was unveiled as a means 10 fonnally obtain a definition. ASN.1provides a collection of primitive types and constructors, allowing a large variety of data structuresto be depicted. In the future more abstract syntaxes are expected to become available.

The transfonnation of presentation data values from local to common fonnat is actually perfonnedaccording to the rules comprised in the transfer syntax. The only transfer syntax currentlystandardized is BER. BER implements a TLV fonnat encoding for data structures described inASN.l. Other transfer syntaxes may be developed focussing on efficiency, compression andencryption.

5The presentation protocol machine

The previous chapters have made c1ear that the core function of the presentation layer consists ofestablishing and maintaining a set of presentation contexts, according to which user information isencoded. This functionality is provided to the (p)-user, the application layer, and is made accessiblethrough invocation of specific primitives. These primitives consequently contain parameters whichare used to implement the service. Both service primitives and parameters have been described sofaro The actual implementation of the services in the shape of a protocol has yet to be elaborated.The collection of protocols which govem peer-to-peer communication is referred to as ProtocolMachine in general, and that will be the main subject in this chapter.

5.1 Introduction

The presentation protocol specifies, for a given presentation connection, the cause-effect relationshipbetween the issuance of Presentation service primitives at a given PSAP and the exchange ofPresentation Protocol Data Units (PPDU) between the two supporting Presentation ProtocolMachines (PPM).The protocol basically pertains to both core presentation services like P-ALTER-CONTEXT andservices which are provided by the session layer like resynchronization and activity management.

Usually (P)-services require peer-to-peer communication which amount to the exchange of PPDUs.The (p)-user may also initiate services which are provided by the session layer. The protocol doesnot define PPDUs for these services, which results in the mapping of parameters 10 theircorresponding (S)-primitives. Enhancing the presentation layer is then required to fully supportthese services (this applies especially to activity management).An exception to this rule is resynchronization. Although really an (S)-service, support requires theexchange of PPDUs. The following sections will focus on each service which involves PPDUs.

31

5.2 Connection Establishment

Establishment of a presentation connection between two end-systems is initiated by the (p)-userdispatching a P-CONNECf request. This subsequently results in a dialogue through PPDUs. ADattempt to establish a connection can have three effects:

o Successful connection establishmento Rejection of the connection by the responding (P)-providero Rejection of the connection by the responding (p)-user

The initiator first transmits a Connect Presentation (CP) PPDU. It contains parameters which areto be negotiated with the responding end-system. The responding end-system may either reject theconnection sending a Connect Presentation Reject (CPR) PPDU or accept it, sending an ConnectPresentation Accept (CPA) PPDU. Connection establishment is successful providing that fourconditions are met:

o Successful negotiation of a DCSo Acceptance of the default context seto Support of the required PUs and session serviceso Successful negotiation of the presentation protocol

l'-CON.Nl!:C'J'.request

P-CONNECT.indication

P-CONNECT.response

(a) SuccesstuIl establishment

P-CONNECT.request

kP-CONNECT.confirm(Result= provider-rejection)

(b) Establishment rejected by tbe (P)-provider

P-CONNECT.request

P-CONNECT.lndlcation

P-CONNECT.response

(Result= provider-rejection)

(Result= provider-rejection)

(c) Eslabllilhment rejected by the (P)-user

Figure 5,1 Exchange of PPDUs in context establishment.

Figure 5,1 illustrates the three different possibilities. Negotiation generally takes place between fourentities, the (p)-users and (P)-providers. The result however depends on the supported sessionservices as weIL Negotiation is different for each of the previously mentioned items and will bediscussed next.

32

CHAPTER 5. THE PRESENTATION PROTOCOL MACHINE

Negotiation of the Defined Context Set:

33

During the request phase the application process lists all the required abstract syntaxes (togetherwith an identifier) in the Presentation Context Definition List. During the first phase ofnegotiation, the presentation layer of the initiating end-system selects one or more appropriatetransfer syntaxes for each abstract syntax listed.

When the parameter arrives at the destination in a CP PPDU, the peer presentation entitychooses one transfer syntax out of the given list of transfer syntaxes for each abstract syntax.If no transfer syntax is supported for a given abstract syntax, the entry is marked with 'providerrejection' and a reason. As the parameter moves up to the application entity on the indicationprimitive, one transfer syntax has been associated with one abstract syntax.

The responding application layer then verifies which abstract syntaxes it can support, markingthe unsupported ones with 'user rejection', and the other entries with 'accepted'. The contextdefinition list is forwarded as the Context Definition Result List. Next, the respondingpresentation layer transmits the refined context list back to the initiatior.

Finally, a confirm is issued to the application entity. If the responding application layer hasadjusted the abstract syntax list, it may result in an abort by the initiator. Otherwise bothinitiatior and responder have agreed on the presentation contexts used and the contexts arestored in the DCSs together with their presentation context identifier by which each context willbe identified later during connection. Also note that the transfer syntax was transparent 10 theapplication entities during context negotiation.

Negotiation of the default context:

Negotiation of the default context set is less complicated. The Default Context Set parameteris inc1uded when the application process wants to define an alternative abstract syntax. If thisparameter is not present some prior arrangement is assurned. It contains an abstact syntax forwhich the initiating presentation layer selects one transfer syntax. On arrival at the destinationthe peer checks if the proposed Default Context can be supported. If not, the peer immediatelyrejects the connection, sending a Connect Presentation Reject (CPR) PPDU.

If on the response primitive the abstract syntax name in the Default Context Result parameteris marked as 'user rejection', the PPM will also reject the connection with a CPR PPDU.Obviously, the default context is not negotiable. If it is not acceptable by the peer end-system,the connection establishment will fail and a corresponding PPDU is returned.

Negotiation of the presentation requirements:

The Presentation requirements parameter is used by the inititiating (p)-user to indicate thedesired FUs. The contents will be delivered at its peer unchanged, unless one or more PUs arenot supported, in which case the unsupported FU requests are discarded. Availability of the CM(Context Management) and CR ( Context Restoration) FU depends on the availability of impliedservices provided by the session layer. This specifically pertains to the Typed Data,Resynchronization and Activity Management FUs.The parameter appears in both the CP and CPNCPR PPDU. Non-acceptance of the selectionby either (p)-user results in rejection of the proposed connection.


Negotiation of the protocol version:

34

Negotiation of the protocol version 10 be applied by ooth presentation entities requires theinitiating presentation entity 10 make available a list of supported protocol versions in theProtocol Version parameter. The responder subsequently selects one of the proposed entries. Ifnone of the versions are acceptable it sends a CPR PPDU with a list of protocols it is able tosupport.

When the (p)-user rejects a connection it must convey this wish to the {P)-provider. This isaccomplished by including a message in the Result parameter. It indicates the result of theconnection establishment procedure as determined by the application layer. The Result parameterdoes not appear in a PPDU. The responding presentation layer instead dispatches a CPA or CPRPPDU, depending on the contents of Result. The initiator deducts Result again from the nature ofthe PPDU (CPA/CPR), and records it in the confirrn primitive.

The resulting connection may not be acceptable to the initiating (p)-user, perhaps because a criticalabstract syntax is not supported. When this occurs the (p)-user may simply release the establishedconnection or abort.

As outlined earlier, the connection establishment procedure involves ooth parameters dedicated topeer-to-peer communication as weU as parameters addressed to the underlying session layer. Thefirst set of parameters is coUected in a PPDU which is included as User Data in the S-CONNECfprimitive, the User Data is then transported transparently to the session layer. The second set ofparameters is mapped direct1y to the corresponding parameters on the S-CONNECf, which makesthem available to the session layer.

5.3 Connection Release

An application entity can instigate a disorderly release by transmitting a P-U-ABORT request. Itcan be sent at any time by the initiator and at any time, after issuance of a P-CONNECf.response,by the responder. This indicates that a connection establishment procedure can be discarded evenbefore it has been set up properly.

The primitive also causes creation of an Abnormal Release User (ARU) PPDU, which contains UserData and under certain circumstances a Presentation Context Identifier List. The latter parameterindicates the presentation contexts the User Data conforms t~.

It is also possible that the underlying session connection is lost because of a failure in one of thelower entities. In this case ooth presentation layer entities receive a S-P-ABORT.indication andissue a P-P-ABORT.indication to their user; the connection is canceled.

A presentation layer can also issue a P-P-ABORT.indication on its own initiative, eg. when aparameter is not recognized. In this case it also sends, if possible, an Abnormal Release Provider(ARP) PPDU. This PPDU contains a Provider Reason, which identifies the reason of the aOOrt, andan Event identifier, indicating which PPDU or session-service primitive caused the error.


5.4 Context Management

35

The P-ALTER-CONTEXT service consists ofthe exchange of Alter Context (AC) and Alter ContextAcknowledge (ACA) PPDUs between the supporting presentation entities. Through this procedureit pennits them to negotiate new presentation contexts to be added or old contexts to be deletedfrom the current DCS. The exchange of PPDUs is illustrated in figure 5,2.

P-ALTER-CONTEXT.request

P-ALTER-CONTEXT.indication

P-ALTER-CONTEXT.response

Figure 5,2 Exchange op PPDUs in context management.

Negotiation of the Presentation context addition list:

The Presentation Context Addition List and Presentation Context Addition Result List areassociated with addition of contexts to the DCS. They appear in the AC and ACA PPDUrespectively. Negotiation is perfonned confonn 10 the mechanism described in the connectionestablishment paragraph.

Negotiation of the Presentation context deletion list:

The Presentation Context Deletion List lists all identifiers of contexts which are subject toremoval from the DCS. Since no addition of transfer syntaxes is needed, negotiation is restrictedto the application layer. It marks agreed entries with 'acceptance', and others with 'userrejection'.The result is forward with the response in a Presentation Context Deletion Result List. Back atthe presentation layer, the DCS is updated and an ACA PPDU is transmitted containing theparameter.

Collision ofP-ALTER-CONTEXT primitives issued simultaneously by two end-systems is possible.This problem is resolved by treating the two alterations independently, synchronizing the twoalteration procedures as follows:

o Changes to the DCS of the responding side become effective when the correspondingresponse primitive is issued.o At the initiating side changes are executed when the corresponding confinn primitive isissued.

The two possibilities are illustrated in figure 5,3. As a consequence, the resulting DCS is the unionof the two alterations and is of course identical at bath end-systems.


ncs = so

36

DCS = S1 =SO+a2*-d2*

ncs = S2 =S1 +a1*-d1*

ncs = SO

DCS = S1 =SO+a2*-d2*

ncs = S2 =S1+a1*-d1*

.. AC(a1.d1)

··:::i~{~:~:.:~;)···":::::·

ACA(a2*.d2*··········Pl·~... ~::::;:~

ACA(a1*,d1*

(a)

AC(a1,d1):::::i~(;2',d;):::::::::::

ACA(a1*,d1*).. ~ ~ ~ .

.............····ICA(a2*,d2*)................................

(b)Figure 5,3 Collision of two CONTEXT-MANAGEMENT procedures.

As stated before, the presentation contexts are indentified by an integer known as Context Identifier.Collision of context alteration procedures could possibly give rise to conflicts in assigning newidentifiers. This has been solved by forcing the initiator of the connection to use odd integers whilethe responder creates even identifiers. It follows that at connection establishment all presentationcontexts have odd identifiers.

Both AC and ACA are transmitted as User Data parameters in S-TYPED-DATA primitives. Uponreceipt the presentation entity must therefore always check the User Data parameter to determineif it is regular user information or an ALTER-CONTEXT PPDU.

5.5 Information Transfer

The user information to be conveyed is always encoded according to the current DCS or the defaultcontext set. This data is then forwarded as a PPDU in a User Data parameter. The data transferservices are all invoked by the (P)-user, with the exception of TYPED-DATA. The latter is usedby the presentation layer to transfer AC and ACA PPDUs.

The following PPDUs are associated with the primitives:oP-DATA : Transfer Data (TD)o P-TYPED-DATA : Transfer Typed Data (TTD), AC/ACAo P-EXPEDITED-DATA : Transfer Expedited (TE)o P-CAPABILITY-DATA: Tranfer Capability (TC) or Transfer Capability Confirm (TCC)


5.6 Resynchronization

37

Nonnally, a P-RESYNCHRONIZE primitive would be mapped directly onto the corresponding SRESYNCHRONIZE. However, this is not always the case since presentation entities sometimesneed to exchange the list of resulting presentation contexts. This piece of peer-to-peercommunication is defmed in two PPDUs. The Resynchronize Session (RS) and ResynchronizeSession Acknowledge (RSA) convey the list in a Presentation Context Identifier List parameter. ThePPDUs are mapped as User Data while the others are directly mapped to make them available tothe session layer.

The actual procedure is shown in figure 5,4. The initiating (P)-provider actually updates its DCSupon reception of the RSA PPDU, and the responder updates the DCS when it recieves the RSPPDU. As mentioned before the outcome of the procedure depends on the functional units selectedand the contents of the Resynchronize Type parameter.

P-RESYNCHRONlZE.request

P-RESYNCHRONIZE.lndlcatiOD

P-RESYNCHRONlZE.responseP-RESYNCHRONlZE.eonfinn~

" "DeS is updated

Figure 5,4 Exchange of PPDUs in resynchronization.

- No FU selectedReception of a request results in transmission of a RS PPDU, optionally with User data. Theother parameters bear no meaning to the presentation layer. Accordingly, if a response primitiveis received, then a RSA PPDU will be dispatched. At arrival a confinn will be generated.

- CM FU selectedIn this case the presentation layer creates a RS PPDU with User Data and a PresentationContext Identifier List corresponding to the DCS. Upon reception of the PPDU, the respondersets its DCS accordingly, and issues an indication primitive. The response primitive willinstigate production of an RSA PPDU holding the same parameters. This procedure applies alsowhen a RSA PPDU is received.

- CM and CR FU selectedResvnchronize Type = 'abandon'The DCS at the transmitter site will not be changed by a request and it will send an RS PPDUcontaining a Presentation Context Identifier List. The responder only takes action when an ACAPPDU is being expected by setting the DCS according to the parameter, otherwise the DCSstays unchanged. The DCS of the initiating presentation layer will be set to the contents of thePresentation Context Identifier List of the RSA PPDU.Resvnchronize Type = 'restart' or 'set'

CHAPTER 5. THE PRESENTATION PROTOCOL MACHINE 38

This type perfonns the real resychronization, which has been discussed previously. Ifthe resyncidentifier corresponds to a sync point associated with a DCS, then that DCS is restored.However, if it is less than any associated sync points, then the DCS is restored to the onenegotiated at connection establislunent. In allother cases, the Des is set as if the resync typewas 'abandon'. The receiver of the RS PPDU follows the same constraints.

Finally, the impact of the RSA PPDU must be taken into account. If there is no sync pointidentifier or it is not associated with a DCS but the value is greater than the lowest sync pointthat has been set, then the DCS will be replaced with the contents of the Presentation ContextIdentifier List.

The reader may wonder how the types of resynchronization to be sent are determined. This howeveris of no concern to the presentation layer but to its user. The presentation layer merely follows theactions imposed on it by the application and session layer. As a flnal remark, the resynchronizationprocedure ends any pending context alteration procedure.

5.7 Summary

The exchange of primitives and parameters has been defined in the Protocol Machine. Peer-to-peercommunications is established by means of a dialogue using PPDUs to convey the necessary controlinfonnation.

This chapter explained the use of PPDUs in implementing the functionality attributed to eachservice. Not every service however involves PPDUs. This regards services which are provided bythe session layer. The invoking primitives parameters are directly mapped to the correspondingsession primitives.

The services requiring PPDUs are Connection Establislunent and Release, Context management,Infonnation transfer and Resynchronization. The PPDUs mainly pertain to the negotiation of theDCS and the maintainance of the integrity of the DCS over the connection.

6Formal description methods

The previous chapters investigated the ins and outs of the presentation layer as defined by CClTf.By now it is c1ear what position the presentation layer takes within the OSI reference model andhow it performs the services attributed to it.

Now it is time to start considering implementation, ultimately the objective of this thesis.Engineering a complex system such as the presentation layer however is not an assignment that isto be undertaken without some preliminary reflections. Although the goal is c1ear, achievement ofa hardware implementation, there are many roads leading to this result. Most importantly, thedesign needs to be structured. This is a critical requirement in order to tackle an engineeringproblem of this size. The term 'structured' itself however is a vague expression which needs to beelaborated.

Through the years, as complexity of systems surged, many different models were devised to relieveengineers from the administrative design details in order to concentrate on the functionality andfacilitate error-free implementation of intricate systems. A big step forward was taken whenE.Yourdon,in 1971, described a new scheme which put the emphasis on the data flows betweenprocesses whereas other methods only considered the functions of processes. Today Yourdon'smethods are widely recognized, especially in software engineering.

The structured specification method we are going to use originates from Yourdon but has beenupgraded 10 embrace the additional requirements and restraints the real-time aspect of hardwaredesign imposes. The model has been devised by DJ. Hatley and LA. Phirbai. They published abook describing their model, called "Strategies for real-time system specification" [Hat187]. Itessentially is a top-down hif::rarchical design method, where each layer is detailed in one or moresubsequent lower layers.

The following paragraphs attempt to c1arify the essence of the design scheme, dividing it into twoparts, the requirements model and the architecture model. Emphasis will be put on the former, sincethis constitutes the pith of this thesis. Finally, a CASE tooI will be discussed, utilized to realizestructered and error-free requirements model.

39

CHAPTER 6. FORMAL DESCRIPTION METHODS

6.1 The requirements model

40

Freedom in specification of a system is often limited because premature hardware constraints areposed. Hatley and Phirbai wanted 10 rid the designer of these restrictions and have separated theentire design process into two steps. The first step involves specification of a requirements model.This model is to be designed without any concern about eventual hardware implementation. Itrepresents a model of what the system must do, not how. It is therefore a complete description ofthe functionality of the system. This scheme allows the engineer 10 freely move around in order tocreate an optimal specification, not hindered by redundant restraints.

In the requirements model one can make a distinction between two major parts, one related todataflows, the other focused 10wards description of control. These parts consist of the followingcomponents:

Datao Data Context Diagram (DCD)o Data Flow Diagrams (DFDs)o Process Specifications (PSPECs)

Controlo Control Context Diagram (CCD)o Control Flow Diagrams (CFDs)o Control Specifications (CSPECs)

Furthermore, there are some genera! components which can be applied to each.o Storeso Requirements dictionaryo Timing specifications

Figure 6, I illustrates how the above mentioned components interact within the overall requirementsmodel.

Data Context Control ContextDiagram Diagram

Timingi 1..- iJ.

, Specificationf"'I J.

Data Flow Control FlowDiagrams

~ ~Diagrams

! !Process ControlSpecifications Specifications

,.

IRequirements Dictionary

IFigure 6,1 Relation between components of the requirements model.

Before one can commence with the actual specifications, the environment must be defined in theData Context Diagram (DCD) and Control Context Diagram (CCD). The formerdepicts interactionbetween data flows and the environment, the other illustrates the same for control flows. The

CHAPTER 6. FORMAL DESCRIPTION METHODS 41

Context Diagrams are represented graphica11y. Usually the only process defined in them is thesystem which is 10 be specified, so the DCD and CCD constitute the top layer of the hiërarchicalmodel.An example of the two Context Diagrams is shown in figure 6,2. BYconvention, data flows aresolid arrows, the control flows are dashed arrows. The direction of the arrow represents thedirection of the flow. Flows may be bi-directional. In a DCD and CCD flows enter or leave soca11ed tenninators, representing the environment. Processes always appear as a drc1e.

terminato1

DeD

terminator2

terminator3

Figure 6,2 Data and Control Context diagrams.

Consequently, the designer must decompose the single top level process into a number of moredetailed subprocesses. These subprocesses constitute a layer one level below the Context Diagram.The layer is described in tenns of the Data Flow Diagram (DFD) and the Control Flow Diagram(CFD). The fonner representing a graphical representation of the data flows and their interactionwith the processes, the other depicting a similar diagram for control flows.

In general, CFDs and DFDs always appear as a pair defining the contents of a process one layerup in the hiërarchy. DFDs and CFDs may contain any number and combination of flows, stores andprocesses. Figure 6,3 illustrates an example of a pair of DFDs and CFDs.

Figure 6,3 Data and Control Flow Diagrams.

Decomposition is continued until a 'primitive' process is created which, according to customlyposed criteria, is indivisable. The process is then defined unambiguously in a Process Specification(PSPEC). A PSPEC usually consists of (semi)-formal text or perhaps scientific formulas.

CHAPTER 6. FORMAL DESCRIPTlON METHODS 42

The flows and stores in Flow Diagrams deserve a litle more attention yet. Also the roIe of theControl Specification (CSPEC) bas not been c1arified yet.

A dataflow, is a pipeline through which data of known composition flows. It may consist of asingle element or an array of elements, each of which can be mandatory or optional. Theinterpretation of a data flow may be everything from single bits to a stream of cars on a highway,the sky is the limit. Control flows are the similar in structure. The difference, again, exhibits itselfin the interpretation. The difference between data and control is not a functional one. Thedistinction is provided to the engineer solely to facilitate design. The designer is therefore free todepict a certain flow as data flow or control flow. The choice between the both may be simple butis usually less c1ear eg. analog signals are data flows but discrete signals can be either. Again itdepends on the interpretation the designer gives to it. Just be consistent.Stores are represented by two horizontallines. Data stores and control stores can be defined. Bothact as memory elements which can be read or written.The contents of stores, control and data flows are formally defined in a data dictionary.

Control flows can flow between processes and to or from a bar. The bar indicates the interfacebetween the CFD and the CSPEC. The CSPEC usually is state machine. It specifies the control(eg.activation) of processes and the contents of control flows in time. CSPECs are optional but onlyone CSPEC is allowed per CFD. Several bars may appear in one CFD for representational purposes.

As stated, the requirements model refrains from any links to the real (hardware) world. This is alsoexpressed in the fact that everything occuring in the requirements model is assumed to be time-Iess.Unfortunately, the environment is not time-Iess and therefore time specifications are defined at theconc1usion of the requirements model. The time specifications only refer to communication withthe outer world.

All discussed components together constitute a model of the requirements of the system, not arepresentation of the implementation of the system. The model is also highly idealized; processesare assumed to be data triggered and infinitely fast. The transition to a more realistic model isdescribed in the next paragraph.

6.2 The Architecture Model

The architecture model is created in the second phase of the system-design. In this phase thefunctional specifications defined in the requirements model are carried over to a more realisticenvironment. To accomplish this objective, the purpose of the architecture model is threefold:

o Define the physical components.o Define the information flow between them.o Specify the nature of the channels over which information flows.

6.2.1 The Architecture Module

The requirements module specified two basic elements of the design ie. the process model andcontrol model. In order to establish a link with the real time world four more elements must beadded. These elements surround the basic requirements model and specify all in- and output.

CHAPTER 6. FORMAL DESCRIPTION MErHODS

User Interface Processing

InputI Process Model I

OutputProcessing Processing

IControl model I

requirements lemplale

Maintenance, Self-Test, andRedundancy Management

Processing

Figure 6,4 The template of an arehitecture module.

43

Figure 6,4 shows how the elements make up a complete architecture model. All blocks putemphasis on specific aspects.The input and output processing bloeks represent the additional processing necessary to establishcommunication with other arehiteeture models and to transform the information to and from aconvenient intemal format.The user inteiface bloek is a special case of the forementioned input and output blocks. It is aseparate building bloek because many user-specifie eonsiderations affect the contents of the userinterface.Finally, the maintenance and self-test bloek embodies implementations to perform self-monitoring,redundancy management and data eollection for maintenanee purposes.

6.2.2 Structure of the architecture model

The architecture model emerges when the aehitecture modules as defined in the previous paragraphare applied hiërarehically similar to the requirements model. The speeific components are listed infigure 6,5.The figure again demonstates the resemblanee 10 the requirements model. The followingcomponents appear:

o The architectural context diagram (ACD) establishes the information boundary between thesystem being implemented and the environment in which the system has to operate. It is formsthe top level diagram.o The architecture flow diagram (AFD) is a network representation of a systems physicalconfiguration. It documents the information flow between all the architecture modules. The AFDalso represents the allocation of proeesses and flows from the data and eontrol flow intoarchitectural modules.o The architecture interconnection diagram (AID) depicts the communication channels whiehexist between the architecture modules. AFDs and AIDs always appear in pairs.o An architecture module specijication (AMS) is written for every module to state the allocationof data flow, control flow, and processing performed by that module.

CHAPTER 6. FORMAL DESCRIPTION METHODS

Architecture ContextDiagram

ÎJ,. J,.

Architecture Aow Architecture interconn.Diagrams .-- -------l Diagrams

1 1Architecture Module Architecture interconn.

Specification Specification

I Architecture Dictionary IFigure 6,5 The architecture model components.

44

o Next, the architecture interconnection specification (AIS) poses the characteristics of thecommunication channels on which infonnation travels between architecture modules. Itdescribes the transfonnation medium as weIl as the infonnation fonnats. An AIS is composedfor every communication channel on an AID.o The architecture dictionary finally, is a list of all the data and control elements that flowbetween the architecture modules and extemal entities. It is an enhancement of teh requirementsdictionary. The additions are the names of the architecture modules between which theinfonnation flows, and the names of the communication channels.

This completes the explanation of the specification model of Hatley and Phirbai. The nextparagraph will focus on a CASE tooI which can be used to implement the requirements model.

6.3 The CASE tooi ProMod

Computers provide excellent opportunities to facilitate design of correct, fine-tuned requirementsmodeIs. ProMod is a software tooI which can be applied to this purpose. It is an automated systemengineering environment enabling the user to generate a detailed specification of the system 10 bedesigned. The specification follows three phases. depicted in figure 6,6.

Problem Requirements System ProgramStatement Analysis & design Design

Defin~ion

User's System System ProgramWhishes Model Specification Specification

Figure 6,6 The ProMod project model.

CHAPTER 6. FORMAL DESCRIPTION METHODS 45

1) Using an elementary system of structered analysis, the designer creates a basic graphic modelof the required system.

2) The analyst or designer, utilizing the information contained in the graphic model, develops asystem architecture made up of modules arranged hierarchically and with strictly defmedinterfaces.

3) Using a pseudocode, the designer refines algorithms and data as ProMod prepares crossreferences for data, functions, etc., and prepares logically structured documents.

The result is a detailed system specification. Additionally, a wide variety of reports can hegenerated. A major advantage offered by ProMod is that the program checks consistency of themodel, eg. it signals undefined flows. This feature prevents propagation of an error from step tostep and ensure matching module interfaces.Ofcourse a syntactical correct design does not guarantee an error free system specification withregard to requirements.

Only the first step will he practiced in this thesis. The aim of this phase is to create a structuredmodel of the presentation layer, which contains all technical requirements.

The key to structured analysis is the manner of thinking about the problem. Conventionalspecification methods put an accent on functions, which a system is to perform. When the analysthas acquired a large set of functions, each function may he easy to onderstand, but insight in theinterrelations fades. This approach usually does not illuminate the influence of individual functionsupon eachother nor the interface through which they communicate. Therefore, ProMods structuredanalysis does not only give attention to functions but to data flow as well.

Unfortunately, ProMod is based on Yourdon and therefore it does not support most of theextensions added like timing specifications. Also some more basic issues like bi-directional flowsare not supported. The most common restrictions are:

o Bidirectional flows cannot not merge or he split.o Every flow diagram requires a mini-spec (PSPEC).o Limited flexibility with regard to definition of flows in data dictionary.o CSPECS are either textual or STDs.

Besides these constraints ProMod seems to exhibit a numher of bugs, which may appear when amodel is analysed:

o Bidirectional flows from a CSPEC bar to the parent-diagram are not supported.o Bidirectional flows to a textual CSPEC bar or to a store are sometimes not fully recognized.In those cases only one direction is regarded during analysis. This flaw can he easilycircumvented by creating two unidirectional flows.o Also, in some cases flows leading to a textual CSPEC are not always recognized, eventhough the flow is explicitly referred in the CSPEC. This can he resolved by placing a dummyflow in the heginning of the CSPEC.o When a data flow and control flow overlap, ProMod may not recognize one of them asexisting during analysis.o When a process is renamed the associated minispec keeps the old name. It is recommendableto explicitly rename the minispec as weIl.

The basis for the requirements model of the presentation layer protocol machine will he the CCITTdefinitions contained in X.216 and X.226. The requirements model will he carried through into as

CHAPTER 6. FORMAL DESCRIPTlON METHODS 46

much depth as the standards do. The encoder/decoder will additionally be based on X.208 andX.209.

6.4 Summary

This chapter has made clear that formal description is indispensibIe in developing a consistentdesign. Several methods have been formulated through the years. Yourdon's specification methodhas proven to be outstanding an is widely recognized. The presentation layer uses a variant, directedtowards hardware design.

HaUey & Phirbai distinguishes two phases. During the first phase the requirements model specifieswhat the system does, without any reference to possible hardware considerations. The architecturemodel subsequently defines how the system is to be implemented.Finally, Promod has proven to be a software package adequate to successfully acquire arequirements model.

7Specification of the presentation layer

As stated before the requirements model is based on the CCnT X.216 and X.226 standards. In thenext sections the environment of the presentation layer will be considered first. Next, a generalstructure of the presentation layer is outlined. This structure is represented by the first layer in therequirements model and at this point fumishes an interesting layout of the different processes to beimplemented. Finally, it is relevant 10 enter into a more detailed description of the objectives of thisthesis-project.

7.1 Context Diagram

The direct environment of the presentation layer is fairly obvious. The boundaries with the sessionlayer and application layer directly border the presentation layer. The structure of and rationalebebind the Context Diagram do not directly influence the functionality of the requirements modelbut more intuitively determine the line of thought by which a requirements model is established.Since it is the objective to acquire a model which defines the presentation layer as clearly aspossible it is weIl worth to put some thought into this conceptual aspect.

A number of considerations influence the arrangement of the Context Diagram:o Should the basic concept of peer-to-peer communication be expressed in the model?o Should the basic concept of service provision by lower layers be applied in the model?o How far should the model correspond to the real world, ie. should the model represent ablueprint for a real implementation?

Note that there is a basic difference between the first two and last factor mentioned. After all, thefirst two issues are not really concemed with creating a model which can directly be transformedinto a real implementation, rather try to model the communication process and the role thepresentation layer plays. In contrast, the last consideration leads to a model which strongly relatesto any possible later implementation. These three basic reflections have led 10 three alternatives,each highlighting a different aspect of OS!. The three concepts are illustrated in figure 7,1, 7,2,and 7,3.

47

CHAPTER 7. SPECIFICATION OF THE PRESENTATION LAYER 48

End-system A

,,,

P-ICI i

,,,,S-ICI[

SessionLayer

ApplicationLayer

SessionLayer

End-system B

P-ICI

S-ICI

Figure 7,1 Context diagram with peer-to-peer communication.

Figure 7, I shows an example Context Diagram which emphasizes peer-to-peer communication. Thepresentation layer is divided into two parts, one transmitting and one receiving end-system. Theenvironment therefore consists of asession and application layer for each end-system. Peer-to-peercommunication is clearly expressed by the exchange of PDUs hetween them. The other two aspects,use of session layer as communication channel and realism, are not clearly expressed. The sessionlayers are merely included as a reception point for primitives, but do not take part in thecommunication process as a medium to transport SOUs.

End-system A

ApplicationLayer

End-system B

ApplicationLayer

P-SDU.\P-ICI

,,

I,P-ICI,:'

Figure 7,2 Service provision in the Context Diagram.

Contrary to the previous figure, the Context Diagram in figure 7,2 puts an accent on serviceprovision by the session layer. The session layers perform as a medium and do therefore not haveto he included in the Context Diagram. They are transparent to the presentation layer and could heregarded as a medium implemented in the presentation layer process. Peer-to-peer communicationcan he implemented by dividing the layer into a receiving and transmitting end-system. Althoughthis concept defines a model which purely regards the communication process from the viewpoint


of the presentation layer, it is even more unrealistic in terrns of hardware implementation. Evenworse, some elements of the communication process have to be disregarded resulting in only apartial view on the functionality of the presentation layer. A particular example is the tokenmanagement service which principally only requires primitives to be mapped to the session layer.Therefore the third and last altemative is presented, depicted in figure 7,3.

P-SDU

S-SDU

APElicationayer ..

,,·· P-ICI,I,·,,

, ,, ,

...,,

·I S-ICI,··,·Session .,

Layer

Figure 7,3 Realistic Context Diagram.

Compared to the two previous Context Diagrams, this is the simplests but most realistic one.Basically, this figure represents a implementation of a presentation layer with receiving andtransmitting sections intertwined in a requirements model. Communication between the presentationand session layer occurs as it would in a real system, establishing virtual peer-to-peer exchange ofPPDUs. Two major advantages are provided over the other options:

o OSI has defined the presentation layer protocol in state tables based on one complete endsystem. Therefore, when the last alternative is adopted, the state tables of X.226 may be usedto implement the requirements model. This is very important since the state tables are verycomplex and having to redesign them could easily introduce severe errors.o The objective to ultimately realize a hardware design of the presentation layer desires therequirements model to be realistic too.

Because of these arguments the last Context Diagram has been favoured over the other modeis. Thisinc1udes acceptance of the concept to define an as realistic as possible requirements model.

7.2 General Structure

To give an idea of how the presentation layer has been structured figure 7,4 shows a block-diagramconsisting of three basic elements. These elements are the protocol machine, the encoder/decoderand an interface unit between them. The functions of the first two blocks have been c1arified inearlier chapters. The interface unit in the figure houses the DCS. In previous chapters it has beenrepeatedly stated that maintenance of the DCS (Defined Context Set) is the principal function ofthe protocol machine. Therefore, the interface unit communicates with the protocol machine toupdate the contents of the DCS, and it is used by the encoder/decoder to deterrnine how User Datais to be transforrned. Finally, the building blocks are separated from the application and sessionlayer by two interfaces which supply the PSDUs and SSDUs. These interfaces basically representSAPs.

CHAPTER 7. SPECIFICATION OF THE PRESENTATION LAYER

Interface Application Layer

P-SDU, P-ICI UserData

50

ProtocolMachine

S-SDU,P-ICI

Interface Session Layer

EncodedUser Data

Figure 7,4 Block diagram of the presentation layer.

The block-diagram merely conveys those aspects which are explicitly defined by the OSI standards.Other likely features such as layer management, resource management etc. are left by OSI as 'localimplementation matter'. These aspects have also been omitted from the DFD (Data Flow Diagram)of the first level of the requirements model (figure 7,5), but can be added later.

update_micro_programs

PRESJ.AYER

Figure 7,S First level Data Flow Diagram.

The block-diagram discussed can easily he recognized in the DFD. The ppm process embodies theprotocol machine. lts interface with the DeS is shaped by the 'filter' data flow which leads tofilter_des. The latter process controlls the DeS contained in the 'manage_dcs' store. In the nextsections ppm will also be referred to as 'protocol machine' and 'filter' should be regarded as thefilter_des process. Finally, the encoder_decoder is linked to the DeS interface by means of a'tesecs ' store, also controlled by filter_des.


Two more components show up in the DFD named psdu_buffer and ssdu_buffer. They are twoprocesses representing the interface with the application layer and session layer respectively.Communication with the two bordering OSI layers is defined with 'p_sdu_e' and 's_sdu_e' dataflows, which exchange parameters, and with 'p_ici' and 's_ici' flows, which convey controlinformation. Of course the control flows are only visible in the CFD which isn't shown here.The two data flows are defined in the requirements dictionary as carriers of parameters belongingto the different services. However, the type of service requested is not conveyed in data flows butin the control flows. Therefore, the control flows transport service-primitives.The flows appear in the requirements dictionary as follows:

p_sdu_e =p_conneccpar =

[ P30nnecCpar I p_release_par I ... ][ mode + protocol + pres_requirements + ... ]

==

[ p_connect I p_release I ... ][ "request" I "indication" I "response" I "confirm" ]

All defined primitives and parameters are covered in the data and control flows. Where a flowtransports values which cannot be decomposed further, the values are enc10sed in quotation-marks.

This level is very suitable to start assigning further development of the defined processes todifferent thesis-projects. All the processes pertain to distinct aspects of the presentation layerfunctionality with simpie, well defined interfaces between them. The decomposition of theencoder/decoder has been described in [Verh91]. The objective of this thesis-project can now benarrowed down to the protocol machine (depicted as ppm). However, service provision of theprotocol machine puts critical demands on the filter_des, psdu_buffer, and ssdu_buffer. In thenext sections the guidelines for implementation of these processes are defined. They strive to keepexplanation as independent of the requirements model of the protocol machine as possible.However, when this is not possible they will also refer to the model which is incorporated inappendix B.

7.2.1 The SOU Buffers

As can be conc1uded from the DFD the buffers form the interface between the bordering OSI layersand the protocol machine. In the model several important tasks are attributed to the buffers. At thismoment they are defined to relieve the protocol machine process from tasks which do not strictlyrelate to handling of presentation services. The tasks both buffers must support can be structuredas follows:

o Storage. Both buffer processes must buffer incoming PSDUs and SSDUs and keep themavailable to the protocol machine (this is not explicitly stated in the requirements model but isimplied by the method of specification using Hatley & Phirbai).o Extraction and concatenation of User Data. As is illustrated in the DFD, the unencoded UserData parameter from a PSDU is extracted and fed to the encoder/decoder. Next, the encodedUser Data unit is inserted into the data stream by the ssdu_buffer process. Likewise, when UserData arrives from the session layer, the buffer must extract it from the SSDU. After decodingthe data it can be fit in as User Data parameter by the psdu_buffer. Note that the ssdu_buffermust obtain the parameter from inside Protocol Data Units. Also, it must be able to inc1udeencoded User Data inside PPDUs.o Mapping of PCI and PDU identification. When a request for service arrives from theapplication layer in the shape of 'p_ici3' containing a service primitive name, that name mustbe indicated to the ppm by mapping it onto the 'p_ici' control flow unaltered. However, when


a serviee primitive arrives from the session layer, the ssdu_buffer must map the name of theprimitive to the name of the PDU contained in the SSDU (eg. CPR or ACA). For example:

'p_ici_e' =p_connect.request -> 'p_ici' =p_connect.request's_iei_e' =p_connect.confirm -> 's_ici' =CPR or CPA.

o Error management. When a PDU is not recognized or an error occurs the buffers should sendthe type of error to the ppm in the 'erroctype' data flow. The 's_iei' or 'p_ici', depending onwhieh buffer trapped the error, must contain 'p_p_abort' so the ppm can break of theconnection. Note that the ccnT recommendations at this point prescribe that if the erroroccured upon arrival of a SSDU the connection must be aborted. However, if a PSDU causedthe error the actions to be taken are 'local implementation matter'. This requirements modeldoes not distinguish between either error. The following errors must be detected:

o 'unrecognized PPDU'o 'unexpected PPDU'o 'unexpected-session-serviee-primitive'

This concludes the combined treatment of the buffers. In the next section the requirements forimplementing the filter_des process are demonstrated.

7.2.2 The Filter

The filter process has already been introduced as the interface between the ppm andencoder_decoder. It maintains the DCS during activities, context management, resynchronizationetcetera. It is fed with commands by the ppm telling the filter whieh operation to perform on theDCS. Besides updating the DCS it also controls the 'tesecs ' store, whieh contains the presentationcontexts User Data must conform too. The encoder/decoder only has access to the 'tesecs' store.It is loaded by the filter when it receives a message from the protocol machine to do so.

In order to administrate the DCS effectively, the filter must keep a record of presentation contextsand their history. When an activity is in progress it should also be able to tie the administration ofsynchronization points and context deletions or additions solely to that activity, as long as theactivity is not ended or discarded. The administration pertaining to that particular activity shouldbe maintained during interrupts too, since the situation must be restored when the activity isrestarted. In order to realize such involved activity management the filter must maintain a list ofactive activities. When no activity is operative, it must remember whieh activity was in effect last.

This gives rise to some kind of array structure which could be implemented in memory. Anexample of such a memory structure is shown in figure 7,6. The figure shows how the filter processcould be able to extract or deduce the following Defined Context Sets or presentation contexts:

o Presentation contexts marked for deletion locallyo Presentation contexts marked for addition locallyo Presentation contexts marked for deletion remotelyo Presentation contexts marked for addition remotelyo The Defined Context Set at connection establishmento The inter-activity Defined Context Seto The Defined Context Set at synchronization points


abstract syntax transfer syntaxname name

mark context foraddition or deletion(locally/remote)

I /defmed atconnectionestablislunent

\

inter-activitypresentation context

presentationcontextidentifier

pointer topresentation context

identifier ""

2

1 3

1 2

2 23

3 3

8

9

Activity 1

set ofsynchronizationserial numbers

No Activity

Figure 7,6 Example of DCS administration.

The mechanism in the figure holds the administration for 'activity l' and 'no activity'. The list ofpresentation contexts in the figure shows three fictitious contexts and one ASN.l - BER definedcontext. The DeS of 'activity I' is created by having pointers referring to the presentation contextsin the DeS. As can be seen, addition and deletion of contexts is administered 'locally' asweIl as the synchronization points. The length of the list of synchronization points should not befixed since new points can be added or deleted at any time. The connection establishment and interactivity DeS can be established globally, since they are not local to any activity. Altematively, theycan also be logged in the 'No activity' registration.

The functionality of the filter process is made available to the protocol machine by means ofcommands which are conveyed in the 'command' control flow. Sometimes, the command offersother associated information like presentation context lists. This data is transported in the 'filter'data flow. FinaIly, many times the protocol machine needs feedback from the filter on the successof an operation. The 'syntax_status' control flow has been incorporated to facilitate thisrequirement.

The following list contains all of the 22 commands which should be supported by the filter. Whenapplicable, the contents of 'filter' are inc1uded as well as the status information which should beretumed to the protocol machine. When a command description refers to the 'current DeS' it refersto the DCS which is currently used to encode/decode User Data.

o set des to interaetive- --Instruction to set the current DeS to the inter-activity Des stored previously.

o remember des as interaetive- - -Stores the current DeS as the new inter-activity Des


o deassociateJync_with_activityDeassociates all previously set synchronization points from the current or, if no activities arein effect, last activity. Effectively, this discards the administration of this activity (or lastactivity).

o set_dcs_toJyncyointRestores the DCS to a previously set synchronization serial number. The number is given in'filter'.

o new_activityTells the filter to setup an administration for a new activity and link all future synchronizationpoints and presentation contexts exclusively to that activity. The 'filter' flow contains the serialnumber of the new activity.

o restore_activityThis command instructs the fIlter to resume a previously interrupted activity. This does notinclude restoration of the DCS. 'Filter' communicates the activity identifier.

o check_activity_associatedCommands the filter to check if a DCS is associated with the pair of parameters given in'filter'. These parameters are an activity identifier and a synchronization point serial number.This command does not set the DCS or restore the activity yet. It merely returns a'syntax_status' which is 'true' if the condition is true, otherwise it returns 'false'.

o set_dcs_activity_checkJyntaxOnly when this command is issued, the DCS is restored to the given activity andsynchronization point. 'Filter' contains the same parameters as the check_activity_associatecommando Additionally, it checks the syntax of the User Data and returns 'true' or 'false' in'syntax_status' depending on the result.

o get_dcsThis simple command retrieves the current DCS and returns a presentation context identifier listto the protocol machine in 'filter'.

o set_dcs_asyres_cont_/istSimilar to the previous command, but this one submits a presentation context identifier list andthe DCS is set accordingly.

o checkJyntax_against-.filterThis commands submits a presentation context identifier list in 'filter' as weIl. However, thefIlter process should not update the DCS this time, but merely check if the User Data complieswith the list. It should then return the result ('true' or 'false').

o resynchronizeJyncyointThe name reveals it is tied to resynchronization procedures. It instructs the filter to check if thesync point serial number, presented in 'filter', exists. If that is indeed the case, the DCS mustbe restored to it. However, if the sync point is lower than any previously defmedsynchronization points then the DCS must be restored to its contents at connectionestablishment. 'Syntax_status' may return three values: (1) 'True' if the DCS has been restoredokay, (2) 'false' if the DCS has been restored to the DCS at connection establishment, and (3),resyncjail , if the synchronization point does not exist but is higher than the lowestsynchronization associated.

o is_sync_not_associatedChecks if the synchronization point in 'filter' is not associated with a DCS but is still higherthen the lowest sync point in the set. In that case it checks the User Data against the currentDCS and returns 'true' or 'false' conform the result. The 'resyncjail' message is sent back ifthe sync point is indeed found.

o p05Checks if each presentation data value in User Data is from presentation contexts of the DCS,or from the default context if the DCS is empty. 'Syntax_status' returns the result.


o p06Looks if each presentation data value is from presentation contexts of the DCS not proposedfor deletion by the peer PPM. The outcome is retumed in 'syntax_status'

o p07Checks if each presentation data value is from presentation contexts of the DCS not proposedfor deletion by the local PPM. 'Syntax_status' reports the result.

o eliminate_and_associate_syncCommand 10 eliminate all synchronization points set earlier and replace them with the singlesynchronization serial number contained in 'filter'.

o associate_syncCommand to add another synchronization point to the administration of the current DCS. The'filter' flow contains a synchronization serial number.

o update_local"'proposed_contexts, updateJemote"'proposed_contextsThese commands are issued during context management by the initiator and responding endsystem respectively. They are instructions to update the DCS with the proposed additions anddeletions, distinguishing between remotely and locally proposed contexts. 'Filter' contains thepresentation context deletion list and presentation context addition result list.

o consolidate_accepted_contextsThis command is the signal for the filter to add the approved additions to the current DCS. Theapproved deletions are deleted from the DCS. In 'filter' two parameters are conveyed, thepresentation context deletion result list and the presenation context addition result list.

o p03Checks if each presentation data value is from presentation contexts proposed in the presentationconnection establishment procedure or from the default context if this DCS is empty. Again aresult is retumed in 'Syntax_status'.

o chk_data_against_allFinally, this command combines p03 with the predicate that each presentation data value canbe decoded using at least one of the transfer syntaxes being negotiated in the presentationcontext definition procedure. The result is reported to the protocol machine.

It is clear that the commands defined can be grouped into one set which does not involve anychecking of User Data and a set which tells the filter to which DCS the User Data must comply.The last group of commands require that the 'tesecs' is filled with the appropriate DCS and thatthe encoder/decoder is subsequently notified that it should commence with a checking routine. Inmost cases the result must then be communicated back to the protocol machine by asserting a'syntmcstatus' control signal.

Most command signals included in the list are also explicitly described in the processes whichactivate them. Therefore, the reader is referred to the requirements model in appendix B forbackground information.

7.2.3 Model of the Encoder/Decoder

The encoder_decoder process has already been defined in a requirements model [Verh9I]. Forcompleteness the main functions are repeated in this sections. As the name already reveals, theprocess performs the actual encoding/decoding of User Data parameters offered by the applicationlayer for transmission to its peer. The encoding process treats the incoming bitstream in two phases.


In the flrst phase syntactical analysis of the abstract syntax in question is perforrned. The User Datais 'compiled', resulting in an intemal representation of primitive presentation data values. Theobjects are arranged in a tree, which facilitates further processing.

During the second phase the encoding process executes the transforrnation of data from the localrepresentation to the common representation according to the mIes posed by the transfer syntaxapplied. The flnal result is an encoded bitstream which is ready to be transported. Decoding isaccomplished in a similar manner.

Besides this 'run-time' task, the encoder_decoder process also deals with updating the 'supp_cs'store. This store contains all abstract syntaxes used by the application layer ( and thus presentationlayer). Each abstract syntax is supplemented by all possible transfer syntaxes which can be usedto code it. Implementation of this task is not at all defined or recommended by the CCnTstandards but is local matter to be solved by the designer. Actually, it is an example of a piece ofresource management. It is necessary though since the list is used at connection establishment andcontext management procedures to select abstract and transfer syntaxes.

7.3 Modelling the Protocol Machine

From the previous sections one can draw the conclusion that implementing the protocol machinerequires a model which describes in detail interaction with the filter process. All operations whichhave to be executed to perform the defined services have been transforrned to commands which areexecuted outside the protocol machine process itself. With this in mind the ppm process bears alot of resemblence with the state tables incorporated in X.226. After all, the state tables define theservices in terms of predicates, actions and states. The predicates and actions can be compared tothe commands sent by the ppm. In fact, many commands are exact replica's of predicates andactions (eg. p05,p06...). It follows that the protocol machine simply controls provision of servicesand the protocols which mIe each service. The process is not concemed with any overhead, thatpart is left to the filter and encoder/decoder.

Complying with the state tables while implementing the protocol machine has some majoradvantages over customly built protocol controllers. First, the state tables are proofed and do notcontain errors. Secondly, custom designed state transition diagrams do not assure 100%conforrnance. Therefore, the requirements model is based largelyon the OSI state tables, sometimessupplemented where necessary.

Before going into detail, it could be beneficial to take a closer look at these state tables. They arebasically matrices with rows representing the event (eg. P-CONNECf.request) and the columnsrepresenting the state. The actions to be taken are controlled by predicates. These predicates mustbe evaluated first. Depending on the result one or more actions may be enacted and the next stateis deterrnined. Every service supported by the presentation layer is described by one of these tables.

Figure 7,7 illustrates the stmcture of the ppm process and shows the spot occupied by the services.The main building blocks are the services and the controller. Both also interact with the errorsystem, which traps errors and reacts to them, and with the administration, which stores allinformation relevant to the support of a connection eg. functional units, protocol version etc.

CHAPTER 7. SPECIFlCATION OF THE PRESENTATION LAYER

-= ... ë5] ~

I 5~ ~

4.l.= I >.5 -0 .=~~

... 4.l o ~ ä sg '"~ bO C,) 0 l:! .g .~ i .~§~ B ~ ~.= 5 4.l5 ril '" ~~ .=

~ ·ä <::; "'..:.:ul!j u::; en 'e oE8 ~

AdministrationFUs, mode etc. Error system

Genera! controlInterface to buffers

Figure 7,7 Block-diagram of protocol machine.

57

When developing a requirements model, the pith of the matter thus comes down to the question ofhow 10 fit in the X.226 state tables as efficiently and clearly as possible. The next chapter willelaborate several alternatives which have been under consideration and will select the best method.Next, the error-system will be examined closely.

7.3.1 Implementing X.226 State Tables

Centra! in the design of the protocol machine is the concept of having one centra! CSPEC (controlspecification) controlling the selVices which are represented by (child) processes. These processesmay on their part contain a CSPEC which may more or less relieve the central CSPEC from itstasks. This concept surfaces in every alternative which is regarded. The predicament concealedbehind this general setup is the issue of distributing the X.226 tables over the CSPECs. Figure 7,8demonstrates the general structure of the protocol machine.

The effects of different distributions will be discussed in an outward fashion, that is, the treatisewill start out with a centra! CSPEC comprehending the entire set of state tables whereaftergradually evolution to a distributed set of CSPECs takes place. The elements sensitive todistribution are:

o States. Recording the state of the system as a whoie.o Reception of primitives. Central or distributed over the appropriate processes.o Evaluation of predicates.o Execution of general actions (eg. filling a store, it is impossible to centralize selVice-specificactions)


.................

/{

\"\"

.......•........_----,,-::::_._--._-------..._---

Figure 7,8 Generallayout of protocol machine.

58

The state tables implement seven states, three of which are only important to the connectionestablishment procedure. Since allother seJVices exc1usively pertain to an established connectionthese three states will not be regarded in any candidate implementation. The states left are STAacO,STAacl, STAac2 and STAtO (the names are defined by OSI). The first three states emerge whena context management procedure is in effect. This procedure subsequently affects the operation ofevery other seJVice until it is conc1uded. There is no other direct mutual influence between seJVices.

At first sight the easiest solution would be to implement all state tables in one central CSPEC,inc1uding recording the state of the system, checking predicates and performing general actions.Primitives are received by this CSPEC and consequently the CSPEC must instruct the individualseJVices what seJVice-specific actions are to be performed. Therefore, message traffic is introducedbetween the CSPEC and the subordinate processes. The following characteristics can be attributedto such a system:

o All OSI state tables are united in one controller.o Control over special control stores is centralized.o Communication between CSPEC and processes occurs through exchange of messages.o Child processes are state independent and very simpIe.o Both CSPEC and processes require access to the filter.

The bottom line is that only actions which are performed independently of the state can bedelegated to the processes. The requirement of the CSPEC to resolve any state discrepancies putsa heavy burden on its complexity. This results in a 'hefty' CSPEC which is mainly caused by theabundance of different messages and predicates, and 'exceptions' necessary to overcomeincompatibility with some processes, eg. the new state of the system after a release procedure canonly be determined after analysis of the received parameters, something which can only beaccomplished in the processes. The number of messages could be reduced from around 80 to 14by careful grouping. However, the result still was a 13 page long CSPEC rating poorly in terms ofreadability and c1arity.


The second alternative tries to apply the same principle less strictly. When the state tables areanalyzed carefully it becomes apparent that in most cases the actions and predicates associated witha primitive can be c1ustered into two sets. Each set represents the actions to be executed when thesystem is in one of two states. Which states are combined depend on the primitive in question. Thepredicates and actions which can be grouped are moved to the child process. This way the proposaltries to limit complexity in the central CSPEC. State maintenance is still located in the centra!CSPEC as well as reception of primitives. However, the child processes also receive and solelytransmit the primitives. This leads to the following characteristics:

o Both CSPEC and child processes receive primitives.o Predicates and most actions are located in processes. State dependencies are resolved bycentra! CSPEC.o Processes must be made aware of state of system with messages.o Control stores control is distributed over all processes.o Increase in communication between processes and CSPEC (feedback conceming predicates)o Only processes access the filter.

The objective of the centra! CSPEC is to maintain the state of the system and to possibly resolvean action or predicate to simplify communication with processes. The complexity has shifted to thechild processes which are not entirely state independent anymore (two sets). This scheme reducedthe complexity of the centra! CSPEC by two. The complexity of individual processes remainedacceptabIe.

Maintaining the state introduced a lot of overhead in the CSPEC which did not quite seem to beworthwhile. When the effects different services have on the states is taken into consideration itbecomes evident that only one service really has an impact on the state of the system, contextmanagement (STAacO, STAac1, STAac2). The other service either do not change the state at allor break off the context management procedure by retuming the system to state STAtO. Thereforethe third idea is to discard the central CSPEC and have the processes update each other on the nextstate. It also implies that every service process implements only the state tables pertaining to itsown service. Combining this thought with the concept of two sets, the context management setshould implement all four states while the remaining services only have to deal with two states:Normal, and context-management-in-effect.

Ultimately, the scheme through which processes inform each other was centralized into a centra!CSPEC. Consequently, the central CSPEC does not process any primitives but is merely a'distribution-centre' for state updates. This method has the following properties:

o Only child processes receive and transmit primitives.o Simplified state tables are implemented in the processes, inc1uding state dependencies.o The central CSPEC merely passes on state changes.

It tumed out that this 'divide-and-conquer' method provided the c1earest and most structuredmethod to translate the OSI state tables into a requirements model. In part this is due to the factthat a uniform approach to combine the services is impossible, mainly caused by predicates andactions which can not be treated uniformly accross the board. The mechanisms necessary to resolvethe exceptions then escalate complexity.By distributing the services, combining states into sets, and analysis of the service-dependent effectson states, the requirements model could be kept simpIe, c1ear, and easy to maintain and extend infuture. An example of this last property is discussed in the next section.

CHAPTER 7. SPECIFlCATION OF THE PRESENTATION LAYER 60

As mentioned the model of the protocol machine is incorporated in appendix B. Basically, it canbe split into two subsets. The first set entails connection establishment (including aborts while theprocedure in on-going). The second suit relates to all services which are provided during apresentation-connection (and has been the subject of this section).

7.3.2 The Error-Trapplng System

The most difficult part in developing the requirements model was trapping and responding to thevarious errors, which may occur. The errors have been defined by OSI and mostly relate to PPDUerrors. However, the response to errors depend on the source:

o If the incoming event is related 10 a received PPDU or session service-provider, the PPMshould issue an ARP PPDU and an P-P-ABORT indication.o If the incoming event causing the error comes from the P-user, any action taken by thepresentation layer is a local matter.

The requirements model has been defined to react to either source by issuing an ARP PPDU andP-P-ABORT indication. Optionally, this can be changed later if the need arises. OSI has definedseven possible errors:

o Reason not specifiedo Unrecognized PPDUo Unexpected PPDUo Unexpected session-service primitiveo Unrecognized PPDU parametero Unexpected PPDU parametero Invalid PPDU parameter value

The last three errors are recognized by the protocol machine (and of course 'reason not specified ').The others are better suitable for detection by the buffers discussed earlier.

Handling of an error consists of two parts. First, an error indication must be produced, which finallymust lead to asserting a P-P-ABORT primitive. Secondly, parameters ofthis primitive must containthe reason and source of the abort, ie. the type of error. The reason is stored in the Provider Reasonparameter. Therefore, some mechanism must convey the type of error to the process which handlestermination of the connection.

To facilitate easy extension of the error system, error indication and supply of the reason have beendivided into two cooperating schemes. When an error occurs in a service-process it sends an errorindication 10 the centra! CSPEC only containing 'error'. At the same time it stores the reason ofthe error in the 'erroctype' store (data store).When the central CSPEC receives an error indication it reports it to the termination process, inorder for the latter to initiate an abort procedure. Subsequently, the termination process reads thetype of error from the store and includes it in the SDUs as Provider Reason. Finally, the conneetionis aborted.

The advantage of disconnecting indication and reason is that more reasons can be added withoutaffecting the indication scheme. Only the process which wants 10 supply an additional reason mustbe updated. A need for such an enhancement may emerge when it is decided 10 alter the way therequirements model reacts to erroneous user events.


7.4 Summary

61

This chapter has presented the requirements model of the presentation layer. The general structurehas been described and the processes which are yet to be developed further have been describedin terms of their requirements with regard to other processes. The buffer processes constitute theinterface between the bordering layers and the protocol machine. The fIlter process maintains theDefined Context Set.

The objective of this thesis-project is the development of a thorough specification of the protocolmachine. lt has been shown that the X.226 state tables occupy a central roIe. Several alternativeshave been discussed and weighed in terms of their advantages and drawbacks. Finally, the errorsystem has been explained.

8Conclusions

The general objective of this thesis-project has been the establishment of a requirements model ofthe presentation layer, which adequatly specifies implementation of the collection of services andprotocols defined in the corresponding CCnT recommendations. The recommendations thereforehad to be analyzed and translated into a graphical model, using a CASE-tooI named ProMod.

Initially, a number of parts have been distinguished within the model. They are the protocolmachine, interfaces with bordering layers (buffers), a Defined Context Set manager/filter, and theencoder/decoder. Since the combined blocks are too comprehensive to be devised by one person,the project was at this point fragmented. The encoder/decoder has been further enhanced by P.Verhaak in [Verh91]. His model is based on the X.208 and X.209 CCnT blue bookrecommendations. The specific goal of this project was narrowed down 10 development of a modelof the protocol machine. The basis for this task are the service and protocol specifications, whichare incorporated in X.216 and X.226 respectively.

Completion of the protocol machine entailed detailed analysis of the recommendations. The X.226state tables have been applied as much as possible to prevent errors and ensure conformance withthe recommendations. However, the process relies in part on the functionality of the other blocks.Therefore, the layer interfaces and the DCS management task have had to be specified in moredetail, in order to support the protocol machine. The first has been described generally in terms ofrequirements, the other has been more specifically described with commands it should be able toresolve.

8.1 What next?

At this point the requirements model includes the protocol machine and the encoder/decoder of onepresentation entity. However, the model is confined to the aspects which have been specificallydefined in the standards. Some other aspects, which are considered 'local implementation matter'by the standards, have been omitted. Implementation of these parts depend on more global designchoices which will have to be made. The considerations do not pertain to hardware yet, but merely

62

to issues like: How should other future protocols be supported, how should error messages beprocessed further, how should more presentation entities be supported?

Some of these issues have already been addressed, eg. error management of user events. However,it will be necessary to extend the requirements model from a single presentation entity to a modelinc1uding the wider environment in terms of general management of entities, addressing, supportfor different protocol versions, possible optimization for special applications etcetera. At this point'local implementation matter' should be settled too. Only when these issues have been addressedthe requirements model will represent a model of the presentation layer instead of purely a modelof the CCnT recommendations.

The appropriate choice of service level, functional units etc. does not only require thoroughknowledge of the standards but also mutual agreement with other implementors. Various standardsorganizations, manufacturer groups and users are involved in defining the functional groupings andoptions to be supported in specific environments [Svob89]. It might be interesting to involve theirresults in the decision taking process.

Hatley & Pbirbai [Hatl8?] define that after completion of the requirements model, the architecturalphase commences with establishment of an architecture model. In other words, hardware designbecomes the focus of development.When making hardware choices, it is important 10 first consider the requirements with regard toreliability and efficiency. When these constraints have been adequatly posed, it is time to makedistinct choices. They centre around two major areas.

The first area involves the design of the presentation layer. Performance considerations favourhardware solutions over software. This especially regards the encoder/decoder which performs acomplex, time-consuming task. However, it is just the complexity which makes it unlikely that theencoder/decoder can be fully implemented in hardware. The alternative is use of a processor. Thelatter provides several options, from using a front-end processor with its own memory to using theprocessing power of the host and sharing (dual-ported) memory.Compared to the encoder/decoder the protocol machine poses much less demanding requirements.The protocol is not very time-consuming and fairly straightforward. A protocol machine may beachieved using dedicated hardware but it would not provide significant advantages. In fact, theadvent of new protocols prefer a more flexible solution. The protocol machine may as well be asoftware-process running stand-alone on a 'plug-in' card or a part of the operating-system of thehost.

The second area entails interfacing the presentation layer with the other layers to form a completesystem. AIso, the interface with the host and even choice of host play a very important role.Keeping the architecture model general, ie. not letting it suggest stringent assumptions about thereal environment would increase portability. The interface with the host is specified in termsresource management like memory and processing power, but also with regard to actually tieingthe layer 10 the host. The interfaces between layers are defined as SAPs (Service Access Points).The recommendations do not dictate the nature of the SAPs. They could be provided in softwareas procedure calIs, in hardware as 1/0 ports, or anything in between. Ultimately, the decision willdepend on the other aspects, discussed already.

Recapitulating, options are still widely available. However, the designer should let bis choice beguided by the encoder/decoder and DeS filter since these are likely to be the most critical processeswith regard to performance. The requirements model does not impose any constraints to hardwarebut the amount of 'local implementation matter' needs the model to be extended to a modelspecifying a complete presentation layer system.

9Literature

[Bess88]

[Cane87]

[Hatl87]

[Hens88]

[Huit89]

[Verh91]

[X.200]

[X.216]

Besson, M., Doghri, A., and Huitema, C."High perfonnance heterogeous transmission using OSI presentation protocol",Proc. of Third Int. Conf. on Computer and Information 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, De: IEEE Comput. Soc. Press, 1987Hatley, D. and Phirbai, I.Strategies for Rea/-Time System Specijication.New York: Dorset House Publishing, 1987Henshall, J. and Shaw, A.OSI Exp/ained: End-to-end computer communication standards.Chichester: Ellis Horwood, 1988.Computer Communications and Networking.Huitema, C. and Doghri, A."Defining faster transfer syntaxes for the OSI presentation protocol", Comput.Commun. Rev., Oct. 1989, vol. 19, no. 5, pp. 44-45.Verhaak, P.An architecture for an OSI protocol (layer 6).Faculty of Electrical Engineering, Digital Information Systems Group, EindhovenUniversity of Technology, December 1991.Infonnation Processing Systems - Open Systems Interconnection - ConnectionOriented Presentation Service Definition, International Standards Organization,1988.Geneva: CCITT, Volume VIII, fascicle VIllA, X.200, 1989.Infonnation Processing Systems - Open Systems Interconnection - ConnectionOriented Presentation Service Definition, International Standards Organization,1988, ISO 8822.

64

[X.226]

[X.208]

lX.209]

[Mant88]

[Pope84]

[Svob89]

[Tane88]

[XA09]

Geneva: CCnT, Volume VIII, fascic1e VIllA, X.216, 1989.Infonnation Processing Systems - Open Systems Interconnection - ConnectionOriented Presentation Protocol Specification, International Standards Organization,1987, ISO 8823.Geneva: CCnT, Volume VIII, fascic1e VIII.5, X.226, 1989.Infonnation Processing Systems - Open Systems Interconnection - Specification ofAbstract Syntax Notation One (ASN.1), International Standards Organization, 1987,ISO 8824.Geneva: CCnT, Volume VIII, fascic1e VIllA, X.208, 1989.Infonnation Processing Systems - Open Systems Interconnection - Specification ofBasic Encoding Ru1es for ASN.1, International Standards Organization, 1987, ISO8825.Geneva: CCnT, Volume VIII, fascic1e VIllA, X.209, 1989.Mantelman, L."Upper 1ayers: From bizarre to bazaar", Data Communications, Jan. 1988, vol. 1,no. 1, pp. 110-128.Pope, A.R."Encoding CCnT XA09 presentation transfer syntax", Comput. Commun. Rev.,Oct. 1984, vol. 14, no. 4, pp. 4-10.Svobodova, L."Imp1ementing OSI systems", IEEE J. Sel. Areas Commun., Sept. 1989, vol.7, no.7, p. 1115-1130.Tanenbaum, A.S.Computer Networks, 2nd Ed..New Jersey: Prentice Hall Int., 1988Message Handling Systems: Presentation Transfer Syntax and Notation, CCnTXA09, Red book, fascic1e VHI.7, Torremolinos, 1984.

Appendix A. Service Protocols

This appendix provides the reader with detailed diagrams illustrating the use of parameters by thevarious presentation layer services. The diagrams must he read as follows (only the requestindication cycle is explained):

o The name of the service primitive is provided in the left corner of the tabie. AIso, in thiscolumn all parameters pertaining to the service are listed.

o The next column shows which of the parameters are contained in the request primitive of theservice. The letter symbolizes the nature of the appearance, eg. Non-Mandatory or Mandatory.

o The third column lists the name of the PPDU when applicable, together with an indicationwhich parameters are included.

o Next, the name of session-primitive 10 which the PPDU or service request is mapped isrecorded in the header of the column. The descriptions in the rows denote the names of thesession parameters.

o Finally, the fifth column shows which parameters reside in the indication primitive of theservice.

66

IParameter P-CONNECT IP-C.req CP S-CONNECT.req P-C.ind P-C.resp CPA CPR S-CONNECT.resp P-C.conf

Mode selector M M SS-user data M(=) M SS-user data

Protocol version NM SS-user data NM NM SS-user data

Calling pres. address M M

Calling presentation selector NM SS-user data

Calling session address SoM Calling SSAP address

Called presentation address M M

Called presentation selector NM SS-user data

Called session address SoM Called SSAP address

Responding pres. selector M NM NM SS-user data M(=)

Responding sess. address SoM S Resp. SSAP address

Pres. context definition list U NM SS-user data C(=)

Pres.cont.def. result list C C NM NM SS-user-data C(=)

Default context name U NM SS-user data C(=)

Default context result C NM NM SS-user-data C(=)

Quality of service SoM SoM Quality of service SoM SoM SoM SoM Quality of service S-M(=)

Presentation requirements U NM SS-user data C U NM SS-user data C(=)

Session requirements SoM S-M(=) SoM Session requirements

User session requirements NM SS-user data NM SS-user data

Revised sess. requirements SoM Session requirements SoM SoM Session requirements S-M(=)

Init.sync.point serial number S-C S-C Init.sync.pointser.num. S-C(=) S-C S-C Init.point.ser.num. S-C(=)

Init.assignment of tokens S-C S-C Init.assign.of tokens S-C(=) S-C S-C Inti.assign.of tokens S-C(=)

Sess. connection identifier SoU SoU Sess.conn.identifier S-C(=) SoU S-C SoU Sess.conn.identifier S-C(=)

User data U NM SS-user data C(=) U NM NM SS-user data C(=)

Provider reason NM SS-user data

Result M-CPR M(=)M+CPA

><NUI'-'

1Parameters P-RELEASE 1 P-R.req S-RELEASE.req P-R.ind P-R.resp S-RELEASE.resp P-R.conf

IUser data IUSS-user data C(=) U SS-user data C(=)

SoM Result S-M(=)Result

IParameters P-U-ABORT I P-U.req IARU IS-U-ABORT.req IP-U.ind I I I I IUser data

IU ~ SS-user data Iq=>I rn I IPres.cont.identifier list NM SS-user data

IParameters P-P-ABORTI1

IARP IS-U-ABORT.req 1P-P.ind1 c=o 1 1

Provider reason

I~ SS-user dala IM

I rn I IEvent identifier NM SS-user data

IParameter P-ALTER-CONT. 1P-A.req AC S-TYPED-DATA.req P-A.ind P-C.resp ACA S-TYPED-DATA.req P-C.conf

Pres.context addition list U NM SS-user data C(=)

Pres.context deletion list U NM SS-user data C(=)

Pres.cont.addition result list C U NM SS-user data C(=)

Pres.cont.deletion result list U NM SS-user data C(=)

User data U NM SS-User data C(=) U NM SS-user data C(=)

P-DATA 1P-D.req ~ S-DATA.req 1P-D.ind c=oIM ~ SS-user data IM(=) c=o

I1 P-T.req ITTD IS-TYPED-DATA.req IP-T.ind c=odata IM ~ SS-user data IM(=) c=o

:E("}c::rn~~I I I I I,

><N-~

I=P=-T=.l=·n=d=:====iCTI=========*===IS-M(=) CTI

S-CONTROL-G.req

D S-TOKEN-GIVE.req

DTokens

11 P-T.req

IIS-M

IParameters P-SYNC-MINOR IP-S.req SoS YNC-MINOR.req P-S.ind P-S.resp S-SYNC-MINOR.resp P-S.conf

Type SoM Type S-M(=)

Sync point serial number SoM Sync.point serial num. S-M(=) SoM Sync.point serial num. S-M(=)

User data U SS-user data C(=) U SS-user data C(=)

IParameters P-TOKEN-GIVE

ITokens

IParameters P-EXPEDIlED-D IP-E.req lE S-EXPEDllED-D.req P-E.ind

IUser data IM NM SS-user data M(=)

IParameters P-CAPABILITY IP-C.req TC S-CAPABILITY.req P-C.ind P-C.resp TCC P-CAPABILITY.resp P-C.conf

IUser data Iu NM SS-user data C(=) U NM SS-user data C(=)

IParameters P-CONTROL-G

IParameters P-TOKEN-GIVE I1 P-T.req D S-TOKEN-PLEASE.req IP-T.ind I CTI I IITokens

II:MEJTOkeos IS-M(=)

I EB I IUser data SS-user data C(=)

Parameters P-SYNC-MAJO P-S.req SoS YNC-MAJOR.req P-S.ind P-S.resp S-SINC-MINOR.resp P-S.conf

Sync point serial number SoM Sync.point serial num. S-M(=)


IParameter P-ACT-START I1 P-A.req D S-ACT-START IP-A.ind I o=J I IActivity identifier SoM Activity identifier S-M(=)

User data U SS-user data C(=)

IParameters P-U-EXCEPT 11 P-U.req D S-U-EXCEPT.req IP-U.indI o=J I I

IR~n II~M BRro~n IS-M(=)I EB I IUser data SS-user data C(=)

IParameter P-RESYNCHRO I P-Rreq RS S-RESYNCHRO.req P-Rind P-R.resp RSA S-RESYNCHRO.resp P-Rconf

Resynchronize type SoM SoM Resynchronize type S-M(=)

Sync point serial number S-C S-C Sync point serial num. SoM SoM SoM Sync point serial num. S-M(=)

Tokens S-C S-C Tokens S-C(=) S-C S-C Tokens S-C(=)

Pres.cont.identification list C C

Pres.cont.identifier list NM SS-user data NM SS-user data

Userdata U NM SS-user data C(=) U NM SS-user data C(=)

><NVI'-'

]:(JC:CI2~S::

I I I I II

I~I====iDl==*,S=-P-=AB=OR=T.=ind=====*'=p-p=.in=d===l=1=~o=J=*===*========lI=====:111 I IReason ISoM I I I I I

IParameters P-P-EXCEPT

IReason

IParameter P-ACT-RESUME 11 P-A.req D S-ACT-RESUME.req IP-A.ind I o=J I IActivity identifier SoM Activity identifier S-M(=)

Old activity identifier SoM Old activity identifier S-M(=)

Sync point serial number SoM Sync point serial num. S-M(=)

Old session conn.identifier SoU Old sess.conn.identifer S-C(=)

Userdata U SS-user data C(=)

Parameters P-ACT-END P-A.req S-ACT-END.req P-A.ind P-A.resp S-SINC-MINOR.resp P-A.conf

Sync point serial number SoM Sync.point serial num. S-M(=)


Parameters P-ACT-INTERR P-A.req S-ACT-INTERR.req P-A.ind P-A.resp S-AeT-INTERR.resp P-A.conf

Reason SoU Reason S-C(=)

Parameters P-ACT-DISCAR P-A.req S-ACT-DISCARD.req P-A.ind P-A.resp S-AeT-DISCARD.resp P-A.conf

Reason SoU Reason S-C(=)

eindhoven university of technology master a requirements ... · a requirements model of the osi...

Documents