Modeling and Simulation of A Spanning Tree Bridge Protocol with Enhanced Forwarding Paths*

King-Shan Lui, Klara Nahrstedt Department of Computer Science University of Illinois, Urbana-Champaign Urbana, IL 61801 E-mail: kinglui@uiuc.edu Abstract The IEEE 802.1D Spanning Tree Protocol has been used widely for bridges and switches to interconnect local area networks and workstations. It builds a rooted shortest path tree among the bridges for frame forwarding. In this paper, we present the modeling and simulation of a method for enhancing the performance of the 802.1D standard protocol. This method identifies enhanced forwarding paths between bridges. We identify some advantages and problems in building our model using OPNET**. Introduction Bridges are interconnection devices to connect several Local Area Networks (LANs) together to form an extended LAN. They operate on top of the Medium Access Control (MAC) layer. The basic function of bridges is to forward MAC frames from one LAN to another without requiring any modification to the communication software in the end systems. Upperlayer protocol transparency and fast processing are the primary advantages of bridging. IEEE 802.1D Spanning Tree Bridge Protocol is a widely used bridge standard for interconnecting the family of IEEE 802 standard LANs [1]. In this standard, a shortest path spanning tree rooted at a particular bridge is used to forward frames among LANs. This rooted spanning tree defines a unique path between a pair of LANs but this path may not be shortest. To enhance the delay performance, we have devised a new protocol, referred to as the Spanning Tree Alternate Routing (STAR) Bridge Protocol [2]. This protocol works seamlessly with the standard protocol and contains all functions that standard bridges have. Through exchanging messages, the STAR Bridge Protocol can identify links that are not used by the standard to form shorter forwarding paths that have smaller delay. Whay Chiou Lee Broadband Networks Research Lab. Motorola Labs Mansfield, MA 02048

In this paper, we describe the modeling and simulation of the STAR Bridge Protocol using the Spanning Tree Bridge (STB) model in OPNET. We discuss how we extend the STB model and resolve some problems that we encountered in OPNET modeling. We will also present some simulation results. Standard and STAR Bridge Protocols Standard bridges build a rooted spanning tree among themselves by exchanging control messages, called Bridge Protocol Data Units (BPDUs). Based on the information carried in the BPDUs, a standard bridge will activate or deactivate forwarding ports to build the tree. For example, Figure 1(a) is an extended LAN where B0, B1, B2 and B3 are bridges connecting four different LANs. Figure 1(b) illustrates the spanning tree rooted at B0. The standard defines the state transition of forwarding ports and a timeout mechanism is used to determine when a state transition should happen. After the tree has been built, data frames are forwarded over the tree. However, a tree path, i.e., a path utilizing only links on the tree, may not be a shortest path. In Figure 1, the tree path from LAN C to LAN D is longer than the shortest path.
B0
LAN A LAN B
LAN A

B0
LAN B

B1
LAN D

B3
LAN D

B1

B3
LAN C

LAN C

B2

B2

(a)

(b)

Figure 1: Rooted Spanning Tree

The work is supported by Motorola Inc. through the Broadband Network Research Lab and the Motorola Center for Communications at the University of Illinois at Urbana-Champaign. ** OPNET is a trademark of Mil3, Inc.

In order to identify enhanced forwarding paths, STAR bridges exchange STAR Bridge Protocol Data Units (SBPDUs) for distance information. STAR bridges use a distance vector mechanism to find enhanced forwarding paths among them after the rooted spanning tree has been built. An enhanced forwarding path between two STAR bridges is an alternate path that is a non-tree path and is shorter than the corresponding tree path between the two STAR bridges. If the shorter alternate path traverses any link that is not on the tree, we refer to the link as a crosslinks. Every STAR bridge first finds its distance to other STAR bridge neighbors, either through tree paths or crosslinks, and then sends out the distance information to its neighbors. For example, if bridge B connects to both bridge A and bridge C, bridge B will tell A the distance between B and C. When A receives the information, it can calculate its distance to C going through B. There are several phases in the STAR bridge protocol. Different SBPDU messages are sent and received in different phases. STAR bridge is in different states during different phases. This is different from the standard protocol. In the standard, only port state transition is defined, but not bridge state transition. However, STAR bridge protocol has both port and bridge state transitions.
Enhanced (5) (4) (1) Tree Learning (4) Tree Learned Starting state

