Designing MPLS Networks

Last Updated on Mon, 02 Jan 2023 | MPLS Networks

The goal of designing an MPLS network prior to installation is to produce a network which will operate correctly, and which will come at least reasonably close to meeting performance goals. Because of the inherently connectionless nature of IP traffic, customers will not be able to tell a carrier exactly what traffic they want to send where. Because of this, it is not possible to perfectly design a network ahead of time. The initial design steps result in a working network:

• Design Points of Presence

• Dimension backbone links in the network

• Design IP routing

• Dimension MPLS Label VC space

The final design step is an on-going process of optimizing the network design:

• Refine the design once the network is operational These steps are considered in the following subsections.

3.1 Points of Presence Structures

The design of Points of Presence (PoPs) for an ATM MPLS network is constrained by:

• The choice of access line types and equipment for a network, as discussed previously.

• Location of PoPs, which is largely determined by where the cities are.

• The population of user sites surrounding each location. Some typical PoP designs are shown in Figure 4.

Single ATM Edge LSR

Where a single Edge LSR device is sufficient for supporting the number and types of access lines in a Point of Presence (PoP) location, then the simple structure shown in Figure 4(a) is sufficient. Numerous access lines (typically tens or hundreds) are brought into a single Edge LSR, which is connected to the rest of the ATM MPLS network. Numbers and types of access lines supported by single Edge LSRs are described in Table 2.

Multiple Edge LSRs and an ATM-LSR

A PoP may require more than one edge LSR because of a large number of access lines to be supported at that location. Alternatively, different types of edge LSR might be required because of different types of access lines to be supported. Where there are several edge LSRs in a PoP, it makes sense to also include an ATM-LSR. This is shown in Figure 4(b). The ATM-LSR:

• Locally switches traffic going between different edge LSRs in the PoP

• Concentrates traffic going from the PoP onto a single set of ATM MPLS links. The alternative would be either separate sets of links to all edge LSRs, or using one edge LSR to carry traffic to the others.

• Improves scalability of routing. Only one set of IP routing protocol (e.g. OSPF) peerings are required from the ATM-LSR to other points in the MPLS network. Without the ATM LSR, separate peerings would be required from all edge LSRs.

Depending on reliability requirements, redundant pairs of links would be used between the edge LSRs and the ATM-LSR.

a. Single Edge LSR

ATM MPLS links to ATM-LSRs or other Edge LSRs

ATM links carrying IP edge traffic over PVCs b. Multiple Edge LSRs and an ATM-LSR

BPX 8650

ATM links carrying IP edge traffic over PVCs c. Edge LSR PoP with BPX 8650 and MGX 8220 access concentrators

: Route Processor Modules t Node Route Processors

Functional view d. 6400 or MGX 8850 Edge LSR

e. Stand-alone ATM-LSR

Figure 4 Point of Presence Structures for ATM MPLS networks

ATM or other

f. Stand-alone router-based LSR

e. Stand-alone ATM-LSR

f. Stand-alone router-based LSR

Figure 4 Point of Presence Structures for ATM MPLS networks

Edge LSR PoP With BPX 8650 and MGX 8220 Access Concentrators

An extension to the previous model is to use traditional access concentrators in addition to edge LSRs and an ATM LSRs. Circumstances where this is appropriate are discussed in "2.1 Structures for MPLS Networks" on page 9. One example of this type of PoP uses MGX 8220 access shelves, 7200 or 7500 edge LSRs, and BPX 8650. This is shown in Figure 4(c). IP traffic from access concentrators is carried in ATM PVCs to a edge LSRs. These may be carried through the same BPX 8650 that acts as an ATM-LSR, as this is an IP+ATM switch. Edge LSRs in such a PoP may have three different types of configuration:

• Typically, one or more edge LSRs will be dedicated to dealing with IP traffic on the edge PVCs. The router labelled 'x' in Figure 4(c) has this configuration. It must have at least two ATM interfaces: one for access PVCs (from the access concentrator) and one for ATM MPLS traffic.

• An edge LSR dealing with access PVCs may also have customer access lines directly terminating on it. Router 'z' in Figure 4(c) does this.

