LSC Redundancy Options

Some of the most appealing features of multiservice switches are all the carrier class RAS and redundancy features, such as controller card redundancy, switching fabric redundancy, hitless switchovers, line card y-redundancy, 1:N redundancy, and so on.

However, the LSC and its control interface present a single point of failure, as shown in Figure 5-7.

Figure 5-7. A Nonredundant ATM-MPLS Switch

If any one of the LSC components shown in Figure 5-7 failed, it could bring down the BPX-based LSR IP switching functionality.

To achieve full system redundancy, each individual component of the LSR should be redundant. Apart from redundant line cards, it is desirable to implement LSC redundancy.

The VSI protocol detailed in Chapter 2 includes some characteristics that make LSC redundancy possible:

• VSI allows multiple, independent control planes to control a switch.

• VSI ensures that the master control processes (MPLS, PNNI) can act independently of each other.

• A VSI slave process manages the switch's resources among the different control planes.

All these characteristics are also true when you use two different LSCs to control the ATM switch. Two different independent control planes can actually be two different LSC instances.

To make an LSC redundant, you perform these basic steps:

• Partition the slave ATM switch's resources.
  
  
• Assign one resource partition to one LSC and another resource partition on the same physical interface to the redundant LSC.
  
  
• Both LSCs independently control the controlled switch. They use a different VSI controller-id.
  
  
• The LSCs need to have different nonoverlapping VPI ranges assigned on the same physical interface.
  
  
• The XTagATM interfaces in different LSCs pointing to partitions of the same physical interface must have different control-vcs.
  
  

To achieve full redundancy, you use a parallel model, as shown in Figure 5-8.

Figure 5-8. LSC Redundancy Model

In Figure 5-8, ATM switch physical interfaces 1 to N are mapped to VSI slaves 1 to N from LSC-1. Similarly, the same physical interface is mapped to VSI slave N+1 to 2N from LSC-N-1. This mapping also results in independent masters and parallel network topology.

In this parallel redundant LSC model, each LC-ATM interface is extended to all its redundant LSCs. If two LSCs are present for redundancy, as shown in Figure 5-9, the four switch ATM physical interfaces are mapped as four XTagATM interfaces at LSC-1 and another four XTagATM interfaces at LSC-2. The mapping is independent and local to the LSC. One LSC mapping is not visible from the other LSC.

Figure 5-9. Redundant LSC Model for an ATM-LSR

Both LSCs could be active all the time. The same sets of VSI slave protocol instances should be running in the controlled switch. In each LSC, only one VSI master runs all the time.

In the case of LSC redundancy, there is a slight change in the configuration of edge LSRs. This is shown in Figure 5-10. Instead of two ATM MPLS subinterfaces, you have to create four ATM MPLS subinterfaces at the edge LSRs. Two of the four interfaces are connected to LSC-1, and the other two are connected to LSC-2, as shown in the figure. LSC redundancy eliminates the single points of failure.

Figure 5-10. Redundant LSC Model Attaching an ATM eLSR

From a logical standpoint, the LSC redundancy model creates a parallel route topology, as shown in Figure 5-11. This provides redundancy in the route tables at the eLSRs.

Figure 5-11. Virtual View When Using LSC Redundancy

Levels of LSC Redundancy

There are two levels of LSC redundancy:

• Hot redundancy Uses both redundant paths to route traffic. Both paths are set up to use the same routing cost so that traffic is load-balanced between the two paths. Hot redundancy uses twice the number of LVCs as warm redundancy but offers a higher level of resiliency. Either logical path is redundant to the other, and there's no traffic interruption in the event of failure.

• Warm redundancy Uses only one path (one LSC) at a time. The paths are set up so that one path has a higher cost than the other. Traffic uses only the lower-cost path. The other path is a backup path. In this case, the failover time equals the sum of the reroute time and the LDP mapping request time.

NOTE

Although it was just mentioned, the fact that hot LSC redundancy mode uses twice as many LCN resources as a non-LSC redundant MPLS network is important enough that it deserves its own note.

