Further Reading The Transport Layer

74 Communication Networks Copyright © 2005 PragSoft

6. The Session Layer

This chapter describes the session layer of the OSI model. The session layer provides a structured means for data exchange between user processes or applications on communicating hosts. This layer uses the term session instead of connection to signify the point that communication is studied from an application rather than a host point of view. More specifically, a session imposes a set of rules on the way applications should communicate. Also of interest are: how a session is negotiated between two applications, the synchronization and control of message exchanges between applications e.g., how they should take turns, the context of messages e.g., whether they relate to records from a database or keystrokes on a terminal, dealing with transport failures, and the bracketing of messages as required by some applications. We will first look at the session service primitives and their use by higher layers. Then we will describe the session protocol and related issues, such as the use of tokens in activities and dialog units, synchronization, error handling, and the structure of session messages. Finally, we will list a number of session layer standards.

6.1. Session Services

As with earlier layers, the session services are defined in terms of session primitives, of which there are many. Figure 6.63 summarizes the primitives together with their possible types and parameters. Figure 6.63 Session service primitives. Primitive Types Parameters Purpose S-CONNECT request indicate response confirm addresses, QOS, result, requirements, serial no., token, user data Used for initiating a session connection connections are always initiated by service users. S-RELEASE request indicate response confirm result, user data Used for orderly release of a connection. S-U-ABORT request indicate user data Used for service user-initiated abort. S-P-ABORT indicate reason Used for service provider-initiated abort. www.pragsoft.com Chapter 6: The Session Layer 75 S-U-EXCEPTION- REPORT 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 76 Communication Networks Copyright © 2005 PragSoft 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