When a designated port is in a discarding or learning state (and only in this case), it sets the PRoposal bit on the BPDUs it sends out. This is what happens for port p0 of the root bridge, as shown in Step 1 of the diagram above. Because Switch A receives superior information, it immediately knows that p1 is going to be its new root port. Switch A then starts a sync to ensure that all of its ports are in-sync with this new information. A port is in-sync if it meets either of the following criteria:
it is in a blocking state (which means discarding, in a stable topology).
t is an edge port
In order to illustrate the effect of the sync mechanism on different kind of ports, suppose there exists an alternate port p2, a designated forwarding port p3, and an edge port p4 on Switch A. Notice that p2 and p4 already meet one of the criteria listed above. In order to be in sync (Step 2 of the diagram above), Switch A just needs to block port p3, assigning it the discarding state. Now that all of its ports are in sync, Switch A can now unblock its newly selected root port p1 and reply to the root by sending an agreement message (Step 3). This message is a copy of the proposal BPDU, with the agreement bit set instead of the proposal bit. This ensures that port p0 knows exactly to which proposal the agreement it receives corresponds to.
Once p0 receives that agreement, it can immediately transition to forwarding. This is Step 4 of the figure above. Notice that port p3 was left in a designated discarding state after the sync. In Step 4, that port is in the exact same situation as was port p0 during Step 1. It then starts proposing to its neighbor, attempting to quickly transition to forwarding.
The proposal agreement mechanism is very fast, as it does not rely on any timers. This wave of handshakes propagates quickly towards the edge of the network, and quickly restores connectivity after a change in the topology.
If a designated discarding port does not receive an agreement after having sent a proposal, it slowly transitions to the forwarding state, falling back to the traditional 802.1d listening-learning sequence. This could happen for instance if the remote bridge doesn't understand RSTP BPDUs, or if the remote bridge's port is blocking.
Cisco introdUCed an enhancement to the sync mechanism that allows a bridge to put only its former root port in the discarding state when syncing. Detailing the way this mechanism works is beyond the scope of this document. However, one can safely assume that it will be invoked in most common reconvergence cases. The scenario described in Convergence with 802.1w section of this document now becomes extremely efficient, as only the ports on the path to the final blocked port are temporarily confused.
Uplink Fast
Another form of immediate transition to the forwarding state included in RSTP is exactly similar to Cisco's uplink fast proprietary spanning-tree extension. Basically, when a bridge loses its root port, it is able to put its best alternate port directly into forwarding mode (the appearance of a new root port is also handled by RSTP). The selection of an alternate port as the new root port generates a topology change. The 802.1w topology change mechanism clears the appropriate entries in the upstream bridges' Content Addressable Memory (CAM) tables, removing the need for the dummy multicast generation process of uplink fast.
Uplink fast does not need to be configured further, as the mechanism is natively included and automatically enabled in RSTP.
New Topology Change Mechanisms
When an 802.1d bridge detects a topology change, it first notifies the root bridge, using a reliable mechanism, as shown in the diagram below:
Once the root bridge is aware of a change in the topology of the network, it sets the TC flag on the BPDUs it sends out, which are then relayed to all the bridges in the network. When a bridge receives a BPDU with the TC flag bit set, it reduces its bridging-table aging time to forward delay seconds, ensuring a relatively quick flushing of stale information. Refer to Understanding Spanning-Tree Protocol Topology Changes for more information on this process. This topology change mechanism has been deeply remodeled in RSTP. Both the detection of a topology change and its propagation through the network have evolved.
Topology Change Detection
In RSTP, only non-edge ports moving to the forwarding state cause a topology change. This means that a loss of connectivity is not considered as a topology change any more, contrarily to 802.1d (that is, a port moving to blocking does no longer generates a TC). When a RSTP bridge detects a topology change, the following happens:
It starts the TC While timer with a value equal to twice the hello time for all its non-edge designated ports and its root port if necessary.
It flushes the MAC addresses associated with all these ports.
As long as the TC While timer is running on a port, the BPDUs sent out of that port have the TC bit set. BPDUs are also sent on the root port while the timer is active.
Topology Change Propagation
When a bridge receives a BPDU with the TC bit set from a neighbor, the following happens:
It clears the MAC addresses learnt on all its ports except the one that received the topology change.
It starts the TC While timer and sends BPDUs with TC set on all its designated ports and root port (RSTP no longer uses the specific TCN BPDU, unless a legacy bridge needs to be notified).
This way, the TCN is flooded very quickly across the whole network. The TC propagation is now a one step process. In fact, the initiator of the topology change is flooding this information throughout the network (as opposed to 802.1d where only the root could do so). This mechanism is much faster than the 802.1d equivalent. There is no need to wait for the root bridge to be notified and then maintain the topology change state for the whole network for seconds.
In just a few seconds (a small multiple of hello times), most of the entries in the CAM tables of the entire network (VLAN) are flushed. This approach results in potentially more temporary flooding, but on the other hand it clears potential stale information that prevents rapid connectivity restitution.
Compatibility with 802.1d
RSTP is able to interOperate with legacy STP protocols. However, it is important to note that 802.1w's inherent fast convergence benefits are lost when interacting with legacy bridges.
Each port maintains a variable defining the protocol to run on the corresponding segment. A migration delay timer of twice hello time is also started when the port comes up. When this timer is running, the current (STP or RSTP) mode associated to the port is locked. As soon as the migration delay has eXPired, the port will adapt to the mode corresponding to the next BPDU it receives. If the port changes its operating mode as a result of receiving a BPDU, the migration delay is restarted, limiting the possible mode change frequency.
For instance, suppose Bridges A and B in the figure above are both running RSTP, with Switch A being designated for the segment. A legacy STP Bridge C is introduced on this link. As 802.1d bridges ignore RSTP BPDUs and drop them, C believes there are no other bridges on the segment and starts sending its inferio