The logical and physical views of both redundancy levels are shown in Figure 5-12.

Figure 5-12. LSC Redundancy Levels

LSC redundancy not only enhances network reliability but also provides increased flexibility. For example, the following operational steps can be performed in one logical network without affecting the other:

• Changing the configuration in a live network

• Upgrading the software image without rebooting the entire system

• Upgrading LSC gracefully

• Running different or experimental configurations or software images

• Switching from warm to hot redundancy on-the-fly

Having several LSCs active on a single BPX switch turns the switch into several separate logical ATM-LSRs, as shown in Figure 5-13. Each logical ATM-LSR acts independently. The ATM-LSRs share the same trunks by way of VSI partitioning, creating separate logical networks.

Figure 5-13. Parallel Redundant LSCs Controlling an ATM Switch

Figure 5-14 shows the resulting logical network topology when two ATM switches are connected in serial.

Figure 5-14. LSC Redundancy in a Two-Switch Network

Figure 5-15 shows a more complex physical and logical MPLS redundant network.

Figure 5-15. LSC Redundancy in a Three-Switch Network

Link Bandwidth Considerations with LSC Redundancy

The LSC redundancy model requires that two LSCs manage resources in the control switch. Three different ways exist for multiple LSCs to control interface resources in the switch:

• Virtual trunks or VNNI This mode provides better separation of bandwidth resources between the LSCs. Its disadvantage is that bandwidth cannot be shared between different virtual trunks. This is because different virtual interfaces such as virtual trunks actually use different sets of queues and shaping devices on the line-card hardware. Therefore, bandwidth cannot be used upon LSC failure, and bandwidth assigned to the failed LSC is locked up. An example is LC-ATM 1.2.1 partition 1 for LSC1 and LC-ATM 1.2.2 partition 2 for LSC2. In this mode, no control-vc collision is possible because the control-vc's VPI must be within the resource partition.

• Physical interface with multiple partitions This mode can share bandwidth between partitions belonging to different LSCs. An example is LC-ATM 1.2 partition 1 for LSC1 and LC-ATM 1.2 partition 2 for LSC2. In this mode, control-vcs can collide and need to be manually configured, as they default to use VPI=0 in both LSCs.

• Different physical interfaces for different LSCs An example is LC-ATM 1.2 partition 1 for LSC1 and LC-ATM 1.3 partition 2 for LSC2. No control-vc collision is possible because the two LSCs control different physical interfaces, but resources can be underused.

Figure 5-16 shows the difference between using multiple VSI partitions and multiple virtual trunks in a physical interface for LSC redundancy.

Figure 5-16. Interface Bandwidth and LSC Redundancy

In Figure 5-16, you can see that a virtual interface (VI) is assigned to each interface in the controlled switch. This is done for physical interfaces as well as for virtual trunks and VNNI/VUNI interfaces. Each VI has in turn 16 class of service buffers (CoSBs) and a scheduler to serve bandwidth among them depending on the load and priority level of the CoSBs. There is a two-level bandwidth distribution in each CoSB based on guaranteed and excess bandwidth. A VI is defined as a group of CoSBs treated as a logical interface.

In a physical interface with multiple partitions, there is only one VI with 16 CoSBs, so different partitions can share the bandwidth in a CoSB for a given class. The formulas comparing the sum of the minimum bandwidth values and the largest maximum bandwidth values studied in the Chapter 2 section titled "Hard, Soft, and Dynamic Resource Partitioning" govern the bandwidth sharing. On the other hand, in a physical interface with virtual trunks or VNNI/VUNI interfaces, every virtual trunk has its own VI with 16 CoSBs each. Therefore, connections from different virtual trunks are serviced in different CoSBs, even for the same class of service.

Because of the bandwidth considerations just covered, it is recommended that you use multiple partitions whenever possible. You should use virtual trunks only when they are necessary for other reasons, such as connecting multiple RPM edge LSR devices in an MGX-8230 or MGX-8250 multiservice concentrator to an ATM MPLS LSR.