gtps2m1t | ACF/SNA Data Communications Reference |
HPR support does not change the existing procedures that are used to start LU-LU sessions. The APPN search (LOCATE command flows on the CP-CP sessions) is still used to calculate the route for the LU-LU session. Once a route has been calculated, it is passed to the node that owns the primary logical unit (PLU) in the route selection control vector (RSCV), which is CV X'2B'. The RSCV contains a hop-by-hop list of the path through the network from the PLU to the secondary logical unit (SLU).
With HPR support, additional information is included in the RSCV for each hop along the route whether the link (hop) supports HPR or not and, if the link supports HPR, whether it is connected to an RTP node or not.
By examining the RSCV, the node that contains the PLU determines if HPR support can be used for this LU-LU session and, if so, how much of the route can use HPR support. This is done automatically and does not require any new network definitions or new parameters on operator messages to use HPR support. On a session by session basis, the system software determines if HPR support can be used.
In base APPN, LU-LU session initiation involves two key steps:
With HPR support, additional processing is done between steps 1 and 2. The RSCV is examined to see if HPR support can be used. If HPR support cannot be used, there is no change to the existing processing. A FID2 BIND request is sent out.
If the RSCV indicates that HPR support can be used, the node containing the PLU selects the RTP connection to use for this LU-LU session. How this is done depends on the implementation, but basically involves either starting a new RTP connection or using one of the existing RTP connections. No matter what, the first step is to determine how far HPR support can be used along the LU-LU session route or, in other words, how far the RTP connection will go. The node where the RTP connection ends is referred to as the remote RTP endpoint. If the RTP connection goes the entire route from the PLU to the SLU, the remote RTP endpoint is the node that contains the SLU. Otherwise, HPR support is being used for only part of the route, and the SLU resides in a node beyond the remote RTP endpoint.
If an LU-LU session is being started, the PLU resides in the TPF system, and HPR support can be used for at least part of the route, the TPF system selects which RTP connection to use. The following describes how the TPF system selects the RTP connection to use:
When an RTP connection starts, there is a new flow called a ROUTE_SETUP command that occurs after the APPN search (LOCATE flows) and before the BIND request is sent out. The purpose of the ROUTE_SETUP process is to gather the HPR information for the route, including:
The ROUTE_SETUP request is sent by the node containing the PLU and is processed by every node along the route, up to and including the remote RTP endpoint, to obtain the forward route information. When the ROUTE_SETUP request reaches the remote RTP endpoint, a ROUTE_SETUP reply is sent back to gather the reverse route information.
Figure 66 shows an example of the flows during the ROUTE_SETUP process.
Figure 66. ROUTE_SETUP Process
In the figure, a session between LUa (the PLU) in the TPF system and LUd in node D is starting. The RSCV calculated by the network is a three-hop route, the TPF system determined that HPR support can be used for the entire route, and a new RTP connection will be started. The step-by-step description of the ROUTE_SETUP process is as follows:
When the ROUTE_SETUP reply is received by the TPF system, the RTP connection is started by sending out an NLP marked as a new connection. The NLP also contains the BIND request to start the new LU-LU session.
The ROUTE_SETUP process is also used during the path switch process. See Path Switches for more information about the path switch process.
If an LU-LU session is starting and an existing RTP connection is used, the ROUTE_SETUP process is skipped and a BIND request is sent in an NLP instead. The following examples show the flows in and out of the TPF system during LU-LU session activation based on whether HPR support is used or not:
Figure 67. LU-LU Session Activation, HPR Support Is Not Used
Figure 68. LU-LU Session Activation, a New RTP Connection Is Started
Figure 69. LU-LU Session Activation, an Existing RTP Connection
Figure 70. LU-LU Session Activation, Part of the Route
For an LU-LU session in a PU 5 network, the combination of the network address (NA) of the PLU with the NA of the SLU uniquely identifies the session. The NAs flow in the transmission header (TH) section of an FID4 PIU.
For an LU-LU session in a PU 2.1 network, a session identifier (SID) together with the origin destination assignment indicator (ODAI) indicator uniquely identify the session between a pair of adjacent nodes. The SID and ODAI indicator flow in the TH section of an FID2 PIU.
For an LU-LU session in an HPR network, a session address (SA) uniquely identifies the session. The SA flows in the TH section of an NLP.
An SA is an 8-byte token that uniquely identifies an LU-LU session in the HPR network. An SA is unique per RTP connection, not per node. There are two SAs assigned to an LU-LU session, one assigned by each RTP endpoint. One SA flows in the TH section of an NLP. Whenever possible, the SA that the remote RTP endpoint assigned is placed in the TH. For example, if node X is sending data to node Y, the SA assigned by node Y is placed in the TH of the NLP.
The reason for having two SAs assigned to an LU-LU session is the same reason that two TCIDs are assigned to an RTP connection. The intention is that a node will create an SA in such a way that it can be used as an index or pointer to control blocks defined in that node.
The SA assigned by the RTP endpoint that owns the PLU is sent in the TH section of the NLP containing the BIND request. The SA assigned by the RTP endpoint that owns the SLU is sent in the BIND response in a new control vector, CV X'62'.
The following figure shows an example of how session addresses are used:
Figure 71. Session Address Usage
In Figure 71:
See NLPs for more information about NLPs.