RSTP - Rapid Spanning Tree Protocol The original spanning tree protocol (IEEE 802.1d) convergences very slowly, after a topological change. When using default values for the max age (20 sec) and the forward delay (15 sec) parameters, it takes 50 seconds until the bridge finally convergences (convergence delay ==2 x forward delay + max age).Although, such convergence delay was adequate when the algorithm was developed, it is unacceptable by many today?s applications (such as voice and video, for example) that require much faster convergence time.
In order to accelerate the spanning tree convergence time the IEEE committee designed a new protocol: 802.1w Rapid Spanning Tree Protocol (RSTP). RSTP is an improved and much faster version of the original 801.d spanning tree protocol. It preserves the terminology, the basic principles and most parameters of the 801.d STP and yet provides rapid recovery from failures.
How RSTP differs from STP:
The purposes of the STP and the RSTP are similar. Both of them aim to transfer the network topology into a spanning tree in order to eliminate network loops. Moreover, each one of them maintains redundant connections which are reactivated only when topological changes occur.
However, they differ in the time it takes them to re-converge after a topological change. The re-convergence of the STP may carry on for 50 seconds while in a well designed network the RSTP re-convergence time may last for less than a second.
In order to achieve this fast re-convergence time the behavior of the spanning tree algorithm had to be changed.
New Port Roles and Port States:
RSTP differentiates explicitly between the state of the port and the role it plays in the topology. It has adapted the STP root port and designated port roles but has split the blocked port role into backup port and alternate port roles. The backup port provides a backup for the designated port and can only exist where two or more ports of the bridge are connected to the same LAN, for which the bridge serves as a designated bridge. The alternate port however, serves as an alternate port for the root port providing redundant path towards the root bridge. Only the root and the designated ports are part of the active topology while the alternate and backup ports do not participate in it.
In addition, the disabled, blocking and listening port states, exist in the STP, have been merged by the RTSP, into a single state called discarding state. Ports in the discarding state do not take part in the active topology and do not learn MAC addresses. The learning and forwarding states have remained unchanged.
When the network is stable the root and the designated ports are in the forwarding state, whereas the alternate and backup ports are in the discarding state. Upon a topology change the new RSTP port roles allow a fast transition of an alternate port into the forwarding state.
Configuration messages as ?keep-alive?STP non root bridge generates its own configuration message only when it receives one on its root port. RSTP bridge on the contrary, generates a configuration message every hello time even if it does not receive one on its root port.
If RSTP bridge does not receive any configuration message from its neighbor bridge within a period of time that equals three hello time, it assumes it has lost connection with that neighbor. This way the configuration messages provide a ?keep-alive? mechanism allowing rapid failure detection and fast re-convergence time.
Faster aging of filtering database entriesWhen STP bridge detects a topology change it does not immediately delete old information from its filtering database. Instead, it generates a topology change notification (TCN) message and sends it towards the root bridge. Even when it receives on its root port, configuration message which TC flag is on, it still does not delete the old information. It first changes its long aging timer to a shorter one and only when the timer expires the old entries are deleted (unless they have been refreshed).
The RSTP bridge, in contrast, deletes old filtering database entries immediately after it has detected a topology change. In addition, instead of sending a TCN message towards the root bridge when a topology change is detected, RSTP bridge generates its own configuration message with TC flag set and sends it to other bridges.
This faster filtering database aging has enormously contributed to the reduction of the re- convergence delay. When a topology change is detected, instead of waiting until the TCN message arrives to the root bridge, then waiting until a configuration message with TC flag on is received and afterwards waiting till the shorter aging timer expires, the RSTP bridges age out old filtering database entries immediately and turn on the TC flag in the configuration messages they generate in order to inform other bridges that topology change has occurred.
Rapid transition to forwarding stateIn order to prevent temporary loops when a topology change occurs, STP bridges do not transition ports from blocking into forwarding state until all the bridges in the network agree on the new topology. The bridges wait till a timer which equals twice the forward delay, expires and only then transition the ports from blocking state into the forwarding state. This delay may cause a temporary loss of connectivity since ports that required to forward data in the new topology remain for some time in the blocking state.
RSTP introduces a rapid transition into the forwarding state in order to reduce the probability for the connectivity loss. A new root port or designated port that is connected to a point-to-point link or configured as an edge port can be transitioned to forwarding state without waiting for the timer to expire.
A root port and an edge port can be immediately transitioned to the forwarding state without exchanging messages with other network bridges. An edge port is a port that directly connected to end stations and thus can not create loops. Therefore, it can be placed in the forwarding state without any delay. RSTP provides a possibility to configure ports that are not connected to other bridges as edge ports. When a bridge receives configuration message on port that is configured to be an edge port, it immediately makes the port be a normal spanning tree port (non-edge port).
Nevertheless, a designated port connected to a point-to-point link can be transitioned to the forwarding state only after it receives an explicit agreement from other bridge that is attached to that link, as part of the agreement/proposal handshake mechanism.
RSTP bridges, connected by point-to-point links, use agreement/proposal handshake mechanism instead of timers, to rapidly re-converge after a topology change. When the bridges detect that the topology has changed they try to transfer their new root and designated ports to forwarding and their alternate and backup ports into blocking as fast as possible. This can be done by using an agreement/proposal handshake mechanism which purpose is to avoid loops and to ensure consistent assignment of port roles across the network.
When a bridge has to transition a designated port in a new topology to forwarding, it set the proposal bit in the configuration messages, it transmits on that port. Once its counterpart bridge receives on a port, connected to the point-to-point link, a proposal configuration message, it verifies that this configuration message is better than the one saved for that port and then it starts a sync operation to ensure that all of it ports are in sync with the new information. A port is in sync if it is in blocking state or if it is an edge port. Therefore during the sync operation the bridge has to block only all its non-edge designated ports. As all the ports of the counterpart bridge are in sync with the new information, the port connected to the point-to-point link sends an agreement to the bridge, originated the proposal configuration message, to place its port in the forwarding state and also transitions itself to the forwarding state if it is the root port in the new topology. The agreement message is a copy of the original proposal configuration message, except that now the proposal bit is off and the agreement bit is on, instead. Once the first bridge receives the agreement message it can immediately move its corresponding port to forwarding.
Similar waves of proposal/agreement handshake messages propagate towards the leaves of the network restoring the connectivity very quickly after a topology change. If a bridge does not receive an agreement of a proposal message it has sent, it returns to the original 802.d convention and slowly transitions its port to the forwarding state through listening and then learning intermediate states.
By relaying on the proposal/agreement handshake mechanism instead of timers the RSTP provides fast re-convergence after a topology change. However, this mechanism works only on point-to-point links and thus in case of shared media the RSTP reverts to 802.d STP operation.
Handling topological changes:
In RSTP, only the movement of a non-edge port to a forwarding state is considered as a topology change. In contrast to the STP, a loss of connectivity, that can be caused by a movement of a port into a blocking state, is not considered by RSTP to be a topology change.
When a STP bridge detects that topology change has occurred, it transmits a TCN message towards the root bridge which then informs all the network bridges about the topology change by setting the TC flag in the configuration messages it transmits to the network. Only when the network bridges receive a configuration message with TC flag on, they also set this flag in the configuration messages they transmit on their designated ports.
RSTP bridges, on the contrary use TCN messages only if a STP bridge needs to be notified of the topology change. Instead, each RSTP bridge that has detected a topology change, starts a timer equals to twice the hello time for all its non-edge designated ports and its root port if needed, and then constantly transmits on these ports configuration messages with TC flag on till the timer expires.
When a bridge receives a configuration message which TC flag is set, it first flushes all the entries in its filtering database except the entries that contain MAC addresses which were learnt via the port that received the configuration message with the TC flag on. Then that bridge starts a timer and transmits its own configuration messages with TC flag set on all its designated ports and the root port until the timer expires.
This way the news of the topology change are quickly spread over the entire network. This is much efficient and faster mechanism than one is used by STP bridges. First of all,there is no need to wait till the TCN message reaches the root bridge, then till a configuration message with TC flag on is received on the root port and then till the shorter aging timer expires, in order to delete old entries from the filtering database. Instead, the RSTP bridge deletes immediately old entries and notify the other bridges to do the same. Secondly a receipt of a configuration message with TC flag set, causes a STP bridge to fast age out all the entries of its filtering database. RSTP bridge, on the contrary, does not flush entries containing MAC addresses which were learnt via the port that received the configuration message with the TC flag on. This way the amount of flushed MAC addresses during a topology change is reduced.
Compatibility with STPRSTP is designed to be compatible and interoperable with the STP.However, the advantages of the fast re-convergence, introduced by the RSTP are lost when it interoperate with STP bridges.
In order to ensure compatibility with STP bridges, each RSTP bridge listens on its ports for configuration messages having the STP format. When a port receives such configuration message it starts behaving as a standard 802.1d STP bridge port. Other ports continue to behave according the RSTP.
RSTP bridge port that is attached to the same LAN as a STP bridge transmits configuration messages in STP format and when it is needed, it generates TCN messages as well. This is necessary because the RSTP configuration messages are discarded by the STP bridges.
In addition, the port state transition timer is increased and messages with TC bit set are being propagated for a longer period to interoperate with the different filtering database flushing mechanism used by STP.
The configuration message (BPDU) of the RSTP differs from the STP configuration message:
The STP configuration message uses only two bits from its flags octet: Topology Change (TC) and Topology Change Acknowledgment (TCA). RSTP configuration message however, uses the six additional bits of that octet. In addition to the TC and TCA bits it uses two bits to handle proposal/agreement handshake mechanism (see below) and four remaining bits to encode the role and the state of the port generating the configuration message.
The STP configuration message type and version fields are carrying the constant value: 0 while these fields of the RSTP configuration message are carrying the constant value: 2.
