Eindhoven University of Technology MASTER. An architecture for an OSI-protocol (layer 6) Verhaak, P.C.H.M. Award date: 1991

Transcription

1 Eindhoven University of Technology MASTER An architecture for an OSI-protocol (layer 6) Verhaak, P.C.H.M. Award date: 1991 Disclaimer This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and 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 Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Download date: 15. Jun. 2018

2 6300 r':() <"/...)('(v An architecture for an OSI-protocol (layer 6) P.C.H.M. Verhaak Faculty of Electrical Engineering Digital Information Systems Group Eindhoven University of Technology Eindhoven, december 1991 Coach: Supervisor: ir. M.J.M. van Ween Prof. ir. M.P.J. Stevens The department of Electrical Engineering of the Eindhoven University of Technology does not accept any responsibility regarding the contents of student project- and graduation reports.

3 Abstract. At the Digital Infonnation Systems Group of the Department of Electrical Engineering at the Eindhoven University of Technology research has started on the development of the sixth layer of the OSI reference model: the presentation layer. This thesis contains a full review of the presentation layer, as well as the manner this layer can be modeled using the method of Hatley and Pirbhai. The presentation layer is concerned with the preserving of the meaning of the data to be exchanged between two peer application entities, not with the bit pattern. To maintain the meaning of the data, the presentation layer uses two kind of syntaxes: the abstract syntax and transfer syntax. The abstract syntax is used to describe the data types to be transferred between two application entities. The transfer syntax is used by the presentation layer to perfonn a translation of the data, described by an abstract syntax. The pairing of an abstract syntax and transfer syntax is called a presentation context. Which presentation contexts are being used during a connection, is negotiated between the peer application and presentation entities. The resulting sets ofactive presentation contexts is called the defined context set (DCS). The presentation layer can be modeled using three major subprocesses: the presentation protocol machine, the context management and the encoder/decoder. The presentation protocol machine takes care of the communicating aspects of the presentation protocol, the context management keeps track of the DCS during a connection, and the encoder/decoder encodes or decodes data into or from a bitstream using the correct abstract and transfer syntax. In tum the encoder/decoder process can be modelled roughly utilising three subprocesses: a parser process, a deparsing process and a process which contains a microprocessor. The parsing process parses the data from the application layer and puts the result into a value tree. The deparsing process perfonns the reverse task. The micro processor accomplishes the actual encoding or decoder procedure, that is from the value tree into a bitstream or vice versa. This encoding or decoding procedure of the micro processor is executed using a routine which is made according the proper abstract and transfer syntax. Development of the presentation protocol machine and the context management is still being done by M.e.A. Hurkmans and will be reported in his thesis. Abstract. iii

4 Contents. Abbreviations List of figures. List of tables. vii ix xi 1. Introduction 1 2. The OSI reference model Layer hierarchy and functionality Layer interaction Interaction between peer entities Interaction between adjacent entities Service Primitives Summary The task of the Presentation Layer Data representations Data compression Network security and privacy Summary The abstract syntax Abstract Syntax Notation The ASN.l Primitive types The ASN.l Constructors The ASN.l quasi-primitive types OPTIONAL and DEFAULT Tagging Value notations in ASN.l The principle of abstract syntaxes in the Presentation Layer Summary The Transfer syntax Basic Encoding Rules The Identifier octets The length octets The contents octets Example of B.E.R Other transfer syntaxes The defined context set Summary. 29 Con~n~. v

5 6. The presentation protocol machine The Presentation Service primitives The session service primitives The services of the presentation layer Connection establishment and release Context management Data transfer The Presentation Protocol Data Units Summary Formal description method The requirements model The architecture model The architecture modules The components of the architectural model The CASE tool ProMod Summary Modelling the Presentation Layer The context diagram of the presentation layer The flow diagram of level Summary ModelIing the encoder/decoder The alternatives for an encoder/decoder Alternative Alternative Alternative Choosing an alternative The model of the encoder/decoder The value tree and parser/deparser The encoder/decoder micro processor The testing for the context set Summary to. Conclusions and recommendations Conclusions Recommendations Literature. 63 Appendix A: ProMod structured analysis report. 63 vi Contents.

6 Abbreviations. ACD AFD AID AIS AMS APDU ASN.l BER ceo CCITI CD CPO CS CSPEC DCD DCS DFD FD FU ICI IDU ISO MSP OSI PCI PCDL PCDRL PDU PICI PIDU PPCI PPDU PPM PSAP PSAPI PSDU PSPEC SAP SAPI SDU SICI SIDU SSAP SSAPI SSDU TLV Architectural Context Diagram Architectural Flow Diagram Architectural Interconnect Diagram Architectural Interconnect Specification Architectural Module Specification Application Protocol Data Unit Abstract Syntax Notation One Basic Encoding Rules Control Context Diagram International Telegraph and Telephone Consultative Committee Context Diagram Control Flow Diagram Context Set Control Specification Data Context diagram Defined Context Set Data Flow Diagram Flow Diagrams Functional Unit Interface Control information Interface Data Unit International Standards Organisation Mini Specification Open Systems Interconnection Protocol Control Information Presentation Context Definition List Presentation Context Definition Result List Protocol Data Unit Presentation Interface Control Information Presentation Interface Data Unit Presentation Protocol Control information Presentation Protocol Data Unit Presentation Protocol Machine Presentation Service Access Point Presentation Service Access Point Identifier Presentation Service Data Unit Process Specifications Service Access Point Service Access Point Identifier Service Data Unit Session Interface Control Information Session Interface Data Unit Session Service Access Point Session Service Access Point Identifier Session Service Data Unit Type, Length, Vale Abbreviations. vii

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

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

9 1. Introduction. Nowadays the need for communication between different computers is a must. For example access to different databases is needed allover the world. However the problem arises that in general the data representation of two computers is not the same. It is possible that the receiving computer obtain all the correct data, pertlaps with the help of error detecting codes and the right protocols, but does not understand the data. To solve this problem ISO designed in the seven-layered OSI reference model the sixth layer or the Presentation Layer. The Presentation layer takes care of the conversion between the different kinds of data representations in order to allow two different computers to communicate in a correct manner and to understand each other. In general the presentation layer is concerned with the meaning of the information transported from one computer to the other. All problems relating to the presentation of transmitted data, including conversion, encryption, and compression is placed in this layer. During my graduation period at the faculty of electrical engineering of the Eindhoven University of Technology, my task was to start research on the presentation layer. The purpose of this research is to come to an hardware/software architecture for the Presentation Layer. Therefore, first a thorough study on the OSI model was needed, in particular the presentation layer. Next, to model the presentation layer, I used the method of Hatley and Pirbhai, described in the book "Strategies for Real Time System Specification" [HATL,'87]. This method is the real-time variant of the SASD method of Yourdon. My work in the modelling of the presentation layer has been the determination of the different parts in which the presentation layer can be divided, and the manner an encoder/decoder process of the presentation layer can be modelled. This thesis is meant for the readers, who are a little familiar with the OSI model, and who want to know exactly what the tasks of the presentation layer are, as well as the way these tasks are performed by the presentation layer according the recommendations of the CCrIT. The thesis contains a full review of the presentation layer, and a possible model for the presentation layer according the method of Hatley and Pirbhai. This thesis is divided into two parts. The first part (chapter 2-6) contains a review of the presentation layer. In chapter 2 the OSI model is explained briefly, to rehearse the different parts of the OSI model and the communication between the different layers. In chapter 3 the task of the presentation layer is described to give the reader insight in the different services the presentation layer can provide. In chapter 4 the use of abstract syntaxes, in particular ASN.I, is explained. An abstract syntax is used by the application layer to describe the data to be exchanged in a formal way. In chapter 5 the transfer syntax, in particular BER, is depicted. The transfer syntax is used by the presentation layer to transfer the data described by an abstract syntax. The presentation protocol machine, used to handle the different service requests, and to negotiate which abstract syntaxes and transfer syntaxes will be used during a connection, is described in chapter 6. Introduction. I

10 The second part (chapter 7-10) consists the mcxlelling of the presentation layer. Chapter 7 gives the reader a brief review of the method of Hatley and Pirbhai, which is used to model the presentation layer. In chapter 8 is given the communication of the presentation layer with the other OSI-Iayers, as well as the different subprocesses of the presentation layer in which the presentation layer can be divided. In chapter 9 the model of a sub-process of the presentation layer is presented: the encoderdecoder. Finally in chapter 10 the conclusions are given. 2 An architecture for an OSI-protocol (layer 6).

11 2. The OSI reference model. To standardize and structure the design of modem computer networks, the International Standards Organization (ISO) designed the OSI Reference Model. The OSI model consists of seven layers, each with it's particular well defined function. These seven layers together make up a stack where each higher layer uses the services of the lower layer to talk with the corresponding layer of another computer system. A communication system consists of two of these stacks communicating over OSI. The OSI model, taken from [TANE,'89l, is shown in figure APDU PPDU 5 ~ '---~r----,":"""""""""""""sessioo'proiocoi"""""'" ~ :'---~r-----' SPDU 4 ::: :: '------",<----' Transport protocol '-----.~----' TPDU 3 Packet 2 physical connection Frame Bit Figure 2.1 The 7 layered OSI model. 2.1 Layer hierarchy and functionality. Layer n on host A carries out a conversation with layer n on host B. The rules and conventions used in this conversation are collectively known as the layer n protocol. The entities comprising the corresponding layers on the different machines are called peer processes. In reality, no data are transferred directly from layer n on one machine to layer n on another machine. Instead, each layer passes data and control information to the layer immediately below it, until the lowest layer is reached. Below layer 1 is the physical medium through which the actual communication occurs. In figure 2.1 virtual communication is shown by dotted lines and physical communication by solid lines. Between each pair of adjacent layers there is an interface. The interface defines what primitive operations and services the lower layer offers to the upper one. The different layers are: The Physical Layer, which takes care of transmitting raw bits over a physical communication channel. The OSI reference model. 3

12 The Oata link Layer, which task is to take a raw transmission facility and transfonn it into a line that appears free of transmission errors to the netwoix layer. It is also concerned with traffic control, in order to prevent a fast transmitter from drowning a slow receiver. The NetwoIX Layer is concerned with controlling the operations of the sub-net. It creates a path over which subsequent communication can occur. Besides routing, the netwoix layer deals with relaying. This is to allow data transmissions from one sub-netwoix to another. The Transport Layer function is to accept data from the session layer, split it up into smaller units when needed, pass these to the netwoix layer, and ensure that the pieces all arrive correctly at the other end. The Session Layer allows users on different machines to establish sessions between them. The Presentation Layer is concerned with the syntax and semantics of the infonnation transmitted. It also provides data compression and data encryption. The Application Layer contains a variety of protocols that are commonly needed. For example: a) file transfer and job management b) message handling services c) job transfer and remote job management. 2.2 Layer interaction Interaction between peer entities. Consider layer (N+ 1), at a transmitting station who wishes to communicate with his peer entity. This can be achieved by sending Protocol Oata Units (POU) to his peer entity. Since there is no physical connection between these peer entities, layer (N+ 1) has to use the services of layer (N), and translates his (N+ 1) POU into a (N) Service Oata Unit (SOU). This is done to create a virtual connection between peer entities. Layer (N) at the transmitting station receives the (N) SOU from the (N+1) layer, and adds "header" infonnation to the data (see figure 2.2). The header is called Protocol control infonnation (PCI) and is used to instruct the peer layer (N) entity. The important point to understand is that at the receiving site, the layer entities use the PCI created by the peer entity at the transmitting site to implement actions. The (N) PCI together with the (N) SOU fonn the (N) POU and is translated into a (N-l) SOU. n-2 PCI I n-1 PCI ~-nsdu-'l \ I~ npdu ~ ~ n-1 PDU ~ ~""'I n-2 PDU I~~ Figure 2.2 Encapsulation of POUs. 4 An architecture for an OS/-protocol (layer 6).

13 The (N-l) layer acts the same as the (N) layer described above, and this process is repeated until the data reaches the bottom layer: the physical layer. When the data is received by the destination receiver, each layer receives POU and strips off the correct PCI. Eventually layer (N+1) of the receiving station receives the correct (N+l) POU Interaction between adjacent entities. As seen above a (N) layer communicates with both the (N+l) and (N-l) layer. Figure 2.3 depicts the situation as we zoom in on a particular (N) layer with it's adjacent layers. In general, each layer entity is concerned with three areas: Service. The set of services it offers to its (upper layer) user. Protocol. The functions it performs, in conjunction with a corresponding layer entity in a remote end-system. Use of services. The services provided by its subordinate layer and used to carry out the (higher layer) services which it provides. LAYERS N+l PDU N N-l Etc. Figure 2.3 OSI Layer Components A layer (N) entity (=service provider) receives from it's layer above (=service user) Interface Oata Units (IOU). These consist of both SOU, mentioned above, and Interface control information (IOU). IOU is passed exclusively between two adjacent layers to control the communication. We review the five components which are involved in the layers' communications process. SDU (service data unit). Consists of user data and control information created at the upper layers which is transferred transparently by layer N+l to layer N, and subsequently to N-l. The SOU identity is preserved from one end of an (N)-connection to the other. The OSl reference model. 5

14 PCI (protocol control infonnation). Infonnation exchanged by peer (the same) entities at different sites on the network to instruct an entity to perfonn a service function (that is, headers and trailers). PDU (protocol data unit). The combination of the SOU and PC!. ICI (interface control infonnation). A temporary parameter or parameters passed between N and N-I to invoke service functions between the two layers. The primitive typically perfonns this function. IDU (interface data unit). The total unit of infonnation transferred across the layer boundaries; it includes the PCI, SOU, and la. The IOU is transmitted across the service access point (SAP). Summarised: (N) to (N) remote entities use: pa for control User data (SOU) POU combines the pa and SOU (N+1) to (N) adjacent entities use: ICI for control User data (SOU) IOU combines the ICI and SOU Each layer has one ore more Service Access Points (SAP) identified by a Service Access Point Identifier (SAPI). Services are available through these (N) SAP which are placed on the boundary between the (N+ 1) and (N) layer. 2.3 Service Primitives When a layer wants service from a lower layer, it must identify which service, for example connection establishment. For this purpose OSI has supplied Service Primitives and SAPs. Four kind of primitives, are invoked to and from the layer through the SAPs (some sessions do not require all primitives): 6 An architecture for an OS/-protocol (layer 6).

15 Request: Primitive by service user to invoke a function. Indication: Primitive by service provider to: a) invoke a function b) indicate a function has been invoked at a service access point (SAP) at the peer entity. Response: Primitive by service user to complete a function previously invoked by an Indication at that SAP. Confirm: Primitive by service provider to complete a function previously invoked by a Request at that SAP. We take as an example a confirmed service (fig. 2.4), for example connection establishment (1) A Service Request primitive is initiated by the service user of layer n. (2) The peer layer n entity gives a Service Indication Primitive to it's service user. (3) To confirm the Service Indication Primitive the peer service user of layer n gives a Service Response Primitive, (4) which appears as a Service Confirmation Primitive on the other side to the layer N service user. n service primitive request. n service primitive confirm. n service primitive response n service primitive indication. Host A Layern :. :.... : Host B Layern : : ~ ~ I. : ~,,.-,: Transport through the lower layers. Figure 2.4 The service primitives of a confirmed service. In case of an unconfirmed service, for example an user abort, (3) and (4) are omitted. The OSl reference model. 7

16 It's also possible that only a Service Indication Primitive appears, usually used to abort a connection.(see figure 2.5) n service primitive indication. n service primitive indication. Host A Layer n Host B Layern 2.4 Summary. Figure 2.5 The service primitives of a indication service. In this chapter, the OSI reference model is described where a communication system is divided into 7 layers, each with a particular task. We have seen that each layer has a virtual connection with his peer, used to carry out a certain protocol. To establish a connection, each layer has to use the services provided by the layer below. Peer layer entities exchange information through PDUs. This is done by the sending of SDUs to his lower layer through SAP. To make a universally applicable model of the presentation layer, we have to use the OSI reference model. On this manner the model of the presentation layer can be easily fitted between the application and session layer. 8 An architecture for an OSI-protocol (layer 6).

17 3. The task of the Presentation Layer. As seen before the presentation layer is the sixth layer of the OSI model and is placed between the application layer and the session layer. Application layer PSA~ PIDU's Presentation layer SS~ SIDU's '-' Application layer Ii PPDU's...:~::. Presentation layer... Ii Session layer Session layer I 1'-- "'1 r Figure 3.1 The place of the presentation layer in the OSI-model In the pastthe Presentation Layerwas onlyused to allow ASCII machinescommunicate with EBCDIC machines or to permit visually-oriented programs (for example full screen editors) to work with a variety of terminals. Now the Presentation Layer's role is to provide the proper means of transferring information so that the original meaning may be preserved during the transfer together with data encryption and data compression Now the job of the presentation layer is on one side to encode structured data from the internal format used on the sending machine to a bit stream suitable for transmission, and on the other side to decode the bit stream to the required representation at the receiving machine. 3.1 Data representations. The lower five layers are only interested in transporting raw bits from one end of the connection to the other. The presentation layer is concerned with the syntax of the information which is being sent. It's possible that the user, despite of all the effort which is taken in protocols of the lower layer, still is not able to communicate because he does not Wlderstand the bits. Most programmes do not exchange random binary bits, but they use things like the names of people, a data or the amount of money. These things are represented by characters, strings, integers, floating point numbers, and data structures composed by primitive types. In the programming language pascal the data structures are called "records" and in C "structures". The task of the Presentation Layer. 9

18 There are different kinds of data representations: a machine can have EBCDIC or ASCII as the character code. A machine can use two's complement arithmetic on 16 or 32-bit integers or 60-bit one's complement. The numbering of bytes can be from left to right. the big endian computers (for example with the MOTOROLA 68000, and microprocessor), or from right to left, the little endian computers (with the INTEL 8088, and microprocessors). These different kind of data representations can cause errors. Example: Bank A wants to transmit a certain amount of money, 10 dollars, represented by integers to bank B. Bank A is a little endian computer and uses 4 bytes for the representation of integers. Bank B is a big endian computer and uses also 4 bytes for the representation of integers. Bank A sends respectively an [10] [0] [0] and [0] which bank B receives in the correct order. Bank A msb~lsb Bank B o msb~lsb Now bank B thinks that he receives lox2 24 or 176,772,166 dollar. Unfortunately manufacturers rarely change their conventions to avoid having their new products to be incompatible with their old ones. So it is unlikely that there will be universal standards for internal data representations. To solve this problem conversion must be made somewhere, for example in the Presentation Layer. There are different solutions for this problem: (1) the sender could do so the conversion of the data (2) the receiver could do the conversion (3) both the sender and receiver could convert to and from a network standard format. Each solution has it's advantages and disadvantages. Solutions (1) and (2) are faster and easier, (3) is relatively slow and complex. This is because the data has to be converted twice in solution (3) instead of once in case of solutions (1) and (2). If, for example, a one's complement machine is talking to another one's complement machine, they can speak one's complement in case of (1) and (2). For solution (3) it is possible that conversions are needed on both ends because it is possible that the network standard format specifies that two's complement must be used. The solution (3) does require less conversion routines. In solutions (1) and (2) every machine must be aware of the internal format used by every other machine in the network. When an 10 An architecture for an OS/-protocol (layer 6).

19 APDU (Application Protocol Data Unit) is build by the application layer, it builds it in the fonn that the receiver expects. With 0 different types of machines in the network 0 x (0.1) different conversion routines must be written, instead of just 20 for solution (3). If a new machine appears in the network, only one conversion routine has to be written for only that new machine in case of solution (3), while for solution (1) and (2) new conversion routines have to be written for all existing machines. The OSI model uses the third solution and here the network standard fonnat of data representation is called Abstract Syntax Notation 1 (ASN.l). 3.2 Data compression. The cost of using a network depends on the amount of data sent. It is possible to reduce the bill by compressing the data before sending them. Data compression is closely related to data presentation. One way to transmit a 32-bit integer is to simply encode it as 4 bytes in some representation and sent it on its way. However, if it is known that 95 percent of the integers transmitted are between 0 and 250, it may be better to transmit these integers in a single unsigned byte, and to use the code 255 to signify that a true 32-bit integer follows. While it is true that once in a while five bytes will be needed instead of four, the gain from being able to use one byte most of the time, offsets this loss. This can be done in the Presentation layer. 3.3 Network security and privacy. In networks data can travel from one place to another without physically seeing or feeling it. Therefore it is possible that a unauthorized person is wiretapping, or is secretly copying your data without knowing it if your data is not protected. Some kind of encryption is needed to make the data unintelligible to all but their intended recipient. Protecting data is not the only issue in networking. There are at least 4 security services: Protecting data from being read by unauthorized persons. Preventing unauthorized persons from inserting or deleting messages. Verifying the sender of each message. Making it possible for user to send signed documents electronically. Encryption can be used to achieve all these goals. In theory encryption can be done in any layer, but in practice encryption is possible in three layers: The physical layer, the transport layer and the presentation layer. The task of the Presentation Layer. 11

20 If encryption is done in the physical layer it is called link encryption. Every bit is encrypted by leaving the machine and decrypted by entering a computer. This method is very inflexible.if encryption is done in the transport layer the entire session is encrypted. Finally to let encryption take place in the presentation layer is the best and most flexible solution. 3.4 Summary. In this chapter is described the function of the presentation layer. Its primary function is to preserve the meaning of the application data during the communication process. This can be done by converting the data to a mutually understood format. Other functions of the presentation layer are encryption and compression of the application data. 12 An architecture for an OSI-protocol (layer 6).

21 4. The abstract syntax. Peer application processes exchange infonnation by the use of the presentation services. The unit of exchange is known as infonnation unit, or simply as data. When an application entity wants to exchange infonnation units with his peer, it has to use the services of the presentation layer. Before the presentation layer can service the request of the application layer, it has to know the structure of the data which the application layer will sent The description of a data type or structure is called an abstract syntax. The word "abstract" is used because we do not want to describe a data type on bit level. Forexample an application wants to access a students data-base from a peer application entity. In that case a lot of data has to be sent in the fonn of records. The structure of the data, a students record, to be sent between the peers, defined by the application layer, is as follows: STUDENT: NAME INITIALS ID_NUMBER GENERATION FEMALE {characters } {characters } {an integer} {an integer} {a boolean: TRUE means female; FALSE means male} The way the data structure is described is called an abstract syntax notation. The abstract syntax notation must be flexible and standard enough for many applications. Many programming languages use abstract syntax notations to define their variables, for example Pascal: type Student = record NAME: string; INITIALS : string; ID_NUMBER : integer; GENERATION : integer; FEMALE : boolean end; The abstract syntax notations of Pascal and C are not standard and not flexible enough. There are many dialects. For example, not every Pascal compiler supports the "string" notation which is used in our example. Besides, they are not always able to describe all data types and structures. Which abstract syntaxes to be used is negotiated by the peer application layers. This negotiation process will be explained in chapter Abstract Syntax Notation 1. The ISO and CCITT have developed a presentation syntax to be used by application layer protocols. The widely used specification is ISO 8824 which is aligned with the Blue Book recommendations X.208 of the corr and is titled: Abstract Syntax Notation I (ASN.1). The notation was intended The abstract syntax. 13

22 primarily for human consumption. Being a formal language, it is also well suited for automated processing. Each piece of information exchanged between users has a type and a value. The type is a class of information such as numeric, boolean, alphabetic, etc. The value is an instance of the type, such as an number or a piece of alphabetic text. In order for machines to know how to interpret data, they must know the type first. - ASN.l describes an abstract syntax for data types and values, and is similar to the data definition statements found in languages such as Pascal, Ada and C. ASN.l is defined by a context-free grammar. With this grammar we can build an ASN.l compiler, which can check if the syntax notation is correct For a full description of this grammar we refer to the CCITf blue book recommendations X.208, appendix II [VIII.4,'88]. We will now give a short review of ASN The ASN.l Primitive types. The primitive types of ASN.l (see table 4.1) are build into the language and form the building blocks of more complex types. The names of these types are reserves words, and, like all ASN.l reserved words, are always written in upper case letters. Tabel 4.1 The ASN.l primitive types. Primitive Type Meaning INTEGER BOOLEAN BIT STRING OCTET STRING REAL ANY NULL OBJECf IDENTIFIER OBJECf DESCRIPTOR ENCRYPTED ENUMERATED Arbitrary length integer. TRUE or FALSE. List of 0 or more bits. List of 0 or more bytes. A real number. Union of all types. No type at all. Object name (e.g., a library). Human readable object name. The result of encryption. Distinct identifiers. Integers identifies signed whole numbers. They do not have a maximum size. Booleans identifies logical data (TRUE or FALSE). Bit strings are ordered lists of bits and each bit string has 0 or more bits, with no maximum. The value of type BITSTRING is written between single quotes, followed by the letter B (binary) or H (hexadecimal). Example: 'OIOOI'B or '2A'R Octet strings are ordered lists of octets, which is OSI jargon for bytes. They are used to represent octet-oriented data, like characters. 14 An architecture for an OS/-protocol (layer 6).

23 Reals are all numbers capable of being specified by the formula M x BE, where M, called mantissa, B the base and E the exponent, are all integers. B can take the values 2 or to. Also the values PLUS-INFINITY and MINUS-INFINITY are allowed. ANY is the union of all types. If a field of a record is declared of type ANY, it can later be filled in by any valid type. NULL is no type at all. It could be a valueless place holder in which there are several alternatives but none of them apply. When a field of a record is assigned the value NULL, it has no value. When it is transmitted, the NULL fields do not have to be sent. The OBJECf IDENTIFIER consists of multiple words, usually enclosed by braces, used to identify an abstract syntax, encoding rule and protocol to be used by the application. It is intended for consumption by machines. The OBJECf DESCRIPTOR is a human readable string identifying an abstract syntax. ENUMERATED denotes a simple type where its values are given as distinct identifiers. It is associated with an integer. For example in case of two possible objects: screw and nut, screw can be identified with the integer 1 and nut with the integer 2. ENCRYPTED is a type whose value is the result of an encryption of another type The ASN.l Constructors. The primitive types can be combined to build more complex types. In ASN.l we use the constructors listed in table 4.2. Tabel 4.2 The principal ASN.l constructors. Constructor Meaning SEQUENCE SEQUENCE OF SET SET OF CHOICE EXTERNAL Ordered list of various types. Ordered list of a single type. Unordered collection of various types. Unordered collection of a single type. Anyone type taken from a given list. Refer to another, not included, type. SEQUENCE is used to combine a collection of types to form a new type, just like in Pascal. The fields of a SEQUENCE may be any types, including constructed types. SEQUENCE OF is employed to build arrays of a single type. This single type may be any type, including constructed types to create an array of records. The SEQUENCE OF do not have any boundaries. SEQUENCE OF is comparable with a "file of' type in Pascal. The SET constructor is similar to SEQUENCE, except that the order of the components is not guaranteed to be the same in the receiver as broadcasted by the transmitter. Analogous SET OF is similar to SEQUENCE OF, with the difference that the elements have no inherent ordering. The abstract syntax. 15

24 CHOICE is utilized when a data structure can hold anyone from a collection of alternative types. It allows a data structure to hold more than one type. The EXTERNAL type allows one abstract syntax to refer to something from a different one, without having to textually include the other one. We can now give the student record from the example above in ASN.l: Student ::= SEQUENCE { name OCfET STRING, initials OCfET STRING, id_number INTEGER, generation INTEGER, remale BOOLEAN The ASN.l quasi-primitive types. In addition to the primitive types and the constructed types, the ASN.l standard also discusses some predefined types that are useful in many applications (see table 4.3). Eight different string types are defined. Each one is a different subset of OCfET STRING. Tabel 4.3 The ASN.l quasi-primitive types. NumericString PrintableString TeletexString VideotexString VisibleString IA5String GraphicString GeneralString GeneralizedTime UniversalTime The NumericString only includes the ten digits 0 through 9 and the space. The PrintableString includes the upper and lower case letters, the ten digits, space, and 11 characters: ()'+-.,/:=? The TeletexString, VideotexString, VisibleString, IA5String, GraphicString and GeneralString are defined in ISO They are provided for the teletex character set, the videotext character set, various international versions of ASCII, and some graphic character sets. GeneralizedTime consists in general of the time in the following notation: [4 digit year] [2 digit month] [2 digit day] [hour] [minutes] [seconds]. For a complete study of the format allowed: see the CCIIT Blue Book Recommendation X.208. UniversalTime embraces the time of the format YYMMDDhlunm. As for GeneralizedTime for a complete review we refer to the CCIIT Blue Book Recommendations X An architecture for an as/-protocol (layer 6).

25 4.1.4 OPTIONAL and DEFAULT. In some cases it is possible that a data field is not used and stays empty. In this situation the data field does not have to be transmitted. To handle this situation, ASN.l allows fields to be declared OPTIONAL. Alternatively, a data field can be declared DEFAULT, followed by the value to be used by the receiver if the particular data field is not transmitted Tagging. The purpose of tagging is closely related to the encoding rules and transfer syntaxes described in chapter 5. Whenever the value of an item is transmitted, its type is sent as well. The type field is in fact a code and is used to identify the value. We also call the type field a tag. ASN.l uses 4 different types of tags, also called classes (see Table 4.4). Tabel 4.4 The four types of tags. UNIVERSAL APPLICATION PRIVATE context specific Each tag consists of one of the reserved words of table 4.4 (in case of context specific no reserved word is used), followed by an integer. Tags are written between brackets. The UNIVERSAL tags are used for the reserved primitive and quasi-primitive types defined in the ASN.l standard. They are application-independent and are listed in table 4.5. The tag numbers identify the different kind of primitive and quasi-primitive types, and are useful when such a type is transmitted. This subject is described in chapter 5. Tabel 4.5 The tags of the UNIVERSAL types. Tag Meaning Tag Meaning BOOLEAN type INTEGER type BIT STRING type OCTET STRING type NULL type OBJECT IDENTIFIER type OBJECT DESCRIPTOR type EXTERNAL type REAL type ENUMERATED type Encrypted type Future recommendations SEQUENCE & SEQUENCE OF type SET & SET OF type NumericString PrintableString TeletexString VideotexString IASString Universal Time Generalized Time Graphic String Visible String General String Future recommendations The abstract syntax. 17

26 Suppose that a SEQUENCE 'Numbers' consists of 4 fields, all of them declared as INTEGER and all optional: Numbers ::= SEQUENCE { value1 INTEGER OPTIONAL value2 INTEGER OPTIONAL value3 INTEGER OPTIONAL value4 INTEGER OPTIONAL Assume only two of them are transmitted. How does the receiver know which two they are? This problem is solved by giving the integers an extra context specific tag to identify the different fields. Now the receiver can identify the different fields by looking at the context specific tags. Furthennore, if the receiver can tell which item it is getting by looking at the context specific tag, there is no need to send the UNIVERSAL type tag. ASN.I provides a way to have the type infonnation suppressed when extra tagged types or fields are sent To suppress this infonnation, the person writing the abstract syntax can add the reseived word IMPLICIT after the extra tag. Numbers ::= SEQUENCE { value1 [0] IMPLICIT INTEGER OPTIONAL value2 [1] IMPLICIT INTEGER OPTIONAL value3 [2] IMPLICIT INTEGER OPTIONAL value4 [3] IMPLICIT INTEGER OPTIONAL If IMPLICIT is not included after a tag, both the tag and the type are sent, as a kind of run-time checking. The APPLICAnON tag is used by many OSI application layer protocols to denote types used in those protocols. The PRIVATE tag is applied by the users to denote their own types. With this knowledge we can now rewrite a student record with the right tags: Student ::= [PRIVATE 1] IMPLICIT SEQUENCE { name [0] IMPLICIT OCTET STRING initials [1] IMPLICIT OCTET STRING, id_number [2] IMPLICIT INTEGER OPTIONAL, generation [3] IMPLICIT INTEGER, female [4] IMPLICIT BOOLEAN DEFAULT FALSE At the data transfer phase the transmitter and receiver are aware of the abstract syntax of the students record identified by the [PRIVATE 1] tag. The PRIVATE tag is used because the record is made by the user. The tag of SEQUENCE does not have to be sent because the structure of the students record is mutually known. Therefore we use IMPLICIT after the SEQUENCE. The data fields within student are all identified by context specific tags. We take as example the first data field name. Knowing the tag, the receiver knows what data is being sent, so the OCTET STRING definition can be omitted by the transmitter. Therefore again IMPLICIT is used. The data field 18 An architecture for an OS/-protocol (layer 6).

27 id_number is declared OPTIONAL and does not have to be sent by the transmitter. Finally the boolean data field female is declared together with the DEFAULT value FALSE. In case the transmitter does not send the female data field, the receiver knows that the value FALSE is meant Value notations in ASN.l ASN.l also provides a way to define values of the types we have written. When the SEQUENCE, SEQUENCE OF, SET or SET OF constructors are used, we notate the corresponding data fields between accolades. When such a constructed type within a constructed type is placed, nesting of accolades is possible. The data fields of a structure are separated by commas. If a name is associated with a data field (which is usually the case) this name has to precede the actual data value. Octet strings are given between quotation marks. An example of the students record is given below. { name "Jones", initials "M.S.E."-, id_number , generation 85 } This notation, defined within the ASN.l standard, is only used to describe the value of a type on a formal way. It is designed to illustrate possible values of a data type declared in ASN.1. It is, however, also possible for automated processing. 4.2 The principle of abstract syntaxes in the Presentation Layer. When all the data types needed by an application are defined in ASN.l, they are put together in a module (or a library) and passed on to the presentation layer of the two communicating systems. (1) When an application wants to transmit a data structure it can pass the data values to the presentation layer, along with the name ofthe data structure (for example "student"). Using the abstract syntax of student as a guide, the presentation layer then knows what the types and sizes of the fields are, and thus knows how to encode them for transmission. (2) At the other end of the connection, the receiving presentation layer looks at the first encoded tag of the data structure, and thus knows how many bits belong to the first field, how many to the second, their types and so on. Armed with this information, the presentation layer can do any necessary conversions from the external format used on the wire to the internal format used by the receiving computer. 4.3 Summary In this chapter we have seen how data structures, exchanged by application entities, can be described using an abstract syntax notation. The abstract syntax notation 1, described in the recommendations X.208 of the CCITI, was studied in full detail. We have seen that ASN.l allows us to universally describe all possible data structures. We will apply this knowledge in the next chapter to encode the data values, described by an abstract syntax, into a bitstream, according to certain encoding rules. The abstract syntax. 19

28 5. The Transfer syntax. There are three fonns of representation (encoding) of the contents of an infonnation unit when it is sent between peer entities: Source: Destination: Transit: The encoding in the real storage on the transmitting end-system. The encoding which will be used by the receiving end-systems to store the infonnation in its own real storage. The encoding understood by both end-systems and used when the infonnation is in transit over a session connection. As seen before it is possible that the transit encoding may be either the source, or the destination encoding (or both in the special case of similar systems communicating), but it is often the case that it is neither of these. On behalf of application processes, peer presentation entities exchange infonnation over a session connection, encoded in a precise representational fonn understood by the peer presentation entities: the transit coding. A commonly understood transit encoding is known as a transfer syntax. The presentation layer translates the data, described by the abstract syntax, into a bitstream according to the transfer syntax. The fonnat of the bit-stream is defined by this transfer syntax. There are many transfer syntaxes possible: each will use different encoding rules to transfer the data into a bitstream. The decision which transfer syntaxes to be used, is negotiated by the peer presentation layers and will be explained in chapter Basic Encoding Rules. As for ASN.l, the ISO and CCITI have developed a transfer syntax to be used by the Presentation Layer. The widely used specification is ISO 8825 which is aligned with the Blue Book recommendation X.209 and is titled: Specification ofbasic encoding rules for abstract syntax notation one (ASN.l). X.209 describes the actual encoding rules for the values of types, in contrast to X.208, which is concerned with the abstract structure of the infonnation. The Basic Encoding Rules are abbreviated with B.E.R. The guiding principle behind the ASN.l transfer syntax is that each value transmitted, both primitive and constructed ones, consists of three components, which appear in the following order: Identifier Length Contents The transmitted value is called a data element. The identifierdistinguishes one type from another and specifies how the contents are interpreted. The length specifies the length ofthe contents. The contents (also called value) contains the actual infonnation of the element. The data element is also identified by the tenn TLV (Type-Length-Value). The transfer data element is illustrated in figure 5.1. It can consist ofa single TLV or a series ofdata elements, described as multiple TLV. The element consists of an integral number of octets, written with the most significant bit (MSB or bit 8) on the left and the least significant bit (LSB or bit 1) on the right. The transfer syntax. 21

29 Om elernerd ~ ErE (al Single Element Oataelemerd r a , Oataelemerd Data elernel'd IderdHier Length Identifier Lenglh CordenlS (b) Mullibla Elementa Note (1) The IdentHier field ia also called 1he 1ypll. No1e (2) The Cordenllfield ia also called 1he value. Figure 5.1 The X.209 Data Elements The Identifier octets. The identifier is coded as depicted in Figure 5.2 and contains the value and type of the tags, also called class (see section 4.1.5). For tags with a number ranking from zero to 30 (inclusive), the identifier comprises a single octet (figure 5.2.a). For tags with a number greater or equal to 31, the identifier comprises a leading octet followed by one or more subsequent octets. (figure 5.2.b). In case of a single-octet identifier distinguishes bits 8 and 7 the four classes. Bit 6 identifies the forms of the data element. Two forms are possible. A primitive element (bit 6 =0) has no further internal structure of data elements. A constructor element (bit 6 = 1) is recursively defined in that it contains a series of data elements. The remaining five bits (5 to 1) contain the tag number. IderdHier OCIet ~ EEI"_ ~ ~ (a) Single-oc:tet identhier Class bh 8bH 7 0 O,>versat o 1 Application 1 0 Conlllxt-specilic 1 1 Private F: Form of 1he elemerd o bh6 prml1lve 1ypll 1 oonstrucl8d 1ypll Leading OCl8t 2nd OCl8t 3n:t octet ~ A A EEl' ',,'~[II~1 last 0CI8I + (b) MoAtibIe 0CI8I iden1iiier number of lag Figure 5.2 X.209 Identifier. 22 An architecture for an OSI-protocol (layer 6).

30 In case of a multiple identifier is the leading octet filled as the single-octet identifier, with the difference that bits 5 to 1 are filled with the value , Ifbit 8 of a subsequent octets is coded with a I, it indicates that more octets will follow. If bit 8 of a subsequent octet is coded with a 0, it indicates the last octet. In bit 7 to 1 of the first subsequent octets, followed by bits 7 to 1 of each further octet, up to and including the last subsequent octet of the identifier octets the unsigned binary integer equal to the tag number is encoded. Bit 7 of the first subsequent bit is the most significant bit. Figure 5.2.b illustrates the use of the multi-octet identifiers The length octets. The length specifies the length of the contents. It may take one of three forms: short, long, and indefinite. The short and long form are also called the definite form. Length OCl8t ~ B , ~ (a) Deljn~e short length octet leading octet 2nd octet ~~ ' , last octet ~ , I, 0' number slbsequenl oct8lll (b) Delinite long length octets Figure 5.3 Length octets. The short form (figure 53.a) is one octet long and is used when the length is less than 128. Bit 8 is always 0 and bits 7 to 1 indicate the length of the contents. Bit 7 is the most significant bit. For example, a contents field of 38 octets long is described by the length field as oolooll~. The long form (figure 53.b) is used when the length is greater than or equal to 128. It consists of an initial octet, followed by one ore more subsequent octets. The initial octet is encoded as follows: Bit 8 is always 1, and bits 7 to 1 indicate the number of subsequent octets in the length octets. Bits 7 to 1 is a unsigned binary integer with bit 7 as the most significant bit. In bits 8 to 1 of the first subsequent octet, followed by bits 8 to 1 of each further octet up to and including the last subsequent octet is encoded the number of octets in the contents octets. It's a unsigned binary integer, with bit 8 of the first subsequent octet as the most significant bit. For example, a contents field of 201 octets long is described by the length field as 1000ooo , The indefinite form is used when data is passed from the application layer to the presentation layer in small units. Ifthe presentation entity has limited buffer space, it may be forced to start transmission before it finds out how much data there is. To handle this situation, a length code 1~ is used to indicate that the data field is of a variable length. The data field is then terminated by end-ofcontents octets. The end-of contents octets consists of two zero octets and can be considered as the encoding of a value whose tag is universal, whose form is primitive, whose number of the tag is zero, and whose contents is absent, thus: The transfer syntax. 23

31 End-of-contents Contents Absent Unfortunately, the transparency problem, which arises when between the length code :2 and the two end-of contents octets two value octets appear which are equal to the two end-of contents octets, is not solved by the CCIIT. The definite form is always used if the encoding is primitive; the indefinite form is always used when the encoding is constructed and not all data is available immediately. When the encoding is constructed and all data is available immediately, either the definite form or the indefinite form can be used as a sender's option The contents octets. The contents (value) is the substance of the element, Le. the actual information. It is described in multiples of eight bits and is of variable length. The encoding of the data fields depends on the type of data it presents. Booleans are encoded in a single octet with FALSE as 0 and TRUE as any other value. Integers are encoded in two's complements and consists of one or more octets. A positive integer below 128 requires 1 byte, a positive integer below requires two bytes, and so forth. The most significant byte is transmitted first To ensure that an integer value is always encoded in the smallest possible number of octets, in case of an encoding in more than one octet, the bits of the first octet and bit 8 of the second octet may not all be ones and may not all be zero. Bit strings are send as they are. The only problem is to indicate the length. The length field tells how many bytes belong to the value, not how many bits. This is solved by using an initial octet, followed by zero, one or more subsequent octets. In the initial octet is encoded, as an unsigned binary integer with bit 1 as the least significant bit, the number of unused bits in the final subsequent octet. The number is in the rank from zero to seven. In the subsequent octets the bits of the bit string are placed, with bit 8 of the first subsequent as most significant bit. (see figure 5.4) Initial octet slbsequent octet 1 Iasllllbsequenl oewt ~~ ==~ IIIL [ Figure 5.4 Encoding of bitstring ~ (lillie] Each octet of the octet strings are just consecutively transmitted, commencing with the first octet up to the last octet The quasi-primitive string types are encoded as octet strings. SEQUENCE, SEQUENCE OF, SET and SET OF types are transmitted by first sending the type of tag for the sequence or set itself (which is ofcourse constructed), then the total length of the encoding of all the fields, followed by the fields themselves. The fields of a sequence must be sent in order, but the fields of a set may be sent in any order. If any two or more fields of a set have the same type, they must be tagged extra so that the receiver can tell which is which. 24 An architecture for an OSI-protocol (layer 6).

32 The NULL value is indicated by having a null contents field (zero bytes long). The fact that the length field is 0 indicates that a NULL value is being sent. No numerical value is actually transmitted. The encoding of a CHOICE value is the same as the encoding of the actual data structure being transferred. If a particular choice is between an INTEGER and a BOOLEAN, and the data structure at hand is an INTEGER, then the rules for INTEGER apply. ENUMERATED values are encoded as the integer value with which it is associated. The encoding of reals are described in ISO Example of B.E.R. The structure of the hypothetical students record is formally described below using ASN.1. Student ::= SEQUENCE { Name OCfET STRING, Initials OCfET STRING, Id_number INTEGER, Generation INTEGER, Female BOOLEAN The value of F.K.L. Jonson Students record is formally described below using ASN.l. Name Initials Id_number Generation Female "Jonson", "F.K.", , 1988, TRUE } The representation on octets of the record value given above (after applying the basic encoding rules) is shown below. The values of the identifiers, lengths, and the contents are shown in hexadecimal, two hexadecimal digits per octet. The tags, marked with a number, are explained below. Student 30 (I) Length IA Contents Name Length Contents 04 (2) 06 4A 6F 6E 73 6F 6E ("Jonson") Initials Length Contents E 4B 2E ("F.K.") Id_number Length Contents 02 (3) (264521) Generation Length Contents C4 (1988) Female Length Contents 01 (4) 01 FF (TRUE) The transfer syntax. 25

33 (1): We have to decode SEQUENCE, which is a constructed type. bit =3<\i Bits 8 and 7 are both zero because SEQUENCE has a universal class. Bit 6 is 1 because it is a constructed type. Bits 5 to 1 carry the binary representation of the decimal number 16, which is the tag number of SEQUENCE. (2): We have to decode the OCfET STRING type. bit =04tt Bits 8 and 7 are both zero because OCfET STRING has a universal class. Bit 6 is 0 because OCfET STRING is a primitive type. Bits 5 to 1 carry the binary representation of the decimal number 4, which is the tag number of OCTET STRING. (3): We have to decode the INTEGER type. bit Bits 8 and 7 are both zero because INTEGER has a universal class. Bit 6 is 1 because INTEGER is a primitive type. Bits 5 to 1 carry the binary representation of the decimal number 2, which is the tag number of INTEGER. (4): We have to decode the BOOLEAN type. bit Bits 8 and 7 are both zero because BOOLEAN has a universal class. Bit 6 is 1 because BOOLEAN is a primitive type. Bits 5 to 1 carry the binary representation of the decimal number I, which is the tag number of BOOLEAN. 5.2 Other transfer syntaxes. At this moment, only one set of encoding rules has been specified for ASN.l. The Basic Encoding rules, defined by X.209 are standard and can be applied universally. It allows to encode data using a uniform recursive approach. In the B.E.R. almost all fields have a variable-size encoding, with a requirement to use exactly the minimum number of bytes necessary to convey the value. This enables flexibility, in the sense that there is no limits in data size: for example, the B.E.R. supports arbitrary wide integers. 26 An architecture for an OSI-protocol (layer 6).

34 Unfortunately, the use oftype and length fields introduces unnecessary overhead on the network, since in many cases the receiver knows what data are being sent to it In addition, the conversion process of ASN.l BER are highly CPU consuming because of the ASN-I encoding, because they are based on bytes and variable-size representation [HUIT, '89]. Therefor the final information transferred through the network is highly redundant, which is not acceptable for several "high speed" applications. If gigabit/s networks appear tomorrow, the speed of demanding applications like fast transactions or multimedia conferencing is likely to be limited by the processing power ofthe end systems. The bulk of the CPU consumption of communication protocols is not used by the protocol itself, but rather to the interaction with the operating system. Fortunately, the OSI presentation protocol incorporates a negotiation phase. An application may use a set ofseveral abstract syntaxes. For each ofthese abstract syntaxes, several transfer syntaxes can be proposed by the calling presentation entity. The responding entity will choose the most appropriate syntax and then the chosen syntax will be used. The negotiating phase will be fully explained in the next section. A faster transfer syntax is defined in [BESS, '89] and [HUIT,'89]. Most implementations have a very conservative negotiation procedure by supporting only the ASN.I B.E.R., but nothing forbids us to realize more intelligent implementations, for example by proposing: the ASN.I B.E.R., in order to guarantee interoperability. a faster transfer syntax to improve the overall efficiency by reducing the overhead of transmitted information and to provide a high speed coding and decoding mechanism, used for high speed transactions. a compressed encoding, for use on low speed networks. a transfer syntaxes for encryption, used for top secret information. 5.3 The defined context set. Only when a presentation entity knows the abstract syntax of an information unit, together with the associated transfer syntax, it can transform information units into a bitstream. An abstract syntax can be associated with a transfer syntax chosen from a set of transfer syntaxes. A single transfer syntax may also be suitable for encoding information units from a number of different abstract syntaxes. A presentation entity may know many abstract and transfer syntaxes, and must be aware of the possible correct pairings. During an application activity, many information units may be exchanged. These information units may be all of the same type, Le. defmed by the same abstract syntax. But it is also possible that a number of abstract syntaxes are required to define the different types of information units that are to be transferred. Therefore peer presentation entities should be able to handle many different abstract syntaxes during a connection. The presentation layer can be implemented in many ways. A simple presentation entity may be able to know and handle only a single transfer syntax, and may be limited in the range ofinformation unit types that can be transferred. Another may have many transfer syntaxes available. During connection establishment peer application entities must negotiate which abstract syntaxes are supported. Similar, peer presentation entities must agree on a specific transfer syntax to be used for The transfer syntax. 27

35 the infonnation units, defined by a particularabstract syntax. This is because it cannot be assumed that all transfer syntaxes which are supported by one presentation entity are also available to its peer. An abstract syntax, together with the transfer syntax is called the presentation context set. The negotiation of the different presentation context sets, which are supported during the connection, between the peer application and presentation entities is done as follows: When the application entity invokes the presentation primitive to open a connection (P CONNECf request), it has to provide, among other parameters, one parameter in which the list of abstract syntaxes to be used is specified. Every entry in the list of abstract syntaxes is a data type and carries an identification number. The presentation layer will examine this list and enriches this infonnation (for each abstract syntax) with a list of possible transfer syntaxes, before sending it over the networlc by using the session services. This enrich process is done by proposing a number of transfer syntaxes for each abstract syntax. Each couple of an abstract syntax and transfer syntax also becomes an identification number. The presentation entity then uses session services to pass the complete list of abstract syntaxes and their respective sets of transfer syntaxes to its peer. On the other side, the presentation entity will locally check this infonnation, provided by the session layer, which transfer syntaxes are supported. Then it will send the request to the local application entity which, in tum, will check the list of supported abstract syntaxes. After this double check, an answer will be sent back to the remote partner, together with a new list of the locally supported abstract and transfer syntaxes. The initiating presentation entity is now aware of the active presentation contexts. It infonns the application entity that it can go ahead and use infonnation units according the agreed abstract syntaxes. Each infonnation unit to be exchanged between peer application entities, will be delivered to the presentation layer together with the identity of the associated abstract syntax. The infonnation layer will be encoded into a bitstream by the presentation layer according the proper presentation context. The bitstream carries, as well as encoded infonnation, the identity of its presentation context. The receiving presentation entity can then perfonn the appropriate transfonnation of the received infonnation before passing the infonnation unit (together with the identity of the associated abstract syntax) to the receiving application process. The list of negotiated presentation contexts is known as the defined context set. In case where no abstract syntax list is available from the application layer, the peer presentation entities will assume that a mutually understood default presentation context is available. In this case, the encoding and decoding will be perfonned according the default presentation context. Once the presentation context set has been defined, and the dialogue between the two application entities is started, one of the presentation entities can decide to change something in the defined context set. This implies either removing already defmed presentation contexts, or adding new presentation contexts, or both. In order to do that, the presentation layer provides the P-ALTER- 28 An architecture for an OSI-protoco[ (layer 6).

36 CONTEXT seivice primitive. The context alteration seivice is achieved, similar to the connection establishment 5.4 Summary. In this chapter it is described how an information unit, described by an abstract syntax notation, can be encoded to a bitstrearn according a transfer syntax. A closer look is taken at the basic encoding rules, described by the recommendation X.209 ofthe CCITI, especially used for ASN.l. But the BER is not the only existing transfer syntax: work is being done on defming other transfer syntaxes. With the combination of an abstract syntax and a transfer syntax, the encoding of an information unit is clearly specified. This combination is called the presentation context. A set of active presentation contexts is called the defined context set (DCS). The DCS is negotiated between the peer application and presentation entities. The transfer syntax. 29

37 6. The presentation protocol machine. The presentation protocol machine (PPM), placed within the presentation-entity (figure 6.1), communicates with the application layer through a presentation selvice access point (PSAP) using presentation-selvice primitives. Presentation selvice primitives will cause or be the result of presentation-protocol-data-unit (PPDU) exchange between the peer PPM's.The PPDUs are exchanged using the Session selvice provide by the session layer. presentation primitives presentation primitives PSAP PSAP SSAP SSAP session primitives Figure 6.1 Model of the Presentation layer. 6.1 The Presentation Service primitives. Presentation selvices primitives are divided into two sets. The first set provides the representational functions, the second set ofselvices is concerned with providing a mechanism to allow the application processes to use the selvices of the session layer (figure 6.2). They are called mirroring selvices. PPDUs... ~ ss-provider Figure 6.2 The two types of presentation selvice. The presentation protocol machine. 31

38 All the Presentation Service Primitives are listed in table 6.1. No PPDUs are exchanged by the peer presentation protocol machines when the mirroring services are invoked by the application layer. They are marked with an asterix in table 6.1. Note: R means REQUEST I means INDICAnON S means RESPONSE C means CONFIRM M means Mirroring service Tabel 6.1 The OSI Presentation Service Primitives. OSI presentation primitive R S C M Meaning P-CONNECT X X X X Establish a presentation connection P-RELEASE X X X X Connection release P-U-ABORT X X User-initiated abort release P-P-ABORT X Provider-initiated abort release P-DATA X X Nonnal data transfer P-EXPEDITED-DATA X X Expedited data transfer P-TYPED-DATA X X Out-of-band data transfer P-CAPABILITY-DATA X X X X Control infonnation data transfer P-TOKEN-GIVE X X Give a token to the peer P-TOKEN-PLEASE X X Request a token from the peer P-CONTROL-GIVE X X Give all the tokens to the peer P-SYNC-MAJOR X X X X Insert a major sync point P-SYNC-MINOR X X X X Insert a minor sync point P-RESYNCHRONIZE X X X X Go back to a previous sync point P-ACTIVITY-START X X Start on activity P-ACTIVITY-END X X X X End of activity P-ACTIVITY-DISCARD X X X X Abandon an activity P-ACTIVITY-INTERRUPT X X X X Suspend an activity P-ACTIVITY-RESUME X X Restart a suspended activity P-U-EXCEPTION-REPORT X X Report of a user exception P-P-EXCEPTION-REPORT X Report of a provider exception P-ALTER-CONTEXT X X X X Context addition and deletion These presentation services are in fact offered by the session layer and are propagated through the presentation layer without change. With other words, these presentation services 'mirror' those offered by the session. When a mirroring service is used by the application layer, it causes a mapping of the parameters of the associated presentation service primitive to or from the equivalent session service primitives which carry the same name. The actual work: is done in the session layer, where also the exchanging of associated session protocol data units (SPDUs) takes place. 6.2 The session service primitives. The Presentation Layer communicates with the Session Layer by means of Session Service Data Units (SSDU). They are listed in table 6.2 Most session primitive carry the same name as the presentation 32 An architecture for an OSI-protocol (layer 6).

39 primitives. They are the "mirrored" services of the presentation layer. The mapping of those mirroring presentation services on the session service is given by table 6.3. Tabel 6.2 The OSI Session Service Primitives. OSI session primitive R S C meaning S-CONNECT X X X X Establish a connection S-RELEASE X X X X Connection release S-U-ABORT X X User-initiated release S-P-ABORT X Provider-initiated abort S-DATA X X Normal data transfer S-EXPEDITED-DATA X X Expedited data transfer S-TYPED-DATA X X Out-of-band data transfer S-CAPABILITY-DATA X X X X Control infonnation data transfer S-TOKEN-GIVE X X Give a token to the peer S-TOKEN-PLEASE X X Request a token from the peer S-CONTROL-GIVE X X Give all tokens to the peer S-SYNC-MAJOR X X X X Insert a major sync point S-SYNC-MINOR X X X X Insert a minor sync point S-RESYNCHRONIZE X X X X Go back to a previous sync point S-ACTIVITY-START X X Start an activity S-ACTIVITY-END X X X X End an activity S-ACTIVITY-DISCARD X X X X Abandon an activity S-ACTIVITY-INTERRUPT X X X X Suspend an activity S-ACTIVITY-RESUME X X Restart a suspended activity S-U-EXCEPTION-REPORT X X Report of a user exception S-P-EXCEPTION REPORT X Report of a provider exception Tabel 6.3 Mapping of PSDUs on SSDUs. PSDU SSDU P-RELEASE S-RELEASE P-TOKEN-GIVE S-TOKEN-GIVE P-TOKEN-PLEASE S-TOKEN-PLEASE P-CONTROL-GIVE S-CONTROL-GIVE P-SYNC-MINOR S-SYNC-MINOR P-SYNC-MAJOR S-SYNC-MAJOR P-P-EXCEPTION-REPORT S-P-EXCEPTION-REPORT P-U-EXCEPTION REPORT S-U-EXCEPTION-REPORT P-ACTIVITY-START S-ACTIVITY-START P-ACTIVITY-RESUME S-ACTIVITY-RESUME P-ACTIVITY-INTERRUPT S-ACTIVITY-INTERRUPT P-ACTIVITY-DISCARD S-ACTIVITY-DISCARD P-ACTIVITY-END S-ACTIVITY-END 6.3 The services of the presentation layer. The services of the presentation layer are divided into three phases: connection establishment and release. information transfer. context management. The presentation protocol machine. 33

40 The services in the first two phases fonn the kernel functional unit (FU) of the presentation layer, while the third fonns the optional context management FU Connection establishment and release. Connection establishment. Connection establishment is a confinned service provided by the P-CONNECf service primitive. It provides the means by which an application entity establishes a connection with its peer. When established, the connection will have an DCS which may, in its minimal fonn, be composed of only a default presentation context. The way a DCS is achieved is described in chapter 6. The associated parameters of the P-CONNECf primitive are: Calling-presentation-address Called-presentation-address Responding-present.-address Presentation context def. list Present. context def. result list Default context name Default context result Presentation requirements User data Result (PSAP address of the initiating application process, only in request and indication) (PSAP address of the intended responder application process, only in request and indication) (PSAP address of the responding application process, only in response and confinn) (List of entries to establish a DCS; each entry has two components: presentation context identifier abstract syntax name.) (list of entries, expanded with a field where the result of negotiation for each entry of the DCS is placed: acceptation or rejection) (abstract syntax name of the default context) (the result of the negotiation of the default context set: acceptation or rejection) (selects a functional unit (FU) of the presentation layer) (the application infonnation that must be transported to the peer application process and is subjected to the representational manipulation, accompanied by a presentation context identifier from the list provided in the PCDL parameter) (The result of the connection establishment, only in response and confinn) Other parameters are only used in the session layer. They are: Quality of service Initial synchronization point serial number Initial assignment of tokens Session connection identifier session requirements When a P-CONNECf request service primitive is received by a PPM (the initiator), all associated parameters are checked. The PPM chooses a list of transfer syntaxes for each entry in the presentation context definition list (PCDL) parameter, and expands the entry. The newly constructed PCDL, 34 An architecture for an OSI-protocol (layer 6).

41 together with other parameters necessary" for the peer presentation entityi are put in the connect presentation (CP) PPDU. TItis PPDU contains the presentation data values and proposed parameters necessary for the operation of the presentation connection. Subsequently the initiating presentation entity constructs from this CP PPDU a S-CONNECf-request SSDU, and sends it to the Session layer to initiate the establislunent ofa connection. On the otherside the responding presentation entity receives a S-CONNECf-indication and reconstruct from this SSDU the CP PPDU. The CP PPDU is examined by the peer PPM and chooses a single transfer syntax for each entry in the expanded PCDL. If a choice is impossible for any entry, then connection establislunent will fail at this point and a connect presentation reject (CPR) is sent to the initiating PPM. If the choice was successful, a P-CONNECf indication primitive is issued to the responding application process (identified by the called presentation address). The PCDL parameter contains a copy of the one provided with the P-CONNECf request. The application layer provides a P-CONNECf response which is received by the responding PPM. If the connection is acceptable (because the abstract syntaxes are known), the presentation context definition result list (PCDRL) containing the supported abstract syntaxes is expanded with the supported transfer syntaxes. SUbsequently the PCDRL is placed in the connect presentation accept (CPA) PPDU and is sent. If the connection is not acceptable, a CPR is issued. The initiating PPM receives the CPA or CPR PPDU and the appropriate response is issued to the initiating application entity. In case of receiving the CPA PPDU, the DCS is known by both entities. Disorderly release. An application start the disorderly release of a presentation connection by invoking the P-U-ABORT primitive. Any information may be lost as a result of use of this service. It can be used at any time by the initiator of the connection and by the responder, any time after issuing the P-CONNECf response. The P-U-abort is an unconfirmed service. When P-U-ABORT request is issued by the applicationlayer, the initiating PPMsends an abnormal release, userinitiated (ARU) PPDU to the peer PPM. The responding PPM in tum will give a P-U-Abort indication to the peer application entity. If an event happens in the underlying layers or in either of the peer presentation entities where the service is disrupted, then the peer presentation entities use a P-P-ABORT indication to both application processes. Any information in transit can be lost. When the lowerlayers initiates an abort, an abnormal release, provider initiated (ARP) PPDU is sent to both presentation entities. Both presentation protocol machines will then issue a P P-abort indication to their application entities. Orderly release. Orderly release of a presentation connection is achieved by using the P-RELEASE primitive. The presentation connection is released as a result of the release of the underlying session connection, It is transparent or mirroring confirmed service Context management We now considerthe service primitive that makes upthe optional context managementfu: P-ALTER CONTEXT. TItis primitive adds new presentation context(s) to, or removes existing presentation The presentation protocol machine. 35

42 contexts from, the DCS. It provides a confinned service, because negotiation is used, and has number of associated parameters. a presentation context addition list presentation context deletion list result list user data (list with new presentation contexts to be added to the DCS) (list with presentation contexts to be removed from the DCS) (list of context sets with a result field, where each entry is the result of negotiation of the newly added context sets) (data written according to an abstract syntax of the DCS) The procedure to alter the DCS is similar to connection establishment. When the initiating PPM receives the ALTER-CONTEXT request, it sends to the responding PPM the alter context (AC) PPDU. When the responding PPM has done all the appropriate actions, the alter context acknowledge (ACA) PPDU, containing all the necessary parameters, is sent back to the initiating PPM Data transfer. A transmitting application process initiates an infonnation unit exchange by use of P-DATA request The tag of the infonnation (the presentation context identifier) indicating the abstract syntax of that infonnation unit, is examined by the presentation entity. The infonnation is encoded according the correct transfer syntax and sent by the PPM in the transfer data (TO) PPDU. The responding PPM receives the TD PPDU and the responding presentation entity perfonns the appropriate transfonnation. Subsequently the infonnation unit is delivered by the intended application entity. Other types of data transfer are possible: The P-TVPED-DATA service offers the same service as P-DATA, but is only used by application processes to exchange infonnation against the current setting of data tokens. The PPDU used is the transfer typed data (TID) PPDU. P-EXPEDITED-DATA guarantees that a infonnation unit arrives by the peer entity, before the primitive that is sent after the P_EXPEDITED-DATA primitive. It is a confinned service and the PPM uses the transfer capability (TC) PPDU, and the transfer capability confinn (TCC) PPDU for the confinn back to the initiating PPM. The infonnation units to be transferred by the P-EXPEDITED DATA service must be according the default context set. p-capabnjty-data is only used when control data is transferred between the peer application entities. This service uses the transfer expedited data (TE) PPDU. 6.4 The Presentation Protocol Data Units. It is of course impossible to describe all the presentation service primitives and presentation protocol data units with their associated parameters in detail. A complete description of all presentation services together with the parameters can be found in the blue book X.216 recommendations of the CCITT. For a full description of the presentation data units, together with the associated parameters and procedures we refer to the blue book X.226 recommendations of the CCITT. There also the full specification of the PPM, existing of only 7 states, can be found. 36 An architecture for an as/-protocol (layer 6).

43 All possible PPDUs, exchanged by the peer PPM are listed in table 6.4. There are 14 PPDU's defined in the presentation layer which are arranged in 5 groups. The PPDUs are exchanged by the peer PPM using the session service. In table 6.5 the mapping of the PPDUs on the session service primitives is listed. Tabel 6.4The presentation-ppdu's with their primitives. PPDU name R I S C CP Connect Presentation X X CPA Connect Presentation Accept X X CPR Connect Presentation Reject X X ARU Abnonnal release, User initiated X X ARP Abnonnal release, Provider initiated X TD Transfer Data X X TE Transfer Expedited Data X X TID Transfer Typed Data X X TC Transfer Capability X X TCC Transfer Capability Confinn X X AC Alter Context X X ACA Alter Context Acknowledge X X RS Resynchronize X X RSA Resynchronize Acknowledge X X Tabel 6.5 Mapping of PPDUs on SSDUs. PPDU CP CPA CPR ARU ARP TD TE TID TC TCC AC ACA RS RSA SSDU S-CONNECT S-CONNECT S-CONNECT S-U-ABORT S-U-ABORT S-DATA S-EXPEDITED-DATA S-TYPED-DATA S-CAPABILITY-DATA S-CAPABILITY-DATA S-TYPED-DATA S-TYPED-DATA S-RESYNCHRONIZE S-RESYNCHRONIZE 6.5 Summary The task of the presentation protocol machine is to handle the different service request from the application layer, and to exchange the appropriate PPDU's with the peer PPM. To do this it has to perform a negotiating process with the peer presentation entity to come to the defined context set. Also the so called "mirroring" services of the presentation have been described, together with a list of its mapping. Finally the transport of the PPDUs, using the services of the session layer, is explained, together with a list of the mapping of the PPDUs on the session service data units. The presentation protocol machine. 37

44 7. Formal description method. Implementing the presentation layer is a complicated job. To make a proper design, it is important to describe the design in a standard and formal manner. They must be standard because, other people must be able to understand the design, and perhaps continue or change the work that has been done. On the other hand the design must be formal because it is the only way to cope with ambiguities. Nowadays a number of methods and tools have been created to aid in every phase of system development. The modelling we used to analyze, and later on design and implement the presentation layer is described by OJ. Hatley and LA. Pirbhai in the book "Strategies for Real-Time System Specification" [HATL,'87]. It is a variation on the method described by E. Yourdon. We also used a Computer-Aided Software Engineering (CASE) tool called PROMOD, which more or less supports the Hatley & Pirbhai-method. The Hatley & Pirbhai method consists of two parts, a requirements model and an architectural model. The requirements model describes what has to be designed (it contains demands and constraints), the architectural model describes how the requirements can be met. The design is made with many iterations vertically (within one model), and horizontally (between the two models). 7.1 The requirements model The requirements model is not a physical design. It represents what has to be designed, not how to design it. It must leave as much space as possible to the designers choice how to implement the system. The requirements model consists of the following components: Data Context Diagram (DCD) Data Flow Diagrams (DFDs) Process Specifications (PSPECs) Control Context Diagram (CCD) Control Flow Diagrams (CFDs) Control Specifications (CSPECs) Stores Requirements dictionary Timing specifications In figure 7.1 the relations of the components of the requirements model are shown. The requirements model is based on the use of flow diagrams (FDs). A flow diagram is a graphical model of signal flows (both data flows and control flows) and processes acting on those flows. FDs consists of data flow diagrams (DFD) and control flow diagrams (CFD). In a DFD, the processes together with the data flows (solid arrows) are shown, while in a CFD the processes with the control flows (dashed arrows) are depicted. The designer decomposes the system and its functions into a hierarchical structure of processes. In this manner the requirements of the system is described. Formal description method. 39

45 Data Context Diagram Data Flow Diagrams Control Context Diagram Timing i Specification i ~ ~ Control Flow ~ -. Diagrams!! Process Specifications Control Specifications I Requirements Dictionary Figure 7.1 Components of the requirements model. I On the top-level is placed the context diagram (CD), existing of only one process. This process represents the system that has to be designed. The CO describes the communication between the system to be designed and the outer world (shown as terminators) and contains the OCO as well as the CCO. The top level process is functionally decomposed into smaller (sub) processes. The decomposition of (sub) processes continues until, at the lowest level, a number ofprimitive processes exists. A primitive process is described by a process specification (PSPEC) in an unambiguous way. This can be done for example using structured English or a arithmetic formula. Each process that is not a primitive process is described by a FO. A CD consists of a OCO and a CCO, just like a FD consists of a OFD and a CFD. Figure 7.2 shows an example of a context diagram, figure 7.3 displays an possible example of a FD belonging to the CD of figure 7.2. ~----. ~ LJES~., ' \.~) cco Figure 7.2 An example of a context diagram. --8-,-' 40 An architecture for an OSI-protocol (layer 6).

46 Figure 7.3 An example of a flow diagram. In the flow diagrams, the processes are depicted as circles. They are part of the hierarchical structure described above. A process indicates the transfonning of ingoing flows into outgoing flows. Nonprimitive processes are described by a FD one level lower in the hierarchy; primitive processes are described by a PSPEC. A data flow, depicted as a directed solid arc, is a pipeline through which data of known composition flows. It may consist of a single element or a group of elements. For example a data flow may represent a single bit, a bit stream, but also the traffic-flow on a road). A control flow, depicted as a directed dashed arc, carry control infonnation. Just like the data flow, it can contain one or a group of elements. The difference between data and control flows are difficult to describe and depends on the interpretation of the designer. Both data and control flows are described in de requirements dictionary. Here the definitions and the functions of all the data and control flows are listed. A store is represented by two horizontal lines with the name of the store in between. There are two kind of stores, data and control stores. They can be used to save data and control flows that may be needed in a later time slot Control flows can flow between processes, and from or to a bar. This bar indicates the interface between the CFD and the control specification (CSPEC) that corresponds to this level. In a CFD, only one CSPEC may appear. All bars in a certain CFD refer to the same CSPEC. The CSPECs are optionally; they need not to be inserted when no process activators are required. A terminator, visible as a square, represents an entity outside the context of the system. It shows the communication of the system with the outer world. The last part of the requirements model is the time specification. Because time is needed in all levels of the design, these are globally available, otherwise there would be to many flows in the diagram, which would make them unreadable.the model itself includes the assumption that it is indefinitely fast with respect to the internal data and control flows. Time specifications are only needed for communication with the outer world. All DFDs and CFDs together constitutes a model of the requirements of a system, not a representation of the implementation of the system. The model is highly idealized; the processes are assumed to be data triggered and infinitely fast. Whenever enough data is available at the input of a process to perfonn its task, it will perfonn that particular task immediately. However, some processes are not triggered by data, but by control. This means that the activation of a process is described in a CSPEC or PSPEC. Formal description method. 41

47 7.2 The architecture model. The architectural model is created to model the system's design, to show the configuration ofphysical modules that perfonn all the required data and control processing. The requirements are mapped into an architecture model taking all the design constraints into account. The purpose of the architecture model are: show physical components that make up the system. define the infonnation flow between these physical components, and specify the channels on which this infonnation flows The architecture modules. The architecture model assigns the processes of the requirements model to physical modules that constitute the system, and establishes the relationships between them. The definition of the physical modules adds four more perspectives to the two addressed by the requirements model (process model and control model). These are input processing, output processing, user interface processing and maintenance or self-test processing, as shown in figure 7.4. User Interface Processing Input Processing I Process Model I Output Processing I Control model I requirements template Maintenance, Self-Test, and Redundancy Management Processing Figure 7.4 The template of an architecture module. The input and output processing blocks represent the additional processing needed for each architecture model to communicate with the other modules and to transfonn the infonnation to and from a usable internal fonnat. The user interface block is a special case of the input and output processing blocks. This block is separated because there are many special considerations, for example human factors, that affect the user interface. The maintenance and self-test block represents modules required to perfonn self-monitoring, redundancy management and data collection for maintenance purposes. 42 An architecture for an OS/-protocol (layer 6).

48 7.2.2 The components of the architectural model. The architectural model is a hierarchical layering ofmodules that are defined by successive application of the architecture template to each of the blocks in the model. The architectural components are: Architectural Context diagram (ACD) Architectural Flow Diagram (AFD) Architectural Module Specification (AMS) Architectural Interconnect Diagrams (AIDs) Architectural Interconnect Specifications (AISs) Architectural Dictionary The relations between these components are shown in figure 7.5. Jr Architecture Context Diagram i Jr Architecture Flow Diagrams Architecture interconn Diagrams 1 1 Architecture Module Architecture interconn. Specification Specification I... Architecture Dictionary Figure 7.S The architecture model components. I The architectural context diagram (ACD) establishes the information boundary between the system being implemented and the environment in which the system has to operate. It is the highest level diagram for any system. The architecture flow diagram (AFD) is a networlc representation of a system's physical configuration; it documents the information flow between all the architecture modules. The AFD also represents the allocation of processes and flows from the data and control flow into architectural modules. The architecture interconnection diagram (AID) is a representation of the communication channels that exists between the architecture modules. An AID always corresponds to an AFD. The AID shows the same architecture modules as its AFD, but it also shows redundant units if they exist. The components of an AID are architecture modules and communication channels, including possible redundancy. The architecture module specification (AMS) is written for every module in the architecture model to state the allocation of data flow, control flow, and processing performed by that module. Formal description method. 43

49 The architecture interconnection specification (AIS) establishes the characteristics of the communication channels on which infonnation travels between architecture modules. It describes the transfonnation medium as well as the infonnation fonnats. An AIS is written for every communication channel on an AID, but they may be simplified. The architecture dictionary consists of a listing of all the data and control elements that flow between the architecture modules and external entities. The architecture dictionary is an enhancement ofthe requirements dictionary. The additions are the names ofthe architecture modules between which the infonnation flows, and the names of these communication channels. 7.3 The CASE tool ProMod. ProMod is a CASE-tool which supports the Hatley & Pirbhai method for the most part. It enables the designer to generate a detailed specification for system development. Using Promod the designer fonns that specification in three logical steps (figure 7.6) Problem Statement User's Whishes Requirements Analysis & Detin~ion System Model System design Program Design I System Spec~ication Program S~ication Figure 7.6 The ProMod project model. 1. Using an elementary system of structured analysis, the designer creates a basic graphic model of the requirements system. 2. With ProMod, utilizing infonnation contained in the graphic model, the designer develops a system architecture made up of modules arranged hierarchically and with strictly defined interfaces. 3. Using a simple pseudo code, the designer refines algorithms and data as ProMod prepares cross references for data, functions, user-selected attributes, etcetera, and prepares logically structured documents. This results in a detailed system specification and a wide variety of valuable reports. At each step in the development process ProMod automatically analyzes the accumulated infonnation to ensure consistency and completeness. This feature prevents propagation of an error from step to step and ensure matching module interfaces. The three principal phases in the system development that are supported by ProMod are: Requirements analysis and definition. System design Program design The first phase, requirements analysis and definition, corresponds to developing a requirements model according to Hatley & Pirbhai and was used to analyze the presentation layer. The other two phases were not used. 44 An architecture for an OSI-protocol (layer 6).

50 The reason ProMod was used, is that ProMod in fact is a database which can be easily altered to the designers wishes. This is very useful because in the analyzing phase many changes had to be made. Also the creation of the different data- and control- flow diagrams is very easy; ProMod takes care of making similar diagrams. Promod checks the flows automatically (both data and control) and the process on consistency and completeness, which on paper of course is impossible. The report ProMod automatically produces, is complete and easy to understand. Finally, working with several people on the same project, ProMod is a good tool for adjusting the interfacing of the processes made by different designers. However, ProMod is not entirely compatible to the method of Hatley & Pirbhai. It demands a specification of all processes instead of only a specification for primitive processes. These process specifications are called mini specifications (MSPs). 7.4 Summary In this chapter a method is described to design the presentation layer with the help of a structured method. This method can be found in the book "strategies forreal-time System Specification" by D.J. Hatley and LA. Pirbhai. Also the CASE-tool ProMod is described which supports the Hatley & Pirbhai method. ProMod is a kind of database, in which a design can be described, analyzed and checked. ProMod is a useful help for describing the presentation layer. Formal description method. 45

51 8. Modelling the Presentation Layer This chapter discusses the design of the presentation layer. The basis of the design of this model are the carr Blue Book Recommendations ofthe presentation layer, especially recommendations X.216 and X.226 [VIII.5, '88]. We will first consider the context diagram of the presentation layer, together with the modelling of the primitives. Next the flow diagram of level 1 will be explained, including the PPM and the encoder/decoder. 8.1 The context diagram of the presentation layer. Modelling the presentation layer can be done in two different ways (figure 8.1 and 8.2). PSDU SSDU Figure 8.1 Context flow diagram variant 1. PSDU PSDU' Application Layer A -'--~!~:,,, -. PICI'..., PSDU' Figure 8.2 Context flow diagram variant 2. Modelling the Presentation Layer. 47

52 When one computer system is considered, the presentation layer has to communicate with the application layer and the session layer (figure 8.1). On the other hand, considering a connection, the presentation has only to act as an medium for the peer application entities. These two considerations result in two different kinds of context flow diagrams (figure 8.2). We have chosen for the first solution because this is the closest approximation ofthe reality. We want to design a single presentation layer for a computer system, which transmits and receives primitives to or from the application layer and session layer. The second solution supports the idea of a connection, and includes a transmitting and receiving presentation entity, which communicates with each other using PPDUs. However, the fact that, for a connection, the presentation layer has to use the seivices of the session layer can not be displayed explicitly in that model. In both diagrams, the communication ofthe presentation process with the terminators takes place with both interface control information (pici or SICI) and seivice data units (PSDU or SSDU). The ICI control flow indicates that a certain primitive is active. Meanwhile, the SDU data flow carries the different parameters that belong to the primitive. For example PICI can be a P-CONNECf primitive, while PSDU carries the parameters that belong to P-CONNECf. In tum, P-CONNECf can carry one of the four different kind of the primitives: request, indication, response or confirm. In the requirements dictionary this appears as: pici = p_connect= psdu = [ P30nneet I p_release I p_u_abort I P_alter30ntext I p_data I... etcetera ] ["request" I "indication" I "response" I "confirm" ] [ P30nneccpar I p_release_par I p_u_abort-par I p_aiteccontexc.par I p_data_par I... etcetera ] ( "caiiinures_adr" ) + ( "caiied_pres_adr" ) + ( pres_contexcdeclist ) +... etcetera The complete definition of the data- and control flows can be found in the requirements dictionary of the presentation layer model, placed in appendix A. In the same appendix also the context diagram of the presentation layer can be found. 48 An architecture for an OSI-protocol (layer 6).

53 8.2 The flow diagram of level 1. The flow diagram of level 1 is shown in figure 8.3. Because we want to buffer the PSDU, SSDU, PICI and SICI, the external data flows (communicating with the application and session layers) are called p_sdu3 and s_sdu3. The external control flows are called p_ici3 and s_ici3. Figure 8.3 The context diagram of level I. In figure 8.3 we can distinguish the presentation protocol machine (PPM), the encoder/decoder and a filter dcs. The presentation protocol machine (PPM) is the process carrying the set of functions which take care of the communicating aspects of the presentation protocol (input/output events, actions and predicates), using the services offered by the Session layer. The Protocol machines is by means of state/event tables described by the CCITT X.226 standard. Also predicates and actions are described, unfortunately in a rather vague way. This vague text implies a further effort to understand its meaning. The work. of analyzing the state tables of the PPM and to fit it in processes and control specifications is done by M.C.A. Hurk.mans and will be described in his thesis. The supported context set store (supp3s) contains a list ofcontext sets which can be handled by the encoder/decoder. This list is provided by the encoder/decoder and used by the PPM to negotiate the defined context set with the peer entity. The default context set (defaulccs) store contains the default context set. This store is filled by the PPM. Modelling the Presentation Layer. 49

54 The store manage_dcs is basically the memory to keep track of the DCS during the lifetime of a connection. The test_cs is a store, provided by the filter_dcs process and available to the encoder/decoder. The encoder/decoder has to test the p_user_data or ss_user_data to be sure it belongs to the tesccs. The filter_dcs process manages the various sets of contexts defined in a presentation connection and saves them in the store manage_dcs. The process also provides the test context set. The processes psdu_buffer and ssdu_buffer take care of splitting or merging the p_user_data and ss_usecdata, from or in the presentation- and session- service data units p_sdu3 and s_sdu3. The p_usecdata and ss_user data is intended for the encoder/decoder, or is coming from the encoder/decoder. The process also acts as a buffer for the external p_sdu3, s_sdu3, p_icce and s_ici3, so that they are always available to the PPM as p_sdu, s_sdu, p_ici and s_ici. Finally, the process ssdu_buffer recognizes the different Presentation Protocol Data Units (PPDU) from the session primitives. (PPDUs are always mapped on session primitives). In case a PPDU arrives, this is indicates to the PPM through the control flow s_ici. The encoder/decoder. It is the process which is capable of understanding in which context data are being referred to, and to code/encode data into/from a bitstream using the correet abstract and transfer syntaxes. The process is described in the next chapter, but can also be found in the appendix A. 8.3 Summary. In this chapter is described how the knowledge of the preceding chapters is combined in a model for the presentation layer. The presentation communicates with both the application- and session- layer. The presentation- and session primitives are modeled by the control flows p_ici3 and s_ici_e, while the associated parameters are carried by the data flows p_sdu3 and s_sdu3. The total model of the PPM can be found in the thesis of M.e.A. Hurkmans, whereas the encoder/decoder process can be found in the next chapter. Because of the method used to describe the presentation layer, the whole design in full detail can be found in the structured analysis report of ProMod in Appendix A. 50 An architecture for an OSI-protocol (layer 6).

55 9. Modelling the encoder/decoder. In chapter 8, figure 8.3, we have seen that, in order to build a presentation model, we have to use an encoder/decoder. The encoder/decoder is used to transform the user data ofthe Presentation Layer User to a bitstream according to a known transfer syntax, and vice versa. In figure 9.1 the inputs and outputs for the decoder/encoder are depicted. The picture is taken from [CANE, '88]. The actual data structure, together with the identification of the data structure is in fact the p_user_data from figure 8.3, the bitstream is the ss_usecdata, and the ASN.l definition of data structures is from the application layer. Actual Id. of ASN.1 data data definition of structure structure data structure Actual Id. of ASN.1 data data definition of structure structure data structure Encoder Decoder Bitstream Bitstream Figure 9.1 Inputs and outputs for the encoder/decoder. There are two main phases during the encoding (decoding) process [CANE,'88] (figure 9.2); one dealing with the syntactic analysis of the abstract syntax, and one dealing with concrete encoding (decoding). These two phases can be seen as the compilation and execution phases ofa programming language. The difference is that a piece of code written in ASN.l is only composed of the types declaration part. This means that the first phase will not give an object code, but an internal representation of objects, the rules of which are discussed later in this thesis. ASN.l definition ASN.l checker Dals 81ruc:lure Enooder Decoder Dals 81ruc:lure "'0 i g: Dals 81ruc:lure Id. I\) bilslream bilslream Figure 9.2 Two-phases encoder/decoder. The first phase is needed to ensure the correctness of the ASN.l data type definition that form an abstract syntax. This phase can be schematically represented by a box that takes as input an abstract syntax definition, and gives as outputaninternal representation ofthe abstract syntax, that will be used during the second phase. The first phase can be done off-line, and not during a connection. Modelling the encoder/decoder. 51

56 The second phase relates to the concrete encoding of data. This phase can be also represented by a box that takes as input the reference to an internal representation ofthe abstract syntax, the actual data structures associated with the abstract data types, and the identifier of the data structures to be encoded/decoded. Output of this phase is the bitstream that will be transferred through the network. As seen in section 5.1, using the basic encoding rules, the encoder has to produce three fields (identifier, length, contents) for each ASN.l data type, during the encoding phase. The identifier field is encoded using the ASN.l definition, while the length and contents fields are encoded by referring to the actual data structure. The problem is how and where the encoder can get the data values. The actual data structure is application dependent, and an application implementer, in theory, can choose whichever way to store data values. This problem can be solved in the model by placing the data structure in a value tree. Where this value tree actually is placed, can be chosen freely. For example in a associated memory within the hardware of the presentation layer, or perhaps in the memory of the computer system where the hardware of the application layer belongs to. (see figure 9.3) Computer system Layer 7 Layer 4 Layer 3 Layer 2 Layer 1 Figure 9.3 Memory allocation of the application data. In figure 9.3 the hardware of the presentation layer is placed outside the computer system, but the memory allocation of the application data is placed within the computer system. The hardware can be seen as a kind of chips which increases the performance of the communication system. It can, for example, handle the presentation protocol and do the necessary conversion. 9.1 The alternatives for an encoder/decoder. To build an encoder (decoder) according to the off-line 'compiler', three alternatives were developed. They will be explained in the next three sections Alternative 1. The first alternative consists of a creation of two data stores: a type tree and a value tree. The type tree and value tree include type and value definition in a form more suitable for processing. A type tree is essentially a parse tree for a type definition. The tree has a hierarchical structure conform its abstract syntax. The leafnodes ofthe tree correspond to primitive types; the interiornodes of the tree represent constructor types. A node is labelled with the kind of type it represents. Where 52 An architecture for an OSI-protocol (layer 6).

57 the definition ofone type incorporates a reference to another defined type, the corresponding tree node points to another type table. Figure 9.4 depicts type tables containing defmition of the PersonnelRecord, Childinfonnation, EmployeeNumber and Date types which are give below and are taken from Appendix I of the X.209 recommendations. PersonnelRecord ::= [APPLICATION 0] IMPLICIT SET { title number dateofhire nameofspouse children Childinfonnation ::= SET { Name, dateoffiirth [0] Date} Name, EmployeeNumber, [I] Date, [2] Name, [3] IMPLICIT SEQUENCE OF Childinfonnation DEFAULT {} } Name ::= [APPLICATION I] IMPLICIT SEQUENCE {givenname VisibleString, initial VisibleString, familyname VisibleString} EmployeeNumber ::= [APPLICATION 2] IMPLICIT INTEGER Date ::= [APPLICATION 3] IMPLICIT VisibleString Personell Record Application 0 (SET) null Name see subtree null null [1] date of hire null [3] children null visible string givenname null visible string null Name Application 1 (Sequence) null null visible string initial Figure 9.4 An example of a type tree. Date see subtree null employeenumber Application 2 (Integer) null Name see subtree null childinformation SET null Date Application 3 (visible string) null null Name visible string see subtree familyname null childinformation see subtree (sequence of) (default: () ) null null [0] date of birth Date see subtree null Modelling the encoder/decoder. 53

58 A value tree is similarly a parse tree, but for a value definition. Leaf nodes represent primitive types and contain actual integers, boolean, bit or octet string values; interior nodes represent constructor types; each node is labelled with the kind of type it represents. Figure 9.5 depicts a value tree for the value of John Smith's personnel record, which is formally described below using ASN.l. { title number dateothire nameofspouce children {givenname "John", initial "P", familyname "Smith"}, "Director", 51, " " {givenname "Mary", initial "T", familyname "Smith"}, {{ {givenname "Ralph", initial "T", familyname "Smith"}, dataofbirth " "}, {{givenname "Suzan", initial "B", familyname "Jones"}, dateofbirth " "} }} title "Director" given name "John" initial "PO family name "Smith" given name "Mary" Initial "p" given Initial family given initia family name"'" name name "6" name "Ralph "Smith" "Suzan" "Jones" Figure 9"5 Value table for John Smith's personnel record. To convert abstract syntaxes into type trees, a compiler is needed, which, as seen before, can be placed outside the presentation layer. The compilerchecks the type definition for consistency and outputs type trees which are placed in a data store inside the encoder/decoder. A parser process within the application layer is needed to convert the data, provided by the application layer, into a value tree. Also a deparser process is necessary to construct the data, consumable for the application layer, from the value tree. 54 An architecture for an as/-protocol (layer 6).

59 An encode process is needed, which converts a value table into a bitstream, for example according the basic encoding rules. This process is guided by the type tables describing the type of the value to be encoded. Finally a decode process is needed, which converts a bitstream, encoded for example according the basic encoding rules, into a value table. This processes is also guided by the type tables describing the type of the value to be decoded. Now the parse process, followed by the encode process perfonn a translation from application data to a bitstream. The decode process followed by the deparse process realizes the inverse. The processes, together with the data flows, are depicted in figure 9.6. Application data Figure 9.6 Encoding with a type tree. A similar construction of an encoder/decoder with an type tree and a value tree in software and hardware can be found in [POPE,'84], [CLEG,'87], [CLEG,'89] and [GAUD,'89]. New abstract syntaxes using the same encoding rules can be defmed by the external compiler which loads the new type tree in the data store. However, when we want to use another transfer syntax, a new encoder and decoder process must be defined in the model. Another disadvantage is that the translation of the application data into a data tree is time and memory consuming Alternative 2. The second alternative consists ofa value tree, together with the necessary parse and deparse processes and a microprocessor which, together with a microprogram, acts like an encoder/decoder. Actually the encoder, and decoder process together with the type tree are combined in one microprocessor and a microprogram. The program includes the encoding and decoding routines to translate application data into a bitstream and vice-versa and can be made by an external compiler. New transfer syntaxes and new abstract syntaxes are easily implemented by changing the program. This is similar to the changing of the program of a digital signal processor, when a different fjiter is realized. A disadvantage is that, as in alternative I, the translation of the application data into a data tree uses considerable time and memory. Modelling the encoder/decoder. 55

60 9.1.3 Alternative 3. The reason that in alternative 1 and 2 a value tree was used, is that for the basic encoding rules the length field is transmitted before the contents field. So the whole record has to exist in a memory, before it can be transmitted. This causes much processing power and memory in the parse or deparse process, especially when the record uses many constructed types and carries many field. Fortunately, when using the basic encoding rules, it is possible to use the construction of end of data field (see section 5.1.2). Using this construction it is possible to encode and decode "on the fly" without using a data tree. Only a micro processor with "on the fly" programming is needed. This alternative uses minimal memory space, and has a good perfonnance. It is, however, not universally applicable Choosing an alternative. An ideal encoder/decoder must be universally applicable, must use very little memory space and must be indefinite fast. This can be approximated by combining alternative 2 and 3. In that case (using alternative 2) we are able to encode/decode universally, and (using alternative 3) encode/decode fast with almost no memory. In fact, alternative 3 is a special case of alternative 2. A data tree, consisting of only the primitive type "ANY", together with the right micro program can act as alternative 3. So alternative 2 is chosen, which also includes alternative The model of the encoder/decoder. In this section the processes of the encoder/decoder are further explained. The data flow diagram of the encoder/decoder is depicted in figure 9.7. Figure 9.7 The data flow diagram of the encoder/decoder. 56 An architecture for an OSI-protocol (layer 6).

61 The control flow diagram and the sub-processes are not depicted. This section will only give a brief description of the encoder/decoder model. The complete model of the encoder/decoder can be found in the structured analysis report, produced by ProMod (appendix A) The value tree and parser/deparser. To create a value tree, a parser process is provided. This process scans the data available from the application layer and puts it in the data store "value tree", which in fact is a tree structure. We will explain this process with the help of an example: the John Smith's personnel record of section In figure 9.8 the same data tree is depicted, where each node and leave has a number, and where each node contains accolades and commas. 6 given name "Mary" 10 initial "p" 11 given initial family given initia family name -r name name "8" name "Ralph 17 "Smith" "Suzan" "Jones" Figure 9.8 The value tree witch additional information. The numbers denote the order in which the nodes were defined. The accolades and commas denote the symbols of the ASN.l value notations, used to construct the tree by scanning on these symbols. With each node of the tree are two labels associated. It contains the name of a data value and the value of the data field. To create the tree from application data (the parsing process), we use the store last_address, indicating the last node used, and the following processes: Initial: When a new record has to be parsed, the initial process is started. It creates the root of the value tree. This process makes a new node, and attaches it to the node which is identified in the store last_address. It is used when a opening accolade is scanned. Modelling the encoder/decoder. 57

62 create_righcsibling: goto_parent: This process makes a new node, and attaches it to the parent node which is identified in the store last address. It is used when a comma is scanned. This process sets last_address to the parent node of the node which is identified by last_address. It is used when a closing accolade is scanned. The actual memory representation is given in figure T, treelist available nul null null null 3 1 null null 6 null 2 Illivenname John 4 null 2 inniaj P 5 null 2 amitynarne Smith null null 1 title Director 7 null 1 number 51 8 null 1 ~teof hire II 10 1 nul nul 13 null II ~ivenname Mary 11 null II inniaj P 12 null II amilynarne Smith null 14 1 nul nul null nul nul nul nul III null 15 ~ivenname RalPh 17 null 15 inniaj T 18 Figure 9.9 The actual structure of the value tree. n address paren type V8Jue r.l~l dllid To create a data field, consumable for the application, from the value tree (the deparsing process), we use the following processes: initial: This process is used at the beginning a deparsing process. It returns the data values of the root. This process is described above. This process returns the value of the left child of the node identified by last address. This process returns the value of the right sibling of the node identified by last address. The deparsing process is achieved by using these processes, starting from the root, left downward, touching every leaf. It can be compared with the process of drawing the contour of your hand from left to right The encoder/decoder micro processor. A complex encoding like the basic encoding rules can be implemented either "manually" or by using some automated "interface generator". Manual programming may in some cases result in better perfonnances, but it is time consuming and errors can be made easily: any misreading of the ASN.I language result in coding errors, which are often difficult to detect. It is also difficult to make modifications. For these reasons, most developers use "interface generators" [HUlT,'89] (figure 9.10), 58 An architecture for an OSI-protocol (layer 6).

63 Interface compiler IASN.l SER II AAematwe e~~ng I ASN.l decriplion of data i.i structures transfer switch - ~ (abstract synl8x8s) Application layer daia value Presentation Layer " AAemalwe coding routinee I ASN.l SER ~ codino routines 1 S~st,.am Figure 9.10 The compiling process of transfer routines. which will automatically "compile" an ASN.l specification, producing the coding and decoding routines. The interface generator or compiler is put outside the presentation layer. With this environment, introducing a new transfer syntax is equivalent to changing the code generation part of the interface compiler, in order to generate not only the ASN.l BER encoding and decoding routines, but also possible alternative transfer syntaxes based upon the new syntax. The choice ofusing either set of routines will be perfonned by the presentation layer. This will differ from connection to connection, depending on the result of the presentation negotiation. The encoder/decoder microprocessor runs the encoder/decoder routines, made by the interface compiler and available at the encoder_decoder_microprogram store. The Microprocessor is able to convert the value tree to a bitstream, used in the session layer as ss_user_data, and to decode the bitstream into a value tree. The encoder_decoder_microprogram can also contain a "on the fly" encoder/decoder routine, using the indefinite length fonn in the coding scheme of TLV of the B.E.R. In that case the value tree exists of only the ANY type. The process change_encoder_decoder contains a store with all the encoding and decoding routines to handle the context sets which are supported by the presentation layer. The list of supported context sets are made available to the PPM by the store suppys as seen before. When the encoder/decoder must be updated, because new abstract syntaxes and transfer syntaxes and thus new context sets are defined, the whole set of encoding/decoding routines can be overwritten by a new set of encoding/decoding routines. The routines are updated by the data flow update_microyrograms. The change3ncoder_decoder process will then load the new set of supported context sets in the store SUPP3S. The process change_encoder_decoder provides also the encoder_decoder_microprogram store with the correct encoding/decoding routines. Which routine is loaded, depends to which context set the p_usecdata or ss_usecdata belongs. The checking to which context set the data belongs is done by the processes check_extracty _user_data and check_extract_ss_user_data. These processes will be explained in the next section. Only one combined encoder/decoder microprocessor is available because the presentation layer can either transmit or receive, and is not able to do both tasks. Modelling the encoder/decoder. 59

64 9.2.3 The testing for the context set. The checking of the p_user_data, to detect if the data belongs to the test3s or defaulccs, is done by the process check_extract.j>_user_data. If the check was negative, the PPM will be warned that the data is not according the supported context sets. If the check was positive, the change3ncoder_decoder process will be told which routine has to be loaded in the store encoder_decoder_microprogram. When this is done, the process will remove the headers from the p_user_data, indicating to which context set the p_data_belongs, and send the remaining lex_data to the parser. The checking of the ss_usecdata and the extracting, with as result a bitstream, is done by the process check_extract_ss_user_data and is similar to the check_extract-p_usecdata, except that the process will remove the headers from the ss_user_data, and send the bitstream to the encoder_decoder_micro-processor. 9.3 Summary. In this chapter is described how we can model the encoder/decoder. Three possible alternatives were given, and we have tried to combine two of them in the fmal model. This model of the encoder/decoder process and his subprocess, such as the parser and the data3heckers, were explained. However, because of the formal method, used to describe the presentation layer, the whole design in full detail can be found in the structured analysis report of ProMod in Appendix A. 60 An architecture for an OSI-protocol (layer 6).

65 10. Conclusions and recommendations Conclusions The presentation layer protocol and its services are described in the Blue Book recommendations of the CCITf X.216 [VIII.4:SS] and X.226 [VIII.4:S9]. The recommendations are written in a very formal way which is difficult to understand for unexperienced readers. The recommendation do not refer to a possible implementation of the presentation layer. The Presentation layer is used to preserve the representation of the data values, exchanged by peer application entities. This is done by converting the data values to a commonly known data format. To support this method the CCITf has developed ASN.I and B.E.R.. ASN.I is used to describe the data types which application entities want to exchange. ASN.l is described in the X.20S recommendations. The B.E.R. are used to transform the data values, described in ASN.I, into a bitstream. The B.E.R. are described in the X.209 recommendations which also do not refer to a possible implementation of the presentation layer. The presentation layer is able to use different abstract syntaxes (described in ASN.l) and transfer syntaxes (for example the B.E.R.). It is possible to define other (faster) transfer syntaxes than the B.E.R., which may support compression or encryption. The couple of an abstract syntax and transfer syntax is called presentation context. The set of presentation contexts, supported during a connection, is negotiated by the peer presentation entities. This negotiating process is described in the presentation protocol. Using the CCITf blue book recommendations [VIII.4:SS] [VIII.S,'SS], we have managed to model the Presentation Layer and the many Presentation Service Data Units (PSDUs) and Session Service Data Units (SSDU's). The modelling of the presentation layer is done corresponding the formal method of Hatley and Pirbhai [HATL, 'S7]. To record the model, we have used the CASE-tool ProMod, which is a very helpful instrument in the development of the requirements model of the presentation layer. After determining the different components of the presentation layer, M.C.A. Hurkmans and I agreed that Mr. Hurkmans models the Presentation Protocol Machine, and I design the encoder/decoder. The criteria of the encoder/decoder were that they were universally applicable and fast. Therefore, in the design, a type tree and a microprocessor is placed which must run a microprogram. The value tree is a tree structure of the application data and is accomplished by parsing the application data. The microprogram must contain encoder/decoder routines to transform the value tree, into a bitstream, and vice versa. The routines of the microprocessor can be made by a compiler, placed outside the presentation model. Utilising a microprocessor with a microprogram, the encoder decoder is not a pure hardware process. The model of the encoder/decoder is able to handle multiple context sets, which can always be updated. Conclusions and recommendations. 61