Traffic Engineering using Multiple

Multipoint-to-Point LSPs
Hiroyuki Saito, Yasuhiro Miyao, and Makiko Yoshida
C&C Media Research Laboratories, NEC Corporation
4-1-1 Miyazaki, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, Japan
hiroyuki@ccm.cl.nec.co.jp
AbstractTraffic engineering aims to optimize the utilization of existing
network resources for load balance and failure recovery, and these are to
be accomplished in a scalable fashion. This paper proposes a traffic engineering scheme using multiple multipoint-to-point (m-t-p) Label Switched
Paths (LSPs) which can reduce the number of LSPs and required labels
in 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. The
m-t-p LSP design problem is formulated as a 01 integer programming
problem. The flow assignment problem is formulated as a mixed integer
programming problem in which maximum link load, i.e., maximum congestion, is minimized. Numerical comparisons with the conventional pointto-point LSP approach show that the m-t-p LSP approach can reduce the
number of required LSPs and labels. Moreover, numerical comparisons
with conventional Shortest Path Fast based flow assignment show that our
flow assignment scheme can reduce maximum link load.
KeywordsTraffic engineering, MPLS, multipoint-to-point LSP, flow assignment

Multipoint-to-point LSP
5

1
Egress node

6
3

MPLS domain

Ingress node

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

I. I NTRODUCTION
Traffic engineering has become an essential requirement for
Internet Service Providers (ISPs) to optimize the utilization of
existing network resources and it enables to maintain a desired
overall 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, which
will have low QoS, and underutilized links, which represent a
waste, to be reduced.
Load balancing requires an ability to control traffic flow precisely. In the traditional metric-based control, an administrator
can change only link metrics, and changes of some link metrics may affect the overall traffic flow. To control traffic flow as
the administrator wants, it is necessary to adjust the link metrics
over a network; however, sometimes this adjustment is impossible. Therefore, explicit route based control, in which the administrator can control traffic as he wants, appears to be a far more
promising choice.
In traffic engineering using the explicit routes there are two
requirements. First, for effective load balancing across a network, each ingress node should have a diversity of explicit
routes to each egress node. Without that, effective load balancing would be impossible. Second, for reliability, among the
diverse routes between any given pair of ingress/egress nodes,
there should be at least one which is not affected in each individual failure case.
One way to provide an explicit routing capability is to use
MPLS (Multiprotocol Label Switching)[1][2]. MPLS provides label swapping based forwarding, and by using it, Label Switched Paths (LSPs) are established between ingress and
egress nodes. The routes of the LSPs can be specified explicitly.

In addition, with the establishment of backup LSPs, a network

will be able to cope with failures in nodes and links.
One way to establish routes in a MPLS network is to use
point-to-point (p-t-p) LSPs. Here, a route between an ingress
node and an egress node is represented by a single p-t-p LSP.
Conventional MPLS traffic engineering frameworks [3] [4] and
mechanisms [5] [6] have been assumed to use p-t-p LSPs. To
connect all edge node pairs by using p-t-p LSPs, the total
number of LSPs necessary to cover the entire network will be
O(N 2 ), where N is the number of edge nodes. For a large network, then, the p-t-p LSP approach can easily become impractically cumbersome.
Multipoint-to-point (m-t-p) LSPs (see Fig. 1) have been proposed [2] to avoid this problem. Here, one LSP represents routes
from multiple ingress nodes to a single egress node. In terms
of graph theory, the shape of the m-t-p LSP is an inverted tree
rooted at an egress node. At connection points in the tree, labels
assigned to different incoming links are merged into one label
assigned to an outgoing link. To provide connections between
all edge node pairs by using m-t-p LSPs, since only one LSP per
individual egress node is sufficient, the total number of LSPs
required is O(N ).
Traffic engineering schemes based on m-t-p LSPs, however,
have yet to be proposed. The reason is the difficulty of creating them. As mentioned before, each ingress/egress node pair
should have diverse routes, including at least one route that is
not affected in each individual failure case. Since individual pt-p LSPs correspond to individual routes, it is easy to represent
such routes with the p-t-p LSPs. A single m-t-p LSP, on the
other hand, represents routes from multiple ingress nodes to an

