Aside: The IETF 9 and TCPIP Standards

Aside: The IETF^[9] and TCP/IP Standards

^[9] IETF stands for Internet Engineering Task Force.

Before exploring the Data Link layer in more detail, this is a good time to mention the other major protocol suite (which has effectively supplanted the OSI protocol suite); namely, the TCP/IP family of protocols.

The IETF was a completely different type of standards organization, which placed "rough consensus and running code" ahead of excessive formality. The IETF grew out of networking research efforts funded by the United States Defense Advanced Research Projects Agency (DARPA, occasionally known as ARPA). The Transmission Control Protocol/Internet Protocol (TCP/IP) protocol stack emerged in the early 1980s.^[10]

^[10] Specifically, the Internet (well, it was the ARPANET at the time) cut over to use TCP/IP instead of the original packet-switching protocol NCP on January 1, 1983.

TCP/IP was not based on the OSI model (in fact, the designers of TCP/IP had significant philosophical differences with the way that de jure networking standards were created at the time; e.g., by the CCITT and ISO. The TCP/IP "reference model" actually only has four layers, namely Subnetwork (maps roughly to the OSI Physical and Data Link layers), IP (maps closely to the OSI Network layer), Transport (maps roughly to the Transport and Session layers of the OSI stack), and Application (maps roughly to the Session, Presentation, and Application layers of the OSI stack).

Although TCP/IP was developed in an ad-hoc fashion by an international team of engineers, and was eventually adopted by users on every continent, it was not an international standard in the traditional sense of the word. However, it was nonproprietary and many vendors supported it (partially because it was free^[11] ), making it a de facto standard, which evolved over time into a real international standard, perhaps eventually becoming a victim of its own success.^[12] Because of the near-universal deployment of the TCP/IP suite, and the fact that the IETF has achieved the necessary international-level recognition from the "official" standards community, the IETF's standards process can legitimately be said to produce de jure, not de facto protocols.

^[11] Much of TCP/IP's early success can be attributed to the fact that it was freely included with BSD UNIX^® distributions in the 1980s. Once implementations of the OSI protocols became available, they were typically expensive, and by the time they came to market, many early adopters were already familiar with TCP/IP. Many organizations that were forced by policy to acquire OSI software opted to keep their OSI software safe inside its shrink-wrap rather than learn something new.

^[12] The IETF "process" is becoming more and more well-defined, which is both good and bad (in the author's opinion). There was always a degree of brazenness about the IETF process, such as it was. The IETF motto was "rough consensus and running code." Their standards were written, implemented, tested, and improved, in a very informal, yet very productive fashion. IETF folks eschewed the formal standards organizations as ossified relics, and ridiculed their output as excessively complex and not grounded in real-world implementation experience. No standard took more abuse than the OSI suite of protocols. The early 21^st-century IETF is a very different beast, with progressively more well-defined processes and the intrusion of terms like "normative references" into their specifications. At this point, the IETF has taken its place alongside the "real" standards bodies like the IEEE, ANSI, and ITU-T.

Referring back to the concept of a connection, TCP/IP restricts its notion of a connection to its Transport layer, although modern technologies like Multi-Protocol Label Switching (MPLS) are adding lightweight connection-oriented features just below the Network layer (i.e., the IP layer in the TCP/IP "reference model").

Because of its flexible design, TCP/IP was, and is, readily adaptable to run over any lower-layer technology, as one can see by looking at how many types of "IP over foo" standards there are in the IETF's RFC library. More information about the IETF can be found at their Web site, www.ietf.org.

IPv4 and IPv6 Encapsulation in IEEE 802 LANs

The IEEE has standardized the LAN technologies over which IP operates, with the notable exception of Ethernet, which pre-dated the inception of the IEEE's Project 802 (the LAN/MAN Standards Committee, or LMSC), the group that was created to standardize LAN technology within the OSI-RM context.

Each LAN technology is given a name according to the working group within the LMSC that has been chartered to develop that standard. For example, the IEEE 802.11 working group is creating standards for wireless LANs. In the next section, the structure of the IEEE LMSC will be described in more detail. For now, suffice it to observe that the IEEE LMSC divided the Data Link layer into medium-specific and medium-independent sub-layers.

The medium-independent sub-layer is known as the Logical Link Control (LLC) sub-layer, and is defined by IEEE 802.2. There are two layered protocols in the LLC sub-layer, one which is called LLC, and is required to be present over all the MAC sub-layer protocols that the IEEE has defined, and the other which is called "SNAP" and is optionally available over LLC when carrying certain higher-layer protocols, in particular IPv4, ARP, and IPv6.

The LLC sub-layer protocol uses the concept of a Service Access Point, which is just a number that identifies what sort of payload is within the payload that follows the LLC sub-layer protocol header. If SNAP is in use, the LLC SAP is set to 0xAA.

Although a unique IEEE 802.2 LLC SAP value was assigned to IPv4, IPv4 is rarely (if ever) seen transmitted over IEEE 802.2 LLC alone the recommended practice for transmitting IPv4 and ARP over IEEE 802 LANs is to encapsulate them in both IEEE 802.2 LLC and IEEE 802.2 SNAP. While it is technically possible to transmit "IPv4 over 'raw' IEEE 802.2 LLC" packets on FDDI or Token Ring LANs, that practice violates RFC-1042, which has been a full Internet Standard for a very long time. However, other protocols such as IPX, NetBEUI, and OSI Connection-Less Network layer Protocol (CLNP), among others, may be layered directly over IEEE 802.2 LLC sub-layer protocol without requiring the presence of the IEEE 802.2 SNAP sub-layer protocol.

Finally, note that there is no IEEE 802.2 LLC SAP value for IPv6, which also must be encapsulated over non-Ethernet (i.e., IEEE 802) LANs in both IEEE 802.2 LLC and IEEE 802.2 SNAP headers (although to differentiate itself from IPv4, IPv6 uses a Type value of 0x86DD, compared to IPv4's Type value of 0x0800).

Figure 2-5 illustrates the common protocol stack used when TCP/IP packets are transported over any IEEE 802 LAN medium. As indicated in the diagram, both IPv4 and IPv6 share the same basic encapsulation. The MAC sub-layer protocol for IEEE 802.11 is highlighted.

Figure 2-5. TCP/IP layering over various IEEE 802 media

When IPv4 or IPv6 is encapsulated in IEEE 802.3 Ethernet (with the "Length" as opposed to "Type" interpretation of the frame), the protocol stack using the LLC sub-layer is used. However, if the original "Type" form of Ethernet is used, the IP header can be layered directly over Ethernet with no intervening IEEE 802.2 LLC sub-layer protocol(s). Figure 2-5 shows both possibilities, only in the case of IEEE 802.3/Ethernet.

The presence of a "Type" field in the original Ethernet header is the main thing that distinguishes it from the protocols that were subsequently developed by the IEEE LMSC, since all of those subsequent protocols rely on the LLC sub-layer protocol (and possibly the SNAP sub-layer protocol) to identify the contents of the frame.