- High-Level Data Link Control
High-Level Data Link Control (HDLC) is a bit-oriented
synchronous data link layerprotocol developed by the International Organization for Standardization(ISO). The original ISO standards for HDLC were:
*ISO 3309 — Frame Structure
*ISO 4335 — Elements of Procedure
*ISO 6159 — Unbalanced Classes of Procedure
*ISO 6256 — Balanced Classes of Procedure
The current standard for HDLC is ISO 13239, which replaces all of those standards.
HDLC can be used for point to multipoint connections, but is now used almost exclusively to connect one device to another, using what is known as
Asynchronous Balanced Mode(ABM). The original master-slave modes Normal Response Mode(NRM) and Asynchronous Response Mode(ARM) are rarely used.
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, while ANSInamed their essentially identical version ADCCP.
Derivatives have since appeared in innumerable standards. It was adopted into the
X.25protocol stack as LAPB, into the V.42protocol as LAPM, into the Frame Relayprotocol stack as LAPFand into the ISDNprotocol stack as LAPD. It was the inspiration for the IEEE 802.2 Logical Link Controlprotocol, and it is the basis for the framing mechanism used with the Point-to-Point Protocolon synchronous lines, as used by many servers to connect to a wide area network, most commonly the Internet. A mildly different version is also used as the control channel for E-carrier(E1) and SONETmultichannel telephone lines. Some vendors, such as Cisco, implemented protocols such as Cisco HDLCthat used the low-level HDLC framing techniques but didn't use the standard HDLC header. It has also been used on Tellabs DXX for destination of Trunk.
HDLC frames can be transmitted over synchronous or asynchronous 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 frame delimiter, or "flag", which is a unique sequence of bits that is guaranteed not to be seen inside a frame. This sequence is '01111110', or, in
hexadecimalnotation, 7E. 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. A sequence of 7 or more consecutive 1-bits within a frame will cause the frame to be aborted.
When no frames are being transmitted on a simplex or full-duplex synchronous link, a frame delimiter is continuously transmitted on the link. Using the standard
NRZIencoding from bits to line levels (0 bit = transition, 1 bit = no transition), this generates one of two continuous waveforms, depending on the initial state:
This is used by
modems to train and synchronize their clocks via phase-locked loops. Some protocols allow the 0-bit at the end of a frame delimiter to be shared with the start of the next frame delimiter, i.e. '011111101111110'.
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.
Actual binary data could easily have a sequence of bits that is the same as the flag sequence. So the data's bit sequence must be modified so that it doesn't appear to be a frame delimiter.
On synchronous links, this is done with
bit stuffing. Any time that 5 consecutive 1-bits appear in the transmitted data, the data is paused and a 0-bit is transmitted. This ensures that no more than 5 consecutive 1-bits will be sent. The receiving device knows this is being done, and after seeing 5 1-bits in a row, a following 0-bit is stripped out of the received data. If the following bit is a 1-bit, the receiver has found a flag.
This also (assuming
NRZIwith transition for 0 encoding of the output) provides a minimum of one transition per 6 bit times during transmission of data, and one transition per 7 bit times during transmission of flag, so the receiver can stay in sync with the transmitter. Note however, that for this purpose encodings such as 8b/10b encodingare better suited.
HDLC transmits bytes of data with the least significant bit first (
asynchronous serial communicationsuch as standard RS-232 serial ports, bits are sent in groups of 8, and bit-stuffing is inconvenient. Instead they use "control-octet transparency", also called "byte stuffing" or "octet stuffing". The frame boundary octet is 01111110, (7E in hexadecimalnotation). A "control escape octet", has the bit sequence '01111101', (7D hexadecimal). 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 data sequence "01111110" (7E hex) would be transmitted as "01111101 01011110" ("7D 5E" hex). Other reserved octet values (such as XON or XOFF, and the escape octet itself) can be escaped in the same way if necessary.
The contents of an HDLC frame, including the flag, are
The P/F bit
Poll/Final is a single bit with two names. It is called Poll when set by the primary station to obtain a response from a secondary station, and Final when 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.
* In NRM, possession of the poll token also grants the addressed secondary permission to transmit. The secondary sets the F-bit in its last response frame to give up permission to transmit.
* In ARM and ABM, the P bit forces a response. In these modes, the secondary need not wait for a poll to transmit, so need not wait to respond with a final bit.
* If no response is received to a P bit in a reasonable period of time, the primary station times out and sends P again.
* The P/F bit is at the heart of the basic checkpoint retransmission scheme that is required to implement HDLC; all other variants (such as the REJ S-frame) are optional and only serve to increase efficiency. Whenever a station receives a P/F bit, it may assume that any frames that it sent before it last transmitted the P/F bit and not yet acknowledged will never arrive, and so should be retransmitted.
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.
N(R), the receive sequence number
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" 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 hasone sequence number space.
I-Frames (user data)
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 subfields in the control field define these functions.
The least significant bit (first transmitted) defines the frame type. 0 means an I-frame.
N(S) defines the sequence number of send frame. 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 acknowledgement at any time.
The P/F and N(R) fields operate as described above. 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 do not have information fields.
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 sequence number. If 7-bit sequence numbers are used, there is also a 4-bit padding field.
The first 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.
The 2-bit type field encodes the type of S frame.
Receive Ready (RR)
*Indicate that the sender is ready to receive more data (cancels the effect of a previous RNR).
*Send this packet if you need to send a packet but have no I frame to send.
*A primary station can send this with the P-bit set to solicit data from a secondary station.
*A secondary terminal can use this with the F-bit set to respond to a poll if it has no data to send.
Receive Not Ready (RNR)
*Acknowledge some packets and request no more be sent until further notice.
*Can be used like RR with P bit set to solicit the status of a secondary station.
*Can be used like RR with F bit set to respond to a poll if the station is busy.
*Requests immediate retransmission starting with N(R).
*Sent in response to an observed sequence number gap. After seeing I1/I2/I3/I5, send REJ4.
*Optional to generate; a working implementation can use only RR.
elective Reject (SREJ)
*Requests retransmission of only the frame N(r).
*Not supported by all HDLC variants.
*Optional to generate; a working implementation can use only RR, or only RR and REJ.
Unnumbered frames, or U-frames, are used for link management, and can also be 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 5 type bits (2 before P/F bit and 3 bit after P/F bit) can create 32 different types of U-frame
*Mode settings (SNRM, SNRME, SARM, SARME, SABM, SABME, UA, DM, RIM, SIM, RD, DISC)
*Information Transfer (UP, UI)
*Recovery (FRMR, RSET)
**Invalid Control Field
**Data Field Too Long
**Data field not allowed with received Frame Type
**Invalid Receive Count
*Miscellaneous (XID, TEST)
Link configurations can be categorized as being either:
*"Unbalanced", which consists of one primary terminal, and one or more secondary terminals.
*"Balanced", which consists of two peer terminals.
The three link configurations are:
*"Normal Response Mode" (NRM) is an unbalanced configuration in which only the primary terminal may initiate data transfer. The secondary terminal transmits data only in response to commands from the primary terminal. The primary terminal polls the secondary terminal(s) to determine whether they have data to transmit, and then selects one to transmit.
*"Asynchronous Response Mode" (ARM) is an unbalanced configuration in which secondary terminals may transmit without permission from the primary terminal. However, the primary terminal still retains responsibility for line initialization, error recovery, and logical disconnect.
Asynchronous Balanced Mode" (ABM) is a balanced configuration in which either station may initiate the transmission.
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.
HDLC Command and response repertoire
*Commands (BALA, I, RR, RNR, (SNRM or SARM or SABM) DISC
*Responses (I, RR, RNR, UA, DM, FRMR)
*Initialization can be requested by either side. When the six-mode set-command is issued. This command:
**Signals the other side that initialization is requested
**Specifies the mode, NRM, ABM, ARM
**Specifies whether 3 or 7 bit sequence numbers are in use.The HDLC module on the other end transmits (UA) frame when the request is accepted. And if the request is rejected it sends (DM) disconnect mode frame.
Functional Extensions (Options)
**Commands: ADD - XID
**Responses: ADD - XID, RD
*For 2-way Simultaneous commands & responses are ADD - REJ
*For Single Frame Retransmission commands & responses: ADD - SREJ
*For Information Commands & Responses: ADD - Ul
**Commands: ADD - SIM
**Responses: ADD - RIM
*For Group Polling
**Commands: ADD - UP
*Delete Response I Frames
*Delete Command I Frames
*For Mode Reset (ABM only) Commands are: ADD - RSET
*Data Link Test Commands & Responses are: ADD - TEST
*Request Disconnect. Responses are ADD - RD
HDLC Command/Response Repertoire
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 request 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.
The UI, XID and TEST frames contain a payload, and can be used as both commands and responses.
* A UI frame contains user information, but unlike an I frame it is not acknowledged or retransmitted if lost.
* The XID frame is used to exchange terminal capabilities.
IBM Systems Network Architecturedefined one format, but the variant defined in ISO 8885 is more commonly used. A primary advertisies its capabilities with an XID command, and a secondary returns an XID response.
* The TEST frame is simply a
pingcommand for debugging purposes. The payload of the TEST command is returned in the TEST response.
* PPP, SLIP
coauthors=John L. Fike, H. Charles Baker, John C. Bellamy
title=Understanding Data Communications
publisher=Howard W. Sams & Company
title=Data and Computer Communications
location=Upper Saddle River
*Computer Communications (course notes) by Chaim Zieglier PhD,
* RFC 2687, Proposed Standard, PPP in a Real-time Oriented HDLC-like Framing
* RFC 1662, standard 51, PPP in HDLC-like Framing
* [http://www.interfacebus.com/Design_HDLC.html HDLC information page]
* [http://www.ict.tuwien.ac.at/skripten/datenkomm/infobase/L03-HDLC_v4-4.pdf Data Communication Lectures of Manfred Lindner - Part HDLC]
* [http://www.acacia-net.com/wwwcla/protocol/iso_4335.htm#I%20format HDLC packet format and other information]
* [http://www.cse.dmu.ac.uk/~cfi/Networks/DataLink/DataLink12.htm The HDLC Family of Protocols ]
Wikimedia Foundation. 2010.
См. также в других словарях:
High-level data link control — Pile de protocoles 7 • Application 6 • Présentation 5 • Session 4 • … Wikipédia en Français
High Level Data Link Control — Pile de protocoles 7 • Application 6 • Présentation 5 • Session 4 • … Wikipédia en Français
High level data link control — Pile de protocoles 7 • Application 6 • Présentation 5 • Session 4 • … Wikipédia en Français
High-Level Data Link Control — (HDLC) бит ориентированный кодопрозрачный сетевой протокол управления каналом передачи данных канального уровня сетевой модели OSI, разработанный ISO. Текущим стандартом для HDLC является ISO 13239. HDLC может быть использован в соединениях точка … Википедия
High-Level Data Link Control — (HDLC) ist ein von der ISO normiertes Netzprotokoll ISO/IEC 13239:2002. Es ist innerhalb des ISO/OSI Modells in Schicht 2, der Sicherungsschicht einzugliedern. HDLC basiert in seiner Grundstruktur auf dem SDLC Protokoll von IBM, darüber hinaus… … Deutsch Wikipedia
High Level Data Link Control — [engl.], HDLC … Universal-Lexikon
High-Level Data Link Control — Pile de protocoles 7. Application 6. Présentation 5. Session 4. Tr … Wikipédia en Français
High-Level Data Link Control — HDLC (High Level Data Link Control, control de enlace síncrono de datos) es un protocolo de comunicaciones de propósito general punto a punto y multipunto, que opera a nivel de enlace de datos. Se basa en ISO 3309 e ISO 4335. Surge como una… … Wikipedia Español
High-level Data Link Control — Abbreviated HDLC. An international protocol defined by the ISO (International Organization for Standardization), included in CCITT X.25packet switchingnetworks.HDLCisa bit oriented, synchronous protocol that provides error correction at the… … Dictionary of networking
High-Level Data-Link Control — (HDLC) A bit oriented data link control protocol endorsed by the International Standards Organization. HDLC is functionally identical to ADCCP … IT glossary of terms, acronyms and abbreviations