Ethernet History Deepdive – Why Do We Have Different Frame Types?

In my previous post Encapsulation of PDUs On Trunk Ports, I showed what happens to PDUs when you change the configuration of a trunk. You may have noticed that there are typically three different types of Ethernet encapsulations that we see:

• Ethernet II.
• 802.2 LLC.
• 802 SNAP.

Historically, there were even more than three, but we’re ignoring that for now. Why do we have three? To understand this, we need to go back in history.

The Origin of Ethernet

In the early 70’s, Robert Metcalfe, inspired by ARPANET and ALOHAnet had been working on developing what we today know as Ethernet. He published a paper in 1976, together with David Boggs, named Ethernet: Distributed Packet Switching for Local Computer Networks:

In the paper, they describe the addressing used in Ethernet:

3.3 Addressing
Each packet has a source and destination, both of which are identified in the packet’s header.
A packet placed on the Ether eventually propagates to all stations. Any station can copy a packet
from the Ether into its local memory, but normally only an active destination station matching ‘its
address in the packet’s header will do so as the packet passes. By convention, a zero destination
address is a wildcard and matches all addresses; a packet with a destination of zero is called a
broadcast packet.

Interestingly, a packet with a destination of zero is a broadcast. Broadcasts use all ones now as you know.

There is then also an image showing what the packet looks like:

There are many similarities to the Ethernet II header, but notice that the destination and source address were only 8 bits at the time! This makes sense when you consider that Ethernet was originally designed to connect Xerox Altos, the first personal computer:

The Alto had a 8-bit serial number, and because the expectation was that there wouldn’t be more than 255 Altos, it was enough to have 8 bits for addressing.

Note that while EtherType isn’t show in the packet header above, it’s described verbally in another part of the paper:

The first 16 bits of all Ethernet packets contain its interface-interpretable destination and source
station addresses, a byte each, in that order (see Figure 2). By software convention, the second ’16
bits of all Ethernet packets cOl1tain_ the packet type.’ Different protocols use disjoint sets of packet
types.

This paper was published when Robert was still at Xerox, at the Palo Alto Research Center (PARC).

The Forming of DIX Consortium

A little before project 802 had been formed, Metcalfe had co-founded 3Com. This is also when DEC, Intel, and Xerox formed the so called DIX consortium in the fall of 1979. Originally, it was Xerox that owned the trademark of Ethernet. These three companies working together in networking may seem strange today, but at the time they were all massive companies with large market share. These three companies had the engineers and products that were needed to develop Ethernet.

The Forming of Project 802

In the fall of 1979, a man named Maris Graube, working for Tektronix at the time, had initiated the process at IEEE of forming a project for standardizing LANs. The Project Authorization Request (PAR) is shown below:

They were given the number 802 (just the next number that was available) and so Project 802 with the goal of standardizing local and metropolitan area networks (LANMAN) had been formed.

The goal of P802 was to agree upon functional requirements and develop a standard for it, rather than having commercial products brought into the standards process.

It’s also important to note that the International Organization for Standardization (ISO), were working on defining the Open Systems Interconnection (OSI) reference model. Additionally, TCP/IP was also being defined by Cerf, Kahn, and the others participating in IETF standards process.

DIX Goes to IEEE

The very first meeting for Project 802 was at the Jack Tar hotel in San Francisco in February in 1980. It was in May that things got really interesting, though! In May of 1980, DIX brought Ethernet to the IEEE, intent on Ethernet becoming the de facto standard for LANs. They had been working on Ethernet for several years at this point and the other main competitor, Arcnet, weren’t going to propose their technology to IEEE. The goal of project 802 was obviously to come up with ONE standard for LANs. DIX from their point of view had the solution and probably didn’t expect much resistance. They had also via a press released promised to release Ethernet version 1 on September 30th 1980. Graube, as chair of P802, wasn’t exactly thrilled with the actions of DIX:

• Project 802 was supposed to develop a standard for LANs, based on requirements that would be agreed upon.
• They wanted to avoid companies coming in with their solutions and trying to get them passed.
• DIX claimed they already had the technology and were somewhat trying to bypass the IEEE process.
• DIX had gone to the press, announcing that Ethernet version 1 would be published on 30th of September 1980.

Trying to get a standard approved is a very political process. There are many parties involved representing different companies. What do you think happened when DIX presented Ethernet to all the other parties in the meeting? Did they give them a standing ovation? No, as always when you present a technology, people start picking it apart. Some of the objections were around:

• Probalistic vs deterministic communication.
• Bus topology.
• Performance under high loads.
• Delivery was not guaranteed.
• Collisions and error handling.

