Google Ryhmät ei enää tue uusia Usenet-postauksia tai ‐tilauksia. Aiempi sisältö on edelleen nähtävissä.

802.3 Lenth Field

3 katselukertaa
Siirry ensimmäiseen lukemattomaan viestiin

Rick Hughson

lukematon,
4.4.1997 klo 3.00.004.4.1997
vastaanottaja

I've seen conflicting documentation about what the length
field in an 802.3 frame includes. I expect there are some
people in this group that can help me out.

Simply put, my question is "What does the length field in
an 802.3 frame include?"

I've seen some documentation that claims Length includes
the Dest. Addr, Source Addr, Length, PDU, and FCS. This
would result in the length being a maximum of 1518 bytes
(decimal).

Other documentation states that the length
field only counts the number of bytes in the PDU. In this
case the largest number in the length field would be
1500 bytes (decimal).

A further question is "Does anyone use this field?"
I know that all the MAC devices I've seen count the
number of bytes themselves and provide the driver
with a count of the number of bytes that it took off
the wire. I haven't seen a MAC device that will compare
the number of bytes that come off the wire to an entry
in the Length field. (This would be a useless function
for devices running in an "Ethernet" environment. Ethernet
uses this field as a Type field)


For extra credit, you may want to comment on how VLANs
effect the Lenght field, if at all.


---
Rick Hughson
Bay Networks, Inc.
3 Federal Street
Billerica, MA 01821

rhug...@baynetworks.com

Rich Seifert

lukematon,
4.4.1997 klo 3.00.004.4.1997
vastaanottaja

In article <33452C34...@baynetworks.com>, Rick Hughson
<rhug...@baynetworks.com> wrote:

> I've seen conflicting documentation about what the length
> field in an 802.3 frame includes. I expect there are some
> people in this group that can help me out.
>
> Simply put, my question is "What does the length field in
> an 802.3 frame include?"
>
> I've seen some documentation that claims Length includes
> the Dest. Addr, Source Addr, Length, PDU, and FCS. This
> would result in the length being a maximum of 1518 bytes
> (decimal).
>
> Other documentation states that the length
> field only counts the number of bytes in the PDU. In this
> case the largest number in the length field would be
> 1500 bytes (decimal).

The Length field, if used, includes all *valid* data bytes within the Data
field. It does NOT include DA, SA, Length, or FCS. If the number of valid
bytes is less than the number of bytes actually transmitted (e.g., if a
minimum length frame contains padding) the Length field effectively tells
you how much padding there is (pad = 46 - Length, for Length < 46).


>
> A further question is "Does anyone use this field?"
> I know that all the MAC devices I've seen count the
> number of bytes themselves and provide the driver
> with a count of the number of bytes that it took off
> the wire. I haven't seen a MAC device that will compare
> the number of bytes that come off the wire to an entry
> in the Length field. (This would be a useless function
> for devices running in an "Ethernet" environment. Ethernet
> uses this field as a Type field)

Actually, I *have* seen MAC controller that can do this, but I agree that
it is not an especially useful function.

>
> For extra credit, you may want to comment on how VLANs
> effect the Lenght field, if at all.
>

As currently defined in the latest draft of IEEE 802.1Q, VLAN tags:

(1) Use a Type field, rather than a Length field, for the encapsulation,
regardless of whether the encapsulated frame uses Length or Type field
style.

(2) Add 4 bytes to the length of a tagged frame (vs. an untagged one), but

(3) Do NOT necessarily increase the minimum length of an Ethernet frame
from 64 to 68 bytes. That is, a frame sent untagged, with a Length field
indicating, say 26 bytes (i.e., there are 20 bytes of pad if sent untagged,
would be sent as a 64 byte frame whether it is sent tagged or untagged. The
tag will add 4 bytes to the frame, but the tagging mechanism would remove 4
bytes of pad.

(4) For a frame using Type field, the VLAN tagging mechanism cannot
possibly know if any of the data field is a pad generated by the higher
layer protocol, so it will always increase the frame by 4 bytes.

No, it ain't pretty, but this was a subject of intense discussion.
Fortunately, very few folks use Length-field style 802.3 frames, so the
problem is fairly well contained.

--
Rich Seifert Networks and Communications Consulting
sei...@netcom.com 21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95030
(408) 395-1966 FAX
"... specialists in Local Area Networks and Data Communications systems"

Kevin Oberman

lukematon,
4.4.1997 klo 3.00.004.4.1997
vastaanottaja

Rick Hughson <rhug...@baynetworks.com> writes:

> I've seen conflicting documentation about what the length
> field in an 802.3 frame includes. I expect there are some
> people in this group that can help me out.
>
> Simply put, my question is "What does the length field in
> an 802.3 frame include?"
>

> A further question is "Does anyone use this field?"
> I know that all the MAC devices I've seen count the
> number of bytes themselves and provide the driver
> with a count of the number of bytes that it took off
> the wire. I haven't seen a MAC device that will compare
> the number of bytes that come off the wire to an entry
> in the Length field. (This would be a useless function
> for devices running in an "Ethernet" environment. Ethernet
> uses this field as a Type field)
>
>

> For extra credit, you may want to comment on how VLANs
> effect the Lenght field, if at all.

As per 802.3 (surely Bay Networks has a copy) 3.2.6, the length field
the length of the actual data in the packet. If there is only one data
(which would be rather odd), the length field would be 1.

The length field does not include the frame header, the FCS, or any
padding included to bring the frame up to minimum length.

I am sure that the field is used here and there, but, since it is
absent in Ethernet formatted data and that is the vast majority of the
data, it is certainly not common to use it. It's only advantage over
the MAC count is that it eliminates the padding. It could not be used
for comparison.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634

0 uutta viestiä