egress node, and it is not clear which routes should be included

in each m-t-p LSP. We have, however, been able to develop a
mathematical scheme, represented here, creating a set of m-tp LSPs which satisfies the requirement that each ingress/egress
node pair should have a diversity of routes including at least one
route that is not affected in each individual failure case, and that
keeps the number of m-t-p LSP as small as possible. Route selection and m-t-p LSP design are performed separately, and the
m-t-p design problem is formulated as a 0 1 integer programming problem.
Even with successful m-t-p creation, however, the problem
of flow assignment remains. Villamizar[6] has proposed a local
optimization scheme. This scheme only determines routes for
a single traffic demand at any one time, and for this reason, it
cannot optimally utilize network resources. A global optimization scheme, on the other hand, determines routes of all traffic
flow simultaneously; therefore, it can provide the optimal solution. Concept of global optimization has been discussed [5]
[7], but no detailed scheme has been proposed before. Therefore, this paper proposes a global optimization scheme for flow
assignment. In our scheme, the flow assignment problem is formulated as a mixed integer programming problem, where flow
assignment of all given traffic demands is simultaneously determined while minimizing maximum link load. By minimizing
maximum link load, the loads of overutilized links decreases, as
a result, the loads across a network will be balanced. Moreover,
the scheme can provide flow assignment for failure recovery, in
which maximum link load is minimized over all failure states.
The remainder of this paper is organized as follows. We describe the framework of m-t-p LSP traffic engineering in Section
II. We propose the m-t-p design scheme in Section III, and the
flow assignment scheme in Section IV. We give numerical examples of the use of both in Section V.
II. T RAFFIC E NGINEERING USING MULTIPOINT- TO - POINT
LSP S
A. Assumptions
A.1 Traffic Demand
In this paper, the term traffic demand refers to all the traffic
between an ingress node and an egress node, or only to a part
of the overall traffic. Additionally, it is used to refer, for example, to all traffic of the same Forwarding Equivalence Class
(FEC) [1], or to some portion of it. Hereafter, we assume that
both traffic control and failure recovery are performed for each
individual traffic demand. This assumption is not mandatory,
and our proposal can be applied to dividing traffic demands into
separate sections.
A.2 Pre-assigned m-t-p LSPs
Multipoint-to-point LSPs are pre-assigned before traffic demands are known, and flow assignment is determined after they
are known. M-t-p LSPs are created simply on the basis of the
network topology alone; link bandwidth is not a consideration.
M-t-p LSPs cannot, however, provide exclusive services specified between ingress/egress node pairs; that has to be done by
p-t-p LSPs.

lsp 1
5

1
6
lsp 2

lsp 3
4

Egress node
lsp 4
Ingress node

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

Traffic demand <9,4>
is assigned to lsp 3.

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

1
Traffic demand <9,1>
is assigned to lsp 2.

6
3

7
9

Egress node
Ingress node

Traffic demand <8,4>

is assigned to lsp 4.

