An Ethernet Frame is the format of the data encoded on a cable to provide connections in the local segment (Layer 2 in the OSI model). Above this are various protocol layers that allow different systems to communicate using the same interface hardware and infrastructure. Let’s look at what is inside an Ethernet Frame.
Preamble
An Ethernet frame has at the start a preamble sequence, which is 64 bits (8 octets) long. The preamble is a hangover from the original Ethernet bus and helped provide timing synchronisation between the different devices. The first 56 bits are an alternating sequence of 1’s and 0’s. The following 8 bits are the Start Frame Delimiter, which follows the same pattern, except the last two bits are 1’s, rather than the expected 10 sequence.
Frame Header
Now we get to the frame header proper. The header is 14 bytes long, and contains the destination MAC address, followed by the source MAC address and then a two-byte type/length field.
Destination MAC Address
The Destination MAC Address is used to direct the frame to the right device on the Ethernet bus. The field is six octets long and comprises a three octet OUI code, and three octets unique to each device. The Organizationally Unique Identifier (OUI) is allocated centrally by the IEEE.
The destination MAC address also identifies multicast destinations, by setting the first bit of the MAC address as 1. If the second bit is a 1, then this indicates a locally administered address (rather than the OUI allocated one). Ethernet doesn’t regularly use locally administered addresses, but it can be helpful sometimes.
Source MAC Address
The source MAC address uses the same group of two sets of three octets as the Destination MAC address. The source address will typically be the OUI allocated address, and should, therefore, be unique on the network. (But it sometimes isn’t, see the post This one time, when I found two identical MAC addresses…) When you use locally administered MAC addresses, the source MAC will be these, rather than the hard-coded adaptor address.
Type/Length Field
Here is where it gets interesting. In the original Ethernet protocol, this field was only used to represent the length of the data transmitted. It counted from the start of the destination MAC address to the end of the Frame Check Sequence. The length field has a minimum value of 64. This format provides the most remaining space for in the frame for the Layer 3 payload.
If there is only a single protocol on the wire, the length field is the most efficient, as there is no need to encode any additional data. However, as Ethernet became more popular, carrying other protocols without the impact of the LLC header (see below) became necessary. This field then became used to identify the protocol being transported in the Layer 3 payload section.
If this value is less than 0x600, this field is coded as the frame length. If the function of this field supports an Ethernet type, then this automatically identifies to contents of the Layer 3 payload. We’ll look at some of the possibilities in the Layer 3 Payload section coming up, but the full IEEE list is available at http://standards-oui.ieee.org/ethertype/eth.txt. Where multiple
802.1Q/p Tag (VLAN header)
This is a specific EtherType field (0x8100), which is used to identify a particular virtual LAN (VLAN) that carries this payload. This VLAN header uses an Ethernet Type of 0x8100 and is followed by two additional octets. These two octets comprise 3 bits of priority code, and a discard eligibility flag, as well as a twelve-bit field indicating the VLAN for which the rest of the traffic is destined.
The VLAN header is generally followed by an additional Ethernet Type field and the Layer 3 payload.
Service Provider networks sometimes double encapsulate packets, using the IEEE 802.1ad (QinQ) protocol. This uses a second VLAN header in front of the first (but with an Ethernet Type of 0x88A8), that groups customer VLANs together into a VLAN within their core infrastructure.
Most network equipment that supports the VLAN header allows the frame size to be expanded so that the additional four octets of information can be carried without leading to a reduction in the potential payload size.
Logical Link Control Header (For 802.2 formatted frames)
When the IEEE standardised Ethernet as the 802.3 protocol in 1983, they wanted to make the Ethernet frame more adaptable, and compatible with other existing standards that used their 802.2 LLC header. The 802.2 header allows multiple protocols to use the same network infrastructure similar to that used on different network types. Using the LLC header meant that multi-topology bridges (such as Ethernet to Token-Ring, or Token-Ring to FDDI) could effectively function.
If used, this appears after the Ethernet Header and starts with either a 0xAA or 0xAB value, followed by a three octet OUI, and a two octet PID code.
Layer 3 Payload
In inside here you have the actual payload of the Ethernet frame for the protocol you’re transmitting across the network, whether it’s IP (versions 4 or 6), Novell IPX, DECnet, or any of the other protocols the network may use.
This part of the frame is where the real data carried across the network resides. There is usually a Layer 3 header which helps identify the source and destination across the network as a whole.
Typical protocols that carried are (Ethernet Type in brackets): IPv4 (0x0800), ARP (0x0806) and IPv6 (0x86DD)
Frame Check Sequence
The last element of the frame is the Frame Check Sequence, which provides a checksum for the data within the frame, and protects against bit errors that may be induced in the transfer.
The FCS uses four octets (32 bits) to provide a Cyclic Redundancy Check (CRC) across the whole of the frame proper (ignoring the preamble). The process for generating the CRC creates a magic number of 0xC704DD7B when the CRC process runs at the receiver. This magic number protects against trailing zeros being added to the frame (for example if the length field becomes corrupted)
With the Frame Check Sequence, the packet size of a normal Ethernet frame is 1518 bytes long.
Interframe Gap
The interframe gap provides a time during which the network is idle following transmission of data. This allows other devices to access the media in the gap, preventing one system monopolising access to the wire.
Tradditionally, this is 96 bit-times long, but faster networks such as 40Gb/s Ethernet may reduce this to a smaller value to improve throughput.