Talk:Ethernet frame

Source

Material in this article originally appeared in Ethernet. --Kvng (talk) 02:59, 7 September 2010 (UTC)

Payload

is it really 46-1500 ? Because I beleive it should be 64-1500, since 64 is one of those 2^x numbers and 46 isn't. Correct me if I'm wrong. —Preceding unsigned comment added by 95.176.132.154 (talk) 20:42, 23 March 2011 (UTC)

I noticed the CRC is located after a payload of non-fixed size and this size is not specified in the header. How can a receiver know if it has reached the CRC or not and what if a payload just looks like the interpacket gap ?Pcdwarf (talk) 13:51, 20 June 2014 (UTC)

Hello there! That's a very good question, to which I don't have a definite answer – at least not yet. Please have a look at this forum thread, which pretty much makes sense. Also, please have a look at pages 41 and 47 in Ethernet: The Definitive Guide, which are backing explanation from the forum thread. What's left is to explain how it all works for variants of Ethernet before the Fast Ethernet. By sensing for the carrier presence, maybe? Perhaps other editors will chime in. — Dsimic (talk | contribs) 09:42, 24 June 2014 (UTC)

Although older protocols use the EtherType/Length field for indicating the size, most commonly used protocols/EtherTypes rely on the physical layer to indicate the end of a frame/packet by sending a special symbol not used in payload data. The exact method varies with the physical layer type. This should probably be added to the article one day... Zac67 (talk) 20:58, 24 June 2014 (UTC)

Yeah, but what about older versions of Ethernet, in case EtherType/Length field is used for EtherType and not for the payload length? What's used in that case for determining the payload length? — Dsimic (talk | contribs) 22:33, 24 June 2014 (UTC)

The length field is redundant since layer 1 signalling indicates the end of a frame. Essentially, this is just the idle phase kicking in (interpacket gap) but several physical layers use additional end of data/end of stream symbols or sequences. Note that the framing options are always the same, regardless of the physical layer. E.g., you can run Ethernet II frames without Length field on 10BASE5. Zac67 (talk) 06:30, 25 June 2014 (UTC)

Totally makes sense, thank you. Regarding the additional "end of data" marks at the physical layer, the one used through Gigabit Ethernet's 8b/10b encoding might be an example. — Dsimic (talk | contribs) 08:10, 25 June 2014 (UTC)

Wrongful edits

I discovered that 121.241.0.148 (TATA Communications in India) specified the 10/100 PHY nibble to 10-bits. Seems there are some that put in data in these very technical pages that is simply wrong. Reason unknown. But please watch for these kind of "edits" that easily remain undiscovered for some time.Electron9 (talk) 20:41, 15 May 2011 (UTC)

It's sneaky vandalism and it can sometimes be difficult to spot. --Tothwolf (talk) 21:01, 15 May 2011 (UTC)

I suspect this is more a case of the uneducated editing facts they actually know too little about.Electron9 (talk) 03:26, 16 May 2011 (UTC)

That's possible too, which is why a citation is always a good idea. --Tothwolf (talk) 06:13, 16 May 2011 (UTC)

The vandalism/error was only there for 2 days. Not so difficult to spot in a diff. IME 50% of it is with good intention. --Kvng (talk) 17:23, 18 May 2011 (UTC)

Dated

This is a bit misleading. It describes what I think is the circa 1980 variant of Ethernet, roughly 10BASE-5. There have been many many physical layers defined in the 30 years since then with variations on this, especially the preamble. This is hinted a little but need to be more clear. W Nowicki (talk) 20:43, 5 July 2011 (UTC)

If you're talking about the preamble, Ethernet_frame#Preamble_and_Start_Frame_Delimiter discusses Ethernet variants up to gigabit Ethernet - not dated enough to warrant tagging with {{out of date}}. 10-gigabit Ethernet should be discussed. WiFi uses a different frame format and that should be mentioned. --Kvng (talk) 13:20, 7 July 2011 (UTC)

Oh sure, I find such tags annoying myself. Perhaps I should say incomplete. In fact, without resorting to opinion we should say something like the frame structure has survived for an amazing time, through many decades and orders of magnitude of speeds etc. with only minor changes. W Nowicki (talk) 22:51, 9 July 2011 (UTC)

Byte Order

There is no mention of the byte order of multi-byte fields such as EtherType or Length. Inmarket (talk) 00:43, 20 March 2012 (UTC)