• There may also be edge LSRs in the PoP which don't deal with access PVCs at all, and have only directly-connected access lines. Router 'y' has this configuration.

Note that the Label Switch Controller (LSC) in the BPX 8650 can act as an Edge LSR simultaneously with performing its LSC function. However, use of an LSC as an Edge LSR is not recommended for providers who consider the separation of MPLS control functions from data forwarding functions to be important. As an edge LSR, an LSC can perform any of the three functions discussed above. The number of Edge LSRs required in the PoP depends on:

• The total number of access lines

• The total bandwidth of the access lines, calculated from the average utilization. For example, the sum of the access lines bandwidths might be (say) 1Gb/s, the utilization might not exceed 500Mb/s.

The capacity of a 7200 or 7500 router running MPLS edge function is roughly the same as its ordinary IP capacity using Cisco Enhanced Forwarding (CEF). For example, a 7200 router with an NPE 200 processor can support close to 200 Mb/s of MPLS edge traffic, at normal IP packet sizes6. It can support MPLS edge function for about 700 access lines. [These figures are preliminary and need confirmation.]

Cisco 6400 and MGX 8850 Edge LSRs

The MGX 8850 and Cisco 6400 integrate the functions described in the previous example into a single device, illustrated in Figure 4(d). It consists of:

• A multiservice access concentrator with various types of Frame Relay and ATM access lines, as well as Circuit Emulation lines. Voice access capability and other types of access lines will be added later.

• One or more edge LSRs. Each edge LSR is a Route Processor Module (RPM) card in the case of the MGX 8850, or a Node Route processor (NRP) card in the case of the 6400. The number of RPMs or NRPs required to act as Edge LSRs depends on:

- The total number of access lines

- The total bandwidth of the access lines, downrated according to the utilization. For example, the sum of the access lines bandwidths might be (say) 1Gb/s, the utilization might not exceed 500Mb/s.

An RPM with an NPE150 processor can support MPLS edge function for 700 access lines. It will support close to 150Mb/s of MPLS edge traffic, at normal IP packet sizes7. The NRP is similar. These limits will be raised in future due to software and hardware improvements.

6. If additional edge functions such as CAR and WRED are used, then performance may be affected. In these circumstances, the performance of the routers needs to be verified for the particular combination of features which will be used. Note also that voice-over-IP packets are very short, and will have significantly lower throughput than indicated here.

7. Again, the performance needs to be verified with the particular combination of edge functions to be used in addition to MPLS edge function.

• An ATM-LSR. In the MGX 8850, one of the RPM cards acts as a Label Switch Controller. It may perform both LSC function and edge LSR function simultaneously, if desired. Use of an RPM for simultaneous LSC and Edge LSR is not recommended for providers who consider the separation of MPLS control functions from data forwarding functions to be important. In the Cisco 6400, the main Node Switch Processor also acts an LSC. The 6400 and MGX 8850 also have IP+ATM capability. Note that these functions are being phased in over time. In particular, LSC function will not be available until later. This has implications to network design which are discussed in "4.5 Examples of Hybrid ATM Network Equipment" on page 52.

Stand-Alone ATM-LSR s

Some sites in a network may have purely a switching role. In an ATM MPLS network, these sites will consist of a single ATM-LSR, as shown in Figure 4(e), or possibly a redundant pair of ATM-LSRs. The ATM-LSR would typically be a BPX 8650, 8540 MSR, or later an MGX 8800 with PXM-45. In some networks, it may make sense to use a router-based LSR instead, as shown in Figure 4(f). A 7500 or 12000-series router may be suitable for this application. Core LSRs usually have Edge LSR capability as well. For example, the BPX 8650 has limited edge LSR capability as part of its Label Switch Controller.

3.2 Dimensioning an MPLS Network's Links

This section is intended to be a guideline to the steps of dimensioning the links in a small MPLS network, but it is not the only way of doing this. Different providers will have their own unique procedures for designing and running networks, but they all will be roughly similar to this. Recall that it is not the purpose of initial design to produce a perfect network. Several approximations are made in this process which lead to a network which works, but is not necessarily optimal. The last step in the design process is to optimize the network, and this is discussed in "3.5 On-going Network Design" on page 38.

