Multi Protocol Label Switching (MPLS) - · PDF fileMulti Protocol Label Switching (MPLS) Author: Sami Uskela, 44362U, [email protected]

Multi Protocol Label Switching (MPLS)

Author:

Sami Uskela, 44362U, [email protected]

mailto:[email protected]

HELSINKI UNIVERSITY OF TECHNOLOGY T-109.509 Seminar on Telecom Business I I

Sami Uskela, 44362u 21 November 2002 EXECUTIVE SUMMARY

Currently all communication services are migrating to IP based networks, which generates new requirements for the technology. As mission-critical data is carried over multipurpose networks, the performance and availability of the communication services become pivotal. Simultaneously, the IP network architectures become more complex and demanding to manage.

The Multiprotocol Label Switching (MPLS) technology have emerged as the answer to the management challenges of the carrier class IP networks. In MPLS networks, the packets are labeled on the edge of the network and they are routed through the network based on simple labels. This enables explicit routing and differentiated treatment of the packets while keeping the core routers simple.

Despite the fact that MPLS development started with goal to expedite packet forwarding, the main benefit from MPLS in current network environment becomes from its traffic engineering capabilities. The ability of MPLS to provide constraint-routed LSPs across MPLS domain enables sophisticated load balancing, QoS, and VPN deployments over single multipurpose network.

The main benefits, which the MPLS provides for the network operator, are:

• Flexible support for all (current and forthcoming) services over single network

• Simplified network topology and configuration compared to IP over ATM solution

• Support for any Layer 2 technology under MPLS network

• Powerful traffic engineering tools including constraint-based routing and protection switching

In short, the MPLS allows operator to provide flexible services, utilize their network better, and simplify network architecture all at the same time.

The MPLS based networks are currently deployed by most of the major network operators and they provide globally MPLS based services, such as VPNs. This is enabled by all major networking equipment vendors having solid lineup of MPLS enabled routers and switches, and by software houses providing network planning, management, and monitoring tools for MPLS networks.

The future of the MPLS looks bright: It is already here and it provides currently only viable solution combining traffic engineering capabilities of ATM and Frame Relay to viable wire-speed forwarding with ever increasing line speeds. Moreover, work is ongoing with Generalized MPLS (GMPLS) that will enable MPLS over DWDM architecture without any intermediate layers.

HELSINKI UNIVERSITY OF TECHNOLOGY T-109.509 Seminar on Telecom Business I II

Sami Uskela, 44362u 21 November 2002 TABLE OF CONTENTS

Executive Summary ................................................................................................................................ I Table of Contents................................................................................................................................... II List of Figures ....................................................................................................................................... III List of Tables......................................................................................................................................... III Appreviations ........................................................................................................................................ III 1 Introduction .................................................................................................................................... 1 2 MPLS Techonology Overview........................................................................................................ 2

2.1 Basics ...................................................................................................................................... 2 2.1.1 Forwarding Equivalence Class......................................................................................... 2 2.1.2 Label Switching ................................................................................................................ 2 2.1.3 MPLS Header................................................................................................................... 3 2.1.4 MPLS Network Topology.................................................................................................. 3 2.1.5 MPLS Node Architecture.................................................................................................. 4

2.2 MPLS Forwarding Plane.......................................................................................................... 5 2.2.1 Journey of an IP Packet through a MPLS domain ........................................................... 5 2.2.2 Penultimate Hop Popping................................................................................................. 6 2.2.3 Label Stacking.................................................................................................................. 7

2.3 MPLS Control Plane ................................................................................................................ 8 2.3.1 Off-Line Path Calculation ................................................................................................. 9 2.3.2 Constraint-Based Routing ................................................................................................ 9 2.3.3 MPLS Signaling Protocols.............................................................................................. 10

3 MPLS Enabled Services .............................................................................................................. 11 3.1 Traffic Engineering ................................................................................................................ 11

3.1.1 Traffic Engineering in MPLS Domain ............................................................................. 12 3.2 Resilience .............................................................................................................................. 12

3.2.1 Protection Switching in MPLS Domain........................................................................... 13 3.3 QoS ....................................................................................................................................... 14

3.3.1 DiffServ and MPLS together........................................................................................... 15 3.4 Virtual Private Networks ........................................................................................................ 15

4 MPLS Implementation Status....................................................................................................... 16 4.1 Vendor Implementations........................................................................................................ 16 4.2 Operator Deployments .......................................................................................................... 17

5 Conclusions.................................................................................................................................. 17 6 References................................................................................................................................... 18

HELSINKI UNIVERSITY OF TECHNOLOGY T-109.509 Seminar on Telecom Business I III

Sami Uskela, 44362u 21 November 2002 LIST OF FIGURES

Figure 1: MPLS Header Structure (Adapted from Alwayn 2001) ................................................................3 Figure 2: MPLS Network Topology .............................................................................................................3 Figure 3: MPLS Node Architecture (adapted from Alwayn 2001) ...............................................................4 Figure 4: Example MPLS Domain Configuration ........................................................................................5 Figure 5: Journey of an IP Packet in MPLS Domain...................................................................................6 Figure 6: Journey of an IP Packet in MPLS Domain with penultimate hop popping...................................7 Figure 7: MPLS Label Stacking Example ...................................................................................................7 Figure 8: Journey of an IP Packet in MPLS Domain with label Stacking....................................................8 Figure 9: Traffic Engineering Process Model (adopted from Awduche 1999)...........................................11 Figure 10: Network Topology for Protection Switching Example ..............................................................13 Figure 11: MPLS VPN...............................................................................................................................15 LIST OF TABLES

Table 1: MPLS Header Fields.....................................................................................................................3 Table 2: Label Actions (adopted from Alwayn 2001) ..................................................................................5 Table 3: Example LFIBs..............................................................................................................................5 Table 4: LFIB of LSR D with Penultimate Hop Popping..............................................................................7 APPREVIATIONS

