MPLS

Traffic Engineering using MultipleMultipoint-to-Point LSPsHiroyuki Saito, Yasuhiro Miyao, and Makiko YoshidaC&C Media Research Laboratories, NEC Corporation

4-1-1 Miyazaki, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, [email protected]

Abstract—Traffic engineering aims to optimize the utilization of existingnetwork resources for load balance and failure recovery, and these are tobe accomplished in a scalable fashion. This paper proposes a traffic engi-neering scheme using multiple multipoint-to-point (m-t-p) Label SwitchedPaths (LSPs) which can reduce the number of LSPs and required labelsin links. The scheme consists of m-t-p LSP creation and flow assignment.Routes are first selected, and m-t-p LSPs are designed to include them. Them-t-p LSP design problem is formulated as a 0−1 integer programmingproblem. The flow assignment problem is formulated as a mixed integerprogramming problem in which maximum link load, i.e., maximum con-gestion, is minimized. Numerical comparisons with the conventional point-to-point LSP approach show that the m-t-p LSP approach can reduce thenumber of required LSPs and labels. Moreover, numerical comparisonswith conventional Shortest Path Fast based flow assignment show that ourflow assignment scheme can reduce maximum link load.

Keywords—Traffic engineering, MPLS, multipoint-to-point LSP, flow as-signment

I. INTRODUCTION

Traffic engineering has become an essential requirement forInternet Service Providers (ISPs) to optimize the utilization ofexisting network resources and it enables to maintain a desiredoverall Quality of Service (QoS) with fewer network resources.One of its key objectives is to balance loads across a network.Load balancing leads the number of overutilized links, whichwill have low QoS, and underutilized links, which represent awaste, to be reduced.

Load balancing requires an ability to control traffic flow pre-cisely. In the traditional metric-based control, an administratorcan change only link metrics, and changes of some link met-rics may affect the overall traffic flow. To control traffic flow asthe administrator wants, it is necessary to adjust the link metricsover a network; however, sometimes this adjustment is impossi-ble. Therefore, explicit route based control, in which the admin-istrator can control traffic as he wants, appears to be a far morepromising choice.

In traffic engineering using the explicit routes there are tworequirements. First, for effective load balancing across a net-work, each ingress node should have a diversity of explicitroutes to each egress node. Without that, effective load bal-ancing would be impossible. Second, for reliability, among thediverse routes between any given pair of ingress/egress nodes,there should be at least one which is not affected in each indi-vidual failure case.

One way to provide an explicit routing capability is to useMPLS (Multiprotocol Label Switching)[1][2]. MPLS pro-vides label swapping based forwarding, and by using it, La-bel Switched Paths (LSPs) are established between ingress andegress nodes. The routes of the LSPs can be specified explicitly.

2

7

3

Egress node

1

9

Multipoint-to-point LSP

4

Ingress node

MPLS domain

58

6

Fig. 1. Example of a multipoint-to-Point LSP

In addition, with the establishment of backup LSPs, a networkwill be able to cope with failures in nodes and links.

One way to establish routes in a MPLS network is to usepoint-to-point (p-t-p) LSPs. Here, a route between an ingressnode and an egress node is represented by a single p-t-p LSP.Conventional MPLS traffic engineering frameworks [3] [4] andmechanisms [5] [6] have been assumed to use p-t-p LSPs. Toconnect all edge node pairs by using p-t-p LSPs, the totalnumber of LSPs necessary to cover the entire network will beO(N2), where N is the number of edge nodes. For a large net-work, then, the p-t-p LSP approach can easily become impracti-cally cumbersome.

Multipoint-to-point (m-t-p) LSPs (see Fig. 1) have been pro-posed [2] to avoid this problem. Here, one LSP represents routesfrom multiple ingress nodes to a single egress node. In termsof graph theory, the shape of the m-t-p LSP is an inverted treerooted at an egress node. At connection points in the tree, labelsassigned to different incoming links are merged into one labelassigned to an outgoing link. To provide connections betweenall edge node pairs by using m-t-p LSPs, since only one LSP perindividual egress node is sufficient, the total number of LSPsrequired is O(N).