{{done} --Kvng (talk) 14:23, 20 March 2012 (UTC)

Ambiguity on Payload vs Frame Size

This sentence: "The table below shows the complete Ethernet frame, as transmitted, for the MTU of 1500 octets." leaves open the possibility of understanding that the complete frame has a MTU of 1500 instead of the payload only. Adjusting the wording to be clear. Buchs (talk) 21:57, 15 November 2012 (UTC)

Ethernet payload size according to IEEE 802.3

The Payload of an Ethernet frame is 46-1500 bytes, not 42-1500. The presence of a VLAN tag does not change the payload. IEEE 802.3 defines minFrameSize as 64 octets and padSize as the following: padSize = ...; {In bits, = max (0, minFrameSize – (2 × addressSize + lengthOrTypeSize + clientDataSize + crcSize))} Thus, the payload is independent from the presence of a VLAN tag. A VLAN tag merely increases the length of the whole frame by 4 bytes.

Please do not change this back again to 42-1500 as this is incorrect. — Preceding unsigned comment added by Nogupry (talk • contribs) 14:16, 20 August 2013 (UTC)

lengthOrTypeSize is 2 for frames without 802.1Q and 4 for frames with so minimum size is dependent on presence of 802.1Q. The overall requirement is that the transmission from end of start of frame delimiter to end of FCS is not less than 512 bit periods. This is required for reliable collision detection on legacy networks. ~KvnG 15:10, 24 August 2013 (UTC)

Comment: --Nogupry (talk) 19:21, 28 August 2013 (UTC) This is not how Ethernet works.

lengthOrTypeSize is a constant of 16 bits=2 bytes. It is 2 bytes for both untagged and tagged frames. If your argument was correct the payload difference between tagged and untagged frames would be 2 (44 vs. 46 bits minimum payload) or 6 (2+4) (40 vs. 46 bits minimum payload), not 42 vs. 46 bits minimum payload as you have stated).

There would be serious problems if the payload size was dependent on the presence of a VLAN tag. Consider the following two cases with traffic behavior in an Ethernet switch (refer to IEEE 802.1D for more details):

1) An untagged frame with 1500 bytes payload is configured to be tagged at the egress port. If your argument was correct the egress frame would have 1504 bytes of payload. This is not allowed. It could also be that 4 bytes of payload was skipped to make room for the VLAN tag. This would lead to data corruption and is not allowed.

2) A tagged ingress frame with 42 bytes of payload (allowed according to your argument) is configured to be untagged at the egress port. This would lead to an undersize frame of 60 bytes but the MinFrameSize on Ethernet is 64 bytes. Since it is not allowed to have frames smaller than the MinFrameSize this would require the switch to do padding (by adding 4 bytes to the payload). A switch does not do behave like this.

Conclusion: the payload does not depend on the presence of the VLAN tag, as clearly stated in IEEE 802.3.

A Wireshark trace of VLAN traffic would also clearly demonstrate that the minimum payload is 46 bytes.

This is how it works according to IEEE 802.3-2012:

An untagged frame consists of the following parts:

Destination address 6 bytes

Source address 6 bytes

Length or type field 2 bytes

Client data (payload) 46-1500 bytes

CRC 4 bytes

Similarly, a tagged frame consists of the following parts:

Destination address 6 bytes

Source address 6 bytes

Vlan tag 4 bytes

Length or type field 2 bytes

Client data (payload) 46-1500 bytes

CRC 4 bytes

So the only difference between a tagged frame and an untagged frame is the presence of the 4 byte VLAN tag inserted between the source address field and the length/type field. The payload has nothing to do with this and is not changed. Also, please remember that the maximum frame size is 1518 bytes for untagged frames and 1522 bytes for tagged frames. This is basic knowledge and clearly stated in IEEE 802.3-2012.

IEEE 802.3-2012 is a very big document. Can you please point out which section defines payload size. Respond here here, and I'll cite it or skip a step and add the citations yourself. ~KvnG 16:18, 1 September 2013 (UTC)

--Nogupry (talk) 21:49, 17 September 2013 (UTC) IEEE 802.3-2012 is indeed a very big standard. The best place to look for the definition of the various parts of an Ethernet frame is probably in section 4.2.7.1. Here it can be seen that the payload is independent from the presence of the VLAN tag. It is also shown that VLAN tagged frames are qTagPreFixSize=4 octets larger than non-tagged frames. Some constants defined in Table 4.2 in Section 4.4.2 are referenced in Section 4.2.7.1.

I can add a reference to Section 4.2.7.1 (section 4.4.2 is referenced by 4.2.7.1).

We're arguing about clientDataSize. It is unclear to me whether this includes the 802.1Q tag or not. From 802.3 table 4-2, it is clear that minFrameSize is 512 bytes regardless of whether there's a 802.1Q tag. How can the minimum payload always be 46 bytes when 802.1Q adds 4 bytes to the packet overhead? ~KvnG 00:27, 23 September 2013 (UTC)

--Nogupry (talk) 08:07, 25 September 2013 (UTC) This is because the minimum frame size of a VLAN tagged frame is 68 bytes, not 64 bytes. This is also discussed in IEEE 802.1Q. However, for legacy reasons there may be support for the correct handling of tagged frames with less than 68 bytes (but at least 64 bytes) in some implementations. (There are a lot of options in IEEE 802.3) This is because some early switch implementations apparently used 64 bytes as the minimum frame size in all cases (this was presumably in the early days of VLAN usage). I have not seen any such switches today but they may of course exist.

