SNA Session Activation and Termination
Data can only flow in an SNA network when a logical relationship, called a session, has been established. This section discusses the basic requirements for activating and terminating sessions. Logical data management facilities of SNA such as routing and pacing are also outlined.
micsrm140
Data can only flow in an SNA network when a logical relationship, called a session, has been established. This section discusses the basic requirements for activating and terminating sessions. Logical data management facilities of SNA such as routing and pacing are also outlined.
Activating Network Resources
One of the major functions of system services control points (SSCPs) is to activate network resources. An SSCP activates SSCP-PU and SSCP-LU sessions with the physical (PU) and logical (LU) units which were defined to it at system generation. These sessions remain active until network deactivation. The SSCP uses the SSCP-PU session to monitor and control the resources in that node. A logical unit requests LU-LU session initiation from the SSCP via the SSCP-LU session.
During network start-up, an SSCP must activate the link to an adjacent node before it can activate SSCP-PU and SSCP-LU sessions with that node. The SSCP sends commands, over the existing SSCP-PU session with the PU at one end of the link, to issue link-level commands to the adjacent link stations which complete the link activation procedure. Because a link must be activated from both ends, the control point in the node at the other end of the link must also request link activation.
Initiating LU-LU Sessions
The purpose of an SNA network is to allow communications between end users, either individuals or application programs. End users communicate via an LU-LU session. An LU-LU session is initiated when an LU sends a session-initiation request to its SSCP via the SSCP-LU session. The SSCP performs three functions upon receipt of the request:
- Verifies that a path is available between the two LUs.
- Verifies that the LUs are authorized to communicate with each other.
- Verifies that the LUs can agree on a set of session protocols.
Activating LU-LU Sessions
When the verifications are completed, the SSCP returns a control initiate (CINIT) request to the LU that will activate the session; this LU is designated the primary LU (PLU). This request contains a set of parameters (called the BIND image) that the requesting LU can support.
The PLU uses the BIND image to format a BIND session request which is sent to the secondary logical unit (SLU), its intended session partner. The BIND specifies the protocols that the LU will use when communicating. There are two types of BIND requests: negotiable and non-negotiable.
The SLU can either accept or reject a non-negotiable BIND. If it accepts the parameters, it returns a positive response to the PLU and the session becomes active. In this case the PLU returns a session started request to the SSCP. If the parameters are unacceptable, the SLU returns a negative response thus rejecting the BIND. In this case, the PLU sends a BIND session failure request to the SSCP.
When an SLU receives a negotiable BIND request, it can return an alternate set of parameters to the PLU if the original set is unacceptable. If the alternate parameters are acceptable to the PLU, the session becomes active. In either case, the SSCP is notified of the resolution of the BIND request in the same manner as for non-negotiable BINDs.
Terminating LU-LU Sessions
An LU-LU session remains active until one of the session partners sends a session-termination request to its SSCP. Only the primary logical unit can actually deactivate a session (except in the case of session between type 6.2 LUs where either the PLU or SLU can terminate the session), but either LU can request session termination.
Usually, the SLU requests session termination by sending a terminate-self (TERM-SELF) request to its SSCP. The SSCP sends a control terminate (CTERM) request to the PLU to notify it that the SLU has requested termination. If the PLU has finished communicating with the SLU, it sends an UNBIND request to the SLU to terminate the session. If the PLU has not finished communicating with the SLU, it ignores the CTERM until it is finished.
When the PLU initiates session termination, it sends a shutdown (SHUTD) request to the SLU. When all outstanding communication has been completed, the SLU returns a shutdown complete (SHUTC) to the PLU. Upon receipt of the SHUTC, the PLU sends an UNBIND request to terminate the session.
Type 6.2 LUs do not use shutdown requests for session termination. Instead, the PLU sends a bracket initiation stopped (BIS) request to the SLU, which returns a BIS reply when all outstanding work is complete. The PLU then sends an UNBIND request to terminate the session.