Traffic engineering schemes based on m-t-p LSPs, however,have yet to be proposed. The reason is the difficulty of creat-ing them. As mentioned before, each ingress/egress node pairshould have diverse routes, including at least one route that isnot affected in each individual failure case. Since individual p-t-p LSPs correspond to individual routes, it is easy to representsuch routes with the p-t-p LSPs. A single m-t-p LSP, on theother hand, represents routes from multiple ingress nodes to an

egress node, and it is not clear which routes should be includedin each m-t-p LSP. We have, however, been able to develop amathematical scheme, represented here, creating a set of m-t-p LSPs which satisfies the requirement that each ingress/egressnode pair should have a diversity of routes including at least oneroute that is not affected in each individual failure case, and thatkeeps the number of m-t-p LSP as small as possible. Route se-lection and m-t-p LSP design are performed separately, and them-t-p design problem is formulated as a 0− 1 integer program-ming problem.

Even with successful m-t-p creation, however, the problemof flow assignment remains. Villamizar[6] has proposed a localoptimization scheme. This scheme only determines routes fora single traffic demand at any one time, and for this reason, itcannot optimally utilize network resources. A global optimiza-tion scheme, on the other hand, determines routes of all trafficflow simultaneously; therefore, it can provide the optimal so-lution. Concept of global optimization has been discussed [5][7], but no detailed scheme has been proposed before. There-fore, this paper proposes a global optimization scheme for flowassignment. In our scheme, the flow assignment problem is for-mulated as a mixed integer programming problem, where flowassignment of all given traffic demands is simultaneously deter-mined while minimizing maximum link load. By minimizingmaximum link load, the loads of overutilized links decreases, asa result, the loads across a network will be balanced. Moreover,the scheme can provide flow assignment for failure recovery, inwhich maximum link load is minimized over all failure states.

The remainder of this paper is organized as follows. We de-scribe the framework of m-t-p LSP traffic engineering in SectionII. We propose the m-t-p design scheme in Section III, and theflow assignment scheme in Section IV. We give numerical ex-amples of the use of both in Section V.

II. TRAFFIC ENGINEERING USING MULTIPOINT-TO-POINT

LSPS

A. Assumptions

A.1 Traffic Demand

In this paper, the term “traffic demand” refers to all the trafficbetween an ingress node and an egress node, or only to a partof the overall traffic. Additionally, it is used to refer, for ex-ample, to all traffic of the same Forwarding Equivalence Class(FEC) [1], or to some portion of it. Hereafter, we assume thatboth traffic control and failure recovery are performed for eachindividual traffic demand. This assumption is not mandatory,and our proposal can be applied to dividing traffic demands intoseparate sections.

A.2 Pre-assigned m-t-p LSPs

Multipoint-to-point LSPs are pre-assigned before traffic de-mands are known, and flow assignment is determined after theyare known. M-t-p LSPs are created simply on the basis of thenetwork topology alone; link bandwidth is not a consideration.M-t-p LSPs cannot, however, provide exclusive services speci-fied between ingress/egress node pairs; that has to be done byp-t-p LSPs.

2

7

Egress node

1

9

lsp 1

4

58

6

Ingress node

lsp 2

lsp 3

lsp 4

3

2

7

Egress node

1

9

Traffic demand <8,1> is assigned to lsp 1.

4

58

6

Ingress node

3

(a) pre-assigned m-t-p LSPs

(b) flow assignment




Fig. 2. Example of load balancing using m-t-p LSPs

B. Concept

B.1 Load balancing with multiple m-t-p LSPs

For an ingress node, one m-t-p LSP seems to be one route tothe egress node. Therefore, except for creating m-t-p LSPs, loadbalancing with m-t-p LSPs and that with p-t-p are the same.

