https://lostintransit.se/2024/08/21/ethernet-history-deepdive-why-do-we-have-different-frame-types/ Skip to content Daniels Networking Blog Networking articles by CCIE #37149/ CCDE #20160011 Menu * CCNA * CCNP * CCDP * CCIE * CCDE * About * Python 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: This image has an empty alt attribute; its file name is Ethernet_paper_1975.png 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: This image has an empty alt attribute; its file name is Ethernet_header_1975.png 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: [Xerox_Alto_mit_Rechner] 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: This image has an empty alt attribute; its file name is PAR_approval.png 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. This image has an empty alt attribute; its file name is Ethernet_v1_1980.png In this paper, they mention that the goal is to support ISO higher layers: This image has an empty alt attribute; its file name is Ethernet_v1_layers.png The header has changed significantly since the paper in 1976: This image has an empty alt attribute; its file name is Ethernet_v1_header.png 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: This image has an empty alt attribute; its file name is Dec_1980_subcommittees.png 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: This image has an empty alt attribute; its file name is Status_report_1981-1024x534.png 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: This image has an empty alt attribute; its file name is IEEE_protocols_OSI-1.png 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: This image has an empty alt attribute; its file name is ECMA_1982.png Note that the ECMA version did use LLC, rather than EtherType: This image has an empty alt attribute; its file name is ECMA_header.png 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: This image has an empty alt attribute; its file name is IEEE_working_groups.png DIX Ethernet II In November 1982, DIX released version 2 of Ethernet: This image has an empty alt attribute; its file name is Ethernet_II_paper.png 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: This image has an empty alt attribute; its file name is Ethernet_II_physical_and_link_layer-1024x563.png Interestingly, DIX stuck with their original header as opposed to using LLC as IEEE and ECMA intended: This image has an empty alt attribute; its file name is Ethernet_II_header.png 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: [Ethernet_II_header_ppt] 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): This image has an empty alt attribute; its file name is LLC_1985.png 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: This image has an empty alt attribute; its file name is LLC_PDU.png 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: This image has an empty alt attribute; its file name is LLC_compared_to_HDLC-1.png 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: This image has an empty alt attribute; its file name is LLC_DSAP.png 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: [802-SNAP-header-1024x90] 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. Ethernet History Deepdive - Why Do We Have Different Frame Types? Tagged on: 802.3 DIX Ethernet LLC SAP SNAP ddib August 21, 2024August 21, 2024 Ethernet 2 Comments * - Why Are OSPF Type 5 LSAs Flooded? * 2 thoughts on "Ethernet History Deepdive - Why Do We Have Different Frame Types?" * [ce644d8f7] Eirik Overby August 21, 2024 at 11:23 pm Permalink All this helps me better understand the mess that is old operating systems, multiple frame types (hello, Novell!), and modern switches not understanding half of it. Thank you! Reply + [772535e20] ddibPost author August 22, 2024 at 6:10 am Permalink Happy to help! Reply Leave a Reply Cancel reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment * [ ] Name * [ ] Email * [ ] Website [ ] [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] [ ] Recent Posts * Ethernet History Deepdive - Why Do We Have Different Frame Types? * Why Are OSPF Type 5 LSAs Flooded? * Some History on VLAN 1 in Cisco Switches * Encapsulation of PDUs On Trunk Ports * Adding Arista Switch to CML Archives * August 2024 * July 2024 * June 2024 * May 2024 * April 2024 * March 2024 * February 2024 * January 2024 * December 2023 * November 2023 * October 2023 * September 2023 * August 2023 * July 2023 * December 2022 * September 2022 * August 2022 * July 2022 * May 2022 * April 2022 * January 2022 * December 2021 * November 2021 * October 2021 * September 2021 * May 2021 * January 2021 * December 2020 * October 2020 * August 2020 * July 2020 * June 2020 * May 2020 * April 2020 * March 2020 * December 2019 * November 2019 * October 2019 * August 2019 * June 2019 * April 2019 * March 2019 * February 2019 * December 2018 * November 2018 * October 2018 * September 2018 * July 2018 * April 2018 * February 2018 * January 2018 * December 2017 * November 2017 * October 2017 * June 2017 * May 2017 * March 2017 * February 2017 * January 2017 * November 2016 * October 2016 * August 2016 * July 2016 * May 2016 * April 2016 * March 2016 * February 2016 * January 2016 * December 2015 * November 2015 * October 2015 * September 2015 * August 2015 * July 2015 * June 2015 * May 2015 * April 2015 * March 2015 * February 2015 * January 2015 * December 2014 * November 2014 * October 2014 * August 2014 * July 2014 * June 2014 * May 2014 * April 2014 * March 2014 * February 2014 * January 2014 * December 2013 * November 2013 * October 2013 * September 2013 * August 2013 * July 2013 * June 2013 * May 2013 * April 2013 * March 2013 * February 2013 * January 2013 * December 2012 * November 2012 * October 2012 * September 2012 * August 2012 * July 2012 * June 2012 * May 2012 * April 2012 * March 2012 * February 2012 * January 2012 * December 2011 * November 2011 * October 2011 * September 2011 * August 2011 * July 2011 * June 2011 * May 2011 * April 2011 * March 2011 * February 2011 * January 2011 * December 2010 * November 2010 * October 2010 * September 2010 * August 2010 * July 2010 Categories * AAA * Anki * Announcement * ARP * AWS * BFD * BGP * Book list * Books * Career * Catalyst * CCDE * CCDP * CCIE * CCIE links * CCNA * CCNP * Certification * Cisco * Cisco Live * Cisco VIRL * Cloud * CML * Commentary * Conferences * Convergence * DevAsc * Diagram * Dynamips * EIGRP * Ethernet * EVPN * FHRP * Fragmentation * Frame relay * GNS3 * INE * IOS-XE * IP services * IPv6 * Job related * Lab preparation * Layer 2 * Licensing * Linux * MPLS * Multicast * NAT * Netflow * Network Design * Network Simulation * Nick Russo * Notes * NX-OS * Optical * OSPF * Other * PPP * Python * QoS * Rack rental * RIP * Routing * Scripts * SD-WAN * Security * Service provider * SNMP * Spanning tree * Storage * Strategy * Switching * TCP/IP * Technology * TLS * Traceroute * Troubleshooting * UCS * Uncategorized * Useful commands * VIRL * VLAN * VXLAN * Wireless Meta * Log in * Entries feed * Comments feed * WordPress.org Copyright (c) 2024 Daniels Networking Blog. All rights reserved. Theme Spacious by ThemeGrill. Powered by: WordPress.