1
2
3
4
5
6
7
Introduction ................................................................................................................. 3
1.1
WHY DO WE NEED SPANNING TREES ....................................................... 3
1.2
The 802.1d and 802.1w protocols. ...................................................................... 3
1.3
Major Differences. .............................................................................................. 3
1.4
The goals of the project....................................................................................... 4
Implementing the two protocols: .................................................................................... 4
Comparing between the protocols: ................................................................................. 4
Way of Implementation. ............................................................................................. 5
2.1
General ................................................................................................................ 5
2.2
Input .................................................................................................................... 5
2.3
Network Building................................................................................................ 5
2.4
Simulation ........................................................................................................... 6
INDEXES FOR COMPARING BETWEEN THE PROTOCOLS ............................ 7
We will examine 4 cases. ................................................................................................ 7
3.1
The 4 cases. ......................................................................................................... 7
Modules....................................................................................................................... 8
4.1
General Module Interaction ................................................................................ 8
4.2
Net Manager Module .......................................................................................... 9
4.2.1
General ........................................................................................................ 9
4.2.2
The Net Building Algorithm ..................................................................... 10
4.2.3
Main Loop ................................................................................................. 11
4.3
Bridge Module .................................................................................................. 12
4.3.1
Main Functionality .................................................................................... 12
4.3.2
Main Fields of “Class Bridge” .................................................................. 12
4.3.3
Main Methods of "Class Bridge" ............................................................. 13
4.4
Port Module ...................................................................................................... 13
4.4.1
Main Functionality .................................................................................... 13
4.4.2
Main Fields of "Class Port" ..................................................................... 13
4.4.3
Main Methods of "Class Port" : ............................................................... 14
4.5
Lan Module ....................................................................................................... 14
4.5.1
Main Functionality .................................................................................... 14
4.5.2
Main Fields of "Class Lan" ...................................................................... 14
4.5.3
Main Methods of "Class Lan".................................................................. 15
The GUI Module ....................................................................................................... 15
5.1
General .............................................................................................................. 15
5.2
The Screen ........................................................................................................ 15
5.3
Output ............................................................................................................... 16
Tests Module............................................................................................................. 16
6.1
General .............................................................................................................. 16
6.2
Data Structures .................................................................................................. 16
6.2.1
TestScenario .............................................................................................. 16
6.2.2
TestSingleFailure ...................................................................................... 16
6.3
Main Functions: ................................................................................................ 17
6.3.1
TestInitTestModule ................................................................................... 17
6.3.2
TestCreateFailure ...................................................................................... 17
Monitor Module ........................................................................................................ 17
7.1
Main Functionality : .......................................................................................... 17
7.2
Main Fields of "Class Monitor" : ..................................................................... 17
7.3
Main Data Structures used in "Class Monitor" : ............................................... 18
7.4
Main Methods of "Class Monitor" :................................................................. 18
8 Milestones ................................................................................................................. 18
1 Introduction
1.1 WHY DO WE NEED SPANNING TREES
In today’s network there is a great demand for efficiency.
The goal is to reduce the time one data packet stays in the network before
it arrives successfully to its target.
Let the network be a connected graph with circles.
Movement of data packets in this graph can create:
A. Movement in loops – will increase the average service of one
packet.
B. The average number of packets in the network will increase –
probably will cause more collision.
C. There could be more than one run between two points – so if the
bridges manage data bases in order to make efficient the routing,
There could be contradiction in the db(two options for one target).
Representation of the network as a spanning tree solves/reduces these
problems:
A. There aren’t loops in spanning tree.
B. The average time of packet in the network will reduce – and a
result there will be less collisions
C. Only one run between ant two points.
1.2 The 802.1d and 802.1w protocols.
The 802.1d, the old protocol who initializes and maintains the
spanning tree. The problem with this protocol is it’s relatively long
recovering time – a minute or so.
Due to the mentioned problem the 802.1w protocol was developed.
It is based on the 802.1d but with changes that suppose to reduce
the recovering time.
1.3 Major Differences.
The major difference between these two protocols is found in their distribution
level.
RSTP's bridges are fully distributed while STP's bridges agrees on a root port
which acts different then the other bridges and "takes" the responsibility for the
network's connectivity.
Other differences (the details are found in the protocols' specification) :
- RSTP defines roles for the ports.
- RSTP defines new BPDU format (STP discards this BPDU version)
- within this format RSTP introduces the Proposal/Agreement mechanism
- BPDU's handling is different in each protocol - in STP only the root port
injects BPDUs to the network ,while in RSTP all the bridges that
participates in the tree generates BPDUs.
- Convergence is performed differently for each protocol :
STP uses timers for this process while RSTP uses the "sync mechanism".
- Recovery from topology change :
In STP the bridge that detects the topology change "tells" it to the
root which passes this information to the other bridges while in RSTP
every bridge "tells" its neighbors when it is aware of a topology change.
- RSTP introduced these new features :
- Rapid Transition To Forwarding State -enabled with the new
variables : Edge Ports , Link Types.
- Uplink Fast - enabled with the distinction between port roles uses Alternate ports.
1.4 The goals of the project
Implementing the two protocols:
We intend to do this , with emphasis on the characters that causes the
difference between the two protocols(in the next goal – the comparing).
Comparing between the protocols:
Will be carried out with several indexes , which will be explained later.
2 Way of Implementation.
2.1 General
This section describes the general approach to the implementation of the
project. It will include information about the input handling, Network
creation and the simulation.
2.2 Input
The GUI Module will handle the input entering by the user.
The user will have the possibility to enter a few parameters. These will
determine the sequence of tests that will be performed accordingly.
The parameters are:
1. Network topology type. (Star, ring, random, all, other…)
2. Range of the number of bridges in the network. (Between XX-XX)
3. Range of the number of segments (LAN's) in the network. (Between
XX-XX)
4. Number of bridge break downs.
5. Number of port break downs.
6. Number of link add-ons.
7. Packet loss probability.
8. Number of tests. (How many times steps 1-7 will be performed)
Few remarks about the algorithm:
- The GUI will enable only “logical” parameters. For example, when a
user
picks star or ring topology, he will pick only the number of bridges.
- The input will be processed, the number of bridges and segments will
be
randomly determined within the range typed, and a network will be built
according to the topology picked. (Could be more than one)
- The other parameters will be transferred to the Tests Module that
generates the tests.
2.3 Network Building
The net work is built according to the input entered. The Bridge Objects and
LAN Objects will be initialized in the amount determined with no
connections. Incase, this is a “Regular Topology” the bridges will be
connected accordingly in random order.
Incase, the Network is random the following algorithm will used:
1. On every iteration an object from the “not yet used list” is picked.
Alternatively, a bridge then a LAN. This object will be connected to
current network already created by the former objects that were picked.
2. When a bridge is picked, the number of ports that will be connected is
randomly set. every port is then connected randomly to the LANs
available.
3. When a LAN is picked, the number of ports that it will be connected to is
randomly set. every port is then connected randomly to this LAN.
4. this is done until all the objects are connected together.
Few remarks about the algorithm:
-
-
This algorithm ensures connectivity.
The algorithm always “keeps to himself several” random ports to avoid
a situation that all the ports are occupied when a LAN object is
connecting to the network.
The algorithm determines “Edge Ports”.
Unconnected ports in the end of the algorithm are put in not connected
mode.
2.4 Simulation
Now that the Network is defined and ready to operate, and the test
settings are determined, a simulation is run by the “Net Manager” Module.
This module manages the sequence of the tests and the actual simulation
of the protocols. Every test is done for the STP protocol and the RSTP
protocol for comparison.
This Module also manages the “Virtual Clock” Timer, which triggers all
operations in a synchronized way. On every “tick” of the timer, the network
performs all actions regarding one iteration in the STP/RSTP protocol, and
the Net Manager performs actions regarding the current test running, like
adding a link or “disabling” a port.
During the test sequence, the Net Manager informs the “Monitoring”
Module with all relevant information about the tests results.
Finally, after the whole sequence is over the Monitoring Module holds the
results of the tests and outputs them to the user.
In the following sections, every module will be specifically described and
explained in details.
3 INDEXES FOR COMPARING BETWEEN THE
PROTOCOLS
We will examine 4 cases.
Each case will have 4 sub cases , creating from two parameters –
1. with or without the possibility a message will lose
2. comparing by the time from the beginning of the scenario till the tree is
stable , or by the number of BPDU(will explain later) messages that have
been broadcasted in the entire network.
There are 4 possibilities of combining theses two parameters – and these a
Are the 4 sub cases.
3.1 The 4 cases.
- Initialization:
From the input of random network( represented as connected
Graph of LANs and bridges) , till the spanning tree is stable.
The next 3 cases deals with topology change:
- Recovering time from falling of random bridge :
Again , till there is new stable bridge.
- Recovering time from falling of random port in random bridge.
- Stabling new bridge after adding a random link –
after ANY topology change there is a possibility that the bridge should
be changed.
4 Modules
4.1 General Module Interaction
Net
Manager
GUI
Monitor
Bridge
Objects
Port
Port
Test
Module
LAN
objects
4.2 Net Manager Module
4.2.1 General
This module is the main module that carries out the following functions:
- Activating the GUI module.
- Initializing all Data Structures accordingly:
Bridge Objects
LAN Objects
Monitoring data structure
- Initializing the Global Clock.
- Calling the Net Building Algorithm. Two identical networks are created,
so that the same tests will run identically on both protocols.
- Managing the “Main” loop of the simulation.
Run the tests.
Simulate the protocols
Advance the Global Clock
4.2.2 The Net Building Algorithm
The next flow chart describes this algorithm.
Choose
which ports
will be
connected
Bridge
Start:
Choose an unused bridge
or LAN alternatively.
Start with Bridge.
LAN
Decide from
the free used
ports, which
ones will
available for
the LAN
Connect them to
the available
LANs
Choose how
many ports will
be connected.
Mark the
unconnected
ports as free
used ports
Choose which of
the available
ports to connect
Mark the Bridge
as used
Go To Start
Mark the LAN
as used
4.2.3 Main Loop
Start
Create identical Networks for
each Protocol
Yes
Any more Tests to
run?
Is the tree stable?
No
Generate
new failure
No
Yes
Current protocol
RSTP?
Each LAN posts its
packets for this iteration
Yes
No
Each Bridge Rx\Tx its
packets for this iteration
Re-Initialize clock
and Data Struct’s
Global Clock Tick
Run the same
scenario with STP
No
Produce Results to
user
Any more Cycles?
Yes
Go To Start
4.3 Bridge Module
4.3.1 Main Functionality
Holding and managing all the data structures and features which are
needed in order to support running of the STP/RSTP protocols by the Net
Manager Module.
Basically, it performs these actions:
-Receiving messages through its ports every virtual clock's
sequence.
-Making operative decisions due to analyzing of the existing
information and the new information arrived at the relevant clock
tick.
-Sending messages through its ports on every clock's sequence.
Remarks:
- The bridge may be STP/RSTP Bridge, depending on its ports'
mode.
- By its capabilities and of course with a generous help from the Net
Manager Module, a bridge is actually communicates with other
bridges while the protocol using is determined by the mode of each
port.
- This approach enables supporting backward compatibility (from
RSTP's side).
- The algorithms for the bridge's features (mainly processing the
messages) are of course 802.1D and 802.1W.
4.3.2 Main Fields of “Class Bridge”
-bridge_id - Bridge's identity (also used as MAC address).
-bridge_prio - Bridge's priority.
-routing_table - Not used (exist only for compatibility with the protocols).
-root_bridge_id - Root Bridge identity.
-root_bridge_prio - Root Bridge priority.
-path_cost .
-port_table[N] - Port's array.
-number_of_ports.
-root_port - The number of the port which holds this role.
-expected_hello_timer - When this timer expires the bridge "thinks" that it
lost connectivity to the root bridge.
-is_stable - Boolean variable , TRUE indicates that all the ports are
stable.
-in_tree - Boolean variable , TRUE indicates that the bridge participates in
the tree (relevant only when is_stable = TRUE).
-tc_timer - While this timer is running BPDU's are sent with the tc bit set.
-proposal_timer - Relevant only for RSTP , while this timer is running
BPDU's are sent with the proposal bit set.
-BPDU_rank[num' of ports][max age] - This two dimensions array holds for
each port the last |max age| BPDUs received.
4.3.3 Main Methods of "Class Bridge"
-BridgeInit - Bridge's initialization.
-BridgeReadAndProcess - This method is called by the Net Manager for
each bridge at the end of the clock sequence. For each message the
bridge performs the needed actions (timers , flags...).
-BridgeGenBPDU - Generation of BPDUs due to the bridge's flags ,
timers and state.
-BridgeSend2Port - Adding message to the port's messages' link list . This
method is called in a port context.
-BridgeDisable - Enables bridge break down.
4.4 Port Module
4.4.1 Main Functionality
This module is basically owned by the bridge module (that is in fact where
the port is placed).
The main purpose of this module is attaching the bridge it serves to a Lan.
Another way to explain the port's role is looking at the network as a "two
sides" graph . In this case one set of verticals includes the LANs and the
other set includes the Bridges while the ports are the edges between
both sides.
4.4.2 Main Fields of "Class Port"
-port_id - Port's serial number.
-port_state - Possible states : Discarding , Listening , Learning ,
Forwarding , Disabled (It supports both STP/RSTP).
-port_role - Possible roles : Unstable , RootPort , Designated , Alternate ,
Backup.
-is_edge_port - Configured during the network creation.
-mode - STP/RSTP.
-lan_id - The serial number of the Lan attached.
-messages - Linked list containing messages to send from the Bridge to
the Lan.
-port_cost
4.4.3 Main Methods of "Class Port" :
-PortInit - Initialization of a Port.
-PortAddMessage - Addition of a message to "messages" linked list.
-PortDisable - To allow port break downs.
4.5 Lan Module
4.5.1 Main Functionality
This module performs mainly these actions :
- Advertising the messages which are found in the head of its
messages' queue .
This action takes place at the beginning of the clock sequence.
Remark : The amount of the messages released at each iteration
depends on the Lan's rate.
- Obtaining the messages from the ports attached.
This action takes place at the end of the clock sequence and is
performed randomly (giving an equal chance for all the ports).
4.5.2 Main Fields of "Class Lan"
-lan_id - Lan's serial number.
-lan_rate - The maximum amount of messages advertised at each clock's
tick.
-lan_cost - Determined due to the rate.
-messages_queue - A link list which holds the messages which entered
the Lan.
-max_ports - Maximum number of ports that can be attached to the Lan.
-ports_num - Number of ports currently attached.
-ports_list - Linked list of the attached ports (Bridge+Port in each node).
4.5.3 Main Methods of "Class Lan"
-LanInit - Lan's initialization.
-LanGetMessages - Obtaining the "ready to be send" messages from the
relevant ports.
-ReadLanMessages - This method is called by the relevant bridges and it
releases the appropriate amount of messages for reading.
5 The GUI Module
5.1 General
The GUI Module is the interface that allows the user to determine the test
parameters.
5.2 The Screen
After the user enters the parameters and clicks on the START button, the
inputs will be checked to ensure that we can build a logical Network and
the TestScenario Struct is initialized.
5.3 Output
All the data collected in the “monitoring” module from all scenarios is
gathered and displayed to the user.
6 Tests Module
6.1 General
The test Module is in charge of maintenance of the “tests” that will be
performed. When the Net Manager decides to perform a test, it will
approach this Module and will get the malfunction to the network.
6.2 Data Structures
6.2.1 TestScenario
Main fields:
Network_topology_type
Num_of_working_bridges
Num_of_segments
Num_bridge_break_downs_left
Num_port_break_downs_left
Num_of_link_add_ons_left
loss_prob
Num_of_cycles
Cycle_number
The values will be initialized to the one received by the GUI screen and
will be updated after every test.
The main functionality of this structure is to hold the tests that the Net
Manager decides to run.
6.2.2 TestSingleFailure
Main Fields:
Type_of_failure
Bridge_id
Port_id
Lans_connected_list
Every failure that will be decided on will be documented in a
TestSingleFailure Object.
During one cycle of the scenario, the total of these failures will be
organized in chronological connected list. every scenario will have its own
independent list.
This is done for a few reasons. First, to make sure that the same
malfunctions are done in the same order in both the STP and RSTP
protocols. Second, in order to document the whole scenario.
6.3 Main Functions:
6.3.1 TestInitTestModule
Will init the TestScenario Structure and an empty TestSingleFailure
connected list.
6.3.2 TestCreateFailure
This function will be called by the Net Manager.
It will randomly decide which malfunction will happen next, including the
kind of test and id of the bridge or port that will be involved.
The function will create the relevant TestSingleFailure Struct to the
connected list.
Each time a test is finished, the next malfunction required by the Net
Manager will be generated from the possible ones left in the data
structure.
7 Monitor Module
7.1 Main Functionality :
Holding and updating the data structures which reflect the networks' (STP
and RSTP ) performances.
7.2 Main Fields of "Class Monitor" :
-num_of_tests - Entered by the user.
-num_of_bridge_break_downs - Entered by the user.
-num_of_port_break_downs - Entered by the user.
-num_of_new_links_addition - Entered by the user.
-tests_array[num_of_tests] - This array holds all the performance
parameters. Its size is determined by the user so its memory is allocated
during run time (like all the coming arrays which their size is a user's
input).
Each entry is dedicated to a test and it contains all the information that
was collected during the test.
Each entry is a struct which has two fields both instances of "struct
Session" - one instance represents the STP network and the other the
RSTP network.
7.3 Main Data Structures used in "Class Monitor" :
-Struct Session - This struct has two fields both instances of "struct
TestInfo" one for a test with a probability to lose BPDUs and the other for
the same test with probability = 0.
-Struct TestInfo - This struct has these fields :
-init_node - Variable of type : struct PerfNode.
-bridge_breaks[num_of_bridge_break_downs] - Array
of type : struct PerfNode .
-port_breaks[num_of_port_break_downs] - Array of
type : struct PerfNode .
-link_adds[num_of_new_links_addition] - Array of
type : struct PerfNode .
-Struct PerfNode - This struct has these fields :
-virtual_time - The time counted for
recovery/initialization.
-num_BPDUs - The number of BPDUs which are sent
to the Lans during recovery/initialization.
7.4 Main Methods of "Class Monitor" :
- MonitorInit - Initialization of this module.
- MonitorUpdate - The Net Manager module calls this method when there
is an information to collect.
- MonitorShowPerformance - This method prints all the collected
information.
8 Milestones
1. Main Modules Definitions and Implementations 3.12.2002
2. Modules first Integration. 7.12.2002
includes Generation \ Transmission of packets through the network.
3. Protocols Features Implementation: 24.12.2002
a. Tree creation (includes Proposal \ Agreement for RSTP)
b. Inserting Heart Beats timers –failure detection.
c. Convergence and TC mechanism.
4. RSTP features: 27.12.2002
a. Rapid Transition to forwarding.
b. Uplink fast.
5. Compatibility . 3.1.2003
6. GUI and Test flow. 7.1.2003
7. Running tests, collecting performance data and analyze it. 14.1.2003
8. Editing the Final Report. 19.1.2003
9. Final Report submission. 19.1.2003