Fig. 2 shows an example of load balancing with m-t-p LSPs.There are two m-t-p LSPs (lsp 1 and lsp 2) for egress node 1from ingress nodes 8 and 9 , and two m-t-p LSPs (lsp 3 andlsp 4) for egress node 4 from ingress nodes 8 and 9 (Fig. 2(a)). The same volume of traffic demand is assumed for eachingress/egress node pair. To avoid concentrating traffic alongany one link, traffic demand <8,1>, i.e. traffic demand from 8to 1 is assigned to lsp 1, and traffic demand <8,4> is assigned tolsp 4 (Fig. 2 (b)). Similarly, traffic demand <9,1> and <9,4>are assigned to lsp 2 and lsp 3 respectively (Fig. 2 (b)). Asa result, no single link is assigned traffic from more than onetraffic demand, i.e. link loads are balanced.

B.2 Failure recovery with multiple m-t-p LSPs

Our failure recovery is based on pre-assigned backup routes[8][9]. A backup route is prepared for each working route, andwhen a failure occurs, traffic on a damaged working route isrerouted to its backup route. Here, working and backup routes

2

7

Egress node

1

9

lsp 1

4

58

6

Ingress node

lsp 23

Working route

Spare route

FECelement Label Label

NextHop

NextHop

working backup

xxx.yyy.zzz 5 612 15

The extended FTN

Fig. 3. Example of recovery using m-t-p LSPs

are assigned not to be affected in each individual failure casesimultaneously. We suppose single node failures in this paper,and, for this case, each working route and its backup route mustbe created not to share a single node in between. The rerout-ing procedure is completed at the ingress node, so no signalingprocedures are required. This speeds the rerouting process.

In our proposed architecture, there are no m-t-p LSPs limitedto being exclusively a working route or a backup route. OneLSP can be a working route for one traffic demand and also abackup route for another traffic demand.

Each ingress node has a map that determines the switching ofworking routes to backup routes. This map is an extension ofan FTN (FEC to Next Hop Label Forwarding Entry (NHLFE)Map) and includes information for backup routes as well as forthe working routes.

The example in Fig. 3 includes working and backup routes,and illustrates an extended FTN. There are two m-t-p LSPs (lsp1 and lsp 2) for egress node 1. For traffic demand <8,1>, lsp 1is the working route and lsp 2 is the backup route. The extendedFTN is assigned to ingress node 8.

In order for rerouting from a working route to a backup routeto be carried out, an ingress node needs to receive an alarm sig-nal indicating a route failure. In transport networks, Alarm In-dication Signals (AISs) are used, but currently there are no suchsignals in MPLS networks. One possibility is to use a Label Re-lease message [10], which is sent upstream when there is no nexthop. Label Release messages could be used as alarm signalsif they had an option not to release labels. Alternatively, Inte-rior Gateway Protocol (IGP) Link State Advertisements (LSAs)[11] could be used. LSAs contain information concerning a lo-cal piece of topology. They are broadcasted upon detection of afailure of a link or a node, and an ingress node which receivedLSAs would learn from the received LSAs whether or not a fail-ure had occurred affecting the traffic originating from the ingressnode, and thus, whether or not it was necessary to switch trafficfrom its working route to its backup route.

��

��

��

��

��

��

��

��

Fig. 4. Operation and Design Flow

C. Design and operation

M-t-p LSP creation and flow assignment are performed sepa-rately (see Fig. 4).

In m-t-p LSP creation, routes are selected first, and then m-t-p LSPs are designed to include the selected routes for eachingress/egress node pair while minimizing the number of m-t-pLSPs.

Flow assignment determines which LSPs are used for giventraffic demands. Reconfiguration of flow assignment of existingtraffic demands may be performed periodically or, for example,when the load on a given link rises significantly.

D. System architecture

Fig. 5 shows two example system architectures: (a) theserver-oriented system and (b) the edge-oriented system .

In the server-oriented system, centralized control such as aconfiguration server sets m-t-p LSPs and flow assignment. Forthe m-t-p LSP setup, the configuration server designs m-t-pLSPs and sets the designed m-t-p LSPs to each routers by us-ing an administrative procedure. For the flow assignment, theconfiguration server determines flow assignment and sets FTN.The configuration server collects the traffic flow statistics mea-sured by each ingress node. This statistics is used when flowassignment is reconfigured.

