White Paper

MPLSAn 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, technology has had to adapt constantly to new demands for increased bandwidth. In addition, the Internet will continue to see dramatic growth due to the everincreasing 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 asynchronous 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 multiprotocol over ATM (MPOA). These forwarding methods proved to be

A
S0 S2 S1

D
S0 S0

S0

B
S0

S3

S1 S1

E
S0

S1

Figure 1. Traditional routing example

cumbersome and complicated. The need for a simpler forwarding methodone with the traffic management features and performance of traditional switches combined with the forwarding intelligence of a routeris 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 importantly, 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

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 packets 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 hops 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 destination 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 desti3

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 bandwidthsuch as two DS-3sand 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.

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 packets 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 interface. Table A is an example of a routers 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

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 referencing an LIB, the true strengths of MPLS traffic engineering capabilities

A
S0 S2 S1

D
S0 S0

S0

B
S0

S3

S1 S1

E
S0

S1

Figure 2. MPLS traffic engineering example

An additional benefit that MPLS provides is that upgrades to the protocol can be done easily because the forwarding and control components are separate. The 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.

Table A. Router Cs LIB

Label
Destination Exit Interface Label Out

Interface IN

Label In

S2 S3

50 45

F F

S0 S1

12 98

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

function at a higher degree of performance 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 technologiessuch 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.

The label is a condensed view of the header of an IP packet, although contained within it is all of the information 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 significance. 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 ATMs virtual path
5

identifier/virtual circuit identifier (VPI/VCI) field and frame relays 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 significant 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 value is copied from the packet header and copied back to the IP packet header when it emerges from the LSP.

Forwarding Equivalence 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).

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 signifies 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, constraintbased routed-label distribution protocol (CR-LDP), resource reservation protocol (RSVP), and BGP. 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-

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.

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 reservation. An example of a protocol that already supports this type of reservation is resource reservation protocol (RSVP). An example of distribution protocols that can be extended to reserve, resources are LDP and BGP. 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.

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

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 constraintbased 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 understanding of some of the nuances of each. CR-LDP

of ATM. It also has the ability to allocate bandwidth based on an LSPs priority (ranging from 0-7) and/or its age. Capabilities of CR-LDP include: 1. Remains in a hard state and can be thought of as a nailed-up connection. 2. Has both explicit setup and explicit teardown. 3. Needs no refresh; once up, it stays up until torn down. 4. Provides a neighbor discovery mechanism by multicasting hello messages as a user datagram protocol (UDP) packet to the LDP port at the all routers on this subnet multicast group address to find all directly connected LSRs [1]. 5. CR-LDP is an extension on an already existing and running protocol, LDP.
Label Req Label Req Label Req FEC 1

communicates with two basic types of messages, PATH and RESV. PATH messages flow from a sender to one or multiple receivers. Upon receipt of a PATH message, a receiver can send an RESV message in return. The label itself is carried within the RESV message. Figure 5 shows an example of a downstream allocation mapping of labels. Label distribution flows in the opposite direction of the LSP flow. In other words, the label bound to a FEC is received from its downstream neighbor.
LSP Path FEC 1

RESV, Label 92

RESV, Label 44

RESV, Label 23

Figure 5. Label request for FEC 1 via RSVP-TE

RSVP-TE:
Label Map 92 Label Map 44 Label Map 23

Constraint-based routed LDP is one method of establishing point-to-point LSPs and QoS in MPLS. These attributes 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

Figure 4. Label request for FEC 1 via CR-LDP

1. Remains in a soft state, requiring the retransmission of refresh messages in order to maintain an LSP. 2. Provides downstream-on-demand label distribution. 3. Reserves network resources for explicit LSPs. 4. Uses IP datagrams to transport messages between peers instead of using TCP and, therefore, must handle the loss of distribution messages itself.
7

RSVP-TE RSVP is another similar method of establishing a point-to-point LSP that meets QoS requirements for MPLS. It is an extension of the original RSVP protocol, with new capabilities to support an MPLS domain [5]. RSVP

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 protocols 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 packets next hop, and carries information 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 multiprotocol 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).

Customer A ISP 2 ISP 1

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 providers network through explicitly routed LSPs to minimize underutilized links. This decreases the possible load placed on network resources. Another benefit an MPLS implementation provides is the ability for service providers and carriers to provide networkbased VPNs, a service that can give companies an alternative to expensive private leased line networks with an inexpensive solution of tunnels through a providers network emulating the leased line network. VPNs also conserve public IP addresses by allowing private

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 IPand much more. We will briefly touch on some applications to give examples of how versatile the protocol is.