When you say "This is also discussed in IEEE 802.1Q", you must not mean the IEEE 802.1Q WP article because that says the minimum size remains 64 bytes. So if you're talking about the IEEE standard, can you please identify which clause you're referring to. ~KvnG 14:18, 25 September 2013 (UTC)

--Nogupry (talk) 20:42, 25 September 2013 (UTC) I referred to the full standard document. Please have a look at IEEE 802.1Q-2011, Annex G (page 1269). In this informative annex both the minimum frame size is discussed. Both 64 bytes and 68 bytes are allowed in principle so I guess we are both right:-) I am slightly surprised to see that 64 bytes tagged frames are still allowed but I would argue that the 64 bytes minimum tagged frame size option is mostly for legacy reasons and that the 68 bytes minimum tagged frame size is how it should be implemented now. I would therefore like to not change the Wikipedia article again as I think the current version (with 68 bytes minimum frame size for tagged frames) is the most appropriate one. It would be too detailed to go into the complexities of annex G in the Wikipedia article I think. Or what do you think?

I agree that discussing these options in the body of the article would be distracting. Allowable payload size is either 42-1500 or 46-1500. When someone asks, "What's the minimum payload size when a 802.1Q tag is present?" the simple answer has to be 42. Your choices are 42 or 46 and 42 < 46. The payload size is labeled 42-1500 in Figure G-1 of the standard so this seems to be the IEEE's simple answer too. I would then add something to the Notes section explaining this in a bit more detail. The crucial constraint here is that a frame from end of SFD to end of FCS must be at least 512 bits. This is described in clause G.2.1. ~KvnG 23:05, 25 September 2013 (UTC)

I've implemented this proposal. It turns our it is now largely back to what it was back in July. ~KvnG 17:29, 2 October 2013 (UTC)

--Nogupry (talk) 09:43, 3 October 2013 (UTC) I strongly disagree with your last edit since it is misleading. This gives the wrong impression as to how modern Ethernet works. And there are situation where there are two VLAN tags in use (double tagging). This would imply a minimum payload of 38 bytes, following your arguments. There are discussions ongoing about adding even more tags. I will not change this article more but Wikipedia users deserve a correct view of this.

PS: This Wikipedia article gives a good description of how this works in modern Ethernet. Please do not change it. https://wiki.riteme.site/wiki/IEEE_802.1ad — Preceding unsigned comment added by Nogupry (talk • contribs) 09:55, 3 October 2013 (UTC)

I don't understand how it is misleading. I see how it is confusing since over time we've added notes on top of notes and this should be cleaned up. ~KvnG 19:14, 9 October 2013 (UTC)

Note 2 and the text in the header structure is now inconsistent regarding the minimum frame size. Which one is the correct? Fredde-Fisk (talk) 15:15, 7 October 2013 (UTC)

Can you be more specific about what part of the text is inconsistent with note 2. Or can you use the background information provided on the talk page here to fix it yourself. ~KvnG 19:14, 9 October 2013 (UTC)

This article is now both inconsistent and misleading. It is inconsistent because the numbers do not add up throughout the article. It is misleading because some of the numbers are not in line with how Ethernet should be used today. A payload of less than 46 bytes may occur in some devices designed prior to the VLAN era (e.g. before 1998) or at least with a very simplistic implementation of VLAN tagging. Such an implementation is not scalable (i.e. does not support multiple tags which is now standard) and this principle cannot accommodate today's complex frame formats with many bytes of additional tagging as well as other payload-like fields. As an example, IEEE 802.1AE (MACSEC) frames may have 32 additional bytes on top of the ordinary frame (40 bytes for double-tagged MACSEC frames). This does NOT lead to frames with a minimum of 6 bytes payload. Complex tagging/untagging actions in modern switches may also rapidly get into trouble with 42-byte payload frames (see above discussions). The article now tells that the minimum payload is reduced from 46 bytes to 42 bytes when there is a VLAN tag present. This is not correct in general. Additional fields in the Ethernet frame today always add on top of the total frame size and do not "steal" from the payload. I would therefore like to change the payload back to being 46-1500 bytes and provide a note saying that it may be 42-1500 in some rare cases. This would be a much better description of reality in my opinion. Instead of changing this article back and forth I propose to have some other networking expert to review this topic and decide the most appropriate and enlightening frame format. --Nogupry (talk) 22:11, 13 October 2013 (UTC)

No mention of Envelope frame, allowing a MAC Client Data field of 1982? This is described in 802.3-2012 section 3.2.7. There are 3 possibly supported MAC Client Data field maximums, 1500 for basic frames, 1504 for Q-tagged frames, and 1982 for envelope frames. Envelope frames (if anyone ever implemented them) would allow additional encapsulation prefixes and suffixes without reducing the MTU. The standard references MPLS, but VXLAN, NVGRE, and multiple VLAN tags can all take advantage of this. 135.245.49.13 (talk) 00:41, 29 January 2015 (UTC)

