Redundancy and Loops
Redundant links are an important part of highly available networks, serving as backups in case of failure in a network. For bridged (or switched) networks, it is common to add a second bridge between two segments as a backup in case the primary bridge fails. Redundancy eliminates a single point of hardware failure in a network, but it is not without its problems. For a network to function properly, only one active path can exist between two stations. The redundant bridge in the network causes multiple active paths between stations which can cause loops in the network topology, and the potential exists for duplication of messages. When loops occur, some bridged stations appear on both sides of the bridge. This condition confuses the basic forwarding algorithm and allows duplicate frames to be forwarded, which can lead to an explosion in traffic and can adversely impact the performance of the network.

Spanning Tree Protocol
Spantasmic’s Spanning Tree Protocol implementation is used to selectively block bridge ports in a bridge loop situation to keep exactly one active path open, thus allowing for redundant bridges to be used without loops. STP specifies an algorithm that bridges can use to create a loop-free logical topology and creates a tree structure of loop-free leaves and branches that spans the entire Layer 2 network. Whenever a loop is created, the root bridge will reconfigure the network and take the redundant bridged path creating the loop out of service. By disabling these inter-bridge links, STP ensures that no L2 frames are forwarded in such a way as to "loop" the frames back to the original LAN that originated them. Further, the single path left active is the one determined to be the most efficient one. The redundancy feature is not lost - if a link in forwarding state becomes unavailable, STP reconfigures the network and reroutes data paths by activating the appropriate standby path.

Spanning Tree Protocol is defined in the IEEE 802.1D standard as an essential element of enterprise and carrier infrastructure. Spantasmic includes support for this specification and is interoperable with other 802.1D compliant bridges and switches. Further, Spantasmic operation is transparent to end-stations, which are unaware of whether they are connected to a single LAN segment or a bridged/switched LAN of multiple segments.

RSTP
Although the basic STP avoids data loops in a bridged network, it takes 30 to 60 seconds to converge, depending upon the complexity of the bridged network topology. Moreover, reconfiguration in the event of bridge failure or link failure is also slow when compared to other Layer 3 protocols that support path reconfiguration. This can be critical in networks carrying delay-sensitive traffic such as voice and video. To avoid this limitation, Spantasmic also implements Rapid STP (RSTP), based on the IEEE 802.1W specification, an enhancement to the original IEEE 802.1D specification. RSTP has a much faster convergence and reconfiguration time in the event of a change in network topology, which is usually less than a second, while retaining compatibility with equipment based on STP on a per-port basis. These improvements are due to the ability of the protocol to distinguish point-to-point vs. shared links.

Spantasmic’s RSTP implementation is a distributed algorithm that selects a single bridge to act as the spanning tree's root. The algorithm assigns port roles to individual ports on each bridge. Port roles determine whether the port is to be part of the active topology connecting the bridge or switch to the root bridge (a root port), or connecting a LAN through the bridge to the root bridge (a designated port). Regardless of their roles, ports can serve as alternate or back-up ports that provide connectivity in the case of failure. State machines associated with port roles maintain and change the port states that control the processing and forwarding of frames. A new root port can rapidly transition to the forwarding port state. Explicit acknowledgements between bridges and switches in the LAN allow designated ports to rapidly transition to the forwarding port state. Thus, Spantasmic ensures rapid recovery of connectivity following the failure of a bridge, bridge port, or LAN.

MSTP
Another limitation of the basic STP is visible when 802.1Q-capable bridges are involved (and most bridges/switches today are 802.1Q-capable) in scenarios where asymmetrical connectivity between VLANs exists. With the advent of Metro Ethernet networks, different VLANs commonly have different connectivity and redundancy requirements, and can have different underlying physical links. This asymmetrical connectivity creates a requirement for the infrastructure to be able to execute separate STP instances for different VLANs, which result in the ability to have a given physical port perform forwarding for one VLAN while doing blocking for another. To address this, Spantasmic adds the facility for VLAN bridges to use multiple spanning trees (MST), providing for traffic belonging to different VLANs to flow over potentially different paths within the virtual bridged LAN.

Spantasmic includes an implementation of the IEEE 802.1S multiple spanning trees specification which enables VLANs to be grouped into a spanning-tree instance, provides for multiple forwarding paths for data traffic, and also enables load balancing.

Each spanning tree instance is independent of other instances, thereby increasing the fault tolerance of the network since failure in one instance does not affect other instances. MSTP is interoperable with STP and RSTP bridges in the same bridged LAN, ensuring cross-protocol compatibility.

Built-in Bridge Framework
For implementations that do not include a switch fabric or external bridge implementation, Spantasmic also includes a bridging component to forward unicast and broadcast frames received on a given port to the appropriate port(s), which reduces the overall traffic in a bridged LAN and provides greater effective bandwidth with its filtering abilities. The filtering engine drops frames that arrive on a port and are destined to hosts in the same LAN, thus reducing the overhead of forwarding. The port that a frame is forwarded to is decided based on an internal address resolution logic (ARL) table that maps MAC addresses to individual LANs connected to the bridge. Entries in the ARL table are filled automatically by the bridge through its learning capability or may be added statically. Spantasmic’s ARL table also provides the unique capability to age entries, wherein entries that exceed a customizable maximum age get deleted from the table automatically. Other features of the bridge include maintaining the port state of individual ports, and bridge management to control and monitor the parameters associated with the bridge. Spantasmic also provides customized APIs to attach and configure any spanning tree protocol to on a bridge port. The bridging component may be used in its software-only form, or may be interfaced to switch fabric hardware to enable fast data-paths, while the control logic resides in software.

Customization Flexibility

• Configurable relative priority of each bridge and each port.
• Configurable path cost associated with each port.
• Management APIs are provided to control and monitor spanning tree parameters.
• Available in full-source format
• Customization hooks and callouts.
• Unwanted components can be scaled out.
• Designed to support hardware switch implementations