Three special message units exist in SNA: ISOLATED PACING RESPONSE (IPR), ISOLATED PACING MESSAGE (IPM), and EXCEPTION REQUEST (EXR). These are explained below.
ISOLATED PACING RESPONSE (IPR)
An IPR is used on a session if BIND specifies nonadaptive session-level pacing is used; i t indicates a pacing response, and can be used even when operating under no-response protocols.
The following fielqs of the TH and RH are set for an IPR:
TH: Either the normal or expedited flow may be indicated. The sequence number is undefined (it may be set to any value, and is not checked by the receiver).
RH: An IPR is coded all O's except for the Request-Response indicator, the Pacing indicator, and the Chain indicators, which are set to lis; thus, the IPR RH is coded X'830100' by the sender; the receiver identifies an IPR by detecting that (RRI, DRII, DR2I, PI)
=
(1, 0, 0, 1) and ignoring the remaining bitsISOLATED PACING MESSAGE (IPM)
An IPM is used on a session if BIND and RSP(BIND) specify adaptive session-level pacing is used. A solicited IPM is sent by a receiver of paced requests either (1) in response to a pacing request i t receives, or (2) after sending, and receiving an acknowledgment to, an unsolicited IPM with a next-window size of 0, which allows the sender to resume sending requests. An unsolicited IPM is sent as a result of
congestion at the IPM-generating node; no additional IPM (solicited or unsolicited) may be sent until the unsolicited IPM is acknowledged by a reset acknowledgment IPM.
Both solicited and unsolicited IPMs specify the next-window size; in addition, an unsolicited IPM resets the current-window residual pacing count so that any queued requests at the sender are counted in a subsequent window. A reset acknowledgment IPM is sent immediately to respond to an unsolicited IPM, thereby delimiting the end of the current window. A Pacing Request indicator received while an unsolicited IPM is outstanding is ignored.
An IPM is used on a link basis between a T2.1 node and an adjacent boundary node or T2.1 node for adaptive BIND pacing if the XID3 exchange on the link so allows. This use of IPM is the same as for adaptive session-level pacing, except the pacing
window applies only to BINDs flowing over the link.
The following fields are set for an IPM.
TH: The expedited flow is indicated. The sequence number is as defined for an IPR.
For an adaptive BIND pacing IPM, the ODAI bit is always set to 0; the OAF'-DAF' pair is set according to the sender's normal setting of the ODAI bit in BIND: the one
that sets ODAI to 0 in BIND, sets OAF' to X'Ol' and OAF' to X'OO' in the BIND pacing IPM, while the other sets them to the same values reversed.
IPM: The IPM consists of the RH and a 3-byte extension shown below.
0-2 3-5 3
4-5
RH: X'830l00' (same as for an IPR, with the same receiver-checking mentioned above)
IPM Extension bits 0-1, type:
00 solicited: sent in response to a pacing request, or after receiving a reset acknowledgment IPM acknowledging an unsolicited IPM that carried a zero next-window size (so paced requests can resume flowing)
01 unsolicited: can be sent at any time, except when a previous unsolicited IPM is still outstanding (no reset acknowledgment yet received)
10 reset acknowledgment: sent to acknowledge receipt of an unsolicited IPM
11 reserved
bit 2, reset current-window residual-count indicator:
o
do not reset the residual count1 reset the residual count to 0 (i.e., terminate the current window)
Note: Currently, this bit is set to 1 in an unsolicited IPM, and
o
otherwise.bits 3-7, reserved
Next-window information:
bit 0, format: 0 (only value defined)
bits 0-15, next-window size: a binary value in the range 1-32,767 in solicited IPMs, and 0-32,767 in unsolicited IPMs; echoed from
unsolicited IPMs in reset acknowledgment IPMs (the echoed value is not checked when received)
EXCEPTION REQUEST (EXR)
Two EXR types are defined: those replacing requests, and those replacing too-long path information units (PIUs) received by transmission group control (TGC) from an upper layer (e.g., ERC in an intermediate routing node).
EXRs replacing requests are generated by some component between the origin and intended destination ofa request found to be in error. The following fields are set in the TH, RH, and RU.
TH: The sequence number remains the same as in the request being replaced. The data count is altered to properly record the new BIU size. The Mapping field is set to (BBIU, EBIU); an EXR replaces a complete BIU, not just one segment of a segmented BIU. All other fields are left as received.
RH: The Sense Data Included bit is set to 1. All other fields are unchanged.
format as returned in negative responses. The sense data is followed by the original RU, truncated to no more than three bytes, as described for negative responses.
EXRs replacing too-long PIUs are formatted as follows.
TH: Like EXRs replacing requests, EXRs replacing too-long PIUs change only the Mapping field (to lis) and the data count (to 10 in this case).
RH: If the PIU is a request, the SOl field is set to indicate sense data is included; the remainder of the RH is unchanged. If the PIU is a middle or last segment of a multi-segment BIU, an RH is supplied and set to X'07BOOO'.
RU: Bytes 0-3 always contain the sense data, X'800AOOOO'. If the PIU contained a request, bytes 4-6 contain up to the first three bytes of the original RU.
Note: A too-long PIU may be found to be a response. In the case of a positive response, the first three bytes are retained and a sense data value of X'800AOOOO' is inserted ahead of them; the RH is changed to indicate SO and negative response.
In the case of a negative response, the existing sense data value is changed to X'800AOOOO' and the following three bytes of the RU are retained; the RH is unchanged. In both cases, the TH is set to indicate BBIU, EBIU, and OCF=lO.