Further developments of the Spanning Tree Protocol

The Spanning Tree Protocol (STP) for computer networks is one practical application of the Spanning Tree Algorithm. The following developments of the STP rectify its weaknesses and solve specific problems. These include, for example, the Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP) and developments by the manufacturers ORing, RuggedCom, Moxa and Hirschmann.

The theoretical foundation for the Spanning Tree Protocol (IEEE 802.1d) is formed by the spanning tree from graph theory. Examples of the practical implementation of the spanning tree can be found in telephone networks or computer networks. The Spanning Tree Protocol and its descendants are also used to guarantee clear communication channels between the individual bridges. The bridge and the switch can be used synonymously in this context because a switch acts as a multi-port bridge.

Within the OSP layer model, the STP is based on the data link layer. This second layer of the model which has a total of seven layers provides transfers which are as error-free as possible. The core of the Spanning Tree Protocol is the avoidance of redundant paths or loops in the network, meaning that data packages (frames) are not duplicated and do not cause errors in higher level layers. The principle of the Spanning Tree Protocol is a central bridge, the so-called root bridge which can be reached by each network participant (node) via a unique communication channel (path). The paths can be duplicated by the hardware; in this case, the second path is blocked temporarily as a backup or a backup path.

Root Bridge

Only a few steps are required to calculate the network topology: determination of the root bridge, of the best channel from each bridge to the root bridge and finally each component is integrated into the network structure and the topology is calculated in-full.

In order to determine a bridge as a root bridge, initially the bridge ID is evaluated. The lower the bridge ID, the higher the priority and the greater the chance of becoming a root bridge. In case of identical bridge IDs, the MAC (Media Access Control) address is evaluated additionally. Here to: the lower the numeric value, the higher the priority. Once the root bridge has been calculated, the next step follows: determination of the root port (root connection).

Root Port

The root port is the most favourable connection to the root bridge. The root bridge as such does not have a root port. The calculation of this favourable connection is made using the so-called channel costs. The port with the lowest channel costs to the root bridge becomes the root port. The channel costs are calculated from the total of the speeds of each individual port from the respective bridge to the root bridge. These speeds are virtual values and standardised according to the IEEE. If the channel costs are identical for several communication channels, the bridge ID and the respective port ID (connection identifier) are evaluated additionally. The lower numeric value enjoys higher priority and becomes the root port.

Integration into the tree-structure

The root bridge and root ports are calculated for the individual bridges. Integration into the entire tree structure then follows. Firstly, the root bridge establishes a tree structure to all the bridges and then calculates the tree structure with the respective lowest channel costs. This calculated structure is propagated by the root bridge to the remaining bridges in the network. Redundant paths are deactivated temporarily and only one clear path between the respective bridges and the root bridge remains active, in order to avoid loops within the network. The communication between the bridges is realised via so-called Bridge Protocol Data Units (BPDUs). The Spanning Tree Protocol recognises two different types of BPDUs: Configuration BPDUs and Topology Change Notification BPDUs (TCNs). Configuration BPDUs are used to calculate the network topology and Topology Change Notifications for notifications of changes within the network topology. As opposed to the configuration BPDU, the TCN only includes the first fields with the protocol ID contents (protocol identifier), protocol version ID (protocol version identifier) and BPDU type. The configuration BPDU incorporates further fields, e.g. with the root bridge ID, the channel costs to the root bridge, the ID of the transmitting port and the age of the BPDU.

After the network structure has been fully established, the bridges exchange BPDUs in order to check whether the neighbouring bridge can be reached. At regular intervals, the so-called hello time, the bridges transmit the packages to the respective neighbouring bridge. If the expected BPDU does not arrive for the triple hello time, an error or fault is assumed and a recalculation of the network topology is initiated.

Due to various conventions within the STP, e.g. waiting triple hello time, 30 seconds can pass from the failure of a component until the network is restored. The network is not available during this period. It is possible to infiltrate fake packages and to cause a topology change with them, again blocking the network for 30 seconds. Improvements to the Spanning Tree Protocol were demanded. Several manufacturers looked for better solutions and these were merged in the successor Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w).

Successor of the STP