ATM Asynchronous Transfer Mode BA Behavior Aggregate BGP Border Gateway Protocol CoS Class of Service CR-LDP Constrained Routing with Label Distribution Protocol DiffServ Differentiated Services DSCP Differentiated Services Code Point E-LSP EXP-Inferred-PSC LSPs FEC Forwarding Equivalence Class FIB Forwarding Information Base GRE Generic Routing Protocol IGP Interior Gateway Protocol IP Internet Protocol IPSec IP Security ISP Internet Service Provider L2TP Layer 2 Tunneling Protocol LDP Label Distribution Protocol LFIB Label Forwarding Information Base LIB Label Information Base L-LSP Label-Only-Inferred-PSC LSPs LSP Label-Switched Path LSR Label Switching Router MPLS Multi Protocol Label Switching PPTP Point-to-Point Tunneling Protocol QoS Quality of Service RFC Request For Comments RSVP Resource Reservation Protocol SLA Service Level Agreement TED Traffic Engineering Database VPN Virtual Private Network

HELSINKI UNIVERSITY OF TECHNOLOGY T-109.509 Seminar on Telecom Business I 1 (19)

Sami Uskela, 44362u 21 November 2002 1 INTRODUCTION

Currently all communication services are migrating to IP based networks, which generates new requirements for the technology. As mission-critical data is carried over multipurpose networks, the performance and availability of the communication services become pivotal. Simultaneously, the IP network architectures become more complex and demanding to manage.

The users of IP network services want virtual private networks, single network connection for public and private services, immediate access to any new services, reliability of the services, predictable service performance, varying degree of privacy and security, and all this with low cost.

On the other hand, service providers want an infrastructure that provides similar performance, QoS, and traffic engineering than ATM, while providing flexible support for wide range of service models. The service providers want to provide all services over single multipurpose core to simplify the network architecture, exploit economies of scale, simplify operations, and rapidly provision new services.

Matching the needs of users and aims of service providers with conventional IP network architectures is challenging. IP routing alone do not provide sufficient support for path protection or traffic engineering and providing VPNs or QoS is complex in pure IP networks.

To overcome the shortcomings of IP networking, many service providers have deployed IP over ATM infrastructure. The ATM layer is used to provide VPNs, path protection, QoS, and traffic engineering. However, there are challenges also in running the IP over ATM architecture: The IP and ATM layers of the network have orthogonal addressing schemes, which makes the IP overlay completely isolated from ATM layer. This leads into serious scaling problems in ATM path provision (PVC configuration) and handling the huge number of peer routers in routing protocols. Moreover, the ATM does not seem to be able to support high-speed interfaces.

The Multiprotocol Label Switching (MPLS) is seen as solution for ATM scaling problem. MPLS is said to provide support for path protection, VPNs, QoS, and traffic routing and simultaneously providing single addressing and control scheme for whole network. MPLS provides protocol and technology agnostic layer between the Layer 2 and Layer 3 technologies.

While original aim of the precursors1 of the MPLS was to speed up the forwarding plane of the routers, current IP routers can perform wire speed conventional IP forwarding up to OC-192/STM-64 speeds (ca. 10 Gbps). Thus, MPLS is not needed for speeding up IP forwarding, but the motivation of MPLS deployments are elsewhere.

In this paper, we give a short introduction to the MPLS technology, describe the network services that the MPLS enables, discuss the implementation status of the MPLS, and give a glance to the future of the MPLS. We assume that the reader has basic understanding of conventional IP routing.

The scope of this paper is limited to basic MPLS functionality; we do not dig into the details of using MPLS over different Layer 2 technologies, such as ATM, Frame Relay, or SDH. All of them have own optimizations and tricks, but those are not relevant for understanding the fundamentals of MPLS.

1 Cisco’s TAG switching and Ipsilon’s (aquired by Nokia) IP switching were basis for MPLS


Sami Uskela, 44362u 21 November 2002

The rest of this paper is organized as follows: In chapter 2, we describe the basis of the MPLS technology. In chapter 3, we discuss the services enabled by MPSL and in chapter 4, we review the implementation status of MPLS. Finally, in chapter 5, we conclude the most important issues and give a glance to the future of the MPLS.

2 MPLS TECHONOLOGY OVERVIEW

2.1 Basics

2.1.1 Forwarding Equivalence Class

The Forwarding Equivalence Class (FEC) is defined in RFC3031 as

“a group of IP packets which are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment)”.

In other words, all IP packets that are forwarded over the same path and treated in the same manner (e.g., put into the same outgoing queue) belong to the same FEC.

The granularity of FECs within a router can be vary from very coarse to extremely fine depending on the level of information used in assigning IP packet to a FEC. For instance, an access router serving small network (e.g., ADSL router in home) may have only two FECs:

• FEC 1: All packets whose IP destination address is any of the hosts in the served network

• FEC 2: All packets whose IP destination address is not any of the hosts in the served network

The access router forwards the packets of the FEC 1 to the destination host and the packets of the FEC 2 to the edge router in ISP network. On the other hand, core router in global ISP backbone may have over 100 000 FECs that are determined based on packet source, destination, DSCP, protocol number, etc.

2.1.2 Label Switching

Label switching devices treat packets (or cells) according to short labels assigned to the packets. The switching devices determine where and how the packets shall be forwarded according to table lookups based on simple labels. (Alwayn 2001)

All essential information about the forwarding of the packet is summarized in the label; this information consists of destination address, forwarding precedence, VPN membership, QoS class, and traffic engineered route (Alwayn 2001). In MPLS, the labels are fixed length, unstructured, and have only link local significance (RFC3031).

In conventional IP routing, each router in the network makes independent routing decision for each packet: the router classifies incoming packet to a FEC based on longest match prefix lookup (and possibly also other properties of the packet listed above), maps the FEC to a next hop address, and forwards the packet. When the packet traverses through the network, every router must perform the same steps. (Alwayn 2001)

In MPLS, the FEC for each packet is assigned only once; i.e., when the packet enters to the network. The assigned FEC is encoded to a MPLS label that is attached to the packet, when it is forwarded to the next hop. After the packet is assigned to a FIC, the header



information of the packet is not analyzed anymore at subsequent hops; the packet is forwarded solely based on the label, which is used as an index in table lookups that specify the packet treatment.

2.1.3 MPLS Header

The MPLS label assigned to the IP packet is carried inside MPLS header that is transmitted together with the IP packet. The MPLS header is inserted in between the IP Packet (including IP headers) and L2 hearer as shown in Figure 1. The MPLS header contains four fields, which are shortly explained in Table 1. (RFC3032)

SLabel (20 bits) CoS TTL (8 bits)

L2 Header MPLS Header IP Packet

Figure 1: MPLS Header Structure (Adapted from Alwayn 2001)

Table 1: MPLS Header Fields

