RSTP vs STP

1. RSTP vs STP Instructors : Assoc’ Prof’ Reuven Cohen Mr. Itay Dabran Mr. Mordo Shalom Submitting : Danny Kalmar 01702821-8 Gilad Wallach 03279719-3 Omer Sharabi 03385662-6

2. Agenda • Project Definition • Implementation • Test Plan • Results • Main Conclusions • General Observations

3. Agenda • Project Definition • Implementation • Test Plan • Results • Main Conclusions • General Observations

4. Introduction • Why do we need spanning tree bridges? • At the beginning : 802.1d • But : the rules were changed • RSTP as an evolution of STP.

5. Goals • Implementing STP and RSTP • Comparing between the performances of the protocols • Results’ discussion.

6. Agenda • Project Definition • Implementation • Test Plan • Results • Main Conclusions • General Observations

7. S/W Modules General: • We implemented a simulation which runs both protocols over a variety of randomized nets • It can run several tests in a single execution and collect statistics about the building and recovery abilities of each protocol • Simulation’s parameters : num’ of bridges and lans , num’ of tests and failures within each test, bridge’s configuration and packet’s lost probability.

8. The Net Manager Module • Simulation’s main loop • Main features : • Creation and initialization of new a randomized net • Running the bridges protocols using the net’s members’ interfaces and the given parameters • Detection of the tree’s : building , failing and recovering • The ability to run multiple tests and failures on a given configuration • Statistics collecting.

9. The Bridge Module • Supports both protocols due to the mode of operation • Main features for the 802.1W: • RSTP’s BPDUs mechanism • Rapid Transition to Forwarding State • Proposal / Agreement mechanism • Sync Mechanism • Uplink Fast • RSTP’s Topology Change Detection and Propagation

10. Main features for the 802.1D: • STP’s BPDUs mechanism • STP’s Topology Change Detection and Propagation

11. The LAN Module • Main features : • Distribution of BPDUs from the previous cycle to their destinations • The LAN receives all messages and prepare them to be sent out the next cycle.

12. The Testing Module • Main features : • Generation of failures on demand : disconnection of a forwarding port or connection of a disabled port while keeping the net with connectivity • Maintenance of failures’ list in order to support running the same tests for both protocols .

13. Bridge.Tick() TestCreateFailure() send_bpdu received_bpdu Lan.Tick() System Arch Bridge Net Manager Testing LAN

14. Main Loop (1) Case: - Packets’ lost probability != 0 • For all tests : • Set a randomized net • Run each protocol till its tree become stable • Collect test’s results. • Print statistics.

15. Main Loop (2) Case: - Packets’ lost probability = 0 • For all tests : • Set a randomized net • Run each protocol till its tree become stable • Collect initialization’s results • For all failures : • Activate the failure • Run each protocol till its tree recover • Collect recovery’s results. • Print statistics.

16. Agenda • Project Definition • Implementation • Test Plan • Results • Main Conclusions • General Observations

17. Test’s Parameters • All the net’s member possibilities are represented as a pair of (Bridge_Num , LAN_Num ) : • Dense networks : { (2,6), (5,10) , (8,15) ,(10,17) , (12,25) , (15,30) } • Sparse networks : { (2,2), (5,5) , (8,8) ,(10,10) , (12,12) , (15,15)} • Bridge’s parameters (following the Cisco configuration) : • Forward delay = 15000 ticks • Max age = 20000 ticks • Hello time = 2000 ticks.

18. Performance's Criteria Case: - Packets’ lost probability = 0 : • Average Initialization time • Average number of BPDUs’ that were sent during initialization • Average recovery time • Average number of BPDUs’ that were sent during recovery Case: - Packets’ lost probability =! 0 : The same without the recovery information

19. Agenda • Project Definition • Implementation • Test Plan • Results • Main Conclusions • General Observations

21. Recover Time in Sparse Networks • Immediate conclusions: • RSTP recovers much faster than STP

23. Recover Time in Dense Networks • Immediate conclusions: • RSTP recovers much faster than STP • Recover time is similar to that in sparse networks.

25. BPDUs Num sent during Recovery Time in Sparse Networks • Immediate conclusions: • RSTP requires less BPDU to achieve stability • This is caused mainly because the recovery time is much faster .

27. BPDUs Num sent during Recovery Time in Dense Networks • Graph Explanation: • RSTP requires less BPDU to achieve stability • Dense network requires much more BPDUs to stabilize.

28. Agenda • Project Definition • Implementation • Test Plan • Results • Main Conclusions • General Observations

29. Conclusions • Recovery– RSTP recovers significantly faster than STP , less significantly better in BPDUs count • Dense and Sparse networks– We did not find any critical differences except the expected gap between BPDUs count • Packet Lost Probability– both protocols act as usual as long as the the probability is less than 10%. Both protocols stability is not guaranteed over ~60%.

30. Agenda • Project Definition • Implementation • Test Plan • Results • Main Conclusions • General Observations

31. Observations • The uplink fast feature in the RSTP can improve if it will use the “Back Up” port feature in addition to the “Alternate” port feature • RSTP’s initialization’s performances can be increased significantly through appropriate configuration (“slow” transition avoidance) • Attention to the fact that RSTP recovers faster than STP which is a very important thing in today networks. RSTP “pays” in increased BPDUs count which is less important due to today possible band width. • Additional tests could explore more deeply the affects and the exact legal range of values of Packet Lost Probability for each protocol .

32. Old Foils

34. Initialization Time in not busy Networks • Graph Explanation: • Similar initialization times in medium and large size Networks,with slight advantage to the RSTP protocol • In small Networks RSTP builds the tree much faster • As expected, a long Forward Delay lengthens the initialization time.

36. Initialization Time in busy Networks • Graph Explanation: • Similar initialization times in medium and large size Networks,with slight advantage to the RSTP protocol • In small Networks RSTP builds the tree much faster • As expected, a long Forward Delay lengthens the initialization time. • Initialization time is similar to that in not busy networks.

40. BPDUs Num sent during Initialization Time in not busy Networks • Graph Explanation: • Linear growth in bpdu sent during initialization in relation to the network size in both protocols • RSTP sends much more BPDUs because of levels of distribution.

42. Bpdus Num sent during Initialization Time in busy Networks • Graph Explanation: • Linear growth in bpdu sent during initialization in relation to the network size in both protocols • the gap between the number of BPDUs in RSTP and STP is not as big in busy networks.