Jump to content

Ethernet frame: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
m avoid bit/s wrap at slash
 
(671 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{Short description|Unit of data on an Ethernet network}}
A data packet on an [[Ethernet]] link is called an '''Ethernet frame'''. A frame begins with Preamble and Start Frame Delimiter. Following which, each Ethernet frame continues with an Ethernet header featuring destination and source [[MAC address]]es. The middle section of the frame is payload data including any headers for other protocols (e.g. [[Internet Protocol]]) carried in the frame. The frame ends with a 32-bit [[cyclic redundancy check]] which is used to detect any corruption of data in transit.
{{Use dmy dates|date=March 2024}}
{{Use American English|date = March 2019}}

[[File:ethernet frame.svg|Ethernet packet. The SFD (start frame delimiter) marks the end of the packet preamble. It is immediately followed by the Ethernet frame, which starts with the destination MAC address.<ref name="802.3-2018">{{Cite book |title=802.3-2018 – IEEE Standard for Ethernet |date=2018-06-14 |publisher=[[IEEE]] |isbn=978-1-5044-5090-4 |doi=10.1109/IEEESTD.2018.8457469}}</ref>|thumb|300x300px]]

In [[computer network]]ing, an '''Ethernet frame''' is a [[data link layer]] [[protocol data unit]] and uses the underlying [[Ethernet physical layer]] transport mechanisms. In other words, a [[network packet|data unit]] on an [[Ethernet]] link transports an Ethernet frame as its payload.<ref name="IEEE 802.3 Clause 3.1.1">{{cite book|title=802.3-2018 – IEEE Standard for Ethernet|section=3.1.1 Packet format|publisher=[[IEEE]]|date=2018-06-14|isbn=978-1-5044-5090-4|doi=10.1109/IEEESTD.2018.8457469}}</ref>

An Ethernet [[Frame (networking)|frame]] is preceded by a [[Preamble (communication)|preamble]] and start frame delimiter (SFD), which are both part of the Ethernet packet at the [[physical layer]]. Each Ethernet frame starts with an Ethernet header, which contains destination and source [[MAC address]]es as its first two fields. The middle section of the frame is payload data including any headers for other protocols (for example, [[Internet Protocol]]) carried in the frame. The frame ends with a [[frame check sequence]] (FCS), which is a 32-bit [[cyclic redundancy check]] used to detect any in-transit corruption of data.


==Structure==
==Structure==
{{See also|Physical Coding Sublayer}}
A data packet on the wire is called a frame and consists of binary data. A frame viewed on the physical wire would show Preamble and Start Frame Delimiter, in addition to the other data. These are required by all physical hardware.<ref group=note>Preamble and Start Frame Delimiter are not displayed by [[packet sniffing]] software because these bits are stripped away at OSI Layer 1 by the [[Ethernet adapter]] before being passed on to the OSI Layer 2 which is where packet sniffers collect their data from. There are OSI Physical Layer sniffers which can capture and display the Preamble and Start Frame but they are expensive and mainly used to detect physical related problems.</ref>

A data packet on the wire and the frame as its payload consist of binary data. Ethernet transmits data with the most-significant [[octet (computing)|octet]] (byte) first; within each octet, however, the least-significant bit is transmitted first.{{efn|The [[frame check sequence]] (FCS) uses a different bit ordering.<ref>{{Cite book
| title = 802.3-2018 – IEEE Standard for Ethernet
| date = 2018-06-14
| publisher = [[IEEE]]
| doi = 10.1109/IEEESTD.2018.8457469
| isbn = 978-1-5044-5090-4
| at = Section 3.3 and annex 31A
| quote = Opcodes are transmitted high-order octet first. Within each octet, bits are transmitted least-significant bit first. [...] Each octet of the MAC frame, with the exception of the FCS, is transmitted least significant bit first.
}}</ref>}}


The table below shows the complete Ethernet frame, as transmitted, for the [[maximum transmission unit|MTU]] of 1500 [[octet (computing)|octets]] (some implementations of [[gigabit Ethernet]] and higher speeds support larger [[jumbo frame]]s).<ref group=note>The bit patterns in the preamble and start of frame delimiter are written as bit strings, with the first bit transmitted on the left (''not'' as byte values, which in Ethernet are transmitted least significant bit(s) first). This notation matches the one used in the IEEE 802.3 standard.</ref> One octet is eight bits of data (i.e., a byte on most modern computers).
The internal structure of an Ethernet frame is specified in IEEE 802.3.<ref name="IEEE 802.3 Clause 3.1.1" /> The table below shows the complete Ethernet packet and the frame inside, as transmitted, for the payload size up to the [[maximum transmission unit|MTU]] of 1500 octets.{{Efn|The bit patterns in the preamble and start of frame delimiter are written as bit strings, with the first bit transmitted on the left (''not'' as octet values, which in Ethernet are transmitted least significant bit(s) first). This notation matches the one used in the IEEE 802.3 standard.}} Some implementations of [[Gigabit Ethernet]] and other higher-speed variants of Ethernet support larger frames, known as [[jumbo frame]]s.