In the edge-oriented system, edge nodes design m-t-p LSPsand determines flow assignment.

The m-t-p LSP setup is done by each egress node. Each egressnode designs all m-t-p LSPs based on topology information ob-tained by LSAs. Then, each egress nodes set own m-t-p LSPsby using signaling procedure such as Label Distribution Proto-col (LDP) [10][12].The LDP for m-t-p LSPs is in further studyin IETF MPLS Working Group. Here, we assumed that La-bel Mapping Messages for explicit m-t-p LSPs are initiated byegress nodes, and then transmitted to ingress nodes.

The flow assignment is performed by each ingress node. Thetraffic flow statistics is measured by ingress nodes, and they aresent to other ingress nodes by using a distributed procedure.There is no standard procedure to distribute such traffic flowinformation, but the OSPF opaque LSA can be used for this pur-pose [13]. Ingress nodes determines flow assignment based ongiven traffic demands and/or measured traffic demands, and setFTN.

Traffic flowmeasurement

m-t-p LSPdesign

Configuration Server

flow assignment

LSP setup

MPLS domainEdge node

flow assignment

(a) Server-oriented

MPLS domain

(b) Edge-oriented

LDP

Traffic flowmeasurement

Edge node

flow assignmentm-t-p LSPdesign

as egress node as ingress node

Fig. 5. System architectures

III. MULTIPOINT-TO-POINT LSP DESIGN

A. Route Selection Step

Optimal load balance in flow assignment might be achievedby employing all possible routes, but this would require exces-sive calculation time. Considering the fact that long routes tendto make relatively little contribution[14], we have establishedthe following criteria for route selection:

Choose a set of routes between the ingress node i /egress node e pair P(i,e) such that the hop count ofeach route p(i,e) is no greater than that of the routehaving the smallest hop count plus ξ which can be thegiven number and such that each route p(i,e) have atleast one route which do not share a single node inPi,e. If no set can be chosen that meets both of thesecriteria, choose, a route pair that does not share asingle node in between and have the smallest and thesecond smallest hop count routes.

Route selection is conducted by means of the Dijkstra algorithmand the depth first search algorithm.

7

Egress node

94

Ingress node

58

63

