Talk:Ethernet frame

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Networking (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as Mid-importance).
 

Source[edit]

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

Payload[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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 (talkcontribs) 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://en.wikipedia.org/wiki/IEEE_802.1ad — Preceding unsigned comment added by Nogupry (talkcontribs) 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[edit]

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[edit]

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[edit]

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[edit]

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 (talkcontribs) 14:41, 11 March 2014 (UTC)