Ethernet Frame
1. The term "Frames" Defined
The term frames is most often used to describe Ethernet Layer 2 data units, or Token Ring Layer 2, or Frame Relay Layer 2, or T-carrier Layer 1 data units. Typically layer 1 frames are delivered using the T-carrier system, and layer 2 frames are delivered using the Ethernet or Token Ring protocol.
Officially, a packet is at Layer 3, and a frame is at Layer 2 or Layer 1.
2. IP packets encapsulated into Ethernet Frames
Note that maximum length Ethernet II frames (1518 bytes, with a payload of 1500 bytes) are much smaller that maximum length IP packets (65,535 bytes). Therefore, for large packets, they must be fragmented into many frames.
3. Ethernet II (DIX), IEEE 802.3 (LLC), and SNAP Frames
Ethernet II is the predominant type. SNAP and LLC are rarely used, particularly not in a TCP/IP context. (They are used for things like AppleTalk, and NetBIOS/NetBEUI, but these are minor players today, relative to TCP/IP.)
Notes
The 802.2 LLC Control byte - this is sometines called "U", for Un-numbered control field command/response.
Difference between Ethernet II and 802.3 - Ethernet II is the only frame that has a "Type" field (bytes 13-14), which lists a number that identifies the protocol of the Data contained in the frame. Here are a few Ethernet II Type field values:
0x0600 XNS (Xerox)
0x0800 IP (the Internet protocol)
0x0806 ARP
0x6003 DECNET
IEEE 802.3 decided to include the Type of both source and destination in the 802.2 LLC header. So they replaced the Type field (bytes 13-14) with a Length field. The "length" is not the full frame size - rather, it is the 802.2 packet length - the number of bytes of the 802.2 (LLC and data) portion of the frame, excluding padding.
how does the Receiver determine the Length of Ethernet II frames (since they have no "Length" field) - even with 802.3, which has a length field - oddly, the length field has never been used to determine the length of the frame! In Ethernet, a frame is over when the carrier drops. The packet driver simply counts bytes as they come in. When they stop, that is the end of the frame, and the current byte count is the total frame length.
How does the Network know if the Frames are Ethernet II or 802.3 ?
By the value of that 2-byte field (bytes 13 and 14). When the IEEE came up with the 802.3 frame, there were only a few Ethernet II protocol Type numbers below 0x600. They were retired and assigned new numbers above 0x600. Therefore . . .
- packet with bytes 13-14 less than 0x600 are IEEE 802.3
- packets with bytes 13-14 equal or greater than 0x600 are Ethernet II.
How does the Network identify SNAP frames ?
First, the value of bytes 13-14 are inspected to identify that the frame is 802.3. Then bytes 15-17 are inspected to see if the frame is standard 802.3 LLC or 802.3 SNAP. SNAP has the LLC field, but does not use it - other than to identify the frame as SNAP !! It's framing uses "AAAA03" for what normally would be the 802.2 LLC DSAP, SSAP, and Control fields. In otherwords, if bytes 15-17 are AAAA03, then the frame is 802.3 SNAP.
"length" is the length of the 802.2 (LLC and data) portion of the frame, excluding padding. The 802.2 LLC starts with the DSAP field. "DSAP" is the destination service access point. "SSAP" is the source service access point. "U" is unnumbered control field command/response.
4. SNAP
SNAP is an extension to the LLC header, so that all protocols can be identified. With Ethernet II, the Type field is 2 bytes. But with 802.3, they moved the Type field into the LLC header, and they made a big mistake - they only alloted one byte to each SAP field!
The value of the one-byte LLC SAP fields (DSAP & SSAP) are limited to between 1 and 255, since it is a 8 bit field. But there are many more protocols than 255! For example, IP and ARP use registered protocol numbers above 1500! Ethernet II and it's 2-byte Type field has no problem with these numbers. But for 802.3 they had to extend the LLC by adding a SNAP header.
One SAP value (the "SNAP" SAP, AA AA hex) was reserved to denote that this is a SNAP (Sub-Network Access Protocol) frame. In a SNAP frame, both the SAP values will be 0xAA and the first 5 bytes of the data will give the protocol ID. Well, some show the 5 bytes as a separate field, and others show it as part of the data field. It is easier to understand if it is shown as a separate field. Out of the 5 bytes of data, the last 2 bytes are same as the protocol type field of the Ethernet II frame. The first 3 bytes are called as 'Organizationally Unique Identifer' (OUI) and are allocated as a vendor identifier. Typically, OUI will be zero.
5. Assembling a Frame
The sending station assembles PDU's (Protocol Data Units), which are binary units of info, one layer at a time, moving downward from Layer 7 to Layer 2 - to be placed on the cable for transmission by Layer 1. Each successive, lower layer, adds it's own "header" (additional info) to the PDU that has been passed down to it by the layer above. Layer 2 PDU's are called frames, and they are placed on the cable by Layer1, one bit at a time.
NOTE: Layer 1 does not add any headers, and therefore does not change the Frame size. However, it does add a 9.6 usec IFG, Inter-Frame gap (9.6 usec at 10 Mbps = 12 bytes worth of silence followed by an 8-byte Preamble, which includes 2 bits called SOF (Start of Frame), which notify the receiving station that the frame is about to begin coming in. Layer 1's only function is to convert the frames to a serial stream of bits for transmission (and reception).
NOTE: the Data portion of the Layer 2 Frame, contains headers from the layers above. But frames do not necessarily contain headers for all layers above. For example, a packet could begin it's assembly at the Transport Layer (layer 4) and work it's way down from there. Most control packets such as ACK, routing protocol info, etc, are created beginning at layers lower than the top Layer 7 (below the Application Layer).
6. Ethernet Frames as compared to the Layered Models
Layer 2 with Ethernet is actually divided into two sublayers . . . the LLC and the MAC. However, the LLC (Logical Link Control), as it's name implies, is just a logical sub-layer and does not add any physical data. The MAC (Media Access Control) sub-layer does add a header and optionally, a CRC trailer. The competed frame is shown below - next to the two most popular protocol standards . . . the OSI model, and the TCP/IP model:
NOTE: this is an Ethernet II Frame (DIX) - if it were an 802.3 Frame, the Type field would be replaced by Length and LLC fields.
7. Pre-Frame Components - IFG Inter-Frame Gap, Preamble, and SOF
When dealing with frame byte counts, and frame diagrams, etc. - the standard is to leave out these "pre-frame" occurences.
Although it is true that all Ethernet frames are preceded by a small idle period (the minimum inter-frame gap, 9.6 microsecond (μS)) and a 8 byte "preamble + SOF" . . . they are not considered part of the frame.
IFG (Inter Frame Gap)
Between transmission of each frame, a transmitter must wait for a period of 9.6 microseconds for Fast Ethernet and .096 usec for Gigabit Ethernet. At 10 Mbps this corresponds to about the time it takes for 12 bytes to be transmitted. The IFG will allow the signal time to propagate through the receiver electronics at the destination. While every transmitter must wait for this time between sending frames, receivers do not necessarily see a "silent" period of 9.6 microseconds. The way in which repeaters operate is such that they may reduce the IFG between the frames which they regenerate.
Preamble and SOF (Start Of Frame)
The purpose of the preamble is to allow time before transmission starts is to allow a small time interval for the receiver electronics in each of the nodes to settle after completion of the previous frame. The purpose of the SOF is to notify the receiving station that the frame bits are going to come in next. The preamble is 8 bytes and includes the SOF, which is the last 2 bits of the preamble, "11" :
In any case, combined they are a total of 64 bits, or 8 bytes. The frame does not officially begin until just after the SOF. Therefore the preamble and SOF are not part of the frame !
When encoded using Manchester encoding, at 10 Mbps, the 62 alternating bits produce a 5 MHz square wave. The purpose of the preamble is to allow time for the receiver in each node to achieve lock of the receiver Digital Phase Lock Loop which is used to synchronise the receive data clock to the transmit data clock. At the point when the first bit of the preamble is received, each receiver may be in an arbitrary state (i.e. have an arbitrary phase for its local clock). During the course of the preamble it learns the correct phase, but in so doing it may miss (or gain) a number of bits. A special pattern (11), is therefore used to mark the last two bits of the preamble. When this is received, the Ethernet receive interface starts collecting the bits into bytes for processing by the MAC layer.
8. Legal Ethernet Frames
Minimum and Maximum Frame Size
As shown in the Frame types diagram at the top - the full frame min=64 bytes, and the max = 1518 bytes. The headers sizes vary, so in order to come up with the same full frame min and max values for all frame types - the min/max Data values change accordingly :
| Frame Type | Header & CRC | Data Min | Data Max |
| Ethernet II (DIX) | 18 | 46 | 1500 |
| 802.3 (IEEE) | 21 | 43 | 1497 |
| SNAP | 26 | 38 | 1492 |
Reasons for the 1500 byte Limit (Ethernet II)
The 1500 byte payload limit was somewhat arbitrary. *Some* upper limit is needed for a number of reasons:
- The longer the maximum frame allowed, the longer the maximum delay on a shared medium. All stations must wait for a frame-in-progress to complete before attempting their own transmission; longer frames means longer wait time.
- Longer frames increases the probability that one or more bits in the frame will be received in error, necessitating retransmission of the frame. (In the extreme case, an infinitely-long frame is *guaranteed* to contain bit errors, ensuring that it would *never* be correctly
received!) - A longer maximum frame increases the memory requirement for a NIC using a simple, fixed buffer design. This is the *real* reason for the 1500
byte limit; at the time we designed it (1979), buffer memory was much more expensive than it is now, and DMA controllers were too complex to
be implemented in anything less than a full-custom chip.
Header
The header consists of three parts:
- A 6-byte destination address, which specifies either a single recipient node (unicast mode), a group of recipient nodes (multicast mode), or the set of all recipient nodes (broadcast mode).
- A 6-byte source address, which is set to the sender's globally unique node address. This may be used by the network layer protocol to identify the sender, but usually other mechanisms are used (e.g. arp). Its main function is to allow address learning which may be used to configure the filter tables in a bridge.
- A 2-byte type field (Ethernet II, DIX frames) OR a 2-byte Length and 3-byte LLC Field (IEEE 802.3 frames). With Ethernet II, the type field provides a Service Access Point (SAP) to identify the type of protocol being carried (e.g. the values 0x0800 is used to identify the IP network protocol, other values are used to indicate other network layer protocols). With 802.3, the LLC 802.2 header is included, which contains the DSAP and SSAP.
CRC (Cyclic Redundancy Check)
The 32-bit (4-byte) CRC field is added at the end of the frame (trailer) and provides error detection in the case where line errors (or transmission collisions in Ethernet) result in corruption of the MAC frame. Any frame with an invalid CRC is discarded by the MAC receiver without further processing. The MAC protocol does not provide any indication that a frame has been discarded due to an invalid CRC.
8. Illegal Ethernet Frames
All illegal frames are dropped by the receiving station. It is up to higher layer protocols, such as TCP/IP, to notify the sending station that the frame was dropped ! They do this by numbering frames - any frame in the sequence that is dropped is identified by comparing the sequence numbers, and notifying the sender which frame was dropped so that he can re-transmit.
Runt Frame
Any frame which is received and which is less than 64 bytes (18 bytes Header/CRC and 46 bytes data) is illegal, and is called a "runt". In most cases, such frames arise from a collision, and while they indicate an illegal reception, they may be observed on correctly functioning networks. A receiver must discard all runt frames.
Padding to prevent Runts - if the network layer wishes to send less than 46 bytes of data, the MAC protocol adds a sufficient number of zero bytes (0x00, is also known as null padding characters) to satisfy this requirement.
Giant Frame
Any frame which is received and which is greater than the maximum frame size, and is called a "giant". In theory, the jabber control circuit in the transceiver should prevent any node from generating such a frame, but certain failures in the physical layer may also give rise to over-sized Ethernet frames. Like runts, giants are discarded by the Ethernet receiver.
Misaligned Frame
Any frame which does not contain an integral number of received octets (bytes) is also illegal. A receiver has no way of knowing which bits are legal, and how to compute the CRC-32 of the frame. Such frames are therefore also discarded by the Ethernet receiver.
9. Transmitting the Frame (byte order and bit order)
Ethernet transmission is strange, in that the byte order is big-endian (leftmost byte is sent first), but bit order little-endian (rigthmost, or LSB (Least Significant Bit) of the byte is sent first).
For example, we assume the preamble has been sent, then the next to be sent is the destination MAC address - 6 bytes, but for this example we will show the first 4 bytes:
Byte1 Byte2 Byte3 Byte4
The data normally moves to the left, using traditional images of frames. This is true for each of the 4 bytes - they will be transmitted in big-endian, meaning "left byte first". But we must reverse the bits in each byte, to show the actual serial stream of bits moving to the left. So the actual bits being transmitted to the left, are as follows with the bits in each byte reversed:
Byte1 Byte2 Byte3 Byte4
(reversed) (reversed) (reversed) (reversed)
NOTE: Ethernet does not group bytes. It has no idea that it is sending a 6-byte address, or a 2-byte Type, etc. It simply sends the entire frame, one byte at a time, from left to right, with each byte being sent LSB first and MSB last.
References:
http://www.infocellar.com/networks/ethernet/