Synchronous Data Link Control

Synchronous Data Link Control (SDLC) is a computer communications protocol. It is the layer 2 protocol for IBM's Systems Network Architecture (SNA). SDLC supports multipoint links as well as error correction. It also runs under the assumption that an SNA header is present after the SDLC header. SDLC was mainly used by IBM mainframe and midrange systems; however, implementations exist on many platforms from many vendors. The use of SDLC (and SNA) is becoming more and more rare, mostly replaced by IP-based protocols or being tunneled through IP (using AnyNet or other technologies). In the United States, SDLC can be found in traffic control cabinets.

In 1975, IBM developed the first bit-oriented protocol, SDLC, from work done for IBM in the early 1970s. This de facto standard has been adopted by ISO as High-Level Data Link Control (HDLC) in 1979 and by ANSI as Advanced Data Communication Control Procedures (ADCCP). The latter standards added features such as the Asynchronous Balanced Mode, frame sizes that did not need to be multiples of bit-octets, but also removed some of the procedures and messages (such as the TEST message).

SDLC operates independently on each communications link, and can operate on point-to-point multipoint or loop facilities, on switched or dedicated, two-wire or four-wire circuits, and with full-duplex and half-duplex operation. A unique characteristic of SDLC is its ability to mix half-duplex secondary stations with full-duplex primary stations on four-wire circuits, thus reducing the cost of dedicated facilities.

Intel used SDLC as a base protocol for BITBUS, still popular in Europe as fieldbus and included support in several controllers (i8044/i8344, i80152). The 8044 controller is still in production by third party vendors. Other vendors putting hardware support for SDLC (and the slightly different HDLC) into communication controller chips of the 1980s included Zilog, Motorola, and National Semiconductor. As a result, a wide variety of equipment in the 1980s used it and it was very common in the mainframe centric corporate networks which were the norm in the 1980s. The most common alternatives for SNA with SDLC were probably DECnet with Digital Data Communications Message Protocol (DDCMP), Burroughs Network Architecture (BNA) with Burroughs Data Link Control (BDLC), and ARPANET with IMPs.

Differences between SDLC and HDLC

HDLC is mostly an extension of SDLC, but some features were deleted or renamed.

HDLC features not in SDLC

Features present in HDLC, but not SDLC, are:

• frames not a multiple of 8 bits long are illegal in SDLC, but optionally legal in HDLC.
• HDLC optionally allows addresses more than 1 byte long.
• HDLC has an option for a 32-bit frame check sequence.
• asynchronous response mode, and the associated SARM and SARME U frames,
• asynchronous balanced mode, and the associated SABM and SABME U frames,
• and several other frame types created for HDLC:
  • the selective reject (SREJ) S frame,
  • the reset (RSET) command, and
  • the nonreserved (NR0 through NR3) U frames.

Also not in SDLC are later HDLC extensions in ISO/IEC 13239 such as:

• 15- and 31-bit sequence numbers,
• the set mode (SM) U frame,
• 8-bit frame check sequence,
• a frame format field preceding the address,
• an information field in mode set U frames, and
• the "unnumbered information with header check" (UIH) U frame.

Naming differences

HDLC renamed some SDLC frames. The HDLC names were incorporated into later versions of SDLC:

Original name		New name
NSA	Nonseqeuenced acknowledge	UA	Unnumbered acknowledge
NSI	Nonseqeuenced information	UI	Unnumbered information
NSP	Nonseqeuenced poll	UP	Unnumbered poll
ROL	Request online	DM	Disconnected mode
CMDR	Command reject	FRMR	Frame reject
RQI	Request initialization mode	RIM	Request initialization mode
RQD	Request disconnect	RD	Request disconnect

HDLC extensions added to SDLC

Some features were added in HDLC, and subsequently added back to later versions of SDLC.

• Extended (modulo-128) sequence numbers and the corresponding SNRME U frame, were added to SDLC after the publication of the HDLC standard.

SLDC features not in HDLC

Two U frames in SDLC which do not exist in HDLC are:

• BCN (Beacon): When a secondary loses carrier (stops receiving any signal) from the primary, it begins transmitting a stream of "beacon" responses, identifying the location of the communication failure. This is particularly useful in SDLC loop mode.
• CFGR (Configure for test) command and response: The CFGR command contains a 1-byte payload which identifies some special diagnostic operation to be performed by the secondary. The least significant bit indicates that the diagnostic mode should start (1) or stop (0). A payload byte of 0 stops all diagnostic modes. The secondary echoes the byte in its response.
  • 0: Stop all diagnostic modes.
  • 2 (off)/3 (on): Beacon test. Disable all output, causing the next recipient to lose carrier (and begin beaconing).
  • 4 (off)/5 (on): Monitor mode. Disable all frame generation, becoming silent, but do not stop carrier or loop mode operation.
  • 8 (off)/9 (on): Wrap mode. Enter local loopback, connecting the secondary's input to its own output for the duration of the test.
  • 10 (off)/11 (on): Self-test. Perform local diagnostics. CFGR response is delayed until the diagnostics complete, at which time the response is 10 (self-test failed) or 11 (self-test successful).
  • 12 (off)/13 (on): Modified link test. Rather than echoing TEST commands verbatim, generate a TEST response consisting of a number of copies of the first byte of the TEST command.