1)1,2(

th

1)2,5(

th

1)1,3(

th

1)5,8(

th

1),(Variable t

mlh

2

11

)2,3(th

1)5,2(

th

1)3,2(

th

1)8,5(

th

1)8,6(

th

1)4,7(

th

1)7,4(

th

1)2,6(

th1

)6,8(th

1)6,2(

th

1)9,6(

th1

)6,9(th

1)7,9(

th

1)9,7(

th

1)7,6(

th1)6,7(

th1

)6,3(th

1)3,6(

th

1)6,5(

th1)5,6(

th

1)7,3(

th1)3,7(

th1

)4,3(th

1)3,4(

th

Fig. 6. Variables represent a m-t-p LSP candidate

B. Multipoint-to-Point LSP Design Step

The m-t-p LSPs design determines m-t-p LSPs which in-cludes all the selected routes while minimizing the number ofm-t-p LSPs required. The m-t-p LSP design problem is formu-lated as a 0−1 integer programming problem for each individualegress node.

The following necessary conditions must be satisfied.1. A m-t-p LSP does not include loop structure.2. A m-t-p LSP is composed of a part of the selected routes

connected to the egress node.3. Each of the selected routes is included at least in one m-t-p

LSP.To formulate these necessary conditions, we introduce m-t-pLSP candidates and route accommodation indicators.

The m-t-p LSP candidate is represented by a set of variableshte

(l,m), which takes a value ’1’ if m-t-p LSP candidate te useslink (l,m), otherwise takes a value ’0’. A set of m-t-p LSPcandidates is given per egress node, and it is used to formulatethe first and second conditions. By solving the problem, all or apart of the m-t-p LSP candidates will become m-t-p LSPs whichinclude all the selected routes.

An example of a m-t-p LSP candidate is illustrated in Fig. 6.This m-t-p LSP candidate is for egress node 1, so the variablesfor outgoing links (1, 2) and (1, 3) from egress node 1 are elim-inated.

By using the m-t-p LSP candidates, the first and second con-ditions are expressed as follows.

1. In each node, summation of the values of hte

(l,m) in outgo-ing links is 1.

2. For each route, summation of the values of hte

(l,m) alongthe route is equal to summation of hop counts of the route.

The route accommodation indicator indicates whether eachselected route is included in a set of LSPs or not, and it is ex-pressed as 0 − 1 variable δte

p(i,e). Then, the third condition is

expressed as follows.3. Summation of the values of δte

p(i,e)over m-p-t LSP candi-

dates is equal to or more than one.We summarize notations for formulation of m-t-p LSP design

problem as follows.Sets:• {e}: Egress node.• Te: A set of m-t-p LSP candidates of egress node e.

• N : A set of nodes.• N Ingress

e : A set of ingress nodes for egress node e.• L: A set of links, and each element is (l,m). l is the upper

node and m is the lower node.• Le: A subset of link set L, in which links from egress node

and links to ingress nodes are removed. Le = L−{(e,m) :(e,m) ∈ L} − {(l,m) : (l,m) ∈ L, ∀m ∈ N Ingress

e }• P(i,e): The set of selected routes between ingress node i

and egress node e.• Lp(i,e) : A set of links used in route p(i,e).

Variables:• rte : Set to ’1’ if m-t-p LSP candidate te includes a part of

selected routes, otherwise set to ’0’.• hte

(l,e): Set to ’1’ if m-t-p LSP candidate te uses link (l,m),otherwise set to ’0’.

• δtep(i,e)

: Set to ’1’ if m-t-p LSP candidate te includes routep(i,e), otherwise set to ’0’.

The m-t-p LSP design problem is formulated as follows.

Min∑

te∈Te

rte (1)

subject to∑

{m:(l,m)∈Le}hte

(l,m) ≤ 1

(∀l ∈ N\{e}, ∀te ∈ Te) (2)∑

(l,m)∈{Lp(i,e)∩Le}

hte

(l,m) ≥ |Lp(i,e) |δtep(i,e)

(p(i,e) ∈ P(i,e), i ∈ N Ingresse , te ∈ Te)(3)

∑

te∈Te

δtep(i,e)

= 1

(∀p(i,e) ∈ P(i,e), ∀i ∈ N Ingresse ) (4)

∑

i∈NIngresse

∑

p(i,e)∈P(i,e)

δtep(i,e)

≤∑

i∈NIngresse

|P(i,e)|rte (∀te ∈ Te) (5)

hte

(l,m), δtep(i,e)

, rte = 0/1 (6)

Here, || means the number of elements. For example, |Lp(i,e) |means the number of links used by path p(i,e).

The objective function (1) indicates minimizing the numberof m-t-p LSP candidates. The constraint (2) gives the first con-dition. The constraint (3) gives the second condition. The con-straint (4) gives the third condition. The constraint (5) judgeswhether each m-t-p LSP candidate te is used to include at leastone route. If one or more than one δte

p(i,e)are set to 1, which

means te includes one or more than one routes, rte is set to1. The coefficient |P(i, e)| is same as the maximum number of∑

i∈NIngresse

∑p(i,e)∈P(i,e)

δtep(i,e)

, and it keeps rte equal to orless than 1.

IV. FLOW ASSIGNMENT

The flow assignment scheme is based on our previous work[15]. In this work, working routes, backup routes and link ca-pacities are determined while accommodating the given trafficdemands with minimum cost. On the other hand, in this paper,

working routes and backup routes of given traffic demands aredetermined while minimizing maximum link load.

Here, we introduce states, each of which represents a set ofnode and link status, i.e. normal or failure. A set of states isinput for the flow assignment, and maximum link load will bedetermined over the given states.

The scheme requires working route candidates for each trafficdemand and backup route candidates for each working route,where each backup route candidate does not share the same nodewith its working route. These candidates are created from routeset P(i,e). First, each route in P(i,e) is set to be a working routecandidate. Then, each route which does not share a single nodewith its working route is set to be a backup route candidate.

Notations, except those explained in the previous section, aresummarized as follows.

Sets:• D: A set of traffic demands.• S: A set of states.• Ls: A set of links affected at state s.• Id: A set of working routes of traffic demand d.• Jid : A set of backup routes of working route id. Backup

route jid does not share the same node with its workingroute id.

Variables:• fid : Set to ’1’ if id is used otherwise set to ’0’.• fjid

: Set to ’1’ if jid is used otherwise set to ’0’.• µmax: Maximum link load.Constants:• vd: Required capacity of traffic demand d• πs

id: Set to ’1’ if the working route id survives at state s

otherwise set to ’0’.• g

(l,m)id

: Set to ’1’ if the route id uses link (l,m) otherwiseset to ’0’.

• b(l,m): A link capacity of link (l,m).The flow assignment problem is formulated as follows.

Min µmax (7)

subject to∑

id∈Id

fid = 1 (∀d ∈ D) (8)

∑

jid∈Jid

fjid= fid (∀id ∈ Id, ∀d ∈ D) (9)

∑

d∈D

∑

id∈Id

{g(l,m)id

πsidvdfid +

∑

jid∈Jid

(1 − πsid

)πsjid

g(l,m)jd

vdfjid}

≤ µmaxb(l,m)

(∀(l,m) ∈ {L − Ls}, ∀s ∈ S) (10)

fid , fjid= 0/1 (11)

The objective function (7) indicates minimizing maximumlink load. The constraint (8) means that one of working routesmust be used per traffic demand. The constraint (9) means thatif working route id is used, one of backup routes of the workingroute must be used. The constraint (10) gives maximum linkload. The first term means link capacities required by workingroutes, and the second means link capacities required by backup

n1

n8n7

n6

n4n3

n2

e2

e1

e3 e4

e6

e7

e8

e5

e5

e2 e1

e6

e8

e11

n2

e3

n1

e4e7

n6

n3

n7

e9

n11

n10e10

n5

n4

n9

n8

��

��

Fig. 7. Network Model

routes. The link capacities along backup routes are required onlywhen their working routes are damaged.

In this formulation, the overall traffic of given traffic demandd is assumed to be assigned to a single route. Changing variablesfid and fjid

from 0−1 variables to real variables, enables to usemultiple routes.

V. NUMERICAL EXAMPLES

A. Basic Results

We evaluated reduction in the number of LSPs and labels byapplying multipoint-to-point LSPs, and load balancing effect onm-t-p LSPs.

Two network models: 16-node and 26-link network (16,26)(see Fig. 7(a)) and 22-node and 45-link network (22,45) (seeFig. 7(b)) have been exploited. These network are modifiedfrom those in [16] and [15] as follows. All nodes in the individ-ual original networks are assumed to be transit nodes, and thesame number of edge nodes are added to the individual origi-nal networks. Each edge node is connected to two transit nodes.The reason of this modification is to avoid the situation that traf-fic demands lose when ingress or egress nodes of the traffic de-mands fail. In (16,26), four traffic demands per each edge pairare given [16]. In (22,45), four traffic demands with the samebandwidth for each edge node pair are given. The additional hopcount in the route selection step is set to 1. Only links betweentransit nodes are exploited for calculation of the maximum linkload.

First, the number of LSPs and labels are evaluated (Fig. 8and Fig. 9). The number of m-t-p LSPs is 16% of that of p-t-pLSPs in the case of (16,26) and 27% in the case of (22,45). Thisresult clearly shows that the m-t-p LSP approach can remark-ably reduce the number of LSPs, which should be managed in anetwork.

(16,26) (22,45)

p-t-p m-t-p m-t-pp-t-p0

100

200

300

400

500

600

700

Nu

mb

er o

f th

e ov

eral

l L

SP

s

Fig. 8. Number of LSPs

(16,26) (22,45)

p-t-p m-t-p m-t-pp-t-p

average

maximum

average

maximum

0

10

20

30

40

50

60

70

80

Nu

mb

er o

f L

abel

s

Fig. 9. Number of Labels

On the other hand, the maximum number of labels requiredfor m-t-p LSPs is 86% of that for p-t-p LSPs in the case of(16,26) and 73% in the case of (22,45). This result also showsthat the m-t-p LSP approach can reduce the number of link la-bels, which needs to be managed for each link. The reductionis smaller compared with the previous evaluation. The reason isthat each m-t-p LSP consists of more links than those of eachp-t-p LSP.

From these results, the m-t-p LSP approach could establish agiven set of routes in a scalable fashion.

Next, link load is evaluated in two cases: a) a normal case,where only a normal state is supposed, and b) a failure case,where each individual transit node failure is supposed. Theshortest path fast (SPF) based flow assignment, which is usedfor the conventional IGP such as OSPF, is performed for com-parison. Each link cost is assumed to be reciprocal of each linkcapacity. In the failure case, a minimum cost route for each traf-fic demand is searched in the topology in which a failure nodeis removed. The result is shown in Fig. 10.

