IEEE Standards AssociationIEEE Standards Interpretation for IEEE Std 802.1D™-1999, IEEE Std 802.1Q™-1998 and IEEE Std 802.3™, 2000 Edition
Copyright © 2002 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.
This is an interpretation of IEEE Std IEEE Std 802.1D-1999, IEEE Std 802.1Q-1998 and IEEE Std 802.3, 2000 Edition.
Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.
IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA
26 July 2002
Interpretation Request #1
Topic:MAC behavior when it is attached
to the 802.1D/Q Bridge
It is clear that IEEE 802.3 MAC may not send frames greater than 1518 bytes
in length for untagged frame and 1522 bytes for a tagged (802.3ac) frame. It
is also clear (from 4.2.4.2.1 a.) that Reception of a frame greater than these
are allowed to be truncated (and reported as a error) but not required to do
so.
In an implementation designed to meet IEEE 802.1D/Q Bridge with integrated IEEE 802.3 MAC, it may receive well-formed (correct frame format with valid FCS) frame that is “slightly“ longer than 1518/1522 bytes. It is desirable to allow these frames to be forwarded. However, simply by allowing these frames to be switched, does this implementation violate this aspect of IEEE 802.3 MAC standard? One could argue that since a frame reception does NOT enforce the frame size limit, it is acceptable to allow it to reach the bridge relay function, but on its egress, a MAC could send a frame that is longer than the maximum MTU specified. But one could further argue that, so long as the implementation only generates longer frame if and only if it received one, the implementation is still conformant in this respect. Please ignore the 4 bytes of 802.3ac/802.1Q tag generation/removal issue when answering this question. The reading of IEEE 802.1D Clause 6.3.8 allows any MTU to be supported and also allows for only supporting smallest common denominator between bridged LAN.
So what is not clear, and would like the clarification/interpretation of the clause 4.2.4.2.1 relative to 802.1D bridging, if a MAC receives frames longer than 1518/1522, otherwise well formed, and relays it to a egress port, and the egress port sends this frame, does the implementation violate the standard? Or this extended length support not covered by the standard? It would settle some internal debate if you could answer both questions and provide any other helpful guidance for us.
Begin From IEEE 802.3-2000
4.2.4.2 Receive media access management
4.2.4.2.1 Framing
The CSMA/CD sublayer recognizes the boundaries of an incoming frame by monitoring
the receive Data-Valid signal provided by the Physical Layer. Two possible length
errors can occur that indicate ill-framed data: the frame may be too long, or
its length may not be an integer number of octets.
a) Maximum Frame Size. The receiving CSMA/CD sublayer is not required to enforce
the frame size limit, but it is allowed to truncate frames longer than maxUntaggedFrameSize
octets and report this event as an (implementation-dependent) error. A receiving
CSMA/CD sublayer that supports tagged MAC frames (see 3.5) may similarly truncate
frames longer than (maxUntaggedFrameSize + qTag- PreSize) octets in length,
and report this event as an (implementation-dependent) error.
b) Integer Number of Octets in Frame. Since the format of a valid frame specifies
an integer number of octets, only a collision or an error can produce a frame
with a length that is not an integer multiple of 8 bits. Complete frames (that
is, not rejected as collision fragments; see 4.2.4.2.2) that do not contain
an integer number of octets are truncated to the nearest octet boundary. If
frame check sequence validation detects an error in such a frame, the status
code alignmentError is reported.
Begin From IEEE 802.1-1998
Clause 6.3.8: The Maximum Service Data Unit Size that can be supported by an
802® LAN varies with the MAC method and its associated parameters (speed,
electrical characteristics, etc.). It may be constrained by the owner of the
LAN. The Maximum Service Data Unit Size supported by a Bridge between two LANs
is the smaller of that supported by the LANs. No attempt is made by a Bridge
to relay a frame to a LAN that does not support the size of Service Data Unit
conveyed by that frame.
IEEE Std 802.1D states: 7.7.1 Enforcing topology restriction Each Port is selected as a potential transmission Port if, and only if a) The Port on which the frame was received was in a forwarding state (8.4), and b) The Port considered for transmission is in a forwarding state, and c) The Port considered for transmission is not the same as the Port on which the frame was received, and d) The size of the mac_service_data_unit conveyed by the frame does not exceed the maximum size of mac_service_data_unit supported by the LAN to which the Port considered for transmission is attached. For each Port not selected as a potential transmission Port, the frame shall be discarded.
A similar statement is made in 8.7.1 of IEEE Std 802.1Q. These clauses clearly require a conformant Bridge to discard, and not transmit, a frame that exceeds the maximum frame size supported by the transmitting MAC. In the context of this interpretation request, the maximum frame size supported by an IEEE 802.3 MAC is defined in 3.2.7 of IEEE Std 802.3.
Interpretation Response for 802.3-2002The standard clearly states in 3.2.7 that the maximum frame size is 1518 (for untagged frames) or 1522 (for tagged frames). A DTE (MAC plus MAC Client) that issues frames greater than the maximum frame size is not compliant.