request indicate (reason, user data)
Used for exception reporting by a service user.
S-P-EXCEPTION- REPORT
indicate (indication) Used for exception reporting by a service provider.
S-DATA request
indicate
(user data) Used for normal data transfer. S-EXPEDITED-DATA request
indicate
(user data) Used for high priority data transfer. S-TYPED-DATA request
indicate
(user data) Used for typed data transfer. S-CAPABILITY-DATA request
indicate
(user data) Used for data exchange when no activity is in progress.
S-ACTIVITY-START request indicate
(activity ID, user data)
Used for starting an activity. S-ACTIVITY- INTERRUPT request indicate response confirm
(reason) Used for temporarily interrupting an activity.
S-ACTIVITY-RESUME request indicate
(new ID, old ID, serial no., user data)
Used for resuming an interrupted activity.
S-ACTIVITY-DISCARD request indicate response confirm
(reason) Used for discarding an activity.
S-ACTIVITY-END request indicate response confirm (serial no., user data)
Used for ending an activity.
S-TOKEN-PLEASE request indicate
(tokens, user data)
Used by a service user for requesting a token.
S-TOKEN-GIVE request indicate
(tokens) Used by a service user for forwarding a token to the other user.
S-CONTROL-GIVE request indicate
() Used by a service user for forwarding all tokens to the other user.
S-SYNC-MINOR request indicate response confirm
(type, serial no., user data)
Used for setting a minor synchronization point. S-SYNC-MAJOR request indicate response confirm (serial no., user data)
Used for setting a major synchronization point.
S-RESYNCHRONIZE request indicate response confirm
(type, serial no., tokens,
user data)
Used for resynchronization.
Addresses refer to Session Service Access Points (SSAP); these typically are the same as their corresponding transport addresses. Quality Of Service (QOS) denotes a set of parameters which collectively describe the quality of the session service requested by the user. These are essentially the same as those used for the
transport layer, with the addition of a few new ones (e.g., concatenation of service requests). Result denotes the acceptance or rejection of the connection.
Requirements is used for the negotiation and selection of functional units (described below) that are to be effective for the duration of the session. Serial number denotes the initial serial number used for synchronization purposes. Token refers to the side to which the tokens are initially assigned. User data denotes actual user data provided by the service user for transfer by the service provider.
Figure 6.36 illustrates the use of the session services in a sample scenario. Session service user A first requests a (half-duplex) connection, which is indicated to session service user B by the service provider. B responds to the request and the service provider confirms with A. Two normal data transfers from A to B follow, with a minor synchronization cycle in between. B then asks A for the data token, which A hands over to B. B sends some data to A, and then asks for the session to be aborted.
Figure 6.64 Sample scenario of session services.
service user (A) Session
S-CONNECT request
S-CONNECT indication S-CONNECT confirm S-CONNECT response
S-DATA request S-DATA indication S-DATA request S-DATA indication service provider Session service user (B) Session S-DATA request S-DATA indication S-TOKEN-PLEASE request S-TOKEN-PLEASE indication S-TOKEN-GIVE request S-TOKEN-GIVE indication S-SYNC-MINOR request S-SYNC-MINOR indication S-SYNC-MINOR confirm S-SYNC-MINOR response S-ACTIVITY-START request S-ACTIVITY-START indication
S-ACTIVITY-END request S-ACTIVITY-END indication
S-ACTIVITY-END confirm S-ACTIVITY-END response S-U-ABORT request S-U-ABORT indication
6.1.1. Session Layer Role
The exact role of the session layer in relation to other layers is worth some consideration. Although the session layer is positioned below and receives its requests from the presentation layer, its primary role is to serve the application layer by allowing applications to converse in a structured manner. The presentation layer is completely transparent to this process.
The interface between the session layer and the transport layer is very simple. It provides for basic opening and closing of transport connections (a session connection directly maps to a transport connection) and reliable transfer of data over the connections. This simple interface is enriched by the session layer into a diverse set of services for the ultimate use by the application layer. Figure 6.65 illustrates these points.
Figure 6.65 Role of the session layer.
Application Layer
Presentation Layer
Session Layer
Transport Layer
6.1.2. Functional Units
It is generally rare for an application to require the use of all session services. Often a relatively small subset will suffice. To facilitate this, the session layer services are divided into 13 functional units (see Figure 6.66). Each functional unit is a logical grouping of related session services. Functional units are negotiated and selected during connection establishment using the requirements parameter in the connection request. The functional units selected determine what services will be available for the duration of the session.
Kernel represents the most basic set of services that applications could live with. All session layer implementations must provide this minimal subset.
Figure 6.66 Session service functional units.
Functional Unit Service Primitives Purpose
Kernel S-CONNECT
S-DATA