Field Length Explanation Label 20 bits The actual value of the MPLS label assigned to the packet CoS 3 bits Class of Service; indicates the queuing and packet discard

algorithms applied to the packet along its way through network S 1 bit Stack Field; indicates usage of hierarchical label stacking TTL 8 bits Time-To-Live; providers same functionality than TTL of IPv4 or

Hop Limit of IPv6. 2.1.4 MPLS Network Topology

A MPLS domain is “a contiguous set of nodes which operate MPLS routing and forwarding” (RFC 3031). The MPLS domain can be divided into MPLS Core and MPLS Edge. The former consist of nodes neighboring only MPLS capable nodes, while the latter consist of nodes that have both MPLS capable and incapable neighboring nodes. Schematic view of the MPLS domain is illustrated in Figure 2.

MPLS Core

MPLS Edge

Edge LSR

Transit LSR

Edge LSR

Edge LSR

Edge LSR

Ingress

Egress

LSP

Transit LSRTransit LSR

Transit LSR

Transit LSR

MPLS Core

MPLS Edge

Edge LSR

Transit LSR

Edge LSR

Edge LSR

Edge LSR

Ingress

Egress

LSP

Transit LSRTransit LSR

Transit LSR

Transit LSR

Figure 2: MPLS Network Topology

When an IP packet traverses through a MPLS domain, it follows a predetermined route depending on the FEC to which it is assigned when it enters to the domain. The



predetermined route is called Label Switched Path (LSP). LSPs are unidirectional; i.e., two LSPs are needed for duplex communication. (RFC3031)

Nodes capable of running MPLS protocols and of forwarding native IP packets are called Label Switching Routers (LSR). Different LSR roles can be identified according to their location in the topology (Uzé 2001):

• Ingress LSR that process traffic entering to the MPLS domain;

• Transit LSR that process traffic within MPLS domain;

• Egress LSR that process traffic leaving the MPLS domain; and

• Edge LSR that is often used as common name for Ingress and Egress LSRs (e.g., Alwayn 2001; Davie & Rekhter 2000).

Naturally, the same physical LSR node can have any combination of the logical LSR roles described above; e.g., most Edge LSRs are simultaneously Ingress LSR for one set of LSPs and Egress LSR for another set of LSPs.

The MPLS forwarding can be done also by Layer 2 switches that cannot analyze Layer 3 headers. Naturally, the Layer 2 switches can act only as transit devices in MPLS domain. In this paper, we focus only on LSRs as part of the MPLS domain, but in most cases the Transit LSR could be replaced be Layer 2 MPLS switch.

2.1.5 MPLS Node Architecture

Internal structure of a LSR is illustrated in Figure 3. LSRs have two architectural planes: control plane and forwarding plane (Alwayn 2001). As discussed above, LSRs is able to process both conventionally routed IP packets and MPLS routed packets; hence, both the control and forwarding plane of the LSRs consists of separate functionalities for IP routing and MPLS forwarding.

Control Plane

IP Routing Protocols

IP Routing Protocols

Label DistributionProtocol

Label DistributionProtocol

Forwarding Plane

Conventional IP Forwarding

Conventional IP Forwarding

MPLS ForwardingMPLS Forwarding

Incoming IP Packets

Incoming Labeled Packets

Outgoing IP Packets

Outgoing Labeled Packets

Routing InformationExchange

Label BindingInformation Exchange

Figure 3: MPLS Node Architecture (adapted from Alwayn 2001)



The MPLS forwarding plane forwards packets according to labels attached to packets. The MPLS forwarding is based on label switching according to Label Forwarding Information Base (LFIB), which is maintained by the LSR.

The MPLS forwarding can perform different label actions according to the instructions in LFIB; these actions are enumerated in Table 2 (Alwayn 2001).

Table 2: Label Actions (adopted from Alwayn 2001)

Action Description Aggregate Remove top label in the stack and perform conventional IP forwarding Pop Remove top label in the stack transmit the remaining packet either as

MPLS labeled packet or unlabelled IP packet Push Replace the top label in the stack with a set of labels Swap Replace the top label in the stack with another value Untag Remove the top label and forward the IP packet to specified IP next hop

2.2 MPLS Forwarding Plane

2.2.1 Journey of an IP Packet through a MPLS domain

A BC D

E

F

G

130.233.0.0/16

18.0.0.0/8

Figure 4: Example MPLS Domain Configuration

Let’s assume following simplified situation: One network provider connects network domains of Massachusetts Institute of Technology (MIT), i.e., 18.0.0.0/8, and Helsinki University of Technology (HUT), i.e., 130.233.0.0/16. The network provider has deployed MPLS throughout the backbone and the provider has defined that traffic from MIT to HUT should be mapped to LSP that traverses via LSRs A, B, C, D, and E. The topology of the example is depicted in Figure 4 and the relevant part of LFIB of each LSR in the LSP is given in Table 3.

Table 3: Example LFIBs LSR A LSR B

Incoming Prefix

Outgoing Label

Outgoing Interface

Next Hop Address Incoming

Label Outgoing

Label Outgoing Interface

Next Hop Address

130.233.0.0 2 0 B 2 5 1 C

LSR C LSR D Incoming

Label Outgoing


Next Hop Address Incoming

Label Outgoing


Next Hop Address

5 23 0 D 23 4 2 E

LSR E Incoming

Label Outgoing


Next Hop Address

4 - 1 130.233.x.x



Now, let’s see what happens when an IP packet is sent from MIT to HUT; e.g., an Echo Request is sent from 18.181.0.31 (www.mit.edu) to 130.233.220.31 (www.hut.fi). The packet arrives to the MPLS domain of the network provider at LSR A, which is the Ingress LSR.

When the Ingress LSR receives IP packet without any label, its conventional IP forwarding part determines the FEC to which the packet belongs and then the MPLS forwarding part of the LSR assigns correct MPLS label to the packet, constructs MPLS header, and determines the outgoing interface and the next hop address. In this case, the FEC is determined based on the destination prefix; outgoing label 2 is assigned; and the packet is forwarded to LSR B via interface 0.

Next, the packet arrives to LSR B, which is Transit LSR in this case. Since the incoming packet has a MPLS label, the MPLS forwarding part of the Transit LSR processes the packet; the Transit LSR performs label swapping and forwards the packet to the next hop router according to its LFIB. Moreover, the Transit LSR decrement the TTL field of the MPLS header by one. In our example, LSR B maps incoming label 2 to outgoing label 5, swaps the labels, and forwards the packet to LSR C via interface 1.

