Initially, Advanced Peer-to-Peer Networking (APPN) supported only peer-to-peer connections???sessions using Logical Unit (LU) 6.2 connections. However, APPN is also viable if the network can support legacy Systems Network Architecture (SNA) traffic (such as LUs 0, 1, 2).
In APPN, there is no longer the concept of primary and secondary end of a session. Whichever endpoint chooses to initiate the session becomes the primary and sends the BIND. With legacy SNA traffic, however, the secondary end asks virtual telecommunications access method (VTAM) to initiate the session. There is no concept of a node that cannot send the BIND in APPN. For this reason, special support is required for legacy secondary LUs that cannot issue BIND.
Dependent LU Requester/Server (DLUR/DLUS) solves the problem for the dependent LUs in APPN networks, where the Server is implemented in VTAM 4.2 and Requester can be in a network node (NN) or end node (EN) in the network.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
A pair of LU 6.2 sessions are established between the DLUR and DLUS Control Flows (such as Activate LU, Deactivate LU, Activate physical unit (PU), Deactivate PU, LOGON, INITIATE) flow over these sessions between DLUS and DLUR. The DLUR passes the messages on to the appropriate resources.
Secondary Dependent LUs (DLUs) can initiate sessions by sending an initiate request to the DLUR, which then puts that on one of the LU 6.2 pipes.
Once the session request flows, the DLUS and DLUR communications are complete.
Once VTAM/DLUS receives the session request, the VTAM determines where the application is located and sends a CDINIT-LOCATE request to the application host, requesting that a BIND be sent to the secondary.
This support in APPN VTAM is known as Session Services Extensions, implying that legacy SNA Session Services was posted to APPN.
Session Service Extensions also support third-party session initiations and queuing until a session partner becomes available, in addition to a secondary initiated session.
Once the application is notified that it should send the BIND to a legacy LU, the BIND is sent across the APPN network. It is not encapsulated. Legacy SNA traffic and APPN traffic use the same SNA header and can coexist on the APPN network.
Although VTAM is aware of the session initiation, session traffic does not need to flow through VTAM or its attached Channel Interface Processor (CIP) router. Using APPN algorithms, the NN providing network server functionality to the application host selects the best path through the network, which provides the appropriate Class of Service (CoS).
When an exchange identification (XID) is received, DLUR signals the system services control points (SSCP) that its services are required by sending a request to activate a physical unit (REQACTPU) to the DLUS. Subsequently, DLUS issues the ACTPU request.
Figure 6
In this flow, Branch Network Node/DLUR (BrNN/DLUR) has received an XID from the downstream PU, which signals DLUR to request SSCP services from DLUS. In all XID02 or XID32 has ACTPU request bit set then REQACTPU sent. If no "pipe" is active, first 'locate' and following a BIND request is sent to start the pipe.
DLUS then returns the positive response +RSP REQACTPU followed by the ACTPU request.
DLUR provides Auto Network Shutdown (ANS) support similar to ANS support provided by Network Control Program (NCP). If a PU has been activated with ANS = CONT specified, any existing LU-LU sessions is preserved when the pipe terminates.
DLUR rejects any SSCP-PU/LU traffic from the dependent device.
Depending on the subsequent activation of the dependent device, DLUR may terminate the LU-LU session.
In Figure 7, all the sessions (SSCP-PU, SSCP-LU and LU-LU) have been established and data is flowing over the LU-LU session.
In Figure 8, a network outage has occurred that breaks the DLUs-DLUR pipes and, consequently, the SSCP-PU and SSCP-LU session.
The LU-LU session continues, since it does not pass through the affected Cisco CIP NN router.
In Figure 9, the Backup DLUS begin to takeover, pipes are established, resources are activated (ACTPU, an activate logical unit [ACTLU]), and DLUR sends session info (primary logical unit [PLU], LU1) on an ACTLU response.
Sessions are now re-established through the new SSCP. Subsequent LU-LU sessions will result in session awareness from DLUR to VTAM3.
When recovery occurs in VTAM1, giveback can occur and SSCP-PU and SSCP-LU sessions can be deactivated by VTAM3 and reactivated by VTAM1, restoring the original configuration without disrupting any LU-LU sessions.