gtps2m1sACF/SNA Data Communications Reference

RTP Connections

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:

CONNECTED
This is the normal state of an RTP connection. Data traffic is flowing between the RTP endpoints.

MOVING
The TPF system is attempting to find a better route for the RTP connection because the ZNRTP SWITCH command was entered. Data traffic continues to flow on the current route. See TPF Operations for more information about the ZNRTP SWITCH command.

RESYNC
The RTP connection resynchronization process is in progress for the RTP connection. See RTP Connection Resynchronization Process for more information about the RTP connection resynchronization process.

STARTING
The RTP connection is being activated and the ROUTE_SETUP process is still in progress. See ROUTE_SETUP Process for more information about the ROUTE_SETUP process.

SWITCHING
A path switch is in progress because the TPF system detected a failure in the network. No data is flowing. See Path Switches for more information about the path switch process.

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:

  1. All intermediate nodes support HPR, and the node containing the destination LU (LU Y in node D) not only supports HPR, but is an RTP node. This means that you can use HPR support for the entire session route, and the RTP connection will be from the TPF system to node D.
  2. All intermediate nodes support HPR, and the node containing the destination LU is an RTP node. Again, you can use HPR support for the entire session route. Even though nodes B and C are RTP nodes, they function like ANR nodes in this example.
  3. Node D supports only APPN; it does not support HPR. This means that you cannot use HPR support for the entire path. However, you can use HPR support for part of the path because one intermediate node (node C) is an RTP node, and all nodes between that node and the TPF system support HPR. In this example, the RTP connection exists between the TPF system and node C. Base APPN flows are used between nodes C and D.
  4. Node D does not support APPN or HPR support. In this example, the RTP connection exists between the TPF system and node C. PU 5 flows are used between nodes C and D.
  5. Even though all nodes support HPR, you cannot use HPR in this example because none of the intermediate nodes or the destination node are an RTP node. No RTP connection can be established; therefore, base APPN flows are used for the entire route.
  6. Even though the destination node is an RTP node, you cannot use HPR support in this example because node C does not support HPR. Flows in and out of node C must be base APPN.

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

TCIDs

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.

Starting RTP Connections

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.

Deactivating RTP Connections

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.

Displaying RTP Connections

To display information about RTP connections:

See TPF Operations for more information about the ZNRTP, ZNDLU, and ZNMON commands.