Section 11.1. MPLS: An Overview

11.1. MPLS: An Overview

An MPLS VC is called a Label-Switched Path (LSP).^[1] You can also think of an LSP as a tunnel, in that a packet is encapsulated behind an MPLS header for transport over the LSP. What makes MPLS so flexible is that it is multiprotocol both in terms of the data link layer and the network layer. Because it operates above the data link layer, MPLS can run over any kind of data link. And because it runs below the network layer, it can carry any kind of network layer packet.

^[1] The acronym LSP is, of course, used throughout this book to represent "Link State PDU." This is not the only example of the same acronym representing different terms. In this chapter, you should normally be able to understand which term LSP represents by the context in which it is used. If the context is unclear, the term rather than the acronym is used.

11.1.1. Labels and Label Switching

An MPLS label is a 20-bit address, normally represented as a simple decimal number. Like ATM VPI/VCIs and Frame Relay DLCIs, it has local significancethat is, it need be unique only between any two devices.

Routers that are MPLS-enabled are called label-switching routers (LSRs). These routers have switching tables^[2] that map incoming labels with outgoing label/interface pairs. When an MPLS packet is received the label is used as an index to the switching table. The label of the incoming packet is changed (swapped) to the mapped outgoing label, and the packet is forwarded out the mapped outgoing interface.

^[2] Depending on the implementation, the switching table is usually just a part of the forwarding table.

Figure 11.1 shows the label-switching process. A packet with a label of 800003 is received. The label is found in the switching table, which says that the label value is to be swapped to 100056 and the packet is to be forwarded out interface 7. You can readily see that this switching process is similar to what happens in an ATM or Frame Relay switch.

Figure 11.1. The MPLS switching table matches incoming labels to outgoing labels and interfaces.

The LSR depicted in Figure 11.1 is a transit LSR for the packet shown, traveling along some label-switched path. When a packet is transiting an LSR, the LSR swaps labels as was shown. However, for a given LSP, a router can also be an ingress or egress LSR. An ingress LSR is the LSR on which an LSP begins; this router pushes a label onto a packet and forwards it onto the LSP. The last LSR along the LSPthat is, the router on which the LSP terminatesis the egress LSR for that LSP. An egress router pops or removes the MPLS label and then forwards the decapsulated packet by normal network-layer forwarding.

Figure 11.2 illustrates the relationship among LSR types and forwarding actions:

1. The leftmost IP router forwards a packet, using normal IP forwarding, to the ingress router.

2. The forwarding table in the ingress router is instructed, for that packet's destination, to push an MPLS label of 800154 onto the packet and forward it out a given interface. (For readability, the outgoing interface part is not shown in the illustration.)

3. The next router along the path is a transit router, and its switching table is instructed to swap incoming label 800154 for outgoing label 100007.

4. The next transit router swaps incoming label 100007 for outgoing label 0. Label 0 is a special reserved label that tells a receiving router to pop the MPLS label.^[3]

   ^[3] There is another reserved label, 3, which can be used as an alternative to label 0. Label 3 tells the last transit LSR before the egress LSRthe penultimate LSRto pop the label before forwarding to the egress LSR. This procedure has the wonderful name penultimate hop popping.

5. The egress router, seeing label 0, pops the label and forwards the decapsulated packet using normal IP forwarding.

Figure 11.2. Packet flow across a label-switched path.

Figure 11.2 illustrates two important facts. First, LSPs are unidirectional. If MPLS packets are to be forwarded from the rightmost LSR to the leftmost LSR, another LSP must be defined. Of course, if that new LSP flows from right to left, the rightmost LSR is the ingress for that LSP and the leftmost LSR is the egress. This leads to the second important fact: Whether an LSR is ingress, transit, or egress is relative to a given LSP. The transit LSRs in Figure 11.2, for example, might also be ingress LSRs for other LSPs and egress LSRs for yet other LSPs.

11.1.2. Forwarding Equivalence Classes and Label Binding

The LSP depicted in Figure 11.2 is, of course, not a physical entity. It is a conceptual entity defined by the series of forwarding and switching table entries from the ingress to the egress. The switching table is, as you saw in the previous section, a set of instructions that identifies incoming packets and classifies them so that they are treated in some predefined way (push, swap or pop some label and forward out some interface). What was not clearly shown in the previous section is that incoming packets with different destination addresses (at an ingress) or different labels (at a transit) or received on different interfaces might be given the same outgoing label and forwarded out the same interface to the same next hop. On any router, the set of packets that the router classifies in such a way that the packets are forwarded identicallyfor instance, given the same outgoing label, queued the same way, and forwarded out the same interfacebelong to the same forwarding equivalence class (FEC). All routing involves FECs, but the concept takes on particular importance with MPLS where the router does not "think"; it simply follows the basic set of instructions in the switching table.

When a label is used to identify what FEC a packet belongs to, that label is bound to the FEC. Every LSR maintains a pool of free labels. When an FEC is defined, the LSR binds one or more labels from its pool to the FEC. But this binding assumes that upstream neighborsneighbors forwarding packets to the LSRknow what that bound label value is, so that they can assign that value as an outgoing label. One way of doing this, of course, is to statically define all the switching tables and hence label bindings to create LSPs. The problem with this approach is the same as it is with static routes: It does not scale to a network of any reasonable size. So just as routing protocols are needed to dynamically compute routes, a signaling protocol is needed in MPLS networks to communicate label bindings from one LSR to another.

