Ethernet frame
[2] The table below shows the complete Ethernet packet and the frame inside, as transmitted, for the payload size up to the MTU of 1500 octets.
[d] The preamble bit values alternate 1 and 0, allowing receivers to synchronize their clock at the bit-level with the transmitter.
The connection between a PHY and MAC is independent of the physical medium and uses a bus from the media-independent interface family (MII, GMII, RGMII, SGMII, XGMII).
The preamble and SFD representation depends on the width of the bus: (GMII bus for Gigabit Ethernet transceivers) The SFD is immediately followed by the destination MAC address, which is the first field in an Ethernet frame.
Non-standard jumbo frames allow for larger payloads on networks built to support them.
An alternative is to calculate a CRC on both the received data and the FCS, which will result in a fixed non-zero "verify" value.
Later physical layers use an explicit end of data or end of stream symbol or sequence to avoid ambiguity, especially where the carrier is continually sent between frames; an example is Gigabit Ethernet with its 8b/10b encoding scheme that uses special symbols which are transmitted before and after a frame is transmitted.
In addition, all four Ethernet frame types may optionally contain an IEEE 802.1Q tag to identify what VLAN it belongs to and its priority (quality of service).
This encapsulation is defined in the IEEE 802.3ac specification and increases the maximum frame by 4 octets.
The IEEE 802.1Q tag, if present, is placed between the Source Address and the EtherType or Length fields.
The TPID is followed by two octets containing the Tag Control Information (TCI) (the IEEE 802.1p priority (quality of service) and VLAN id).
[h] Since the recipient still needs to know how to interpret the frame, the standard required an IEEE 802.2 header to follow the length and specify the type.
That value was chosen because the maximum length of the payload field of an Ethernet 802.3 frame is 1500 octets (0x05DC).
Novell's "raw" 802.3 frame format was based on early IEEE 802.3 work.
Novell used this as a starting point to create the first implementation of its own IPX Network Protocol over Ethernet.
This does not conform to the IEEE 802.3 standard, but since IPX always has FF as the first two octets (while in IEEE 802.2 LLC that pattern is theoretically possible but extremely unlikely), in practice this usually coexists on the wire with other Ethernet implementations, with the notable exception of some early forms of DECnet which got confused by this.
[11] Some protocols, such as those designed for the OSI stack, operate directly on top of IEEE 802.2 LLC encapsulation, which provides both connection-oriented and connectionless network services.
There exists an Internet standard for encapsulating IPv4 traffic in IEEE 802.2 LLC SAP/SNAP frames.
The AppleTalk v2 protocol suite on Ethernet ("EtherTalk") uses IEEE 802.2 LLC + SNAP encapsulation.
At the physical layer, the link channel and equipment do not know the difference between data and control frames.
