'n' pieces of the Networked world
had touched upon Multi-protocol Label Switching (MPLS)
in one of the earlier issues, and mentioned that I'd
come back to the topic sometime later. After having
been privy to some information shared at the recent
MPLS Congress, I feel that it is time for me to revisit
the topic in the light of all of the industry advances.
The recent past has seen rapid developments in this
technology, with routing and switching companies helping
move it from the research labs all the way into marketing
collateral and RFPs. I have seen MPLS flavours being
positioned aggressively by different vendors in the
internetworking space over the last one year, and
while its deployment might not exactly be in line
with what is envisioned and enshrined in the RFCs,
MPLS and its applications are definitely being used
the risk of repetition, and for the first time readers
of this issue, let me spend a few paragraphs giving
a brief overview of the MPLS concept. MPLS started
off as a standardized effort on the part of the Internet
Engineering Task Force (IETF) to quicken switching
in a multi-protocol environment and to aid in traffic
it deals with the designation, routing, switching
and forwarding of traffic flows through a network.
combines the best of both routing and switching, and
has perhaps brought the power of both IP and ATM together.
While it does not fit into any part of the OSI model
by itself, MPLS supports IP, ATM and Frame-Relay L2
protocols. It also provides interfaces to existing
routing protocols such as BGP and OSPF, specifies
mechanisms for controlling and managing traffic flows
of varying granularity and perhaps most important,
defines a labeling mechanism that maps IP addresses
to simple, fixed-length labels.
labels are at the core of the MPLS concept. How do
they help? And what are they? Simply put, these labels
are path identifiers. MPLS uses labels native to the
media. They are encapsulated in Layer-2 headers along
with the IP packet. See Figure 1.0. The MPLS header
must include a label or a stack of labels. It may
also include other information relevant to label forwarding
like the Time to Live (TTL), Stack indicator, Class
of Service, or the type of next-header indicator especially
if it is non-IP. So now, routers along the path base
their routing decision upon the labels, and do not
get into stripping the packet open.
and the FEC
Now remember, in a large traditional routed network,
the routing decision essentially hinges upon the elements
in the forwarding table viz. the destination address
prefix, or the value of the Forward Equivalence Class
(FEC). The FEC is evaluated at each router based on
the IP header content, and this exercise not only
proves costly (in terms of having routers with greater
processing power), but also introduces a lot of overheads.
Paths are derived from the SPF routing protocol, and
packets with the same FEC follow this path.
MPLS allows for grouping of packets, and applying
rules to them. This forms part of the FEC. Packets
can now be assigned to the FEC, and the beauty of
this is they are assigned just once, at the point
of entry (ingress) into the network.
has its genesis in the need to forward a series of
packets from the same ingress to the same egress on
a given path, without evaluating the FEC at each intermediate
node. The idea was to introduce a soft (or even hard)
connection that would act as a path over which the
packets would be switched using labels identifying
the FEC. In doing this the FEC evaluation is done
only once, when the packet enters the network. Here
the FEC represents a group of packets having similar
requirements for transport. Packets in one FEC group
would be subjected to the same generic rule or treatment.
After this, the label is inserted into the packet,
and at each router, the label will be swapped, and
packet with the new label is sent to the next hop.
So the label assignment and removal are the concern
of the ingress and egress node, while most of the
other nodes are concerned with label swapping. (See
routers are involved in analyzing an IP packet header,
not just for determining the next hop, but also to
determine a packet's precedence, or Class of Service.
Some policies may then be applied to the packet based
on the information so obtained. MPLS allows for this
information to be inferred from the label, and it
is fair to say that the label represents a combination
of a routing based FEC, and a precedence or class
of service. Since MPLS does not require labels to
be analyzed, switches that are MPLS enabled can also
do packet forwarding.
a conventional network, routing decisions are enforced
by algorithms that calculate the shortest path to
a network, or one with the highest bandwidth rather
than the one that is most optimal. Optimality is not
an outcome of one or two factors, but one that is
based on various metrics such as delay, congestion,
jitter and bandwidth, apart from the number of 'hops'.
The data transmission in MPLS is through Label Switched
Paths (LSPs), which are sort of virtual paths from
the source to the destination. Like ATM, these LSPs
can be established prior to data transmission, or
can be set-up at flow time. MPLS labels serve as protocol-specific
identifiers and are distributed using traditional
routing protocols like BGP, OSPF or by the Label Distribution
Protocols (LDP). MPLS has label stacking, which means
that they can be provisioned once, and the same LSP
can be used for multiple purposes.
the heart of the network, MPLS has the concept of
high-speed core Label Switching Routers (LSRs) which
participate in the establishment of Label Switched
Paths (LSPs) and are responsible for high-speed switching
on these paths. At the Edges are the Label Edge Routers
(LERs), or the Edge LSR that operate on the MPLS and
access edges. The LERs are primarily concerned with
the assignment and removal of labels as traffic enters
into, or goes out of an MPLS network. (See Figure
selection in MPLS
Label switching supports two explicit route selection
models. One is the traditional "hop-by-hop"
mode used in existing IP networks with protocols like
OSPF. The second is by means of an explicit route
selection. In MPLS the explicit route has to be specified
at the time of label assignment. This makes it to
be a more efficient protocol than IP since, the entire
route is specified by either the ingress or egress
LSPs. This route information is often picked up from
topological data learned from a link state database,
and makes the process of switching quite fast.
MPLS Lambda Switching (MPlS) / Generalized MPLS
the market for optical switches and routers shifting
gears over the last few years, MPLS Lambda switching
has hit the ground running. MPL(ambda) switching has
extended the MPLS paradigm into the optical domain,
by using an MPLS-like control plane, to control the
optical cross-connects, which are the fundamental
building blocks of optical networks. It combines the
control plane of MPLS with the point-and-click provisioning
capabilities of photonic switches to offer a flexible
service-based switching model.
derivative protocols enable equipment in the service
layer to dynamically request for bandwidth services
from the transport layer using existing control-plane
techniques. In addition to advertisements and path
establishment, MPlS includes performance related information
on the network. The Edge routers, which actually deal
with services will use this information to dynamically
manage the available wavelengths in the photonic layer.
is now a part of Generalized MPLS (GMPLS). The goals
of GMPLS include extending MPLS support to multiple
switching types including TDM (SONET), Wavelength
(lambda) and Physical port (Fiber) switching. The
extension of the MPLS control plane into the optical
domain is largely accomplished by treating components
like circuits, lambdas (wavelengths) fibers and bundles
seeks to establish a single control-plane that would
not be tied down to any particular vendor, technology
or architectural approach. It also aims to facilitate
parallel evolution in both the IP and Optical transmission
domains, thereby lending credence to the much-touted
2-layer network. If this concept evolves further,
it could simplify the integration of optical switches,
optical transport mechanisms, and the original label-switching
That it is an emerging standard is evident by the
fact that some of the first RFCs related to MPLS (RFC
3031-3038) came into existence as late as January
2001. (See Figure 3.0). The MPLS working group has
so far produced over 40 Internet drafts, and is presently
branching into new working groups like the Provider
Provisioned VPNs (PPVPNs) and Common Control and Management
Protocols (CCAMP). As always, interoperability issues
are also being addressed at the famous University
of New Hampshire Interoperability lab, and at the
Advanced Internet lab at the George Mason University.
While it too early to proclaim interoperability between
vendors and implementations, if the MPLS concept has
to succeed in the larger context of the Internet,
it should happen in due course of time.
a standards perspective, work on Label Distribution
Protocols (LDP) is forthcoming. LDP is a set of procedures
and negotiations where LSRs communicate with each
other to exchange their label/FEC bindings, find out
their MPLS capabilities and set up label-switched
paths (LSPs). A number of LDPs are being standardized.
Existing protocols are being extended to allow LDP
to piggyback on them, leading to MPLS-BGP, MPLS-OSPF,
MPLS-RSVP etc., while new ones like MPLS-LDP and MPLS-CR-LDP
are being developed exclusively for label distribution.
large part of the networking community is behind the
development of MPLS-CR-LDP, while some vendors like
Cisco and Juniper networks are promoting the concept
of RSVP to establish ER-LSPs. Constraints introduce
a lot of flexibility into traffic engineering. Some
constraints like bandwidth, resource class, class
of service and priority settings can be introduced
to make the MPLS label have more "characteristics",
and give it the proper treatment.
other words, these are specified as "path attributes"
for each LSP. The Constraint- based Shortest Path
first (CSPF) algorithm deals with this. Organizations
are aligning one way or the other, and at some point
they are going to converge, and find themselves non-interoperable,
and that is when the fun starts.
- Deployment issues
One must note that MPLS by itself is not a solution,
but is a part of a whole. In other words it is but
just a component in the switching and routing domain.
Unlike popular misconception, the Integration of IP
and ATM is but one of the applications of MPLS, and
not the only one. It also does not make the routers
run fast, by virtue of the algorithm itself, but being
simpler than the IP forwarding algorithm certainly
helps in speeding up the process.
India, it would perhaps make some sense for only the
large ISPs to deploy MPLS-enabled equipment in the
near short-term, and not necessarily MPLS-ready. Even
then I'd advocate a play of wait-and-watch for sometime.
With VPNs becoming so critical to secure connectivity
access MPLS VPNs might turn out to be a necessity
in large ISP networks, and if properly deployed can
enhance performance to a degree. It is wise to perform
analysis as always before considering any deployment
starting from a detailed lab test.
MPLS features have an impact on performance one way
or the other, and this needs to be studied carefully.
Scalability issues are still being addressed, as are
load-sharing and the all-important security features.
in all, MPLS and its applications have some way to
go, before they can claim domain mindshare. They seem
to be getting there as well. Without doubt, it is
an exciting technology that is being adopted by many
vendors in the IP, Optical and the ATM space. But
for those interested in deployment, it might just
be prudent to be a bit cautious
for now, and save that extra dollar for a feature
that is immediately usable.
tuned, and Happy Networking!! NM - N. Shashi Kiran
works for Nortel Networks at Santa Clara, as a Product
Manager. The views expressed are his own, and not
that of the organization. He can be reached at firstname.lastname@example.org