{| class="wikitable" style="text-align: center;"
{| class="wikitable" style="text-align: center;"
|+ 802.3 Ethernet frame structure
|+ 802.3 Ethernet packet and frame structure
|-
|-
! Preamble !! Start of frame delimiter !! MAC destination !! MAC source !! [[802.1Q]] tag (optional) !! [[Ethertype]] or length !! Payload !! [[Cyclic redundancy check]] !! [[Interframe gap]]
! Layer !! Preamble !! Start frame delimiter (SFD) !! MAC destination !! MAC source !! [[802.1Q]] tag (optional) !! [[Ethertype]] ([[Ethernet II|Ethernet&nbsp;II]]) or&nbsp;length ([[IEEE&nbsp;802.3]]) !! Payload !! [[Frame check sequence]] (32‑bit [[cyclic redundancy check|CRC]]) !! [[Interpacket gap|Interpacket&nbsp;gap (IPG)]]
|-
|-
| Length ([[Octet (computing)|octets]])
| 7 [[Octet (computing)|octet]]s of 10101010 || 1 octet of 10101011 || 6 octets || 6 octets || (4 octets) || 2 octets || {{nowrap|46–1500 octets}} || {{nowrap|4 octets}} || 12 octets
| 7 || 1 || 6 || 6 || (4) || 2 || 42–1500{{efn|Payload can be 42 octets if an 802.1Q tag is present. Minimum is 46 octets without.}} || 4 || 12
|-
|-
| [[Layer 2]] Ethernet frame
| colspan="2" | || colspan="6" style="background:#fdd;"| {{nowrap|64–1522 octets}} ||
| colspan="2" | (not part of the frame)|| colspan="6" style="background:#fdd;" | {{nowrap|← 64–1522 octets →}} ||(not part of the frame)
|-
|-
| [[Layer 1]] Ethernet packet & IPG
| colspan="8" style="background:#fdd;"| {{nowrap|72–1530 octets}} ||
| colspan="8" style="background:#fdd;"| {{nowrap|← 72–1530 octets →}} || style="background:#fdd;" | ← 12 octets&nbsp;→
|}

The optional 802.1Q tag consumes additional space in the frame. Field sizes for this option are shown in brackets in the table above. [[IEEE 802.1ad]] (Q-in-Q) allows for multiple tags in each frame. This option is not illustrated here.

=== {{Anchor|Ethernet packet}}Ethernet packet – physical layer===

==== {{Anchor|SFD}}Preamble and start frame delimiter ====
{{See also|Syncword}}

An Ethernet packet starts with a seven-octet (56-bit) [[Preamble (communication)|preamble]] and one-octet (8-bit) ''start frame delimiter'' (SFD).{{Efn|Preamble and start frame delimiter are not displayed by [[packet sniffing]] software because these bits are stripped away at OSI layer 1 by the [[network interface controller]] (NIC) before being passed on to the [[OSI layer 2]], which is where packet sniffers collect their data. There are layer-2 sniffers that can capture and display the preamble and start frame delimiter, but they are expensive and mainly used to detect problems related to physical connectivity.}} The preamble bit values alternate 1 and 0, allowing receivers to synchronize their clock at the bit-level with the transmitter. The preamble is followed by the SFD which ends with a 1 instead of 0, to break the bit pattern of the preamble and signal the start of the actual frame.<ref name="802.3-2018" />{{rp|section 4.2.5}}

[[PHY|Physical layer transceiver circuitry]] (PHY for short) is required to connect the Ethernet MAC to the physical medium. The connection between a PHY and MAC is independent of the physical medium and uses a bus from the media-independent interface family ([[Media Independent Interface|MII]], [[GMII]], [[RGMII]], [[SGMII]], [[XGMII]]). The preamble and SFD representation depends on the width of the bus:
{| class="wikitable"
|+Preamble and SFD representations as bits, decimal, bytes, and nibbles
!Representation
! colspan="14" |'''56-bit (7-byte) Preamble'''
! colspan="2" |'''SFD byte'''
|-
|uncoded on-the-wire '''bit pattern''' transmitted from left to right (used by Ethernet variants transmitting serial bits instead of larger [[symbol (data)|symbols]])<ref name="802.3-2018" />{{rp|sections 4.2.5 and 3.2.2}}
| colspan="2" |10101010
| colspan="2" |10101010
| colspan="2" |10101010
| colspan="2" |10101010
| colspan="2" |10101010
| colspan="2" |10101010
| colspan="2" |10101010
| colspan="2" |10101011
|-
|'''decimal''' in Ethernet [[Least Significant Bit|LSb]]-first ordering<ref name="802.3-2018" />{{rp|sections 3.2.2, 3.3 and 4.2.6}}
| colspan="2" |85
| colspan="2" |85
| colspan="2" |85
| colspan="2" |85
| colspan="2" |85
| colspan="2" |85
| colspan="2" |85
| colspan="2" |213
|-
|hexadecimal LSb-first '''bytes''' for 8-bit wide busses
([[GMII|GMII bus]] for [[Gigabit Ethernet]] transceivers)
| colspan="2" |0x55
| colspan="2" |0x55
| colspan="2" |0x55
| colspan="2" |0x55
| colspan="2" |0x55
| colspan="2" |0x55
| colspan="2" |0x55
| colspan="2" |0xD5
|-
|-
|hexadecimal LSb-first [[nibble|'''nibbles''']] for 4-bit wide busses ([[Media-independent interface|MII bus]] for [[Fast Ethernet]] or [[RGMII]] for gigabit transceivers)
| colspan="9" style="background:#fdd;"| {{nowrap|84–1542 octets}}
|0x5
|0x5
|0x5
|0x5
|0x5
|0x5
|0x5
|0x5
|0x5
|0x5
|0x5
|0x5
|0x5
|0x5
|0x5
|0xD
|}
|}


The SFD is immediately followed by the destination [[MAC address]], which is the first field in an Ethernet frame.
===Preamble and Start Frame Delimiter===
{{see also|Syncword}}
10/100M transceiver chips ([[Media Independent Interface|MII]] [[PHY]]) work with 4-bits (one [[nibble]]) at a time. Therefore the preamble will consist of 7 instances of 0101 + 0101, and the Start Frame Delimiter 0101 + 1101. 8-bit values are sent low 4-bit first and then high 4-bit. 1000M transceiver chips ([[Gigabit Media Independent Interface|GMII]]) work with 8-bits at a time, and 10 Gbit/s ([[XGMII]]) PHY works with 32-bits at a time. Note that when using octets, first 7 octets of 01010101 are sent, and then one octet of 11010101. But because the low 4-bit nibble 0101 is sent first, and later the high 4-bit nibble 1101, the Start-of-frame sequence 1101 will be sent after the preamble not before the last 4-bits of the preamble as one might otherwise be lead to believe.


===Frame – data link layer===
===Header===
====Header====
The header features source and destination MAC address, the Ethertype protocol identifier field and optional [[IEEE 802.1Q]] VLAN tag indicating VLAN membership and traffic priority.
The header features destination and source MAC addresses (each six octets in length), the [[EtherType]] field and, optionally, an [[IEEE 802.1Q]] tag or [[IEEE 802.1ad]] tag.


The EtherType field is two octets long and it can be used for two different purposes. Values of 1500 and below mean that it is used to indicate the size of the payload in octets, while values of 1536 and above indicate that it is used as an EtherType, to indicate which protocol is encapsulated in the payload of the frame. When used as EtherType, the length of the frame is determined by the location of the [[interpacket gap]] and valid [[frame check sequence]] (FCS).
===Frame check sequence===
The frame check sequence is a 32-bit cyclic redundancy check which enables detection of corrupted data within the entire frame.


The [[IEEE 802.1Q]] tag or [[IEEE 802.1ad]] tag, if present, is a four-octet field that indicates [[virtual LAN]] (VLAN) membership and [[IEEE 802.1p]] priority. The first two octets of the tag are called the '''T'''ag '''P'''rotocol '''ID'''entifier (TPID) and double as the EtherType field indicating that the frame is either 802.1Q or 802.1ad tagged. 802.1Q uses a TPID of 0x8100. 802.1ad uses a TPID of 0x88a8.
===Interframe gap===
{{main|Interframe gap}}


====Payload====
After a frame has been sent, transmitters are required to transmit a minimum of 12 octets of idle line state before transmitting the next frame.
Payload is a variable-length field. Its minimum size is governed by a requirement for a minimum frame transmission of 64 octets (bytes).{{Efn|Minimum payload size is dictated by the 512-bit slot time used for [[Carrier-sense multiple access with collision detection|collision detection]] in the Ethernet LAN architecture.}} With header and FCS taken into account, the minimum payload is 42 octets when an 802.1Q tag is present{{Efn|Both 42 and 46 octet minimums are valid when 802.1Q is present.<ref>{{cite book|doi=10.1109/IEEESTD.2011.6009146|chapter=Annex G|title=IEEE Standard for Local and metropolitan area networks--Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks|isbn=978-0-7381-6708-4}}</ref>}} and 46 octets when absent. When the actual payload is less than the minimum, padding octets are added accordingly. IEEE standards specify a maximum payload of 1500 octets. Non-standard [[jumbo frame]]s allow for larger payloads on networks built to support them.


