Copyright © 2008 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 802.1D-1999. Interpretations are issued to explain and clarify the intent of a standard and are not intended to constitute an alteration to the original standard or 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 Standard 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
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?
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.
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.
Searching for the information on link failure detection by RSTP, I have found the following website http://standards.ieee.org/reading/ieee/interp/802.1D.html. 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?
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.
Back to Available IEEE Standards Interpretations Online