will transit to the Tree Learned state. A timer is started when this transition happens. STAR bridges will start sending out SBPDUs to identify STAR bridge neighbors. When the timer expires, the STAR bridge goes to the Neighbor Distance Found state. The timer is reset upon this transition. In this state, STAR bridges send out neighbor distance information to other STAR bridge neighbors and receive distance information from its neighbors to find out the distances to all non-neighbor STAR bridges in the extended LAN. When the timer expires again, the STAR bridge goes to the Enhanced state. In this state, shorter alternate tree paths have been identified and can be used for frame forwarding. A STAR bridge can forward data frames on shorter alternate paths only when it is in the Enhanced state. Tree paths are used when the STAR bridge is in other states. The standard protocol has a mechanism to detect topology changes in the extended LAN. When a bridge finds out that the tree topology has changed, it will send out Topology Change BPDUs to inform other bridges. The rooted spanning tree is then rebuilt. In the state transition diagram, a STAR bridge goes back to Tree Learning state whenever it receives a Topology Change BPDU. If a crosslink that is used for an enhanced forwarding path goes down, it affects only the enhanced forwarding path but not the tree path. In that case, it is not necessary to recompute the tree, but only to recalculate the distance vector. Therefore, when a crosslink fails, a STAR bridge goes back to the Tree Learned state and starts to find alternate paths again. As shown in Figure 2, there are two different kinds of events that trigger a change of state in the STAR bridge protocol: timeout and receipt of a Topology Change BPDU. These two kinds of events are modeled differently in OPNET and will be described in the following section. STB Model OPNET has a library model for IEEE 802.1D standard protocol STB Model. It consists of three processes: a parent process that handles a received frame and two child processes that handle BPDUs and data frames, respectively. The parent process, dispatch process, maintains two frame queues, one for BPDUs and one for data frames. It is responsible for identifying the frame type and put the frame in an appropriate queue. The BPDU handling process changes the port states according to the standard. The data frame relaying process forwards data frames over activated tree ports. Since the IEEE standard defines a state transition of ports but not a state transition of bridges, the finite state machine (FSM) of the BPDU handling process models the BPDU queue and the timeout, but not a bridge state transition. As the design of how to handle SBPDUs in STAR bridges is based on the BPDU handling process, we will describe this process in more details. Figure 3 is the OPNET FSM of the BPDU handling process. To distinguish a state in an OPNET FSM from a state of a

(3)

(4) (5) (2)

Neighbor Distances Found

(1) Rooted spanning tree found (timeout) (2) Distances to neighbors found (timeout) (3) Distances to all STAR bridges found (timeout) (4) Tree topology changes (5) Crosslink fails Figure 2: STAR Bridge State Diagram Figure 2 is the state diagram of STAR bridges. When a STAR bridge starts up, it is in the Tree Learning state, indicating that the STAR bridge is forming the rooted spanning tree with other bridges in the extended LAN. In this state, STAR bridges will receive only BPDUs according to the standard protocol. When the standard tree is built, the STAR bridge

bridge in Figure 2, we use FSM state to refer to a state in an OPNET FSM. In FSM state init, variables are initialized. After the initialization, an STB bridge will go to the idle FSM state. As the name implies, this FSM state refers to the situation that the bridge is idle, that is, it is not processing and there is no BPDU waiting to be processed. When a BPDU is received, the bridge goes to the busy FSM state to process the frame. The bridge will stay in that FSM state if there are some other BPDUs in the queue. It goes back to the idle FSM state after it processes the last BPDU in the queue.

SBPDU handling process. The first one is to build the FSM of the process according to the bridge state transition in Figure 2. The second choice is to keep the bridge states as variables, which is similar to how STB keeps port states. We refer to the first implementation method as FSM-based and the second one as variable-based. There are advantages and disadvantages of these two options. If we use FSM-based method, the bridge state transition is known by simply opening up the process model, without going into the codes and tracing the functions and variable assignment statements. As a STAR bridge would receive different SBPDUs in different states, by using FSM-based method, the codes would be simpler because some if-else statements are done implicitly by the FSM. Unfortunately, the translation from the bridge state transition diagram to an FSM is not simple. In order to model the bridge state diagram using OPNET FSM, we have to represent bridge states and state transitions using FSM states and FSM transitions. Figure 3 is the BPDU handling process and it is an FSM of a bridge that is always in the same bridge state (no bridge state transition). Two FSM states are needed to model a single bridge state because of the invocation mechanism. The dispatch process may or may not invoke the BPDU handling process when a BPDU is received. It depends on whether the child process is idle. For each bridge state, there are two scenarios: the bridge is busy, or the bridge is idle. Each of these scenarios is modeled as an FSM state. As a result, for each of the bridge states in Figure 2 that would receive SBPDUs, that is, all except Tree Learning, we need two FSM states to model one STAR bridge state. This requires the FSM to have at least 7 FSM states. However, this is not completed yet. As we mentioned earlier, there are two events that trigger a bridge state transition: receipt of a Topology Change BPDU and timeout. While modeling the receipt of a BPDU is not difficult, modeling the timeout, or more precisely, a timer reset after timeout, needs an extra FSM state. There are two reasons why an extra FSM state is needed. First, timer reset cannot be done using an FSM transition, which is only a condition check. Second, we cannot put the timer reset in any code box of the FSM states that represent a bridge state. This is because the timer should be reset only after it expires. If we reset the timer in a code box, say, in FSM state idle in Figure 3, since FSM state idle would be entered more than once before the timer expires, the timer would be reset prematurely, making the protocol run incorrectly. Therefore, a separate FSM state is needed for timer reset. Since we need two FSM states for most of the bridge states and we need another FSM state for each timer reset, the total number of FSM states to model the STAR bridge state transition diagram is 9. As there are two FSM states for a bridge state, two FSM transitions are needed for a bridge transition. This leads to over 20 FSM transitions needed in the complete FSM. This complicated FSM is not likely to be planar and not easy to draw or understand. There is yet