Well spotted! However, I don't think this has really been implemented that way anywhere. Usually you use "baby giants" which looks like pretty much the same concept on first glance (without the specific EtherType value which I fail to locate anywhere). I've never seen "envelope frames" mentioned in any hardware doc and had no idea that baby giants may be 802.3. Any which way, this should get at least some coverage here. -- Zac67 (talk) 18:01, 29 January 2015 (UTC)

Packet vs. Frame

The article is titled "Ethernet Frame" but the description pervasively includes Ethernet Packet data (including preamble) that appears outside the frame, which begins with Destination Address and ends with Frame Check Sequence. The name of the "start of frame delimiter" field should be a hint that the frame does not start with the preamble. The IEEE 802.3 standard is authoritative; this article should not use language that is inconsistent with the standard. Picanorm (talk) 21:34, 21 August 2013 (UTC)

I agree, "Ethernet packet" should never be said. I've made some edits. It is OK to say "data packet", "IPX packet" or "packet sniffer". ~KvnG 23:12, 25 September 2013 (UTC)

Videos

A couple videos have been added to the article bu Renepick. Similar videos have been added to Carrier sense multiple access with collision detection, IP address and Internet protocol suite (the latter addition was reverted by Kbrose). I'm not convinced that addition of these is an improvement to the articles. Other opinions? ~KvnG 04:17, 27 October 2013 (UTC)

I think it would be useful to link from this article to the Wikiversity topic, but they don't fit the format of Wikipedia and they can't be changed by other Wikipedia editors. For example, I can't correct the glaring misspelling of "Preambel" or the overuse of "actually" in the video. -- intgr [talk] 14:43, 27 October 2013 (UTC)

First of all you can record a new audio track and exchange it in the current video so that the word actually is not overused. Second: As you can see in commons we are rerecording videos where mistakes are mentioned. So if you have a better audio track and no ways of recording them why don't you upload a better transcript on the talk page in commons. third: We would love also to publish the source files of the videos so that everyone can correct mistakes. But this is restricted by commons and also hard for technical reasons. So I would suggest we talk to the wikimedia foundation about the possibilities to extend the mediawiki software to enable better collaborative video editing features. (I will give a presentation about this on the Wikicon 2013 in Germany together with a Elly Koepf from Wikimedia Foundation Germany) I am pretty sure that the video format itself is something that the Wikipedia could greatly benefit from but right now has technical limitations to collaboratively work on. So as long as mediawiki software won't change I suggest to go for my first and second suggestion in order to improve the videos rather then excluding them from the articles --Renepick (talk) 20:07, 27 October 2013 (UTC)

Thanks for responding. Can you make a case why adding the videos improves the articles? Best case I'm seeing is that we have the same information in two different formats. Duplication creates a maintenance issue.

What do you think about the suggestion to includa a link it the relevant articles to Wikiversity? This is is commonly done for Wictionary and Wikibooks. ~KvnG 20:49, 27 October 2013 (UTC)

The information is the same but with a video I might have much better chance to understand what is really going on. For example if you think about the file on the collision detection algorithm there is much more details that you can easily communicate via an example animation (e.g. how waves travel through the cable and how occupying the cable really works.) I am pretty sure that this adds value to a pearson who is interested in the algorithm. Otherwise for our lecture we would not produce these videos. I also agree that different learners have different learning habbits. For some people the flow chart File:CSMACD-Algorithm.svg (which by the way is also redundant with the text) might be enough. Still our students also told us that they like the videos and that they improve the learning experience. I really do not understand why the collision detection algorithm video was removed by Kbrose with the comment "video spam".

Additionally wikimedia offers the possibility to host videos and videos are included in other Wikipedia articles. Also I am admin in the german wikiversity. During the last meeting with the WMF it was heavily discussed if Youtube videos should be allowed inside mediawiki software since the video format can increase education and this is one of the goals of WMF. It was aggreed though that the content should be free (and thus coming from commons) even though less content was there than youtube. I think removing videos from wikipedia would be the wrong signal. I'd rather like more people uploading their excellent videos not to youtube but rather to commons and include them to Wikipedia articles and thus contribute to free knowledge.

at last there would certainly be the way to also include wikiversity links. -- Renepick (talk) 09:00, 28 October 2013 (UTC)

> there is much more details that you can easily communicate via an example animation

Sure, adding animations to Wikipedia is a good idea, but it doesn't follow that you have to add whole lecture videos. This falls under WP:NOTGUIDE: "The purpose of Wikipedia is to present facts, not to teach subject matter". That's why we have other Wikimedia projects like Wikiversity -- they are different from Wikipedia in purpose and in format.

I agree that the other Wikimedia projects are underrepresented, but let's work on fixing that instead -- let's not shoehorn everything into Wikipedia simply because it's more popular and these videos get more exposure that way.

There is a template {{Wikiversity}} (which I have added to the article), but it clearly has problems: it's not used very much, the template is not obtrusive enough to attract attention from readers, and it instructs editors to place it at the end of the article, where nobody will see it.

