Content

| 3.4 |  | 802.1w Rapid Spanning-Tree Protocol |
| 3.4.4 |  | RSTP timers |

When a port has been selected by the STA to become a designated port, 802.1D still waits twice <forward delay> seconds (2x15 by default) before transitioning it to the Forwarding state. In RSTP, this condition corresponds to a port with a designated role but a Blocking state. Figures through illustrate how fast transition is achieved step-by-step. If a new link is created between the root and Switch A, both ports on the link are put in a Discarding state until they receive a BPDU from their counterpart.

When a designated port is in a Discarding or Learning state, and only in this case, the port 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 Figure . 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).
- It 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 Switch A 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. 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.

Once p0 receives that agreement, it can immediately transition to forwarding. Notice that port p3 was left in a designated Discarding state after the sync. In Step 4, that port is in the 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 x1, falling back to the traditional 802.1D Listening-Learning sequence. This could happen if the remote bridge does not understand RSTP BPDUs, or if the remote bridge port is blocking.

Uplink Fast RSTP incorporates an automatically enabled feature exactly similar to Cisco uplink fast proprietary spanning tree extension. The 802.1w topology change mechanism clears the appropriate entries in the Content Addressable Memory (CAM) tables of the upstream bridges, removing the need for the dummy multicast generation process of uplink fast.

When an 802.1D bridge detects a topology change, it first notifies the root bridge, using a reliable mechanism. 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.

This topology change mechanism has been deeply remodeled in RSTP. Both the detection of a topology change and propagation through the network have evolved.

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 <max age plus forward delay> 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 inherent fast convergence benefits are lost when interacting with legacy bridges.