ACC HDLC-NRM (SDLC) User's Guide

Using HDLC-NRM (SDLC) Protocols
Error Handling
Chapter 334
Error Handling
Several mechanisms are used to detect and recover from error
conditions.
Checkpoint Recovery
The principal method of error recovery used by the HDLC-NRM (SDLC)
protocol is known as checkpointing. This technique, which is more fully
described in ISO 4335, ensures that a received frame with the poll or
final bit set acknowledges all frames sent prior to or including the last
frame sent with the final or poll bit (respectively) set. If this is not the
case, then there is a need for re-transmission of the unacknowledged
frames. If this condition occurs more times than the configured retry
limit, then the protocol software will attempt to either request a reset of
the link (if a secondary) or reset the mode with SNRM (if a primary), to
recover from the error condition.
Transmit Blockage
Another error which can occur is the inability to transmit frames. This is
usually because of a hardware exception condition. Such a condition is
usually caused by a cable problem between the mux panel and the Data
Communications Equipment (DCE). However, there are several other
conditions which can cause such an error, such as an absent or slow
transmit clock signal, or no Clear to Send signal. Because this condition
is detected by a timer expiring, it can also be detected because a very low
line speed is being used. When this error occurs, an immediate exception
condition is sent to the application via an unsolicited status message
with reason code “Cable or local modem fault”.
Command/Response Reject Conditions
In accordance with the ISO standards, a number of error conditions
associated with frames are detected and handled. Short frames (less
than Address and Control field) are discarded. Frames ending in an
abort sequence, or frames received with FCS errors are also discarded.