gtps2m1w | ACF/SNA Data Communications Reference |
In PU 5 and PU 2.1 networks, a message (either an SNA command or user data) flows in a path information unit (PIU). In HPR support, a message flows in a network layer packet (NLP), which is an extension to the existing PIU format.
Figure 73 compares the parts of a PIU to the parts of an NLP.
Figure 73. Comparing an NLP to PIUs
The following information describes the parts of a PIU and an NLP, and how these parts are used:
In a PU 5 or PU 2.1 network, the TH is required in a PIU, but the RH and RU are optional; therefore, possible combinations of a PIU are:
The FID5 TH, RH, and RU are often referred to as the DATA portion of an NLP. The NHDR and THDR are required in an NLP, but all of the parts in the DATA portion are optional. The valid combinations of an NLP are:
See HPR Control Messages for more information about HPR control messages.
See Reassembling Input Messages for more information about TH chained messages.
See Segmentation and Reassembly for more information about THDR chained messages.
See IBM Systems Network Architecture Network Product Formats for more information about PIUs and NLPs.
The network layer header (NHDR) portion of the NLP is used by the network to route the NLP from the origin RTP endpoint to the destination RTP endpoint along a specific path. When the origin RTP endpoint builds the NLP, the list of ANR labels representing the path from the origin node to the destination node is placed in the ANRF field of the NHDR. When an intermediate node receives an NLP, the ANRF field in the NHDR is examined to find the ANR label of the next hop, that ANR label is removed from the ANRF field, and the NLP is then routed to the next node. The NHDR is the only part of an NLP that is examined by or modified by intermediate nodes in the network. When the NLP arrives at the remote RTP endpoint, the only part of the ANRF field that remains is the NCE representing the destination LU.
The following figure shows an example of how NLPs are routed:
Figure 74. Routing an NLP through the Network
In Figure 74:
The following are the steps for routing NLPs between the TPF system to node D:
When Node D receives the NLP, the entire NLP is processed. The NLP was routed correctly because the ANRF field contains the NCE of node D.
When the TPF system receives the NLP, the entire NLP is processed. The NLP did get routed correctly because the ANRF field contains the NCE of the TPF system.
The NHDR of each NLP includes the specific path that the NLP will take in the network. If the current route fails and a path switch is done, a different set of ANR labels is placed in the ANRF field of subsequent NLPs to tell the intermediate nodes the new path to use. Because intermediate nodes only examine the NHDR, they have no knowledge of the RTP connection or LU-LU session associated with the NLP.
Because NLPs and FID2 PIUs can flow on the same link, the first 3 bits after the link header (LH) are used to indicate the type of message. In a FID2 PIU, these are the first 3 bits of the TH and are always set to X'001'. In an NLP, these are the first 3 bits of the NHDR and are always set to X'110'.
There are two slowdown indicators in the NHDR. When an NLP is first built by the origin RTP endpoint, both of these slowdown indicators are cleared. If any intermediate node along the route is congested, it can set one of the slowdown indicators in the NHDR. When the NLP arrives at the destination RTP endpoint, the slowdown indicators in the NHDR are examined and used to adjust the rate at which data is sent on the RTP connection. See ARB Pacing for information about how the slowdown indicators in the NHDR are used.
The transport header (THDR) portion of the NLP contains control information about the RTP connection. The THDR is created by the RTP endpoint that sends the NLP and is processed by the remote RTP endpoint that receives the NLP. Intermediate nodes do not examine or modify the THDR.
The first part of the THDR consists of fixed-length fields that are always present. The key fields include:
Following the fixed part of the THDR, there are zero or more optional segments, each of which contains control information about the RTP connection. See THDR Optional Segments for more information about THDR optional segments.
When the TPF system receives an NLP, the NHDR and the THDR are processed immediately during read interrupt processing. SNA Opzero processes the TH, RH, and RU sections of a PIU and an NLP.
When the TPF system needs to send control information (one or more optional segments) to the remote RTP endpoint, the optional segments and user data are sent in the same NLP whenever possible. In the context of this discussion, user data means either application data or an SNA command (for example, a BIND). Piggybacking of control data and user data in the same NLP is done to reduce the number of NLPs that flow on an RTP connection. If one or more optional segments need to be sent when no user data is waiting to be sent, and no user data is generated in the next SNA polling interval, the TPF system will send an HPR control message (which is an NLP that contains just an NHDR and THDR, but no data).
The following list contains the optional segments that can be included in
the THDR:
Adaptive Rate-Based | ARB (X'22') | Used to control the flow of data on the RTP connection. |
Connection Fault | CF (X'12') | Sent whenever a protocol violation has been detected, or to immediately deactivate an RTP connection. |
Connection Identifier Exchange | CIE (X'10') | When node X starts an RTP connection with node Y, the first NLP sent by node Y back to node X includes the CIE segment, which contains the TCID that node Y assigned to the RTP connection that was just started. |
Client "Out of Band" Bits | COB (X'10') | Used to deactivate the RTP connection normally. |
Status | STATUS (X'0E') | Acknowledges the receipt of data and informs the RTP endpoint of missing data that needs to be retransmitted. |
Connection Setup | CS (X'0D') | Sent when a new RTP connection is being started. It identifies the control point (CP) name of the destination RTP endpoint and the network connection endpoint (NCE) identifier in the destination RTP endpoint. |
Switching Information | SI (X'14') | Sent by node X to node Y to inform node Y of the path it should now use for the RTP connection. The SI segment is included in the NLP that starts the RTP connection and anytime a path switch has occurred. |
RTP endpoints maintain SYNC numbers for each RTP connection. A SYNC number is sent as part of the STATUS segment when present in the THDR of an NLP. The SYNC number is used to detect old control information. Each time a state change takes place on the RTP connection, the SYNC number is incremented. Each RTP endpoint has its own SYNC number. In addition, each RTP endpoint keeps track of the most current SYNC number received from the remote RTP endpoint. When building a STATUS segment, an RTP endpoint places its own SYNC number in the SYNC field of the STATUS segment and then places the current SYNC number received from the remote RTP endpoint in the ECHO field of the STATUS segment.
The SYNC and ECHO numbers are used to detect a path switch race condition, which means that both RTP endpoints do a path switch at the same time. When an RTP endpoint does a path switch, it increments its SYNC number and sends an NLP containing the STATUS segment and the SI segment, which contains the new route. When a STATUS segment is received whose ECHO field contains the value of the new SYNC number of this RTP endpoint, the remote RTP endpoint has acknowledged that a path switch has taken place. A path switch race condition exists if the NLP with the SI segment is sent and then an NLP with an SI segment is received before receiving an NLP with a STATUS segment that acknowledges the path switch.
SYNC and ECHO numbers also play an important role in the RTP connection resynchronization process. See RTP Connection Resynchronization Process for more information about the RTP connection resynchronization process.
The data portion of an NLP can contain a transmission header (TH), request header (RH), and request unit (RU), all of which are optional. The data portion of an NLP exists when there is either application data or an SNA command to send on an LU-LU session. The RH and RU sections of an NLP are identical to the RH and RU sections in an FID2 PIU.
The TH section in the data portion of an NLP is an FID5 TH. It is a different format than an FID2 or FID4 TH, but provides the same function in that it identifies the LU-LU session. The session address (SA) field is contained in the FID5 TH. The combination of the SA from the TH and the TCID from the THDR uniquely identifies the LU-LU session. As with the FID2 and FID4 TH, the FID5 TH includes the sequence number field (SNF), which identifies the sequence number of the message for this LU-LU session.
An HPR control message is an NLP that includes an NHDR and THDR, but no data (no TH, RH, or RU). Control messages are sent when one RTP endpoint has control information (THDR optional segments) to send to the partner RTP endpoint regarding a specific RTP connection, but has no user data to send for any of the LU-LU sessions on the RTP connection.
Before HPR support, every PIU that flowed in or out of the TPF system contained data for an LU-LU session, except for virtual route (VR) pacing responses. With HPR support, there are two more conditions where there is no LU-LU session data:
Because an NLP is larger than a PIU, messages that used to fit in a single read buffer before HPR support was installed may now span more than one read buffer. To account for this condition, consider increasing the size of the read buffers used to read in data from the network.
Use the UNITSZ parameter on the SNAKEY macro in CTK2 to change the size of the read buffers. See TPF ACF/SNA Network Generation for more information about the SNAKEY macro.