The MPLS FAQ - Page 2 of 3

4. MPLS Components

a. What is a Label?
Section 3.1 of RFC 3031: "Multiprotocol Label Switching Architecture" defines a label as follows "A label is a short, fixed length, locally significant identifier which is used to identify a FEC. The label which is put on a particular packet represents the "Forwarding Equivalence Class" to which that packet is assigned."

The MPLS Label is formatted as follows:

|-20bits Label-|-3bits CoS-|-1bit Stack-|-8bits TTL-|

The 32-bit MPLS label is located after the Layer 2 header and before the IP header. The MPLS label contains the following fields:

• The label field (20-bits) carries the actual value of the MPLS label.
• The CoS field (3-bits) can affect the queuing and discard algorithms applied to the packet as it is transmitted through the network.
• The Stack (S) field (1-bit) supports a hierarchical label stack.
• The TTL (time-to-live) field (8-bits) provides conventional IP TTL functionality. This is also called a "Shim" header.

b. What is a Label Switch Path?
An LSP is a specific path traffic path through an MPLS network.  An LSP is provisioned using Label Distribution Protocols (LDPs) such as RSVP-TE or CR-LDP.  Either of these protocols will establish a path through an MPLS network and will reserve necessary resources to meet pre-defined service requirements for the data path.

LSPs must be contrasted with traffic trunks.  From RFC 2702: "Requirements for Traffic Engineering Over MPLS," "A traffic trunk is an aggregation of traffic flows of the same class which are placed inside a LSP.  It is important, however, to emphasize that there is a fundamental distinction between a traffic trunk and the path, and indeed the LSP, through which it traverses.  In practice, the terms LSP and traffic trunk are often used synonymously. The path through which a trunk traverses can be changed.  In this respect, traffic trunks are similar to virtual circuits in ATM and Frame Relay networks."  

c. What is a Label Distribution Protocol?  
A label distribution protocol (LDP) is a specification which lets a label switch router (LSR) distribute labels to its LDP peers. When a LSR assigns a label to a forwarding equivalence class (FEC) it needs to let its relevant peers know of this label and its meaning and LDP is used for this purpose. Since a set of labels from the ingress LSR to the egress LSR in an MPLS domain defines a Label Switched Path (LSP) and since labels are mapping of network layer routing to the data link layer switched paths, LDP helps in establishing a LSP by using a set of procedures to distribute the labels among the LSR peers.

Label Switching Routers (LSRs) use labels to forward traffic. A fundamental step to Label Switching is that LSRs agree on the what  labels they should use to forward traffic. They come to this common understanding by using the Label Distribution

Label Distribution Protocol is a major part of MPLS. Similar mechanisms for Label exchange existed  in vendor implementations like Ipsilonâs Flow Management Protocol (IFMP), IBMâs Aggregate Route-based IP Switching (ARIS), and Ciscoâs Tag Distribution Protocol. LDP and labels are the foundation of Label Switching. 

LDP has the following basic characteristics:

