gtps2m1tACF/SNA Data Communications Reference

Starting LU-LU Sessions

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:

  1. One or more LOCATE commands flow. Eventually, a LOCATE command containing the RSCV will be sent to the node containing the PLU.
  2. The PLU sends out the BIND request (as a FID2 PIU) to start the LU-LU session.

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:

  1. The remote RTP endpoint (node Y) is determined by examining the RSCV.
  2. The table of active RTP connections is searched to see if any of the RTP connections can be used. For an existing RTP connection to be a candidate, all of the following conditions must be true:
  3. If none of the existing RTP connections are candidates for use, the TPF system starts a new RTP connection.
  4. If one or more existing RTP connections are candidates for use, the Select an RTP Connection user exit (URTP) is called. URTP can either select one of the existing RTP connections to use or select to have a new RTP connection started. See TPF System Installation Support Reference for more information about URTP.

ROUTE_SETUP Process

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:

  1. The TPF system receives a LOCATE command on the CP-CP sessions containing the RSCV.
  2. The TPF system builds the ROUTE_SETUP request; the following information is included:

    Req
    The ROUTE_SETUP command is marked as a request.

    PCIDx
    A new procedure correlation identifier (PCID) to identify this ROUTE_SETUP process. This is not the PCID of the LU-LU session being started.

    RSCV
    The route for the LU-LU session.

    DLU
    Name of the destination LU, which, in this example, is LUd.

    FANR
    Forward ANR field. The TPF system includes the ANR label for the first link (which is A1) here. Each node along the route will add to this field.
  3. Node B adds ANR label B2 to the FANR field and then, using the RSCV, passes the ROUTE_SETUP request to node C.
  4. Node C adds ANR label C1 to the FANR field and then, using the RSCV, passes the ROUTE_SETUP request to node D.
  5. Node D builds the ROUTE_SETUP reply; the following fields are included:

    Rep
    The ROUTE_SETUP command is a reply.

    PCIDx
    The PCID from the ROUTE_SETUP request.

    CP_DLU
    CP name of the remote RTP endpoint (CP name of node D).

    FANR
    Forward ANR field. This is copied from the ROUTE_SETUP request.

    NCE_DLU
    NCE identifier assigned to the destination LU in the remote RTP endpoint, which is D4 in this example.

    RANR
    Reverse ANR field. The remote RTP endpoint puts ANR label D1 here. Each node along the route will add to this field.
  6. Because the ROUTE_SETUP command is a reply, intermediate nodes add to the RANR field rather than the FANR field. Node C adds ANR label C2 to the RANR field.
  7. Node B adds ANR label B1 to the RANR field.

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.

LU-LU Session Activation Flows

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





Session Addresses

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:

  1. Node X creates a new SA called SAyx and sends the BIND request to the SLU across the selected RTP connection. The TH of the NLP contains the SA assigned by node X because the SA assigned by the remote RTP endpoint (node Y) is not known yet.
    Note:
    A bit in the SA indicates whether the sending or receiving node assigned the SA.
  2. Node Y accepts the BIND request and assigns an SA of its own called SAxy, which is appended to the BIND response in CV X'62'.
    Note:
    The TH of the NLP contains the SA assigned by node X.
  3. Once the BIND response has been received, node X now knows the SA assigned by node Y and will put that SA (SAxy) in the TH of every subsequent NLP sent on this LU-LU session.
  4. The RTP endpoint owning the SLU (node Y) always knows the SA assigned by the RTP endpoint that owns the PLU and, therefore, always puts SAyx in the TH of NLPs sent on this LU-LU session.

See NLPs for more information about NLPs.