Figure 3: BPDU Handling Process In the STB model, variables are used to keep track of the bridge port states. We call these variables port state variables. Port state variables are shared by all processes in the STB model. There are two events that lead to a change of port state: timeout and receiving a Topology Change BPDU. These two events are the same as those which trigger a change of STAR bridge states. A BPDU is processed in the busy FSM state. As a result, the port state variables are changed in the busy FSM state when a Topology Change BPDU is received. Timeout is handled in a different manner. In OPNET, a time interrupt event indicates a timeout. As shown in Figure 3, when timeout occurs, the bridge transits to the Timer_pr FSM state. The port state variables will be updated in the Timer_pr FSM state. The bridge goes back to either idle or busy FSM state after the timeout has been processed. STAR Bridge Protocol Model In this section, we discuss how we extend the STB model to implement the STAR Bridge Protocol in OPNET. In order to utilize what the STB model provides, we follow the design of STB and avoid making changes to the existing FSMs. The following two entities in STAR are absent in STB: SBPDUs and bridge states. For SBPDUs, as STB puts different frames into different queues and handles them using different processes, in STAR, apart from the original processes that are in the STB model, there is one more child process that is responsible for SBPDU processing in our implementation. In the rest of this paper, we call this new process SBPDU handling process. For the bridge states, we model the transition in the SBPDU handling process since a STAR bridge must send and receive different types of SBPDUs in different bridge states. We have two choices in implementing the bridge state transition diagram in the

another reason why FSM-based implementation is not used in our implementation. As the bridge state also affects how a data frame is forwarded, if we do not want to modify the FSM of the data frame relaying process, we need to keep the bridge states as variables. As we still need variables for other processes even after building a complex FSM we decided to use the variable-based implementation. As the BPDU handling process is also variable-based, we can design the SBPDU handling process FSM based on the FSM of the BPDU handling process. In the following, we describe the SBPDU handling process and how we modify the processes in STB. Dispatch Process: This is the parent process of the model. In addition to the BPDU queue and data frame queue, one more queue is used for keeping SBPDUs received. Similar to how the STB Model dispatch process handles BPDUs and data frames, when this process receives an SBPDU, it first checks whether the SBPDU handling process is busy. If so, it puts the newly received SBPDU in the queue; otherwise, it invokes the SBPDU handling process. BPDU Handling Process: This process is responsible for handling BPDUs. All BPDUs are handled in the same way as the standard does. This process also determines when a rooted spanning tree is successfully built. After the tree is built, a STAR bridge will send an SBPDU on each of the tree ports. There are two purposes of sending out this SBPDU frame. First, it informs neighboring STAR bridges about the identity of the STAR bridge that sends the frame; moreover, it informs the SBPDU handling process to start the timer.

first SBPDU in FSM state busy. Once the SBPDU handling process is in FSM state busy, the FSM works similar as the FSM in the BPDU handling process. When timeout occurs, the process changes the bridge state variable accordingly. Data Frame Relaying Process: This is the child process of the model that forwards data frames. In STB, a table is used to store the forwarding directions of different destination addresses. In STAR, there are several tables and the bridge state governs which table should be used. Therefore, before processing a data frame, we first check the bridge state and call different functions to process the frame. OPNET Modeling Advantages and Problems We have described in the last section how we model our STAR bridge protocol. In this section, we discuss the advantages and problems of using OPNET for running simulations of the STAR bridge protocol. The major advantage of using OPNET is that it saves a lot of time in implementation. OPNET is well-documented and has a good technical support service. We find that learning OPNET is not difficult. Since OPNET provides traffic profiles and measurement mechanisms, we do not have to model processes for generating traffic and measuring packet delay in the simulation. All we need to do is to implement the protocol. Moreover, OPNET has already an STB model. Therefore, when we build a model for the STAR bridge protocol, we do not have to implement the whole protocol, but only the extension to the standard. Although we need to spend time in understanding how the STB is designed and written, the time spent on understanding the existing codes is definitely less than the time it takes to write the codes ourselves. A problem, that we encounter, is related to the STB implementation. SBPDUs are newly defined frame types. Bridges, that do not understand the STAR bridge protocol, i.e. the standard bridges, would drop the SBPDUs that transit. To avoid this, SBPDUs are encapsulated as data frames so that standard bridges would forward them. When an SBPDU is encapsulated, the whole SBPDU frame is carried as the data field of a data frame. The destination address is the MAC address of the intended STAR bridge recipient. In the standard, this bridge MAC address is unique across the bridged LAN that the bridge resides in. It should be different from the addresses of all end stations in the same bridged LAN. Without this property, an encapsulated SBPDU cannot get to the intended destination STAR bridge. However, we realized that in OPNET, a bridge and a LAN could have the same address. It is because the bridges and the LANs are running address resolution mechanism independently and they both start numbering entities from zero. As a result, the first created bridge would have the same address as the first created LAN in the scenarios, violating the feature specified by the standard. Fortunately, according to the

