OSI Layer 2, the data link layer, defines the standards and protocols used to control the transmission of data across a physical network. If you think of Layer 1 as “sending bits,” you can think of Layer 2 as meaning “knowing when to send the bits, noticing when errors occurred when sending bits, and identifying the computer that needs to get the bits.” Similar to the section about the physical layer, this short section describes the basic data link layer functions. Later, you will read about the specific standards and protocols for Ethernet. Data link protocols perform many functions, with a variety of implementation details. Because each data link protocol “controls” a particular type of physical layer network, the details of how a data link protocol works must include some consideration of the physical network. However, regardless of the type of physical network, most data link protocols perform the following functions: Arbitration—Determines when it is appropriate to use the physical medium Addressing—Ensures that the correct recipient(s) receives and processes the data that is sent Error detection—Determines whether the data made the trip across the physical medium successfully Identification of the encapsulated data—Determines the type of header that follows the data link header:-
Data Link Function 1: Arbitration Imagine trying to get through an intersection in your car when all the traffic signals are out— you all want to use the intersection, but you had better use it one at a time. You finally get through the intersection based on a lot of variables—on how tentative you are, how big the other cars are, how new or old your car is, and how much you value your own life! Regardless, you cannot allow cars from every direction to enter the intersection at the same time without having some potentially serious collisions. With some types of physical networks, data frames can collide if devices can send any time they want. When frames collide in a LAN, the data in each frame is corrupted and the LAN is unusable for a brief moment—not too different from a car crash in the middle of an intersection. The specifications for these data-link protocols define how to arbitrate the use of the physical medium to avoid collisions, or at least to recover from the collisions when they occur. Ethernet uses the carrier sense multiple access with collision detection (CSMA/CD) algorithm for arbitration. The CSMA/CD algorithm is covered in the upcoming section on Ethernet.
Data Link Function 2: Addressing When I sit and have lunch with my friend Gary, and just Gary, he knows I am talking to him. I don’t need to start every sentence by saying “Hey, Gary….” Now imagine that a few other people join us for lunch—I might need to say something like “Hey, Gary…” before saying something so that Gary knows I’m talking to him. Data-link protocols define addresses for the same reasons. Many physical networks allow more than two devices attached to the same physical network. So, data-link protocols define addresses to make sure that the correct device listens and receives the data that is sent. By putting the correct address in the data-link header, the sender of the frame can be relatively sure that the correct receiver will get the data. It’s just like sitting at the lunch table and having to say “Hey Gary…” before talking to Gary so that he knows you are talking to him and not someone else. Each data-link protocol defines its own unique addressing structure. For instance, Ethernet uses Media Access Control (MAC) addresses, which are 6 bytes long and are represented as a 12-digit hexadecimal number. Frame Relay typically uses a 10-bit-long address called a data-link connection identifier (DLCI)—notice that the name even includes the phrase data link. This post covers the details of Ethernet addressing. You will learn about Frame Relay addressing in the CCNA ICND Exam Certification Guide.
Data Link Function 3: Error Detection Error detection discovers whether bit errors occurred during the transmission of the frame. To do this, most data-link protocols include a frame check sequence (FCS) or cyclical redundancy check (CRC) field in the data-link trailer. This field contains a value that is the result of a mathematical formula applied to the data in the frame. An error is detected when the receiver plugs the contents of the received frame into a mathematical formula. Both the sender and the receiver of the frame use the same calculation, with the sender putting the results of the formula in the FCS field before sending the frame. If the FCS sent by the sender matches what the receiver calculates, the frame did not have any errors during transmission. Error detection does not imply recovery; most data links, including IEEE 802.5 Token Ring and 802.3 Ethernet, do not provide error recovery. The FCS allows the receiving device to notice that errors occurred and then discard the data frame. Error recovery, which includes the resending of the data, is the responsibility of another protocol.
Data Link Function 4: Identifying the Encapsulated Data Finally, the fourth part of a data link identifies the contents of the Data field in the frame.
When PC1 receives data, should it give the data to the TCP/IP software or the NetWare client software? Of course, that depends on what is inside the Data field. If the data came from the Novell server, PC1 hands off the data to the NetWare client code. If the data comes from the web server, PC1 hands it off to the TCP/IP code. But how does PC1 make this decision? Well, IEEE Ethernet 802.2 Logical Link Control (LLC) uses a field in its header to identify the type of data in the Data field. PC1 examines that field in the received frame to decide whether the packet is an IP packet or an IPX packet.
Data Link Function 1: Arbitration Imagine trying to get through an intersection in your car when all the traffic signals are out— you all want to use the intersection, but you had better use it one at a time. You finally get through the intersection based on a lot of variables—on how tentative you are, how big the other cars are, how new or old your car is, and how much you value your own life! Regardless, you cannot allow cars from every direction to enter the intersection at the same time without having some potentially serious collisions. With some types of physical networks, data frames can collide if devices can send any time they want. When frames collide in a LAN, the data in each frame is corrupted and the LAN is unusable for a brief moment—not too different from a car crash in the middle of an intersection. The specifications for these data-link protocols define how to arbitrate the use of the physical medium to avoid collisions, or at least to recover from the collisions when they occur. Ethernet uses the carrier sense multiple access with collision detection (CSMA/CD) algorithm for arbitration. The CSMA/CD algorithm is covered in the upcoming section on Ethernet.
Data Link Function 2: Addressing When I sit and have lunch with my friend Gary, and just Gary, he knows I am talking to him. I don’t need to start every sentence by saying “Hey, Gary….” Now imagine that a few other people join us for lunch—I might need to say something like “Hey, Gary…” before saying something so that Gary knows I’m talking to him. Data-link protocols define addresses for the same reasons. Many physical networks allow more than two devices attached to the same physical network. So, data-link protocols define addresses to make sure that the correct device listens and receives the data that is sent. By putting the correct address in the data-link header, the sender of the frame can be relatively sure that the correct receiver will get the data. It’s just like sitting at the lunch table and having to say “Hey Gary…” before talking to Gary so that he knows you are talking to him and not someone else. Each data-link protocol defines its own unique addressing structure. For instance, Ethernet uses Media Access Control (MAC) addresses, which are 6 bytes long and are represented as a 12-digit hexadecimal number. Frame Relay typically uses a 10-bit-long address called a data-link connection identifier (DLCI)—notice that the name even includes the phrase data link. This post covers the details of Ethernet addressing. You will learn about Frame Relay addressing in the CCNA ICND Exam Certification Guide.
Data Link Function 3: Error Detection Error detection discovers whether bit errors occurred during the transmission of the frame. To do this, most data-link protocols include a frame check sequence (FCS) or cyclical redundancy check (CRC) field in the data-link trailer. This field contains a value that is the result of a mathematical formula applied to the data in the frame. An error is detected when the receiver plugs the contents of the received frame into a mathematical formula. Both the sender and the receiver of the frame use the same calculation, with the sender putting the results of the formula in the FCS field before sending the frame. If the FCS sent by the sender matches what the receiver calculates, the frame did not have any errors during transmission. Error detection does not imply recovery; most data links, including IEEE 802.5 Token Ring and 802.3 Ethernet, do not provide error recovery. The FCS allows the receiving device to notice that errors occurred and then discard the data frame. Error recovery, which includes the resending of the data, is the responsibility of another protocol.
Data Link Function 4: Identifying the Encapsulated Data Finally, the fourth part of a data link identifies the contents of the Data field in the frame.
When PC1 receives data, should it give the data to the TCP/IP software or the NetWare client software? Of course, that depends on what is inside the Data field. If the data came from the Novell server, PC1 hands off the data to the NetWare client code. If the data comes from the web server, PC1 hands it off to the TCP/IP code. But how does PC1 make this decision? Well, IEEE Ethernet 802.2 Logical Link Control (LLC) uses a field in its header to identify the type of data in the Data field. PC1 examines that field in the received frame to decide whether the packet is an IP packet or an IPX packet.