gtps2m1s | ACF/SNA Data Communications Reference |
An RTP connection is a logical pipeline between two RTP nodes over which one or more LU-LU sessions exist. The two RTP nodes are the RTP endpoints for the RTP connection, and these two nodes are not necessarily adjacent. RTP connections are based on SNA class of service (COS), meaning all LU-LU sessions for a given RTP connection have the same COS. Between a pair of RTP nodes, there can be multiple RTP connections, each with the same COS or a different COS.
At any point in time, an RTP connection is in one of the following states:
If only part of the network supports HPR, it is possible for an RTP connection to be established for only the HPR-capable part of the network and have the LU-LU session extend beyond that point.
Figure 64 shows an example of whether an RTP connection can be started and, if so, how far the RTP connection goes based on the levels of HPR support in the nodes in the network:
Figure 64. Sample Networks and RTP Connections
In Figure 64, LU X in the TPF system is in session with LU Y in node D across a three-hop route. The capabilities of the nodes along the path determine if HPR support can be used and, if so, for how much of the session route. The following six examples are shown in Figure 64:
The following example shows an RTP connection that exists for only part of the LU-LU session path:
Figure 65. Combination of HPR Support and APPN
Starting RTP Connections discusses how to determine if you can use HPR support and, if so, for how much of the session route. You get the benefits of HPR support only on the HPR part of the route (the RTP connection). For example, in Figure 65 there is a session between LU X in the TPF system and LU Y in node E. Assume the path goes from the TPF system to node B, then to node C, then to node D, and then to node E. The RTP connection is between the TPF system and node C. If node B fails, the RTP connection would automatically switch and go through node F (rather than node B). The session between LU X and LU Y would remain active. However, if node D fails, the LU-LU session fails even though another path exists between nodes C and E (through node G).
Because an RTP node can have several RTP connections active at the same time, a token called a transport connection identifier (TCID) is assigned to uniquely identify an RTP connection. Each RTP endpoint assigns a TCID to each RTP connection. Therefore, there are two TCIDs assigned to each RTP connection. For example, assume there is an RTP connection from node X to node Y. The TCID assigned by node X is TCIDyx and the TCID assigned by node Y is TCIDxy. Each message sent on an RTP connection contains one TCID in the transport header (THDR) section of the NLP. Whenever possible, the sending node should use the TCID that the remote RTP endpoint assigned. When node X sends NLPs to node Y, TCIDxy should be placed in the THDR section of the NLP. This is done for performance reasons because a node should generate a TCID in such a way that it can be used as an index or pointer into control blocks defined in that node.
Just like ANR label generation, TCIDs are only unique per node, not in the whole network.
See NLPs for more information about NLPs. See THDRs for more information about the format of the THDR and how it is used.
Unlike links and sessions, which you can start yourself, you can never start an RTP connection. Instead, RTP connections are always started automatically by RTP nodes during the LU-LU session activation process. See Starting LU-LU Sessions for more information about how RTP connections are started.
RTP connections are deactivated automatically by one of the RTP endpoints when the connection is no longer being used. This happens some time after the last LU-LU session that was using the RTP connection ends. The TPF system delays ending the RTP connection in case a new LU-LU session is started that can use that RTP connection.
How long a node waits to deactivate the RTP connection depends on the implementation. In the TPF system, the amount of time to wait is based on the value of the alive timer. See Alive Timer for more information about the alive timer.
You can deactivate an RTP connection yourself at any time by using the ZNRTP INACT command. The remote operator can deactivate an RTP connection at any time as well. When you deactivate an RTP connection, it is immediate and unconditional. The RTP connection is cleaned up and all LU-LU sessions that were using the RTP connection are also cleaned up. See TPF Operations for more information about the ZNRTP INACT command.
To display information about RTP connections:
See TPF Operations for more information about the ZNRTP, ZNDLU, and ZNMON commands.