Cisco Multiservice Switching Networks

One logical connection number (LCN) is used for each first-level label allocated in an LVC in the core network. A first-level label is assigned to each Forwarding Equivalence Class (FEC) in the MPLS network (that is, for each entry in the global routing table that has a specific class of service). The global routing table in the network normally consists of the loopback addresses of each participating MPLS router, both LSR and eLSR. Therefore, the number of LCNs needed is directly related to the number of addresses in the global routing table. For example, it would not be possible to introduce the full Internet table (currently over 110,000 routers) into the global routing table because there would not be enough logical channels. An MPLS network should be designed to be simple in the core, with the objective of allowing edge LSR reachability through shortcut LVCs.

NOTE

It is important to remember that the LCN assignment is arranged into different port groups in multiservice switching line cards (LCs). The arrangement is either Broadband Switch Module (BXM) line cards for BPX switches, Universal Switch Module (UXM) line cards for IGX switches, or ATM Switch Service Module (AXSM) line cards for MGX-8850 and MGX-8950 switches.

As a good general design practice, when you interconnect LC-ATM links in the same line card, the busier links should not be configured in the same port group. Not taking this into consideration increases the possibility of exhausting the LCN pool.

Multiservice switching software contains an algorithm for allocating LCNs to service groups (partitions) within the port group on the line cards according to their minimum and maximum requirements. A number of LCNs can be held in a common pool, depending on the ratio of the configured maximum to the sum of the minimum. The formula that governs the LCN allocation and VSI partitions and common pools is covered in Chapter 2, "SCI: Virtual Switch Interface." Refer to the section "Hard, Soft, and Dynamic Resource Partitioning" in that chapter for formulas and further details.

Dimensioning MPLS LVC Space

Many of the issues in designing MPLS networks are similar to those in designing ordinary IP networks. One important exception to this resemblance is the dimensioning of MPLS LVC requirements on each link. A sufficient number of virtual circuits (VCs) must be reserved for use as LVCs on each link, based on a worst-case scenario. VCs are precious resources that need to be controlled. This is particularly important if multiple controllers, such as MPLS, PNNI, and redundant MPLS LSCs, are sharing the links' VSI VC resources. The design dilemma is determining how many LVCs are required on a per-link basis and in a worst-case scenario.

The required number of LVCs depends on the following:

• The number of IP destinations in the network, not counting blocked destinations

• The number of classes of service in a multi-vc environment, in which multiple LVCs are requested per destination

• The number of nodes with eLSR functionality

• Whether VC-merge is used

• The paths chosen by IP routing

Destinations

The number of LVCs used in a particular area of a network depends on the number of IP destination prefixes advertised in that area. These prefixes include the following:

• Loopback address of all routers in the area.

• The subnet address-prefix of any numbered point-to-point link. Because of this, it is best to use unnumbered links in MPLS networks or to configure the router not to request LVCs for numbered link destinations.

• Any other address prefixes advertised into the area. If addresses are summarized into a single address prefix at the area border router (or autonomous system boundary router), this counts as a single destination prefix.

It is strongly recommended that you not share eLSR and LSC functionality in a single router. The LSC should be a dedicated router not terminating customer traffic. It is also recommended that you disable headend and tailend edge functionality in the LSC, as covered in the section "Running Out of LVCs" in Chapter 6, "MPLS Implementation and Configuration."

Calculating the Number of LVCs Required

To ensure proper functioning of the network, you need to allocate enough resources to support a worst-case scenario for the number of LVCs required. The problem we are trying to solve is shown in Figure 5-2.

It is important to emphasize one of the concepts mentioned at the beginning of the section "Label Virtual Circuit Resources" earlier in this chapter: The connections or channel resources in the controlled switches are called logical connection numbers (LCNs), and different LCs support different numbers of LCNs. One LCN is used for every first-level label allotted in the core network, for every forwarding equivalence class (FEC) defined by a global routing entry and class of service. The number of LCNs needed is directly related to the number of FECs in the MPLS network. VSI provides a clean separation between the control and forwarding planes. Remember that LVC is a controller concept, and an LCN is a switch entity.

To calculate the number of LCNs required, you must take into account the number of edge LSRs behaving as MPLS devices in the MPLS network.

Equation 5-1 shows the formula used to calculate the number of LCNs required in the core network in a worst-case scenario of link failures.

Equation 5-1 Worst-Case LVC Usage in an MPLS Link

The symbols used in Equation 5-1 are as follows:

• L = Number of active LVCs in an MPLS link.

• c = Number of classes of service.

• n = Number of eLSRs.

• d = Number of destinations. Destinations blocked for LVC requests are not counted.

During the calculation of Equation 5-1, the following simplifications take place and need to be true in order to use the formula:

• All eLSRs contribute with at least one destination.

• The number of eLSRs is greater than 2.

• The number of destinations is greater than 3.

If those conditions are not met, Equation 5-2 must be used.

Equation 5-2 LVC Usage in an LSR Link Without VC-Merge

In the most general case, you can calculate the LCN requirement in a specific link by counting the sources (routers) and destinations (IP prefixes) at both ends of a link and using Equation 5-3.

Equation 5-3 General-Case LVC Usage Calculation

In Equation 5-3, subindex 1 indicates one side of the link, and subindex 2 indicates the other side of the link. The calculation is based on the fact that each eLSR (n_i) from one side requests LVCs for all destinations (d_j) on the other side, and vice versa.

At the edge of the network, Equation 5-3 can be simplified by assuming that subindex 1 corresponds to the eLSR side, so the following are true:

• n₁ = 1 There is only one eLSR.

• d₁ = 1 The eLSR is advertising only one prefix by summarization.

Based on that, the formula shown in Equation 5-4 can be used for eLSRs.

Equation 5-4 LVC Usage Calculation in eLSR Links Without VC-Merge

It is critical to take into account that by default, LSRs and LSCs have edge functionality. By default, they have eLSR behavior in the sense that LSRs and LSCs request headend LVCs for the destinations they learn and respond to tailend LVC requests for their own destinations. This behavior can be modified, as described in Chapter 6 in the section "Running Out of LVCs."

LVC Usage Per Link and VC-Merge

Each MPLS device behaving as an ATM edge LSR requests LVCs for the destinations it learns through the IGP. If an MPLS multi-vc class of service is used, it may ask for up to four LVCs for each destination prefix.

The requests for label prefix mappings or bindings flow through the network according to the paths chosen by the IGP IP routing.

With VC-merge, the LVCs to each FEC are merged at each ATM LSR. This means that each link has at most one LVC per FEC, where each FEC defines a destination in the area and a class of service.

Figure 5-3 shows the effect of VC-merge in an MPLS network.

ATM Edge LSRs and VC-Merge

The existence of VC-merge can simplify some of the LVC calculations for links connecting an eLSR to an LSR. A VC-merge link has at most one LVC per FEC. Therefore, the LVC requirement can be calculated as shown in Equation 5-5.

Equation 5-5 LVC Requirement on VC-Merge eLSRs

ATM LSRs with VC-Merge

The formula shown in Equation 5-5 for merge LVCs also applies to ATM LSRs with VC-merge. However, another important issue with LSRs needs to be taken into account: the number of merging LVCs.

As discussed in Chapter 4, "Introduction to Multiprotocol Label Switching," multiservice switches implement VC-merge in the egress line card. On a multiservice switching ATM LSR, the number of LCNs for each FEC equals one LCN per incoming merging LVC plus one LCN for the merged root LVC. For example, if 15 LVCs merge into one LVC, the outgoing line card uses 16 LCNs.

The formula shown in Equation 5-6 also needs to be considered.

Equation 5-6 Number of LVCs to Be Merged in an LSR

Equation 5-6 uses the following definitions:

• M = Number of merging LVCs

• k = Number of links in the ATM LSR

VP-Tunnels and LVC Usage

Some changes apply when you calculate the number of LVCs on VP-Tunnel interfaces: When multiple VP-Tunnels exist on an interface, the LVCs on all VP-Tunnels must be taken into account.

Either equation applicable to eLSR links or LSR links needs to be multiplied by the number of VP-Tunnels in a physical interface.

To include the presence of VP-Tunnel interfaces in the formulas discussed, Equations 5-1 through 5-5 need to be multiplied for the number of tunnel interfaces in the MPLS LSR. On the other hand, in order to update Equation 5-6, we need to redefine the variable k to include not only physical interfaces but also VP-Tunnel interfaces.

Figure 5-4 gives a summary view of LVCs with VC-merge and VP-Tunnels. VC-merge benefits normally increase when you avoid VP-Tunnels and ATM LSRs are used.

Tips on Saving LCN Resources When Designing ATM-MPLS Networks

Three design tips reduce the number of required LVCs in an MPLS network:

• Disable eLSR functionality in the LSCs. This includes disabling headend LVCs and tailend LVCs.

• Use unnumbered links whenever possible, or configure all eLSRs and LSRs to not request LVCs for the numbered links.

• Monitor the IGP, ensuring that unneeded prefixes are not injected into the global routing table.

These steps are covered in detail with configuration examples in Chapter 6 in the section "Reducing the Number of LVCs."

Summary of LVC Dimensioning

Table 5-1 summarizes the LVC calculations based on the equations presented in this chapter.

Two independent scenarios multiply the number of LVCs used in an MPLS network: LSC hot redundancy and multi-vc class of service.