In the normal case, the maximum link load obtained by theproposed scheme is 70% of that obtained by the SPF based flowassignment in the case of (16,26) and 38% in the case of (22,45).

(16,26) (22,45)

SPF Proposed

Max

imum

lin

k l

oad

SPF Proposed0

0.2

0.4

0.6

0.8

1

Normal case

Failure case

Fig. 10. Load balancing result

In the failure case, it is 97% in the case of (16,26) and 69% inthe case of (22,45). This result shows that the proposed schemecan reduce the maximum link load in any case. However, thereduced rate depends on the topology. For example, in (16,22),choice of routes is limited because damaged node is removedfrom the original topology, so the reduced rate is small. Theproposed flow assignment is shown to be effective for load bal-ancing, especially in well-connected networks.

Processing time for flow assignment calculation may be aproblem in global optimization [5]. Therefore, we evaluate theprocessing time (Table I). The flow assignment calculation wasperformed by using the model description language AMPL andthe linear programming problem solver CPLEX version 6.5 onDEC Ultimate Server Model 533au2. Requirement to the pro-cessing time is dependent on a time cycle of operations. Thesevalue are small enough for hourly or daily operation.

TABLE I

PROCESSING TIME FOR FLOW ASSIGNMENT

Network # of demands CPU time (sec)the normal the failure