1. Design edge points of presence and their layout.

The first step in MPLS network design will to be to choose the size, type, and layout of the Points of Presence according to the considerations described above. An example is shown in Figure 5. This example is based on a network in Australia. Australia was chosen for this example because it is small enough to make a suitable realistic example. The edge PoPs shown in Figure 5(a) are chosen based on the estimated customer link demand shown in Figure 5(b). BPX 8600-based edge LSR PoPs (which consist of several MGX 8800 shelves and a BPX 8650 for aggregation) are used in Sydney and Melbourne, which have the largest link bandwidths and number of links in this example. An MGX 8800 is used in Brisbane. Adelaide and Perth are smaller centres which can, in this example, be adequately served by router-based PoPs.

2. Estimate traffic from each point of presence

Based on the total access line bandwidths, an estimate on the total traffic sent from customers into each PoP can be made. A 'busy-period' estimate should be used, e.g. of the rate during the busiest minute of the day. This is to ensure adequate dimensioning. A conservative estimate would be the total of the access line bandwidths at the PoP, as in Figure 5(b). However it will often be reasonable to take a somewhat lower estimate, e.g. 50% of the total access bandwidth, as shown in Figure 5(c)

3. Estimate the traffic matrix

The exact process for this step will vary from network to network. In Australia, for example, the two main business centres are Sydney and Melbourne, with Sydney being slightly larger. In a large MPLS network for interstate business IP traffic, a reasonable first approximation may be that 50% of traffic will go to Sydney, 40%to Melbourne, 5% to Brisbane, and 2.5% to Adelaide and Perth respectively. An existing service provider would probably already have estimates for traffic patterns for their region. Based on the estimated traffic distribution percentages, and the total PoP traffic from Step 2, a traffic matrix can be estimated. The traffic matrix for this example is in Table 4. In a typical network, this matrix will be very roughly symmetrical. For example, in Table 4, the traffic from Sydney to Adelaide is 12.5Mb/s, but the traffic from Adelaide to Sydney is 25Mb/s. If the traffic were more asymmetrical than about 2:1 or 3:1, then there may be an error in traffic estimates or modelling.

4. In IP networks, traffic from x to y will often flows along the same path (but in the reverse direction) as traffic from y to x. Although this can be overridden by numerous routing protocol features, it maybe useful to assume that this will happen, particularly in small networks. Because of this, it may be easier to use bidirectional traffic flows rather than unidirectional flows

Traffic Destination	Distribution Percentage	Traffic Source
Traffic Destination	Distribution Percentage	Adelaide	Brisbane	Melbourne	Perth	Sydney
Adelaide	2.5%	1.25	2.5	10	1.25	12.5
Brisbane	5%	2.5	5	20	2.5	25
Melbourne	40%	20	40	160	20	200
Perth	2.5%	1.25	2.5	10	1.25	12.5
Sydney	50%	25	50	200	25	250
Total	100%	50Mb/s	100Mb/s	400Mb/s	50Mb/s	500Mb/s

in an initial network design. The estimated bidirectional flows for the example network are shown in Table 5. The bidirectional traffic bandwidth between Adelaide and Sydney, for example, is taken to be 25Mb/s, which is the maximum of the unidirectional bandwidth from Sydney to Adelaide (12.5Mb/s) and the bandwidth from Adelaide to Sydney (25Mb/s). Forming bidirectional flows in this way will tend to slightly overestimate the traffic in the network. This is useful as a conservative first approximation.

Table 5 Network example: approximate bidirectional traffic flows

	Adelaide	Brisbane	Melbourne	Perth	Sydney
Adelaide	1.25
Brisbane	2.5	5
Melbourne	20	40	160
Perth	1.25	2.5	20	1.25
Sydney	25	50	200	25	250

5. Design the layout of the backbone network

The layout of the backbone will involve consideration of

- Geographic layout, i.e. good locations for nodes

- Network-level redundancy, i.e. having multiple paths to each destination

- Redundancy of trunks

The network layout chosen in this example is shown in Figure 5(d). Many layouts are possible. The one chosen consists of a combination of a partial ring, linking adjacent nodes at the outside of the network, and a star, connecting nodes back to an extra ATM-LSR in the core of the network. This provides a good degree of network-level redundancy, with at least two paths between each pair of nodes. The extra ATM-LSR node is placed in Bourke, a town which is roughly equidistant from four of the five customer PoPs. With a good degree of network-level redundancy, it is not essential to have redundant trunks, because it is possible to re-route MPLS Label VCs8. In this example, most trunks are chosen to be non-redundant for economy. A redundant pair of trunks is used for the link which is expected to have the heaviest utilization, namely between Sydney and Melbourne.

8. In traditional connection-oriented networks, re-routing of virtual circuits is a last resort to be used only when all other redundancy mechanisms have failed. This is because it inevitably involves disruption of customer traffic for many seconds or minutes as all circuits are re-routed. In traditional IP networks, re-routing is a much less severe issue, as packet flows can be switched from one link to another almost instantaneously, once the IP routing protocol has converged. MPLS networks lie between theses two extremes. Re-routing in MPLS networks is particularly feasible if VC Merge is used, for two reasons: VC merge reduces the number of VCs which are used in the network, and it reduces the scope of changes required in connections when re-routing does occur.

100Mb/s

1 Sydney iJ

^ cii^

|-L - / ' |-L

Melbourne

a. Point-of-Presence layout a. Point-of-Presence layout

100Mb/s

1Gb/s

800Mb/s b. Total access line bandwidths

Figure 5 Network design example - geographic layout

50Mb/s

Cisco Aironet Access Point Block Diagram

500Mb/s

400Mb/s c. Peak traffic sent from each PoP

500Mb/s

Brisbane

; Sydney

Melbourne d. Network link design

Brisbane

; Sydney

Melbourne d. Network link design

Figure 5 Network design example - geographic layout (continued)

6. Estimate link flows based on the estimated traffic

This involves calculating the paths taken by traffic through the network backbone. With IP routing protocols such as OSPF, this is a straightforward procedure, as the IP traffic will follow the minimum-hop path unless administrative costs are used. Where there are two or more minimum-hop paths, the traffic will be approximately balanced across them. The process of calculation of link flows for the traffic in Table 5 is shown in Figure 6(a), and the totals in Figure 6(b)

7. Assign link capacities

Based on the estimated link flows, link capacities can be assigned to the links in the network. This would generally involve choosing the next standard link size (T3/E3, STM-1, etc.) larger than the link flows just calculated. This is illustrated in Figure 6(c).

8. Adjust for redundancy

Where redundant trunks are not used, and the network relies on re-routing for reliability, it may be necessary to adjust link bandwidths to ensure that there is sufficient capacity to deal with link failures. For example, if the link labelled 'r' in Figure 6(c) fails, then links 's' and 't' will need to carry some or all of its traffic. The load on these links would then exceed E3 rates, so an STM-1 link (or multiple E3 links) would be required for each of links 's' and 't'. Similarly, if link 'u' failed, then link 'v' would require more than E3 capacity. Also, if link 'y' failed then the offered load for 'w' would exceed E3. So, the final allocation of link bandwidths is as shown in Figure 6(d).

9. Check whether the selected equipment is adequate

This involves checking in Table 2 and Table 3 whether the selected PoP equipment can support the number and size of links chosen in the network design. The network in this case would pass this check But for example, assume the Melbourne PoP had used an MGX8850 instead of a BPX8680. This PoP needs two STM-4 links and two STM-1 links, which is not yet supported on an MGX 8850. So, in this hypothetical example, the PoP would need to be re-designed, e.g. by using a BPX 8680 instead of an MGX8850.

Note that any such re-designs, if required, are a relatively minor issue. Many different types of Cisco equipment can be used in ATM MPLS PoPs, and it will usually be found that a PoP can be built to meet the requirements of one location, simply by using combinations of equipment used at other locations. A BPX 8680, for example, combines several MGX 8850 shelves.

Note on Redundant Pairs of ATM Links

There are three main ways of achieving changeover for a redundant pair of ATM links:

• Data link-level changeover. This is the normal link redundancy mechanism in traditional ATM networks. Changeover occurs because of physical and data link-layer monitoring in the ATM switch or ATM-LSR hardware. The switch hardware also typically sets up a copy of all virtual circuit state on the backup link. In a switch with data link-level redundancy, any single link failure will typically result in close to zero data loss on any virtual circuits. In addition, the network layers and routing (IP or PNNI, etc.) will not be affected by the link failure, or even be aware that it has occurred. However with data link redundancy, the backup link is not available to carry data except in the case of failure of the main link. Depending on how it is implemented, SONET Automatic protection Switching (APS) may be a form of data link redundancy. On the MGX 8850 and BPX 8650, SONET APS changeovers result in no change to the interfaces as seen by connection routing, and no loss of connection state. This does not necessarily apply to APS on other Cisco equipment.

• Inverse multiplexing over ATM (IMA). IMA carries distributes data over a group of links by distributing cells across the links in round-robin fashion. It offers both data-link level load sharing across links, and redundancy. If one of the links in a group fails, cells are no longer sent on that one link, but the others are still used. IMA is available only for low-speed links—groups of T1 or E1 links.

• Parallel links with network-layer changeover. In this case, a redundant pair of trunks is used, but data-link layer protection is not used at all, and all connection changeover takes place at the network layer. IP or PNNI routing is aware of all link failures and reacts to them. This is not particularly good for connection-oriented traffic, but works well with IP routing and MPLS. With OSPF equal-cost-multipath or similar, OSPF will choose to balance traffic for every route across both links in a pair of links. This causes a pair of MPLS Label LVCs to be set up for each destination, one per link. If one of the links fails, IP routing will simply divert

a. Calculating traffic flows according to IP routing

25Mb/s

70Mb/s

25Mb/s

70Mb/s

37.5Mb/s

232.5Mb/s b. Total link bandwidths 30Mb/s

37.5Mb/s

232.5Mb/s b. Total link bandwidths 30Mb/s

STM-1 r

STM-1

STM-4

c. Link types - first pass

STM-1

d. Link types, allowing for network-level redundancy

Figure 6 Network design example - calculating link bandwidths

7200 LSC/Edge LSR

: a. Physical viewpoint

Figure 7 Viewpoints of an ATM MPLS network b. Functional viewpoint

Figure 7 Viewpoints of an ATM MPLS network traffic onto the other, already-established, LVCs. If VC merge is used, this will require no more MPLS signalling, and could be achieved in a second or so. The advantage of this method is that it allows the bandwidth in the 'backup' trunk to be used, allowing more best-effort traffic to be carried in the network. SONET APS changeovers, as implemented on the non-MSSBU Cisco equipment, are a form of parallel link redundancy, but without the capability of equal-cost multipath to set up back-up links.

Where a redundant link is required, recommendations for use of these modes are as follows:

• IP+ATM networks: these should use Inverse Multiplexing for redundancy for low-speed trunks, and otherwise use data link-layer redundancy. This avoids costly re-routes of the connection-oriented traffic.

• Pure ATM MPLS networks: again, these should use Inverse Multiplexing for redundancy for low-speed trunks. Otherwise, if the network uses VC merge, parallel links with network-layer changeover should be used, in order to make the full network capacity available for use. Finally, if VC merge is not available, data link-layer redundancy should be used.

: Layer 2 switches are invisible to IP routing

An LSC plus a switch is a single IP routing node c. Deriving the routing viewpoint

d. Routing viewpoint

Figure 7 Viewpoints of an ATM MPLS network (continued) 3.3 IP Routing in an MPLS Network

MPLS uses ordinary IP routing protocols—OSPF, IS-IS, etc.—to determine the routes for IP traffic and LVCs. Every LSR runs ordinary IP routing protocols in the same way that ordinary IP routers do. An important implication of this is that OSPF (or IS-IS, etc.) "sees" an MPLS network as being exactly like an ordinary router network. This is illustrated in Figure 7. It is possible to have various viewpoints of an ATM MPLS network:

• Physical viewpoint: This viewpoint represents the physical devices and links in a network. An example is shown in Figure 7(a).

