August 14, 2000
Algorithms for Flow Allocation for Multi Protocol Label Switching
Teunis Ott, Tony Bogovic, Tami Carpenter, K. R. Krishnan, and David Shallcross
Telcordia Technologies, Inc.
445 South Street, Morristown, NJ 07960
1. Introduction
Multi Protocol Label Switching (MPLS) [1] is a flexible routing mechanism for traffic flows that
is based on the assignment of flows to complete end-to-end paths within an Autonomous Domain.
The flexibility comes from the freedom to choose the criterion by which traffic flows will be
recognized and treated as distinctive flows. In particular, such freedom allows for the traffic of a
given source-destination pair to be divided between parallel routes in order to avoid congesting
links in the network. Such “traffic engineering” in the Internet is one of the primary applications
envisioned for MPLS [1,2]. The goal of traffic engineering is to optimize the utilization of
network resources, and thus, the performance of operational networks, by moving traffic
efficiently and reliably through the network and mitigating network congestion. This capability is
difficult to achieve in the current Internet because virtually all of IP routing is destination-based;
i.e., the information used to decide where to forward a packet is based solely on the destination
address field contained within the IP packet itself. Thus, each router examines the destination
address of each packet and decides, on a hop-by-hop (or per-router) basis, where the packet is
sent next. Moreover, the distributed algorithms found in IGPs (Interior Gateway Protocols), such
as RIP (Routing Information Protocol) and OSPF (Open Shortest Path First), use primarily static
metrics, such as hop count or administrative weight, for calculating which paths to send the traffic
on. This has the effect of over-burdening certain paths in the network, while under-utilizing other
paths.
One could, however, consider other fields in the IP header besides the destination address (e.g.,
type of service, source address), and use other metrics [3,4] and approaches [5] in determining the
paths on which traffic should be sent. In fact, in MPLS, any field in an IP header can be used
individually or in combination to decide how a packet is forwarded. Consequently, MPLS is not
subject to the traditional, strictly destination-based IP paradigm. In addition, MPLS supports
explicit routing, which is a key feature for providing traffic engineering capability. Explicit routes
are routes that are fully-specified from end to end, and which might differ from the routes chosen
by network layer routing protocols. The MPLS mechanism is equally suitable for assigning flows
to paths according to Quality-of-Service requirements, and is thus a potential means of offering
differentiated service levels [6,7].
A feasible solution to the MPLS problem, for a given network with a given set of traffic demands,
will consist of a set of paths for all the traffic flows (Label Switched Paths) and the allocation of
flows to these paths, such that no capacity constraints are violated. When a feasible solution
exists, one can consider ‘optimizing’ such a solution for various notions of optimality. Thus, the
mathematical formalism for the MPLS problem is that of multi-commodity flow allocation in a
network.
In this paper, we consider both Linear Programming (LP) and Non-Linear Programming (NLP)
approaches to the MPLS flow allocation problem. In particular, we propose four LP formulations,
including two cases in which certain aggregations of the point-to-point traffic demands are shown
to result in a drastic reduction in the size of the problem to be solved. The NLP formulation leads
1
August 14, 2000
to a problem that can be solved either by means of centralized or distributed computation.
Exploiting the fact that the NLP lends itself to distributed computation, we then propose a method
of making use of both the LP and the NLP algorithms to solve the problem, taking advantage of
their respective strengths. In this combined method, we rely on LP computations to select a
suitable set of paths for traffic flows, and then use the NLP to determine the actual flow
allocations to these paths. In practice, this approach would separate the computations into two
levels, at two different time-scales: infrequent execution of time-consuming off-line calculations
for path selection combined with continual rapid adjustments to flow allocations. We present the
results obtained with our methods for several networks that have been studied in the literature in
connection with Curtis Villamizar's method of Optimum Multi Paths (OMP) [5].
The NLP algorithm used in this paper is a version of the algorithm described by Gallager [8] for
routing in data networks. Gallager showed that the algorithm was capable of either centralized or
distributed implementation. The MPLS traffic engineering scheme known as MATE [9]
essentially uses the distributed version of Gallager’s scheme, based on the exchange, between
neighboring nodes, of information derived from traffic measurements. Thus, the distributed
implementation of the NLP algorithm proposed in this paper is equivalent to the algorithm in
MATE. However, our work goes beyond MATE in an important respect. MATE begins with the
assumption that the LSPs to be considered have been already specified. It does not deal with the
selection of LSPs, but only with the allocation of flows to them. We, however, have proposed in
this paper an interesting method of combining the strengths of the LP and the NLP algorithms,
using an LP to determine a set of LSPs over which the NLP (centralized or distributed)
determines the flow allocations. Thus, while MATE offers only the allocation part of the solution
to the MPLS problem, we present here a complete solution.
In Section 2, we formulate the MPLS problem as a multi-commodity flow allocation problem,
and explore various criteria of optimization that might be reasonable candidates for consideration.
The various LP formulations are presented in Section 3, and the NLP formulation is discussed in
Section 4. The method of combined use of the LP and the NLP algorithms is presented in Section
5. Numerical results obtained with our methods are compared with previous results in Section 6,
and the conclusions are summarized in Section 7.
2. Formulation of the MPLS Flow Allocation Problem
This section gives a formal definition of the flow-allocation problem for MPLS, and describes
several notions of ‘optimality’ that might be applicable to the solution.
2.1.
Notation and Problem Statement
We have a network consisting of N nodes (say routers). A pair of routers (m, n) might be
connected, in the direction m  n , by a directed link (m, n) with bandwidth equal to b(m,n) (say,
in bytes/sec). If the link does not exist, we take b(m,n)  0 . There is no need to assume symmetry
(i.e., to assume b(m,n)  b(n,m) ). The number of links is the number of pairs (m, n) with b(m,n)  0 ,
and is denoted by L . We assume that the network has the property that every node n can be
reached from every other node m by following the direction of the links. This implies that
N  L  N ( N  1)
In this note we make the simplifying assumption that a pair (m, n) has at most one link. In more
complicated situations it is possible to have more than one link from node m to node n .This
complicates the notation but not the concepts.
2
August 14, 2000
The traffic demands are given by the matrix [d (i, j ) ] , where d (i , j ) is the amount of traffic (in bytes
per second) that enters the network at node i and exits the network at node j . We assume here
that the capacities [b( m,n) ] and demands [d (i, j ) ] are constant in time (alternatively, we can think of
the demand matrix as specifying the average traffic rate), although the algorithms presented here
could be extended to deal with the practical situation in which the routing must adapt to
fluctuations of the traffic.
The assumption that a link (m, n) has a well-defined bandwidth b(m,n) means that we essentially
assume that all links are point-to-point connections (no shared media such as Ethernet), or, at
least that the bottlenecks are always in point-to-point connections. This seems a plausible
assumption.
Any assignment of the demands d (i , j ) to paths in the network leads to link-loads X ( m,n) , where
X ( m,n) is the load (say, in bytes per second) on link (m, n) . To begin with, we assume that all
flows are “fluid flows” and that no losses occur. Let x(i, j ),(m,n)  0 denote the flow of the traffic of
node-pair (i, j ) on link (m, n) ; since traffic that reaches its destination does not re-enter the
network, we have x(i, j ),( j ,n)  0 . The flows, of course, are determined by the paths selected for the
traffic and by the allocation of traffic to the paths, i.e., by the traffic routing.
We then have
X ( m,n)   x (i, j ),( m,n)
(2.1)
(i , j )
On each link, we have the feasibility-constraint
0  X (m,n)  b(m,n)
(2.2)
In addition, we express the requirement that the traffic d (i , j ) should be carried in the network
from node i to node j , as follows:
 i , n d (i , j )   x (i , j ),( k ,n )   n, j d (i , j )   x (i , j ),( n,k ) at each node n
k
2.2.
(2.3)
k
Optimization Criteria
The general objective, of course, is more or less to minimize all the linkloads X ( m,n) . Thus, we
begin with the weakest optimality criterion:
Definition: A routing scheme is non-dominated if it results in link loads X (*m , n ) with the property
that there does not exist another routing scheme with link loads X ( m,n) with
X ( m, n )  X (*m, n ) for all (m, n), and X ( m, n )  X (*m, n ) for at least one (m, n)
3
(2.4)
August 14, 2000
2.2.1. A Linear Criterion in Link Flows
A non-dominated solution will be obtained if we seek to minimize a criterion of the form
 w(m,n) X (m,n)
(2.5),
( m, n)
subject to the constraints (2.1-2.3), where w(m,n)  0 are weights chosen for the link flows.
For some purposes, it is more convenient to work with the slacks S ( m,n) defined by
S (m,n)  b(m,n)  X (m,n)
(2.6).
Then, we seek to maximize the criterion
 w(m,n) S (m,n)
(2.7)
( m, n )
In the special case where all the weights are equal, i.e., w(m,n)  w independent of (m, n) , we are,
in effect, minimizing the average hop-count of the traffic, subject to the feasibility constraints. In
another special case, if we make the weight w(m,n) equal to the propagation delay of link (m, n) ,
we are minimizing the sum of propagation delays, which was the intention of the original form of
OSPF (Open Shortest Path First) routing. In general, we can think of the weights w(m,n)  0 as the
)
OSPF costs of the links.
2.2.2. Taking Account of Traffic Fluctuations: A Maxmin Criterion
Since traffic is almost never deterministic, if the plan is to achieve a ‘nominal’ flow X ( m,n) on
link (m, n) , we can expect that the actual flow (bandwidth used) will fluctuate around X ( m,n) .
Therefore, a link with X (m,n)  b(m,n)  0 , is, in fact, highly congested and can suffer significant
losses, and a solution with such links is hardly “feasible”. Therefore, we slightly redefine
feasibility, and call a routing problem “feasible” if there exists a solution with S (m,n)  0 for all
0
(m, n) with b(m,n)  0 . It is clear that links (m, n) with “small” S ( m,n) are the more critical ones and
should be given greater weight. One way of formalizing this is to use the maxmin objective
function:
For coefficients C(m,n)  0 (either given or chosen in some manner),
Maximize z ,
subject to
S (m,n)  zC (m,n) for all (m, n) with b(m,n)  0
(2.8).
In other words, the objective is to maximize
 S ( m, n )
min 
( m, n ) C ( m, n )

4




(2.9),
August 14, 2000
where the minimum is taken over all (m, n) with b(m,n)  0 . For later reference, let Z denote the
maximal value of (2.9).
The exact choice of C(m,n) is of secondary importance. Villamizar [5] takes C(m,n)  b(m,n) and
thus maximizes the normalized link “slack” (or minimizes the maximum link utilization) in the
network. When there is a feasible solution to the routing problem, it could be argued that the
choice C ( m,n)  b( m,n) has the effect of minimizing the maximal probability of a link flow
exceeding its bandwidth.
While the maxmin criterion has the advantage of giving greater weight to links with small slacks,
it has the disadvantage that an optimum solution according to that criterion is not necessarily nondominated. The criterion only ‘cares’ about links that have the ‘bottleneck’ value of
S ( m, n )
C ( m, n )
, and
tries to shift load away from those links, treating the flow on other links as of no value. This
implies that it does not necessarily discourage using paths with high hop-count or large
propagation delays. The non-dominated property can be recovered by considering a combined
criterion as follows.
2.2.3. A Combined Parametric Criterion
We consider the following objective, parametrized by   0 :


Maximize Z   w( m,n) S ( m,n)  , or equivalently,


( m, n )

Minimize  Z 

w
( m, n )
( m, n )

X ( m, n ) 

(2.10),
subject to the same constraints as before. In particular, the constraint involving Z can be written
as
X (m,n)  C(m,n) Z  b(m,n) for each (m, n) such that b(m,n)  0 .
For any   0 , an optimum solution is non-dominated, and for sufficiently large  , an optimum
solution is also optimum for the following two-stage criterion:
Minimize  w(m,n) X (m,n) ,
( m, n)
subject to the previous constraints as well as to the additional constraint
S ( m, n )
C ( m, n )
Z
(2.11),
where Z is the maximum value attained by (2.9).
2.2.4. Separable Additive Convex Non-Linear Criterion
We can consider the use of a criterion that has a non-linear dependence on link flows in order to
keep the slacks S ( m,n) on links bounded away from zero. Let D(m,n) ( x) be a decreasing convex
function of x , with the property that
5
August 14, 2000
lim D(m,n) ( x)  
(2.12).
x 0
For example, the function


D( m, n ) S ( m, n ) 
1
1

S ( m , n ) b( m , n )  X ( m , n )
(2.13),
which represents the expected delay in an M/M/1 system with an arrival rate of X ( m,n) and a
service rate of b(m,n) , has the required property.
We now consider minimizing an objective of the form
 w(m,n) D(m,n) S (m,n) 
(2.14),
( m, n )
which, at light loads, has the effect of minimizing a weighted hop-count, while, at heavy loads, is
essentially equivalent to maximizing the minimum slack. Thus, the criterion manages to reflect
the transition to different desired effects at different load regimes. Of course, the solution of the
routing problem with a non-linear objective function calls for the use of non-linear programming
algorithms.
3. Linear Program (LP) Solutions for MPLS Routing
In this section, we investigate linear programs for the MPLS routing problem, working with those
criteria in Section 2.2 that are amenable to solution by LP. We begin with the simplest and most
straightforward formulation in which the traffic d (i , j ) of each node-pair (i, j ) is treated as a
separate ‘commodity’, and then present other versions which work with aggregations of the
individual node-pair traffic demands, and thus lead to LPs with fewer variables. These different
formulations of the standard multicommodity network flow problem are discussed in the text by
Ahuja, Magnanti and Orlin [10] and the references contained therein.
3.1.
Pair-Based Flow Formulation
This is, in fact, the formulation already introduced in Section 2.1, which we re-state here for
convenience with the parametric criterion given in (2.10), making use of (2.1)


 Z   w( m, n )  x (i , j ),( m, n ) ,
( m, n )
(i , j )


subject to the constraints
Minimize
x (i , j ),( m, n )  0; Z  0
(3.1)
 x (i , j ),( m,n)  C ( m,n) Z  b( m,n) for each (m, n) with b( m,n)  0
(i , j )
 i , n d (i , j )   x (i , j ),( k , n )   n, j d (i , j )   x (i , j ),( n, k ) at each node n
k
k
6
August 14, 2000
The ‘pair-wise’ formulation of (3.1) has [ N ( N  1) L  1] variables (assuming that there is a traffic
demand for every node-pair), L inequality constraints, and N 2 ( N 1) equality constraints. Note
that for each pair (i,j), the equality constraints sum to zero, after bringing all terms to the same
side of the equation, so one constraint is redundant. Only N ( N  1) 2 of the equality constraints
are linearly independent.
3.2.
Egress-centric Flow Formulation
Instead of treating the traffic of each node-pair as a commodity, we now define the total traffic
exiting the network at each node (from all originating nodes) as a commodity. Thus, we define
D (jout)   d (i , j )
(3.2).
i
We also define x(m,n), j as the amount of flow carried on link (m, n) that is destined for node j .
Then, the conservation-of-flow constraints, analogous to (2.3), take the form
d ( n, j )   x ( k , n ), j   n, j D (jout)   x ( n,k ), j at each node n
k
k
and we have the LP for the egress-centric formulation:

Minimize  Z 
w( m, n )

( m, n )
subject to the constraints


j

x( m, n ), j ,

x( m, n ), j  0; Z  0
(3.3)
x
( m , n ), j
 C( m, n ) Z  b( m, n )
for each (m, n) with b( m, n )  0
j
d( n, j ) 
x
( k , n ), j
  n, j D (jout) 
x
k
( n , k ), j
k


for each destination j 
at each node n,
The egress-centric LP has ( NL  1) variables, N 2 equality constraints, and L inequality
constraints. Again, for each commodity, the equality constraints sum to zero, and we only have a
total of N ( N  1) linearly independent equality constraints.
3.3.
Ingress-centric Flow Formulation
This case is entirely analogous to the egress-centric case, with total traffic entering the network
at each node (for all destination nodes) now being defined as a commodity. Thus, we define
Di(in)   d (i , j )
(3.4).
j
We also define yi,(m,n) as the amount of flow carried on link (m, n) that originated at node i . The
conservation-of-flow constraints take the form
7
August 14, 2000
 (i , n) Di(in)   y i ,( k ,n )  d (i ,n )   y i ,( n,k ) at each node n
k
k
and we have the LP for the ingress-centric formulation:

 Z 
w( m , n )

( m,n )
subject to the constraints

Minimize
y

i ,( m, n ) ,

j
y i ,( m, n )  0; Z  0
y
i ,( m, n )
(3.5)
 C ( m , n ) Z  b( m , n )
for each (m, n) with b( m, n )  0
i
 (i , n ) Di(in) 
y
i ,( k , n )
 d (i , n ) 
k
y
i ,( n , k )
k
at each node n,


for each origin i 
Just as in the egress-centric case, the ingress-centric LP also has ( NL  1) variables, N 2 equality
constraints (of which N ( N  1) are linearly independent), and L inequality constraints.
3.4.
Path-Based Flow Formulation
When the commodities in a multicommodity flow problem are origin-destination pairs and the
cost associated with each link is non-negative, we can consider another formulation in which the
variables correspond to paths between node pairs. In this approach, we return to the pair-based
definition of commodity, but assume that an explicit set of admissible paths has been provided for
the traffic between each node-pair. If the admissible set of paths includes all of the possible paths,
then the solution to the resulting linear program will be optimal. In most cases, the linear
program that would result from considering all possible paths would be prohibitively large. Thus,
we now describe a well-known column generation procedure that iteratively solves a “master”
linear program using a small set of admissible paths and then solves shortest path sub-problems to
generate new paths, as they are needed. In this iterative manner, we arrive at an optimum set of
paths and the corresponding optimum assignment of flows to those paths. A description of the
basic column generation approach is provided in Ahuja, Magnanti, and Orlin [10].
Let P denote the set of paths that are currently included in the master problem; let P( i , j ) be the set
of paths from node i to node j; and let P ( m,n ) be the set of paths that use link (m,n). A path
p  P has cost
Kp 
w
( m,n )
( m , n ): pP ( m , n )
,
(3.6),
which is the sum of the cost of the links composing the path. Define variable B p to be the flow
(or bandwidth) allocated to path p  P . We can now state the master problem for the path-based
multicommodity flow problem as:
8
August 14, 2000


 Z   K p B p ,
pP


subject to the constraint s
Minimize
B p  0; Z  0
B
(3.7)
p
 C ( m ,n ) Z  b( m ,n )
p
 d (i , j )
for each link (m, n)
pP ( m , n )
B
pP( i , j )
for each node pair (i,j )
When (3.7) does not include all of the possible paths between pairs of nodes, we need to be able
to determine when the solution obtained by the simplex method is optimal. The column
generation method allows us to implicitly “price out” paths not included in the formulation, in
order to identify a path, if one exists, that reduces the value of the objective.
Solving a linear program by the simplex method provides not only the solution for the problem at
hand but also the solution for a related problem called its “dual”. The dual solution provides a
“certificate of optimality” for the associated primal solution. During the optimization, dual
variables allow us to determine the incremental effect of increasing path flows that are currently
at zero. For our purposes, the flow on any path not explicitly included in (3.7) is set to zero, and
thus, should be a candidate for raising from zero.
We now consider the dual of linear program (3.7). Let u ij be the dual variable associated with
the constraint for demand (i,j), and let v mn be the dual variable associated with the capacity
constraint for link (m,n). The dual linear program can be stated as:
d
Maximize
u
(i,j) ( i , j )
i,j
  b( m ,n ) v( m ,n ) ,
m,n
subject to the constraint s :
u ( i , j )  0; v( m ,n )  0
for each commodity (i,j ) and link (m,n)
(3.8)
C
v
( m,n ) ( m,n )

for each link (m, n)
( m,n )
ui, j 
v
( m,n )
( m , n ): pP ( m , n )
 Kp
for every (i,j ); p  P( i , j )
Given a primal solution and its associated dual, we wish to determine whether the current solution
is optimal for the full problem or whether we need to expand the set of paths and find a new
9
August 14, 2000
solution. We need to expand the set of paths whenever there is some path that is not included but
could reduce the objective value. To do this we can implicitly “price out” the paths that are not
included in the current set P. The “reduced cost” for any path that is currently at zero is given
by:
 (w
( m, n )
( m, n ): pP ( m , n )
 v( m , n ) )  u ( i , j ) .
(3.9)
If the reduced cost for some path is negative, then the objective value is reduced by sending flow
on this path and reducing flow on another. To identify whether the current solution is optimal,
we solve a shortest path problem for each commodity to find the path that satisfies:
min
pP( i , j )
 (w
( m,n )
( m , n ): pP ( m , n )
 v( m , n ) ) .
Any path for which this value is less than u ij has a negative reduced cost, so the objective can be
reduced by including this path. Otherwise, we have implicitly searched all paths not already
included in (3.7) and determined that none can help to improve the solution. When the latter
condition occurs, we can declare the current solution optimal. When the former condition occurs,
we add the paths whose reduced cost is negative to P and resolve the master problem.
The number of variables represented in (3.7) is P  1 , and the number of inequality constraints
is N ( N  1)  L. Assuming that Z is nonzero in any optimal solution, the simplex method for
linear programming [11] provides a solution in which at most N ( N  1)  L  1 of the path
variables have nonzero flow. All remaining path variables have zero flow, so they can be
removed from the formulation without affecting the current solution. This allows us to prune the
set of paths so that the master problem does not grow too large during the column generation
procedure. Possible advantages of the path-based method are: 1) that the LPs are smaller than
those for the link-flow formulations presented previously; and 2) that the solution provides path
flows directly. The main disadvantage is that the method is iterative and may require resolving
the master problem a large number of times.
3.5.
Determining Paths from LP Solutions
From each of the above LP formulations, we may determine a set of paths and an assignment of
demands to these paths. The path-based flow formulation gives this set of paths and assignment
of demands directly. For the pair-based flow formulation, and the two aggregated (rooted) flow
formulations, we determine the paths and assign demands by what is basically the same
algorithm. We will give details for the egress-centric flow formulation, with directions on how to
adapt this for the ingress-centric and the pair-based flow formulations.
For the egress-centric flow formulation, for each demand destination j, we have a flow using the
variables x(m,n),j for the various links (m,n), where the supply at each node i is d(i,j). We want to
decompose this flow into a sum of flows on paths terminating at j. Consider the restricted graph
)
of links (m,n) so that x(m,n),j is positive. If x is a non-dominated solution, for example, if it
G (out
j
)
is an optimal solution for an objective with coefficients w all positive, G (out
will have no
j
10
August 14, 2000
)
directed cycles. In this case, initialize G’ to be G (out
. Repeat the following steps until G’ has
j
no remaining links and x(m,n),j is zero everywhere. Find a node i with outgoing links but no
incoming links in G’. Find an ij path P in G’. Different path-finding methods may affect, for
example, how much the paths for a single destination vary in length, but it suffices to perform a
directed random walk in G’, starting at i. Let lP be the minimum of x(m,n),j over all links (m,n) in
P. Assign a flow of lP to P, and subtract lP from x(m,n),j for all (m,n) in P. At least one link has had
its flow reduced to zero for this demand pair, so remove all such links from G’. We preserve the
conditions that G’ has no directed cycles, that the sum of the net supply with respect to x(.,.),j plus
the flow assigned to paths from i equals the demand d(i,j), and that the only net sink is at j. Thus,
we can proceed until G’ has no links, and all of the demand is assigned to the identified paths.
Each path found corresponds to at least one positive component of x. As stated above, the LP has
N(N-1) + L linearly independent constraints, so if x and Z make a basic solution to the LP (as
produced by the simplex method), and Z is positive, x will have at most N(N-1) + L - 1 positive
components. Thus we have at most N(N-1) + L - 1 paths. This is the same bound as in the pathbased flow formulation.
)
If G (out
has directed cycles, we can sequentially find these cycles and reduce x on them until
j
there are no more such cycles, giving a new solution x’ to the LP, at least as good as x, with fewer
positive components. We then run the above algorithm on x’ to produce a set of path flows with
the same bound on the number of paths.
The ingress-centric flow formulation may be treated symmetrically with the egress-centric
)
)
formulation, with “terminating” replaced by “originating”, G (out
by G (in
, “ij” by “ji”,
j
j
“incoming” and “outgoing” reversed, and so forth.
For the pair-based flow formulation, for each demand d(i,j), we have an ij flow using the
variables x(i,j),(m,n) for the various links (m,n). We want to decompose this flow into a sum of
flows on ij paths. We can apply the same algorithm, as though the only source was i. Again, if
the LP solution is not non-dominated, it will correspond to a sum of flows on paths and flows on
directed cycles, and the flows on paths we find will correspond to an alternative LP solution that
dominates the original solution. Our upper bound on the number of paths is now N(N-1)2+L..
4. Non-Linear Programming Formulation and Solution
It was pointed out in Section 2.2.4 that the use of a decreasing convex function of link “slack” (or
an increasing convex function of link occupancy) to represent the ‘cost’ of a link captures the
effects that are important at different load regimes. The use of such a criterion turns the
optimization problem into a non-linear program (NLP), which we formulate in this section.
To solve the MPLS flow allocation problem, one needs to select a set of paths (LSPs) and to
determine the corresponding flow allocations. To begin with, we assume that the set of paths has
been selected, and concentrate on the problem of optimum flow-allocation. Of course, one could
begin with a very large set of potential paths, and allow the algorithm to determine which of those
should be used and which not. Alternatively, the flow allocations obtained for an initial choice of
paths can themselves be used to determine a better set of paths as was discussed in Section 3.4.
The NLP can be solved along the lines of a method proposed by Gallager [8]. The method
essentially consists of starting from the Kuhn-Tucker conditions of optimality for the NLP
11
August 14, 2000
formulation of the flow allocation problem, and interpreting those conditions to yield a metric of
comparison between alternative paths.
Notation
We introduce the following additional notation:
K (i , j )  number of paths for node - pair (i, j )
K
K
(i , j )
 total number of paths in the network
(i , j )
P(i , j ), k  path k of node - pair (i , j)
k  1,  , K (i , j ) ,
 (i , j ), k  fraction of d (i,j) allocated to path P(i , j ), k
We then have the conditions
 (i , j ), k  0,
K (i , j )

(4.1)
 (i , j ), k  1, for each (i, j )
k 1
Equations for Link Flows
Define the structure of paths by the path-link incidence relations
1 if path p (i , j ),k uses link (m, n)
 ( m,n),(i , j ),k  
0 otherwise
We then have the following equations, which express the link-loads X ( m,n) in terms of the nodepair loads d (i , j ) :
X ( m,n)    (m,n),(i, j ),k d (i, j ) (i, j ),k
(4.2)
(i , j ), k
Performance Criterion
We assume that the network performance criterion to be minimized is given by a function D of
the link loads X ( m,n) , of the following separable form:

D( X )   D(m,n) X (m,n)

(4.3),
( m, n)
where each D j is an increasing convex function of its argument, with the property that, for each
(m, n)
lim
X ( m, n ) b( m , n )


D( m,n) X ( m,n)  
(4.4)
The condition that each link load X ( m,n) cannot exceed the corresponding link-bandwidth b(m,n) is
implicit in (4.4).
For a given network, with node-pair loads {d (i, j ) } , and a chosen set of paths, the link loads are
determined by the allocation factors { (i, j ),k } , as seen from (4.2). Hence, we may write
12
August 14, 2000


D( X )   D( m,n) X ( m,n)   D( m,n)    ( m,n),(i , j ),k d (i , j ) (i , j ), k   Q( ), say
( m, n )
( m, n )
 (i , j ),k



(4.5)
Kuhn-Tucker Conditions of Optimality
We now have the following constrained non-linear program:
Minimize Q( ),
subject to the conditions
 (i , j ), k  0,
(4.6)
K (i , j )

(i , j ), k
 1, for each (i, j )
k 1
The Kuhn-Tucker necessary conditions of optimality for the NLP (4.6) state that there exist
constants {(i, j ) } such that, at an optimum solution {(i, j ), k } , we have
Q

  (i , j )  0
 (i , j ), j

, k  1,  , K (i , j ) for each (i, j )
 Q

 k (i , j ), k 
  ( i , j )   0



 k (i , j ), k


(4.7)
It follows from (4.7) that
Q
 (i , j ),k
Q
 (i , j ),k
  ( i , j )
  (i , j ) if  (i , j ), k



, k  1,  , K (i , j ) for each (i, j )
 0


(4.8)
The conditions (4.8) have the following interpretation:
at an optimum solution, the partial derivatives of the network performance criterion with respect
to the flow allocations of a given node-pair are equal for all paths that are in use for that nodepair, and are less than or equal to the derivatives with respect to allocations of the unused paths
for that node-pair.
The necessary conditions (4.8) are also sufficient for optimality [8] when D is a convex
differentiable function of the { (i, j ),k } , as is the case here, since D is a convex increasing function
of {X ( m,n) } , which, by (4.2), are convex functions of the { (i, j ),k } .
 Q 
Calculation of Derivatives 

  (i , j ), k 
We have
13
August 14, 2000
Q
 (i , j ), k
 
D( m, n ) ( X ( m,n ) )
 (i , j ), k
( m, n )
  D(m,n ) ( X ( m,n ) )
( m, n )
X ( m,n )
 (i , j ), k
 d (i , j  D(m, n ) ( X ( m, n ) ) I (m, n, i, j , k )
( m, n )
where
1, if link (m, n) is part of path P(i , j ), k
I (m, n, i, j, k )  
0, otherwise
Hence,
Q
 (i , j ), k
 d (i , j )

( m,n)P(i , j ), k
D(m,n) ( X ( m,n) )
(4.9)
Using (4.9) in (4.8), we obtain
 (i , j )

  (i , j ) , say 
d (i , j )

P(i , j ), k
, k  1,  , K (i , j )
D(m, n ) ( X ( m, n ) )   (i , j ) , if  (i , j ), k  0

( m,n)P(i , j ), k

 D
( m,n)
( m,n ) ( X ( m,n ) )


(4.10)
for each (i, j ) for which d (i , j )  0
We note that

(m,n)P(i , j ),k
D(m,n) ( X ( m,n) ) is in the nature of a load-sensitive “path metric” for path
P(i, j ),k , with each term D(m,n) ( X (m,n) ) representing the corresponding “link metric”. Moreover, the
path metric can be determined at the source node by distributed computation, by each node of the
path transmitting a partial path metric to its upstream neighbor, the partial metric consisting of the
sum of metrics of links traced backwards from the destination up to the node in question.
Define
M (i , j ),k ( X ) 

(m,n)P(i , j ), k
D(m,n) ( X ( m,n) )  metric for path P(i , j ), k
(4.11)
Then, (4.10) has the following simple interpretation: in an optimum solution, for the traffic of
each node-pair, all the paths that have flows allocated to them must have the same path-metric,
and this metric must be less than or equal to the metric of paths which have no flows allocated to
them.
Thus, an algorithm for arriving at the optimum flow allocation should be based on the principle of
taking the flow allocations closer to attaining the conditions (4.10), by increasing the allocation to
the path with the smallest metric and reducing the allocations on the other paths, keeping the sum
of the allocations equal to 1.
It is important to note from (4.10-4.12) that the actual implementation of the algorithm does NOT
require explicit knowledge of the point-to-point loads {d (i, j ) } , and could be accomplished by
distributed computation among the nodes. It is based on comparisons of the metrics of alternative
14
August 14, 2000
paths, which are determined entirely by link-loads, for the form of performance criterion assumed
in (4.5). These metrics can be computed by the originating node on the basis of information
collected from its ‘downstream’ neighbors.
5. Combined Use of LP and NLP Methods
There are two parts to the solution of the general problem of assigning traffic demands to paths in
the network: choosing a good set of paths, and determining the right allocation of traffic to the
paths.
The pair-based LP formulation of Section 3.1 proceeds without an explicit choice of paths,
describing the problem entirely in terms of link flows, and can also be described as link-based.
From the link-flows assigned by the LP solution, we derive a compatible set of paths and
corresponding path-allocation of flows by the method described in Section 3.5. The NLP
formulation presented in Section 4, on the other hand, is based on a pre-specified set of
admissible paths for the traffic of each demand, and determines the optimum allocation of flows
to this set of paths.
An argument in favor of the NLP is that the nonlinear ‘cost-function’ proposed for a link (as a
function of its load) manages to capture the different effects that are important at different load
regimes. We therefore considered the idea of using the set of paths derived from the solution of
the link-based LP as the input paths to the path-based NLP. Thus, we use the LP to determine the
paths and the NLP to determine the allocation of flows to those paths. As we see later, this
combination of the two methods seems to produce a solution that has excellent characteristics.
There are additional arguments in favor of this approach of combining the LP and the NLP
methods. The LP formulation requires complete knowledge of the point-to-point demand matrix,
and is thus suitable for centralized off-line computation. The NLP algorithm, however, is capable
of being implemented by means of distributed computations among the network nodes, by
exchange of local information [8], without explicit knowledge of the point-to-point demand
matrix, as was pointed out in Section 4. For this reason, the NLP can accommodate uncertainties
in loads and adapt itself to ‘slow’ load variations (slower than the rate of convergence of the
algorithm). We can thus consider a scheme in which the traffic paths (MPLS LSPs) themselves
are determined at infrequent intervals, by means of off-line centralized LP computations on the
basis of the most recent estimates of the point-to-point demand matrix, while the NLP is being
continually implemented in the network in its distributed mode, adapting itself to the actual loads
in the network. Thus, the time-consuming path calculations are done off-line and at intervals over
which significant changes occur in the loads or link-capacities, while the flow-allocations are
under continual adaptation through distributed actions at the nodes.
6. Numerical Results
We report results for two networks provided on a web-site (http://brookfield.ans.net/omp/randomtest-cases.html) maintained by Curtis Villamizar for testing and evaluating MPLS-OMP. The
smaller of the two networks has 10 nodes and 58 links, while the larger has 50 nodes and 202
links. The test cases provide the capacity for each link and the demand between each pair of
nodes. We found that the capacities provided in the test data set are not the same as those implied
by the solution that Villamizar provides. Thus, for the 10-node case, we have based our tests on
the capacities implied by his solution in order that we may compare our results to those of MPLSOMP. For the larger network, we use the test network as given and provide results for only our
own methods. We note that our results are still quite preliminary, but they illustrate the general
efficacy of the proposed methods.
15
August 14, 2000
In the trials performed, we observe both the solution time and the character of the resulting
solution. The character of the solutions for the 10-node network is summarized by the link
utilizations displayed in Figure 1. The illustrated results are obtained by four different methods:
1)
2)
3)
4)
the linear programming solution of the egress-centric formulation (LP);
the NLP solution obtained using paths extracted from the LP solution (LP-NLP);
the MPLS-OMP solution provided by the aforementioned web-site (MPLS-OMP); and
the NLP solution obtained using the paths provided by the MPLS-OMP web-site (OMPNLP).
We consider the LP formulation that employs the combined objective described in Section 2.2.3.
We set the objective parameters to assure that we obtain a non-dominated solution that also
optimizes the maxmin criterion.
Number of links
We solve the LP using CPLEX 3.0, which is a commercially available LP solver. CPLEX itself
includes the choice of two LP solvers. The first employs the simplex method [11], while the
second employs the more recent barrier method [12]. The barrier method often performs well in
solving large, sparse linear programs like those for our multi-commodity flow problems. In the
context of our test problems, the barrier method is considerably faster than the simplex method on
the 50-node problem but slower on the 10-node example. A feature of the simplex method,
which we lose with the barrier method, is the bound on the number of nonzero flows assured by a
basic solution. (This is described in Section 3.5.) The barrier solution may have many more than
the necessary number of nonzero flows. However, CPLEX includes a “crossover” procedure [13]
to obtain a basic solution from a barrier solution. To obtain our results, we apply the barrier
method followed by the crossover procedure to obtain a basic solution to the LP. Then (for the
LP-NLP case) we extract paths from the LP link flows and apply the NLP to distribute flow to the
selected paths.
LP
LP-NLP
MPLS-OMP
OMP-NLP
90-100%
80-90%
70-80%
60-70%
50-60%
40-50%
30-40%
20-30%
10-20%
0-10%
60
50
40
30
20
10
0
Percent utilization
Figure 1: Distribution of link utilizations for various routing methods.
For the 10-node example, all of the computations required to solve the LP, extract paths from the
LP solution and then apply the NLP to distribute flow to the paths are completed in under a
second on a Sun S670.
16
August 14, 2000
The maximum link utilization is approximately 54.6% for the 10-node test case. Thus, the linear
programming method provides a solution in which no more than 54.6% of the bandwidth on any
link is utilized. Figure 1 shows that the other methods require a larger percentage of available
bandwidth on the most congested links in the network. However, the NLP method seems to
dampen the peaks in the distribution of link loads, thus yielding a slightly lower average
utilization. The two tests of the NLP method indicate that its results are very sensitive to the paths
provided as input. In this case, the paths extracted from the LP solution seem to yield a better
solution from the NLP because there are far fewer congested links.
Number of links
For the 50-node problem, we limit our testing to the LP and the NLP using paths extracted from
the LP solution. The maximum link utilization determined by the LP is 55.2%. The distribution
of link utilizations is shown in Figure 2. The link load distribution for the LP and NLP cases is
quite similar. Here, the NLP distributes flow with a maximum link utilization of 59.3% (or
slightly higher than the LP value) but, of course, performs better with respect to the non-linear
delay criterion.
160
140
120
100
80
60
40
20
0
LP
NLP
5060%
4050%
3040%
2030%
1020%
0-10%
Percent utilization
Figure 2: Distribution of link loads for the 50-node network.
The LP formulation that results from the 50-node case is rather large, having 2702 constraints and
10101 variables. The LP solution is obtained and paths are extracted in 123.9 seconds. Flow
distribution with the NLP requires an additional 11 seconds. On this example path selection
requires approximately two minutes, but flow allocation (or re-allocation) is considerably faster.
Thus, given a good set of paths the NLP obtains a solution very quickly. This suggests that the
NLP method may perform well in a dynamic environment, provided the input set of paths remains
viable.
Finally, a word on the number and “quality” of paths we obtain. In both test problems, there is
demand between each pair of nodes. Thus, we require at least 90 unique paths in the small
network and at least 2450 paths in the larger network to guarantee that there is at least one path
for each demand.
17
August 14, 2000
In the 10-node example, 117 paths are extracted from the LP solution. A total of 66 demands
have a single associated path; 21 demands have two paths; and 3 demands have 3 paths. Of these
paths, 111 are “min-hop” paths, while the remaining 6 require one extra hop. The NLP allocates
flow to 112 of the 117 paths extracted from the LP solution. The MPLS-OMP site provides 110
paths as input, and of these, the NLP allocates flow to only 91.
In the 50-node example, 2577 paths are extracted from the LP solution, and the NLP allocates
flow to 2469 of them. Of the paths extracted from the LP, 2534 are min-hop paths, while the
remaining 43 use one extra link. In the subset of paths selected by the NLP, all but 5 are minhop. The small deviation from the optimum hop count suggests that the paths we obtain are
likely to be good with respect to many practical criteria.
In the solution extracted from the LP, 3227 demands have a single associated path; 120 demands
have two paths; 2 demands have 3 paths; and 1 demand has 4 paths. The NLP prunes the paths so
that all but 19 demands have a single associated path, and those 19 demands have exactly 2 paths.
Thus it appears that, with either an LP method or the NLP method (with paths extracted from the
LP solution), the vast majority of the demand is served by a single path in a well-designed
network.
7. Conclusions
Multi Protocol Label Switching (MPLS) is a flexible routing mechanism for traffic flows that can
reduce congestion in the network by means of the intelligent matching of flows to capacities of
paths. MPLS also has the potential to be a mechanism for realizing differentiated service-levels in
the network for designated sets of traffic flows. To realize the potential benefits of MPLS, one
has to find efficient solutions to problems that can be formulated as the optimization of multicommodity flows in a capacitated network.
In this paper, we have provided solutions to the MPLS problem, by means of Linear
Programming (LP) and Non-Linear Programming (NLP) methods. In particular, we have
presented various versions of the LP formulation, and have proposed methods of ‘aggregation’ of
input demands that drastically reduce the complexity of the problem. Also, with the LP approach,
we have shown that the objective function can be manipulated to incorporate a degree of
‘robustness’ as part of the characteristics of the solution.
Exploiting the fact that the NLP method lends itself also to distributed computation, we have also
proposed a method of making use of both the LP and the NLP algorithms to solve the problem,
taking advantage of their respective strengths. In this combined method, we carry out LP
computations for determining a suitable set of paths for traffic flows, and then use the NLP to
determine the actual flow allocations to this parsimonious set of paths. In practice, this approach
would separate the computations into two levels, at two different time-scales: infrequent
execution of time-consuming off-line calculations for path selection combined with continual
rapid adjustments to flow allocations.
We have used the LP formulation to obtain a solution to the MPLS problem for a network of 50
nodes in minutes, and we expect to make improvements that will permit larger networks to be
solved. The NLP algorithm has been successfully tested on both 10 and 50-node examples, and is
an area of active research.
18
August 14, 2000
REFERENCES
1. E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol Label Switching Architecture,"
Internet draft <draft-ietf-mpls-arch-06.txt>, August 1999.
2. D. Awduche et al, "Requirements for Traffic Engineering over MPLS," IETF RFC 2702,
September 1999.
3. D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF," Internet Draft <draft-katzyeung-ospf-traffic-01.txt>, November 1999.
4. H. Smit, T. Li, "IS-IS extensions for Traffic Engineering," Internet Draft <draft-ietf-isistraffic-01.txt>, May 1999.
5. C. Villamizar, "MPLS Optimized Multipath (MPLS-OMP)," Internet Draft <draft-villamizarmpls-omp-01>, February 1999.
6. D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels," Internet Draft <draftietf-mpls-rsvp-lsp-tunnel-05.txt>, February 2000.
7. B. Jamoussi, "Constraint-Based LSP Setup using LDP," Internet Draft <draft-ietf-mpls-crldp-03.txt>, September 1999.
8. R. G. Gallager, “A Minimum Delay Routing Algorithm Using Distributed Computation”,
IEEE Transactions on Communications, Vol. COM-25, No. 1, pp. 73-85, January, 1977.
9. I. Widjaja and A. Elwalid, “MATE: MPLS Adaptive Traffic Engineering”, Internet Draft
<draft-widjaja-mpls-mate-01.txt>, October 1999.
10. R. K. Ahuja, T. L. Magnanti, and J. B. Orlin, Network Flows: Theory, Algorithms and
Applications, Prentice-Hall, Inc., Englewood Cliffs, NJ, 1993.
11. V. Chvatal, Linear Programming, W. H. Freeman and Company, New York, NY, 1983.
12. I. J. Lustig, R. E. Marsten, and D. F. Shanno, “Interior Point Methods for Linear
Programming: Computational State of the Art”, ORSA Journal on Computing, 6, pp. 1-14,
1994.
13. R. E. Bixby, “Progress in Linear Programming”, ORSA Journal on Computing, 6, pp. 15-22,
1994.
19