I think the best course of action would be to discuss this either in Wikiversity or general Wikipedia discussion pages like WP:PUMP, to design a new template that has better visibility and can be used at the top of articles (if that's deemed reasonable), so people who want to learn this subject can immediately get to the right place. Or just WP:BOLD it and see what people think. -- intgr [talk] 10:18, 28 October 2013 (UTC)

I like what intgr says so I won't repeat it. I believe an improved {{Wikiversity}} is a better way to incorporate this material than adding copies of it to Wikipedia articles.

Kbrose is a valued contributor to WP:NETWORK articles but doesn't always do a good job of explaining what he's doing or why. ~KvnG 17:10, 28 October 2013 (UTC)

I think that how-to videos are not encyclopedic and should not be prominently positioned in Wikipedia articles. We can have links to the videos, but I think that having a lecture prominently displayed in the top right corner of the article is a bad idea. Pburka (talk) 17:01, 4 November 2013 (UTC)

I've moved the videos into a "Further Reading" section, as I think it was inappropriate to have them mixed into the body of the article. While I feel this is better, I'm still not completely comfortable with the presence of the videos at all, and would not object to their outright removal. Pburka (talk) 18:27, 6 November 2013 (UTC)

Ethernet packet size correction

As I've tried to correct, the Ethernet packet does not include the interpacket gap. This makes it exactly 8 bytes larger than the frame it transports (preamble + SFD). This is already sourced in 802.3 3.1.1. Figure 3-1 & 3.2 provide detail and it's also covered in the 1.4 Definitions section: "1.4.226 interpacket gap (IPG): A delay or time gap between Ethernet packets intended to provide interframe recovery time for other Ethernet sublayers and for the Physical Medium. (See IEEE Std 802.3, 4.2.3.2.1 and 4.2.3.2.2.)" - Zac67 (talk) 21:21, 26 February 2014 (UTC)

Hardware Creep

We have some creep from the MII page into this (admittedly I contributed to this while trying to clarify a section), obviously they are very interrelated topics from the point of view of bus width, data rate etc. Should we have a short section on hardware (generation of, e.g. Fast Ethernet vs GbE) and how it may relate to variations in the frame? — Preceding unsigned comment added by ValliusDax (talk • contribs) 14:41, 11 March 2014 (UTC)

Preamble and start frame delimiter glitch?

I'm looking at the discussion of the 'Preamble and start frame delimiter', and it says that the binary version of the preamble and SFD is:

10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011

and that the hexadecimal is:

0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5

Something seems wrong there. The binary 10101011 is equivalent to hex 0x57, is it not? 0xD5 is, I think, 11011010.

Can anybody help?

Mctmike (talk) 14:54, 22 August 2017 (UTC)

Ethernet transmits lowest bit first, the usual notation lists highest bit first. --Zac67 (talk) 20:18, 22 August 2017 (UTC)

That would do it - thanks! --Mctmike (talk) 17:33, 24 August 2017 (UTC)

There's more confusion here about the bit order, since " 15:08, 12 July 2018‎ 92.67.128.131 (talk)‎ . . (24,678 bytes) (-79)‎ . . (→‎Preamble and start frame delimiter: SFD is not in the MAC frame and is not transmitted least significant bit first) (undo)". In fact 803.2 section 1 lists the preamble and SFD (3.2.1) as part of the "Elements of the MAC frame and packet" (3.2) and then states (3.3) "Each octet of the MAC frame, with the exception of the FCS, is transmitted least significant bit first". So the 10101011 (10mb/s transmission order) is 0xd5 = 213 not 171 as currently stated on that page.

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Ethernet frame. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20150418013816/http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html to http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:50, 24 September 2017 (UTC)

Actual text of the IEEE standard

The article refers to 802.3-2012 which is a paysite. The 2015 IEEE GET program version contains only an abstract. Is the actual text of the 802.3 standard (current or historical version) available for free on the internet ? -- Juergen 91.15.255.247 (talk) 13:27, 16 August 2018 (UTC)

The current version IEEE 802.3-2015 is free for download on https://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=68 after registration. --Zac67 (talk) 16:39, 16 August 2018 (UTC)

As the GET program page linked above says, "Online access provided at no cost by the IEEE GET program(TM)". It's a bit more of a pain than it's been in the past, before they used IEEE Xplore in the GET program, but you can till get there for free. Older versions of standards aren't offered by the GET program, so you have to buy them. Guy Harris (talk) 19:17, 16 August 2018 (UTC)

Maximum frame size - 802.3as

Unless I'm missing something, this article completely misses that the maximum frame size is 2000 bytes?

802.3as increased the frame size by allowing a maximum header of 482 bytes. This was to be used for QinQ, MPLS, etc.

Has 802.3as since been deprecated and it got changed back to 1522? — Preceding unsigned comment added by Wafflefuzzy (talk • contribs) 09:44, 26 March 2022 (UTC)

The article states that the maximum payload is 1500 bytes which hasn't changed and is unlikely to change ever. 802.3as allowed a larger overall frame size to accomodate more header overhead (as did 802.3ac before that). The article doesn't contradict that but doesn't mention it prominently either. --Zac67 (talk) 11:00, 26 March 2022 (UTC)

Thanks for your reply. Yes, the article correctly states the maximum MTU. My comment wasn't referring to the MTU, however.

Not only doesn't the article "mention it prominently", as far as I can tell, it makes ZERO reference to it, prominent or otherwise.

In my opinion the article does indeed contradict it as the diagram under "structure" notes the frame size as "64–1522 octets". However, to be fair, a broader comment is that the article doesn't really detail the maximum header length (2000B or otherwise) generally. Wafflefuzzy (talk) 02:38, 27 March 2022 (UTC)

That section does make a (very) short reference to Q and QinQ tags and states that they're not depicted here. We could go into more detail there but then again could the topic quickly get out of hand. Perhaps a new subsection at the end of #Structure with references to 802.1ad/ah/AE/generic envelopes would be best. --Zac67 (talk) 06:50, 27 March 2022 (UTC)

IEEE Std 802.3-2018 Section One, Clause 3 "Media Access Control (MAC) frame and packet specifications", subsection 3.1.1 "Packet format", shows, in Figure 3–1 "Packet format", that the Length/Type field is followed by the MAC Client Data field field, possibly followed by a Pad field, followed by the Frame Check Sequence field. The MAC Client Data field's length is indicated as "46 to 1500 or 1504 or 1982 octets (see 3.2.7)". Subsection 3.2.7 "MAC Client Data field" says:

Ethernet implementations shall support at least one of three maximum MAC Client Data field sizes defined as follows:

a) 1500 decimal—basic frames (see 1.4.152)