case case(16,26) 224 0.7 2.8(22,45) 440 18.7 55.1

B. Impact of the Number of Routes

To evaluate impact of the number of routes on the maximumlink load, we varied the additional hop counts to the minimumhop count. The results are shown in Fig. 11 and Fig. 12.

There is little difference in the maximum link loads inchanges of the additional hop count, though the number ofroutes increases, especially in the case of (22,45). This indicatesthat traffic flow is not assigned to the routes added by increas-ing the additional hop count. This result shows the long routesdo not affect the value of maximum link load and the additionalhop count of ’1’ is enough in our route selection scheme in theseexamples.

0

0.2

0.4

0.6

0.8

1

1 2 30

50

100

150

Max

imu

m l

ink

lo

ad

Nu

mb

er o

f ro

ute

s

Additional hop count

Number of routes

Maximum link loadin the normal case

Maximum link loadin the failure case

Fig. 11. Link load versus additional hop count: (16,22)

Number of routes

Maximum link load in the normal case

0

0.2

0.4

0.6

0.8

1

1 2 30

500

1000

1500

2000

2500

3000

3500

4000

Max

imu

m l

ink

lo

ad

Nu

mb

er o

f ro

ute

s

Additional hop count

Maximum link load in the failure case

Fig. 12. Link load versus additional hop count: (22,45)

VI. SUMMARY

