[Home] . [What's New?] . [Active Ballots] . [Minutes] . [Meetings] . [Maintenance] . [Interpretations] . [Public Docs] . [Committee Docs]
[Local Address Study Group] . [802 Architecture Group] . [Data Center Bridging Task Group] [Time-Sensitive Networking Task Group]
[Email] . [Ancient Email] . [802.1 MIBs] . [802.1 OIDs] . [IEEE 802] . [IEEE 802 PARs]
TSN: [802] . [802a] . [802b] . [802.1D] . [802.1D-2004] . [802.1G] . [802.1H-REV] . [802.1Q] . [802.1Q-2014] . [802.1s] . [802.1v] . [802.1w] . [802.1AB-2005] . [802.1AB-2009] . [802.1AC-2012] . [802.1AC-2016] . [802.1ad] . [802.1ag] . [802.1ah] . [802.1aj] . [802.1ak] . [802.1ap] . [802.1aq] . [802.1Qaw] . [802.1AX-2008] . [802.1Qay] . [802.1Qbc] . [802.1Qbe] . [802.1Qbf] . [802.1AXbk] . [802.1Qbp] . [802.1AX-2014] . [802.1AX-Rev] . [802.1Qbz] . [802.1Qca]
[802.1AS] . [802.1AS-Rev] . [802.1Qat] . [802.1Qav] . [802.1BA] . [802.1Qbu] . [802.1Qbv] . [802.1CB] . [802.1Qcc] . [802.1Qch] . [802.1CM] . [802.1Qcn] . [802.1Qcp] . [802.1Qcr]
Security: [802.1X-2001] . [802.1X-2004] . [802.1X-2010] . [802.1AE] . [802.1af] . [802.1AR] . [802.1AEbn] . [802.1AEbw] . [802.1Xbx] . [802.1ARce] . [802.1AEcg] . [802.1Xck] . [802E]
DCB: [802.1Qau] . [802.1Qaz] . [802.1Qbb] . [802.1Qbg] . [802.1Qbh] . [802.3bd] . [802.1BR] . [802.1Qcd] . [802.1Qcj] . [802c] . OmniRAN: [802.1CF]

Interpretation #2
Request for Interpretation of 802.3 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 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

So what is not clear, and would like the clarification/interpretation
of the clause 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 ========================= Receive media access management 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- Pre?xSize) 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 speci?es 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 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.

================= END  From IEEE 802.3-2000 =========================

================= BEGIN From IEEE 802.1-1998 ========================

Clause 6.3.8, ?..  ?The Maximum Service Data Unit Size that can be
supported by an IEEE 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?.

================= END  From IEEE 802.1-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 802.3 MAC is defined in 3.2.7 of
IEEE Std 802.3.

Pages copyright © Institute of Electrical and Electronics Engineers, Inc. Please read the rules on Confidentiality Statements and Copyright Notices on Communications. Information on Privacy and opting out of cookies is available. If you have any comments on these pages, please send them to me.

Valid XHTML 1.0 Transitional Valid CSS!

Last modified by njarvis, at 8:41am on Mon, 15 Jul 2002