In my last article, I introduced the Open System Interconnect (OSI) reference model and discussed it's first layer; the Physical Layer. In this article I will discuss the second layer, the Data Link Layer, from a hardware perspective.
The data link layer provides functional and procedural methods of transferring data between two points. There are five general functions which the Data Link layer is responsible for. These functions are:
- Logical Link Control
- Media Access Control
- Data Framing
- Error Detection
Logical Link Control
The Logical Link Control (LLC) is usually considered a sublayer of the Data Link layer (DLL), as opposed to a function of the DLL. This LLC sublayer is primarily concerned with multiplexing protocols to be sent over Media Access Control (MAC) sublayer. The LLC does this by splitting up the data to be sent into smaller frames and adding descriptive information to these frames, called headers.
Media Access Control
Like LLC, the Media Access Control (MAC) is considered a sublayer of the DLL, as opposed to a function of the DLL. Included in this sublayer is what is known as the MAC address. The MAC address provides this sublayer with a unique identifier so that each network access point can communicate with the network. The MAC sublayer is also responsible for the actual access to the network cable, or communication medium.
If one were to simply send data out onto the network medium not much would happen. The receiver has to know how, and when, to read the data. This can happen in a number of ways and is the sole purpose of framing. In general terms, framing organizes the data to be transferred and surrounds this data with descriptive information, called headers. What, and how much, information these headers contain is determined by the protocol used on the network, like Ethernet.
The structure of a frame adhering to the Ethernet protocol is shown below in Figure 1.
Figure 1: Structure of an Ethernet frame (Courtesy: Wikipedia)
Addressing in layer 2 happens, as I mentioned earlier, with the MAC address of the MAC sublayer. It is very important not to confuse this with network or IP addressing. It can be helpful to associate the MAC address with a specific network access point and the network or IP address associated with an entire device (i.e. a computer, server, or router).
Speaking of routers, keep in mind that routers operate in layer 3, not layer 2. Switches and hubs do operate in layer two, and therefore direct data based on layer 2 addressing (MAC addresses) and are unaware of IP or network addressing. And, just so that I don't get an inbox filled with complaints ... yes I know... some routers also include layer 2 functionality. I will discuss routers with layer 2 functionality in another future article.
Error Detection and Handling
Whenever data is sent over any kind of transmission medium, there exists a chance that the data will not be received exactly as it was sent. This can be due to many factors including interference and, in the case of long transmissions, signal attenuation. So, how can a receiver know if the data received is error free? There are several methods that can be implemented to accomplish this. Some of these methods are simple and somewhat effective – others are complicated and very effective.
Parity bits are an example of an error detection protocol that is simple and, despite its limited effectiveness, its use is widespread. A parity bit, simply put, is an extra bit added to a message. There are two options for the value of this bit. Which value is chosen depends on the flavor of parity bit detection that is in use. These two flavors are even and odd parity detection. If even parity is in use, then the parity bit is set to the value ('1' or '0') to make the number of '1's in the message even. Likewise, if odd parity is in use the parity bit is set to the value needed to make the number of '1's in the message odd.
When using parity bit error detection the receiver will check all '1's in the frame, including the parity bit. The receiver will have a setting for even or odd parity; if the number of '1's in the frame does not match this setting, an error is detected. Now this is great, but as I mentioned earlier the effectiveness of this error detection method is limited. It is limited because if there is an even number of errors in the frame then the evenness or oddness of the number of '1's will be maintained and this method will fail to detect any errors – thus the need for a more rigorous error detection method.
A checksum error detection method can give us more rigor especially if used with a parity bit method. A checksum method, as its name suggests, will basically check the sum of all the '1's in a message and check that value against the checksum value added by the sender to the message. While a checksum method can provide more rigor to your error detection efforts, there are still limitations. For example, a simple checksum cannot detect an even number of errors which sum to zero, an insertion of bytes which sum to zero, or even the re-ordering of bytes in the message. While there are some more advanced implementations of the checksum method, including Fletcher's checksum method, I will discuss an even more rigorous method here.
One of the most rigorous methods of error detection is the cyclic redundancy check (CRC). What a CRC does is convert the message to a polynomial where the value of the coefficients correspond to the bits in the message and then divide that polynomial by a predetermined, or standard, polynomial called a key. The answer, more specifically the remainder part of the answer, is what is sent along with the message to the receiver. The receiver performs the same polynomial division with the same key and then checks the answer. If the answers match, then the chances are pretty good that there were no errors. I say pretty good because there are a lot of possible polynomials one could use for a key and not all polynomials provide equally good error detection. As a general rule, longer polynomials provide better error detection but the mathematics involved with this are quite complex and as with many aspects of technology there is some debate as to which implementations of this method provide the best error detection.
Lastly, I would like to point out that these error detection methods are not limited to transmissions of data over a network medium; they can be used equally well in a data storage scenario where one wants to check that the data has not been corrupted.
In my next article I will discuss layer 3 of the OSI model. I will also explain in a little more detail why routers (mostly) belong in the 3rd layer and not the 2nd. And as always, if you have any questions about this or any previous article, please do not hesitate to email me and I will do my best to answer any and all questions.
If you would like to read the other parts in this article series please go to:
- OSI Reference Model: Layer 1 Hardware
- OSI Reference Model: Layer 3 Hardware
- OSI Reference Model: Layer 4 Hardware