2.2 Vertical communication
Figure 6 shows the OSI view of adjacent layers. The interface between two layers in the same system is called a service access point (SAP). One of the features of a service access point is that it has an identifier, or an address, which allows each communication between adjacent layers to be uniquely identified. The processes that communicate across the interface are called entities. These are typically software routines, but may also be hardware components. The notation in Figure 6 may appear odd, but it is designed to apply to any pair of layers in the reference model. The upper layer is called (N + 1) and the lower layer (N). Layer (N) is the service provider and layer (N + 1) the service user.
The interaction between adjacent layers is expressed in terms of issuing and receiving primitives. The form taken by primitives depends on the implementation of the system but typically they are software procedure calls. In two systems involved in any communication there is a range of primitives depending on the service required. For each primitive up to four basic types are available:
request – an entity invokes a service
indication – an entity is informed of an event
response – an entity reacts to an event
confirm – an entity is informed of the result of an earlier request.
Figure 7 illustrates an exchange of all four types of primitive, and some concrete examples are given below. Because primitives are issued and received across the boundaries between adjacent layers in the OSI reference model, their interaction is sometimes referred to as vertical communication.
Most primitives carry parameters, which provide the information necessary to fulfil the service. For instance, the service of setting up a connection between two OSI transport entities requires a connection primitive, and the request type of this primitive has the following parameters:
receipt confirmation selection;
expedited data selection;
quality-of-service parameter set;
A procedure call implementation of a connection request may take the form of:
Call CONNECT-request (called address, calling address, receipt confirmation selection, expedited data selection, quality-of-service parameter set, user data)
The indication, response and confirm types of this connection primitive have similar sets of parameters. Once a connection has been established data is transferred by invoking a service with a data transfer primitive. This primitive has only two forms, request and indication, which have the parameters:
The called and calling addresses were supplied when the connection was established and it is assumed that the entities still know this information.
The equivalent data transfer primitive associated for a connectionless service needs to include parameters for the called and calling addresses. Why?
In a connectionless service, the flow of data is not associated with a connection, so no connection primitive is issued. Each block of user data must therefore be accompanied by the information necessary for its delivery.
At this stage it is not necessary to understand what information each of these parameters represents, merely to appreciate that primitives do carry additional information necessary for a layer to provide services.