An understanding of the basics of the Ethernet Frame Format is crucial to any discussion of Ethernet technology.
In this document, we will discuss:
- The four different frame formats used in the Ethernet world
- The purpose of each of the fields in an Ethernet frame.
- The reasons that there are so many different versions of the Ethernet Frame Format
Ethernet, Ethernet, Ethernet, or Ethernet?!
When somebody tells me that they are running Ethernet on their network, I inevitably have to ask: “Which Ethernet?”. Currently, there are many versions of the Ethernet Frame Format in the commercial marketplace, all subtly different, and not necessarily compatible with each other.
The explanation for the many types of Ethernet Frame Formats currently on the marketplace lies in Ethernet’s history. In 1972, Work on the original version of Ethernet, Ethernet Version 1, began at the Xerox Palo Alto Research Center. Version 1 Ethernet was released in 1980 by a consortium of companies consisting of DEC, Intel, and Xerox. In the same year, the IEEE meetings on Ethernet began. In 1982, the DIX (DEC/Intel/Xerox) consortium released Version II Ethernet, and since then, it has almost completely replaced Version I in the marketplace. In 1983, Novell NetWare ’86 was released, with a proprietary frame format based on a preliminary release of the 802.3 specs. Two years later, when the final version of the 802.3 spec was released, it had been modified to include the 802.2 LLC Header, making NetWare’s proprietary format incompatible. Finally, the 802.3 SNAP format was created to address backward compatibility issues between Version 2 and 802.3 Ethernet.
As you can see, the large number of players in the Ethernet world has created a number of different choices. The bottom line is this: Either a particular driver supports a particular frame format, or it doesn’t. Typically, Novell stations can support any of the frame formats, while TCP/IP stations will support only one, although there are no hard and fast rules in Networking.
Ethernet Frame Formats
The following sections of the essay will outline the specific fields in the different types of Ethernet frames. Throughout the section, we will refer to fields by referencing their “offset” or number of bytes from the start of the frame, beginning with zero. Therefore, when we say that the destination address field is from offset zero through five, we are referring to the first six bytes of the frame.
The Preamble
Regardless of the frame type being used, the means of digital signal encoding on an Ethernet network is the same. While a discussion of Manchester Encoding is beyond the scope of this document, it is sufficient to say this: On an idle Ethernet network, there is no signal. Because each station has its own oscillating clock, the communicating stations have to have some way to “synch up” their clocks and thereby agree on how long one bit time is. The preamble facilitates this. The preamble consists of 8 bytes of alternating ones and zeros, ending in 11. A station on an Ethernet network detects the change in voltage that occurs when another station begins to transmit and uses the preamble to “lock on” to the sending station’s clock signal. Because it takes some amount of time for a station to “lock on”, it does not know how many bits of the preamble have gone by. For this reason, we say that the preamble is “lost” in the “synching up” process. No part of the preamble ever enters the adapter’s memory buffer. Once locked on, the receiving station waits for the 11 that signals that the Ethernet frame follows.
Most modern Ethernet adapters are guaranteed to achieve a signal lock within 14 bit-times.
The Different “Flavors” of Ethernet
While the preamble is common to every type of Ethernet, what follows it is certainly not. The major types of Ethernet Frame Format are:
| Frame Type | Novel calls it… | Cisco calls it… |
| IEEE 802.3 | ETHERNET_802.2 | LLC |
| Version II | ETHERNET_II | ARPA |
| IEEE 802.3 | SNAP | ETHERNET_SNAP SNAP |
| Novell Proprietary (“802.3 Raw”) | ETHERNET_802.3 | NOVELL |
As you examine the table above please note that an IEEE 802.3 frame is referred to as an 802.2 frame by Novell. The frame that Novell refers to as “802.3 Raw” or “Ethernet_802.3” is their own proprietary frame format.
Frame Format IEEE 802.3
The IEEE 802.3 Frame Format
The following is a description of the Ethernet Frame Format described in the IEEE 802.3 Specification. The 802.3 Specification defines a 14 byte Data Link Header followed by a Logical Link Control Header that is defined by the 802.2 Specification.
The Data Link Header
Offset 0-5: The Destination Address
The first six bytes of an Ethernet frame make up the Destination Address. The Destination Address specifies to which adapter the data frame is being sent. A Destination Address of all ones specifies a Broadcast Message that is read in by all receiving Ethernet adapters.
The first three bytes of the Destination Address is assigned by the IEEE to the vendor of the adapter and are specific to the vendor.
The Destination Address format is identical in all implementations of Ethernet.
Offset 6-11: The Source Address
The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card.
The Source Address format is identical in all implementations of Ethernet.
Offset 12-13: Length
Bytes 13 and 14 of an Ethernet frame contain the length of the data in the frame, not including the preamble, 32 bit CRC, DLC addresses, or the Length field itself. An Ethernet frame can be no shorter than 64 bytes total length, and no longer than 1518 bytes total length.
THE 802.2 LOGICAL LINK CONTROL (LLC) HEADER
Following the Data Link Header is the Logical Link Control Header, which is described in the IEEE 802.2 Specification. The purpose of the LLC header is to provide a “hole in the ceiling” of the Data Link Layer. By specifying into which memory buffer the adapter places the data frame, the LLC header allows the upper layers to know where to find the data.
Offset 15: The DSAP
The DSAP, or Destination Service Access Point, is a 1 byte field that simply acts as a pointer to a memory buffer in the receiving station. It tells the receiving NIC in which buffer to put this information. This functionality is crucial in situations where users are running multiple protocol stacks, etc…
Offset 16: The SSAP
The SSAP, or Source Service Access Point is analogous to the DSAP, and specifies the Source of the sending process.
Offset 17: The Control Byte
Following the SAPs is a one byte control field that specifies the type of LLC frame that this is.
USER DATA AND THE FRAME CHECK SEQUENCE (FCS)
Data: 43-1497 Bytes
Following the 802.2 header are 43 to 1,497 bytes of data, generally consisting of upper layer headers such as TCP/IP or IPX and then the actual user data.
FCS: Last 4 Bytes
The last 4 bytes that the adapter reads in are the Frame Check Sequence or CRC. When the voltage on the wire returns to zero, the adapter checks the last 4 bytes it received against a checksum that it generates via a complex polynomial. If the calculated checksum does not match the checksum on the frame, the frame is discarded and never reaches the memory buffers in the station
Snap Ethernet IEEE 802.3
SNAP Frame Format
The IEEE 802.3 SNAP Frame Format
While the original 802.3 specification worked well, the IEEE realized that some upper layer protocols required an Ethertype to work properly. For example, TCP/IP uses the Ethertype to differentiate between ARP packets and normal IP data frames. In order to provide this backwards compatibility with the Version II frame type, the 802.3 SNAP (SubNetwork Access Protocol) format was created.
The SNAP Frame Format consists of a normal 802.3 Data Link Header followed by a normal 802.2 LLC Header, and then a 5 byte SNAP field, followed by the normal user data and FCS.
The Data Link Header
Offset 0-5: The Destination Address
The first six bytes of an Ethernet frame make up the Destination Address. The Destination Address specifies to which adapter the data frame is being sent. A Destination Address of all ones specifies a Broadcast Message that is read in by all receiving Ethernet adapters.
The first three bytes of the Destination Address are assigned by the IEEE to the vendor of the adapter, and are specific to the vendor.
The Destination Address format is identical in all implementations of Ethernet.
Offset 6-11: The Source Address
The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card.
The Source Address format is identical in all implementations of Ethernet.
Offset 12-13: Length
Bytes 13 and 14 of an Ethernet frame contain the length of the data in the frame, not including the preamble, 32 bit CRC, DLC Addresses, or the Length field itself. An Ethernet frame can be no shorter than 64 bytes, and no longer than 1518 bytes in total length.
The 802.2 Logical Link Control Header (LLC)
Following the Data Link Header is the Logical Link Control Header, which is described in the IEEE 802.2 Specification. The purpose of the LLC header is to provide a “hole in the ceiling” of the Data Link Layer. By specifying into which memory buffer the adapter places the data frame, the LLC header allows the upper layers to know where to find the data.
Offset 14: The DSAP
The DSAP, or Destination Service Access Point, is a 1 byte field that simply acts as a pointer to a memory buffer in the receiving station. It tells the receiving NIC in which buffer to put this information. This functionality is crucial in situations where users are running multiple protocol stacks, etc…
In order to specify that this is a SNAP frame, the DSAP is set to AA hex.
Offset 15: The SSAP
The SSAP, or Source Service Access Point is analogous to the DSAP, and specifies the Service Access Point (SAP) of the sending process.
In order to specify that this is a SNAP frame, the SSAP is set to AA hex.
Offset 16: The Control Byte
Following the SAPs is a one byte control field that specifies the type of LLC frame that this is.
The Sub-Network Access Protocol (SNAP) Header
Offset 17-19: The Vendor Code
The first 3 bytes of the SNAP header is the vendor code, generally the same as the first three bytes of the source address, although it is sometimes set to zero.
Offset 20-21: The Local Code
Following the Vendor Code is a 2 byte field that typically contains an Ethertype for the frame. Here is where the backwards compatibility with Version II Ethernet is implemented.
User Data and the Frame Check Sequence (FCS)
Data: 38-1492 Bytes
Following the 802.2 headers are 38 to 1,492 bytes of data, generally consisting of upper layer headers such as TCP/IP or IPX and then the actual user data.
FCS: Last 4 Bytes
The last 4 bytes that the adapter reads in are the Frame Check Sequence or CRC. When the voltage on the wire returns to zero, the adapter checks the last 4 bytes it received against a checksum that it generates via a complex polynomial. If the calculated checksum does not match the checksum on the frame, the frame is discarded and never reaches the memory buffers in the station.
Version II
The Ethernet Version II Frame Format
The following is a description of the frame format described by the original Ethernet Version II specification, as released by DEC, Intel, and Xerox.
Like the 802.3 spec, the Version II spec defines a Data Link Header consisting of 14 bytes of information, but the Version II spec does not specify an LLC header.
The Data Link Header
Offset 0-5: The Destination Address
The first six bytes of an Ethernet frame make up the Destination Address. The Destination Address specifies to which adapter the data frame is being sent. A Destination Address of all ones specifies a Broadcast Message that is read in by all receiving Ethernet adapters.
The first three bytes of the Destination Address are assigned by the IEEE to the vendor of the adapter, and are specific to the vendor.
The Destination Address format is identical in all implementations of Ethernet.
Offset 6-11: The Source Address
The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card.
The Source Address format is identical in all implementations of Ethernet.
Offset 12-13: The Ethertype
Following the Source, Address is a 2 byte field called the Ethertype. The Ethertype is analogous to the SAPs in the 802.3 frame in that it specifies the memory buffer in which to place this frame.
An interesting question arises when one considers the 802.3 and Version II frame formats: Both formats specify a 2 byte field following the source address (an Ethertype in Version II, and a Length field in 802.3) — How does a driver know which format it is seeing, if it is configured to support both?
The answer is actually quite simple. All Ethertypes have a value greater than 05DC hex, or 1500 decimal. Since the maximum frame size in Ethernet is 1518 bytes, there is no point of overlap between Ethertypes and lengths. If the field that follows the Source Address is greater than O5DC hex, the frame is a Version II, otherwise, it is something else (either 802.3, 802.3 SNAP, or Novell Proprietary).
User Data and FCS
Data: 46-1500 Bytes
Following the Ethertype are 46 to 1,500 bytes of data, generally consisting of upper layer headers such as TCP/IP or IPX and then the actual user data.
FCS: Last 4 Bytes
The last 4 bytes that the adapter reads in are the Frame Check Sequence or CRC. When the voltage on the wire returns to zero, the adapter checks the last 4 bytes it received against a checksum that it generates via a complex polynomial. If the calculated checksum does not match the checksum on the frame, the frame is discarded and never reaches the memory buffers in the station.
Novell Proprietary (“802.3 Raw”)
The Novell Proprietary Frame Format
Novell’s Proprietary Frame Format was developed based on a preliminary release of the 802.3 specification. After Novell released their proprietary format, the LLC Header was added, making Novell’s format incompatible.
The Data Link Header
Offset 0-5: The Destination Address
The first six bytes of an Ethernet frame make up the Destination Address. The Destination Address specifies to which adapter the data frame is being sent. A Destination Address of all ones specifies a Broadcast Message that is read in by all receiving Ethernet adapters.
The first three bytes of the Destination Address is assigned by the IEEE to the vendor of the adapter, and are specific to the vendor.
The Destination Address format is identical in all implementations of Ethernet.
Offset 6-11: The Source Address
The next six bytes of an Ethernet frame make up the Source Address. The Source Address specifies from which adapter the message originated. Like the Destination Address, the first three bytes specify the vendor of the card.
The Source Address format is identical in all implementations of Ethernet.
Offset 12-13: Length
Bits 13 and 14 of an Ethernet frame contain the length of the entire data frame, not including the preamble or 32 bit CRC. An Ethernet frame can be no shorter than 64 bytes, and no longer than 1518 bytes.
User Data and the Frame Check Sequence (FCS)
Data: 46-1497 Bytes
Following the Data Link header are 46 to 1500 bytes of data. In all Novell frames, the user data begins with an IPX (Novell’s network layer protocol) header. The IPX header contains as its first two bytes an optional checksum, with the value FFFF signifying that the checksum is not used. By convention, the checksum is always turned off, and the FFFF that occurs 3 bytes after the end of the source address is how device drivers differentiate Novell frames from 802.3 frames, which look identical until the first byte following the length field.
FCS: Last 4 Bytes
The last 4 bytes that the adapter reads in are the Frame Check Sequence or CRC. When the voltage on the wire returns to zero, the adapter checks the last 4 bytes it received against a checksum that it generates via a complex polynomial. If the calculated checksum does not match the checksum on the frame, the frame is discarded and never reaches the memory buffers in the station.
A Final Note on the Novell Ethernet Frame Format
“A Novell client can only use one frame format for NetWare”
This is a true statement that needs some clarification to be fully understood.
It should be noted that Novell’s workstations are capable of using any of the four Ethernet frame types mentioned in this essay, based on the LOAD and BIND settings in the NET.CFG file. A Novell client will use the list of frame formats in NET.CFG to attempt to locate a file server (or a Netware Directory Server for the VLM shell). The client starts at the top of the list of frame types in NET.CFG and broadcasts a ‘Find Nearest Server’ message. If no file server answers (or Directory Services server in a VLM client) then the client tries the next frame format. When a server finally does answer then the client will use the successful frame format from then on; until the client is rebooted.
As a result, you should remember that a Novell client will ultimately use only one of the four frame formats; it can not actually use multiple formats for NetWare at the same time. The format it selects will be based on its initial attempt to locate a server. This behavior is restricted to the frame format used by NCP and SPX – if the client is also running a TCP/IP stack then the IP protocol can be configured to use any other frame format (typically Version II Ethernet).