The LSR C and LSR D are also Transit LSRs for the packet and they perform similar MPLS forwarding procedure as LSR B above. According to their LFIBs the LSR C forwards the packet to LSR D and the LSR D further forwards the packet to LSR E.

Eventually, the packet arrives to LSR E, which is the egress LSR for the packet. The MPLS forwarding part of the Egress LSR lookups the LFIB, which indicates that the MPLS header shall be removed from the packet and conventional IP forwarding shall be applied. The conventional IP forwarding part of Egress LSR forwards the packet to the next hop router according to the FIB.

Figure 5 illustrates the journey of our example IP packet through an MPLS domain. First, The packet enters to the MPLS domain at the Ingress LSR, which pushes label to it. Then, the label attached to the packet is swapped in each LSR. Finally, the packet reaches the Egress LSR, which pops the label and the packet is forwarded towards its destination using conventional IP forwarding.

A B C D E

130.233.220.31

IP Data

5

130.233.220.31

IP Data

5

130.233.220.31

IP Data

23

130.233.220.31

IP Data

23

130.233.220.31

IP Data

2

130.233.220.31

IP Data

2

130.233.220.31

IP Data

4

130.233.220.31

IP Data

4

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

Figure 5: Journey of an IP Packet in MPLS Domain

2.2.2 Penultimate Hop Popping

The simple MPLS forwarding explained above has clear drawback: the Egress LSR (LSR E in this case) must perform double lookup. First the Egress LSR must make table lookup to

http://www.mit.edu/

http://www.hut.fi/



LFIB just to realize that the label must be popped and conventional L3 lookup must be performed to forward the packet to the next hop router. This double lookup can degrade the performance of the Egress LSR and it makes the hardware implementation of MPLS forwarding more complex. (Alwayn 2001)

The double lookup can be avoided with penultimate hop popping procedure, where the Egress LSR requests it’s upstream neighbor (LSR D in our example) to perform label pop operation before forwarding the packet (RFC 3031). Since the penultimate hop LSR pops the label, the Egress LRS receives the unlabelled IP packet and can directly perform L3 lookup based on the destination address of the IP packet.

A B C D E

130.233.220.31

IP Data

5

130.233.220.31

IP Data

23

130.233.220.31

IP Data

2

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

A B C D E

130.233.220.31

IP Data

5

130.233.220.31

IP Data

5

130.233.220.31

IP Data

23

130.233.220.31

IP Data

23

130.233.220.31

IP Data

2

130.233.220.31

IP Data

2

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

Figure 6: Journey of an IP Packet in MPLS Domain with penultimate hop popping

Figure 6 depicts how the journey of an IP packet would look like, if penultimate hop popping would be applied in our example above. Further, Table 4 shows the LFIB of the penultimate LSR, which is LSR D in the example.

Table 4: LFIB of LSR D with Penultimate Hop Popping LSR D

Incoming Label

Outgoing Label

Outgoing Interface

Next Hop Address

23 - 2 E 2.2.3 Label Stacking

Since the MPLS can be used to carry any protocol over the MPLS domain, also MPLS labeled frames (e.g., IP packets) can be carried over MPLS; this is called label stacking. In other words, the label stacking can be seen as “tunneling” of LSP inside another LSP. We will later explain applications for label stacking.

A BC D

E

F

G

130.233.0.0/16

18.0.0.0/8

Figure 7: MPLS Label Stacking Example



To illustrate the label stacking, let’s modify our example and assume that the LSP assigned to the IP packet by LSR A is carried within another LSP from LSR B via LSR C to LSR D as shown in Figure 7. In this configuration, the LSR B becomes the Ingress LSR for the second LSP and the LSR D becomes the Egress LSR for this LSP.

The journey of an IP packet through the MPLS domain in this case is illustrates in Figure 8. In short, the procedure looks like following:

• LSR B pushes new label to the label stack and forwards the packet to LSR C; the Stack field of the new MPLS Header is set 1 to indicate that there are more labels in the stack.

• LSR C acts like Transit LSR in previous example; when there are multiple labels attached to the IP packet, only the topmost label is processed.

• LSR D pops the topmost label from the label stack and processes the remaining MPLS labeling packet; in this case swaps the label and forwards the packet to LSR E

Naturally, the LSR A and LSR E work just like in the previous example. Like careful reader notices, the penultimate hop popping can be used also here to avoid the double lookup in LSR D.

A B C D E

130.233.220.31

IP Data

2

130.233.220.31

IP Data

4

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

2

9

130.233.220.31

IP Data

2

14

A B C D E

130.233.220.31

IP Data

2

130.233.220.31

IP Data

2

130.233.220.31

IP Data

4

130.233.220.31

IP Data

4

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

130.233.220.31

IP Data

2

9

130.233.220.31

IP Data

2

9

130.233.220.31

IP Data

2

14

130.233.220.31

IP Data

2

14

Figure 8: Journey of an IP Packet in MPLS Domain with label Stacking

2.3 MPLS Control Plane

Above, we described that how an IP packet is conveyed over a MPSL domain assuming that the LSRs have all the needed information on labels, FECs, LSPs, etc. in their LFIBs. In this section, we discuss how this information is created and distributed to the LSRs.

The main issues needed to configure the MPLS domain are determining the FECs with desired granularity and determining the physical paths for the LSPs. Two main approaches to MPLS domain configuration are off-line path determination and constraint-based routing (Uzé 2001).

The off-line path determination and constraint-based routing are both control driven methods for creating bindings between labels and FECs, since the LSPs and label bindings are calculated and distributed completely by the control plane of an MPLS domain. The label bindings can also be data driven, when the bindings are created by LRS by reacting



to the forwarded data packets; e.g., when several consecutive packets belonging to the same FEC are forwarded, LSR can create label for the FEC and communicate with neighboring LSRs to inform them about label bindings. (Davie & Rekhter 2000).

The motivation behind data driven binding is speed-up the data forwarding; the other MPLS benefits cannot be exploited in practice with data driven binding. However, the forwarding speed of IP packets is not an issue anymore (Armitage 2000; Uzé 2001); hence, the data driven label binding is not relevant in practice.

2.3.1 Off-Line Path Calculation

The off-line path calculation is performed by specific tool, which can be developed in-house or sourced from third party2, outside of the MPLS domain; i.e., the LSR do not directly participate to the process. (Uzé 2001)

