IEEE’s Version of Ethernet

There are actually two variants of Ethernet: IEEE’s implementation and the DIX implementation. Ethernet was developed by three different companies in the early 1980s: Digital, Intel, and Xerox, or DIX for short. This implementation of Ethernet has evolved over time; its current version is called Ethernet II. Devices running TCP/IP typically use the Ethernet II implementation.

The second version of Ethernet was developed by IEEE and is standardized in the IEEE 802.2 and 802.3 standards. IEEE has split the data link layer into two components: MAC and LLC. These components are
described in Table 2-5. The top part of the data link layer is the LLC, and its function is performed in software. The bottom part of the data link layer is the MAC, and its function is performed in hardware.

The LLC performs its multiplexing by using Service Access Point (SAP) identifiers. When a network layer protocol is encapsulated in the 802.2 frame, the protocol of the network data is placed in the SAP field. When the destination receives the frame, it examines the SAP field to determine which upper-layer network layer protocol should process the frame. This allows the destination network device to differentiate between TCP/IP and IPX network layer protocols that are being transmitted across the data link layer connection. Optionally, LLC can provide sequencing and flow control to provide a reliable service, as TCP does at the transport layer. However, most data link layer implementations of Ethernet don’t use this function—if a reliable connection is needed, it is provided by either the transport or application layer.

IEEE 802.3
As mentioned earlier, IEEE 802.3 is responsible for defining the framing used to transmit information between two NICs. A frame standardizes the fields in the frame and their lengths so that every device understands how to read the contents of the frame. The top part of Figure 2-3 shows the fields of an 802.3 frame.

Table 2-6 shows the fields found in the 802.3 frame. The field checksum sequence (FCS) value is used to ensure that when the destination receives the frame, it can verify that the frame was received intact. When generating the FCS value, which is basically a checksum, the NIC takes all of the fields in the 802.3 frame, except the FCS field, and runs them through an algorithm that generates a four-byte result, which is placed in the FCS field.

When the destination receives the frame, it takes the same fields and runs them through the same algorithm. The destination then compares its four-byte output with what was included in the frame by the source NIC. If the two values don’t match, then the frame is considered bad and is dropped. If the two values match, then the frame is considered good and is processed further.

IEEE 802.2
IEEE 802.2 (LLC) handles the top part of the data link layer. There are two types of IEEE 802.2 frames: Service Access Point (SAP) and Subnetwork Access Protocol (SNAP). These 802.2 frames are encapsulated (enclosed) in an 802.3 frame when being sent to a destination. Where 802.3 is used as a transport to get the 802.2 frames to other devices, 802.2 is used to define which network layer protocol created the data that the 802.2 frame will include. In this sense, it serves as a multiplexing function: it differentiates between TCP/IP, IPX, AppleTalk, and other network-layer data types. Figure 2-4 shows the two types of 802.2 frames.

Table 2-7 lists the fields found in an 802.2 SAP frame.

When a destination NIC receives an 802.3 frame, the NIC first checks the FCS to verify that the frame is valid and then checks the destination MAC address in the 802.3 frame to make sure that it should process the frame (or ignore it). The MAC sublayer strips off the 802.3 frame portion and passes the 802.2 frame to the LLC sublayer. The LLC examines the destination SAP value to determine which upper-layer protocol should have the encapsulated data passed to it. Here are some examples of SAP values: IP uses 0x06 (hexadecimal) and IPX uses 0x0E. If the LLC sees 0x06 in the SAP field, it passes the encapsulated data up to the TCP/IP protocol stack running on the device.

The second frame type supported by 802.2 is SNAP, which is shown in the bottom portion of Figure 2-4. As you can see from this frame, there is one additional field: type. Table 2-8 explains the 802.2 SNAP fields.

One of the issues of the original SAP field in the 802.2 SAP frame is that even though it is eight bits (one byte) in length, only the first six bits are used for identifying upper-layer protocols, which allows up to 64 protocols. Back in the 1980s, there were many more protocols than 64, plus there was an expectation that more protocols would be created. SNAP overcomes this limitation without having to change the length of the SAP field.

To indicate a SNAP frame, the SAP fields are set to hexadecimal 0xAA, the control field is set to 0x03, and the OUI field is set to 0x0. The type field identifies the upper-layer protocol that is encapsulated in the payload of the 802.2 frame. Since a SAP frame can identify only 64 protocols, the type field was made two bytes in length, which theoretically allows the support of up to 65,536 protocols! AppleTalk is an example of a protocol that uses an 802.2 SNAP frame.

Note that concerning 802.2 there are other data link layer protocols for the LAN besides Ethernet, including Token Ring and FDDI. IEEE’s 802.2 standard supports these sublayer standards at the MAC layer. Token Ring is specified in IEEE’s 802.5 standard, and FDDI is specified in an ANSI standard. This book only focuses on Ethernet.