The object oriented approach to system design is applicable to most large computer systems. One of its strengths is that the implement of an object has complete freedom to choose appropriate algorithms to achieve her purpose so long as the end result is an object which conforms to specification. For communication services the situation is a little different since the objects themselves are distributed; A service A is implemented by enhancing service B. This enhancement is performed by a pair of processes X and Y, one in each of the communicating systems. It is quite likely that X and Y will have been implemented by different people. If this is to work, then the distributed algorithm which defines the interactions between X and Y must itself be standardized. These distributed algorithms are called 'protocols, and the processes which implement them at each end of a communications service are called 'protocol entities, or 'entities' for short.

Figure: Communicating Processes

Communications protocols may be extremely complex specifying complicated message sequences to recover from loss or mis-sequencing of messages. Alternatively, they may be very simple, specifying little more than the format of the messages which will be exchanged. Naturally, the degree of complexity depends mainly on the amount by which the underlying service needs to be enhanced. Drawing nested boxes to any depth strains both typography and the reader's eyesight. Instead, it is conventional to represent the boxes as in figure #fn63#1401> and to stack these vertically to illustrate the complete architectural model (#fn64#1402>). Figure i#fn65#1403> shows a pair of similar protocol entities (peer entities) exchanging messages with each other in order to implement the distributed algorithm. The net effect of all this is to provide the service represented by the broken box. The messages exchanged between the service users and provider are shown by the vertical arrows. The messages exchanged by the peer entities are, of course, transported through the use of some subordinate service, thus each service provider is also a user of the service below (except for the bottom one of course!).

Figure: Layering as Model of Nesting

Figure: ISO OSI 7 Layer Model

It is worth introducing some OSI jargon here. The vertical arrows in Figure 6.5 represent 'service primitives' - the requests and indications that the service reports. In most cases there will be some data associated with these primitives which is being passed across the service interface. An individual lump of this data is called a 'Service Data Unit' (SDU). The horizontal arrows in Figure 6.5 represent the protocol messages that are formed by the protocol entities and exchanged with each other. These messages consist of two types of information; 'Protocol Control Information' (PCI) - which consists of the sequence numbers, checksums etc. required by the operation of the protocol; and 'User Data' - the data (submitted in SDUs) which the service is supposed to be transporting. Together, the PCI and the User Data constitute a 'Protocol Data Unit' (PDU). There is obviously a relationship between SDUs and PDUs. This is not necessarily simple as there may be good reasons to split one SDU into several PDUs or to lump several PDUs into one SDU when requesting the service below.