Several U frames are almost entirely unused in HDLC, existing primarily for SDLC compatibility:

• Initialization mode, and the associated RIM and SIM U frames, are so vaguely defined in HDLC as to be useless, but are used by some peripherals in SDLC.
• Unnumbered poll (UP) is almost never used in HDLC, its function having been superseded by asynchronous response mode. UP is an exception to the usual rule in normal response mode that a secondary must receive the poll flag before transmitting; while a secondary must respond to any frame with the poll bit set, it may respond to a UP frame with the poll bit clear if it has data to transmit. If the lower-level communication channel is capable of avoiding collisions (as it is in loop mode), UP to the broadcast address allows multiple secondaries to respond without having to poll them individually.

The TEST U frame was not included in early HDLC standards, but was added later.

Loop mode

A special mode of SDLC operation which is supported by e.g. the Zilog SCC but was not incorporated into HDLC is SDLC loop mode. In this mode, a primary and a number of secondaries are connected in a unidirectional ring network, with each one's transmit output connected to the next's receive input. Each secondary is responsible for copying all frames which arrive at its input so that they reach the rest of the ring and eventually return to the primary. Except for this copying, a secondary operates in half-duplex mode; it only transmits when the protocol guarantees it will receive no input.

When a secondary is powered off, a relay connects its input directly to its output. When powering on, a secondary waits for an opportune moment and then goes "on-loop" inserting itself into the data stream with a one-bit delay. A similar opportunity is used to go "off-loop" as part of a clean shutdown.

In SDLC loop mode, frames arrive in a group, ending (after the final flag) with an all-ones idle signal. The first seven 1-bits of this (the pattern 01111111) constitutes a "go-ahead" sequence (also called EOP, end of poll) giving a secondary permission to transmit. A secondary which wishes to transmit uses its 1-bit delay to convert the final 1 bit in this sequence to a 0 bit, making it a flag character, and then transmits its own frames. After its own final flag, it transmits an all-ones idle signal, which will serve as a go-ahead for the next station on the loop.

The group starts with commands from the primary, and each secondary appends its responses. When the primary receives the go-ahead idle sequence, it knows that the secondaries are finished and it may transmit more commands.

The beacon (BCN) response is designed to help locate breaks in the loop. A secondary which does not see any incoming traffic for a long time begins sending "beacon" response frames, telling the primary that the link between that secondary and its predecessor is broken.

Because the primary also receives a copy of the commands it sent, which are indistinguishable from responses, it appends a special "turnaround" frame at the end of its commands to separate them from the responses. Any unique sequence which will not be interpreted by the secondaries will do, but the conventional one is a single all-zero byte. This is a "runt frame" with an address of 0 (reserved, unused) and no control field or frame check sequence. (Secondaries capable of full-duplex operation also interpret this as a "shut-off sequence", forcing them to abort transmission.)

References

• McFadyen, J. H. (1976). "System Network Architecture: An Overview" (PDF). IBM Systems Journal. 15 (1): 4–23.
• Odom, Wendell (2004). CCNA INTRO Exam Certification Guide: CCNA Self-study. Indianapolis, IN: Cisco Press. ISBN 1-58720-094-5.
• Friend, George E.; John L. Fike; H. Charles Baker; John C. Bellamy (1988). Understanding Data Communications (2nd ed.). Indianapolis: Howard W. Sams & Company. ISBN 0-672-27270-9.
• Pooch, Udo W.; William H. Greene; Gary G. Moss (1983). Telecommunications and Networking. Boston: Little, Brown and Company. ISBN 0-316-71498-4.
• Hura, Gurdeep S.; Mukesh Singhal (2001). Data and computer communications: networking and internetworking. Indianapolis: CRC Press. ISBN 0-8493-0928-X.
• ITS Cabinet Standard. Washington, DC: Institute of Transporation Engineers. November 16, 2006. p. 96.

External links

• IBM Communication Products Division (March 1979). IBM Synchronous Data Link Control: General Information (PDF) (Technical report) (3rd ed.). Document No. GA27-3093-2.
• Cisco page on Synchronous Data Link Control and Derivatives
• Bitbus/fieldbus community site.