|
Archive
Flanagan Consulting
Network Analysts and Consultants
"We Have the Experience"
-------------------------------------------------------------------------
ViewsLetter on Provisioning
13 Jan 2003 #14
IN THIS ISSUE:
--Traffic Engineering with MPLS
--Footnote to a Wish
>>Analysis
WHAT PUTS THE 'TE' IN MPLS?
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
--capacity
--latency
Some are left to the user to define:
--link is encrypted
--carried over satellite
USING THE INFORMATION
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
LER.
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
LER.
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
needle."
FINDING THE 'RIGHT' PATH
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).
DETAILS, DETAILS
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
labels.
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
provisioning.
>>FOOTNOTE TO A WISH
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 info@flanagan-consulting.com
See what else we do at www.flanagan-consulting.com
============ + ===== + ===== + ===== + ============
"Flanagan Consulting" and "ViewsLetter" are
Service Marks of W. A. Flanagan, Inc.
Updated: 11 June 2003
|