The basic inputs to the tool are ingress and egress points, physical topology, and traffic estimates. Based on the inputs the tool calculates a set of physical paths for LSPs that optimize the usage of the network resources. Any determined physical path is expressed as an explicit route through the MPLS domain.

The off-line path calculation has some distinct benefits:

• It enables global resource optimization;

• It allows predictable LSP routing;

• It provides stable network configuration; and

• It can provide a lot of information to support decision making

The off-line path calculation tools often include possibilities to design the network topologies, analyze traffic load in different scenarios, and simulate different events. The simulations can provide valuable information on, e.g., how the network would behave in case of equipment failure or sudden traffic peak, which is essential in network planning.

2.3.2 Constraint-Based Routing

The constraint-based routing is executed online by Ingress LSRs (RFC 2702). The constraint-based routing allows dynamic and distributed route calculations when needed.

The constraint-based routing process requires following inputs:

• Attributes of the traffic trunks; e.g., bandwidth, priority, …

• Attributes of the links of the network; e.g., bandwidth, cost, …

• Attributes of the LSRs; e.g., capacity, interfaces, …

• Other topology state information

Each LSR determines explicit route for each traffic trunk originating from the LSR based on these information. The explicit route is in practice a LSP that satisfies the requirements of the traffic taking into account the constraints set by available resources.