network addresses to traverse the Internet while encapsulating a private IP address link within a virtual tunnel.
ATM Network

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

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 Figure 7. IP over ATM overlay N(N-1)/2 problem

ATM Network

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, fourteen more PVCsa 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 Figure 8. MPLS over an existing ATM network

An added benefit of an MPLS implementation 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 implemented in the same network that is also simultaneously operating standard Layer 2 protocols, also known as shipsin-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

MPLS CoS can also be used to implement ATMs 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 telephone 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 appli9

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

tion, allowing service providers to take the flexibility of MPLS and apply it to an optical (and particularly dense wavelength 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 information 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 information 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 techniques 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 problems 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 availabilities of MPLS, as well as the multi-layered

pushing and poppingcombined with the CoS controls contained in higher layersallows 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 successfully switch packets without management past the lightwave level. While this seems to lack some of the redundancy 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 carriergrade reliability. This evolution, while taken in baby steps, will allow us to eventually have networks that require

Lbl Stack, Red/89

Lbl Stack, Blue/89 Label, 89

Label, 52

Figure 10. Example of label stacking using GMPLS

10

much less management and overhead, allowing for more bandwidth and less headache.

the protocol. Each can be found on the working groups website at http://www.ietf.org/html.charters/ mpls-charter.html.

LDPLabel Distribution Protocol LERLabel Edge Router LIBLabel Information Base LSPLabel Switch Path

Summary
MPLS is the natural evolution for existing networks to provide the necessary 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 deployment. 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 standardization. The IETF working group currently has several Internet drafts that can provide a deeper understanding of the protocol. Multiprotocol Label Switching Architecture and A Framework for MPLS are the best starting points for a deeper understanding of

Acronyms
ASAutonomous System ATMAsynchronous Transfer Mode BGPBorder Gateway Protocol CoSClass of Service CR-LDPConstraint-based Routing Label Distribution Protocol DLCIData Link Connection Identifier DWDMDense Wavelength Division Multiplexing EGPExterior Gateway Protocol FECForwarding Equivalence Class FTNFEC to NHLFE Map GMPLSGeneralized Multiprotocol Label Switching GREGeneric Route Encapsulation IETFInternet Engineering Task Force IGPInterior Gateway Protocol ILMIncoming Label Map IPInternet Protocol ISPInternet Service Provider L2Layer 2 L3Layer 3 LANLocal Area Network

LSRLabel Switch Router MANMetropolitan Area Network MEMSMicro-Electric Mechanical System MPEMultiprotocol Extension MPLambdaSMultiprotocol Lambda Switching MPLSMultiprotocol Label Switching MPOAMultiprotocol over ATM NHLFENext Hop Label Forwarding Entry NLRINetwork Layer Reachability Information OEOOptical-Electrical-Optical OSIOpen Systems Interconnection OSPFOpen Shortest Path First OXCOptical Cross-Connect PNNIPrivate Network-to-Network Interface PoSPacket over SONET PSTNPublic Switched Telephone Network PVCPermanent Virtual Circuit
11

QoSQuality of Service RIPRouting Information Protocol RSVPResource Reservation Protocol SVCSwitched Virtual Circuit SVPSwitched Virtual Path TCPTransmission Control Protocol TETraffic Engineering TTLTime-To-Live UBRUnspecified Bit Rate UDPUser Datagram Protocol VCVirtual Circuit VCIVirtual Circuit Identifier VoIPVoice over IP VPVirtual Path VPIVirtual Path Identifier VPNVirtual Private Network WANWide Area Network

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-mplsframework-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-tunnelapplicability-01), October 2000.

12

In the United States:

In Canada:

In Europe:

In Asia:

In Australia:

Nortel Networks 4006 Hwy. 54 P.O. Box 13010 RTP, NC 27709

Nortel Networks Limited 8200 Dixie Road Suite 100 Brampton, Ontario L6T 5P6

Nortel Networks Maidenhead Office Pk. Westacott Way Maidenhead Berkshire SL6 3QH Tel: +44 1628 432 000 Fax: +44 1628 437 666

Nortel Networks Singapore Pre Ltd 151 Lorong Chuan #02-01 New Tech Park Singapore, 556741 Tel: 65 287-2877
Published by:

Nortel Networks Australia Pty Ltd 380 St. Kilda Rd. 5th/6th Fl. Melbourne, Victoria 3004 Tel: 613 9206 4646

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 Dept. 0526 P.O. Box 13010 RTP, NC 27709

http://www.nortelnetworks.com
Copyright 2001 Nortel Networks Corporation. Printed in USA, April 2001. Information subject to change. Nortel Networks 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. 55053.25/04-01 Issue 2 Printed in USA April 2001