Figure 4: SBPDU Handling Process SBPDU Handling Process: Figure 4 is the FSM of the SBPDU handling process. It is formed by adding FSM state tree_learning to the FSM of the BPDU handling process. SBPDU handling process is in FSM state tree_learning when the STAR bridge is building the spanning tree. The timer is started when the process leaves FSM state tree_learning. The process leaves the tree_learning FSM state when the STAR bridge receives the first SBPDU. This SBPDU is sent by the BPDU handling process. The STAR bridge then processes the

standard, each port of a bridge also has a unique address and this address is different from the addresses of the LANs. OPNET does ensure this feature by assigning addresses to LANs and ports from the same address pool. As a result, to fix the address conflict problem among bridges and LANs, we can assign the bridge address to be the address of port 0 of the bridge. Simulation Study

Figure 6: Voice Packet Delay (sec)

Figure 5: Test Scenario We have built a simple bridged LAN scenario to run simulations of the STAR bridge protocol model and we measured the end-to-end delay performance of multimedia applications. Figure 5 shows the topology that we used. If all bridges are standard bridges, the traffic from LAN 2 to LAN 3 will go through B2, LAN 1, STD B0, LAN 0, B1 and then finally LAN 3. If we replace B1 and B2 to be STAR bridges, the path from LAN 2 to LAN 3 will be LAN 2 B2 LAN 4 B1 LAN 3. As this path is shorter, the delay of frames should be smaller. We verify this by running multimedia applications on both LAN 2 and LAN 3 and measure the endto-end packet delay. We put one LAN user on LAN 2 and LAN 3 respectively. They are both default multimedia users defined by OPNET who run video conferencing application with low resolution. The duration of the simulation is 2 minutes. Figure 6 shows the voice packet end-to-end delay and Figure 7 shows the video packet end-to-end delay of two scenarios during the 2-minute period. These metrics are provided and measured by OPNET. 2STAR_1STD_4L_2to3 is the scenario when B1 and B2 are STAR bridges, while in 0STAR_1STD_4L_2to3, all bridges are standard bridges. In the beginning of the simulation period, 2STAR_1STD_4L_2to3 has a larger delay due to the overhead of the STAR bridge protocol. However, after shorter forwarding paths are found, the delay performance becomes better than 0STAR_1STD_4L_2to3. Therefore, we may conclude that the STAR bridge protocol has been implemented correctly.

Figure 7: Video Packet Delay (sec)

Conclusion In this paper, we describe the Spanning Tree Bridge model implemented in OPNET, and present how we extend it to implement an OPNET model for a new bridge protocol, the STAR bridge protocol. Specifically, we use a variable-based implementation and do not make changes to the existing FSMs. We discuss the advantages and problems we found in using OPNET to perform simulation for the new protocol. We also present the simulation result. By using OPNET, we save a lot of time in implementing the STAR bridge protocol. We also realize that extending the standard protocol model to the

STAR bridge protocol is not complicated due to the backwardcompatibility feature of the STAR bridge protocol. In the STAR bridge protocol, the enhanced forwarding paths are provably shorter than their corresponding tree paths. Our simulation result confirms this desirable property of the protocol. Analytical study and evaluation of the protocol overhead of the STAR bridge protocol are beyond the scope of this paper. References
[1] MAC Bridges, ISO/IEC 10038, ANSI/IEEE Std 802.1D, 1993.

[2] King-Shan Lui, Whay Chiou Lee, Spanning Tree Alternate Routing Bridge Protocol, Technical Report UIUCDCS-R-2001-2211 UILU-ENG-2001-1716, Department of Computer Science, University of Illinois at Urbana-Champaign, April 2001. [3] R. Perlman, Interconnections Bridges and Routers, AddisonWesley, 1992. [4] F. Backes, Transparent bridges for interconnection of IEEE 802 LANs, IEEE Network Magazine, vol. 2, no. 1, January 1988.