802.3 : Length interpretation and payload type
I've just noticed that IEEE 802.3-2005 does not explicitly tell what MAC client data is when the Length/Type field contains a length value. It's generally assumed to be an LLC PDU, but the assumption doesn't seem to be backed by the standard. So I wonder whether it's a shortcoming of the standard or IEEE really meant it.Of course, it can be speculated that a sender and recipient can agree upon the data.type in advance and choose LLC or whatever, but it wasn't the way other IEEE standards followed. E.g., 802.4 explicitly mentioned the LLC PDU. Any ideas?
Re: 802.3 : Length interpretation and payload type
Quote:
Originally Posted by
Stefan09
I've just noticed that IEEE 802.3-2005 does not explicitly tell what MAC client data is when the Length/Type field contains a length value. It's generally assumed to be an LLC PDU, but the assumption doesn't seem to be backed by the standard. So I wonder whether it's a shortcoming of the standard or IEEE really meant it.Of course, it can be speculated that a sender and recipient can agree upon the data.type in advance and choose LLC or whatever, but it wasn't the way other IEEE standards followed. E.g., 802.4 explicitly mentioned the LLC PDU. Any ideas?
As you say, the sender and receiver could in principle make whatever agreements they want. But the more standards-oriented answer would probably be that 802.3 only describes Layer 1. And that if you want to go up to Layer 3 and beyond, you first need to obsess over layer 2. Layer 2 is covered in 802.2, where LLC is. The way I look at it, the original Xerox Ethernet spec sort of glossed over the stricter layer orientation the IEEE worked with. The "length" format is the original IEEE take on what Ethernet should look like. Check out the older 802.3 documents and you won't even find the "type" format at all. So, like all other IEEE standards, the original 802.3 assumed that you'd layer 802.2 on top of the physical layer and the MAC layer, as all the other 802 nets did. But instead, with Ethernet, they had to deal with legacy. And the legacy was stronger than the new-fangled 802.3, and it was finally incorporated into 802.3.
Re: 802.3 : Length interpretation and payload type
So the confusing thing is that the type field is described in layer 1, but LLC isn't?
Re: 802.3 : Length interpretation and payload type
Quote:
Originally Posted by
Marlon
So the confusing thing is that the type field is described in layer 1, but LLC isn't?
In a sense, the Type field is the link layer, IMO. The Type field is in fact a Protocol ID field, identifying (among other possibilties) the Layer 3 protocol carried in that Ethernet frame. The MAC layer, instead, is usually considered to be the upper half of the Physical layer. So that leaves the Type field as Layer 2.
Re: 802.3 : Length interpretation and payload type
Quote:
Originally Posted by
Marco-D
As you say, the sender and receiver could in principle make whatever agreements they want. But the more standards-oriented answer would probably be that 802.3 only describes Layer 1. And that if you want to go up to Layer 3 and beyond, you first need to obsess over layer 2. Layer 2 is covered in 802.2, where LLC is. The way I look at it, the original Xerox Ethernet spec sort of glossed over the stricter layer orientation the IEEE worked with. The "length" format is the original IEEE take on what Ethernet should look like. Check out the older 802.3 documents and you won't even find the "type" format at all. So, like all other IEEE standards, the original 802.3 assumed that you'd layer 802.2 on top of the physical layer and the MAC layer, as all the other 802 nets did. But instead, with Ethernet, they had to deal with legacy. And the legacy was stronger than the new-fangled 802.3, and it was finally incorporated into 802.3.
I've got a similar impression. The modern text of 802.3 suggests it was patched once to match both DIX and IEEE 802 realities when IEEE decided to recognize both branches of Ethernet. E.g., at the very top of Section 4, Media Access Control, we can read:
The MAC sublayer defines a medium-independent facility,built on the medium-dependent physical facility provided
by the Physical Layer, and under the access-layer-independent LAN LLC sublayer (or other MAC client).
Such parenthesised references to "other MAC client" can be found all over 802.3; clearly, they were added later. However, the patch wasn't ideal and created options that shouldn't have been there, like the one in question. That's my conclusion.
