IEEE 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.
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 220.127.116.11.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 18.104.22.168.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
22.214.171.124 Receive media access management 126.96.36.199.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 188.8.131.52.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.
Interpretation Response - 802.1D-1999 & 802.1Q-1998
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-2002
The 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.