In addition to that, IBM were not interested in passing a standard that they hadn’t developed. The so called not invented here syndrome. They didn’t really have anything else at the time, but weren’t going to back something not coming out of IBM. General Motors were also not happy with Ethernet as they were representing the automotive industry, which according to them had other needs. They were representing the Token Bus camp, another token-based LAN.

P802 Split Into Three Groups

After the first few P802 meetings, it was becoming clear that they couldn’t agree on one LAN standard, a failure for 802 at the time. They decided to divide the project into subcommitees. Hence, 802 was split into:

• Physical Level.
• Link Level.
• High-Level Interface.

The Link Level (datalink in OSI terms) would consist of Medium Access Control (MAC) and Logical Link Control (LLC). The High-Level Interface is layers three and up in the OSI reference model.

The Different Camps in IEEE

After the meeting in May, IEEE continued to have meetings and there were four different camps advocating for different solutions:

• The CSMA/CD camp advocating for Ethernet, led by DIX.
• PROWAY advocates, advocating for a token technology.
• IBM, rumored to favor token ring, but unwilling to make their intentions clear.
• A chaotic camp, consisting of firms advocating for their proprietary technologies.

Ethernet Version 1

Then, on September 30th, DIX released Ethernet version 1 as promised. Phil Kaufman of Intel describes how they printed 25000 copies of it:

The result of that was, with much agony, the Blue Book, which, as I recall, was printed by Intel
on my budget, some 25,000 copies, and passed out to the world. What we tried to say was “Here it is.
We’ve signed up for it. We’re going to make this work, and if you want to put a standards stamp on it,
that’s fine.” Of course, we didn’t really take into account the fact that there were lots of other people in the
world with other axes to grind that would try to perturb the standard, and in hindsight, maybe we should
have just held it quiet for another couple of years until we were delivering, but we took it to the IEEE and
a lot of people spent a lot of money. In parallel with that, we tried to get other companies to buy in.

In this paper, they mention that the goal is to support ISO higher layers:

The header has changed significantly since the paper in 1976:

Ironically, this version of the header published in 1980 is what we still use to this day. The main changes from the paper in 1976 are:

• The destination and source address is now 6 octets (48 bits) as opposed to 8 bits.
• The concept of multicast by setting a bit to one in the destination address.
• Broadcast is now all ones instead of all zeroes.
• Data is 46-1500 octets. Previously, it wasn’t well defined what the maximum size was.
• The FCS is 4 octets (32 bits) instead of 16 bits.

The header is 18 octets, meaning the minimum size frame is 64 octets, and maximum size frame is 1518 octets, which is exactly what is being used today.

Token Proponents Try to Sink CSMA/CD

DIX had released Ethernet version 1 to the public while the work in IEEE was still ongoing. There was a meeting to be held in December 1980, where there was going to be a vote on CSMA/CD (Ethernet) vs token passing technology. There were large companies, such as IBM, determined to sink CSMA/CD at this meeting. From DIX’s point of view, they were going to go forward with Ethernet, regardless of the outcome of IEEE. However, when voting for the two technologies, token passing couldn’t get the two thirds of votes as needed, and neither could Ethernet! Instead, it was decided that there would be two additional subcommittees, for a total of five, where both CSMA/CD and tokens had their own committee:

LAN Status Report from 1981

It’s difficult to find all the details of what went on during these years, but there is an interesting status report from 1981 by G.J. Clancy, Jr., and T.J. Harrison:

In this status report, the goals of the Data Link and Media Access Control (DLMAC) working group are listed as:

• HDLC Convergence – HDLC is widely understood and implemented so HDLC should be used if appropriate to do so.
• Topological Independence – Support topologies such as bus, ring, tree, and star.
• Transmission Rate Independence – The data link layer should not be affected by different transmission rates.
• Media Independence – Ability to use different media such as coaxial, fiber, and twisted pair, without affecting data link layer.
• Encoding Technique Independence – Different transmission rates require different encoding, this shouldn’t affect data link layer.

The report also says:

In its earlier versions, the proposal recognized the need to interconnect with other networks by providing a “multi link” sublayer at the top of Layer two which provided for the existence of unique interfaces and protocols into the network layer of existing or future networks. At its most recent meeting, the subcommittee further refined and detailed this requirement by providing a mechanism for multiple Service Access Points (SAPs) at the interface between the Link and Network layers. The SAPs provide for multiple connections, identified by unique addresses, as might be required to accomodate multiple “sessions” in the sense of the OSI model.

The concept of SAPs is something that came out of the OSI reference model.

