2. USAGE CONSIDERATIONS › 2.2 General Analysis Considerations › 2.2.2 SNA Overview › 2.2.2.3 SNA Session Activation and Termination

2.2.2.3 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.


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:

o  Verifies that a path is available between the two LUs.

o  Verifies that the LUs are authorized to communicate
   with each other.

o  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.