ViewsLetter(SM) on Provisioning

Site Map




Links
Acronyms


Archive

  Flanagan Consulting                 Network Analysts and Consultants
                                         "We Have the Experience"
-------------------------------------------------------------------------
ViewsLetter on Provisioning             18 Nov 2002         #10

>> How MPLS fits into provisioning, Part 1
============ + ===== + ===== + ===== + ============

>>Analysis
MUCH MISUNDERSTOOD MPLS HAS A
PROPER PLACE IN PROVISIONING

But it might not be what you think:  most explanations of MultiProtocol
Label Switching (MPLS) miss what we consider to be significant points.

First, we'll separate the frame-forwarding mechanisms (the data plane)
from signaling (the control plane).  Then we'll look at how the MPLS
control plane fits into provisioning.  These are fairly large chunks to
absorb, so we'll spread this topic over several issues.

Unless you just joined the telecom industry, you've seen articles,
advertisements, books, and entire conferences devoted to MPLS.  The
impression that most of these give is that MPLS is a form of Internet
Protocol (IP).  A frequently recurring expression is "MPLS over an IP
network."

Strictly speaking, this statement may apply to the control plane.  MPLS
signaling does assume an IP network.  However, that statement does not
describe the data plane at all.  In this issue we'll compare MPLS frame
forwarding and IP routing, and see they are almost diametrically opposite.

What are the implications for provisioning?  Potentially, two big ones for
carriers:
1.  Lower Cost.  Defined methods to encapsulate many other protocols in
MPLS raise the hope that one carrier network could deliver all present and
future services.  Carriers hope to reduce costs by eliminating multiple
switching technologies and overlay networks.
2.  Higher Revenue.  MPLS supports "pinning" physical paths to specific
nodes and links, thus supporting traffic engineering and enhanced services
for which the subscriber would pay more than commodity rates.


MPLS DATA PLANE DIFFERS FROM IP ROUTING

To ensure we understand terms in the same way, we'll start with a few
words on IP routing.

An IP router contains a table that shows which outbound port is the best
"next hop" for each destination IP address (DA).  The initial
determination for an arriving packet comes from looking up its DA in the
table, and reading the corresponding exit port.  In most cases this
packet's address will not appear as an individual entry, but as part of an
aggregated address--a range of IP addresses expressed as a subnet.  The
subnet mask determines how many of the most significant bits in the packet
address need to match an entry in the table.  In the degenerate case of a
"one-armed router," the routing table need contain only one wild-card
entry pointing to the single port.

To give some sessions higher priority, routers may classify packets
further:  by protocol ID, by Layer 4 port number, by source address, or in
other ways.  This process can, for example, direct packets into different
queues at the outbound port.  Classification takes additional time and
requires processing power, typically supplied by the control processor in
the router.

Note that as long as the network is stable, the routing table doesn't
change.  All packets from one specific host to another follow the same
physical path until the network undergoes a topological change or the
routing protocol in use responds to congestion with a routing update. 
"Packet by packet routing" generally doesn't send each packet on a
different path, as is often implied in discussions of the Internet.

When the IP network is stable, each router forwards equivalent packets
aimed at the same destination through the same exit port (with the same
priority, etc.).  The router doesn't care whether it's one host or a
thousand hosts sending the packets.  When an additional host starts to
send packets to the same address, a router handles the new user the same
way.  This feature is the essence of a connectionless network:  a user can
hand packets to the network without first establishing a connection to the
destination or even checking that the routing tables contain an
appropriate entry.  If a given router doesn't have an entry for a specific
destination address, the packet goes to a default router (which is
expected to know) or the router uses a routing protocol to find a path
(which means a specific outbound port).

Connectionless operation depends on each packet containing a globally
unique destination address.  If the router doesn't already know how to
forward toward that address, it can find out because no other destination
can possibly have that address.

MPLS forwarding is based on the "label" applied to each packet, not the IP
address or other characteristics of the header or payload.  To make MPLS
efficient, the label is short and frame forwarding is kept simple.  But
this is not your father's IP packet (probably not your older brother's,
either).  A label header is inserted ahead of the IP header, after an
Ethernet MAC or a PPP header.

By definition of MPLS, then, an "IP router" cannot deal with MPLS
frames--they are malformed and too long.  MPLS requires a "Label Switching
Router" (LSR) which understands the new frame format so it can read the
label.  From one point of view, then, MPLS can't operate over an "IP
network."

Granted, new software adapts most routers to MPLS (makes them LSRs).  By
configuration, you can set the device to forward MPLS packets properly.
Of course, if IP routing was burned into ASICs to improve throughput
speed, they can't be programmed to read labels.

Being short, the label can't be globally unique and has only local
significance (on the link between two LSRs).  Specific values of the label
must be reused often, which means each LSR generally changes the label of
every MPLS packet handled.  To set up a connection based on labels,
specific label values must be defined and inserted in a routing table in
each LSR along a Label Switched Path (LSP)--before traffic flow starts.
The label table is in addition to any IP routing table present in the same
device.

In other words, an LSP is a virtual circuit in a connection-oriented
network.  Note that both IP and MPLS packets follow a fixed path between
end points as long as the network is stable.  Setting up LSPs is a
function of the control plane (more on that later).

Sticking with MPLS forwarding, the LSR finds an arriving packet has a
label, looks it up in the label table to find the exit port and the new
label value.  The table will refer to all the other characteristics of the
connection as well:  priority, bandwidth allocation or guarantees, etc.
Here's where MPLS is more efficient than IP routing, doing in one step
what routing does in several.

The label table directs a packet to the proper queue as well as the
physical port.

Unlike Frame Relay and ATM switches, the LSR may apply the same outbound
label to packets arriving with many different inbound labels.  Only
packets belonging to the same "forwarding equivalency class" (FEC) share a
label.  Label aggregation may reduce the number of connections each LSR
must maintain--if connections are equivalent.  That is, the packets must
have identical characteristics from this point (this LSR) to a final or
intermediate destination.  At that point, MPLS assumes the destination
host can sort our the sessions based on IP address and L4 port number.

Two LSRs can create a "trunk" between them by adding a second, common
label to encapsulate MPLS frames that retain their original labels.  This
process, "label stacking," is the simplest form of encapsulation.  Moving
all services to one network requires many types of encapusulation, which
we'll look at next time.  After that, we'll see where routing tables come
from and how they relate to service provisioning.

+============ + ===== + ===== + ===== + ===== +=================+

LINKS
-- Visit www.flanagan-consulting.com for information about our
   services, speaking engagements, and updates on other activities.
-- Your input is encouraged--ask a question or suggest a topic by phone or
email.
-- Special thanks to www.webtorials.com for hosting our web site and
ViewsLetter.
-- For sponsorship information, email us at info@flanagan-consulting.com
   or phone 703.855.0191.



"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
[directions]
 

Editor@ViewsLetter.com
www.flanagan-consulting.com







Site Map


ViewsLetter
Archive
 


Links
Acronyms

Home