It was the division of data link into MAC and LLC that was going to allow the MAC layer to be transparent to the upper layers. It would also allow interconnectivity between different LANs data link layers. The diagram below shows how different MAC layers can work with different upper layers:

The intent here was to have all the protocols coming through 802, such as 802.3, 802.4, and 802.5, use LLC as the layer towards upper layers, allowing for different MAC layers.

IEEE P802 Drafts and ECMA

In 1981, P802 created a number of drafts for a LAN standard. The first draft, Draft A was released in May 1981 and Draft B in October. However, calling it a standard was a stretch as these initial drafts had both CSMA/CD and token mechanisms. In fact, rather than telling the readers what to do, which is usually what a standard does, they were telling you what you could do. Do you want baseband or broadband signaling? Do you want coax, fiber, or copper? Do you want CSMA/CD or token passing? There was still a lot of work to be done before this could be passed as a standard.

The CSMA/CD camp, led by DIX, were getting frustrated by the lack of progress in the IEEE standardization process. To try to push things forward, they turned to European Computer Manufacturers Association (ECMA) which had been successful in the work of standardizing OSI protocols. In November of 1981, ECMA created technical group TG LN under Technical Committee 24 to develop LAN standards.

ECMA, working with Xerox, DEC, Siemens, and Olivetti, created a CSMA/CD draft that was closer to what was published in DIX “Blue Book” than the CSMA/CD proposal coming from 802. Additionally, 24 companies had made public their intention to introduce Ethernet products.

When 802 met in March of 1982, it was decided that they would align with ECMA’s proposal, which was the opposite of what had been decided the month before.

ECMA Ratifies a LAN Standard

In June of 1982, ECMA ratified a LAN standard that was very close to the initial proposal from DIX. In July, 19 companies announced public support for the ECMA CSMA/CD standard. Additionally, press also reported on Ethernet semiconductor chip announcements. The picture below shows a version of the ECMA standard from September 1982:

Note that the ECMA version did use LLC, rather than EtherType:

P802 Fragments Further

Ironically, once the camps supporting token passing couldn’t sink CSMA/CD, they started to fraction further into two camps:

• Token bus.
• Token ring.

In August of 1982, P802 was fragmented further into three distinct subcommittees:

• 802.3 – CSMA/CD.
• 802.4 – Token bus.
• 802.5 – Token ring.

The intention was to use 802.2 Logical Link Control for all of them according to this structure where 802.1 is overseeing the entire architecture and direction:

DIX Ethernet II

In November 1982, DIX released version 2 of Ethernet:

This document had been reworked from 1980 based on the work in the IEEE and ECMA. In the preface of this document, there is some interesting information. They mention differences from v1:

Version 2.0 of the Ethernet specification reflects the experience of the three corporations in designing equipment to the Version 1.0 specification. Version 2.0 includes network management functions and better defines the details of the physical channel signaling. Version 2.0 is upward compatible with Version 1.0. Equipment designed to the two specifications is interoperable.

On the compatibility with IEEE and ECMA:

Version 2.0 of the Ethernet specification is substantially compatible with standards for CSMA/CD local area networks being developed by IEEE and ECMA. The three corporations have been active participants in these standard efforts and have now endorsed their documents. Version 2.0 of the Ethernet specification is an interim document. We expect that future work will take place in these standards bodies.

The physical- and data link layers are described as:

Interestingly, DIX stuck with their original header as opposed to using LLC as IEEE and ECMA intended:

The outcome of all of the work from P802 was basically:

• Ethernet switched from DIX physical interface specs to 802.3.
• While the Ethernet II header was more common, there were also some systems using 802.3 framing.
• To separate between the two, Ethernet II uses only EtherType values that have a value of 1536 or greater (0x600).

The Ethernet II header is shown below:

What about the other two frame types I mentioned initally?

802.2 LLC

As I mentioned previously, the intention with 802.2 LLC was to have it be a layer above the MAC layer, to make the MAC layer transparent to upper layers and also to facilitate for interconnections between different LANs data link layers. I also mentioned that LLC was inspired by HDLC.

802.2 LLC was originally published in 1985 (IEEE 802.2-1985):

The standard initially deals with 802.3, 802.4, and 802.5:

This family of standards deals with the physical and data link layers as defined by the ISO Open System Interconnection Reference Model. The access standards define three types of medium access technologies and associated physical media, each appropriate for particular applications or system objectives. The standards defining these technologies are
(1) ANSI/IEEE Std 802.3-1985 (ISO DIS 8802/3), a bus utilizing CSMA/CD as the access method
(2) ANSI/IEEE Std 802.4-1985 (ISO DIS 8802/4), a bus utilizing token passing as the access method
(3) ANSI/IEEE Std 802.5-1985,1 a ring utilizing token passing as the access method.

