Content

| 3.4 |  | 802.1w Rapid Spanning-Tree Protocol |
| 3.4.5 |  | RSTP BPDU format |

A few changes have been introduced by RSTP to the BPDU format. Only two flags, Topology Change (TC) and TC Acknowledgment (TCA), were defined in 802.1D. However RSTP now uses all six remaining bits of the flag byte in order to do the following:

- Encode the role and state of the port originating the BPDU.
- Handle the proposal/agreement mechanism.

Another important change is that the RSTP BPDU is now of type 2, version 2. The implication of this is that legacy bridges must drop this new BPDU. This property makes it easy for an 802.1w bridge to detect legacy bridges connected to it.

BPDU are sent every hello-time (not simply relayed anymore). With 802.1D, a non-root bridge would only generate BPDUs when it received one on its root port. In fact, a bridge was rather relaying BPDUs more than actually generating them. This is not the case anymore with 802.1w. A bridge now sends a BPDU with its current information every <hello-time> seconds (2 by default), even if it does not receive any from the root bridge.

On a given port, if hellos are not received for three consecutive times, protocol information can be immediately aged out (or if max_age expires). Because of the previously mentioned protocol modification, BPDUs are now used as a keep-alive mechanism between bridges. A bridge considers that it has lost connectivity to its direct neighboring root or designated bridge if it misses three BPDUs in a row. This fast aging of the information allows quick failure detection. If a bridge fails to receive BPDUs from a neighbor, it is certain that the connection to that neighbor has been lost, as opposed to 802.1D where the problem could have been anywhere on the path to the root. Note, failures are detected even much faster in case of physical link failures.

The concept of accepting inferior BPDUs is what makes up the core of the backbone fast engine. The IEEE 802.1w committee decided to incorporate a similar mechanism into RSTP. When a bridge receives inferior information from its designated or Root Bridge, it immediately accepts it and replaces the one previously stored.

In Figure , Bridge C still knows the root is alive and well and immediately sends a BPDU to Bridge B containing information about the root bridge. As a result, Bridge B stops sending its own BPDUs and accepts the port leading to Bridge C as its new root port.