==Ethernet frame types==
====Frame check sequence====
The [[frame check sequence]] (FCS) is a four-octet [[cyclic redundancy check]] (CRC) that allows detection of corrupted data within the entire frame as received on the receiver side. According to the standard, the FCS value is computed as a function of the protected MAC frame fields: source and destination address, length/type field, MAC client data and padding (that is, all fields except the FCS).
There are several types of Ethernet frames. The different frame types have different formats and [[MTU (networking)|MTU]] values, but can coexist on the same physical medium.
*The Ethernet Version 2<ref group=note>A version 1 Ethernet frame was used for early Ethernet prototypes and featured 8-bit MAC addresses and was never commercially deployed.</ref> or Ethernet II frame or DIX frame is the most common type in use today, as it is often used directly by the Internet Protocol.
*[[Novell]]'s non-standard variation of raw [[IEEE 802.3]] frame
*[[IEEE 802.2]] [[Logical Link Control]] (LLC) frame
*[[Subnetwork Access Protocol]] (SNAP) frame


Per the standard, this computation is done using the left shifting CRC-32 ([[cyclic redundancy check#Introduction|polynomial]] = 0x4C11DB7, initial CRC = 0xFFFFFFFF, CRC is post complemented, verify value = 0x38FB2284) algorithm. The standard states that data is transmitted least significant bit (bit 0) first, while the FCS is transmitted most significant bit (bit 31) first.<ref name="802.3-2018" />{{rp|section 3.2.9}} An alternative is to calculate a CRC using the right shifting CRC-32 (polynomial = 0xEDB88320, initial CRC = 0xFFFFFFFF, CRC is post complemented, verify value = 0x2144DF1C), which will result in a CRC that is a bit reversal of the FCS, and transmit both data and the CRC least significant bit first, resulting in identical transmissions.
In addition, all four Ethernet frames types may optionally contain a IEEE 802.1Q tag to identify what [[Virtual LAN|VLAN]] it belongs to and its [[IEEE 802.1p]] priority ([[quality of service]]). This encapsulation is defined in the [[IEEE 802.3ac]] specification and increases the maximum frame by 4 bytes.


The standard states that the receiver should calculate a new FCS as data is received and then compare the received FCS with the FCS the receiver has calculated. 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. (The result is non-zero because the CRC is post complemented during CRC generation). Since the data is received least significant bit first, and to avoid having to buffer octets of data, the receiver typically uses the right shifting CRC-32. This makes the "verify" value (sometimes called "magic check") 0x2144DF1C.<ref>{{cite web|url=https://www.autosar.org/fileadmin/user_upload/standards/classic/4-1/AUTOSAR_SWS_CRCLibrary.pdf#page=24|title=Specification of CRC Routines V4.5.0 R4.1 Rev 3|page=24|publisher=[[AUTOSAR]]|access-date=30 January 2020|archive-date=11 June 2020|archive-url=https://web.archive.org/web/20200611204430/https://www.autosar.org/fileadmin/user_upload/standards/classic/4-1/AUTOSAR_SWS_CRCLibrary.pdf#page=24|url-status=dead}}</ref>
The IEEE 802.1Q tag, if present, is placed between the Source Address and the EtherType or Length fields. The first two bytes of the tag are the Tag Protocol Identifier (TPID) value of 0x8100. This is located in the same place as the EtherType/Length field in untagged frames, so an EtherType value of 0x8100 means the frame is tagged, and the true EtherType/Length is located after the Q-tag. The TPID is followed by two bytes containing the Tag Control Information (TCI) (the IEEE 802.1p priority ([[quality of service]]) and [[Virtual LAN|VLAN]] id). The Q-tag is followed by the rest of the frame, using one of the types described above.

However, hardware implementation of a logically right shifting CRC may use a left shifting [[Linear-feedback shift register#Galois LFSRs|Linear Feedback Shift Register]] as the basis for calculating the CRC, reversing the bits and resulting in a verify value of 0x38FB2284. Since the complementing of the CRC may be performed post calculation and during transmission, what remains in the hardware register is a non-complemented result, so the residue for a right shifting implementation would be the complement of 0x2144DF1C = 0xDEBB20E3, and for a left shifting implementation, the complement of 0x38FB2284 = 0xC704DD7B.

=== {{Anchor|EOF|EOD|End of frame}}End of frame – physical layer ===
The ''end of a frame'' is usually indicated by the end-of-data-stream symbol at the physical layer or by loss of the carrier signal; an example is [[10BASE-T]], where the receiving station detects the end of a transmitted frame by loss of the carrier. 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.<ref>{{cite book
| url = https://archive.org/details/ethernetdefiniti0000spur
| url-access = registration
| title = Ethernet: The Definitive Guide
| date = February 2000 | access-date = 2014-06-30
| author = Charles E. Spurgeon | publisher = O'Reilly
| pages = [https://archive.org/details/ethernetdefiniti0000spur/page/41 41], 47
| isbn = 9780596552824
}}</ref><ref>{{cite book
| title = 802.3-2018 – IEEE Standard for Ethernet
| section = 40.1.3.1 Physical Coding Sublayer (PCS)
| publisher = [[IEEE]]
| date = 2018-06-14
| isbn = 978-1-5044-5090-4
| doi = 10.1109/IEEESTD.2018.8457469}}</ref>

==={{Anchor|Interpacket gap}}Interpacket gap – physical layer===
[[Interpacket gap]] (IPG) is idle time between packets. After a packet has been sent, transmitters are required to transmit a minimum of 96 bits (12 octets) of idle line state before transmitting the next packet.

==Types==
{| class="wikitable floatright" style="text-align: center; margin-left: 1.5em; margin-right: 0;"
|+ Ethernet frame differentiation
|-
! Frame type !! Ethertype or length !! Payload start two bytes
|-
| Ethernet II || ≥ 1536 || Any
|-
| Novell raw IEEE 802.3 || ≤ 1500 || 0xFFFF
|-
| IEEE 802.2 LLC || ≤ 1500 || Other
|-
| IEEE 802.2 SNAP || ≤ 1500 || 0xAAAA
|}

There are several types of Ethernet frames:

* Ethernet II frame, or Ethernet Version 2,{{Efn|A version 1 Ethernet frame was used for early Ethernet prototypes and featured 8-bit MAC addresses and was never commercially deployed.}} or DIX frame is the most common type in use today, as it is often used directly by the Internet Protocol.
* [[Novell]] raw [[IEEE 802.3]] non-standard variation frame
* [[IEEE 802.2]] [[Logical Link Control]] (LLC) frame
* [[IEEE 802.2]] [[Subnetwork Access Protocol]] (SNAP) frame

The different frame types have different formats and [[Maximum transmission unit|MTU]] values but can coexist on the same physical medium. Differentiation between frame types is possible based on the table on the right.

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.<!--802.3as subsequently increased maximum frame size still further-->

The IEEE 802.1Q tag, if present, is placed between the Source Address and the EtherType or Length fields. The first two octets of the tag are the Tag Protocol Identifier (TPID) value of 0x8100. This is located in the same place as the EtherType/Length field in untagged frames, so an EtherType value of 0x8100 means the frame is tagged, and the true EtherType/Length is located after the Q-tag. The TPID is followed by two octets containing the Tag Control Information (TCI) (the IEEE 802.1p priority ([[quality of service]]) and VLAN id). The Q-tag is followed by the rest of the frame, using one of the types described above.


===Ethernet II===
===Ethernet II===
'''Ethernet II framing''' (also known as '''DIX Ethernet''', named after [[Digital Equipment Corporation|DEC]], [[Intel]] and [[Xerox]], the major participants in its design<ref>{{cite book |title=Drew Heywood's Windows 2000 Network Services |author=Drew Heywood |author2=Zubair Ahmad |publisher=Sams |year=2001 |isbn=0672317419 |page=53}}</ref>), defines the two-octet [[EtherType]] field in an Ethernet [[Frame (telecommunications)|frame]], preceded by destination and source MAC addresses, that identifies an [[upper layer protocol]] [[Encapsulation (networking)|encapsulating]] the frame data. For example, an EtherType value of 0x0800 signals that the frame contains an [[IPv4]] datagram. Likewise, an EtherType of 0x0806 indicates an [[Address Resolution Protocol|ARP]] frame, 0x8100 indicates an IEEE 802.1Q frame and 0x86DD indicates an [[IPv6]] frame.
'''Ethernet II framing''' (also known as '''DIX Ethernet''', named after [[Digital Equipment Corporation|DEC]], [[Intel]] and [[Xerox]], the major participants in its design<ref>{{cite book |title=Drew Heywood's Windows 2000 Network Services |author=Drew Heywood |author2=Zubair Ahmad |publisher=Sams |year=2001 |isbn=978-0-672-31741-5 |page=53}}</ref>), defines the two-octet [[EtherType]] field in an Ethernet [[Frame (telecommunications)|frame]], preceded by destination and source MAC addresses, that identifies an [[upper layer protocol]] [[Encapsulation (networking)|encapsulated]] by the frame data. Most notably, an EtherType value of 0x0800 indicates that the frame contains an [[IPv4]] datagram, 0x0806 indicates an [[Address Resolution Protocol|ARP]] datagram, and 0x86DD indicates an [[IPv6]] datagram. See {{Section link|EtherType|Values}} for more.


[[Image:Ethernet Type II Frame format.svg|thumb|center|700px|The most common Ethernet frame format, type II]]
As this industry-developed standard went through a formal [[IEEE]] standardization process, the EtherType field was changed to a (data) length field in the new 802.3 standard.<ref group=note>Original Ethernet packets define their length with the framing that surrounds it, rather than with an explicit length count.</ref> Since the packet recipient still needs to know how to interpret the packet, the standard required an IEEE 802.2 header to follow the length and specify the packet type. Many years later, the 802.3x-1997 standard, and later versions of the 802.3 standard, formally approved of both types of framing. In practice, both formats are in wide use,{{Citation needed|date=March 2011}} with original Ethernet framing the most common in Ethernet local area networks, due to its simplicity and lower overhead.


As this industry-developed standard went through a formal [[IEEE]] standardization process, the EtherType field was changed to a (data) length field in the new 802.3 standard.{{Efn|Original Ethernet frames define their length with the framing that surrounds it, rather than with an explicit length count.}} 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. Many years later, the 802.3x-1997 standard, and later versions of the 802.3 standard, formally approved of both types of framing. Ethernet II framing is the most common in Ethernet local area networks, due to its simplicity and lower overhead.
In order to allow some packets using Ethernet v2 framing and some packets using the original version of 802.3 framing to be used on the same Ethernet segment, EtherType values must be greater than or equal to 1536 (0x0600). That value was chosen because the maximum length of the data field of an Ethernet 802.3 frame is 1500 bytes (0x05DC). Thus if the field's value is greater than or equal to 1536, the frame must be an Ethernet v2 frame, with that field being a type field.<ref>{{cite book|author=LAN MAN Standards Committee of the IEEE Computer Society|title=IEEE Std 802.3x-1997 and IEEE Std 802.3y-1997|publisher=The Institute of Electrical and Electronics Engineers, Inc.|date=20 March 1997|pages=28–31}}</ref> If it's less than or equal to 1500, it must be an IEEE 802.3 frame, with that field being a length field. Values between 1500 and 1536, exclusive, are undefined.<ref>IEEE Std 802.3-2005, 3.2.6</ref> This convention allows software to determine whether a frame is an Ethernet II frame or an IEEE 802.3 frame, allowing the coexistence of both standards on the same physical medium.


In order to allow some frames using Ethernet II framing and some using the original version of 802.3 framing to be used on the same Ethernet segment, EtherType values must be greater than or equal to 1536 (0x0600). That value was chosen because the maximum length of the payload field of an Ethernet 802.3 frame is 1500 octets (0x05DC). Thus if the field's value is greater than or equal to 1536, the frame must be an Ethernet II frame, with that field being a type field.<ref>{{cite book|author=LAN MAN Standards Committee of the IEEE Computer Society|title=IEEE Std 802.3x-1997 and IEEE Std 802.3y-1997|publisher=The Institute of Electrical and Electronics Engineers, Inc.|date=20 March 1997|pages=28–31}}</ref> If it's less than or equal to 1500, it must be an IEEE 802.3 frame, with that field being a length field. Values between 1500 and 1536, exclusive, are undefined.<ref>{{cite book|doi=10.1109/IEEESTD.2018.8457469|section=3.2.6 Length/Type field|title=802.3-2018 – IEEE Standard for Ethernet|date=2018-06-14|isbn=978-1-5044-5090-4}}</ref> This convention allows software to determine whether a frame is an Ethernet II frame or an IEEE 802.3 frame, allowing the coexistence of both standards on the same physical medium.
===802.2 LLC===
Some protocols, particularly those designed for the [[OSI stack]], operate directly on top of 802.2 LLC, which provides both datagram and connection-oriented network services.


===Novell raw IEEE 802.3===
The 802.2 variants of Ethernet are not in widespread use on common networks currently, with the exception of large corporate Netware installations that have not yet migrated to Netware over IP. In the past, many corporate networks supported 802.2 Ethernet to support transparent translating bridges between Ethernet and IEEE 802.5 Token Ring or FDDI networks. The most common framing type used today is Ethernet Version 2, as it is used by most Internet Protocol-based networks, with its [[EtherType]] set to 0x0800 for [[IPv4]] and 0x86DD for [[IPv6]].
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. They did not use any LLC header but started the IPX packet directly after the length field. 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.


[[Novell NetWare]] used this frame type by default until the mid-nineties, and since NetWare was then very widespread, while IP was not, at some point in time most of the world's Ethernet traffic ran over "raw" 802.3 carrying IPX. Since NetWare 4.10, NetWare defaults to IEEE 802.2 with LLC (NetWare Frame Type Ethernet_802.2) when using IPX.<ref>{{cite newsgroup | author=Don Provan | title=Ethernet Framing | date=17 September 1993 | newsgroup=comp.sys.novell | message-id=1993Sep17.190654.13335@novell.com | url=https://groups.google.com/group/bit.listserv.novell/browse_thread/thread/d00a24530625714c }} ([http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html HTML-formatted version] {{webarchive|url=https://web.archive.org/web/20150418013816/http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html |date=18 April 2015 }}) &nbsp;— a classic series of Usenet postings by Novell's Don Provan that have found their way into numerous FAQs and are widely considered the definitive answer to the Novell Frame Type usage.</ref>
There exists an [[Internet standard]] for encapsulating IP version 4 traffic in IEEE 802.2 frames with LLC/SNAP headers.<ref>RFC 1042</ref> It is almost never implemented on Ethernet (although it is used on [[FDDI]] and on [[token ring]], [[IEEE 802.11]], and other [[IEEE 802]] networks). IP traffic cannot be encapsulated in IEEE 802.2 LLC frames without SNAP because, although there is an LLC protocol type for IP, there is no LLC protocol type for [[Address Resolution Protocol|ARP]]. IP Version 6 can also be transmitted over Ethernet using IEEE 802.2 with LLC/SNAP, but, again, that's almost never used (although LLC/SNAP encapsulation of IPv6 is used on IEEE 802 networks).


===Subnetwork Access Protocol===
===IEEE 802.2 LLC===
{{Main|IEEE 802.2}}
By examining the 802.2 LLC header, it is possible to determine whether it is followed by a SNAP header. The LLC header includes two additional eight-bit address fields, called ''service access points'' (SAPs) in OSI terminology; when both source and destination SAP are set to the value 0xAA, the SNAP service is requested. The SNAP header allows EtherType values to be used with all IEEE 802 protocols, as well as supporting private protocol ID spaces. In IEEE 802.3x-1997, the IEEE Ethernet standard was changed to explicitly allow the use of the 16-bit field after the MAC addresses to be used as a length field or a type field.
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.


IEEE 802.2 LLC encapsulation is not in widespread use on common networks currently, with the exception of large corporate [[NetWare]] installations that have not yet migrated to NetWare over [[Internet Protocol|IP]]. In the past, many corporate networks used IEEE 802.2 to support transparent translating bridges between Ethernet and [[Token Ring]] or [[FDDI]] networks.
[[Mac OS]] uses 802.2/SNAP framing for the [[AppleTalk]] V2 protocol suite on Ethernet ("EtherTalk")


There exists an [[Internet standard]] for encapsulating IPv4 traffic in IEEE 802.2 LLC SAP/SNAP frames.<ref>
===Novell raw 802.3===
{{cite IETF
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. They did not use any LLC header but started the IPX packet directly after the length field. This does not conform to the IEEE 802.3 standard, but since IPX has always FF at the first two bytes (while in IEEE 802.2 LLC that pattern is theoretically possible but extremely unlikely), in practice this mostly coexists on the wire with other Ethernet implementations, with the notable exception of some early forms of [[DECnet]] which got confused by this.
| rfc = 1042
| title = A Standard for the Transmission of IP Datagrams over IEEE 802 Networks
| publisher = Network Working Group of the IETF
| date = February 1988
}}
</ref> It is almost never implemented on Ethernet, although it is used on FDDI, Token Ring, [[IEEE 802.11]] (with the exception of the [[IEEE 802.11p|5.9 GHz band]], where it uses EtherType)<ref>{{Cite book|title=IEEE Std 802.11-2016: Part 11: Wireless LAN Medium Access Control IEEE (MAC) and Physical Layer (PHY) Specifications.|last=Computer Society|first=IEEE|publisher=IEEE|year=2016|location=New York, NY|pages=249}}</ref> and other [[IEEE 802]] LANs. IPv6 can also be transmitted over Ethernet using IEEE 802.2 LLC SAP/SNAP, but, again, that's almost never used.


===IEEE 802.2 SNAP===
[[Novell NetWare]] used this frame type by default until the mid nineties, and since Netware was very widespread back then, while IP was not, at some point in time most of the world's Ethernet traffic ran over "raw" 802.3 carrying IPX. Since Netware 4.10, Netware now defaults to IEEE 802.2 with LLC (Netware Frame Type Ethernet_802.2) when using IPX. (See "Ethernet Framing" in References for details.)
{{Main|Subnetwork Access Protocol}}
By examining the 802.2 LLC header, it is possible to determine whether it is followed by a SNAP header. The LLC header includes two eight-bit address fields, called ''service access points'' (SAPs) in OSI terminology; when both source and destination SAP are set to the value 0xAA, the LLC header is followed by a SNAP header. The SNAP header allows EtherType values to be used with all IEEE 802 protocols, as well as supporting private protocol ID spaces.

In IEEE 802.3x-1997, the IEEE Ethernet standard was changed to explicitly allow the use of the 16-bit field after the MAC addresses to be used as a length field or a type field.

The [[AppleTalk]] v2 protocol suite on Ethernet ("[[AppleTalk#EtherTalk, TokenTalk and AppleShare|EtherTalk]]") uses IEEE 802.2 LLC + SNAP encapsulation.


==Maximum throughput==
==Maximum throughput==
We may calculate the maximum efficiency or [[channel utilization]] for Ethernet:
We may calculate the [[protocol overhead]] for Ethernet as a percentage (packet size including IPG)
:<math>\text{maximum efficiency} = \frac{\text{Payload size}}{\text{Frame size}}</math> Maximum efficiency is achieved with largest allowed payload size and is
:<math>\text{Protocol overhead} = \frac{\text{Packet size} - \text{Payload size}}{\text{Packet size}}</math>
We may calculate the ''protocol efficiency'' for Ethernet
:<math>\frac{1500}{1538} = 97.53%</math>
:<math>\text{Protocol efficiency} = \frac{\text{Payload size}}{\text{Packet size}}</math>
for untagged Ethernet packets, since the frame size is maximum 1500 byte payload + 8 byte preamble + 14 byte header + 4 Byte trailer+ minimum interframe gap corresponding to 12 bytes = 1538 bytes. The maximum efficiency is
Maximum efficiency is achieved with largest allowed payload size and is:
:<math>\frac{1500}{1542} = 97.28%</math> when 802.1Q VLAN tagging is used.
:<math>\frac{1500}{1538} = 97.53\%</math>
for untagged frames, since the packet size is maximum 1500 octet payload + 8 octet preamble + 14 octet header + 4 octet trailer + minimum interpacket gap corresponding to 12 octets = 1538 octets. The maximum efficiency is:
:<math>\frac{1500}{1542} = 97.28\%</math>
when 802.1Q VLAN tagging is used.


The [[throughput]] may be calculated from the efficiency:
The [[throughput]] may be calculated from the efficiency
:<math>\text{throughput} = \text{efficiency} \times \text{Net bit rate}\,\!</math>,
:<math>\text{Throughput} = \text{Efficiency} \times \text{Net bit rate}\,\!</math>,
where the physical layer [[net bit rate]] (the wire bit rate) depends on the [[Ethernet physical layer]] standard, and may be 10 Mbit/s, 100 Mbit/s, 1 Gbit/s or 10 Gbit/s. Maximum throughput for 100BASE-TX Ethernet with maximum payload size (1500 bytes) is consequently 97.53 Mbit/s without 802.1Q, and 97.28 Mbit/s with 802.1Q.
where the physical layer [[net bit rate]] (the wire bit rate) depends on the [[Ethernet physical layer]] standard, and may be {{nowrap|10 Mbit/s}}, {{nowrap|100 Mbit/s}}, {{nowrap|1 Gbit/s}} or {{nowrap|10 Gbit/s}}. [[Maximum throughput]] for 100BASE-TX Ethernet is consequently {{nowrap|97.53 Mbit/s}} without 802.1Q, and {{nowrap|97.28 Mbit/s}} with 802.1Q.


[[Channel utilization]] is a concept often confused with protocol efficiency. It considers only the use of the channel disregarding the nature of the data transmitted – either payload or overhead. At the physical layer, the link channel and equipment do not know the difference between data and control frames. We may calculate the [[channel utilization]]:
==Runt frames==<!--[[Runt frame]] redirects here-->

A runt frame is an Ethernet frame that is less than the IEEE 802.3<!-- or IEEE 802.2?? --> minimum length of 64 bytes. Possible causes are collision, underruns, bad network card or software.<ref>{{cite web|title=Glossary of Terms - R (Zarlink Semiconductor)|url=http://www.zarlink.com/zarlink/hs/7805.htm}} 071227 products.zarlink.com{{Dead link|date=October 2010}}</ref>
:<math>\text{Channel utilization} = \frac{\text{Time spent transmitting data}}{\text{Total time}}</math>

The total time considers the round trip time along the channel, the processing time in the hosts and the time transmitting data and acknowledgements. The time spent transmitting data includes data and acknowledgements.

=={{Anchor|RUNT-FRAMES}}Runt frames==
A runt frame is an Ethernet frame that is less than the IEEE 802.3's minimum length of 64 octets. Runt frames are most commonly caused by [[Collision (telecommunications)|collisions]]; other possible causes are a malfunctioning [[network card]], [[buffer underrun]], [[duplex mismatch]] or software issues.<ref>
{{cite web
| url = http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1904.html
| title=Troubleshooting Ethernet
| publisher = Cisco Systems
| access-date = 2016-08-13
}}
</ref>


==Notes==
==Notes==
{{Notelist}}
{{Reflist|group=note}}


==References==
==References==
{{Reflist}}
{{Reflist}}


==Further reading==
{{Use dmy dates|date=October 2010}}
{{Wikiversity|Topic:Web Science/Part1: Foundations of the web/Internet Architecture/Ethernet}}

<gallery>
File:How to build an Ethernet Frame.webm|Video which explains how to build an Ethernet Frame
File:Minimum Frame Length in Ethernet explained.webm|Minimum Frame Length in Ethernet explained
</gallery>

{{Ethernet}}


{{DEFAULTSORT:Ethernet Frame}}
{{DEFAULTSORT:Ethernet Frame}}
[[Category:Ethernet]]
[[Category:Articles containing video clips]]
[[Category:Ethernet|Frame]]


[[id:Ethernet II]]
[[de:Datenframe]]
[[pt:DIX]]
[[sv:DIX]]

Latest revision as of 17:02, 21 November 2024

Ethernet packet. The SFD (start frame delimiter) marks the end of the packet preamble. It is immediately followed by the Ethernet frame, which starts with the destination MAC address.[1]

In computer networking, an Ethernet frame is a data link layer protocol data unit and uses the underlying Ethernet physical layer transport mechanisms. In other words, a data unit on an Ethernet link transports an Ethernet frame as its payload.[2]

An Ethernet frame is preceded by a preamble and start frame delimiter (SFD), which are both part of the Ethernet packet at the physical layer. Each Ethernet frame starts with an Ethernet header, which contains destination and source MAC addresses as its first two fields. The middle section of the frame is payload data including any headers for other protocols (for example, Internet Protocol) carried in the frame. The frame ends with a frame check sequence (FCS), which is a 32-bit cyclic redundancy check used to detect any in-transit corruption of data.

Structure

[edit]

A data packet on the wire and the frame as its payload consist of binary data. Ethernet transmits data with the most-significant octet (byte) first; within each octet, however, the least-significant bit is transmitted first.[a]

The internal structure of an Ethernet frame is specified in IEEE 802.3.[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.[b] Some implementations of Gigabit Ethernet and other higher-speed variants of Ethernet support larger frames, known as jumbo frames.

802.3 Ethernet packet and frame structure
Layer Preamble Start frame delimiter (SFD) MAC destination MAC source 802.1Q tag (optional) Ethertype (Ethernet II) or length (IEEE 802.3) Payload Frame check sequence (32‑bit CRC) Interpacket gap (IPG)
Length (octets) 7 1 6 6 (4) 2 42–1500[c] 4 12
Layer 2 Ethernet frame (not part of the frame) ← 64–1522 octets → (not part of the frame)
Layer 1 Ethernet packet & IPG ← 72–1530 octets → ← 12 octets →

The optional 802.1Q tag consumes additional space in the frame. Field sizes for this option are shown in brackets in the table above. IEEE 802.1ad (Q-in-Q) allows for multiple tags in each frame. This option is not illustrated here.

Ethernet packet – physical layer

[edit]

Preamble and start frame delimiter

[edit]

An Ethernet packet starts with a seven-octet (56-bit) preamble and one-octet (8-bit) start frame delimiter (SFD).[d] The preamble bit values alternate 1 and 0, allowing receivers to synchronize their clock at the bit-level with the transmitter. The preamble is followed by the SFD which ends with a 1 instead of 0, to break the bit pattern of the preamble and signal the start of the actual frame.[1]: section 4.2.5 

Physical layer transceiver circuitry (PHY for short) is required to connect the Ethernet MAC to the physical medium. 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:

Preamble and SFD representations as bits, decimal, bytes, and nibbles
Representation 56-bit (7-byte) Preamble SFD byte
uncoded on-the-wire bit pattern transmitted from left to right (used by Ethernet variants transmitting serial bits instead of larger symbols)[1]: sections 4.2.5 and 3.2.2  10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011
decimal in Ethernet LSb-first ordering[1]: sections 3.2.2, 3.3 and 4.2.6  85 85 85 85 85 85 85 213
hexadecimal LSb-first bytes for 8-bit wide busses

(GMII bus for Gigabit Ethernet transceivers)

0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5
hexadecimal LSb-first nibbles for 4-bit wide busses (MII bus for Fast Ethernet or RGMII for gigabit transceivers) 0x5 0x5 0x5 0x5 0x5 0x5 0x5 0x5 0x5 0x5 0x5 0x5 0x5 0x5 0x5 0xD

The SFD is immediately followed by the destination MAC address, which is the first field in an Ethernet frame.

[edit]
[edit]

The header features destination and source MAC addresses (each six octets in length), the EtherType field and, optionally, an IEEE 802.1Q tag or IEEE 802.1ad tag.

The EtherType field is two octets long and it can be used for two different purposes. Values of 1500 and below mean that it is used to indicate the size of the payload in octets, while values of 1536 and above indicate that it is used as an EtherType, to indicate which protocol is encapsulated in the payload of the frame. When used as EtherType, the length of the frame is determined by the location of the interpacket gap and valid frame check sequence (FCS).

The IEEE 802.1Q tag or IEEE 802.1ad tag, if present, is a four-octet field that indicates virtual LAN (VLAN) membership and IEEE 802.1p priority. The first two octets of the tag are called the Tag Protocol IDentifier (TPID) and double as the EtherType field indicating that the frame is either 802.1Q or 802.1ad tagged. 802.1Q uses a TPID of 0x8100. 802.1ad uses a TPID of 0x88a8.

Payload

[edit]

Payload is a variable-length field. Its minimum size is governed by a requirement for a minimum frame transmission of 64 octets (bytes).[e] With header and FCS taken into account, the minimum payload is 42 octets when an 802.1Q tag is present[f] and 46 octets when absent. When the actual payload is less than the minimum, padding octets are added accordingly. IEEE standards specify a maximum payload of 1500 octets. Non-standard jumbo frames allow for larger payloads on networks built to support them.

Frame check sequence

[edit]

The frame check sequence (FCS) is a four-octet cyclic redundancy check (CRC) that allows detection of corrupted data within the entire frame as received on the receiver side. According to the standard, the FCS value is computed as a function of the protected MAC frame fields: source and destination address, length/type field, MAC client data and padding (that is, all fields except the FCS).

Per the standard, this computation is done using the left shifting CRC-32 (polynomial = 0x4C11DB7, initial CRC = 0xFFFFFFFF, CRC is post complemented, verify value = 0x38FB2284) algorithm. The standard states that data is transmitted least significant bit (bit 0) first, while the FCS is transmitted most significant bit (bit 31) first.[1]: section 3.2.9  An alternative is to calculate a CRC using the right shifting CRC-32 (polynomial = 0xEDB88320, initial CRC = 0xFFFFFFFF, CRC is post complemented, verify value = 0x2144DF1C), which will result in a CRC that is a bit reversal of the FCS, and transmit both data and the CRC least significant bit first, resulting in identical transmissions.

The standard states that the receiver should calculate a new FCS as data is received and then compare the received FCS with the FCS the receiver has calculated. 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. (The result is non-zero because the CRC is post complemented during CRC generation). Since the data is received least significant bit first, and to avoid having to buffer octets of data, the receiver typically uses the right shifting CRC-32. This makes the "verify" value (sometimes called "magic check") 0x2144DF1C.[5]

However, hardware implementation of a logically right shifting CRC may use a left shifting Linear Feedback Shift Register as the basis for calculating the CRC, reversing the bits and resulting in a verify value of 0x38FB2284. Since the complementing of the CRC may be performed post calculation and during transmission, what remains in the hardware register is a non-complemented result, so the residue for a right shifting implementation would be the complement of 0x2144DF1C = 0xDEBB20E3, and for a left shifting implementation, the complement of 0x38FB2284 = 0xC704DD7B.

End of frame – physical layer

[edit]

The end of a frame is usually indicated by the end-of-data-stream symbol at the physical layer or by loss of the carrier signal; an example is 10BASE-T, where the receiving station detects the end of a transmitted frame by loss of the carrier. 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.[6][7]

Interpacket gap – physical layer

[edit]

Interpacket gap (IPG) is idle time between packets. After a packet has been sent, transmitters are required to transmit a minimum of 96 bits (12 octets) of idle line state before transmitting the next packet.

Types

[edit]
Ethernet frame differentiation
Frame type Ethertype or length Payload start two bytes
Ethernet II ≥ 1536 Any
Novell raw IEEE 802.3 ≤ 1500 0xFFFF
IEEE 802.2 LLC ≤ 1500 Other
IEEE 802.2 SNAP ≤ 1500 0xAAAA

There are several types of Ethernet frames:

The different frame types have different formats and MTU values but can coexist on the same physical medium. Differentiation between frame types is possible based on the table on the right.

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 first two octets of the tag are the Tag Protocol Identifier (TPID) value of 0x8100. This is located in the same place as the EtherType/Length field in untagged frames, so an EtherType value of 0x8100 means the frame is tagged, and the true EtherType/Length is located after the Q-tag. The TPID is followed by two octets containing the Tag Control Information (TCI) (the IEEE 802.1p priority (quality of service) and VLAN id). The Q-tag is followed by the rest of the frame, using one of the types described above.

Ethernet II

[edit]

Ethernet II framing (also known as DIX Ethernet, named after DEC, Intel and Xerox, the major participants in its design[8]), defines the two-octet EtherType field in an Ethernet frame, preceded by destination and source MAC addresses, that identifies an upper layer protocol encapsulated by the frame data. Most notably, an EtherType value of 0x0800 indicates that the frame contains an IPv4 datagram, 0x0806 indicates an ARP datagram, and 0x86DD indicates an IPv6 datagram. See EtherType § Values for more.

The most common Ethernet frame format, type II

As this industry-developed standard went through a formal IEEE standardization process, the EtherType field was changed to a (data) length field in the new 802.3 standard.[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. Many years later, the 802.3x-1997 standard, and later versions of the 802.3 standard, formally approved of both types of framing. Ethernet II framing is the most common in Ethernet local area networks, due to its simplicity and lower overhead.

In order to allow some frames using Ethernet II framing and some using the original version of 802.3 framing to be used on the same Ethernet segment, EtherType values must be greater than or equal to 1536 (0x0600). That value was chosen because the maximum length of the payload field of an Ethernet 802.3 frame is 1500 octets (0x05DC). Thus if the field's value is greater than or equal to 1536, the frame must be an Ethernet II frame, with that field being a type field.[9] If it's less than or equal to 1500, it must be an IEEE 802.3 frame, with that field being a length field. Values between 1500 and 1536, exclusive, are undefined.[10] This convention allows software to determine whether a frame is an Ethernet II frame or an IEEE 802.3 frame, allowing the coexistence of both standards on the same physical medium.

Novell raw IEEE 802.3

[edit]

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. They did not use any LLC header but started the IPX packet directly after the length field. 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.

Novell NetWare used this frame type by default until the mid-nineties, and since NetWare was then very widespread, while IP was not, at some point in time most of the world's Ethernet traffic ran over "raw" 802.3 carrying IPX. Since NetWare 4.10, NetWare defaults to IEEE 802.2 with LLC (NetWare Frame Type Ethernet_802.2) when using IPX.[11]

IEEE 802.2 LLC

[edit]

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.

IEEE 802.2 LLC encapsulation is not in widespread use on common networks currently, with the exception of large corporate NetWare installations that have not yet migrated to NetWare over IP. In the past, many corporate networks used IEEE 802.2 to support transparent translating bridges between Ethernet and Token Ring or FDDI networks.

There exists an Internet standard for encapsulating IPv4 traffic in IEEE 802.2 LLC SAP/SNAP frames.[12] It is almost never implemented on Ethernet, although it is used on FDDI, Token Ring, IEEE 802.11 (with the exception of the 5.9 GHz band, where it uses EtherType)[13] and other IEEE 802 LANs. IPv6 can also be transmitted over Ethernet using IEEE 802.2 LLC SAP/SNAP, but, again, that's almost never used.

IEEE 802.2 SNAP

[edit]

By examining the 802.2 LLC header, it is possible to determine whether it is followed by a SNAP header. The LLC header includes two eight-bit address fields, called service access points (SAPs) in OSI terminology; when both source and destination SAP are set to the value 0xAA, the LLC header is followed by a SNAP header. The SNAP header allows EtherType values to be used with all IEEE 802 protocols, as well as supporting private protocol ID spaces.

In IEEE 802.3x-1997, the IEEE Ethernet standard was changed to explicitly allow the use of the 16-bit field after the MAC addresses to be used as a length field or a type field.

The AppleTalk v2 protocol suite on Ethernet ("EtherTalk") uses IEEE 802.2 LLC + SNAP encapsulation.

Maximum throughput

[edit]

We may calculate the protocol overhead for Ethernet as a percentage (packet size including IPG)

We may calculate the protocol efficiency for Ethernet

Maximum efficiency is achieved with largest allowed payload size and is:

for untagged frames, since the packet size is maximum 1500 octet payload + 8 octet preamble + 14 octet header + 4 octet trailer + minimum interpacket gap corresponding to 12 octets = 1538 octets. The maximum efficiency is:

when 802.1Q VLAN tagging is used.

The throughput may be calculated from the efficiency

,

where the physical layer net bit rate (the wire bit rate) depends on the Ethernet physical layer standard, and may be 10 Mbit/s, 100 Mbit/s, 1 Gbit/s or 10 Gbit/s. Maximum throughput for 100BASE-TX Ethernet is consequently 97.53 Mbit/s without 802.1Q, and 97.28 Mbit/s with 802.1Q.

Channel utilization is a concept often confused with protocol efficiency. It considers only the use of the channel disregarding the nature of the data transmitted – either payload or overhead. At the physical layer, the link channel and equipment do not know the difference between data and control frames. We may calculate the channel utilization:

The total time considers the round trip time along the channel, the processing time in the hosts and the time transmitting data and acknowledgements. The time spent transmitting data includes data and acknowledgements.

Runt frames

[edit]

A runt frame is an Ethernet frame that is less than the IEEE 802.3's minimum length of 64 octets. Runt frames are most commonly caused by collisions; other possible causes are a malfunctioning network card, buffer underrun, duplex mismatch or software issues.[14]

Notes

[edit]
  1. ^ The frame check sequence (FCS) uses a different bit ordering.[3]
  2. ^ The bit patterns in the preamble and start of frame delimiter are written as bit strings, with the first bit transmitted on the left (not as octet values, which in Ethernet are transmitted least significant bit(s) first). This notation matches the one used in the IEEE 802.3 standard.
  3. ^ Payload can be 42 octets if an 802.1Q tag is present. Minimum is 46 octets without.
  4. ^ Preamble and start frame delimiter are not displayed by packet sniffing software because these bits are stripped away at OSI layer 1 by the network interface controller (NIC) before being passed on to the OSI layer 2, which is where packet sniffers collect their data. There are layer-2 sniffers that can capture and display the preamble and start frame delimiter, but they are expensive and mainly used to detect problems related to physical connectivity.
  5. ^ Minimum payload size is dictated by the 512-bit slot time used for collision detection in the Ethernet LAN architecture.
  6. ^ Both 42 and 46 octet minimums are valid when 802.1Q is present.[4]
  7. ^ A version 1 Ethernet frame was used for early Ethernet prototypes and featured 8-bit MAC addresses and was never commercially deployed.
  8. ^ Original Ethernet frames define their length with the framing that surrounds it, rather than with an explicit length count.

References

[edit]
  1. ^ a b c d e 802.3-2018 – IEEE Standard for Ethernet. IEEE. 14 June 2018. doi:10.1109/IEEESTD.2018.8457469. ISBN 978-1-5044-5090-4.
  2. ^ a b "3.1.1 Packet format". 802.3-2018 – IEEE Standard for Ethernet. IEEE. 14 June 2018. doi:10.1109/IEEESTD.2018.8457469. ISBN 978-1-5044-5090-4.
  3. ^ 802.3-2018 – IEEE Standard for Ethernet. IEEE. 14 June 2018. Section 3.3 and annex 31A. doi:10.1109/IEEESTD.2018.8457469. ISBN 978-1-5044-5090-4. Opcodes are transmitted high-order octet first. Within each octet, bits are transmitted least-significant bit first. [...] Each octet of the MAC frame, with the exception of the FCS, is transmitted least significant bit first.
  4. ^ "Annex G". IEEE Standard for Local and metropolitan area networks--Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks. doi:10.1109/IEEESTD.2011.6009146. ISBN 978-0-7381-6708-4.
  5. ^ "Specification of CRC Routines V4.5.0 R4.1 Rev 3" (PDF). AUTOSAR. p. 24. Archived from the original (PDF) on 11 June 2020. Retrieved 30 January 2020.
  6. ^ Charles E. Spurgeon (February 2000). Ethernet: The Definitive Guide. O'Reilly. pp. 41, 47. ISBN 9780596552824. Retrieved 30 June 2014.
  7. ^ "40.1.3.1 Physical Coding Sublayer (PCS)". 802.3-2018 – IEEE Standard for Ethernet. IEEE. 14 June 2018. doi:10.1109/IEEESTD.2018.8457469. ISBN 978-1-5044-5090-4.
  8. ^ Drew Heywood; Zubair Ahmad (2001). Drew Heywood's Windows 2000 Network Services. Sams. p. 53. ISBN 978-0-672-31741-5.
  9. ^ LAN MAN Standards Committee of the IEEE Computer Society (20 March 1997). IEEE Std 802.3x-1997 and IEEE Std 802.3y-1997. The Institute of Electrical and Electronics Engineers, Inc. pp. 28–31.
  10. ^ "3.2.6 Length/Type field". 802.3-2018 – IEEE Standard for Ethernet. 14 June 2018. doi:10.1109/IEEESTD.2018.8457469. ISBN 978-1-5044-5090-4.
  11. ^ Don Provan (17 September 1993). "Ethernet Framing". Newsgroupcomp.sys.novell. Usenet: 1993Sep17.190654.13335@novell.com. (HTML-formatted version Archived 18 April 2015 at the Wayback Machine)  — a classic series of Usenet postings by Novell's Don Provan that have found their way into numerous FAQs and are widely considered the definitive answer to the Novell Frame Type usage.
  12. ^ A Standard for the Transmission of IP Datagrams over IEEE 802 Networks. Network Working Group of the IETF. February 1988. doi:10.17487/RFC1042. RFC 1042.
  13. ^ Computer Society, IEEE (2016). IEEE Std 802.11-2016: Part 11: Wireless LAN Medium Access Control IEEE (MAC) and Physical Layer (PHY) Specifications. New York, NY: IEEE. p. 249.
  14. ^ "Troubleshooting Ethernet". Cisco Systems. Retrieved 13 August 2016.

Further reading

[edit]