2 For instance WANDL (http://www.wandl.com/) provides suitable tools

http://www.wandl.com/



Even though it can be shown that the constraint-based routing problem is intractable in general (RFC 2702), very simple heuristics can be used to find feasible constraint-routed paths in all practical situations (Lee, et al. 1995; Uzé 2001):

• Prune resources (links and LSRs) that do not meet the requirements for the LSP

• Run the shortest path first algorithm for the remaining network

• Setup the LSP

These three steps are performed for each LSP in turn from highest priority LSP to lowest priority LSP.

2.3.3 MPLS Signaling Protocols

After the LSP paths are determined, they must be established in the network; that requires a signaling protocol for coordinating the label distribution, explicitly routing the LSPs, reserving required bandwidth, and preventing loops. The MPLS architecture does not assume any single signaling protocol (RFC 3031): three protocols have been specified for label distribution:

• Label Distribution Protocol (LDP),

• Resource Reservation Protocol (RSVP) extensions for MPLS (RSVP-TE), and

• Constrained Routing with LDP (CR-LDP).

LDP (RFC 3036) is suitable for hop-by-hop label distribution, but it always selects the same physical path than conventional IP routing would select. Thus, LDP does not support traffic engineering, which limits the applicability of LDP in real-life deployments (RFC 3037).

RSVP-TE (RFC 3209) is extension of RSVP (RFC 2205) that utilizes the RSVP mechanisms to setup LSPs. RSVP-TE supports explicitly routed LSP paths that do not have to follow conventional IP routing giving support also for traffic engineering (RFC 3210).

Recently, LDP has been extended to support constraint-based routes for LSP setup (RFC 3212) and LSP modification (RFC 3214); the extended LDP is called CR-LDP. The CR-LDP supports traffic engineering and can provide the same functionality than RSVP-TE (RFC 3213).

RSVP-TE can be seen as a “quick-and-dirty” solution for LSP setup problem, which satisfies the requirements for traffic engineering, but has also some drawbacks. Since RSVP-TE is so-called soft-state protocol, it suffers inherent scalability problems when number of LSPs per LSR increases (RFC 2208). Further, RSVP-TE uses unreliable message transport and it may take up to 90 seconds for nodes to realize that signaling message has been lost (Ghanwani 1999).

The drawbacks of RSVP-TE have been addressed in the design of CR-LDP; the signaling messages are transported over reliable TCP and the protocol uses hard-state architecture, which scales better than soft-state approach. Further, CR-LDP supports more versatile label distribution and binding modes than RSVP-TE. (Ghanwani 1999)

Routing loops can be formed into MPLS domain when the network is in transient state, if no countermeasures are applied. Either the control packets or data packets may become



looped (Ohba 1999): In former case, MPLS signaling messages are forwarded in a loop, when the algorithms do not converge. In latter case, the labeled packets are forwarded in the loop until the TTL limit is reached. Fortunately, viable algorithms for MPLS loop prevention have been specified (RFC 3036).

3 MPLS ENABLED SERVICES

3.1 Traffic Engineering

In conceptual level, a network can be said to consist of a demand system (offered traffic), a constraint system (link and node capacities), and a control system (network protocols and processes). The purpose of the traffic engineering is to establish the operating points and parameters for the three systems in an operational context. Thus, the Internet traffic engineering is, in essence, a control problem. (RFC 2702)

In practice, the traffic engineering maps the offered traffic onto the network infrastructure trying to meet the performance objectives set by the network operator. The critical objectives for Today’s commercial IP networks comprise high service quality, efficient usage of resources, resilience, and economy. (Awduche 1999)

Observation of Network State

Formulation of Control Policy

Characterization of traffic and network

state

Optimize Network Performance

Capacity augmentationConfiguration ControlCapacity augmentationConfiguration Control

Capacity PlanningNetwork Design

Network operation control

Capacity PlanningNetwork Design

Network operation control

Performance monitorsFault monitors

Analytical models

Performance monitorsFault monitors

Analytical models

Revise control policy

Performance optimization

Yes

Yes

No

No

Figure 9: Traffic Engineering Process Model (adopted from Awduche 1999)

The process of traffic engineering is illustrated in Figure 9. The desired control policy depends on cost structure, revenue model, operating environment, etc. The monitoring functions of the network feed information to the observation phase, which provides feedback from network state to the process. In next stage, the characteristics of the traffic and network state are analyzed with various qualitative and quantitative methods. In this stage, anomalies and bottlenecks are identified and the results are utilized for network planning, design, and control. In last stage, the network performance is optimized by applying control actions to drive the network to desired state. The control actions may include adding capacity, manipulating traffic paths, etc.

The traffic engineering is continuously on going adaptive process; the process is iterated repeatedly. Thus, in real operational context the process should be as automated as possible.


Sami Uskela, 44362u 21 November 2002 3.1.1 Traffic Engineering in MPLS Domain

Implementing efficient traffic engineering with conventional IP routing is virtually impossible, but MPLS provides good tools traffic engineering. As discussed above, inherent nature of the MPLS supports explicit path management and traffic assignment. In addition, network state information dissemination and network management can be implemented efficiently in MPLS domain.

The LSP routing management capability provided by RSVP-TE and CR-LDP protocols allow performance optimization in operational network in various ways; for example:

• If part of the network is congested, but alternative path have spare capacity, LSPs can be routed around the congested point;

• Multiple LSP paths can be established between two nodes and traffic can be divided across the LSPs; if the LSPs are routed via different physical paths, the load of the network can be balanced

• LSPs can be easily provided with flexible survivability options (which are described in more detail later)

An additional strength of the MPLS is that LSPs can be easily parameterized (e.g., required bandwidth, delay, and protection level) and those parameters can be used to dynamically allocate resources for each LSP. (Awduche 1999)

The flexible control architecture of the MPLS allows individual LSRs initiate traffic-engineering action when needed without risk of loosing the consistency of the network. For instance, Ingress LSR may monitor the traffic entering to a LSP, if it notes significant change in the traffic, it may autonomously adjust the LSP parameters and use RSVP-TE or CR-LDP signaling to find potentially better route to the LSP. (Swallow 1999)

3.2 Resilience

Now, when the mission-critical and real-time traffic have migrated to IP networks, the reliability of the communications has become pivotal. The conventional IP routing protocols are extremely robust and survivable, but it can take long time (up to minutes) to recover from link or router failure (Huang, et al. 2002). The unacceptable downtime before IP routing protocols converge after failure have motivated search for new methods to provide network resilience: MPLS have some inherent characteristics that can be used to protect availability of LSPs (Chen and Oh 1999; Huang, et al. 2002).

The path recovery mechanisms can be classified according to two criteria: recovery by rerouting vs. protection switching and local repair vs. path protection (Huang, et al. 2002).

In recovery by rerouting a new path (or path segments) are established on demand after a fault occurs. On the other hand, protection switching mechanism pre-establishes recovery paths according to the network policies. Protection switching schemes are inherently faster than rerouting schemes, which are again simpler and less resource hungry.

Local repair aims to protect against link or neighbor node failure with minimized amount of time needed for failure propagation and path restoration. Local repair with protection switching tends to be fastest way to recover from failure, but, clearly, it does not scale well. Therefore, local repair is best suited in where certain link or nodes are more prone to failure than rest of the network, when those nodes can be protected.



MPLS path protection aims to protect the whole LSP path from Ingress LSR to Egress LSR from failure of any node or link in the path. The LSR in origin of both the working path and the corresponding recovery path is called Path Switching LSR (PSL). In case of failure, the PSL switches the traffic from failed path the alternative path; the time needed from PSL to detect the failure dictates the time needed for path restoration.

All the protection schemes discussed above can be used in MPLS networks efficiently; especially support the protection switching models is inherent due to flexible management of LSPs. Both RSVP-TE and CR-LDP support nicely setting up alternative routes and protection policies per LSP.

Since supporting protection switching in Layer 3 routed IP networks is practically impossible, operators deploying MPLS based networks have more efficient tools for providing resilient services than those relying solely conventionally routed IP networks.

3.2.1 Protection Switching in MPLS Domain

Next, we illustrate the protection switching implementation in MPLS domain via an example scenario. Figure 10 depicts network topology familiar from our previous examples.

A BC D

E

F

G

130.233.0.0/16

18.0.0.0/8

Figure 10: Network Topology for Protection Switching Example

We want to provide protected path from MIT (18.0.0.0/8) to HUT (130.233.0.0). This time the default path for the LSP from Ingress LSR (LSR A) to Egress LSR (LSR E) goes via LSR F, and LSR C. The alternative path for the LSR goes via LSR B, LSR G, and LSR D. These both paths are setup by either RSVP-TE or CR-LDP.

When, e.g., LSR C fails, the default path of the LSP becomes unavailable and protection switching must be used. First, LSR F notes3 that LSR C is down. Then, LSR F must notify LSR of the failure (e.g., with LDP message). Finally, LSR A switches the traffic of the LSP to the alternative path.

If it is observed that LSR C is more prone to failures that other nodes, specific protection with local repair mechanism can be applied. In this case, an alternative path from LSR F to LSR E via LSR G and LSR D would be prepared. Now, LSR F can switch the traffic to an alternative path immediately after it notes the failure of LSR C, which speeds up the protection.

The network utilization is often sub-optimal after local repair have been applied. Thus, after the immediate availability of the LSP is secured, the LSP can be switched to another, more optimal path from LSR A.

3 This can happen for instance via lower layer notification or hello messages


Sami Uskela, 44362u 21 November 2002 3.3 QoS

First, it has to be noted that MPLS is not complete solution for Internet QoS problem; even tough hearing such a claims is not uncommon (Uzé 2001). On the contrary, the basic MPLS functionality can be seen orthogonal to QoS mechanisms. However, MPLS provides some tools that help network operators to implement QoS aware services.

Before going into the MPLS specific issues, we revisit the big picture of the IP QoS (Xiao & Lionel 1999):

• First, a Service Level Agreement (SLA) must be negotiated between customer and network operator. The SLA specifies the characteristics (bandwidth, delay, jitter, protection level, etc.) of the service that the network operator provides to the customer.

• The customer domain must be able to decide how to the applications and hosts share the services agreed in SLA. This can happen, for instance, by best effort principle or the applications may mark packets with DiffServ Code Points (DSCP)

• Network provider configures the ingress routers of the network according to the SLAs; the configuration includes rules for classification, policing, and remarking the traffic entering to the network. The core routers are unaware of the specific SLAs and edge configurations, they just forward packets according to pre-defined priorities.

• The challenge for the network operator to ensure that all customers get services according to their different SLAs, while utilizing the network resources as efficiently as possible.

As discussed above, MPLS provides convenient traffic engineering tools (such as constraint-based routing and protection switching) for the network operators to optimize the usage of network resources while providing agreed service level to all customers. These tools support viable QoS provisioning in multipurpose networks. The parameters of LSPs can be set according to the SLAs and when constraint-based routing for these LSPs is performed, the requested QoS is automatically provisioned.

The Ingress LSRs map the traffic entering to the LSPs and assign CoS according to priority of the packets and constraints of relevant SLAs. The Ingress LSRs ensure that the traffic entering to the MPLS network complies the agreed specification. Thus, the Transit LSRs do not have to monitor traffic flows. Moreover, if the constraint-based routing has been performed correctly, no congestions should occur in the network.

The MPLS forwarding provides two levels of packet treatment differentiation: Transit LSRs determine the packet treatment based on packet label and CoS field. The label-based differentiation provides means for differentiation between different LSPs, while CoS field can be used to indicate different priority for packets within one LSP.

Even tough MPLS provides good tools for enabling QoS, it is not as such sufficient solution or only solution for QoS in IP networks; similar packet treatment differentiation can be implemented with classical DiffServ (RFC 2475) architecture and constraint-based routing can be applied (in theory) to any network architecture and topology. Moreover, DiffServ or similar packet end-to-end from is still needed to provide application based packet treatment differentiation.


Sami Uskela, 44362u 21 November 2002 3.3.1 DiffServ and MPLS together

In real networks, the QoS support (i.e., differentiated packet treatment) will be implemented with combination of classical DiffServ and MPLS. Therefore, we introduce the solution briefly here.

In DiffServ domain, all incoming IP packets requiring the same treatment constitute a Behavior Aggregate (BA). The Ingress Node of the domain classifies the incoming packets and marks them with a DiffServ Code Point (DSCP) according to the BA allocated to the packets. Each transit router in the DiffServ domain determines the packet treatment required for the packet based on the DSCP. (RFC 2475)

There are remarkable similarities between DiffServ and MPLS domain topologies: in both, the ingress router classifies the incoming packets and marks the packets according to their classification, and the transit router determine the packet treatment according to the marking. Consequently, MPLS based networks provide good tools for implementing DiffServ functionality.

When DiffServ is used in MPLS network, the Ingress LSR must codify the information on incoming packet’s FEC and BA (which is indicated by DSCP) into the MPLS headers. Two codifying strategies are defined: either both the FEC and BA can be expressed in the label or the FEC is expressed in the label and the BA is expressed in the CoS field of the MPLS header. The former method is called Label-Only-Inferred-PSC LSPs (L-LSP) and the latter method is called EXP-Inferred-PSC LSPs (E-LSP). Both L-LSP and E-LSP method can be used simultaneously in one network. (RFC 3270)

The MPLS signaling protocols can be used to determine physical paths and to reserve appropriate resources for the LSPs carrying DiffServ traffic. When the LSPs are setup, the only the Ingress LSR must be aware of the DiffServ BAs, the Transit LSR forward the packets and decide their treatment based on label and CoS without any need to know anything about DiffServ.

3.4 Virtual Private Networks

Site 1

Site 2

Site 3Site 4

Figure 11: MPLS VPN

Virtual Private Network (VPN) services are estimated to be huge market in the future. For instance, Ovum (2002) forecasts that in year 2007 IP VPN services will generate revenue of 32 500 million USD globally and that 1.6 million sites will be interconnected via IP VPNs. Furthermore, Ovum (2002) estimates that (in 2007) 70% of the IP VPN revenues will come from VPN services realized with MPLS technology.



Since the network operator is free to define the criteria how the traffic entering to the MPLS domain is mapped to FECs, MPLS enables flexible VPN services over multipurpose network.

A simple MPLS VPN configuration is depicted in Figure 11: The VPN connects four sites together via a multipurpose MPLS network with a LSP from each site to all the other sites. In case of bigger network with tens of sites, this kind of mesh topology might not scale well and star topology might be better. The Ingress LSRs assign the packets coming from the corporate sites to a LSP going to the destination site and the MPLS forwarding takes case of forwarding the traffic to the right destination.

The inherent strengths of the MPLS VPNs include:

• They can carry any protocol

• They can easily support private address spaces for Intranets (since the IP addresses are not used for routing in the MPLS domain)

• The physical paths of the VPN traffic can be selected freely; e.g., load of the network can be balanced by routing the traffic via several different paths

• The resilience features of MPLS discussed above enable high availability of the VPN services

• The QoS features of MPLS discussed above enable enforcement of customer specific QoS for the VPN

• Low overhead (compared e.g., to IPSEC VPNs)

Since the traffic flowing in the LSPs should not go anywhere else than to its intended destination nor should any other source than the Ingress of the LSP be able to insert data to LSP, the MPLS VPNs provide relatively secure VPN solutions. However, if the enterprise wants to have additional protection of the confidentiality and integrity of the data sent over the VPN, employing IPSEC tunneling on top of MPLS VPN is viable option.

4 MPLS IMPLEMENTATION STATUS

4.1 Vendor Implementations

A recent MPLS interoperability-testing event has proven that all significant network equipment vendors have robust MPLS implementations available in their product portfolio. Moreover, the implementations interoperate together, which is essential for network operators to avoid lock-in to single network gear vendor. The vendors who participated to the event are listed below. (MPLS Forum 2002)

• Agilent Technologies • Alcatel • Avici Systems • Celox Networks • Charlotte's Web Networks • Ericsson • Extreme Networks • Foundry Networks • Ixia • Juniper Networks • Laurel Networks

• Lucent Technologies • Mahi Networks • Marconi • Nettest • Riverstone Networks • Spirent Communications • Tenor Networks • Intel • Unisphere Networks • Vivace Networks



The list above proves that there are plenty of vendors targeting to the MPLS markets. Initially, the MPLS technology will be used mostly in service provider networks. The service provider network markets are dominated by Cisco and Juniper; the former has ca. 2/3 of the markets and the latter 1/3. Thus, it is extremely challenging for any new entrants to penetrate into the service provider router markets. (Gartner 2002a)

Both Cisco and Juniper have solid line-up of MPLS enabled products that support most essential MPLS features including RSVP-TE signaling, LDP signaling, VPNs, Traffic Engineering, etc. Both vendors have core routers that support line rate forwarding (of both MPLS and conventional IP) up to OC-192 (10 Gbps) interfaces with total forwarding capacity of over 300 Gbps per router. (Gartner 2002a)

4.2 Operator Deployments

Several major network operators provide MPLS based services Today; for instance, WorldCom, Equant, Clobal Crossing, AT&T, and BT provide MPLS based VPNs for enterprises. (Gartner 2002b)

However, some operators (like KPNQwest) have opted not to deploy MPLS based equipment. The main reason for deferring MPLS deployments for those operators is abundance of network capacity; operators with plenty of network resources in their disposal do not benefit directly from advanced traffic engineering features of MPLS. (Gartner 2002b)

Furthermore, some operators, for instance Sonera (Hold 2001), have implemented state-of-art IP over ATM networks just few years ago, when they did not consider MPLS mature enough (mainly due to interoperability issues).

The operators with MPLS based networks utilize the inherent features of MPLS to provide end-to-end CoS, performance monitoring, and reporting features for their customers. Further, these operators are capable of offering tiered services for different customer segments. Implementing similar capabilities have proven to be challenging for operators with classical IP over ATM architecture. (Gartner 2002b)

5 CONCLUSIONS

Despite the fact that MPLS development started with goal to expedite packet forwarding, the main benefit from MPLS in current network environment becomes from its traffic engineering capabilities. The ability of MPLS to provide constraint-routed LSPs across MPLS domain enables sophisticated load balancing, QoS, and VPN deployments over single multipurpose network.

The main benefits, which the MPLS provides for the network operator, are:

• Flexible support for all (current and forthcoming) services over single network

• Simplified network topology and configuration compared to IP over ATM solution

• Support for any Layer 2 technology under MPLS network

• Powerful traffic engineering tools including constraint-based routing and protection switching

In short, the MPLS allows operator to provide flexible services, utilize their network better, and simplify network architecture all at the same time.



The MPLS based networks are currently deployed by most of the major network operators and they provide globally MPLS based services, such as VPNs. This is enabled by all major networking equipment vendors having solid lineup of MPLS enabled routers and switches, and by software houses providing network planning, management, and monitoring tools for MPLS networks.

The future of the MPLS looks bright: It is already here and it provides currently only viable solution combining traffic engineering capabilities of ATM and Frame Relay to viable wire-speed forwarding with ever increasing line speeds. Moreover, work is ongoing with Generalized MPLS (GMPLS) that will enable MPLS over DWDM architecture without any intermediate layers.

6 REFERENCES

Alwayn, V. (2001). Advanced MPLS Design and Implementation, 450 pages. Cisco Press. Indianapolis, USA. ISBN 1-58705-020-x

Andersson, L., Doolan, P., Feldman N., Fredette, A., Thomas, B. (2001) LDP Specification RFC 3036, IETF, January 2001

Armitage, G. (2000). MPLS: The Magic Behind the Myths, IEEE Communications Magazine, January 2000, 124-131

Ash, J., Girish, M., Gray, E., Jamoussi, B., Wright G. (2002), Applicability Statement for CR-LDP, RFC 3213, IETF<, January 2002.

Ash, J., Lee, Y., Ashwood-Smith, P., Jamoussi, B., Fedyk, D., Skalecki, D., Li, L. (2002). LSP Modification Using CR-LDP, RFC 3214, IETF, January 2002.

Awduche, D. O. (1999). MPLS and Traffic Engineering in IP Networks, IEEE Communications Magazine, December 1999, 42-47

Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., Swallow G. (2001). RSVP-TE: Extensions to RSVP for LSP Tunnels. RFC 3209. December 2001

Awduche, D., Hannan, A., Xiao, X. (2001) Applicability Statement for Extensions to RSVP for LSP-Tunnels, RFC 3210, IETF, December 2001

Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J. (1999). Requirements for Traffic Engineering Over MPLS. RFC 2702. September 1999

Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W. (1998). An Architecture for Differentiated Services, RFC 2475, IETF. December 1998.

Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, (1997). Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification, RFC 2205, IETF. September 1997.

Chen, C. M. and Tae, O. H. (1999). Reliable Services in MPLS. IEEE Communications Magazine, December 1999, 58-62.

Davie, R., Rekhter, Y. (2000). MPLS Technology and Applications, 286 pages. Morgan Kaufmann. San Diego, USA. ISBN 1-55860-656-4

Gartner Group (2002a). Challenges for Success in the Next-Generation Service Provider Router Market. Focus Report. 9 April 2002.



Gartner Group (2002b). Global Virtual Private Network (VPN). Operational Management Report. 29 May 2002.

Ghanwani, A, Jamoussi, B., Fedyk, D. (1999). Traffic Engineering Standards in IP Networks Using MPLS, IEEE Communications Magazine, December 1999, 49-53

Hold, D. (2001) Sonera’s Next Generation Internet. BroadbandWorld, Volume 3, Number 1.

Huang, C., Sharma, V., Owens, K., Makam, S. (2002). Building Reliable MPLS Networks Using a Path Protection Mechanism, IEEE Communications Magazine, March 2002, 156-162.

Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., Malis, A. (2002). Constraint-Based LSP Setup using LDP. RFC 3212. January 2002

Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., Heinanen J. (2002). Multi-Protocol Label Switching (MPLS) Support of Differentiated Services. RFC 3270, IETF, May 2002

Lee, W., Hluchyi, M., and Humblet, P. (1995) "Routing Subject to Quality of Service Constraints in Integrated Communication Networks," IEEE Network, July 1995, pp 46-55.

Mankin, A., Baker, F., Braden, B., Bradner, S., O`Dell, M., Romanow, A., Weinrib, A., Zhang, L (1997). Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment. RFC 2208. IETF. September 1997

MPLS Forum (2002). MPLS Forum Successfully Completes World's Largest Multi-Vendor MPLS Interoperability Test. Press Release. 20 May 2002

Ohba, Y. (1999). Issues on Loop Prevention in MPLS Networks. IEEE Communications Magazine, December 1999, 64-68

Ohba, Y., Katsube, Y., Rosen, E., Doolan, P. (2001). MPLS Loop Prevention Mechanism, RFC 3063, IETF February 2001

Ovum (2002). Ovum Forecasts: Global IP and Broadband Markets. March 2002

Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., Conta, A. (2001) MPLS Label Stack Encoding, RFC 3032, IETF, January 2001

Rosen, E., Viswanathan, A., Callon, R. (2001). Multiprotocol Label Switching Architecture, RFC 3031, IETF, January 2001

Swallow, G. (1999). MPLS Advantages for Traffic Engineering. IEEE Communications Magazine, December 1999, 54-57

Thomas, B., Gray, E. (2001). LDP Applicability. RFC 3037. IETF. January 2001.

Uzé, J-M. (2001). MPLS – Technology and Implementation. Tutorial in INET 2001. Stockholm, Sweden.

Documents

Multi Protocol Label Switching (MPLS) - · PDF fileMulti Protocol Label Switching (MPLS) Author: Sami Uskela, 44362U, [email protected]