ViewsLetter(SM) on Provisioning

Site Map



Flanagan Consulting                 Network Analysts and Consultants
                                                    "We Have the Experience"
ViewsLetter on Provisioning                16 Dec 2002             #12

>> How MPLS fits into provisioning, Part 3:  Labels and Tables

============ + ===== + ===== + ===== + ============
We have our winners. The carrier service that has been completely
discontinued is Morse code telegraphy, not ISDN or party lines or X.25.  A
copy of "T-1 Networking" by William A. Flanagan is on the way to each of
the first three readers who emailed the answer (two of the three are in
    "It was fun;  we'll do this again."
If you didn't win, order a copy from our web site, under Publications.]
============ + ===== + ===== + ===== + ============


Last time we looked at the way Multiprotocl Label Switching (MPLS) behaves
like a virtual circuit network;  that is, like frame relay or ATM (OK,
like X.25 in some cases).
-- The label is the packet address the switch uses to determine where and
how to send that packet.
-- Each switch/router (in general) changes the label on every packet it
-- The previous point means labels have only local significance, on a link
between adjacent Label Switching Routers (LSRs).
-- An LSR keeps track of connections, associated labels, and the treatment
each packet should receive in a forwarding table (FT).

The FT is just a list in memory that's organized for quick lookups.  It
might be indexed by the values of the labels expected to be on arriving
packets--that way it's easier to find the appropriate table entry when a
packet shows up.  The table entry contains the new label to replace the
one just looked up, the port where the packet should be sent out, and
handling procedures associated with this connection--most likely the
prioritization class and which queue to place it in.

All this is very simple and works well.  The main task is populating all
the forwarding tables with all the proper information to create the
logically linked hops that constitute a virtual circuit with the desired
"handling" parameters for each connection.

LSRs offer two basic ways to create these entries in the FT:
1.  Manually, by an operator at the command line interface.  These entries
are static--the router leaves them in the table until later commands
delete or change them.
2.  Automatically, calculated by the router from information provided by a
routing protocol such as RIP, OSPF, IS-IS, etc.

A third method relies on a separate Network Management System (NMS).  This
workstation calculates a physical route from an inventory that represents
the topology of the network and (ideally) the utilization of each
component.  The NMS creates a connection by sending messages to all nodes
on the new path, instructing them to place labels and parameters in their
forwarding tables.

This centralized method isn't favored by many as it doesn't fit the
distributed model of Internet routers.  The central NMS also poses several
problems in scaling up in size:  discovering and maintaining the
inventory, calculating large numbers of paths quickly, and distributing
new table entries across large numbers of nodes from various vendors.  On
the other hand, one NMS to coordinate an entire network can ensure high
utilization, avoid stranding assets, and offer better control and
security.  This method has been used successfully in private TDM networks.

For the present, most development work is going into method 2, based on a
routing protocol (most interest is in Border Gateway Protocol, BGP) and a
Label Distribution Protocol (LDP).  That is, the routing protocol reports
the number of hops, or some other metric for distance or cost, to reach
each destination from each outbound port on the switch or LSR.  Routing
protocols operate continually, letting all participating routers know
about changes to the topology and conditions in the network.

When asked to set up a connection, the LSRs pick the "best" path, based on
whichever metric it is using, to the specified destination.  On each link,
he upstream LSR (upstream with respect to the direction of the connection
setup) signals to the adjacent (downstream) LSR with a connection request,
via LDP:  "I want to reach destination 'X' with a connection that has
parameters 'K, L, and M'."  Common parameters to specify include
throughput, latency, and loss ratio.

The downstream LSR on this link may accept the request, returning a label
it selects for the two LSRs to use on this link for this connection.  The
same label value may be in use by these nodes for different connections on
other links, even between themselves.

The downstream LSR will reject the request if it lacks the resources to
deliver the parameters requested.  The downstream LSR passes the
connection request to a node further downstream, requesting the same
parameters and a new label value, and so on to the destination LSR.

After the connection is set up, packets may flow between the end points.
Note that the MPLS Label Switched Path (LSP) is the same physical route
(nodes, ports, links) taken by a routed IP packet between the same end
points--the same routing protocol determines both.

So, if packets take the same path whether "routed" or "on an MPLS
connection," tell me again why we wanted to set up the LSP?

Most observers will admit there is not much gain from LSPs based on
standard routing.  This is particularly true if the network is not heavily
loaded and all traffic is treated the same.

MPLS is not necessary to prioritize packet types for "real time"
applications such as voice, video, and TDM circuit emulations.  Marking
packets by setting bits in the Type of Service (ToS) field of the IP
header (also known as the Differentiated Service, DifServ, field) is
enough for routers to recognize those packets and give them priority on
outbound ports.

But LSPs based on BGP are automatic--making provisioning easier.  LSPs are
more secure because the local address is difficult to guess and nearly
impossible to spoof by a third party.  For virtual private networks based
on LSPs, provisioning based on BGP is easy for the carrier and provides
the same isolation from intrusion as FR or ATM connections.

The odd aspect of MPLS/BGP is that carriers seem to be accepting this
automation on IP networks where they have insisted on manual configuration
of virtual circuits over frame relay and ATM.  FR and ATM switches have
for years offered "switched virtual circuits" (SVCs).  That is, an end
point can signal the network to request a connection, on-demand, just by
specifying the other end (destination).  The network will set up the SVC,
automatically optimizing the use of system resources, honoring the service
parameters in the connection request (throughput, delay, etc.), and
possibly establishing a stand-by path for failure protection.

A question exists as to whether existing FR and ATM networks (ATM in the
core) will be adapted to MPLS.  The DLCI and VCC fields are defined as
labels, if that's what you want to call them.  Frame and cell forwarding
engines can't tell the difference between a "normal" packet and one in
which a "label" occupies the address field.  All that's necessary, then,
is to add routing and label distribution protocols to the control modules
in the FR and ATM switches.  Then the nodes can use these protocols to set
up virtual circuits based on the "best" route.  LDP replaces whatever
inter-node signaling method the switch vendor originally  designed for
SVCs (FR and ATM standards define the user interface, not how the network
operates internally).

Sounds very much like SVCs, regardless of the type of switch (or router)
that is the LSR.  But if MPLS is what it takes to automate the process of
provisioning virtual circuits, maybe that's the best way forward.

An added benefit is that Generalized MPLS extends automation to cover
optical wavelengths and TDM channels (as on SONET networks), two other
types of networks where manual provisioning has prevailed.  Given its wide
acceptance, MPLS may be the ONLY way forward.

One argument for keeping manual setup is the perceived need for an
operator to control the physical path of a connection.  The basic routing
protocol doesn't offer that ability.  However, there are extensions to
routing protocols that do let an operator pin a connection to a path. 
More on that next time.

-- Visit when you need to write a White Paper,
   create/present a seminar/tutorial, or strategically position your telecom
   product.  We have that experience.
-- Your input is encouraged--ask a question or suggest a topic--email
-- Special thanks to for hosting ViewsLetter.

"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