b) 1504 decimal—Q-tagged frames (see 1.4.416)

c) 1982 decimal—envelope frames (see 1.4.245)

If layer management is implemented, frames with a MAC Client Data field larger than the supported maximum MAC Client Data field size are counted. It is recommended that new implementations support the transmission and reception of envelope frames, item c) above.

NOTE 1—The envelope frame is intended to allow inclusion of additional prefixes and suffixes required by higher layer encapsulation protocols (see 1.4.240) such as those defined by the IEEE 802.1 working group (such as Provider Bridges and MAC Security), ITU-T or IETF (such as MPLS). The original MAC Client Data field maximum remains 1500 octets while the encapsulation protocols may add up to an additional 482 octets. Use of these extra octets for other purposes is not recommended, and may result in MAC frames being dropped or corrupted as they may violate maximum MAC frame size restrictions if encapsulation protocols are required to operate on them.

NOTE 2—All IEEE 802.3 MAC frames share a common format. The processing of the three types of MAC frames is not differentiated within the IEEE 802.3 MAC, except for management. However, they may be distinguished within the MAC client.

NOTE 3—All Q-tagged frames are envelope frames, but not all envelope frames are Q-tagged frames.

In the Introduction, 1.4.152 defines a "basic frame" as

A MAC frame that carries a Length/Type field with the Length or Type interpretation and has a maximum length of 1518 octets. The basic frame is not intended to allow inclusion of additional tags (i.e., untagged) or encapsulations required by higher layer protocols. (See IEEE Std 802.3, 3.2.7.)

1.4.416 defines a "Q-tagged frame" as

A MAC frame with a specific Ethertype value, and that has a maximum length of 1522 octets. (See IEEE Std 802.3, 3.2.7 and IEEE Std 802.1Q, Annex G.)

and 1.4.245 defines an "envelope frame" as

A MAC frame that carries a Length/Type field with the Type interpretation that may indicate additional encapsulation information within the MAC client data and has a maximum length of 2000 octets. The envelope frame is intended to allow inclusion of additional prefixes and suffixes required by higher layer encapsulation protocols. The encapsulation protocols may use up to 482 octets. (See IEEE 802.3, 3.2.7.)

Given all of that, I would suggest that:

• in the diagram that appears at the top of Ethernet frame § Ethernet packet – physical layer, we should rename "EtherType" to "Length/Type" (as in current 802.3 it can either hold a length or a type value), rename "Payload" to "MAC client data" (as that's what the standard calls it, and as, at least to me, it makes a less strong claim about the contents, e.g. it may have extra headers preceding what might be thought of as a "network layer" PDU), possibly add a "Pad" field;
• in Ethernet frame § Header, we should change the second paragraph to

The Length/Type 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).

and remove the third paragraph;

• rename Ethernet frame § Payload to "MAC client data", and replace it with something such as:

If there are fewer than 46 octets of MAC client data, the MAC client data field is followed by a Pad field containing enough octets that the sum of the sizes of the MAC client data and Pad fields is 46 octets. The maximum MAC client data field size is 1500 octets for "basic frames", 1504 octets for "Q-tagged frames", and 1982 octets for "envelope frames". Non-standard jumbo frames allow for larger maximum MAC client data size.

