Interpretations

Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretation for IEEE Std 802.1D™ -1999 IEEE Standard for Local and Metropolitan Area Networks-- Media Access Control (MAC) Bridges

Copyright ©2008 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

March 2008

Interpretation Request #1
In IEEE Std 802.1D, 8.8.3 disable_port(port_no) {root = root_bridge -- --

if ( root_bridge & !root) { detected topology change

} }

This will not work for root bridge. So if the root bridge has multiple ports, removing one link will not generate any topology change. If [you] remote the !root, then topology change will be generated. What is the correct way of solving this?

Interpretation Response
If the bridged local area network being considered is exclusively operating RSTP (802.1w Clause 17) rather than STP (802.1D Clause 8):

(1) Loss of a link does not directly give rise to a spanning tree topology change.

(2) Loss of a link may or may not cause a spanning tree topology change depending on the subsequent action of RSTP once the link loss has been detected.

(3) Link loss may be detected by RSTP either by expiry of the infoWhile timer at a Bridge Port following a period of cessation of reception of BPDUs from the Designated Bridge for a LAN/link or by detection of a change in the MAC Operational status of the Bridge Port's MAC (attached to the LAN/link) link to FALSE. (The MAC Operational parameter in specified in 6.4.2 of 802.1t).

(4) A change in the MAC Operational status of a Bridge Port's MAC to FALSE results RSTP's portEnabled variable for the port being set to FALSE. (This is described in the definition of the portEnabled variable in 17.18.15 IEEE Std 802.1w-2001).

(5) Which ever way link loss is detected by RSTP, a topology change will only be detected and communicated to other bridges if the operation of RSTP in determining the active topology of the bridged local area network result in another Bridge Port that was previously not forwarding transitioning to the Forwarding state.

If a bridge attached to a link that is lost is operating STP:

(6) Loss of the link may be detected either by expiry of the BPDU last received by the port attached to the link, or by the bridge port becoming disabled.

(7) If the bridge port has become Disabled and was previously in the Forwarding state, a topology change will be detected and communicated to other bridges (assuming sufficient connectivity exists for this to be done).

(8) If the loss of the link is only detected by expiry of a BPDU received, and the port was not previously Forwarding but becomes Forwarding due to the STP protocol selecting it as the Designated Port for the LAN/link, then a topology change will be detected and communicated.

(9) There are circumstances where loss of a LAN/link will not result in STP detecting or communicating a topology change. If the loss of the link is not internally communicated by the MAC Enabled status , whatever the implementation reason, to a port that is already Forwarding there will be no topology change detected. If the loss of the link occurs on a port that is not Forwarding (an Alternate or Backup port) there will be no topology change. In both these circumstances there is no effective change to the active topology of the network, so the failure to detect is unimportant unless it is though that topology change detection can be used as a general purpose method for determining the future availability of LANs/links rather than their present use. There is no intent that the topology change mechanism be used as such a general purpose method.

Interpretation Request #2
Whether or not a loss of link causes a spanning tree topology change

Interpretation Response
The text of IEEE Std 802.1D:-1999 does not explicitly couple the operational state of a MAC to the Disabled Port state; however, the intent of the standard is that detectable failure of a MAC should cause the Bridge Port supported by that MAC to enter the Disabled state, as indicated by the last paragraph of 8.3.5 and the explanation of the port state transitions of type (2) shown in Figure 8-3. A transition to the Disabled Port state causes the Bridge to initiate a topology change notification, unless, for the Port concerned, topology change detection has been explicitly disabled (8.5.5.10). Current technical and editorial corrections to this standard, proposed under project P802.1t, include a macEnabled and a macOperational parameter in the Internal Sublayer Service definition. The macEnabled parameter allows administrative control over the availability of a MAC; the macOperational parameter reflects the operational state of a MAC, and is set to FALSE if the MAC detects a link failure, or if macEnabled is FALSE. The definition of the Disabled Port state is extended to explicitly state that the Disabled state is entered if macOperational becomes FALSE.

Interpretation Request #3
Searching for the information on link failure detection by RSTP, I have found this following website. In this document you write: "Link loss may be detected by RSTP either by expiry of the infoWhile timer at a Bridge Port following a period of cessation of reception of BPDUs from the Designated Bridge for a LAN/link or by detection of a change in the MAC Operational status of the Bridge Port's MAC (attached to the LAN/link) link to FALSE. (The MAC Operational parameter in specified in clause 6.4.2 of 802.1t)." I am specifically interested in the MAC Operational status. This parameter is equal to portEnabled value from 802.1w. A change of portEnabled from TRUE to FALSE means a loss of a link. I cannot understand however what triggers this change. This is very relevant for my simulation of link failures. Is this information coming from physical layer ? When bridge knows that it should change this value? Is it the same for copper and fibre?

Interpretation Response
The appropriate reference for the definition of the MAC_Operational status parameter is now clause 6.4.2 of IEEE Std 802.1D-2004. This clause states: "The value of this parameter is determined by the specific MAC procedures, as specified in 6.5." Clause 6.5 describes the parameter value determination for IEEE Std 802.3 (in 6.5.1), IEEE Std 802.5 (in 6.5.2), and for other media access control methods (further subclauses of 6.5). These procedures may, in principle, differ for different physical media, as determined by the 802 Working Group responsible for the development of that MAC. Such variation may be explicit at the level of the description in clause 6.5, or be a consequence of the way that physical media dependent procedures contribute to the physical media independent function defined by the relevant 802 MAC standard. Reference should be made first to clause 6.5, and then to the specific MAC standards as called out by clause 6.5. This response was approved by 802.1 at its March 2007 plenary meeting.