gtps2m1v | ACF/SNA Data Communications Reference |
When the route being used by an RTP connection fails, one of the RTP endpoints will detect the failure and start the path switch process. How and when the TPF system detects failures in the HPR network can be broken into two categories:
A short request timer exists for each RTP connection. Whenever a status request is sent to the remote RTP endpoint, the short request timer is started. Its purpose is to detect failures in the network. Whenever a status reply is received, the short request timer is stopped. If no status reply is received and the short request timer expires, the TPF system sends another NLP with no data to verify the route and the short request timer is restarted. If the short request timer expires two consecutive times before a status reply is received, a path switch is started.
The value of the short request timer is based on the smoothed round-trip time (SRTT) of the RTP connection. The SRTT is the average time it takes the TPF system to receive a status reply on the RTP connection after sending a status request. Each time a status reply is received, the SRTT for the RTP connection is adjusted to take into account changing network conditions.
When the short request timer is started, it is set to a value larger than the SRTT to allow for normal network delays and congestion. This is particularly important when the SRTT is a very low number; for example, in the millisecond range.
The primary purpose of the alive timer is to detect network failures for idle RTP connections. If the TPF system has not sent or received data on an RTP connection for a given period of time, a status request will be sent in an HPR control message to verify that the route is still active. This is also referred to as a heartbeat message. Because the control message contains a status request, the short request timer is started. Normal short request timer processing takes over from this point. If no status reply is received, the TPF system starts a path switch.
The goal of sending these heartbeat messages is to detect network failures in a timely way. For example, if a node along the route of an active RTP connection fails, the next data message for this RTP connection is not going to be sent for several minutes. Without the alive timer, the network failure would not be detected until that first data message is sent minutes later. Processing of that data message would be delayed until a path switch was started and completed successfully.
The other purpose of the alive timer is to keep limited resource links active. If there are limited resource links along the route of an RTP connection, traffic must be sent across that link every so often; otherwise, the intermediate nodes in the network will deactivate the link thinking that there are no sessions using it. Intermediate nodes have no awareness of HPR LU-LU sessions.
The HPRALIVE parameter on the SNAKEY macro in CTK2 defines the alive timer value used by the TPF system. You can also use the ZNKEY command with the HPRALIVE parameter specified to define a value for the alive timer. See TPF ACF/SNA Network Generation for more information about the SNAKEY macro. See TPF Operations for more information about the ZNKEY command.