(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 to
the egress node. Therefore, except for creating m-t-p LSPs, load
balancing 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 1
from ingress nodes 8 and 9 , and two m-t-p LSPs (lsp 3 and
lsp 4) for egress node 4 from ingress nodes 8 and 9 (Fig. 2
(a)). The same volume of traffic demand is assumed for each
ingress/egress node pair. To avoid concentrating traffic along
any one link, traffic demand <8,1>, i.e. traffic demand from 8
to 1 is assigned to lsp 1, and traffic demand <8,4> is assigned to
lsp 4 (Fig. 2 (b)). Similarly, traffic demand <9,1> and <9,4>
are assigned to lsp 2 and lsp 3 respectively (Fig. 2 (b)). As
a result, no single link is assigned traffic from more than one
traffic 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, and
when a failure occurs, traffic on a damaged working route is
rerouted to its backup route. Here, working and backup routes





The extended FTN

FEC
element
xxx.yyy.zzz

working
Next Label
Hop
5

12

backup
Next
Hop Label
6



 
 


 




 




15

Working route
lsp 1
5








 


1
6


 

lsp 2

3
Spare route
7

Fig. 4. Operation and Design Flow

Egress node
Ingress node

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

are assigned not to be affected in each individual failure case

simultaneously. We suppose single node failures in this paper,
and, for this case, each working route and its backup route must
be created not to share a single node in between. The rerouting procedure is completed at the ingress node, so no signaling
procedures are required. This speeds the rerouting process.
In our proposed architecture, there are no m-t-p LSPs limited
to being exclusively a working route or a backup route. One
LSP can be a working route for one traffic demand and also a
backup route for another traffic demand.
Each ingress node has a map that determines the switching of
working routes to backup routes. This map is an extension of
an FTN (FEC to Next Hop Label Forwarding Entry (NHLFE)
Map) and includes information for backup routes as well as for
the working routes.
The example in Fig. 3 includes working and backup routes,
and illustrates an extended FTN. There are two m-t-p LSPs (lsp
1 and lsp 2) for egress node 1. For traffic demand <8,1>, lsp 1
is the working route and lsp 2 is the backup route. The extended
FTN is assigned to ingress node 8.
In order for rerouting from a working route to a backup route
to be carried out, an ingress node needs to receive an alarm signal indicating a route failure. In transport networks, Alarm Indication Signals (AISs) are used, but currently there are no such
signals in MPLS networks. One possibility is to use a Label Release message [10], which is sent upstream when there is no next
hop. Label Release messages could be used as alarm signals
if they had an option not to release labels. Alternatively, Interior Gateway Protocol (IGP) Link State Advertisements (LSAs)
[11] could be used. LSAs contain information concerning a local piece of topology. They are broadcasted upon detection of a
failure of a link or a node, and an ingress node which received
LSAs would learn from the received LSAs whether or not a failure had occurred affecting the traffic originating from the ingress
node, and thus, whether or not it was necessary to switch traffic
from its working route to its backup route.

C. Design and operation

M-t-p LSP creation and flow assignment are performed separately (see Fig. 4).
In m-t-p LSP creation, routes are selected first, and then mt-p LSPs are designed to include the selected routes for each
ingress/egress node pair while minimizing the number of m-t-p
LSPs.
Flow assignment determines which LSPs are used for given
traffic demands. Reconfiguration of flow assignment of existing
traffic 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) the
server-oriented system and (b) the edge-oriented system .
In the server-oriented system, centralized control such as a
configuration server sets m-t-p LSPs and flow assignment. For
the m-t-p LSP setup, the configuration server designs m-t-p
LSPs and sets the designed m-t-p LSPs to each routers by using an administrative procedure. For the flow assignment, the
configuration server determines flow assignment and sets FTN.
The configuration server collects the traffic flow statistics measured by each ingress node. This statistics is used when flow
assignment is reconfigured.
In the edge-oriented system, edge nodes design m-t-p LSPs
and determines flow assignment.
The m-t-p LSP setup is done by each egress node. Each egress
node designs all m-t-p LSPs based on topology information obtained by LSAs. Then, each egress nodes set own m-t-p LSPs
by using signaling procedure such as Label Distribution Protocol (LDP) [10][12].The LDP for m-t-p LSPs is in further study
in IETF MPLS Working Group. Here, we assumed that Label Mapping Messages for explicit m-t-p LSPs are initiated by
egress nodes, and then transmitted to ingress nodes.
The flow assignment is performed by each ingress node. The
traffic flow statistics is measured by ingress nodes, and they are
sent to other ingress nodes by using a distributed procedure.
There is no standard procedure to distribute such traffic flow
information, but the OSPF opaque LSA can be used for this purpose [13]. Ingress nodes determines flow assignment based on
given traffic demands and/or measured traffic demands, and set
FTN.

Configuration Server
m-t-p LSP
design

