gtps2m1y | ACF/SNA Data Communications Reference |
After the TPF system performs an IPL, it will take one of the following actions for the RTP connections:
When the TPF system takes an outage, whether the network remains active or not depends on how long it takes the TPF system to IPL. If the TPF system is down for too long and the automatic network shutdown (ANS) timers expire, the network will deactivate the links to the TPF system causing all PU 5 and PU 2.1 LU-LU sessions across those links to fail. If the links remain active across the IPL, the LU-LU sessions remain active as well.
Because there is no way of knowing how long the TPF system has been down for a hardware IPL, and because you can define the ANS timer values for each link, the TPF system verifies the status of each link after the IPL. For HPR LU-LU sessions, a link failure does not cause those sessions to fail. Instead, it triggers a path switch of the RTP connections that were using that link. If the TPF system is down for a long period of time, the network will clean up all RTP connections that went to the TPF system and, therefore, all HPR LU-LU sessions as well. When the TPF system comes back up, it needs to be able to detect this condition and internally clean up all RTP connections and HPR LU-LU sessions that were active before the outage.
If the network has cleaned up its RTP connections, the TPF system could detect this after the IPL. No responses would be received on those RTP connections causing path switches to be started. When the path switch attempts eventually time out, this would cause the TPF system to clean up the RTP connections. Rather than wait for all of this to happen, the TPF system checks to see if any HPR-capable links remained active across the IPL. If not, this indicates that the TPF system has been down too long and causes the TPF system to clean up all RTP connections and HPR LU-LU sessions.
If at least one HPR-capable link remained active across the IPL of the TPF system and the SNA tables were reloaded from file (which always occurs for a hardware IPL), information in the RTPCB entries will likely be old. If RTPRSYNC=YES is coded on the SNAKEY macro in CTK2, the RTP connections remain active and the TPF system performs the RTP connection resynchronization process for each RTP connection. If RTPRSYNC=NO is coded on the SNAKEY macro in CTK2, the TPF system ends all RTP connections.
If at least one HPR-capable link remained active across the IPL of the TPF system and the core copies of the SNA tables were reused, the RTP connections remain active. The RTP connection resynchronization process is not necessary when this occurs because the information in the RTPCB entries is accurate.
The RTP connection resynchronization process is the method used to keep RTP connections active across a hardware IPL of the TPF system. After a hardware IPL, the file copy of the SNA tables, including the RTPCB table, is reloaded from file. The RTPCB table on file is likely to be several seconds old. Therefore, the TPF system does not know the current input or output byte sequence number (BSN) values for an RTP connection. The current SYNC and ECHO values for an RTP connection are not known either. See SYNC and ECHO Numbers for more information about how SYNC and ECHO numbers are used by HPR support. The following provides an example of the problems:
All of the values in the RTPCB entry are old, which can lead to different problems:
The RTP connection resynchronization process prevents all of these problems. The first step after reloading the RTPCB table from file is to increase the SYNC number value of the RTP connection by a large amount to make sure it is current. Using the previous example, the SYNC number in the file copy of the RTPCB entry is 85, but the real current SYNC number is 88. The RTP connection resynchronization process will increase the SYNC number in the RTP entry by a large amount (for example, by 100), so that the new value (185) is guaranteed to be greater than the current SYNC number. This way, control information sent by the TPF system will be accepted.
The next step is to set a flag in the RTPCB entry to indicate that when the first NLP is received after the IPL, assume that the BSN in that NLP is the BSN of the next expected message.
The final step is the most complicated part of the RTP connection resynchronization process. The TPF system sends out an HPR control message (an NLP with no data) to ask the remote RTP endpoint the BSN of the next message it is expecting. Until the response to that control message is received, the TPF system cannot send any data on this RTP connection. When the response is received, the next expected BSN value is copied into the output BSN field in the RTPCB entry and data traffic continues.
The following figure shows an example of the events leading up to a hardware IPL of the TPF system:
Figure 80. RTP Connection Resynchronization, before the IPL
In Figure 80:
The following figure shows an example of the steps involved in the RTP connection resynchronization process:
Figure 81. RTP Connection Resynchronization, after the IPL
In Figure 81:
The ECHO number (104) in the STATUS segment does not match the current SYNC number (203); therefore, the RTP connection resynchronization process continues. The STATUS segment in this NLP is the reply to the status request sent out just before the IPL.
This example shows that the first STATUS segment received after the IPL does not necessarily contain the latest information. The RSEQ value of the first STATUS segment was 350, but NLPs with BSN values 350-449 were already sent before the IPL. The RTP connection resynchronization process must send its own status request after the IPL and wait for the reply to that status request to determine the correct RSEQ value.
The RTPRSYNC parameter on the SNAKEY macro in CTK2 enables the RTP resynchronization process for the TPF system. You can also use the ZNKEY command with the RTPRSYNC parameter specified to enable the RTP resynchronization process. See TPF ACF/SNA Network Generation for more information about the SNAKEY macro. See TPF Operations for more information about the ZNKEY command.