This paper proposed a traffic engineering scheme using mul-tiple multipoint-to-point LSPs. Difficulty in traffic engineeringusing multiple m-t-p LSPs is to create m-t-p LSPs. A set ofm-t-p LSPs needs to satisfy the requirements that they providea diversity of routes including at least two routes which doesnot share any single node to each individual ingress/egress nodepair for effective load balance and reliability. We achieved theabove m-t-p LSP creation by separating route selection and m-t-p LSP design procedures, and formulating the m-t-p LSP designproblem as a 0 − 1 integer programming problem.

We also proposed a flow assignment scheme. Here, flow as-signment of all given traffic demands are determined while mini-mizing maximum link load. The proposed scheme can deal withfailure recovery.

Numerical examples showed that m-t-p LSPs could reducethe number of overall LSPs and the number of labels in eachlink in comparison with the p-t-p LSPs as well. In addition,the proposed flow assignment scheme could reduce maximumlink load in comparison with the Shortest Path Fast based flowassignment, and achieved effective load balance across each ex-ample network.

REFERENCES

[1] R. Callon, P. Doolan, N. Feldan, A. Fredette, G. Swallow, and A.Viswanathan, “A framework for multiprotocol label switching,” InternetDraft (Work in Progress), draft-ietf-mpls-framework-05.txt, September1999.

[2] E. C. Rosen, A. Viswanathan, and R. Callon, “MultiprotocolLabel Switch-ing Architecture,” Internet Draft (Work in Progress) , draft-ietf-mpls-arch-06.txt, August, 1999.

[3] D. O. Awduche, etc, “Requirements for traffic engineering over MPLS,”RFC 2702, September, 1999.

[4] G. Swallow, “Traffic engineering & MPLS,” IW-MPLS ’98,http://info.uu.net/ads/techconf, November 1998.

[5] F. Fahim, “Constraints Based Routing Algorithms and Applications” IW-MPLS ’98, http://info.uu.net/ads/techconf, November 1998.

[6] C. Villamizar, “OSPF Optimized Multipath (OSPF-OMP),” Internet Draft(Work in Progress), draft-ietf-ospf-omp-02, February 1999.

[7] M. D. O’Dell, “Some pretty good challenges building very large net-works,” IW-MPLS ’98, http://info.uu.net/ads/techconf, November 1998.

[8] M. M. Slominski and H. Okazaki, “ Guided restoration algorithm for ATMcross-connect networks,” Proc. ICC ’94, pp. 466-470, March 1994

[9] R. Kawamura, K. Sato, and I. Tokizawa, “Self-healing ATM network tech-niques utilizing virtual paths,” Proc. NETWORKS ’92, May 1992.

[10] L. Anderson, P. Doolan, N. Feldman, A. Fredette, and B. Thomas,”LDPSpecification,” Internet Draft (Work in Progress), draft-ietf-mpls-ldp-06.txt, October,1999.

[11] J. Moy, “OSPF Version 2,” Internet RFC 2178, April 1998.[12] B. Jamoussi, ”Constraint-Based LSP Setup using LDP,” Internet Draft

(Work in Progress), draft-ietf-pls-cr-ldp-03.txt, September 1999.[13] R. Coltun, “The OSPF Opaque LSA Option,” RFC2370, July 1998.[14] M. Herzberg, S. J. Bye, and A. Utano, “The hop-limit approach for spare-

capacity assignment in survivable networks,” IEEE/ACM Transaction Net-working, vol. 3 no. 6, pp. 775-784, December 1995.

[15] H. Saito, Y. Miyao, T. Komine, and F. Kubota, “Joint capacity assignmentto state-independent working and spare paths for enhanced network sur-vivability,” Proc. ICC’98, June 1998.

[16] D. Mitra, J. A. Morrison, and K. G. Ramakrishnan, “VPN DESIGNER: atool for design of multiservice virtual private networks,” Bell Labs Techni-cal Journal October-December 1998, pp. 15-31.

MPLS

Documents

Transcript of MPLS