Data Link Layer
The Data Link Layer (DLL) of the OSI Reference Model, also known as Layer 2, is responsible for providing error-free communication between adjacent devices on a network. To accomplish this, the DLL protocol must perform several functions:
- Framing and Synchronization: The Physical Layer deals with the transmission of bits. At the DLL, bits are organized and blocked together into units typically called frames. Some information, then, must be added to the frame to indicate its beginning and end. The frame usually comprises a header, a trailer, and an information payload.
- Data Delimiting: Because the DLL protocol adds overhead to the information being transmitted, the system receiving the information has to be able to tell the difference between the overhead added by the transmitter and the actual data being transmitted.
- Detection/correction of bit errors: Most DLL protocols use a cyclic redundancy check (CRC) to detect bit errors. The CRC is typically found in the trailer. If the DLL also acts to correct bit errors, it typically does so by requesting a retransmission from the transmitter, a process known as backward error correction. Many modern DLL protocols simply discard errored frames, which requires the upper layers (typically the Transport Layer) to resolve the loss.
- Addressing: If the underlying Physical Layer is a point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) circuit, then the DLL must also define an addressing structure to ensure that the correct system reads and copies the data. If present, the address is typically carried in the frame header.
- Access control: Again, if the underlying Physical Layer is a point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) circuit, the DLL must ensure orderly access to the medium to prevent systems from colliding with one another on the circuit. Medium access control (MAC) schemes were commonly found in local area networks, most of which were originally broadcast in nature.
- Link establishment and termination: Some DLL protocols operate on the connectionless communication model, while other operate on a connection-oriented communication model. If the DLL is connection-oriented, then it must define procedures for establishing and terminating the DLL connection between devices. In most cases, once the DLL connection is established between two systems, it is usually not terminated as long as the network is operational. Although less common today, this model is still present for such things as dial-access to the Internet.
- Flow control: The DLL may also implement flow control mechanisms. Although typically associated with connection-oriented DLLs, there are some connectionless DLLs (e.g., some version of Ethernet) that also define flow control mechanisms.
Some modern DLL protocols also define a switching function, which was not anticipated by the OSI Reference Model.
Common DLL protocols include: Ethernet, LAPF (frame relay), ATM, PPP, LAPD, and DOCSIS. There are also DLL protocols in wireless environments (e.g., Wi-Fi, WiMAX)). Older, more obsolete DLL protocols include SDLC, LAPB, Token Ring, and LocalTalk, to name a few.
Protocol Control Information
The sending and receiving DLL stations use control information to ensure that only “correct” information is passed to higher layers. The sending station adds control information to the beginning and end of the data (most DLL protocols function in this manner), and then sends the frame to the Physical Layer. The receiving station uses the control information to ensure that the frame has been received correctly.
Header information typically includes the receiving station’s address and control information. An error detecting code is normally included in the Trailer field.
In most modern data link protocols the trailer is used for error detection only. Earlier the field was used in conjunction with the header to perform error correction after errors were detected. With today’s digital transmission systems errors are infrequent, as a consequence the error correction capability of the DLL has been eliminated in newer protocols. Elimination increases the protocol efficiency by allowing the receiver to treat each frame as an independent entity.
Data Link Layer Services
The basic services of a DLL protocol are defined below:
1. Framing and Frame Synchronization
The DLL is responsible for providing synchronization at the frame level, that is, determining the beginning and end of each frame. The Physical Layer is typically responsible for maintaining bit synchronization. How this is accomplished differs from one DLL to another. Some protocols (e.g., Ethernet, Wi-Fi) require the Physical Layer to go inactive for a minimum period between frames. This means each frame must begin with starting delimiter that will provide the receiver with a window during which it can resynchronize it's Physical Layer clock and prepare to receive a new frame.
Other protocols, (e.g., PPP, frame relay, HDLC, LAPD) keep a continuous stream of bits on the medium. When there is no actual frame to be transmitted, the continuously transmit a sequence known as the flag pattern: 01111110. When this repetitious pattern is interrupted, the receiver knows it is witnessing the beginning of a new frame. To avoid confusion, the transmitter must ensure this pattern does not occur within the frame itself. It achieves this using a simple technique known as bit stuffing.
Still other protocols (e.g. ATM) achieve synchronization by placing a continuous stream of fixed-length frames, called cells, on the medium. The header for these cells contains an error detection code for the header only. The receiver scans the incoming bit stream looking for an error check code that consistently evaluates correctly, at which point it has "lock on" to the header of the cells and knows how to extract each cell. Cells that have no payload are given a special address to distinguish them from cells that have a valid payload.
2. Data Delimiting
The DLL adds control information to the transmitted frame. The receiving station must be able to distinguish the header and trailer from the payload. There are essentially two strategies for doing so.
Some DLL protocols (e.g., frame relay) fix the length of the header and trailer. If these fields never vary in length, and the receiver can synchronize on the frame itself, then identifying the payload within the frame is trivial.
Some DLL protocols either have varying length headers, or define optional fields. For such protocols, there must be explicit information in the header or trailer indicating where the valid payload resides. For example, the header may include a header length field and a payload length field. Or the header may have a fixed number of basic fields, and then optional fields, each of which contains a "last option" indicator. This indicator would be set (e.g., turned on) only in the last option in the header, effectively marking the end of the DLL header.
3. Error Detection and Correction
Error detection is a primary service provided by the DLL. Using an error detecting or correcting code, the DLL protocol ensures that frames with errors are recognized and not delivered to higher layers. Error detection is the DLL’s primary reason for existence. Within the scope of error detection are two general categories: A DLL must be able to detect bit errors within a frame; and the DLL must be able to determine if all transmitted frames have arrived.
To determine that all of the delivered bits are correct, an error detecting code is transmitted in a control field. This code (usually a CRC is computed from the data by both transmitter and receiver. If the receiver’s calculation matches what the transmitter sent, the bits are assumed correct.
If the DLL provides and error correction function, then it typically also defines sequence numbers to ensure that it can detect if all frames have arrived and are in the correct order. If Frame 6 arrives before Frame 5, for example, at least the receiver knows that Frame 5 is required. It is left to the individual protocols to specify if out-of-sequence frames are accepted or rejected.
Sequence numbering alone cannot detect the fact that an isolated frame failed to arrive. Thus, where guaranteed delivery is an important issue, transmitter timers are also employed. The transmitter gives the receiver N time units to acknowledge receipt. If the receiver fails to respond in the allotted time, the transmitter re-sends the frame or polls the receiver for an indication of its status.
Backward Error Correction
In computer-to-computer communication, a protocol can opt for forward or backward error correction. Backward error correction (i.e., detect-retransmit) is the simplest and most common approach. The transmitter sends the data along with a calculated error-detecting code capable of detecting the presence of bit errors. The receiver uses the code to check the received data bits. If an error is detected, the receiver ignores the frame and waits for (or asks) the transmitter to send it again.
Various error-detecting codes have been developed, each with their own strengths and weaknesses. Strengths are usually expressed in terms of the kinds of errors detected (e.g., single bit, multiple bits). Weaknesses relate to the complexity of the computation and the number of bits that must be sent to perform the detection.
Forward Error Correction
Forward error correction codes contain sufficient information to not only detect the presence of bit errors, but to enable the receiver to determine which bits need correcting. As expected, the number of code bits required to correct an error is substantially greater than the number to simply detect an error. Due to the high overhead, forward error correction is reserved for extremely noisy channels (i.e., where there is a large probability that the retransmitted frame will contain errors). It is also used for channels with inordinately long propagation delays (e.g., frames from a solar system explorer), or those having no reverse path (i.e., a submarine under radio silence).
Since the vast majority of physical media do not suffer from high error rates, long propagation delay, or simplex service, detect-retransmit is the choice for most Data Link Layers.
Addressing is used to determine the destination for the frames. Two types of addressing are commonly found at the data link. The first is a hardware address that uniquely identifies each station. The second is a virtual circuit identifier, these identify the path to the destination.
DLL protocols operate over both point-to-point and multipoint physical links. Many DLL protocols, such as IBM’s Synchronous Data Link Control (SDLC), provide for multipoint configurations in which one station, called the primary, is in charge of the link. In such a configuration, an address is required to ensure message delivery to the correct secondary station. An address may also be contained in frames to the primary, so the primary can determine the sender. The addresses shown on the accompanying visual should not be confused with network address; network addressing is a separate issue. Station addresses A, B, and C are local to the Data Link Layer.
In LAN settings, all stations are generally considered peers (i.e., there is no primary/secondary distinction). Since any station can transmit to any other, the Address field of a frame must contain both destination and source addresses.
5. Line Access Control
Line control determines which station can transmit next. This commonly used in a local area network for access to the shared medium.
Line access control is determined by the type of physical circuit connecting the stations and the number of stations connected.
Links can be full duplex or half duplex. Full duplex links (i.e., two-way simultaneous) allow two communication stations to transmit at will, whereas on a half duplex link (i.e., two-way alternate), the stations must take turns. However, some protocols (e.g., BISYNC) force two-way alternate communication even on a full duplex link.
Three link configurations are possible: P2P, P2MP, MP2MP. The latter is also known as a broadcast circuit.
P2P Access Control
Access control is only needed in a P2P configuration if it is half duplex. In such an environment, a mechanism for turning the line around must be defined. This is fairly rare in modern P2P circuits.
P2MP Access Control
In a P2MP configuration, one station (the point) is typically designated the “primary,” the others (the MP) are considered the “secondaries.” The primary station controls the behavior of the secondary stations. The primary can talk to any secondary, but the secondary stations can only talk to the primary. The primary arbitrates access to the circuit. In this environment, addressing is also typically defined.
MP2MP Access Control
Typically found in broadcast LAN environments, this schemes are typically referred to as MAC schemes. In the wired LAN world, two models have predominated: token passing and contention.
Token Ring, Fiber Distributed Data Interface (FDDI), and token bus LANs use variations of the distributed polling technique called token passing. Unlike those environments where a single device (or primary station) grants permission to all other devices (secondary stations) allowing them to send their data, token passing systems take turns using the shared link without one central controlling station. Each station holds peer status with others on the same link—there is no primary/secondary designation. A station wishing to transmit waits until an electronic “token” is passed to it by one of its peers. After sending its data (or after an established maximum time) the token is passed to another station on the link. This orderly passing of the token allows each station an opportunity to transmit, but no one station dominates the others as in primary/secondary environments. These technologies have become largely obsolete and with it this form of access control.
As the name implies, contention-based methods find stations contending for a common broadcast link. When a station needs to transmit, it checks first to see if the link is already in use by another station by simply “listening” to (or sensing carrier on) the link—a technique called Carrier Sense Multiple Access (CSMA). If the link is in use, the station defers its transmission so as not to cause a “collision,” thereby corrupting both its own and the other stations data stream. If the link is idle, the station transmits its data. However, should two or more stations begin transmitting at roughly the same time, a collision will result. collision detection (CD) and collision avoidance (CA) try to minimize wasted time and link throughput resulting from such collisions. Both Ethernet and Wi-Fi use contention-based methods.
6. Connection Setup and Release
If the DLL in question operates on a connection-oriented model, once all physical connections are in place and the equipment is running, the DLL must be activated. Similarly, there must be a mechanism to deactivate a link.
Stations that sequence data frames to ensure sequential delivery must have a known starting point for these sequence numbers. Stations must also agree on a sequencing modulus. One station initiates the logical connection by sending a defined Start command to the intended recipient. The format for this command and which station(s) may send it are defined by the specific protocol. Typically, a connection acknowledgment is returned by the other station before the transfer of data begins. The start-up process can also clear error conditions and restart the DLL protocol.
While not often used, DLL protocols also have a defined “stop” frame. The command causes a software halt rather than a hardware stop.
Connectionless DLL protocols do not engage in any of these activities. They simply send frames whenever there is a frame to be sent. Most of these do not define an error correction mechanism.
7. Flow Control
There are times when a transmitter can overwhelm a receiver. This can happen in either a connectionless or connection-oriented DLL protocol. Many DLL protocols define a mechanism by which the receiver can limit transmissions from the transmitter. If the DLL is connection-oriented, this is typically achieved by explicitly sending the transmitter a Receiver Not Ready (RNR) frame as part of the normal exchange. The transmitter is required to withhold all further transmissions until it receives a Receiver Ready (RR) frame from the receiver. This capability is part of PPP, HDLC, SDLC, LAPB, and LAPD, to name a few.
In connectionless environments, if a flow control function is required, it is typically accomplished by defining a special "pause" frame. The receiver sends it on the link to the transmitter, which is required to cease all transmissions until it receives a new frame releasing it from the pause condition. This strategy is defined for Ethernet.
Some DLLs do not define a flow control mechanism at all (e.g., frame relay).
Switching in the Data Link Layer
The OSI Reference model never anticipated this development in the DLL. It was the Network Layer that was supposed to (and does) provide a packet switching function. But the early 1990s saw the introduction of at least three DLL environments in which frame switching was defined at the DLL: Ethernet, frame relay, and ATM. There were also switched Token Ring and FDDI environments, but these are now considered obsolete technologies and are fading from the industry.
|| Data Link Layer|
|| OSI Reference Model|