A "Q-tagged frame" is a MAC frame in which the Length/Type field is interpreted as an EtherType rather than a length, and in which the Ethertype value is 0x8100(?), 0x88a(?), or 0x88e7(?). An "envelope frame" is a MAC frame in which the Length/Type field is interpreted as an EtherType rather than a length and in which the EtherType value may indicate additional encapsulation information within the MAC client data. A "basic frame" is either a MAC frame in which the Length/Type field is interpreted as an length rather than an EtherType or in which that field is interpreted as an EtherType but in which the EtherType value does not indicate that the frame is a Q-tagged frame or an envelope frame.

with references and non-reference footnotes placed appropriately, and perhaps with additional information explaining the three EtherType values for Q-tagged frames (Virtual LAN appears only to discuss 0x8100 Customer VLANs, not 0x88a8 Service VLANs/Backbone VLANs or 0x88e7 Backbone Service Instances - are the latter two discussed anywhere?) and giving examples of EtherType values indicating envelope frames (are 0x8847 and 0x8848 for MPLS examples of EtherType values indicating envelope frames, and what others are there?).

I have some questions about Q-tagged frames, though.

What EtherType values indicate Q-tagged frames? 0x8100 seems to fit, as those frames have an extra 4 bytes of tag information, and adding 4 bytes to the maximum MAC client data allows a 1500 octet MTU with the tags present.

0x88a8 appears to be used for QinQ, which, as I read the IEEE 802.1ad page, has 4 bytes of 0x88a8 tag followed by 4 bytes of 0x8100 tag. That doesn't appear to allow a 1500 octet MTU, as a Q-tagged frame only allows 4 bytes of tag.

It also appears to be used for Provider Backbone Bridges, which appear to 1) have a tag larger than 4 bytes and 2) an entire Ethernet frame encapsulated within it, so the 4-octet extension for Q-tagged frames doesn't seem to work there, either. 0x88e7 appears to be the same. So are 0x88a8 and 0x88e7 EtherType values that indicate envelope frames rather than Q-tagged frames? Guy Harris (talk) 09:15, 27 March 2022 (UTC)

Thanks for pasting the excerpt from the standard. How did you access them? They all seem paywalled?

Re your questions at the end, yes, all additional (beyond single Q-tag) encapsulation headers (for QinQ, MPLS, etc.) are "envelope frames".

You might find (like I did) this presentation (from just prior to 802.3as being ratified) very helpful: https://www.ieee802.org/3/as/public/0607/802.3as_overview.pdf Wafflefuzzy (talk) 10:03, 27 March 2022 (UTC)

