Normal and Alternate Paths

This network diagram was taken from the RSTP section in 802.1D. In this diagram there are six switches each shown with a unique Bridge ID. Since Bridge 111 has the lowest numerical bridge value, it becomes the root bridge in STP and RSTP testing. When conducting either the trunking or proprietary ring tests, the root bridge has no special significance. There are three ports on each switch numbered from 1 to 3.

A port with a solid black dot indicates that the port will be forwarding frames (normal operation) away from the root bridge. A port with an unfilled circle means that the port is forwarding frames towards the root bridge. Attached to segment A will be our master PC and attached to segment G is our slave PC. You will notice that port 3 on Bridge 444 is "discarding." What this means is that it is receiving traffic but it does not pass the traffic on to its switch fabric because to do so would create a loop. However, this port is attached to a healthy segment H that could form the alternate path in the event of a segment failure somewhere else around the ring. Therefore under normal operation, a transmission from the master PC will travel through switches 111, 222, 333 and then 444 before it gets to the slave PC. The slave to master response would travel through the same path in reverse order. If a break occurs at segment D, the network will reconfigure such that a transmission from the master PC will now travel from 111, 666, 555 and then 444 before it gets to the slave PC.

Test Results

Once the representative network was operating, we simulated a break by the removal and insertion of a cable. Both instances resulted in a topology change so we measured the time for the network to recover and resume normal operation. We first ran the UDP test followed by the TCP test for all four redundancy schemes. In each case, we attempted two successive readings. The results are in the table below.

Trunking provided the best results with an amazing 5 ms recovery time using UDP. We had to make several readings just to capture the failure since we could not send messages as fast as the recovery time. Proprietary ring came in second with a 138–431 ms recovery time again using UDP. RSTP was not as rapid but still very fast with recovery times in the range of 1.4 to 2.4 seconds. TCP results were worse. STP was a distant fourth with a 31 second recovery using UDP and 51 seconds under TCP! Clearly, TCP had an impact on recovery time. However, to be fair to TCP, recovery times could have been improved. Once an application program realizes that it lost communication, it could have broken the TCP connection and re-established the connection in order to avoid the lengthy time-out process.

SUMMARY

Even though STP provided the poorest performance, it does not mean it is unusable. It depends upon the application. Applications such as building automation and some process control applications may continue to function even if communication is lost for 30 seconds or more. Other applications, especially in safety or security, may not tolerate any disruption thereby causing controller shutdowns. There may be no practical solution if several Ethernet frames are lost during the recovery process. Users should know the requirements of the application before insisting on a particular redundancy scheme.

IEEE Std 802.1D™-2004, IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges