Service Provider MPLS Network Design Study

7/28/2019 Service Provider MPLS Network Design Study

1/14

Subject: An MPLS Network Design Case Study Date: 2013-4-10

From: Ahmet Akyamac

Benjamin Tang

Ramesh Nagarajan

Advanced Technologies

Bell Laboratories

Holmdel, NJ07744

(732) 949-5413

(732) 949-6477

(732) 949-2761

[email protected]

[email protected]

[email protected]

1 IntroductionMPLS (Multi-Protocol Label Switching) has become the choice of packet transport technology to meet multiple service

requirements in the next generation network (NGN). More and more service providers, both wireline and wireless, are

starting to deploy MPLS as the common packet backbone to achieve convergence of existing heterogeneous TDM and

packet (X.25, ATM/FR, best-effort IP) networks and services, and offer new MPLS-enabled services such as IP VPN

and VPLS to increase revenue generation. For those service providers the MPLS network must be designed to be

scalable, highly available and capable of supporting various quality of service (QoS) requirements, and be operated in an

efficient and cost-effective manner.

Lucent Worldwide Services (LWS) is offering a complete suite of MPLS network design and optimization services to

help service providers resolve key issues encountered in the rollout and operation of MPLS networks. The LWS MPLSservices, powered by rigorous methods and procedures (M&P), intelligent algorithms and tools developed by Bell Labs,

are geared to address such key issues as service characterization and traffic modeling, Greenfield IP/MPLS network

design, multi-class traffic engineering, design and optimization, and protection design based on mixed protection policies

for various types of traffic.

This paper presents a case study of MPLS network design that was performed for a service provider using the service

capabilities available from LWS MPLS network design and optimization services. In the remainder of this study, this

service provider will be referred to as Service Provider A, orSPA. Furthermore, due to the sensitive nature of theinformation, the geographical and traffic information have been modified from the original study. The case study

addresses a specific traffic engineering (TE) challenge facing service providers in the operation and growth of an MPLS

network. Based on the service providers existing MPLS network and a set of services selected, we performed a DiffServ

based traffic engineering (DS-TE) design to find the routing of both primary and backup LSPs carrying that multi-

service traffic. The LSP routing is driven by minimizing a particular cost measurement of the MPLS network chosen forthis study that is, the total link bandwidth consumedby the routing of LSPs. The details of the case study are presented

in the remainder of this paper as follows:

Section 2 A brief summary of SPAs current ATM and MPLS networks and how they are used in the case

study is given.

Section 3 We describe our design methodology.

Lucent Technologies Inc. - ProprietaryUse pursuant to Company instructions.

1
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/14

Section 4 We describe how traffic modeling for the two selected services, SPAs existing Internet access and

new IP VPN service, is conducted in the study. By using historical SPA network data and reported growth rates,and leveraging Bell Labs developed traffic modeling tools, we were able to derive a reasonable estimate of the

Internet access and IP VPN traffic that were used as input to the MPLS TE design.

Section 5 The alternative design scenarios addressed and M&P and design tool used in the study are

described, followed by a comparison and analysis of the results. Depending on the TE design philosophies used whether link bandwidth is pre-partitioned for various class types (CTs), whether single or multi-class LSPs

are used three different design scenarios are defined and addressed in the study. For each of the designscenarios a DS-based TE design was conducted to find the routing of primary and backup LSPs. The results of

TE design for these scenarios are then compared and analyzed, with a look into how these TE designs can help

service providers meet their MPLS requirement for efficient utilization, low cost, and assured QoS support and

high availability for multi-class traffic.

Section 6 Conclusion and possible additional studies in the future.

2 SPA MPLS NetworkSPA currently operates a large ATM backbone network based on Lucent equipment and an overlay MPLS backbone

based on Juniper routers. The ATM backbone consists of two tiers: one national backbone including seven core nodes

fully mesh connected via OC12 (in this document, we will refer to these nodes as Gate1, Gate2, Gate3, Core1, Core2,

Core3, Core4), and thirty tier-2 provincial backbone networks homed to the core nodes. The ATM backbone supportsmultiple services including ATM, FR, Internet access and VoIP. In 2004 SPA started to deploy an overlay MPLS

backbone initially consisting of seven core nodes collocated with the ATM core nodes, each containing one Juniper

T640 and interconnected via OC48. Over time SPA plans to migrate traffic from ATM to the MPLS backbone. At

present Internet access traffic previously carried over the ATM national backbone has been diverted to the MPLS

backbone at the core node locations (Figure 1). Additional existing traffic in the ATM backbone (such as VoIP) and new

IP-based services such as IP VPN and VPLS will be carried over MPLS in the future.

T640

GX 550

Core node

locationMPLS BB

IP VPN

Internet

accessATM Natl BB

ATM Prov. BB

Figure 1: SPA ATM and MPLS Backbone Networks

This MPLS network design study is based on SPAs current MPLS backbone network and traffic demands that include

existing Internet access and new IP VPN traffic assumed to be carried over the MPLS backbone. The IP VPN traffic may

be terminated directly on T640 (as shown in Figure 1) or coming from some PE routers connected to T640s via logical

links provisioned through the provincial ATM backbones. In either case, we are only concerned about the total IP VPN


2


3/14

traffic aggregated at T640s and use it as input to the MPLS network design. Section 4 describes how Internet access and

IP VPN traffic is modeled in this study.

3 Network Design MethodologyThe following figure shows a flow diagram of the general MPLS network design methodology used in this study.

Figure 2: General MPLS Network Design Methodology

Typical inputs to the MPLS network design procedure include topology information (such as node locations,

capacity/configurations; link types, connections, class type partitioning and subscription constraints) and traffic

information (multi-class traffic and/or LSP information, protection - path based, FRR etc.). The gathering of this type of

information for this study is further discussed in Sections 4 and 5. The traffic engineering constraints (hop, delay etc.),and design objectives (such as minimizing bandwidth, minimizing maximum subscription, etc.) are further inputs to the

design process. Subsequent to network design, routing and performance analysis can be performed to estimate network

performance in terms of capacity utilization, traffic quality of service measures such as delay, loss, etc. The studypresented in this document focused on capacity utilization as the main performance measure. As a final step, the design

output information is collected through a series of reports, which can be analyzed to compare design results to design

objectives and specifications. This could result in recommended changes to the network, which would then be used to

perform further network studies as part of a closed loop process (shown by the dashed lines in Figure 2).

4 Traffic ModelingFor this study we assumed two types of traffic: Internet access (IA) and IP Virtual Private Network (VPN).

4.1 Internet AccessAs discussed earlier, the SPA MPLS backbone consists of seven nodes. Of these, Gate1, Gate2 and Gate3 are considered

to be the gateway nodes for IA traffic. IA traffic aggregated at the gateway nodes does not traverse the MPLS core

network but goes directly to the Internet off those gateway nodes. On the other hand, IA traffic aggregated at any of the

four non-gateway core nodes (Core1 through Core4) must traverse the core network to reach one of the gateway nodes.

We assumed that each non-gateway node sends IA traffic to the two geographically closest gateway nodes, split equally

to each of the two gateways.


3

Input Network

topology and link

class partitioning info

Input Multi-Class traffic

and/or LSP information,

(VoIP, VPN, 3G, IA, etc.),

protection options (Path,

FRR, etc.)

MPLS Multi-Class

Network DesignTE constraints

(subscription, hops,

delay, etc.)

Routing and

Performance Analysis

Reports

Reports

Input Network

topology and link


Input Network

topology and link






FRR, etc.)





FRR, etc.)

MPLS Multi-Class

Network Design

MPLS Multi-Class

Network DesignTE constraints


delay, etc.)

TE constraints


delay, etc.)

Routing and


Routing and


ReportsReports

ReportsReports


4/14

The IA traffic demand observed in this study is based on our estimate of the current IA traffic in SPAs network. Since

we did not have the current traffic information available from SPA, our estimate is based on the IA traffic levels in

August 2003 available from earlier SPA studies, which are then augmented to account for IA traffic growth since August

2003. We used the Internet subscriber growth data available for SPAs geographical region of operation and extrapolated

to August 2005, as seen in Table 1. Based on our extrapolation, the IA traffic levels in August 2003 were multiplied by afactor of 1.627 and the current IA traffic is estimated to be 5508 Mbps in total.

Internet access subscribers (millions) Extrapolated

Jan-02 Aug-02 Jan-03 Aug-03 Jan-04 Aug-04 Jan-05 Aug-05

33.7 45.8 59.1 68 79.5 87 98.4 110.6

Table 1: IA subscribers in SPAs geographical region

The total IA traffic estimated was proportionally distributed among the seven nodes based on their weights (i.e., thetotal amount of traffic aggregated at each node based on the August 2003 traffic data). As mentioned before, IA traffic

aggregated at gateway nodes does not traverse the MPLS core and thus does not produce input traffic to the MPLSnetwork design. For the non-gateway nodes IA traffic is split between the two geographically closest gateways, resulting

in 16 uni-directional IA traffic demands in the traffic matrix shown in Table 2. IA traffic is assumed to be of class type

CT0.

Table 2: IA Traffic Demand Matrix (Mbps)

4.2 IP VPNSPA currently does not offer IP VPN service. For the purpose of the study we assumed VPN traffic demands exist

between each pair of core nodes. IP VPN traffic demands were generated by first calculating the total IP VPN traffic in

the network based on the IP VPN service demand model illustrated in Table 4. The IP VPN service demand model takes

various input parameters as specified in the table and calculates the consequent total IP VPN traffic. This study uses the

figures shown in the table and as a result the total IP VPN traffic is estimated to be 15,655 Mbps.


4

433433Core4

460460Core3

188188Core2

296296Core1

460188Gate3

433296Gate2

433460188296Gate1

Core4Core3Core2Core1Gate3Gate2Gate1IA Traffic

433433Core4

460460Core3

188188Core2

296296Core1

460188Gate3

433296Gate2

433460188296Gate1

Core4Core3Core2Core1Gate3Gate2Gate1IA Traffic


5/14

Number of IP-VPN Customers 100

IP VPN Customers Yearly Growth Rate 5%

Large Medium Small

IP-VPN Customer Distribution 10% 30% 60%Avg. Number of Nodes per IP VPN Customer 50 30 10

Access Speed Distribution

NxDS0 50% 65% 80%

T1 30% 25% 20%

T3 20% 10% 0%

OC3

Avg. IP-VPN Traffic (as % of access speed)

NxDS0 50%

T1 30%

T3 30%

OC3

Table 3: IP VPN Service Demand Model All Class Types

Next the total IP VPN traffic is converted to a traffic demand matrix (42 source-destination pairs) shown in Table 4

based on a weighted distribution traffic model (again the weight being the total amount of aggregated traffic at the seven

nodes based on August 2003 traffic data). The total VPN traffic between each pair of nodes was split into the four VPNclasses for a total of 168 VPN demands, using the following percentages: 50% for VPN0, 25% for VPN1, 20% for VPN2

and 5% for VPN3. The VPN traffic was assumed to be of class types CT3 (for VPN0) to CT6 (for VPN3).

Table 4: Total VPN Traffic Demand Matrix (Mbps)

5 Detailed MPLS Network TE DesignIn this section, we discuss the different aspects of the SPA multi-class MPLS network TE design. The MPLS network

TE design is based on SPAs current MPLS backbone and existing Internet Access and new IP VPN traffic as modeled

in the previous section. The goal of the TE design is to find routing of LSPs carrying multi-class IA and IP VPN trafficsuch that the network cost, defined by total consumed link bandwidth, is minimized. In the subsequent descriptions we

first define the three design scenarios addressed, followed by the procedure and design tool used in the MPLS network

TE design. Lastly we present the TE design results with a comparison and further analysis.


5

8534.554.5221160.5690Core4

8536.558234.5170.5736Core3

34.536.523.59468.5283Core2

54.55823.5149108.5456.5Core1

221234.594149451.52209.5Gate3

160.5170.568.5108.5451.51502.5Gate2

690736283456.52209.51502.5Gate1

Core4Core3Core2Core1Gate3Gate2Gate1Total VPN Traffic

8534.554.5221160.5690Core4

8536.558234.5170.5736Core3

34.536.523.59468.5283Core2

54.55823.5149108.5456.5Core1

221234.594149451.52209.5Gate3

160.5170.568.5108.5451.51502.5Gate2

690736283456.52209.51502.5Gate1

Core4Core3Core2Core1Gate3Gate2Gate1Total VPN Traffic


6/14

5.1 Design ScenariosFor the SPA MPLS network, all traffic demands are carried on LSPs. IA demands are carried on LSPs with zero TE

bandwidth and as a result routed over shortest paths. IP VPN demands are carried on LSPs with non-zero TE bandwidth

where the LSPs can besingle ormulti-class depending on the design philosophy. In the case of single-class LSP, theLSP carries traffic from a single grade of IP VPN service and contains bandwidth request (with MPLS framing overhead

included) for that grade of service, while in the case of multi-class LSP, the LSP carries traffic from multiple grades of

IP VPN service and contains multiple bandwidth requests, one for each grade of service. In either case, each LSP is

assigned asetup and holdingpriority that, combined with class type(s) associated with the LSP, will be used to decide

the routing priority of the LSP in the TE design. All LSPs are protected against single link failure by end-to-end pathprotection backup paths. The backup paths share capacity as long as the corresponding primary paths are link disjoint.1

Both primary and backup LSPs are routed over the given SPA MPLS network. On all network links, 100% of the

available bandwidth (after deducting SONET framing overhead) is available to the routing of LSPs. In addition, the

available bandwidth on a network link may be pre-partitioned to various class types (again depending on the design

philosophy) and the routing of LSPs must be subject to this constraint. When class based partitioning of link bandwidth

is applied, Maximal Allocation Model (MAM) is used as the bandwidth constraint model on all network links. The

routing of primary and backup LSPs is decided through traffic engineering with an objective of minimizing the total linkbandwidth consumed (or subscribed) by the routing of LSPs.

Based on different design philosophies, three different design scenarios were considered in the MPLS TE design. These

are summarized in Table 5 and Table 6, and discussed below.

LSP Type Class Based Link

Bandwidth Partitioning

No Yes

Single Class Scenario 1 Scenario 2

Multi Class Scenario 3

Table 5: Summary of Design Scenarios

Setup Priorities Scenario 1 Scenario 2 Scenario 3VPN3 1 1

1

50% BW

VPN2 2 2 25% BW

VPN1 3 3 20% BW

VPN0 4 4 5% BW

IA 7 7 7

Table 6: LSP Class Setup Priorities

Single class LSPs allow for more granular bandwidth control, whereas multi class LSPs present operational advantages.

Design Scenario 1

This design scenario corresponds to a traffic-engineered network with single-class LSPs and no class based partitioningof link bandwidth. Each LSP carries one traffic class, thus there are 5 types of LSPs: IA, VPN0 through VPN3. Each

traffic type is bound to its corresponding LSP type, for example VPN3 traffic is carried on VPN3 LSPs. As discussed

1 In some cases sharing of backup bandwidth is subject to the Shared Risk Group (SRG) constraint. That is, backup paths

for link disjoint primary LSPs cannot share capacity if some of the disjoint links from the primary LSPs are in the same

SRG i.e., those disjoint links are actually provisioned through physical conduits that have shared risk such that one

failure in the physical network may bring down all of the primary LSPs at the same time. Although we have thecapability to address SRG in the protection design, we do not consider it in the case study.


6


7/14

above, IA LSPs have zero TE bandwidth. For VPN LSPs, the TE bandwidth is set to the amount of traffic carried (plus

required MPLS overhead). The links are not partitioned to classes and 100% of the link bandwidth is available for TE

subscription. All LSPs have a holding priority of 1. The setup priorities are as follows: 1 for VPN3, 2 for VPN2, 3 for

VPN1, 4 for VPN0 and 7 for IA LSPs. Thus, the VPN3 LSPs have the highest setup priority.

Design Scenario 2

This design scenario corresponds to a traffic-engineered network with single-class LSPs and class-based partitioning of

link bandwidth. Each LSP carries one traffic class, thus there are 5 types of LSPs: IA, VPN0 through VPN3, same as

Design Scenario 1. All of the link bandwidth is available for TE subscription, partitioned for various class types as

follows: IA: 0%, VPN0: 50%, VPN1: 25%, VPN2: 20%, VPN3: 5%, which is the same as the distribution used in the IP

VPN traffic model in Section 4. Thus, the link partitioning uses a priori knowledge of the class type bandwidth

requirements. LSPs have the same holding and setup priorities as assigned in Design Scenario 1

Design Scenario 3

This design scenario corresponds to a traffic-engineered network with multi-class LSPs and class-based partitioning of

link bandwidth. For Design Scenario 3, single-class LSPs are still used to carry IA traffic while the four classes of VPN

traffic are carried altogether on multi-class VPN LSPs. Each multi-class LSP contain bandwidth requests for each of the

four classes of VPN traffic. All of the link bandwidth is available for TE subscription, partitioned as follows: IA: 0%,VPN0: 50%, VPN1: 25%, VPN2: 20%, VPN3: 5%, same as in Design Scenario 2. All LSPs have a holding priority of 1.

Single-class IA LSPs have a setup priority of 7 and multi-class VPN LSPs have a setup priority of 1.

5.2 MPLS TE Design Procedure and ToolThe MPLS network design was performed using a commercially available MPLS network design and simulation tool

customized for Lucent Technologies. The tool is capable of conducting TE design and performs flow analysis andpacket-based discrete event simulation based on the output of the TE design. Using this tool, the following steps were

followed in the MPLS TE design:

Import network topology and traffic demands for multiple CTs

Import LSP bandwidth requests for single or multiple CTs

Run design action to find routing paths of primary and backup LSPs with the objective to minimize the totalconsumed link bandwidth

Run flow analysis that places traffic onto the routed LSPs and collects network performance data (such as hop

counts and link bandwidth subscription by both primary and backup LSPs)

The MPLS network topology (nodes and links) was imported to the tool via Juniper configlet files provided by SPA.

Figure 3 shows a non-geographical display2 of SPA MPLS network consisting of 7 Juniper T640 routers and 10 OC-48

links as viewed via the graphical user interface (GUI) of the tool after the import of the configlet files. As shown in the

figure there is only one OC48 link between Core4 and Gate1. For redundancy purposes, a second OC48 link between thepair was added in the MPLS TE design (for a total of 11 OC-48 links).

2 Since no coordinates are provided in the Juniper configlet files, the display of network nodes in Figure 3 does notreflect their geographical locations. The nodes were later moved to locations on a map (Figure 4).


7


8/14

Figure 3: SPA MPLS network after configlet file import to the tool


8


9/14

Figure 4: Network model after geographical modifications

The traffic demands and LSP information (including bandwidth requests) were imported to the tool via CSV based text

files. Figure 5 shows the network model in Design Scenario 3 after traffic demands and LSP information are imported.

Figure 5:Network model for Design Scenario 3 showing IA and multi-class VPN LSPs

5.3 MPLS Network DesignThe TE LSP routing problem is NP-hard and the solution for primary path routing has complexity of ~2|D||A|, where |D| isthe number of LSPs and |A| is the number of unidirectional links (for example, for the first two design scenarios, there

are |D| =184 LSPs and 12 bi-directional links, |A|=24). The complexity for a protection design is higher and includes an

additional factor relating to the number of failures to be considered. The primary/backup path routing problem networks

of the size considered in this study is computationally notoriously difficult and finding optimal solutions is impossible.

Our design uses a heuristic based approach to arrive at a quality solution satisfying the design objectives.

After network topology, traffic demands and LSPs import, the routing of primary and backup LSPs was determined by

the mpls_ds_te design action available in the tool, custom built for Lucent Technologies. The mpls_ds_te design action

uses a heuristic approach (as mentioned above) based on LSP ordering to arrive at a network design solution with a

minimum cost objective. For this study, the cost is defined to be the total link bandwidth subscribed by the LSPs acrossthe network. The outcome of the TE design is a set of explicitly routed LSPs, which can be evaluated based on the

following metrics:

Minimum, maximum and average hop count of LSP explicit routes


9


10/14

Minimum, maximum and average link TE subscription3

Subsequent to the TE design, we ran flow analysis (FLAN) available from the tool where traffic demands were placed onthe primary LSP ER paths and link utilization4 was measured. We did not conduct failure analysis in this study.

5.4 Study Results and AnalysisThe tool is capable of generating a rich set of class-based and summary reports on the outcome of the TE design and

Flow Analysis. For example, Figure 6 to Figure 8 show portions of the LSP explicit routes and link TE subscription

reports generated after the TE design, and link utilization report generated after FLAN, all for Design Scenario 2.

Figure 6: LSP Explicit Routes Report for Design Scenario 2 (Partial)

Figure 7: Link TE Subscription Report for Design Scenario 2 (Partial)

3 Link TE subscription refers to the portion of a links capacity that is reserved for all LSPs routed over the link during

TE design.4 Link utilization, as opposed to link TE subscription, refers to the portion of a links capacity that is consumedby actual

traffic. Its measurement is usually obtained through a flow analysis where actual traffic is placed onto the network. Alinks utilization may be higher or lower than its TE subscription.


10


11/14

Figure 8: Link Utilization Report for Design Scenario 2 (Partial)

Based on the information generated by the reports, we summarize the study results in the following descriptions with a

comparison among the three alternative Design Scenarios. The study results are presented based on the measurement ofthree metrics: LSP hop count, link TE subscription and link utilization.

LSP Hop Count

Minimum, average and maximum hop counts5 of primary and backup LSPs are summarized in Figure 9. Note that allprimary LSPs were successfully routed in all design scenarios. However, in Design Scenario 1 backup paths failed for 5

VPN LSPs (corresponding to 5 unprotected VPN demands), while in Design Scenario 3 backup paths failed for 4 multi-

class VPN LSPs (corresponding to 16 unprotected VPN demands). For Design Scenario 2, all backup LSPs were

successfully routed.

Backup

Primary

LSPHops (inCoreLinks)

553553553Max

Hops

2.86 1,32.95 322.712.7722.57 22.63 22AvgHops

111111111MinHops

332332222Max

Hops

1.53 11.571.1251.531.571.1251.501.541.125Avg

Hops

111111111MinHops

AllVPNIAAllVPNIAAllVPNIA

Scenario 3:58 LSPsScenario 2:184 LSPsScenario 1:184 LSPs

Backup

Primary

LSPHops (inCoreLinks)

553553553Max

Hops

2.86 1,32.95 322.712.7722.57 22.63 22AvgHops

111111111MinHops

332332222Max

Hops

1.53 11.571.1251.531.571.1251.501.541.125Avg

Hops

111111111MinHops

AllVPNIAAllVPNIAAllVPNIA

Scenario 3:58 LSPsScenario 2:184 LSPsScenario 1:184 LSPs

1 : Normalized to number of demands per VPN LSP

2 : Backup paths failed for 5 LSPs (5 VPN demands unprotected)

3 : Backup paths failed for 4 LSPs (16 VPN demands unprotected)

Figure 9: LSP Hop Counts

5 The calculation of hop count is based on the number of links traversed by the LSPs.


11


12/14

For IP VPN, the hop count for primary and backup LSPs increases from Design Scenario1 to Scenarios 2, 3 since class-

based link bandwidth partitioning employed in Design Scenarios 2 and 3 reduces the chances of picking topologically

shortest paths. The hop count for backup LSPs increases from Design Scenario 2 to Scenario 3 since it is more difficult

for Design Scenario 3 to route multi-class backup LSPs with a much higher total bandwidth (equivalent to routing 4single-class LSPs simultaneously) over the residual capacity left after routing of primary LSPs, leaving the backup LSPsto be routed over longer paths. The same difficulty also results in the 4 un-routable backup LSPs in Design Scenario 3.

For IA, the LSP hop counts are the same in all Design Scenarios since IA LSPs with zero TE bandwidth are always

routed over shortest paths.

Link TE Subscription by Primary and Backup LSPs

Link TE subscription, by primary and backup LSPs respectively, is summarized in Figure 10. In Design Scenario 1

where link bandwidth is not partitioned, LSPs of higher priority with smaller bandwidth get routed first6, causing those

LSPs of lower priority with larger bandwidth to be routed over longer paths (this also accounts for the 5 un-routablebackup IP VPN LSPs in Design Scenario 1 as noted in Figure 9). On the other hand class-based link partitioning was

employed in Design Scenarios 2 and 3, preventing higher priority LSPs from using up link capacity and leaving room for

lower priority IP VPN LSPs to find shorter paths. As a result, the average link TE subscription by primary LSPs

(referred to asprimary link TE subscription in subsequent discussion) in Design Scenario 1 is higher than those inDesign Scenarios 2 and 3. The average primary link TE subscriptions in Design Scenarios 2 and 3 are identical since the

class-based link partitioning was chosen to be proportional to the distribution of multi-class traffic. Finally, the difficulty

of routing multi-class LSPs, as mentioned above, led to a higher average backup link TE subscription for Design

Scenario 3 as compared to the other two scenarios.

96.85

96.85

98.86

Max

0.00

0.00

0.00

Min

Link TE Subscriptionby Backup LSPs (%)

38.07

18.68

35.78

Avg

85.87

54.59

64.63

Max

52.29

23.67

52.73

Min

74.37

54.98

77.02

Avg MaxAvgMin

97.8136.300.00Scenario 3

99.3736.300.00Scenario 2

99.9041.320.00Scenario 1

Link TE Subscriptionby All LSPs (%)

Link TE Subscriptionby Primary LSPs (%)Design

Scenario

96.85

96.85

98.86

Max

0.00

0.00

0.00

Min

Link TE Subscriptionby Backup LSPs (%)

38.07

18.68

35.78

Avg

85.87

54.59

64.63

Max

52.29

23.67

52.73

Min

74.37

54.98

77.02

Avg MaxAvgMin

97.8136.300.00Scenario 3

99.3736.300.00Scenario 2

99.9041.320.00Scenario 1

Link TE Subscriptionby All LSPs (%)

Link TE Subscriptionby Primary LSPs (%)Design

Scenario

Figure 10: Link TE Subscription by Primary and Backup LSPs

Link Utilization by Traffic Carried on the Primary LSPs

Link utilization7, in both forward and return directions, by traffic carried on the primary LSPs is summarized in Figure

11. Note that some links have link utilization greater than 100%. This is because IA LSPs are routed over shortest paths

with zero TE bandwidth in this study, leaving them with no bandwidth reservation on the links. On certain links whereIA traffic is routed and there is a high level of IP VPN traffic, the link utilization will be greater than 100%. Counting

both forward and return directions, the total link capacity consumed by traffic carried on primary LSPs is 28,257 Mbps

for Design Scenario 1 and 25,632 Mbps for both Design Scenarios 2 and 3.

As a general technical summary,

Scenario 1 is best in terms of minimum hop counts. Scenario 2 is best if all LSPs are to be successfully protected.

Scenario 2 is best in terms of overall TE subscription.

Scenarios 2 and 3 are best in terms of link utilization.

6 This behavior is a result of the heuristic approach based on LSP ordering.7 The calculation of link utilization is based on the link bandwidth after deducting the SONET framing overhead.


12


13/14

12,816

12,816

14,520

Total FwdLinkCapacityConsumed(Mbps)

12,816102.3549.000.00112.0349.0012.36Scenario 3

12,816102.3549.000.00112.0349.0012.36Scenario 2

13,737116.1952.520.00117.8455.5112.36Scenario 1

Total RtnLinkCapacityConsumed(Mbps)

MaxRtnUtil(%)

AvgRtnUtil(%)

MinRtnUtil(%)

MaxFwdUtil(%)

AvgFwdUtil(%)

MinFwdUtil(%)

DesignScenario

12,816

12,816

14,520

Total FwdLinkCapacityConsumed(Mbps)

12,816102.3549.000.00112.0349.0012.36Scenario 3

12,816102.3549.000.00112.0349.0012.36Scenario 2

13,737116.1952.520.00117.8455.5112.36Scenario 1

Total RtnLinkCapacityConsumed(Mbps)

MaxRtnUtil(%)

AvgRtnUtil(%)

MinRtnUtil(%)

MaxFwdUtil(%)

AvgFwdUtil(%)

MinFwdUtil(%)

DesignScenario

Figure 11: Link Utilization by traffic carried on primary LSPs

Scenario 2 generates a TE design with the lowest link utilization and overall link capacity consumed while maintaining

only slightly higher hop counts for primary and backup LSPs. We discuss further considerations for service providers in

the next section.

5.5 What Does It Mean To Service Providers?From a service providers perspective, the various design scenarios addressed in the study represent different options for

the service provider to use in designing its MPLS network. Each of the network performance metrics shown above

corresponds to a certain key requirement for the operation of the MPLS network. For example, a maximum LSP hop

count for a particular class of traffic may be needed in order to meet the end-to-end delay requirement for the class of

traffic (such as max end-to-end delay for VoIP). Link subscription by LSPs reflects how efficient the capacity of the

MPLS network is used by multi-class traffic, and could be used to derive the total network cost or cost per unit

bandwidth carried. As the study showed, various design scenarios led to different measurements of network performancemetrics. Depending on the particular requirements set up by the service provider for the MPLS network, some design

scenario would be the best option for the service provider to adopt. For example, Design Scenario 2 (with single-class

LSPs and class-based link bandwidth partitioning) generates a TE design with the lowest link utilization and overall link

capacity consumed while maintaining only slightly higher hop counts for primary and backup LSPs, will be a good

choice for a service provider looking to enhance the MPLS network efficiency and reduce unit bandwidth cost.

Single class LSPs represent a more granular routing, thus making better use of available capacity. However, from a

service providers point of view, multi class LSPs could present operational advantages. While partitioning bandwidthmay result in under-utilization of existing resources, it also creates fairness in that a certain bandwidth is always

available for each class type.

There are additional design parameters that can be used in the TE design to meet other MPLS requirements desired by

the service provider. For example, a different protection policy such as MPLS Fast Re-Route (FRR) can be used in the

TE design to meet the service providers requirement for fast recovery in the event of network failures. Overall, LWS

has the full capability and innovative tools to help service providers design an MPLS network that meets their specific

requirements for efficient network utilization, low cost, and assured QoS support and high availability for multi-classtraffic carried over the MPLS network.

6 Conclusion and Future Study OpportunitiesThe following presents some additional areas where we would like to conduct future studies:

MPLS TE design with a class-based link bandwidth partitioning based upon no a priori knowledge of the multi-

class traffic In the current study, the class-based link bandwidth partitioning used a priori knowledge of the

relative bandwidths required by the various classes of IP VPN traffic. In reality, the actual IP VPN traffic for


13


14/14

each class type may deviate from the original forecast due to uncertainty in traffic forecast or growth and

therefore would not match the partitioning of link bandwidth. A further study of MPLS TE design would be

employing a class-based link bandwidth partitioning that is not proportional to the distribution of multi-class

traffic and examining how it affects the routing of LSPs and the consequent network performance.

MPLS TE design with different protection policies This study assumedbackup LSPs are derived in the TE

design based on end-to-end path protection. Different protection policies can be used in the TE design, such as

one-to-one or facility-based FRR, or a mixed of end-to-end path protection and FRR applied differently to

various classes of traffic deepening on their availability requirements.

Failure analysis to assess the robustness of the various TE designs In this new study we would run failure

simulation (failing a single link or single node at a time) and examine how backup LSPs kick in to protect

traffic on the affected primary LSPs and the consequent network performance.

End-to-end performance analysis for multi-class traffic over an MPLS network The current study focused on

measuring the network performance at the flow level that is, LSP hop count and link utilization. The tool we

have is capable of performing end-to-end performance analysis at packet level (packet delay, jitter and loss) for

multi-class traffic carried over a traffic-engineered MPLS network.

Analysis for cases where IA traffic takes non-zero LSP bandwidth.


Documents

Service Provider MPLS Network Design Study