Let’s dive into the format of the LLC PDU.

LLC PDUs

The LLC PDU is shown below:

The following fields are in the PDU:

• DSAP – Destination SAP indicates the Destination Service Access Point.
• SSAP – Source SAP indicates the Source Service Access Point.
• Control – Designates command and response functions.
• Information – Payload from upper layers.

Notice the use of the Control field, which is the same as used in HDLC. The picture below shows a comparison of LLC to HDLC where 802.3 is used with LLC:

Compared to HDLC, the address and FCS is handled by the MAC layer. Additionally, LLC has the DSAP and SSAP that can be used to identify upper layer protocols/applications.

The use of 802.3 with LLC was what IEEE was intending to standardize on for CSMA/CD, but as you know, the Ethernet II frame is what prevailed. There’s a lot more to the DSAP that I’ll cover in a future post. For now, think of the DSAP as the equivalent of EtherType. There’s an issue with the DSAP, though.

Let’s take a closer look at the DSAP:

The DSAP consists of eight bits, but since one bit is used to indicate if it’s an individual or group DSAP, that means only seven bits remain for assignment to upper layer protocols. Additionally, all DSAPs with an address starting with a one (X1DDDDDD) are reserved by IEEE, meaning that there are actually only 6 bits that can be used to assign DSAPs, for a total of 64 (2^6) values. With EtherType being 16 bits, it allows for a theoretical maximum of 65536 values, while DSAP only has 64! Having only 64 values is not enough which leads us to 802 SNAP.

802 SNAP

Having only 64 values to assign to upper layer wasn’t going to be enough. What could be done to provide more values? An addition was made to the 802 standard, defined in 802.1. Subnetwork Access Protocol (SNAP) is defined as follows:

The reserved LLC address for use with SNAP is called the SNAP address. It is defined to be the bit pattern
(starting with the LSB) Z1010101, in which the symbol Z indicates that either value 0 or 1 can occur,
depending on the context in which the address appears (as specified in ISO/IEC 8802-2). The two possible
values have Hexadecimal Representation AA and AB.

The SNAP address identifies, at each MSAP, a single LSAP for standard, public, and private protocol usage.
To permit multiple public and private network layer protocols to coexist at one MSAP, each public or private
protocol using SNAP must employ a protocol identifier that enables SNAP to discriminate among these
protocols.

What this is telling us is that two SAPs are reserved in LLC to indicate SNAP is being used:

• AA – (10101010).
• AB – (10101011).

The SNAP extension is five octets, where three octets are used as an OUI to identify the organization, and two octets to identify the protocol. The format of the SNAP frame is shown below:

Below is an example of a PVST+ BPDU:

Frame 2: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
IEEE 802.3 Ethernet 
    Destination: 01:00:0c:cc:cc:cd
    Source: 52:54:00:04:2a:87
    Length: 50
Logical-Link Control
    DSAP: SNAP (0xaa)
    SSAP: SNAP (0xaa)
    Control field: U, func=UI (0x03)
    Organization Code: 00:00:0c (Cisco Systems, Inc)
    PID: PVSTP+ (0x010b)
Spanning Tree Protocol

Note the following:

• The frame is 64 bytes, 14 bytes of Ethernet and 50 bytes of payload.
• The length is 50 bytes, which is the payload excluding Ethernet header.
• Both DSAP and SSAP are set to 0xaa to indicate 802 SNAP frame.
• Control is set to 0x03 which is used for unnumbered frames.
• The organization code identifies the organization as Cisco.
• The protocol code identifies the protocol as PVST+.

The benefit of using 802 SNAP is that a vendor can define their own protocols associated with their OUI, as opposed to requesting an EtherType from IEEE. However, the use of SNAP is an additional eight bytes, three bytes of LLC, and five bytes of SNAP. This means that the payload is decreased by eight bytes. The 802 SNAP frame is less efficient than Ethernet II. This is not really an issue today as SNAP is mainly used for control protocols, not user data. There was a time when 802 SNAP was also used for user data, though.

Summary

The history of Ethernet is fascinating. The reason why we have three different frame types is that DIX used the Ethernet II frame that is prevalent today, while IEEE intended to use a different frame format that could be used for different MAC layers, such as token bus, token ring, FDDI, and so on. The IEEE were also inspired by HDLC, and modeled their frame header more in alignment with the OSI reference model that had the concept of SAPs. When they discovered that the number of available SAPs weren’t enough, they made an addition to the 802 standard to support SNAP frames. In networks today, Ethernet II is dominant, but some control protocols may use LLC and/or SNAP frames.