• Functional viewpoint: Where a product has several functions, these can be shown separately. For example, the MGX 8850s in Figure 7 each include two separate Edge LSRs, which are shown separately. In addition, it is useful to think of the PVC switching function of an MGX 8850 to be separate from the MPLS switching function. It is sometimes useful to consider the Label Switch Controller (LSC) function in an ATM-LSR as being separate from the switching function. This is particularly true if the LSC is also acting as an Edge LSR.

• Routing viewpoint: This viewpoint shows the network as it is seen by an IP routing protocol. An example of deriving it is shown in Figure 7(c) and (d).

- Layer 2 PVC switches and PVC switching functions are invisible to IP routing. If a customer site is connected to a router by a PVC, then the PVC is a 1-hop direct connection from an IP routing perspective. See for example the sites labelled 'a' Figure 7(c), and assume that these are connected by PVCs to Edge LSR 'y'. Then, in the routing viewpoint, the sites are directly adjacent to router 'y'.

- A Label Switch Controller and a switch together form a single routing node.

Using these rules, the routing viewpoint of an MPLS network can be derived. This is shown in Figure 7(d).

Designing IP routing in an MPLS network is almost exactly the same process as designing IP routing for an ordinary IP network. By looking at the routing viewpoint, a network can be divided into Areas, route summarization can be designed, and so on. There are several design guides for IP routing on http://wwwin-cons.cisco.com/~dblack/design-guides/. Also, see the book "Internet Routing Architectures," mentioned in the Introduction. There are a small number of routing issues specific to MPLS networks, and these are considered next.

MPLS-Specific IP Routing Issues

• The interior routing protocol used in MPLS backbones should be either OSPF or IS-IS9. EIGRP can also be used, but it will not work with an advanced MPLS-based IP traffic engineering feature called Routing with Resource Reservations (RRR). RRR requires a link-state routing protocol, i.e. OSPF or IS-IS10. Since EIGRP is a distance-vector routing protocol, it will not work with RRR. IGRP or RIP also will work with MPLS but not RRR, and are not recommended. Note that RRR is sometimes referred to loosely as "MPLS Traffic Engineering," but is actually a specific type of MPLS traffic engineering.

• Use unnumbered IP links where possible. This reduces the number of IP destinations known to the routers, and hence reduces the number of LVCs used in the network. This is also discussed under "3.4 Dimensioning MPLS Label VC space" on page 30.

• Route summarization must not be done at an ATM-LSR. Multiple OSPF or IS-IS areas can be used in an ATM-MPLS network, as shown in Figure 8. An ATM-LSR may be used an OSPF or IS-IS Area Border Router (ABR), but only if no summarization is done at the Area Border routers. In Figure 8(c), this means that the address prefixes known in all the areas must be the same. An ABR in Figure 8(c) may not, for example, summarize reachability for 1.1.1.0/24, 1.1.2.0/24 and 1.1.3.0/24 with a single route for 1.1.0.0./16. If route summarization is required in an ATM MPLS network, it must be done at an ATM Edge LSR, as shown in Figure 8(b).

• The previous rule also applies to Autonomous Systems and BGP 4. An ATM-LSR may not be a BGP Autonomous System Boundary Router, but an ATM Edge LSR may be one.

• Routing with Resource Reservations (RRR) works best in backbones which contain a single OSPF or IS-IS Area. Currently, RRR may be not be used in multi-Area networks where the Area Border Routes are ATM-LSRs. This restriction will be eased in a later version of RRR.11

• Route summarization may not be done in the interior of an MPLS VPN network. MPLS VPN networks will be discussed in detail in a later version of this design guide. The interior of a MPLS network supporting VPNs may have multiple OSPF or IS-IS areas, but summarization should not be used.

9. IS-IS is currently supported on most Cisco MPLS equipment, but not on the LS1010 and 8540 MSR.

10. Both the OSPF and IS-IS Working Groups at the IETF are working on extensions to support IP Traffic Engineering, and these capabilities will be used by RRR.

11. One specific requirement is that a Traffic Engineering (TE) or RRR tunnel must start and end at a device which can "push" and "pop" labels on a packet's label stack. Currently this requires that the tunnels start and end at ATM edge LSRs or other packet-based LSRs. It is theoretically possible to let ATM-LSRs push and pop an extra label by carrying the additional label in a range of VPIs. However this has not yet been implemented. Another requirement is that TE/RRR tunnels may not pass through Area Border Routers; they must terminate and re-start. Together, these requirements currently mean that it is currently impossible to use RRR or TE in a network where the ABRs are ATM-LSRs. A future RRR release will allow TE/RRR tunnels to pass through Area Border Routers, and this will permit RRR to be used in networks where the ABRs are ATM-LSRs.

