White Paper

MPLS—An introduction to
multiprotocol label switching
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Basic routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Traditional routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
MPLS traffic engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
MPLS components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Forwarding Equivalence Class (FEC) . . . . . . . . . . . . . . . . . . . . 6
Label Switch Path (LSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Label Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Label Distribution Protocol (LDP) . . . . . . . . . . . . . . . . . . . . . . 6
CR-LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Interior Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Border Gateway Protocol (BGP) . . . . . . . . . . . . . . . . . . . . . . . 8
Applications of MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Application 1: MPLS in a provider network . . . . . . . . . . . . . . 8
Application 2: MPLS over ATM VCs . . . . . . . . . . . . . . . . . . . . . 9
Future applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Online Comments and Suggestions

Click anywhere in this box to visit our online ‘Reader
Response’ form to comment on this document.

Find Out about Our Other Products

Click anywhere in this box to get on the mailing list
for brochures, planning guides & other information.
Introduction
With the exponential growth of the
Internet over the last few years, tech-
nology has had to adapt constantly to
new demands for increased bandwidth.
In addition, the Internet will continue
to see dramatic growth due to the ever-
increasing demand for more bandwidth
to the home, with projections of every
household having broadband access in
the future.
With over 250 million new users
projected in the next decade and with
the implementation of Internet protocol
version 6 (IPv6), carriers and service
providers struggle to scale their current
infrastructures for the inevitable demand
on their networks.
In order to meet the growing demand
for bandwidth, Internet service providers
(ISPs) need higher performance switching
and routing products. Although most
carrier and service provider core
networks run on impressive asynchro-
nous transfer mode (ATM) backbones,
most connections to these providers
continue to be slow frame relay and
point-to-point connections, introducing
latency and sometimes bottlenecks at
the edge access points. Core network
routers also contribute to latencies, as
each must make its own individual
decision on the best way to forward each
incoming packet. Traditionally, IP has
been routed over ATM using IP over
ATM via virtual circuits (VCs) or multi-
protocol over ATM (MPOA). These
forwarding methods proved to be
A D
S0
S2 C S0
B S3 S1
S0
Figure 1. Traditional routing example
cumbersome and complicated. The need
for a simpler forwarding method—one
with the traffic management features
and performance of traditional switches
combined with the forwarding intelli-
gence of a router—is definitely felt.
All of these needs can be met with
multiprotocol label switching (MPLS),
because it integrates the key features of
both Layer 2 and Layer 3. Most impor-
tantly, it is not limited to any Layer 2
or Layer 3 protocol. In particular,
MPLS has several applications and can
be extended across multiple product
segments (such as an MPLS router, an
IP services switch/router, a multiservice
switch, an Optical Ethernet switch, as
well as optical switches).
Basic routing
Traditional routing
In traditional routing environments, a
packet is forwarded through a network
on a hop-by-hop basis using interior
S1 S0
S0
F
E S1
S1 S0
gateway protocols (IGPs), such as routing
information protocol (RIP) and open
shortest path first (OSPF), or exterior
gateway protocol (EGPs) such as border
gateway protocol (BGP). This is done
by referencing the destination Layer 3
addresses against a routing table for a
next hop entry. To clarify, each router
that a packet traverses must do a route
lookup, based on that destination Layer 3
address in the IP header. This must be
performed to determine the packet’s
next hop in its path to get it to its final
destination. The Layer 2 destination
address is then replaced with the address
of the next hop’s Layer 2 address, and the
source Layer 2 address is then replaced
with the Layer 2 address of the current
router, leaving the source and destina-
tion Layer 3 addresses in place for the
next hop to perform its own route lookup
on the packet. This process must be
repeated at each hop to deliver the
packet to its final destination. In Figure
1, to forward packets to Router F,
Router C will reference only the desti-
3
nation address of Router F. Router C
will then determine the best route
based on the attributes that are defined
for that particular IGP. If the router is
using RIP, the lowest sum of all hops to
the destination is preferred as the best
path, as long as the total number of
hops does not exceed 15. If the IGP is
OSPF, the total cumulative cost (i.e.,
metric, usually based on bandwidth) to
a destination is referenced, and the
lowest total cost of all links is preferred.
Running IGPs such as RIP and OSPF
have provided scalable solutions, but fall
short when introducing the need for
inter-AS (autonomous system) routing,
network management, traffic engineering,
and scalable IP services. To reference
Figure 1 again, in traditional routing
environments, Router C must make its
forwarding decisions for packets destined
to Router F based on the metrics defined
by the IGP being implemented. If OSPF,
the metric can be based on various
criteria, although bandwidth is usually
the one used. RIP, on the other hand
uses a metric based on hop count and
drops packets after 15 hops. As seen in
Figure 1, all packets coming from
Router A or B destined for Router F
will be forwarded in the same way, along
the path with the preferred metric.
Therefore, if the path to Router F via
Router D is a higher bandwidth—such
as two DS-3s—and the path via Router
E was connected through T-1s, the path
via Router D would be the only one
used unless a network failure occurred.
4
MPLS traffic engineering
In contrast, MPLS is a method of
forwarding packets at a high rate of speed.
It combines the speed and performance
of Layer 2 with the scalability and IP
intelligence of Layer 3. Routers on the
edge of the network (label edge routers
[LERs]) attach labels to packets based
on a forwarding equivalence class (FEC).
Packets would then be forwarded through
the MPLS network, based on their
associated FECs, through swapping the
labels by routers or switches in the core
of the network called label switch
routers (LSRs) to their destination.
The most important idea is that
by adding a simple label, the LSR
is able to switch a packet much
more efficiently, due to a simple
forwarding element, in contrast
to the hop-by-by basis used in
traditional routing.
A label is usually a locally significant,
condensed view of the IP header, which is
bound to a FEC (such as a given IP
prefix) that is then referenced against a
table of incoming labels to outgoing
labels and interface mappings called
the label information base (LIB). The
label itself represents the particular
FEC to which it was mapped. By refer-
encing an LIB, the true strengths of
MPLS traffic engineering capabilities
become quite apparent. When an LSR
or LER constructs its LIB, explicit control
can be used to direct a packets route
through a network.
The true strength of the MPLS
forwarding algorithm is that analysis of
the IP packet header only needs to be
done once, at the ingress of the MPLS
domain by an LER. Once a packet has
been assigned to a FEC, forwarding of
the packet can be done solely on the
labels used by the particular label switch
path (LSP).
In Figure 2, we see that by using MPLS,
we have granular control over a packet’s
path. Packets destined to Router F
sourcing from Router A follow the solid
green LSP. Packets originating from
Router B will be forwarded along the
dotted red LSP. This is accomplished
by referencing incoming labels to the
LIB in order to attain the value of the
outgoing label and the outgoing inter-
face. Table A is an example of a router’s
LIB. Packets destined for a FEC off
Router F will arrive at Router C on
interface S2 with a label of 50. They
will be referenced against an LIB to
ascertain a forwarding decision. Based
on the LIB, packets with a label value
of 50 arriving on interface S2 will be
swapped for a label with a value of 12
and be switched out interface S0.
The strength of controlling traffic
patterns quickly becomes apparent
when compared to traditional IGPs
(such as OSPF), which forward packets
 A D
S0
S2 C S0
S3 S1
B E
S0
Figure 2. MPLS traffic engineering example
Table A. Router C’s LIB
Interface IN Label In Destination
S2 50
S3 45
based on the destination Layer 3
address only. Most OSPF network
designs with multiple paths to the same
destination use only the route with the
lowest accumulative cost.
MPLS components
MPLS employs many new enhancements
to IP routing in the forwarding of
packets. Many of these enhancements
are similar to traffic engineering and
quality of service (QoS) techniques
employed in ATM. Other components
of the MPLS protocol enable it to
S1 S0
S0 F control components are separate. The
S1
S1 S0
Exit Interface Label Out
F S0 12
F S1 98
function at a higher degree of perform-
ance and intelligence than current
technologies. It also provides a more
efficient manner of forwarding packets
from source to destination than the
hop-by-hop basis used in traditional
routing, as described earlier. Many of
its components are simply extensions
of already existing technologies—such
as the extensions added to existing
routing protocols, which will be described
in further detail later in this document.
Additionally, LSR/LER functionality
can be added to ATM or optical switches
simply by upgrading software.
An additional benefit that MPLS provides
is that upgrades to the protocol can be
done easily because the forwarding and
forwarding component is responsible
for transporting a packet based on a
routing table. The control component
is responsible for the construction and
maintenance of the route table, as well
as working with the control components
of other nodes to disseminate routing
information. We will discuss each of
these in greater detail as we continue
through the components section.
Label
The label is a condensed view of the
header of an IP packet, although
contained within it is all of the infor-
mation needed to forward the packet
from source to destination. Unlike the
IP header, it does not contain an IP
address, but rather a numerical value
agreed upon by two MPLS nodes to
signify a connection along an LSP. The
label is a short, fixed-length, physically
contiguous identifier which is used to
identify a FEC, usually of local signifi-
cance. A packet assigned to a given FEC
is usually based on its destination address,
either partially or completely. The label,
which is put on a particular packet,
represents the FEC to which that packet
is assigned.
Within some transport mediums, there
are existing labels that can be used by
MPLS nodes when making forwarding
decisions, such as ATM’s virtual path
5
identifier/virtual circuit identifier
(VPI/VCI) field and frame relay’s data
link connection identifier (DLCI). Other
technologies, such as Ethernet and
point-to-point links, must use what is
called a shim label, shown in Figure 3.
The shim label is a 32-bit, locally signifi-
cant identifier used to identify a FEC.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | EXP | S | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+
Label (20)—A locally significant ID used to represent a particular FEC during the forwarding process.
EXP (3)—Previously called class of service (CoS), it is now considered an experimental range. Currently, this field
is being considered for QoS implementations.
S (1)—Used to signify if label stack is present. If the label is the only one present or at the bottom of the stack, the
bit will be a value of zero.

TTL (8)—Field used to signify the number of MPLS nodes that a packet has traversed to reach its destination. The
Forwarding Equivalence value is copied from the packet header and copied back to the IP packet header when it emerges from the LSP.

Class (FEC)
A FEC can be thought of as any set of
packets that are forwarded in the same
way through a network. A FEC can
include all packets whose destination
address matches a particular IP
network prefix, or packets that belong
to a particular application between a
source and destination computer. FECs
are usually built through information
learned through an IGP, such as OSPF
or intermediate system to intermediate
system (IS-IS).
Label Switch Path (LSP)
The LSP is essentially the predetermined
route that a set of packets bound to a
FEC traverse through an MPLS network
to reach their destination. Each LSP is
unidirectional; therefore, return traffic
must use a separate LSP.
Figure 3. Shim label alignments
topmost label is swapped. The labels are
organized in a last-in, first-out manner.
In other words, the topmost label signi-
fies the highest LSP, and each successive
label signifies the next lowest LSP.
Label Distribution Protocol (LDP)
In order for an LSR to swap the label
on an incoming packet and forward it
to its downstream peer, it must have a
method of learning what label value
its downstream peers are expecting.
Currently, several protocols can be used
for the distribution of labels betweeen
LSR peers, such as LDP, constraint-
based routed-label distribution protocol
(CR-LDP), resource reservation protocol
(RSVP), and BGP.
ular network. The LDP was designed
solely for this use, but LDP alone cannot
meet QoS needs. In order to support
QoS applications, an LDP must be
able to properly select and reserve
network resources along an LSP. In
order to support this, one can either
use an existing protocol used for
resource reservation and extend it for
label distribution, or take a protocol
that can be used for label distribution
and extend it to support resource reser-
vation. An example of a protocol that
already supports this type of reserva-
tion is resource reservation protocol
(RSVP). An example of distribution
protocols that can be extended to
reserve, resources are LDP and BGP.

Label Stack
By placing multiple labels onto a packet,
MPLS can support a hierarchal routing
design. The set of labels attached to a
packet is called the label stack. As the
packet traverses the network, only the
6
The MPLS architecture RFC 3031
does not specify that any one protocol
should be used for the distribution of
labels between LSR peers. In fact, the
protocol used should depend on what
requirements must be met by a partic-
The LDP Specification Internet Draft
defines LDP as the set of procedures
and messages by which LSRs establish
LSPs through a network by mapping
network-layer routing information
directly to data-link layer switched paths.
However, as these LSPs are built, there
is also a need to ensure that they can
support CoS and traffic engineering
requirements. In addition, there are some
cases where there is a need for a method
of creating explicitly routed LSPs through
an MPLS domain. As stated before,
LDP alone cannot support this, so it
has been extended to support constraint-
based routing (CR-LDP). CR-LDP is
not alone in offering this functionality;
RSVP is another protocol (more fully
discussed in section 3.4.2) that provides
many of the same benefits of CR-LDP
but with traffic engineering extensions;
i.e., RSVP-TE (traffic engineering).
The following descriptions are given so
that a high level understating can be
gained about how each signaling protocol
performs to attain the same end result.
A more detailed description of each is
beyond the scope of this document.
What is important is to gain an under-
standing of some of the nuances of each.
CR-LDP
Constraint-based routed LDP is one
method of establishing point-to-point
LSPs and QoS in MPLS. These attrib-
utes are particularly useful when
attempting to engineer links over the
public Internet or when setting up a
virtual private network (VPN). CR-LDP
allows for explicit routes, using both strict
and loose hops, providing maximum
flexibility in building a specific path
through a network. Some of the appeal
to CR-LDP is that its version of QoS
is similar to the rock-solid technology
of ATM. It also has the ability to allocate communicates with two basic types of
bandwidth based on an LSP’s priority messages, PATH and RESV. PATH
(ranging from 0-7) and/or its age. messages flow from a sender to one or
Capabilities of CR-LDP include: multiple receivers. Upon receipt of a
PATH message, a receiver can send an
1. Remains in a hard state and can be
RESV message in return. The label
thought of as a nailed-up connection.
itself is carried within the RESV message.
2. Has both explicit setup and explicit Figure 5 shows an example of a down-
teardown. stream allocation mapping of labels.
Label distribution flows in the opposite
3. Needs no refresh; once up, it stays
direction of the LSP flow. In other
up until torn down.
words, the label bound to a FEC is
4. Provides a neighbor discovery mech- received from its downstream neighbor.
anism by multicasting hello messages
LSP Path
as a user datagram protocol (UDP) FEC 1
packet to the LDP port at the “all
routers on this subnet” multicast
group address to find all directly RESV, Label 92 RESV, Label 44 RESV, Label 23
connected LSRs [1].
Figure 5. Label request for FEC 1
5. CR-LDP is an extension on an already
via RSVP-TE
existing and running protocol, LDP.
Label Req Label Req Label Req
FEC 1
RSVP-TE:
1. Remains in a soft state, requiring
Label Map 92 Label Map 44 Label Map 23
the retransmission of refresh messages
in order to maintain an LSP.
Figure 4. Label request for FEC 1
2. Provides downstream-on-demand
via CR-LDP
label distribution.
3. Reserves network resources for
RSVP-TE
explicit LSPs.
RSVP is another similar method of
4. Uses IP datagrams to transport
establishing a point-to-point LSP that
messages between peers instead of
meets QoS requirements for MPLS. It
using TCP and, therefore, must
is an extension of the original RSVP
handle the loss of distribution
protocol, with new capabilities to
messages itself.
support an MPLS domain [5]. RSVP
7

Interior Gateway Protocol
IGPs are routing protocols used within
an autonomous system (AS) to provide
intra-AS routing. Most interior routing
protocols used today fall under two
different models, distance vector and
link state. The details of these models
are beyond the scope of this document.
In production environments, link state
algorithms are usually preferred for
their resiliency, scalability, and built-in
intelligence. Common link state proto-
cols are OSPF and IS-IS. For MPLS
environments, typical link state routing
protocols are being extended to support
the construction of LSPs that meet
specific QoS requirements. An example
is OSPF-TE, where LSA Type-10 will
support additional information
required for QoS uses.
While these extensions are being used
for traffic engineering, it is important
to note that IGPs are used for providing
a next hop label forwarding entry
(NHLFE). The NHLFE is used when
forwarding a labeled packet by providing
the packet’s next hop, and carries infor-
mation on what to do with the packet
upon receipt. If the next hop is itself,
the LSR will pop the top level label and
“forward” the resulting packet to itself.
Another forwarding decision will then
be made, based on what remains after
the label stacked is popped. At this point,
the packet may still be labeled, or it may
be a native IP packet. If it is a native
IP packet, the LER will then make a
forwarding decision based on its IGP.
8
Border Gateway Protocol (BGP)
BGP is a routing protocol usually used
between autonomous systems (AS) to
provide inter-AS routing. It is currently
widely deployed to interconnect large
provider networks into what we call
the Internet. In MPLS, BGP can also
be used to distribute label-binding
information for each route it advertises.
This is made possible by the multipro-
tocol extensions (MPEs) to BGPv4. A
label for a route can be piggybacked
within the same UPDATE message used
to advertise it to its peer. The label and
any related information is carried as
part of the network layer reachability
information (NLRI).
Applications of MPLS
This document presents several possible
scenarios of MPLS in different networks.
The goal of the following sections is to
provide a high-level overview of some
possibilities of using MPLS. These are
not the only ways to use MPLS. In
fact, implementations of MPLS are
limited not by the protocol itself, as it
can be used to offer circuit emulation,
Internet connectivity, IP/VPNs, and
QoS for IP—and much more. We will
briefly touch on some applications to
give examples of how versatile the
protocol is.
Customer A
ISP 1
ISP 2
MPLS
Network
Customer B
Figure 6. Provider network
Application 1: MPLS in a
provider network
There are several implementations
within service provider and carrier
networks where MPLS can be used to
offer more services. MPLS can be used
in conjunction with BGP for scalable
inter-AS routing, by alleviating the
need for internal AS routers to receive
BGP routes as long as they support
MPLS [2]. This allows more control
over the path in which transit traffic
flows through a provider’s network
through explicitly routed LSPs to mini-
mize underutilized links. This decreases
the possible load placed on network
resources.
Another benefit an MPLS implementa-
tion provides is the ability for service
providers and carriers to provide network-
based VPNs, a service that can give
companies an alternative to expensive
private leased line networks with an
inexpensive solution of “tunnels” through
a provider’s network emulating the
leased line network. VPNs also conserve
public IP addresses by allowing private
network addresses to traverse the
Internet while encapsulating a private
IP address link within a virtual tunnel.
ATM Network
Figure 7. IP over ATM overlay
N(N-1)/2 problem
Application 2: MPLS over
ATM VCs
In traditional networks, IP routing has
been implemented over ATM networks
by creating permanent virtual circuits
(PVCs) between IP hosts. This type of
network design can become complex
very quickly when multiple hosts are
added to the network. For every one
host added there would need to be
N(N-1)/2 (where N is the total number
of nodes) PVCs created to provide a
full mesh to all nodes. Figure 7 shows
that if a provider wanted a network of
four routers, they will need to create
six PVCs to keep a full mesh network.
If four more routers are added, four-
teen more PVCs—a total of twenty—
will be needed to keep the full mesh
environment. With MPLS, IP packets
can be routed directly over the data
link plane, eliminating the need for
explicitly defined PVCs to be built for
each pair of nodes. NHLFEs can be
provided by private network-to-network
interface (PNN) or IGP of choice. This
greatly simplifies future implementations
of MPLS in an ATM environment, as
well as providing a simple migration to
MPLS in the core of an existing ATM
network.
MPLS Domain
ATM Network
Figure 8. MPLS over an existing
ATM network
An added benefit of an MPLS imple-
mentation over an existing ATM
network is that it is not required that
every device in the MPLS domain be an
LER or LSR. MPLS is can be imple-
mented in the same network that is
also simultaneously operating standard
Layer 2 protocols, also known as “ships-
in-the-night.” It also does not impose
additional configuration on non-MPLS
switches [2]. This allows more freedom
when designing and migrating to MPLS
from an existing network infrastructure.
Moreover, ATM switches that currently
offer multi-service features can continue
to provide ATM/FR services as usual
while being migrated to an MPLS
environment.
UBR Traffic
CBR Traffic
Figure 9. MPLS/ATM QoS mapping
MPLS CoS can also be used to imple-
ment ATM’s QoS features, allowing
providers to reliably offer voice and
video services as well as traditional data
transport. Figure 9 shows how voice or
video traffic can be assigned to a certain
CoS, and then mapped as ATM CBR
traffic. Data traffic can be assigned a
default best-effort CoS (usually 0) and
mapped as unspecified bit rate (UBR)
traffic, because it traverses the ATM
network to its final destination. Such
capabilities will be greatly needed, as
companies switch to voice over IP (VoIP)
from traditional public switched tele-
phone networks (PSTNs) and as more
multimedia applications are ported to
the Internet.
Future applications
As we end our examination of present
MPLS applications, we can begin to
see where future evolutions and appli-
9
cations of this technology, primarily
generalized multiprotocol label
switching (GMPLS) (formerly known
as multiprotocol lambda switching
[MPLambdaS]), can carry us. As carrier
grade networks continue to increase in
size and dependability, they also need
to flatten. The ability to collapse their
Layer 1, 2, and 3 networks onto one
platform is becoming increasingly
apparent. MPLS offers the ability to
dynamically transport any Layer 2 or 3
protocol through any MPLS aware
network. GMPLS is the next evolu-
Label, 67
Label, 89
Lbl Stack,
Green/89
Lbl Stack,
Red/89 Lbl Stack,
Blue/89
Label, 89
Label, 52
Figure 10. Example of label stacking
using GMPLS
10
tion, allowing service providers to take
the flexibility of MPLS and apply it to
an optical (and particularly dense wave-
length division multiplexing [DWDM])
framework. A basic overview of this
technology is as follows: instead of an
LER assigning a label to a particular
segment of an LSP from its label infor-
mation database, the optical cross
connect (OXC) will act as a GMPLS
LER. The GMPLS LER will assign an
individual lambda (referred to as a color
or wavelength) to a particular segment
from its wavelength forwarding infor-
mation base. One of the things that will
allow this technology to be scalable with
the Internet is the ability of GMPLS to
provision optical paths using the tech-
niques embedded in MPLS for traffic
engineering and ISIS/OSPF extensions.
This technology is particularly pertinent
now that Layer 2 and 3 networks are
moving towards MPLS. As the protocols
powering all layers of the open systems
interconnection (OSI) model begin to
use similar, if not the same, protocols
many of the complex networking prob-
lems of the past begin to dissolve.
Another approach to solving this problem
is using Ethernet over fiber. While this
solution is solid in the local area network
(LAN) and metropolitan area network
(MAN), its feasibility is limited in the
wide area network (WAN). Carriers
and other WAN players are looking for
more feature ability than traditional
Ethernet gives. The tunneling availabil-
ities of MPLS, as well as the multi-layered
pushing and popping—combined with
the CoS controls contained in higher
layers—allows it to offer a granularity
so far unsurpassed.
MPLS, particularly its applications in the
optical realm (through GMPLS), creates
a protocol scalable in ways unheard of
until now. The technology powering
GMPLS is micro-electric mechanical
systems (MEMS). The ability to use
micro-mirrors to redirect lambdas has
opened the doors to a bandwidth
explosion. One of the limitations that
surfaced with mimetic switching has
turned out to be a positive progression
in the end. Until now, we have always
wanted to see to the bit level within
each box in our network. As of now we
have no way to “see” into light waves
without terminating them in some type
of optical-electrical-optical (OEO) device
which, while necessary in some places,
adds unneeded latency in others. In
getting away from terminating lambdas,
we have had to take a daunting step:
trusting a box in our network to success-
fully switch packets without manage-
ment past the lightwave level. While
this seems to lack some of the redun-
dancy and stability of older technologies,
it more than makes up for that lack
with its scalability and speed. It is also
much less of a concern when we have
fully protected rings and equipment
that can successfully deliver carrier-
grade reliability. This evolution, while
taken in baby steps, will allow us to
eventually have networks that require
much less management and overhead,
allowing for more bandwidth and less
headache.
Summary
MPLS is the natural evolution for
existing networks to provide the neces-
sary capabilities to support the explosive
growth of the Internet, while at the same
time enabling network administrators
to control traffic at a more granular
level. The act of simply swapping a
label instead of referencing an IP header
at each hop provides a more efficient
manner of forwarding packets, which in
turn allows the opportunity for traffic to
be forwarded at tremendous speeds.
Additionally the multiprotocol part of
MPLS allows flexibility on the type of
media used as a transport, be it ATM,
frame relay, gigabit Ethernet, or Packet
over SONET (PoS)—allowing providers
and carriers tremendous opportunities
for expansion.
The protocol is now an official standard
with the tremendous need for its deploy-
ment. Further information on MPLS can
be located at the Internet Engineering
Task Force (IETF) website, where an
established MPLS working group is
developing the protocol for standardi-
zation. The IETF working group
currently has several Internet drafts that
can provide a deeper understanding
of the protocol. “Multiprotocol Label
Switching Architecture” and “A Frame-
work for MPLS” are the best starting
points for a deeper understanding of
the protocol. Each can be found
on the working group’s website at
http://www.ietf.org/html.charters/
mpls-charter.html.
Acronyms
AS—Autonomous System
ATM—Asynchronous Transfer Mode
BGP—Border Gateway Protocol
CoS—Class of Service
CR-LDP—Constraint-based Routing
Label Distribution Protocol
DLCI—Data Link Connection Identifier
DWDM—Dense Wavelength Division
Multiplexing
EGP—Exterior Gateway Protocol
FEC—Forwarding Equivalence Class
FTN—FEC to NHLFE Map
GMPLS—Generalized Multiprotocol
Label Switching
GRE—Generic Route Encapsulation
IETF—Internet Engineering Task Force
IGP—Interior Gateway Protocol
ILM—Incoming Label Map
IP—Internet Protocol
ISP—Internet Service Provider
L2—Layer 2
L3—Layer 3
LAN—Local Area Network
LDP—Label Distribution Protocol
LER—Label Edge Router
LIB—Label Information Base
LSP—Label Switch Path
LSR—Label Switch Router
MAN—Metropolitan Area Network
MEMS—Micro-Electric Mechanical
System
MPE—Multiprotocol Extension
MPLambdaS—Multiprotocol Lambda
Switching
MPLS—Multiprotocol Label
Switching
MPOA—Multiprotocol over ATM
NHLFE—Next Hop Label Forwarding
Entry
NLRI—Network Layer Reachability
Information
OEO—Optical-Electrical-Optical
OSI—Open Systems Interconnection
OSPF—Open Shortest Path First
OXC—Optical Cross-Connect
PNNI—Private Network-to-Network
Interface
PoS—Packet over SONET
PSTN—Public Switched Telephone
Network
PVC—Permanent Virtual Circuit
11
QoS—Quality of Service
RIP—Routing Information Protocol
RSVP—Resource Reservation Protocol
SVC—Switched Virtual Circuit
SVP—Switched Virtual Path
TCP—Transmission Control Protocol
TE—Traffic Engineering
TTL—Time-To-Live
UBR—Unspecified Bit Rate
UDP—User Datagram Protocol
VC—Virtual Circuit
VCI—Virtual Circuit Identifier
VoIP—Voice over IP
VP—Virtual Path
VPI—Virtual Path Identifier
VPN—Virtual Private Network
WAN—Wide Area Network
12
References
1 Andersson et al., “Label Distribution
Protocol Specification,” work in
progress (draft-ietf-mpls-ldp-11),
February 2001.
2 Callon et al., “Framework for
Multiprotocol Label Switching,”
work in progress (draft-ietf-mpls-
framework-05), March 2000.
3 Rosen et al., “Multiprotocol Label
Switching Architecture,” work in
progress (draft-ietf-mpls-arch-07),
January 2001.
4 D. Awduche et al., “Requirements
for Traffic Engineering Over MPLS,”
RFC 2702, September 1999.
5 D. Awduche et al., “Applicability
Statement for Extensions to RSVP
FOR LSP-Tunnels,” work in
progress (draft-ietf-mpls-rsvp-tunnel-
applicability-01), October 2000.
In the United States: In Canada: In Europe: In Asia: In Australia:
Nortel Networks Nortel Networks Limited Nortel Networks Nortel Networks Nortel Networks
4006 Hwy. 54 8200 Dixie Road Maidenhead Office Pk. Singapore Pre Ltd Australia Pty Ltd
P.O. Box 13010 Suite 100 Westacott Way 151 Lorong Chuan 380 St. Kilda Rd.
RTP, NC 27709 Brampton, Ontario Maidenhead Berkshire #02-01 5th/6th Fl.
L6T 5P6 SL6 3QH New Tech Park Melbourne, Victoria
Tel: +44 1628 432 000 Singapore, 556741 3004
Fax: +44 1628 437 666 Tel: 65 287-2877 Tel: 613 9206 4646

Published by:
For more information, contact your Nortel Networks representative. Call 1-800-4 NORTEL
(1-800-466-7835) in North America or 1-506-674-5470 outside North America. Nortel Networks
Marketing Publications
http://www.nortelnetworks.com
© Copyright 2001 Nortel Networks Corporation. Printed in USA, April 2001. Information subject to change. Nortel Networks
Dept. 0526
Corporation reserves the right, without notice, to make changes in equipment design or components as changes in engineering or
manufacturing methods warrant. Nortel Networks and the globemark are trademarks of Nortel Networks Corporation.
P.O. Box 13010
55053.25/04-01 Issue 2 • Printed in USA April 2001 RTP, NC 27709