LightningEdge Enhancements

World Wide Packets LightningEdge solution supports the delivery of time critical services such as voice and video. In order to maintain acceptable service levels during topology changes, reconvergence must occur within 200 milliseconds or less, much more rapidly than what RSTP alone was designed to support.

The LightningEdge solution has been optimized to enable RSTP reconvergence well below 200 milliseconds often below 50 milliseconds. These enhancements allow Ethernet service delivery networks based on LightningEdge products to support critical, time-sensitive applications with the same service level agreements and guarantees of SONET/SDH optical rings.

These enhancements can be categorized using the same classification as the RSTP enhancements defined in the IEEE 802.1w (now part of 802.1D-2004) standard. They include:

• More efficient state machines
• More efficient negotiation process

The LightningEdge enhancements are fully compatible and interoperable with IEEE STP and RSTP, and will operate seamlessly in a mixed vendor network deployment without any modification to the BPDUs. However, the overall reconvergence performance of the network will be significantly enhanced with more LightningEdge devices. This is due, in part, to our hardware and software-based optimizations for detecting link failure conditions, as well as optimizations of the protocol itself. World Wide Packets will continue to enhance our RSTP performance to achieve even faster reconvergence times.

LightningEdge RSTP Performance

World Wide Packets measures the LightningEdge RSTP performance using a ring topology. Several parameters are changed between tests to maximize the test coverage. Those parameters include:

• Ring diameter: number of devices present in the ring.
• MAC table size: number of MAC addresses present in the forwarding tables during the tests.
• Cause of the topology change: link failure, bridge failure, and new root bridge.

Figure 7. Performance Test Configuration

In the test configuration, bridge 1 is the root bridge. Traffic is sent from bridge 7 to bridge 2. Traffic will flow from bridge 7 to bridge 2 via bridge 1. To test reconvergence times, the link between bridge 1 and bridge 7 is disabled. After the topology change the traffic will flow via bridge 6, 5, 4 and 3. The number of frames dropped during the failure event is used to determine the total time required for the traffic to reroute. World Wide Packets defines this as the failover time.

Once failover is accomplished, the cause of the topology change is removed, and traffic is restored over the original path. World Wide Packets defines the time required to reroute the traffic as the restore time.

Figure 8.

The number of MAC addresses present in the forwarding table is a factor in the RSTP performance. As the topology change occurs, the forwarding tables need to be updated in order to forward the traffic onto the failover path. The more MAC addresses that need to be updated, the longer the reconvergence will take.

Figure 9.

The ring diameter is another factor in the RSTP performance. The more devices that are present in the network, the more BPDUs have to be exchanged, and the longer the negotiation process will take. The important point here is that the failover time increases in a linear and predictable fashion as the ring diameter increases.

Figure 10.

The cause of the topology change is also a factor of RSTP performance. A new root bridge will result in the least negotiation, while a root bridge failure will result in the most negotiation.

Spanning Tree Domains

RSTP is a global protocol. It runs across a bridged Ethernet network. As the access network grows, it may be desirable to partition the reach of RSTP to certain areas of the network.

One example of this is illustrated by the figure below, where the provider network is carried on a main ring to provide services to edge rings that are connected to the core provider ring. If a topology change occurs on an edge ring, the reconvergence event could impact the main provider ring, and cause traffic problems across the entire network.

Figure 11. Spanning Tree Domains

The LightningEdge solution enables a network operator to define areas of the networks as Spanning Tree Domains. Traffic within and between those domains flows without any restriction. However, RSTP BPDUs are only forwarded between bridges of the same Spanning Tree Domain. This prevents a link failure on one ring from causing traffic problems on other rings.

The LightningEdge solution also offers Multi-Device Spanning Tree Domains, a mechanism that enables an edge ring to be connected to two bridges of the main ring for increased reliability and redundancy.

Figure 12. Multi-Device Spanning Tree Domain

As with all LightningEdge RSTP features, including Spanning Tree Domains, are fully compliant with the IEEE 802.1D and 802.1w standards. The format of the BPDUs exchanged between bridges is not modified.

Dynamic RSTP Path Cost

The RSTP negotiation process relies on path cost to define designated bridges and designated ports. The network operator defines the path cost for each physical port.

Figure 13. RSTP on Link Aggregation Groups

If link aggregation groups are present in the network (logical link between two devices created by bundling several physical links together in order to offer link redundancy or increase link bandwidth), the cost of a link can vary. If a physical link part of a link aggregation group fails, the amount of traffic that that logical link can carry decreases.

In the previous figure, two link aggregation groups are present on a network device. Link aggregation group A is forwarding, while link aggregation group B is blocked by RSTP. If a failure occurs on A, the cost of link A can become higher than the cost of link B.

The LightningEdge solution offers a unique mechanism to either statically configure the cost of a link aggregation group, or dynamically relate the link aggregation cost to its dynamic aggregation level, i.e. the number of physical links aggregated.

RSTP Loopback Port Disable

The LightningEdge solution also offers a mechanism to prevent loops caused by non-bridge network devices connected to a Lightning Edge device.

Figure 14. RSTP Loopback Port Disable

After sending a BPDU, if a LightningEdge device detects its own BPDU coming back, it means that a physical loop exists on that part of the network. The LightningEdge device will automatically disable RSTP on that port and send a SNMP trap to alert the operator of the loop condition.

RSTP will periodically try to re-enable the port in order to detect an eventual suppression of that loopback.

RSTP Management

All LightningEdge features, including RSTP, can be configured via the Command Line Interface (CLI), Simple Network Management Protocol (SNMP), or from the LightningEdge Network Supervisor (LE-NS). Additionally, all LightningEdge RSTP features can be enabled or disabled independently.

The LightningEdge solution also provides several SNMP traps that facilitate troubleshooting of the network. These traps are generated on events such as the detection of incoming Per-VLAN Spanning Tree (PVST) BPDUs, new root bridge, RSTP port state changes, and RSTP loopback port disable.

Continue

• Part 1:
  Introduction/Broadcast Storms
• Part 2:
  Spanning Tree Protocol
• Part 3:
  LightningEdge Enhancements
• Part 4:
  Conclusion