• It provides an LSR ã discoveryä mechanism to enable LSR peers to find each other and establish communication
• It defines four classes of messages: DISCOVERY, ADJACENCY, LABEL ADVERTISEMENT, and NOTIFICATION messages
• It runs over TCP to provide reliable delivery of messages (with the exception of DISCOVERY messages

LDP label distribution and assignment may be performed in several different modes: 

• Unsolicited downstream versus downstream-on-demand label assignment
• Order versus independent LSP control
• Liberal versus conservative label retention

d. What's the difference between CR-LDP and RSVP-TE
CR-LDP and RSVP-TE are both signaling mechanisms used to support Traffic Engineering across an MPLS backbone. RSVP is a QoS signaling protocol that is an IETF standard and has existed for quite some time. RSVP-TE extends RSVP to support label distribution and explicit routing while CR-LDP proposed to extend LDP (designed for hop-by-hop label distribution to support QoS signaling and explicit routing). MPLS Traffic Engineering tunnels are not limited to IP route selection procedures and thus will spread network traffic more uniformly across the backbone taking advantage of all available links. A signaling protocol is required to set up these explicit MPLS routes or tunnels.

There are many similarities between CR-LSP and RSVP-TE for constraint-based routing. The Explicit Route Objects that are used are extremely similar. Both protocols use ordered Label Switched Path (LSP) setup procedures. Both protocols include some QoS information in the signaling messages to enable resource allocation and LSP establishment to take place automatically. 

At the present time CD-LDP development has ended and RSVP-TE has emerged as the "winner" for traffic engineering protocols.

e. What is a "Forwarding Equivalency Class"?
Forwarding Equivalency Class (FEC) is a set of packets which will be forwarded in the same manner (e.g., over the same path with the same forwarding treatment). Typically packets belonging to the same FEC will follow the same path in the MPLS domain. While assigning a packet to an FEC the ingress LSR may look at the IP header and also some other information such as the interface on which this packet arrived. The FEC to which a packet is assigned is identified by a label.

One example of an FEC is a set of unicast packets whose network layer destination address matches a particular IP address prefix.  A set of multicast packets with the same source and destination network layer addresses is another example of an FEC.  Yet another example is a set of unicast packets whose destination addresses match a particular IP address prefix and whose Type of Service bits are the same

f. How are Label Switch Paths built?
A Label Switch Path (LSP) is a set of LSRs that packets belonging to a certain FEC travel in order to reach their destination. Since MPLS allows hierarchy of labels known as label stack, it is possible to have different LSPs at different levels of labels for a packet to reach its destination. So more formally, a LSP of a packet with a label of level m is a set of LSRs that a packet p has to travel at level m to reach its destination. Please refer to 3.15 of RFC 3031 - Multiprotocol Label Switching Architecture, for a very formal and complete definition.

As an example: consider the following scenario

|------| 1                                     1 |-----|
| R1   |--\                                  /---| R5  |
|------|   \   2          2          2      /    |-----|
            \|------|   |-----|   |-----|  /
           | R2   |---| R3  |---| R4  |/
          |------|   |-----|   |-----|

In the above fig. R1 to R5 are the LSRs that a packet p must travel to reach its destination. The numbers 1 and 2 are label stack depth. R1 and R5 are border gateway routers and R2, R3 and R4 are the interior gateway routers. For the purpose of label forwarding R1 and R5 are peers at the border gateway level and R2, R3, R4 are peers at the interior gateway level. When R1 receives the packet P with a label that is 1 level deep, it will swap that P's label with a corresponding label that will be used by R5. Also since the packet has to travel through R2, R3 and R4, R1 will push a new label and the label stack level is now 2. So we have two LSPs here. One is at level 1 from R1 to R5 and the second is at level 2 from R2 to R4.

In order to build a LSP the LSRs make use of the routing protocols and the routes learned from these protocols. They may use other protocols such as RSVP but they are not required to. 

Label Switch Path setup can be either ãindependentä or ãorderedä control. Independent control of LSP establishment is when label switching is used in support of destination-based routing. Here each LSR may make an independent decision to assign a label to an FEC and to advertise that assignment to its neighbors.  This way the establishment of an LSP follows the convergence of routing almost immediately. In ordered control, label assignment proceeds in an orderly fashion from one end of an LSP to the other. LSP setup may be initiated by the ingress or egress end of the LSP. 

It is possible to support both ordered and independent control without interoperability issues.  Both approaches have their advantages and disadvantages.  Please refer to Davie, B. and Rekhter, Y., "MPLS: Technology and Applications" for more details.

Label binding may be created locally and remotely; by downstream or upstream LSRs; they may be created in response to control- or data-driven traffic; and the binding may be distributed in a stand-alone protocol (LDP) or piggybacked on an existing one (i.e. BGP).

g. What is the relationship between MPLS and the Interior Routing Protocol
Interior Gateway Protocols (IGP), such as OSPF and IS-IS, are used to defined reachability and the binding/mapping between FEC and next-hop address. MPLS learns routing information from IGP (e.g., OSPF, IS-IS). Link-state Interior Gateway Protocol is typically already running on large Corporations or Service Providers networks There are no changes required to IGP routing protocols to support MPLS, MPLS-TE, MPLS QoS, or MPLS-BGP VPNs. 

h. What other protocols does MPLS support besides IP?
By definition, Multiprotocol Label Switching supports multiple protocols.  At the Network Layer MPLS supports IPv6, IPv4, IPX and AppleTalk. At the Link Layer MPLS supports Ethernet, Token Ring, FDDI, ATM, Frame Relay, and Point-to-Point Links. It can essentially work with any control protocol other than IP and layer on top of any link layer protocol. In addition, development efforts have allowed MPLS to not only work over any data link layer protocol, but also to natively carry a data link layer protocol over IP, thus enabling services such as Ethernet over MPLS.

5. MPLS and ATM

a. What are the differences between MPLS and ATM?
MPLS brings the traffic engineering capabilities of ATM to packet-based network. It works by tagging IP packets with "labels" that specify a route and priority. It combines the scalability and flexibility of routing with performance and traffic management of layer 2 switching. It can run over nearly any transport medium (ATM, FR, POS, Ethernet...) instead of being tied to a specific layer-2 encapsulation. As it uses IP for its addressing, it uses common routing/signaling protocols (OSPF, IS-IS, RSVP...) 

b. Does MPLS replace ATM?
MPLS was not designed to replace ATM but, the practical reality of the dominance of IP-based protocols coupled with MPLS's inherent flexibility has led many service providers to migrate their ATM networks to one based on MPLS. 

MPLS can co-exist with ATM switches and eliminate complexity by mapping IP addressing and routing information directly into ATM switching tables. The MPLS label-swapping paradigm is the same mechanism that ATM switches use to forward ATM cells. For ATM-LSR the label swapping function is performed by the ATM forwarding component. Label information is carried in the ATM Header, specifically the VCI and VPI fields.  MPLS provides the control component for IP on both the ATM switches and routers. For ATM switches PNNI, ATM ARP Server, and NHRP Server are replaced with MPLS for IP services. The ATM fowarding plane (i.e 53-byte cells) are preserved.  PNNI may still used on ATM switches to provide ATM services for non-MPLS ports.  Therefore, an IP+ATM switch delivers the best of both worlds; ATM for fast switching and IP protocols for IP services all in a single switch.

 c. What is "Ships in the night"?
Some vendors support the running of MPLS and ATM in the same device.  Generally speaking, these two processes run separately.  A change in an MPLS path has no bearing on ATM virtual circuits.  This practice is commonly referred to "ships in the night" since the two processes act alone.  However, in some cases, there is some interaction between the two processes.  For example, some vendors support a mechanism whereby a reservation of resources by a label switch path is detected by the ATM control mechanism to avoid resource conflicts.  

"Ships in the night" is used as a transitioning mechanism as networks migrate their ATM control planes to MPLS.  Networks initially preserve ATM for carrying time sensitive data traffic such as voice and video, and for connecting to non-MPLS enabled nodes, while concurrently running MPLS to carry data.  Over time there will no longer be a need for separate ATM flows and therefore networks will only carry MPLS label-based traffic.

6. MPLS Traffic Engineering

a. What does MPLS traffic engineering accomplish?
Traffic engineering refers to the process of selecting the paths chosen by data traffic in order to balance the traffic load on the various links, routers, and switches in the network. Traffic engineering is most important in networks where multiple parallel or alternate paths are available.

A major goal of Internet Traffic Engineering is to facilitate efficient and reliable network operations while simultaneously optimizing network resource utilization and traffic performance.

The goal of TE is to compute a path from one given node to another (source routing), such that the path does not violate the constraints (e.g. Bandwidth/administrative requirements...) and is optimal with respect to some scalar metric. Once the path is computed, TE (a.k.a. Constraint based routing) is responsible for establishing and maintaining forwarding state along such a path.  

b. What are the components of MPLS-TE?
In order to support Traffic engineering,  besides explicit routing (source routing), the following components should be available:

• Ability to compute a path at the source by taking into account all the constraints.  To do so the source need to have all the information either available locally or obtained from other routers in the network (e.g. Network topology) 
  
  
• Ability to distribute the information about network topology and attributes  associated with links throughout the network once the path is computed, need a way to support forwarding along such a path
  
  
• Ability to reserve network resources and to modify link attributes (as the result of certain traffic taking certain routes)

MPLS TE leverages several foundation technologies:

• Constraint shortest path first algorithm used in path calculation. This is a modified version of the well known SPF algorithm extended to constraints support
  
  
• RSVP extension used to establish the forwarding state along the path, as well as to reserve resources along the path
  
  
• Link state IGPs with extension (OSPF with Opaque LSAs, IS-IS with  Link State Packets TLV (type, length, value)) keeping track  of topology changes propagation

c. How does MPLS merge traffic flows?
MPLS allows the mapping from IP packet to forwarding equivalence class (FEC) to be performed only once at the ingress to an MPLS domain.  A FEC is a set of packets that can be handled equivalently for the purpose of forwarding and thus is suitable for binding to a single label.

From a forwarding point of view, packets within the same subset are treated by the LSR in the same way, even if the packets differ from each other with respect to the information in the network layer header. The mapping between the information carried in the network layer header of the packets and the entries in the forwarding table of the LSR is many to one. That is packets with different content of their network layer headers could be mapped into the same FEC. (example of a FEC: set of unicast packets whose network layer destination address match a particular IP address prefix...) 

d. How are loops prevented in MPLS networks?
Before focusing on MPLS loops prevention,  let's introduce briefly the different loops handling schemes.

Generally speaking, loop handling can be split into two categories:

• Loop prevention: provides methods for avoiding loops before any packets are sent on the path - i.e. Path Vector
  
• Loop mitigation (survival+detection): minimize the negative effects of loopseven though short term transient loops may be formed. - i.e. Time-To-Live (TTL). If the TTL reaches 0, then the packet is discarded
  
• Dynamic routing protocols which converge rapidly to non-looping paths 

As far as loop mitigation is concerned, MPLS labeled packets may carry a TTL field that operates just like the IP TTL to enable packets caught in transient loops to be discarded.

However, for certain medium such as ATM and Frame Relay, where TTL is not available, MPLS will use buffer allocation as a form of loop mitigation. It is mainly used on ATM switches which have the ability to limit the amount of switch buffer space that can be consumed by a single VC.

Another technique for non TTL segment is the hop count approach: hop count information is carried within the Link Distribution Protocol messages [3]. It works like a TTL. Hop count will decrease by 1 for every successful label binding.

A third alternative adopted by MPLS is an optional loop detection technique called path vector. A path vector contains a list of the LSRs that label distribution control message has traversed. Each LSR which propagates a control packet (to either create or modify an LSP) adds its own identifier to the path vector list. Loop is detected when an LSR receives a message with a path vector that contains its own identifier. This technique is also used by the BGP routing protocol with its AS path attribute.

e. How does MPLS perform failure recovery?
When a link goes down it is important to reroute all trunks that were routed over this link. Since the path taken by a trunk is determined by the LSR at the start of the MPLS path (head end), rerouting has to be performed by the head end LSR. To perform rerouting, the head end LSR could rely either on the information provided by IGP or by RSVP/CR-LDP.

However, several MPLS-specific resiliency features havebeen developed including Fast Re-Route, RAPID, and Bidirectional Forwarding. See RFC 3469: "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery" for additional information.

f. What differences are there in running MPLS in OSPF versus IS-IS environments?
This is not an MPLS question but an IGP (Interior Gateway Protocol) question.  MPLS extensions, stated in IEFT RFC's, are supported for both OSPF and IS-IS.  MPLS and BGP-VPN real-world deployments have been on both protocols for some time now.

Ultimately, it is  best to first understand the benefits and disadvantages of each protocol.  Then use the customer / network requirements to choice the IGP which best suites your needs.

g. Can there be two or more Autonomous Systems within the same MPLS domain?
This is possible only under very restricted circumstances. Consider the ASBRs of two adjacent ASes. If either or both ASBRs summarize eBGP routes before distributing them into their IGP, or if there is any other set-up where the IGP routes cover a set of FECs which differs from that of the eBGP routes (and this would almost always be the case), then the ASBRs cannot forward traffic based on the top-level label. A similar argument applies to TE tunnels. Some traffic usually will be either IP forwarded by the ASBR, or forwarded based on a non-top-level label.

So there would usually be 2-3 MPLS forwarding domains if there were two ASes: one for each of the two ASes, and possibly one for the link between the two ASBRs (in the case that labelled packets instead of IP packets are forwarded between the two ASBRs).

Also, it's likely that the ASBRs could not be ATM-LSRs, as ATM-LSRs typically have limited or no capability of manipulating label stacks or forwarding unlabelled IP traffic.

Another example (thanks to Robert Raszuk) is with the multi-provider application of BGP+MPLS VPNs.   As described earlier, there are usually no *top-level* LSPs established across the two (or more) provider ASes involved, so it can be argued that:

1. The two ASes are separate administrative domains. However there are some LSPs established across the two ASes, at a lower level in the label stack. So, it can be argued that
2. The two ASes are the same administrative domain, in so far as the two providers agree to allow lower-level LSPs to  be established across the two ASes

(1) and (2) are both true, which implies that different definitions of the boundary of the administrative domains can exist with respect to different levels in the label stack. It is also (in hindsight) obvious that different MPLS domain boundaries can exist with respect to different levels of the label stack.

7. MPLS VPNs

a. How does MPLS enable VPNs?
Since MPLS allows for the creation of "virtual circuits" or tunnels, across an IP network, it is logical that service providers would look to use MPLS to provision Virtual Private Network services.  Several standards have been proposed to allow service providers to use MPLS to provision VPN services that isolate a customers traffic across the provider's IP network and provide secure end-to-end connectivity for customer sites.

It should be noted that using MPLS for VPNs simply provides traffic isolation, much like an ATM or Frame Relay service.  MPLS currently has no mechanism for packet encryption, so if customer requirements included encryption, some other method, such as IPsec, would have to be employed.  The best way to think of MPLS VPNs is to consider them the equivalent of a Frame Relay or ATM virtual circuit.

b. What alternatives are there for implementing VPNs over MPLS  
There are multiple proposals for using MPLS to provision IP-based VPNs.  One proposal (MPLS/BGP VPNs) enabled MPLS-VPNs  via extensions to Border Gateway Protocol (BGP).  In this approach, BGP propagates VPN-IPv4 information using the BGP multiprotocol extensions (MP-BGP) for handling these extended addresses.  It propagates reachability information (VPN-IPv4 addresses) among Edge Label Switch Routers (Provider Edge router).  The reachability information for a given VPN is propagated only to other members of that VPN. The BGP multiprotocol extensions identify the valid recipients for VPN routing information. All the members of the VPN learn routes to other members.

Another proposal for using MPLS to create IP-VPN's is based on the idea of maintaining separate routing tables for various virtual private networks and does not involve BGP.  

Most implementations of Layer 3 MPLS-VPNs are based on RFC-2547.

c. What is the "Martini Draft'?
The "Martini Draft" actually refers to set of Internet drafts co-authored by Luca Martini.  These drafts define how MPLS can be used to support Layer 2 transport services such as Ethernet, Frame Relay and/or ATM.  Martini drafts define Layer 2 encapsulation methods, as well as Layer 2 transport signaling methods. 

Many service providers wish to use MPLS to provision L2-based services to provide an easy migration for the current L2 service customers, while the providers migrate their networks to MPLS.  Service providers can use standards such as Martini Draft to provide a myriad of services over their MPLS networks, so customers can simply choose the technology that is best suited to their environment.

The Psuedo Wire Emulation Edge-to-Edge (PWE3) working group is currently developing standards for Layer 2 encapsulation (including Draft-Martini and other supporting standards).   Current working group drafts can be located at www.mplsrc.com/standards.shtml under the sub-heading "Layer 2 VPNs and Layer 2 Emulation." 

d. What is a "Layer 2 VPN"
Layer 2 VPNs are an extension of the work being undertaken in the PWE3 working group.  Layer 2 VPNs allow service providers to provision Layer 2 services such as Frame Relay, ATM and Ethernet between customer locations over an IP/MPLS backbone.  Service providers can thus provision Layer 2 services over their IP networks, removing the need to maintain separate IP and Frame Relay/ATM network infrastructures.  This allows service providers to simplify their networks and reduce operating expenses.

The IETF's "Layer 2 Virtual Private Networks (l2vpn)" working group is currently defining standards for provisioning Layer 2 VPN services.  Current working group drafts can be located at www.mplsrc.com/standards.shtml under the sub-heading "Layer 2 VPNs and Layer 2 Emulation."

e. What is a Virtual Private LAN Service (VPLS)?
VPLS refers to a method for using MPLS to create virtual LAN services based on Ethernet.  In this type of service, all edge devices maintain MAC address tables for all reachable end nodes, much in the same way as a LAN switch.

VPLS services enable enterprises to provide Ethernet reachability across geographic distances served by MPLS services.  Several alternatives for enabling VPLS services are in development by the L2VPN working group.  Please refer to drafts from that working group for additional information.  Also see the Juniper Network's White Paper "VPLS: Scalable Transparent LAN Services."

f. Are MPLS-VPNs secure?
Among many network security professionals, the term "VPN" implies "encrypted" tunnels across a public network.  Since MPLS-VPNs do not require encryption, there is often concern over the security implications of using MPLS to tunnel non-encrypted traffic over a public IP network. There are a couple of points to consider in this debate:

• MPLS-VPN traffic is isolated by the use of tags, much in the same way ATM and Frame Relay PVCs are kept isolated in a public ATM/Frame Relay network.  This implies that security of MPLS-VPNs is equivalent to that of Frame Relay or ATM public network services.  Interception of any of these three types of traffic would require access to the service provider network. 
  
• MPLS-VPNs do not prohibit security.  If security is an issue, traffic can be encrypted before it is encapsulated into MPLS by using a protocol such as IPSec or SSL.

The debate over MPLS security really comes down requirements of the customer.  Customers comfortable with carrying their traffic over public ATM or Frame Relay services should have the same level of comfort with MPLS-VPN services.  Customers requiring additional security should employ encryption in addition to MPLS.

For additional information, see Miercom's report "Cisco MPLS-VPN: Security Equivalent to Frame Relay"

8. MPLS Quality of Service

a. What kinds of QoS protocols does MPLS support?
MPLS supports the same QoS capabilities as IP.  These mechanisms are IP Precedence, Committed Access Rate (CAR), Random Early Detection (RED), Weighted RED, Weighted Fair Queuing (WFQ), Class-based WFQ, and Priority Queuing.  Proprietary and non-standard QoS mechanisms can also be support but are not guaranteed to interoperate with other vendors. 

Since MPLS also supports reservation of Layer 2 resources, MPLS can deliver finely grained quality of service, much in the same manner as ATM and Frame Relay. 

b. How do I integrate MPLS and DiffServ
DiffServ can support up to 64 classes while the MPLS shim label supports up to 8 classes.  This shim header has a 3-bit field defined ãfor experimental use.  This poses a problem.  This Exp field is only 3 bits long, whereas the Diff-Serv field is 6 bits.  There are different scenarios to work around this problem. 

There are two alternatives that address this problem called Label-LSP and Exp-LSP models.  But they introduce complexity into the architecture.  The diffserv model essentially defines the interpretation of the TOS bits. As long as the IP precedence bits map to the Exp bits the same interpretation as the diffserv model can be applied to these bits. In the case where additional bits are used in the diffserv model, one can essentially use the label value to interpret the meaning of the remaining bits. Recognizing that 3 bits are sufficient to identify the required number of classes, the remaining bits in the diffserv model are used for identifying the drop priority and these drop priorities can be mapped into an L-LSP in which case the label identifies the drop priority while the exp bits identify the Class that the packet belongs to. 

Many Service Provides have or will add just a few classes.  This small enhancement will be hard enough to provision, manage and sell.  This would be an effective strategy to get to market quickly with a value-added service. 

The followings classes may be more appropriate for the initial deployment of MPLS QoS:

• High-priority, low-latency "Premium" class (Gold Service)

• Guaranteed-delivery "Mission-Critical" class (Silver Service)

• Low-priority "Best-Effort" class (Bronze Service)

c. How do I integrate MPLS and ATM QoS ?
MPLS makes it possible to apply QoS across very large routed or switched networks because Service Providers can designate sets of labels that have special meanings, such as service class.  Traditional ATM and Frame Relay networks implement CoS with point-to-point virtual circuits, but this is not scalable for IP networks.  Placing traffic flows at the edge into service classes enables providers to engineer and manage classes throughout the network.  

If service providers manage networks based on service classes, not point-to-point connections, they can substantially reduce the amount of detail they must track and increase efficiency without losing functionality.  Compared to per-circuit management, MPLS-enabled CoS provides virtually all of the benefit with far less complexity.  Using MPLS to establish IP CoS has the added benefit of eliminating per-VC configuration.  The entire network is easier to provision and engineer.