h(t81 ,5 )
flow assignment

LSP setup

flow assignment

h(t51 , 2 )

2
t1
h(t21 ,5)
t1 h( 5,8 )
t
h(8,6 ) t1 t1 h 1
h( 6 ,5) h( 5, 6 ) ( 6 , 2 )
t1
t
h(t21 , 6) h( 2 ,3) h(31 , 2 )
t1
t1
h( 6,8)
h
6

h(t91 , 6 )

MPLS domain

Edge node
Traffic flow
measurement

( 6 , 3)
t1
t1
( 3, 6 )
t1
( 6,7 )
t1
t1
(7 ,6)
( 7 , 3)
( 6,9) t
1
( 9, 7 )

h
h

h
h

h(t71 ,9 )

h(t21 ,1)

h(t31 ,1)

1
Egress node

t1
( 3, 4 )

h
h(t31 , 7 ) t h t1
1
h( 4 , 7 ) ( 4 ,3)
4
t1
h( 7 , 4 )

Ingress node

Variable h(tl1, m )

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

(a) Server-oriented
Edge node
as egress node
as ingress node
m-t-p LSP
flow assignment
design
Traffic flow
measurement

MPLS domain

LDP

(b) Edge-oriented
Fig. 5. System architectures

III. M ULTIPOINT- TO -P OINT LSP DESIGN

A. Route Selection Step
Optimal load balance in flow assignment might be achieved
by employing all possible routes, but this would require excessive calculation time. Considering the fact that long routes tend
to make relatively little contribution[14], we have established
the 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 of
each route p(i,e) is no greater than that of the route
having the smallest hop count plus which can be the
given number and such that each route p(i,e) have at
least one route which do not share a single node in
Pi,e . If no set can be chosen that meets both of these
criteria, choose, a route pair that does not share a
single node in between and have the smallest and the
second smallest hop count routes.
Route selection is conducted by means of the Dijkstra algorithm
and the depth first search algorithm.

B. Multipoint-to-Point LSP Design Step

The m-t-p LSPs design determines m-t-p LSPs which includes all the selected routes while minimizing the number of
m-t-p LSPs required. The m-t-p LSP design problem is formulated as a 01 integer programming problem for each individual
egress 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-p
LSP candidates and route accommodation indicators.
The m-t-p LSP candidate is represented by a set of variables
e
ht(l,m)
, which takes a value 1 if m-t-p LSP candidate te uses
link (l, m), otherwise takes a value 0. A set of m-t-p LSP
candidates is given per egress node, and it is used to formulate
the first and second conditions. By solving the problem, all or a
part of the m-t-p LSP candidates will become m-t-p LSPs which
include 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 variables
for outgoing links (1, 2) and (1, 3) from egress node 1 are eliminated.
By using the m-t-p LSP candidates, the first and second conditions are expressed as follows.
e
1. In each node, summation of the values of ht(l,m)
in outgoing links is 1.
e
along
2. For each route, summation of the values of ht(l,m)
the route is equal to summation of hop counts of the route.
The route accommodation indicator indicates whether each
selected route is included in a set of LSPs or not, and it is expressed as 0 1 variable pte(i,e) . Then, the third condition is
expressed as follows.
3. Summation of the values of pte(i,e) over m-p-t LSP candidates 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.
NeIngress : 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 NeIngress }
P(i,e) : The set of selected routes between ingress node i
and egress node e.
p
L (i,e) : A set of links used in route p(i,e) .
Variables:
t
r e : Set to 1 if m-t-p LSP candidate te includes a part of
selected routes, otherwise set to 0.
te
h(l,e) : Set to 1 if m-t-p LSP candidate te uses link (l, m),
otherwise set to 0.
t
pe
: Set to 1 if m-t-p LSP candidate te includes route
(i,e)
p(i,e) , otherwise set to 0.
The m-t-p LSP design problem is formulated as follows.


Min
r te
(1)

te Te

subject to

{m:(l,m)Le }

e
ht(l,m)
1

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