11.1.3. Label Distribution

Figure 11.3 shows how a signaling protocol might be used to set up the LSP depicted in Figure 11.2. First, when the ingress LSR wants to set up an LSP it looks up the IP address for the LSP endpointnormally the loopback address of the egress LSRin its unicast IP routing table. The ingress LSR then can then route a message to the egress requesting that an LSP be set up. Next, the egress router creates a label binding. Because it is the egress, the label binding is simply to a pop function. The egress LSR4 then sends a setup message upstream to LSR3, telling it that it has bound label 0 to the FEC. LSR3 then creates an FEC with outgoing label 0 and the interface on which it received the setup message from LSR4, selects a label from its pool of free labelsin this case 100007and binds the label to the FEC. LSR3 then sends a setup message to LSR2 with this binding information. LSR2 creates an FEC with the label in the message, selects a label and binds it to the FEC, and sends a setup message to LSR1, the ingress, with the binding information. The LSP is now created, and LSR1 knows that to send any packets over the LSP to LSR4 it encapsulates the packet with a label of 800154 and forwards it out the interface to LSR2.

Figure 11.3. An ingress LSR that wants to set up an LSP sends a request message to the egress LSR; the egress then sends a setup message back upstream to the ingress, so that label bindings can be created along the path.

The theoretical signaling protocol just described is simplistic and is not the only way to distribute labels, but it gives you an idea of the basic approach to dynamically building an LSP. Three signaling protocols currently are available for distributing labels:

• Label Distribution Protocol (LDP)

• Constraint-Based Label Distribution Protocol (CR-LDP)

• Resource Reservation Protocol for Traffic Engineering (RSVP-TE)

LDP is a lightweight, scalable protocol for distributing labels and is particularly useful in some types of MPLS-based VPN services. However, when LSPs are set up using LDP, they always follow the IGP shortest path as it exists in the network's IP unicast routing tables. As described in Section 11.2, MPLS traffic engineering enables you to set up LSPs over paths other than the ones prescribed by the IGP. Signaling such a path setup requires either CRLDP or RSVP.

CR-LDP and RSVP-TE are competing and incompatible protocols that do the same thing. Which one you use in your network depends primarily on what vendors you use. Cisco Systems and Juniper Networks, for example, advocate RSVP-TE, whereas Nortel Networks champions CR-LDP.

Describing how any of these three MPLS signaling protocols works is beyond the scope of this chapter; there are plenty of good books and whitepapers available on the subject. For our purposes, it is enough to know that they exist and what they do.

11.1.4. The MPLS Header

MPLS encapsulates packets by adding a 4-byte header to the packet (Figure 11.4). The resulting MPLS packet can then be itself encapsulated by the data link protocol of the link over which it is to be transmitted. Because the MPLS header appears between the network layer header and the data link header, it is sometimes called a "shim" header. Its position between these two headers is also why MPLS is sometimes called a "layer 2.5" protocol.

Figure 11.4. The MPLS header is added to the front of the network layer packet to be encapsulated, and is then encapsulated by the data link header.

Figure 11.5 shows the format of the MPLS header. The majority of the header is the 20-bit label.

Figure 11.5. The MPLS header.

The Experimental (EXP) field is somewhat unfortunately named, because it now has an explicit use: The value of the 3-bit field specifies how the MPLS packet is to be queued in class-of-service (CoS) applications. The values that can be carried in the field normally correspond to the 3-bit Precedence portion of the Type-of-Service (ToS) field in the IPv4 header.

The Stack (S) bit is used for label stacking: Encapsulating an MPLS packet within another MPLS packet. That is, adding another MPLS header in front of an existing MPLS header. Label stacking enables you to tunnel LSPs within other LSPs for scalability. When the S bit is cleared in an MPLS header, it indicates that the next header is another MPLS header. If the S bit is set, it indicates the bottom of the stack: The next header is encapsulated information.

The Time-to-Live (TTL) field is an 8-bit field that functions exactly the same as the TTL field in the IPv4 header and the Hop Limit field of the IPv6 header. It is decremented at each LSR hop, and if it decrements to 0 the MPLS header is discarded. When an IP packet is encapsulated, the value of its TTL field is copied into the TTL field of the MPLS header. The value then continues to be decremented across the LSP. When the packet is decapsulated at the egress LSR, the value of the MPLS TTL field is copied to the TTL field of the IP header. This way the TTL is accurately tracked when an IP packet traverses an MPLS network.

A Useful MPLS TTL Option

An option enables you to disable the operation of writing the value of the MPLS TTL field into the IP TTL field at the egress LSR. The effect of this is that the IP TTL is decremented once at the ingress, before being encapsulated into MPLS, and again at the egress, after being decapsulated from MPLS. As a result, the entire MPLS "cloud" appears to be a single hop.

Many MPLS service providers use this option because many customers regularly track the number of hops through a network on the outdated belief that additional hops add significant latency. (Anyone who has concerns about latency should be tracking actual latency, not router hops.) Therefore, when an LSP is moved for traffic engineering or other reasons, the hop count can change, generating calls to the NOC from customers who mistakenly believe their service is being degraded. Eliminating the MPLS hop count from the IP TTL field prevents a flood of calls from concerned customers every time the service provider makes a traffic engineering change. Customers see a single hop, no matter what the provider is doing internally.