OSPF or IS-IS Area Border Routers (ABRs)

: a. Routing viewpoint

If routes are summarized at MPLS-capable ABRs, then they must be ATM Edge LSRs w w

If routes are summarized at MPLS-capable ABRs, then they must be ATM Edge LSRs

: b. Functional viewpoint, with route summarization

: Figure 8 Multiple routing areas and summarization in an ATM MPLS network

The restrictions on summarization exist because summarization stops some types of label-switched paths being set up end-to-end. For example, assume that an ABR summarizes reachability for 1.1.1.0/24, 1.1.2.0/24 and 1.1.3.0/24 with a single route for 1.1.0.0/16. Now assume that a packet with IP address 1.1.1.23 arrives with a label for 1.1.0.0/16. The ABR cannot label-switch the packet. It must look past the label and examine the IP address to find that the packet should go on to 1.1.1.0/24. Since ATM-LSRs

3.4 Dimensioning MPLS Label VC space

This design guide has shown how many of the issues of designing MPLS networks are similar to those of designing ordinary IP networks. One important exception to this is the dimensioning of MPLS LVC requirements on each link. This design problem is illustrated in Figure 9. In order to complete the design of an ATM MPLS network, a sufficient number of VCs must be reserved for use as LVCs on each link. This can be a problem, as any ATM switch will support only a certain number of active VCs. This is particularly important if there are multiple ATM services—MPLS, PNNI, etc.—sharing the resources of the links in an IP+ATM network. The design problem is to determine what number of LVCs is required.

Figure 9 Label VC Requirements

The required number of LVCs depends on:

• The number of IP destinations in the network

• The relationship between destinations and LVCs

• 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 known in that area. This follows the normal rules for an IP network:

• The loopback address of all LSRs and other routers in the area is a destination-prefix.

• The subnet address-prefix of any numbered point-to-point link, or any other subnet, is a destination-prefix. Because of this, it is best to use unnumbered links in MPLS networks.

• Any other address prefixes advertised into the area need to be counted as well13. If many addresses are summarized into a single address at the Area Border Router (or Autonomous System Border Router), then this counts as a single destination-prefix.

These rules are shown in Figure 10.

12. Some ATM-LSRs, e.g. the BPX 8650, have a limited ability to examine IP addresses by sending the packets to the Edge LSR function in their Label Switch Controller. However this may be done only for a small minority of the traffic flowing through the ATM-LSR

13. Note that in MPLS VPN networks, this does not apply to VPN customers' addresses. VPN customers' destination-prefixes are not advertised into the core of the network. This is one of the keys to scalability of MPLS VPNs.

cannot examine IP addresses, they may not do IP route summarization12.

need to allow on each link?

171.71

171.71.57.20/30

171.71.57.9

The loopback address of all / LSRs and other routers in the _ Area is a destination. ~ >

The subnet address-prefix of any numbered link or subnet is a destination.

171.71.57.20/30

171.71.57.9

171.71

The subnet address-prefix of any numbered link or subnet is a destination.

171.71.57.17

171.71.57.

171.71.57.17

171.71.57.

171.71.57.13

171.71.57.24/30

a. Destinations within an area

Any other address prefixes reachable from the Area count as destinations.

: 171.71.128.0/23

171.71.33.0/24

b. Destinations outside the area Figure 10 Destination-prefixes in an MPLS network (or any other IP network) LVC's Used Per Link & VC Merge

Each ATM Edge LSR and each Label Switch Controller will ask a neighbouring MPLS node for LVCs for the destination-prefixes it knows about. If MPLS Class of Service is used, it may ask for up to four LVCs for each destination-prefix. The requests for LVCs flow through the network according to the paths chosen by IP routing. With VC merge, the LVCs to each destination will be merged at each ATM-LSR. This means that on each link, there is at most one LVC per destination in the Area. This is shown in Figure 11(a). If MPLS Class-of-Service is used, then this is multiplied by the number of classes. If VC merge is not used, there may be many more LVCs: this is discussed later.