te
p(i,e) te
h(l,m) |L
|p(i,e)
p(i,e)
Le }

(l,m){L

(p(i,e) P(i,e) , i NeIngress , te Te )(3)

pte(i,e) = 1

te Te

(p(i,e) P(i,e) , i NeIngress )

pte(i,e)

(4)

iNeIngress p(i,e) P(i,e)

|P(i,e)|r te (te Te )

(5)

iNeIngress
e
ht(l,m)
, pte(i,e) , r te = 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 number
of m-t-p LSP candidates. The constraint (2) gives the first condition. The constraint (3) gives the second condition. The constraint (4) gives the third condition. The constraint (5) judges
whether each m-t-p LSP candidate te is used to include at least
one route. If one or more than one pte(i,e) are set to 1, which
means te includes one or more than one routes, r te is set to
1. The coefficient
number of

 |P(i, e)| istesame as the maximum
te
Ingress

,
and
it
keeps
r
equal
to or
p(i,e) P(i,e) p(i,e)
iNe
less than 1.
IV. F LOW A SSIGNMENT
The flow assignment scheme is based on our previous work
[15]. In this work, working routes, backup routes and link capacities are determined while accommodating the given traffic
demands with minimum cost. On the other hand, in this paper,

working routes and backup routes of given traffic demands are

determined while minimizing maximum link load.
Here, we introduce states, each of which represents a set of
node and link status, i.e. normal or failure. A set of states is
input for the flow assignment, and maximum link load will be
determined over the given states.
The scheme requires working route candidates for each traffic
demand and backup route candidates for each working route,
where each backup route candidate does not share the same node
with its working route. These candidates are created from route
set P(i,e) . First, each route in P(i,e) is set to be a working route
candidate. Then, each route which does not share a single node
with its working route is set to be a backup route candidate.
Notations, except those explained in the previous section, are
summarized as follows.
Sets:
D: A set of traffic demands.
S: A set of states.
s
L : 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 working
route id .
Variables:
fid : Set to 1 if id is used otherwise set to 0.
fji : Set to 1 if jid is used otherwise set to 0.
d
max

: Maximum link load.
Constants:
vd : Required capacity of traffic demand d
s
i : Set to 1 if the working route id survives at state s
d
otherwise set to 0.
(l,m)
gi
: Set to 1 if the route id uses link (l, m) otherwise
d
set to 0.
b(l,m) : A link capacity of link (l, m).
The flow assignment problem is formulated as follows.
Min
subject to

max


fid = 1 (d D)

(7)
(8)

id Id

fjid = fid

(id Id , d D) (9)

jid Jid

(l,m) s
id vd fid

{gid

dD id Id

jid Jid

(l,m)

(1 isd )jsi gjd

d

vd fjid }

max b(l,m)
((l, m) {L Ls }, s S)
fid , fjid = 0/1

(10)
(11)

The objective function (7) indicates minimizing maximum

link load. The constraint (8) means that one of working routes
must be used per traffic demand. The constraint (9) means that
if working route id is used, one of backup routes of the working
route must be used. The constraint (10) gives maximum link
load. The first term means link capacities required by working
routes, and the second means link capacities required by backup

e5

e4

e3
n3

700

n4

600
Number of the overall LSPs

n2
e6
e2

n6
e7





n1
n7
n8
e1

n2

e2

e1
e6

e8
n3

500
400
300
200

n1




100

n6

e3
e4

e7

0
p-t-p

n7
n5

n4

m-t-p

p-t-p

m-t-p
(22,45)

(16,26)

e8
n8

Fig. 8. Number of LSPs

e5

e11

n9
e9

n11

80

e10

70

n10

routes. The link capacities along backup routes are required only
when their working routes are damaged.
In this formulation, the overall traffic of given traffic demand
d is assumed to be assigned to a single route. Changing variables
fid and fjid from 0 1 variables to real variables, enables to use
multiple routes.
V. N UMERICAL E XAMPLES
A. Basic Results
We evaluated reduction in the number of LSPs and labels by
applying multipoint-to-point LSPs, and load balancing effect on
m-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) (see
Fig. 7(b)) have been exploited. These network are modified
from those in [16] and [15] as follows. All nodes in the individual original networks are assumed to be transit nodes, and the
same number of edge nodes are added to the individual original networks. Each edge node is connected to two transit nodes.
The reason of this modification is to avoid the situation that traffic demands lose when ingress or egress nodes of the traffic demands fail. In (16,26), four traffic demands per each edge pair
are given [16]. In (22,45), four traffic demands with the same
bandwidth for each edge node pair are given. The additional hop
count in the route selection step is set to 1. Only links between
transit nodes are exploited for calculation of the maximum link
load.
First, the number of LSPs and labels are evaluated (Fig. 8
and Fig. 9). The number of m-t-p LSPs is 16% of that of p-t-p
LSPs in the case of (16,26) and 27% in the case of (22,45). This
result clearly shows that the m-t-p LSP approach can remarkably reduce the number of LSPs, which should be managed in a
network.

