ViewsLetter(SM) on Provisioning

Site Map



Flanagan Consulting                 Network Analysts and Consultants
                                         "We Have the Experience"
ViewsLetter on Provisioning                13 Jan 2003        #14

--Traffic Engineering with MPLS
--Footnote to a Wish


In Issue 12 we explained how a basic routing protocol can provide enough
topology information to allow the nodes (label switching routers) in an
MPLS network to set up Label Switched Paths (LSPs) automatically.  This
form of automation can isolate users from each other by placing them on
different Virtual Private Networks (VPNs).  But all packets travel over
the same physical paths they would have taken if routed normally.  The
network operator has no control over traffic engineering, beyond adjusting
the "cost" of various links.

That is, Multiprotocol Label Switching is no better at directing traffic
efficiently over multiple paths than the routing protocol running on the
network.  Run a standard Interior Gateway Protocol (IGP) and you get
standard traffic distribution:  one path from any point to another, the
"best" path according to the metric (such as router hops) applied by that
protocol.  The path changes only when the topology or links costs change.

In large networks built on the very practical topology of a partial mesh,
traditional routing can lead to congestion.  All traffic is sent on the
"best" path, though it is busy or lacks capacity.  Other viable paths may
remain lightly loaded.  To take full advantage of available capacity, the
routing protocol must report the state of each link.

"Link State Protocols" have been around;  Open Shortest Path First (OSPF)
is an example.  From its beginning, OSPF reported if a link were up or
down, its capacity, and its utilization.  For a best-effort network, that
was enough.

But the demands of interactive applications such as voice and video
include latency and packet loss ratio.  Financial matters demand
encryption, or "no-satellite" paths.  Effective redundancy demands that no
link in a backup path appears in the main path.  These factors require
more information, which is made available by extensions to routing
protocols that are intended for Traffic Engineering (TE).

A routing protocol for TE gathers additional details about the link.  Some
items are standardized (with assigned code points):
--link ID

Some are left to the user to define:
--link is encrypted
--carried over satellite


The path-finding function in the Label Edge Router (LER) draws on this
information gathered by the routing protocol to choose a next-hop
forwarding direction.  Alternatively, an LER may calculate the entire path
and request it explicitly, which is very similar to source routing (SR) in
Token Ring networks (and others that do SR).

To set up a path based on the calculation by the ingress LER, that LER
sends a connection request to the next node on the path.  The form of this
message can be the PATH message of the Resource Reservation Protocol
(RSVP), among others.  The second node looks at its own available
resources, to see if it can fulfill the request (for bandwidth, latency,
any guarantees, etc.)  If it can meet the request, that node passes the
connection request to the third node on the path, and so on to the exit

When "last" LER accepts a connection request, it responds (if in RSVP)
with a RES (reservation) message back along the same path.  This message
contains the label that will be used on this link for this connection.  It
also contains confirmation of the parameters requested by the originating

The N-1st node records the downstream label in its forwarding table, then
adds its own choice of upstream label to the RES message and sends it up
the path to the next node.  All nodes on the path in this way learn the
labels to use on each side and the expected treatment for packets on this
connection.  When the message reaches the originating LER, the connection
is available for traffic.

For those of you who have been around more than 15 years, you may
recognize this connection setup from X.25 as "threading the Tymnet


TE features allow the path-finding "engine" to calculate a path that
depends on the current state of the network.  Not only on the gross
level--links up or down--but at the more subtle level of latency or the
amount of bandwidth available at this time to commit to a new connection.
The first request for an LSP from Point A to Point X may take up most of
the bandwidth on a particular path or link.  A second request, identical
to the first, will find a different path, even though it may contain more
hops or have a higher "cost" than the first route.

Routers enabled for TE can apply quite complex logic, established policy,
or operator input when choosing a path.

This is a key concept:  the "TE" path selection depends on many more
inputs than the hop count or other simple routing metric.

We've mentioned the ability to route diversely by prohibiting an element
from being on both paths.  When a link or node is to be taken out of
service, the operator can establish a policy that no new LSPs will include
those elements--as LSPs are torn down, all traffic eventually is removed.

Voice traffic will be given the path with lowest latency, even if LSPs for
other types must be rerouted over longer paths (or satellite).


You should understand that this explanation is _really_ simplified.  The
documents that describe just the TE aspects of MPLS run to hundreds of
pages.  There are other routing protocols and other ways to distribute

Details are important, because interoperability depends on them.  But from
a higher level, the details are not as important as the fact that these
methods are being defined, hardware vendors are building them into
equipment, and the industry is gaining experience with them.

Much remains to be done, for example to say what entities may originate a
connection request--in the hardware or an application.  It would ease
deployment if one label distribution method proved easier to set up,
cheaper to build, faster to establish a connection, and better at scaling
up to global proportions.

While we expect several methods to compete for top position for at least
several years, that is not a reason to avoid deploying MPLS-TE.
More-likely inhibitors are the depressed economic condition of the
industry, lack of perceived need among many people at the ILECs, and a
lingering reluctance among carrier operations staff to trust the network
to do as good a job of traffic engineering as they can.

But don't forget the prediction in VL#1 that there won't be enough trained
people to do this work manually for the demand we all see coming.  MPLS
and automated label distribution should play a role in automated

    As a reader "down under" pointed out, the holiday wish in the last issue
failed to acknowledge that some people on this planet were celebrating the
_summer_ Solstice.  Pardon us!

This issue sponsored by
============ + ===== + ===== + ===== + ============
The White Paper Dept. of Flanagan Consulting
a service of W. A. Flanagan, Inc.
     To sell it, first explain it.  We can do that.
     Ph:  +1.703.242.8381
See what else we do at
============ + ===== + ===== + ===== + ============

"Flanagan Consulting" and "ViewsLetter" are Service Marks of W. A. Flanagan, Inc.
 Updated:  11 June  2003

Flanagan ConsultingSM
W. A. Flanagan, Inc.
45472 Holiday Drive, Dulles, VA 20166
Ph:  +1.703.242.8381
Fx:  +1.703.242.8391