The IEEE GET Program makes some standards, including current 802 standards, "available for download at no cost". They provide a browsable list of 802 standards available from the GET Program; they offer current standards (so pre-802.3-2018 standards, including the ones rolled up into 802.3, aren't available through the GET program), and there's a six-month delay before newly-published standards are available.

You have to create an IEEE account; the page to create one appears not to require an IEEE membership.

Thanks for the additional information; I'll work on an update to my proposed wording. Guy Harris (talk) 10:46, 27 March 2022 (UTC)

Thanks heaps! Wafflefuzzy (talk) 11:07, 27 March 2022 (UTC)

Revised suggestion:

• in the diagram that appears at the top of Ethernet frame § Ethernet packet – physical layer, we should rename "EtherType" to "Length/Type" (as in current 802.3 it can either hold a length or a type value), rename "Payload" to "MAC client data" (as that's what the standard calls it, and as, at least to me, it makes a less strong claim about the contents, e.g. it may have extra headers preceding what might be thought of as a "network layer" PDU), possibly add a "Pad" field;

• in Ethernet frame § Header, we should change the second paragraph to

The Length/Type 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).

and remove the third paragraph;

• rename Ethernet frame § Payload to "MAC client data", and replace it with something such as:

If there are fewer than 46 octets of MAC client data, the MAC client data field is followed by a Pad field containing enough octets that the sum of the sizes of the MAC client data and Pad fields is 46 octets. The maximum MAC client data field size is 1500 octets for "basic frames", 1504 octets for "Q-tagged frames", and 1982 octets for "envelope frames". Non-standard jumbo frames allow for larger maximum MAC client data size.

A "Q-tagged frame" is a MAC frame in which the Length/Type field is interpreted as an EtherType rather than a length, and in which the EtherType value is 0x8100; these are IEEE 802.1Q-style tagged Virtual LAN frames. An "envelope frame" is a MAC frame in which the Length/Type field is interpreted as an EtherType rather than a length and in which the EtherType value may indicate additional encapsulation information within the MAC client data; examples of envelope frames would be IEEE 802.1ad-style QinQ frames and provider bridged frames (EtherTypes 0x88a8), IEEE 802.1ah-2008-style provider backbone bridged frames (EtherTypes 0x88a8 and 0x88e7), IEEE 802.1AE-style MACsec frames (EtherType 0x88e5), and MPLS frames (EtherTypes 0x8847 and 0x8848). A "basic frame" is either a MAC frame in which the Length/Type field is interpreted as an length rather than an EtherType or in which that field is interpreted as an EtherType but in which the EtherType value does not indicate that the frame is a Q-tagged frame or an envelope frame.

with references and non-reference footnotes placed appropriately. Guy Harris (talk) 18:10, 27 March 2022 (UTC)

That's quite a bit more than what we have now. Why so complicated? As I understand it, the constraints are:

1. All transmissions must be 512 bits or more
2. Payload is not to exceed 1500 bytes. (except for non-standard jumbos). ~Kvng (talk) 00:24, 31 March 2022 (UTC)

Do we want to assume that people will understand that, for example, VLAN headers, MPLS headers, QinQ headers, provider bridged frame headers, etc. do not count as part of the "payload"? Guy Harris (talk) 00:35, 31 March 2022 (UTC)

I'm glad we agree on what we're trying to get at. I can work on trying to come up with a better way to say it. ~Kvng (talk) 13:42, 31 March 2022 (UTC)

I have made some improvements to Ethernet frame § Payload. To address 802.3as, I think we should update Ethernet frame § Header; the payload and FCS are unaffected by this expansion. ~Kvng (talk) 02:13, 1 April 2022 (UTC)

I.e., treat MPLS headers, QinQ headers, provider bridged frame headers, etc. as part of the Ethernet frame header? Guy Harris (talk) 02:22, 1 April 2022 (UTC)

Yes, I think that's how the standard has handled them since 802.3as. Before that, things were muddy. I'm not sure it is helpful to try to explain the mud. ~Kvng (talk) 15:25, 3 April 2022 (UTC)

Maximal frame size: 1518 vs 1522

In the figure of Section "Structure", the Ethernet Frame size is assumed to be in range 64-1522 octets. But I just add a look on 802.3, Table 4-2, that states that the maximal size (maxBasicFrameSize) is 1518 (and the minimal, minFrameSize is 64 octets). MarcBoyerONERA (talk) 10:58, 12 December 2022 (UTC)

The four-byte 802.1Q tag is optional. Maximum (standard) frame size without is 1518 - IEEE 802.3 Table 4-2 uses maxBasicFrameSize. --Zac67 (talk) 11:32, 12 December 2022 (UTC)

Dear Zac, thank you for helping. I was confused by the fact that the Q tag is explicitely taken into account in several parts of the standard (e.g 802.3 specifies that the maximum MAC client data field should be 1500 for basic frames, and 1504 for Q-tagged frames, and 1982 for enveloppe frames), but not in Table 4-2. Whatever, 1.4.146 explicitly states that a Q-tagged frame "has a maximum length of 1522 octets". So, question is solved. MarcBoyerONERA (talk) 12:26, 12 December 2022 (UTC)

Frame Check Sequence description is hard to use

• I find the FCS sequence very difficult to use. The mention of BZIP2 is confusing. I initially thought it was CRC/BZIP2 that was used, but that turns out to be wrong. I don't think that using the word BZIP2 adds anything and would suggest that we remove it.

• I also think it would be helpfuly to add an example. I tried to add one but was blocked by the edit filter. If people think an example would be appropriate, there is one that I tried to add. IMHO a Python one-liner would be ideal because it is compact and precise and allows you to check that your implementation is correct. But that was rejected because apparently it is a howto. I don't really see the difference between a Python one-liner like data + zlib.crc32(data).to_bytes(4, "little"), which was rejected by Zac67 and a mathematical formula. It would be nuts to write "compute the energy by the square of speed of light and multiplying it by the mass" when you can write E = mc². Why would it be different with code? As a reader having that code snippet is way more valuable than the paragraphs of English that are insufficiently precise to be sure that you are doing the right thing. Would an example or snippet be acceptable to add? Blaisegassend (talk) 23:29, 13 May 2023 (UTC)

It is the usual CRC32. Initialized to 0xffffffff and complemented at the end. It doesn't have anything to do with BZIP2, other than it might use the same one. Since it is well described in Cyclic redundancy check, no need for it here. The Python code doesn't help, as it doesn't show the algorithm. And the source for zlib.crc32() would be too far off topic. Gah4 (talk) 04:01, 14 May 2023 (UTC)

I don't think that using the word BZIP2 adds anything and would suggest that we remove it. I don't think it adds anything, either, so I removed it.

Discussion of the details of computing a CRC belong in cyclic redundancy check and computation of cyclic redundancy checks, not in an article about a protocol or file format that uses a particular CRC. (Bear in mind WP:NOTHOWTO.) Guy Harris (talk) 04:48, 14 May 2023 (UTC)

I removed the Python line because it didn't really add anything to the article. The Python code was a simple library call that in another language could look like CalcEthernetFCS() – that's pretty redundant. An actual code sample with the algorithm like in CRC would be more informative but provide far too much detail for this page, like Guy Harris stated. --Zac67 (talk) 06:42, 14 May 2023 (UTC)