Number of Labels

60

Fig. 7. Network Model

maximum

50
40
30

average

20
maximum

10

average
0

p-t-p

m-t-p
(16,26)

p-t-p

m-t-p
(22,45)

Fig. 9. Number of Labels

On the other hand, the maximum number of labels required

for 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 shows
that the m-t-p LSP approach can reduce the number of link labels, which needs to be managed for each link. The reduction
is smaller compared with the previous evaluation. The reason is
that each m-t-p LSP consists of more links than those of each
p-t-p LSP.
From these results, the m-t-p LSP approach could establish a
given 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. The
shortest path fast (SPF) based flow assignment, which is used
for the conventional IGP such as OSPF, is performed for comparison. Each link cost is assumed to be reciprocal of each link
capacity. In the failure case, a minimum cost route for each traffic demand is searched in the topology in which a failure node
is removed. The result is shown in Fig. 10.
In the normal case, the maximum link load obtained by the
proposed scheme is 70% of that obtained by the SPF based flow
assignment in the case of (16,26) and 38% in the case of (22,45).

1
Number of routes

Normal case
Failure case

0.4

0.2

Maximum link load

in the failure case

0.6

0.4
50
0.2

0
Proposed

SPF

SPF

Proposed

Maximum link load

in the normal case
1

(22,45)

(16,26)

Fig. 10. Load balancing result

2
Additional hop count

TABLE I
P ROCESSING T IME FOR FLOW ASSIGNMENT

Network

# of demands

(16,26)
(22,45)

224
440

CPU time (sec)

the normal the failure
case
case
0.7
2.8
18.7
55.1

B. Impact of the Number of Routes

To evaluate impact of the number of routes on the maximum
link load, we varied the additional hop counts to the minimum
hop count. The results are shown in Fig. 11 and Fig. 12.
There is little difference in the maximum link loads in
changes of the additional hop count, though the number of
routes increases, especially in the case of (22,45). This indicates
that traffic flow is not assigned to the routes added by increasing the additional hop count. This result shows the long routes
do not affect the value of maximum link load and the additional
hop count of 1 is enough in our route selection scheme in these
examples.

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

1

4000
3500

0.8
Maximum link load

In the failure case, it is 97% in the case of (16,26) and 69% in

the case of (22,45). This result shows that the proposed scheme
can reduce the maximum link load in any case. However, the
reduced rate depends on the topology. For example, in (16,22),
choice of routes is limited because damaged node is removed
from the original topology, so the reduced rate is small. The
proposed flow assignment is shown to be effective for load balancing, especially in well-connected networks.
Processing time for flow assignment calculation may be a
problem in global optimization [5]. Therefore, we evaluate the
processing time (Table I). The flow assignment calculation was
performed by using the model description language AMPL and
the linear programming problem solver CPLEX version 6.5 on
DEC Ultimate Server Model 533au2. Requirement to the processing time is dependent on a time cycle of operations. These
value are small enough for hourly or daily operation.

100

Maximum link load

in the failure case

3000
2500

0.6

2000
Number of routes

0.4

1500
Maximum link load
in the normal case

0.2

Number of routes

0.6

Number of routes

0.8
Maximum link load

Maximum link load

0.8

150

1000
500

2
Additional hop count

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

VI. S UMMARY
This paper proposed a traffic engineering scheme using multiple multipoint-to-point LSPs. Difficulty in traffic engineering
using multiple m-t-p LSPs is to create m-t-p LSPs. A set of
m-t-p LSPs needs to satisfy the requirements that they provide
a diversity of routes including at least two routes which does
not share any single node to each individual ingress/egress node
pair for effective load balance and reliability. We achieved the
above m-t-p LSP creation by separating route selection and m-tp LSP design procedures, and formulating the m-t-p LSP design
problem as a 0 1 integer programming problem.
We also proposed a flow assignment scheme. Here, flow assignment of all given traffic demands are determined while minimizing maximum link load. The proposed scheme can deal with
failure recovery.
Numerical examples showed that m-t-p LSPs could reduce
the number of overall LSPs and the number of labels in each
link in comparison with the p-t-p LSPs as well. In addition,
the proposed flow assignment scheme could reduce maximum
link load in comparison with the Shortest Path Fast based flow
assignment, and achieved effective load balance across each example network.

R EFERENCES
[1]

[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]

R. Callon, P. Doolan, N. Feldan, A. Fredette, G. Swallow, and A.

Viswanathan, A framework for multiprotocol label switching, Internet
Draft (Work in Progress), draft-ietf-mpls-framework-05.txt, September
1999.
E. C. Rosen, A. Viswanathan, and R. Callon, Multiprotocol Label Switching Architecture, Internet Draft (Work in Progress) , draft-ietf-mpls-arch06.txt, August, 1999.
D. O. Awduche, etc, Requirements for traffic engineering over MPLS,
RFC 2702, September, 1999.
G. Swallow, Traffic engineering & MPLS, IW-MPLS 98,
http://info.uu.net/ads/techconf, November 1998.
F. Fahim, Constraints Based Routing Algorithms and Applications IWMPLS 98, http://info.uu.net/ads/techconf, November 1998.
C. Villamizar, OSPF Optimized Multipath (OSPF-OMP), Internet Draft
(Work in Progress), draft-ietf-ospf-omp-02, February 1999.
M. D. ODell, Some pretty good challenges building very large networks, IW-MPLS 98, http://info.uu.net/ads/techconf, November 1998.
M. M. Slominski and H. Okazaki, Guided restoration algorithm for ATM
cross-connect networks, Proc. ICC 94, pp. 466-470, March 1994
R. Kawamura, K. Sato, and I. Tokizawa, Self-healing ATM network techniques utilizing virtual paths, Proc. NETWORKS 92, May 1992.
L. Anderson, P. Doolan, N. Feldman, A. Fredette, and B. Thomas,LDP
Specification, Internet Draft (Work in Progress), draft-ietf-mpls-ldp06.txt, October,1999.
J. Moy, OSPF Version 2, Internet RFC 2178, April 1998.
B. Jamoussi, Constraint-Based LSP Setup using LDP, Internet Draft
(Work in Progress), draft-ietf-pls-cr-ldp-03.txt, September 1999.
R. Coltun, The OSPF Opaque LSA Option, RFC2370, July 1998.
M. Herzberg, S. J. Bye, and A. Utano, The hop-limit approach for sparecapacity assignment in survivable networks, IEEE/ACM Transaction Networking, vol. 3 no. 6, pp. 775-784, December 1995.
H. Saito, Y. Miyao, T. Komine, and F. Kubota, Joint capacity assignment
to state-independent working and spare paths for enhanced network survivability, Proc. ICC98, June 1998.
D. Mitra, J. A. Morrison, and K. G. Ramakrishnan, VPN DESIGNER: a
tool for design of multiservice virtual private networks, Bell Labs Technical Journal October-December 1998, pp. 15-31.