Design Calculations: Edge LSRs

For ATM Edge LSRs, the number of LVCs used per link depends on whether VC merge is being used in the network. Let d be the number of destination-prefixes known in an area, and c be the number of classes-of-service used in the network. If VC merge is used, then the number of LVCs used per link, l, satisfies l £ cd. (1)

If VC merge is not being used in the network, there is also a dependency on the number of LSCs and Edge LSRs in the area. There is also a dependency on how many destinations are directly reached through the edge LSR in question. If de is the number of destinations reachable through a particular ATM edge LSR (this will often equal 1, due to summarization) and the total number of ATM Edge LSRs and LSCs in the area is n , then the number of LVCs used per link satisfies l < c( d - dp ) + cn de.

With VC merge, there is at most one LVC per destination per link. (If MPLS Class-of-Service is used, this is multiplied by the number of classes.)

Some links will not carry LVCs for this' destination.

a. LVCs to a destination with VC merge

Without VC merge, there may be many LVCs for each destination on each link

b. LVCs to a destination without VC merge

Figure 11 LVCs to each destination

In the particular case where VC merge is not used, and there is one destination-prefix per edge LSR or LSC, and all links are unnumbered, and there are no address prefixes from outside the area, a simpler equation applies. These conditions will often apply in the core of MPLS networks supporting VPNs, but not using VC Merge. The number of LVCs used per link on the ATM Edge LSR in this case is given by:

One of these equations is then used to check whether a sufficient number of LVCs is available on the equipment, as shown in Table 6. Table 7 shows the LVC capacity of Cisco ATM Edge LSR interfaces.

Table 6 Checking the LVC limits of Edge LSR

Device	Situation	Key Parameter	Check Agains
Edge LSR	The network uses VC merge	Number of active VCs supported per ATM link.	Equation (1)
Edge LSR	The network does not use VC merge, there is one destination-prefix per LSR or edge LSR, all links are unnumbered, and there are no out-of-area routes.	Number of active VCs supported per ATM link.	Equation (3)
Edge LSR	The network does not use VC merge, all other situations.	Number of active VCs supported per ATM link.	Equation (2)

Table 7 Cisco ATM Edge LSRs and LVC capacity

Responses

POPPY
What does mpls stand for in networking?

12 days ago
- Reply

MPLS stands for Multi Protocol Label Switching.

Device	Interface hardware	Number of active LVCs supported	Notes
3600	NM-1A ATM Network Modules	1024
4700	NP-1A ATM Network Processor Module	1023
7200, 7500	PA-A1 or standard ATM port adaptor	2048
Catalyst 5500, 7200, 7500	PA-A3 ATM port adaptor.	4096
6400	Node Route Processor (NRP)	2048	Capacity is reduced by 1 LVC for each active PVC which terminates on the NRP
MGX 8850 IP+ATM switch	Route Processor Module (RPM)	4096	Capacity is reduced by 1 LVC for each active PVC which terminates on the RPM. In addition, the PXM is limited to 16k LVCs. This is unlikely to be a problem unless more than 3 RPMs are used in an MGX 8850 shelf.
12000 series routers	4xOC3 ATM Line Card	2047[Needs confirmation]	The 2047 active VCs are shared between all four ports. Network capacity is reduced by 1 destination-prefix for every second and subsequent route chosen for each destination according to equal-cost multipath routing, if the extra route(s) are on the same card.
12000 series routers	1xOC12 ATM line card	2047[Needs confirmation]

Edge LSRs: Worked Examples

Q. Consider a network where VC merge is being used and one class of service is being used. If the edge LSRs are all 7200-series routers with PA-A3 port adaptors, then how many IP destination prefixes can safely be supported in the area? A. VC merge is being used, so Table 6 indicates that Equation (1) should be used. One class of service is being used, so c = 1 . Table 7 states that the PA-A3 port adaptor supports 4096 LVCs, so l = 4096 . Substituting these into Equation (1) gives

Continue reading here: Dn 1 d n 1 8192

Was this article helpful?