gtps2m1uACF/SNA Data Communications Reference

Path Switches

When an RTP connection is started, a specific route in the network is assigned to that RTP connection. The RTP connection will use this route until a problem with the route is detected; for example, a node along the route fails. A path switch is the process by which an RTP connection changes its route. The path switch is non-disruptive, meaning no sessions or data is lost, and is transparent to the end user.

The path switch process is started automatically when a problem with the current route is detected. See Detecting Network Failures for more information about how problems in the network are detected.

You can start the path switch process yourself at any time by issuing the ZNRTP SWITCH command. When you enter the ZNRTP SWITCH command, the APPN network is searched to see if a better route exists. While the search is taking place, the RTP connection continues to use its existing route. If the search returns a better route, the path switch process continues and the RTP connection is switched over to that better route. However, if the search fails or indicates that the RTP connection is already using the best route, the path switch process ends and the RTP connection continues to use its existing route. See TPF Operations for more information about the ZNRTP SWITCH command.

Regardless of what caused a path switch to start, the TPF operator is notified when a path switch ends successfully or fails. The fact that a path switch started usually indicates a problem in the network that needs to be investigated. This is true regardless of the outcome of the path switch.

A path switch is done at the RTP connection level; that is, when a path switch is done, all LU-LU sessions on that RTP connection switch to the new route. A path switch is not done for individual LU-LU sessions.

Path Switch Process

The path switch process is very similar to the LU-LU session activation process; that is, an APPN search is performed, followed by the ROUTE_SETUP process. The LOCATE command that flows during the APPN search is marked as search only because a new LU-LU session is not being started. Normally, LOCATE commands flow only during the LU-LU session activation process and do so to calculate a route between the two LUs. During a path switch, the APPN search, instead, calculates a new route between the two RTP endpoints. The search origin and destination fields in the LOCATE command are set to the control point (CP) names of the RTP endpoints.

If the APPN search finds a new route connecting the RTP endpoints, the ROUTE_SETUP process is performed to gather the HPR information for the new route. When the ROUTE_SETUP process ends, an NLP is sent along the new route to the remote RTP endpoint. A Switching Information (SI) segment, which contains information about the new route, is included in the NLP. The presence of an SI segment in an NLP indicates that a path switch has taken place. See ROUTE_SETUP Process for more information about the ROUTE_SETUP process.

The following figure shows an example of the flows during the path switch process:

Figure 72. Path Switch Process




In Figure 72:

  1. An RTP connection exists between the TPF system and node Z. The route is through node X.
  2. Node X fails.
  3. The TPF system detects the failure in the network and sends a LOCATE request on the CP-CP sessions to start the path switch process.
  4. The LOCATE reply is received and contains a new route between the TPF system and node Z. The new route is through node Y.
  5. The TPF system builds the ROUTE_SETUP request and sends it to node Y. Node Y adds information to the ROUTE_SETUP request and passes it to node Z.
  6. Node Z builds the ROUTE_SETUP reply and sends it to node Y. Node Y adds information to the ROUTE_SETUP reply and passes it to the TPF system.
  7. The TPF system sends an NLP to node Z along the new route. The NLP includes the SI segment, which tells node Z the new route to use from now on.
  8. NLPs sent by node Z now use the new route (through node Y).

Path Switch Timer

The path switch timer is started when the RTP endpoint begins the path switch process. The timer continues to run until the path switch process ends successfully, which is signaled by the receipt of an NLP from the remote RTP endpoint acknowledging the path switch. The function of the path switch timer is to detect when the remote RTP endpoint has failed or when no working path exists to the remote RTP endpoint.

The path switch timer (and path switch process) is stopped if an NLP is received on the RTP connection on the existing route. This can happen when network congestion delays the arrival of the status reply.

You can define the value of the path switch timer. When an RTP connection is started, each RTP endpoint informs its partner RTP endpoint how long that node requires to complete a path switch. The HPRPST parameter on the SNAKEY macro in CTK2 defines how long the TPF system tells the remote RTP endpoint to wait when that node starts a path switch before considering that the path switch has failed. You can also use the ZNKEY command with the HPRPST parameter specified to specify a new value for the path switch timer. See TPF ACF/SNA Network Generation for more information about the SNAKEY macro. See TPF Operations for more information about the ZNKEY command.

Note:
Once the value of the path switch timer is set for an RTP connection, that value is used for the life of that RTP connection. Therefore, if you specify a new value for the path switch timer, that new value is used only for new RTP connections that are started. Existing RTP connections continue to use the original value of the path switch timer.

The logic for choosing the value of the HPRPST parameter is the same as the logic that is done today for determining an appropriate value for the automatic network shutdown (ANS) parameter in the NCP generation deck. For example, if you want PU 5 or PU 2.1 LU-LU sessions to remain active across an IPL of the TPF system, you must to set the ANS parameter in the NCP to a value higher than the time it takes the TPF system to complete the IPL. If you want RTP connections (and, therefore, HPR LU-LU sessions) to remain active across an IPL of the TPF system, you need to set the HPRPST parameter to a value higher than the time it takes the TPF system to complete the IPL.

Stationary and Mobile RTP Nodes

An RTP endpoint can be defined as a stationary or mobile node. Most nodes are stationary, but the TPF system is defined as a mobile node to avoid having the network flooded with path switch requests if the TPF system is dumping storage for a long time or performs an IPL. When the short request timer expires and a path switch is needed, the path switch timer is started, but that node does not necessarily send a request to the network to ask for a new path. If the remote RTP endpoint is a stationary node, the local RTP endpoint that detected the network failure will send a request to the network right away to ask for a new path. However, if the remote RTP node is mobile, the local RTP node (if it is stationary) does not send a request for a new path to the network even though its path switch timer is running. When this occurs, it is up to the remote mobile node to do the path switch if there was an actual failure in the network. If the path switch timer expires and the node has not asked for a new path, it will ask the network for a new path at this time as a last chance effort to keep the RTP connection active.

See Short Request Timer for more information about the short request timer. See Path Switch Timer for more information about the path switch timer.

To understand why having the TPF system defined as a mobile node is important, assume that there are 100 000 RTP connections with the TPF system and a system error is taken that lasts for 10 seconds. During that 10-second interval when the TPF system is not sending or receiving data from the network, the remote RTP endpoints will detect that there is a problem and start their path switch timers. When the dump ends and data traffic resumes, the remote RTP endpoints will receive data from the TPF system and stop their path switch timers. If the TPF system was defined as a stationary node, the network would be flooded with 100 000 path switch requests while the TPF system was dumping. This would cause unnecessary high-priority messages (APPN LOCATE commands) to flow and result in the delay of processing data traffic.