| High-Level Data Link Control | |
| Abbreviation: | HDLC |
| Purpose: | Data framing |
| Developer: | International Organization for Standardization (ISO) |
| Based On: | SDLC |
| Osilayer: | Data link layer |
High-Level Data Link Control (HDLC) is a communication protocol used for transmitting data between devices in telecommunication and networking. Developed by the International Organization for Standardization (ISO), it is defined in the standard ISO/IEC 13239:2002.
HDLC ensures reliable data transfer, allowing one device to understand data sent by another. It can operate with or without a continuous connection between devices, making it versatile for various network configurations.
Originally, HDLC was used in multi-device networks, where one device acted as the master and others as slaves, through modes like Normal Response Mode (NRM) and Asynchronous Response Mode (ARM). These modes are now rarely used. Currently, HDLC is primarily employed in point-to-point connections, such as between routers or network interfaces, using a mode called Asynchronous Balanced Mode (ABM).
HDLC is based on IBM's SDLC protocol, which is the layer 2 protocol for IBM's Systems Network Architecture (SNA). It was extended and standardized by the ITU as LAP (Link Access Procedure), while ANSI named their essentially identical version ADCCP.
The HDLC specification does not specify the full semantics of the frame fields. This allows other fully compliant standards to be derived from it, and derivatives have since appeared in innumerable standards. It was adopted into the X.25 protocol stack as LAPB, into the V.42 protocol as LAPM, into the Frame Relay protocol stack as LAPF and into the ISDN protocol stack as LAPD.
The original ISO standards for HDLC are the following:
ISO/IEC 13239:2002, the current standard, replaced all of these specifications.
HDLC was the inspiration for the IEEE 802.2 LLC protocol, and it is the basis for the framing mechanism used with the PPP on synchronous lines, as used by many servers to connect to a WAN, most commonly the Internet.
A similar version is used as the control channel for E-carrier (E1) and SONET multichannel telephone lines. Cisco HDLC uses low-level HDLC framing techniques but adds a protocol field to the standard HDLC header.
HDLC frames can be transmitted over synchronous or asynchronous serial communication links. Those links have no mechanism to mark the beginning or end of a frame, so the beginning and end of each frame has to be identified. This is done by using a unique sequence of bits as a frame delimiter, or flag, and encoding the data to ensure that the flag sequence is never seen inside a frame. Each frame begins and ends with a frame delimiter. A frame delimiter at the end of a frame may also mark the start of the next frame.
On both synchronous and asynchronous links, the flag sequence is binary "01111110", or hexadecimal 0x7E, but the details are quite different.
Because a flag sequence consists of six consecutive 1-bits, other data is coded to ensure that it never contains more than five 1-bits in a row. This is done by bit stuffing: any time that five consecutive 1-bits appear in the transmitted data, the data is paused and a 0-bit is transmitted.
The receiving device knows that this is being done, and after seeing five 1-bits in a row, a following 0-bit is stripped out of the received data. If instead the sixth bit is 1, this is either a flag (if the seventh bit is 0), or an error (if the seventh bit is 1). In the latter case, the frame receive procedure is aborted, to be restarted when a flag is next seen.
This bit-stuffing serves a second purpose, that of ensuring a sufficient number of signal transitions. On synchronous links, the data is NRZI encoded, so that a 0-bit is transmitted as a change in the signal on the line, and a 1-bit is sent as no change. Thus, each 0 bit provides an opportunity for a receiving modem to synchronize its clock via a phase-locked loop. If there are too many 1-bits in a row, the receiver can lose count. Bit-stuffing provides a minimum of one transition per six bit times during transmission of data, and one transition per seven bit times during transmission of a flag.
When no frames are being transmitted on a simplex or full-duplex synchronous link, a frame delimiter is continuously transmitted on the link. This generates one of two continuous waveforms, depending on the initial state:
The HDLC specification allows the 0-bit at the end of a frame delimiter to be shared with the start of the next frame delimiter, i.e. "011111101111110". Some hardware does not support this.
For half-duplex or multi-drop communication, where several transmitters share a line, a receiver on the line will see continuous idling 1-bits in the inter-frame period when no transmitter is active.
HDLC transmits bytes of data with the least significant bit first (not to be confused with little-endian order, which refers to byte ordering within a multi-byte field).
When using asynchronous serial communication such as standard RS-232 serial ports, synchronous-style bit stuffing is inappropriate for several reasons:
Instead asynchronous framing uses "control-octet transparency", also called "byte stuffing" or "octet stuffing". The frame boundary octet is 01111110, (0x7E in hexadecimal notation). A "control escape octet", has the value 0x7D (bit sequence '10111110', as RS-232 transmits least-significant bit first). If either of these two octets appears in the transmitted data, an escape octet is sent, followed by the original data octet with bit 5 inverted. For example, the byte 0x7E would be transmitted as 0x7D 0x5E ("10111110 01111010"). Other reserved octet values (such as XON or XOFF) can be escaped in the same way if necessary.
The "abort sequence" 0x7D 0x7E ends a packet with an incomplete byte-stuff sequence, forcing the receiver to detect an error. This can be used to abort packet transmission with no chance the partial packet will be interpreted as valid by the receiver.
The contents of an HDLC frame are shown in the following table:
Note that the end flag of one frame may be (but does not have to be) the beginning (start) flag of the next frame.
Data is usually sent in multiples of 8 bits, but only some variants require this; others theoretically permit data alignments on other than 8-bit boundaries.
The frame check sequence (FCS) is a 16-bit CRC-CCITT or a 32-bit CRC-32 computed over the Address, Control, and Information fields. It provides a means by which the receiver can detect errors that may have been induced during the transmission of the frame, such as lost bits, flipped bits, and extraneous bits. However, given that the algorithms used to calculate the FCS are such that the probability of certain types of transmission errors going undetected increases with the length of the data being checked for errors, the FCS can implicitly limit the practical size of the frame.
If the receiver's calculation of the FCS does not match that of the sender's, indicating that the frame contains errors, the receiver can either send a negative acknowledge packet to the sender, or send nothing. After either receiving a negative acknowledge packet or timing out waiting for a positive acknowledge packet, the sender can retransmit the failed frame.
The FCS was implemented because many early communication links had a relatively high bit error rate, and the FCS could readily be computed by simple, fast circuitry or software. More effective forward error correction schemes are now widely used by other protocols.
Synchronous Data Link Control (SDLC) was originally designed to connect one computer with multiple peripherals via a multidrop bus. The original "normal response mode" is a primary-secondary mode where the computer (or primary terminal) gives each peripheral (secondary terminal) permission to speak in turn. Because all communication is either to or from the primary terminal, frames include only one address, that of the secondary terminal; the primary terminal is not assigned an address. There is a distinction between commands sent by the primary to a secondary, and responses sent by a secondary to the primary, but this is not reflected in the encoding; commands and responses are indistinguishable except for the difference in the direction in which they are transmitted.
Normal response mode allows the secondary-to-primary link to be shared without contention, because it has the primary give the secondaries permission to transmit one at a time. It also allows operation over half-duplex communication links, as long as the primary is aware that it may not transmit when it has permitted a secondary to do so.
Asynchronous response mode is an HDLC addition for use over full-duplex links. While retaining the primary/secondary distinction, it allows the secondary to transmit at any time. Thus, there must be some other mechanism to ensure that multiple secondaries do not try to transmit at the same time (or only one secondary).
Asynchronous balanced mode adds the concept of a combined terminal which can act as both a primary and a secondary. Unfortunately, this mode of operation has some implementation subtleties. While the most common frames sent do not care whether they are in a command or response frame, some essential ones do (notably most unnumbered frames, and any frame with the P/F bit set), and the address field of a received frame must be examined to determine whether it contains a command (the address received is ours) or a response (the address received is that of the other terminal).
This means that the address field is not optional, even on point-to-point links where it is not needed to disambiguate the peer being talked to. Some HDLC variants extend the address field to include both source and destination addresses, or an explicit command/response bit.
Three fundamental types of HDLC frames may be distinguished:
The general format of the control field is:
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||
|---|---|---|---|---|---|---|---|---|---|
| N(R) Receive sequence no. | P/F | N(S) Send sequence no. | 0 | I-frame | |||||
| N(R) Receive sequence no. | P/F | type | 0 | 1 | S-frame | ||||
| type | P/F | type | 1 | 1 | U-frame | ||||
There are also extended (two-byte) forms of I and S frames. Again, the least significant bit (rightmost in this table) is sent first.
| 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| N(R) Receive sequence no. | P/F | N(S) Send sequence no. | 0 | Extended I-frame | |||||||||||||
| N(R) Receive sequence no. | P/F | 0 | 0 | 0 | 0 | type | 0 | 1 | Extended S-frame | ||||||||
Poll/Final is a single bit with two names. It is called Poll when part of a command (set by the primary station to obtain a response from a secondary station), and Final when part of a response (set by the secondary station to indicate a response or the end of transmission). In all other cases, the bit is clear.
The bit is used as a token that is passed back and forth between the stations. Only one token should exist at a time. The secondary only sends a Final when it has received a Poll from the primary. The primary only sends a Poll when it has received a Final back from the secondary, or after a timeout indicating that the bit has been lost.
When operating as a combined station, it is important to maintain the distinction between P and F bits, because there may be two checkpoint cycles operating simultaneously. A P bit arriving in a command from the remote station is not in response to our P bit; only an F bit arriving in a response is.
Both I and S frames contain a receive sequence number N(R). N(R) provides a positive acknowledgement for the receipt of I-frames from the other side of the link. Its value is always the first frame not yet received; it acknowledges that all frames with N(S) values up to N(R)−1 (modulo 8 or modulo 128) have been received and indicates the N(S) of the next frame it expects to receive.
N(R) operates the same way whether it is part of a command or response. A combined station only has one sequence number space.
This is incremented for successive I-frames, modulo 8 or modulo 128. Depending on the number of bits in the sequence number, up to 7 or 127 I-frames may be awaiting acknowledgment at any time.
Information frames, or I-frames, transport user data from the network layer. In addition they also include flow and error control information piggybacked on data. The sub-fields in the control field define these functions.
The least significant bit (first transmitted) defines the frame type. 0 means an I-frame.Except for the interpretation of the P/F field, there is no difference between a command I frame and a response I frame; when P/F is 0, the two forms are exactly equivalent.
Supervisory Frames, or 'S-frames', are used for flow and error control whenever piggybacking is impossible or inappropriate, such as when a station does not have data to send. S-frames in HDLC do not have information fields, although some HDLC-derived protocols use information fields for "multi-selective reject".
The S-frame control field includes a leading "10" indicating that it is an S-frame. This is followed by a 2-bit type, a poll/final bit, and a 3-bit sequence number. (Or a 4-bit padding field followed by a 7-bit sequence number.)
The first (least significant) 2 bits mean it is an S-frame. All S frames include a P/F bit and a receive sequence number as described above. Except for the interpretation of the P/F field, there is no difference between a command S frame and a response S frame; when P/F is 0, the two forms are exactly equivalent.
Unnumbered frames, or U-frames, are primarily used for link management, although a few are used to transfer user data. They exchange session management and control information between connected devices, and some U-frames contain an information field, used for system management information or user data.The first 2 bits (11) mean it is a U-frame. The five type bits (2 before P/F bit and 3 bit after P/F bit) can create 32 different types of U-frame. In a few cases, the same encoding is used for different things as a command and a response.
The various modes are described in . Briefly, there are two non-operational modes (initialization mode and disconnected mode) and three operational modes (normal response, asynchronous response, and asynchronous balanced modes) with 3-bit or 7-bit (extended) sequence numbers.
These frames may be used as part of normal information transfer.
There are several U frames which are not part of HDLC, but defined in other related standards.
Link configurations can be categorized as being either:
The three link configurations are:
An additional link configuration is Disconnected mode. This is the mode that a secondary station is in before it is initialized by the primary, or when it is explicitly disconnected. In this mode, the secondary responds to almost every frame other than a mode set command with a "Disconnected mode" response. The purpose of this mode is to allow the primary to reliably detect a secondary being powered off or otherwise reset.
The minimal set required for operation are:
The HDLC module on the other end transmits (UA) frame when the request is accepted. If the request is rejected it sends (DM) disconnect mode frame.
| Type Of Frame | Name | Command/ Response | Description | Info | C-Field Format | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ||||||
| Information(I) | C/R | User exchange data | N(R) | P/F | N(S) | 0 | |||||||
| Supervisory (S) | Receive Ready (RR) | C/R | Positive Acknowledgement | Ready to receive I-frame N(R) | N(R) | P/F | 0 | 0 | 0 | 1 | |||
| Receive Not Ready (RNR) | C/R | Positive Acknowledgement | Not ready to receive | N(R) | P/F | 0 | 1 | 0 | 1 | ||||
| Reject (REJ) | C/R | Negative Acknowledgement | Retransmit starting with N(R) | N(R) | P/F | 1 | 0 | 0 | 1 | ||||
| Selective Reject (SREJ) | C/R | Negative Acknowledgement | Retransmit only N(R) | N(R) | P/F | 1 | 1 | 0 | 1 | ||||
Unnumbered frames are identified by the low two bits being 1. With the P/F flag, that leaves 5 bits as a frame type. Even though fewer than 32 values are in use, some types have different meanings depending on the direction they are sent: as a command or as a response. The relationship between the DISC (disconnect) command and the RD (request disconnect) response seems clear enough, but the reason for making SARM command numerically equal to the DM response is obscure.
| Name | Command/ Response | Description | Info | C-Field Format | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |||||
| Set normal response mode SNRM | C | Set mode | Use 3 bit sequence number | 1 | 0 | 0 | P | 0 | 0 | 1 | 1 | |
| SNRM extended SNRME | C | Set mode; extended | Use 7 bit sequence number | 1 | 1 | 0 | P | 1 | 1 | 1 | 1 | |
| Set asynchronous response mode SARM | C | Set mode | Use 3 bit sequence number | 0 | 0 | 0 | P | 1 | 1 | 1 | 1 | |
| SARM extended SARME | C | Set mode; extended | Use 7 bit sequence number | 0 | 1 | 0 | P | 1 | 1 | 1 | 1 | |
| Set asynchronous balanced mode SABM | C | Set mode | Use 3 bit sequence number | 0 | 0 | 1 | P | 1 | 1 | 1 | 1 | |
| SABM extended SABME | C | Set mode; extended | Use 7 bit sequence number | 0 | 1 | 1 | P | 1 | 1 | 1 | 1 | |
| Set Mode SM | C | Set mode, generic | New in ISO 13239 | 1 | 1 | 0 | P | 0 | 0 | 1 | 1 | |
| Set initialization mode SIM | C | Initialize link control function in the addressed station | 0 | 0 | 0 | P | 0 | 1 | 1 | 1 | ||
| Request initialization mode RIM | R | Initialization needed | Request for SIM command | 0 | 0 | 0 | F | 0 | 1 | 1 | 1 | |
| Disconnect DISC | C | Terminate logical link connection | Future I and S frames return DM | 0 | 1 | 0 | P | 0 | 0 | 1 | 1 | |
| Request disconnect RD | R | Solicitation for DISC Command | 0 | 1 | 0 | F | 0 | 0 | 1 | 1 | ||
| Unnumbered acknowledgment UA | R | Acknowledge acceptance of one of the set-mode commands. | 0 | 1 | 1 | F | 0 | 0 | 1 | 1 | ||
| Disconnect mode DM | R | Responder in disconnected mode | Mode set required | 0 | 0 | 0 | F | 1 | 1 | 1 | 1 | |
| Unnumbered information UI | C/R | Unacknowledged data | Has a payload | 0 | 0 | 0 | P/F | 0 | 0 | 1 | 1 | |
| UI with header check UIH | C/R | Unacknowledged data | New in ISO 13239 | 1 | 1 | 1 | P/F | 1 | 1 | 1 | 1 | |
| Unnumbered poll UP | C | Used to solicit control information | 0 | 0 | 1 | P | 0 | 0 | 1 | 1 | ||
| Reset RSET | C | Used for recovery | Resets N(R) but not N(S) | 1 | 0 | 0 | P | 1 | 1 | 1 | 1 | |
| Exchange identification XID | C/R | Used to Request/Report capabilities | 1 | 0 | 1 | P/F | 1 | 1 | 1 | 1 | ||
| Test TEST | C/R | Exchange identical information fields for testing | 1 | 1 | 1 | P/F | 0 | 0 | 1 | 1 | ||
| Frame reject FRMR | R | Report receipt of unacceptable frame | 1 | 0 | 0 | F | 0 | 1 | 1 | 1 | ||
| Nonreserved 0 NR0 | C/R | Not standardized | For application use | 0 | 0 | 0 | P/F | 1 | 0 | 1 | 1 | |
| Nonreserved 1 NR1 | C/R | Not standardized | For application use | 1 | 0 | 0 | P/F | 1 | 0 | 1 | 1 | |
| Nonreserved 2 NR2 | C/R | Not standardized | For application use | 0 | 1 | 0 | P/F | 1 | 0 | 1 | 1 | |
| Nonreserved 3 NR3 | C/R | Not standardized | For application use | 1 | 1 | 0 | P/F | 1 | 0 | 1 | 1 | |
| Ack connectionless, seq 0 AC0 | C/R | Not part of HDLC | IEEE 802.2 LLC extension | 0 | 1 | 1 | P/F | 0 | 1 | 1 | 1 | |
| Ack connectionless, seq 1 AC1 | C/R | Not part of HDLC | IEEE 802.2 LLC extension | 1 | 1 | 1 | P/F | 0 | 1 | 1 | 1 | |
| Configure for test CFGR | C/R | Not part of HDLC | Was part of SDLC | 1 | 1 | 0 | P/F | 0 | 1 | 1 | 1 | |
| Beacon BCN | R | Not part of HDLC | Was part of SDLC | 1 | 1 | 1 | F | 1 | 1 | 1 | 1 | |
| Command | Response | C-Field Format | Command | Response | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ||||
| 1 | 1 | 0 | 0 | P/F | 0 | 0 | 0 | UI | 1 | 1 | 1 | 0 | P/F | 0 | 1 | 0 | (unused) | ||
| 1 | 1 | 0 | 0 | P/F | 0 | 0 | 1 | SNRM | 1 | 1 | 1 | 0 | P/F | 0 | 1 | 1 | CFGR | ||
| 1 | 1 | 0 | 0 | P/F | 0 | 1 | 0 | DISC | RD | 1 | 1 | 1 | 0 | P/F | 1 | 0 | x | (unused) | |
| 1 | 1 | 0 | 0 | P/F | 0 | 1 | 1 | SM | 1 | 1 | 1 | 0 | P/F | 1 | 1 | x | AC0–AC1 | ||
| 1 | 1 | 0 | 0 | P/F | 1 | 0 | 0 | UP | 1 | 1 | 1 | 1 | P/F | 0 | 0 | 0 | SARM | DM | |
| 1 | 1 | 0 | 0 | P/F | 1 | 0 | 1 | (unused) | 1 | 1 | 1 | 1 | P/F | 0 | 0 | 1 | RSET | ||
| 1 | 1 | 0 | 0 | P/F | 1 | 1 | 0 | UA | 1 | 1 | 1 | 1 | P/F | 0 | 1 | 0 | SARME | ||
| 1 | 1 | 0 | 0 | P/F | 1 | 1 | 1 | TEST | 1 | 1 | 1 | 1 | P/F | 0 | 1 | 1 | SNRME | ||
| 1 | 1 | 0 | 1 | P/F | 0 | x | x | NR0–NR3 | 1 | 1 | 1 | 1 | P/F | 1 | 0 | 0 | SABM | ||
| 1 | 1 | 0 | 1 | P/F | 1 | x | x | (unused) | 1 | 1 | 1 | 1 | P/F | 1 | 0 | 1 | XID | ||
| 1 | 1 | 1 | 0 | P/F | 0 | 0 | 0 | SIM | RIM | 1 | 1 | 1 | 1 | P/F | 1 | 1 | 0 | SABME | |
| 1 | 1 | 1 | 0 | P/F | 0 | 0 | 1 | FRMR | 1 | 1 | 1 | 1 | P/F | 1 | 1 | 1 | UIH | ||
| BCN | |||||||||||||||||||
* ISO/IEC 13239 addition
† Not part of HDLC
The UI, UIH, XID, TEST frames contain a payload, and can be used as both commands and responses. The SM command and FRMR response also contain a payload.