RSTP triggers a reorganisation of the network topology as soon as a deactivated port changes to an active status. This has the advantage that the waiting period of three times the hello time is dropped. The normal hello time is roughly two seconds. Additionally, each bridge can transmit TCNs to neighbouring bridges without having received a corresponding notification from the root bridge as was still true for the STP. Interrupted connections can therefore be localised faster and the recalculation of the network can be initiated. The period from the occurrence of the error until the restore is only a few hundred milliseconds for RSTP.

Not only faults or errors can cause topology changes, but also adding a new bridge or manual intervention, e.g. in order to change priorities if a specific path should be favoured.

Multiple Spanning Tree Protocol

The Multiple Spanning Tree Protocol (MSTP, IEEE 802.1s) is a further successor. The MSTP supports several independent spanning tree instances and guarantees burden sharing between VLANs (Virtual Local Area Networks).

In addition to the standards, various manufacturers developed proprietary RSTP variants, e.g. Open Ring from ORing, HiPER Ring from Hirschmann, eRSTP from RuggedCom and Turbo Ring from Moxa.


The Open Ring Protocol from ORing supports all proprietary variants in addition to the STP standards. This means that the professional user can combine ORing switches with those of all other manufacturers in one environment. This enables easy integration of the ORing switches within an existing network. The restore period in case of errors is defined by the manufacturer with less than 50 ms with a maximum of 250 network nodes. The restore period remains less than 10 ms within an environment with exclusively own switches.

ORing SwitchesORing Switches


The Hirschmann switches use the HiPER Ring as the proprietary variant of the RSTP. The central principle of the HiPER Ring is the splitting of a network into rings which are, in turn, redundantly connected. According to internal specifications, the manufacturer guarantees a restore period of less than 500 ms in a network with up to 50 switches and a line link of up to 3000 km. As opposed to standardised RSTP, the restore period for HiPER Ring is almost completely independent of the number of switches.


RuggedCom extended the RSTP protocol in two respects: reduction of the restore period to a few milliseconds between two switches and increasing the number of switches participating in the network from 40 (RSTP) to 160. The name of the protocol is based on the IEEE standard: eRSTP and stands for enhanced RSTP. The advantage of eRSTP is its application options in heterogeneous network landscapes as well as a free selection for network topology.


Moxa developed the Turbo Ring protocol as its own RSTP variant. According to the manufacturer, the restore periods in a network with up to 250 switches consisting of a simple ring are less than 20 ms. The protocol supports ring topologies such as ring coupling, dual-homing and dual ring.

Ring CouplingRing Coupling

Dual HomingDual Homing

Dual RingDual Ring

Possible restrictions

Although some of the protocol features may sound enticing when expressed by the respective manufacturers, certain restrictions must in-part be taken into consideration elsewhere: some proprietary RSTP variants only support ring topologies (Open Ring, HiPER Ring and Turbo Ring), for others the restore periods increase considerably with an increasing number of switches in the network (eRSTP and Turbo Ring) and others again can only be combined with the same manufacturer's switches (HiPER Ring, Turbo Ring). Specialist and independent distributors such as acceed (www.acceed.de) support concrete palling in detailed questions. Just as each network provides special requirements, there are various solutions on the market.




Structure of the BPDU configuration

Protocol ID
Protocol version ID
BPDU type
Root ID
Root path cost
Bridge ID
Port ID
Message age
Maximum age
Hello time
Forward delay

Protocol ID: identifier of the protocol used

Protocol version ID: current version of the protocol used

BPDU type: type of notification

Flags: further specifications

Root ID: identifier of the root bridge

Root path cost:channel costs to the root bridge

Bridge ID:identifier of the transmitting bridge

Port ID: identifier of the transmitting port

Message Age: age of the current message

Maximum age: maximum message age determined by the bridge

Hello time: time interval within which the arrival of the next message is expected

Forward delay: time which the bridge waits before it changes a port's status


Structure of a Topology Change Notification BPDU

Protocol ID
Protocol version ID
BPDU type

Protocol ID: identifier of the protocol used

Protocol version ID: current version of the protocol used

BPDU type: type of notification


Overview of channel costs

Connection speed Channel costs
10 Mbps 100
100 Mbps 19
1 Gbps 4
10 Gbps 2