Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    MPLS Label Switching and Packet Forwarding Overview

    MPLS is not a routing protocol; it works with layer 3 routing protocols (BGP, IS-IS, OSPF) to integrate network layer routing with label switching. An MPLS FEC consists of a set of packets that are all forwarded in the same manner by a given label-switching router (LSR). For example, all packets received on a particular interface might be assigned to a FEC. MPLS assigns each packet to a FEC only at the LSR that serves as the ingress node to the MPLS domain. A label distribution protocol binds a label to the FEC. Each LSR uses the label distribution protocol to signal its forwarding peers and distribute its labels to establish an LSP. The label distribution protocol enables negotiation with the downstream LSRs to determine what labels are used on the LSP and how they are employed.

    Labels represent the FEC along the LSP from the ingress node to the egress node. The label is prepended to the packet when the packet is forwarded to the next hop. Each label is valid only between a pair of LSRs. A downstream LSR reached by a packet uses the label as an index into a table that contains both the next hop and a different label to prepend to the packet before forwarding. This table is usually referred to as a label information base (LIB).

    The LSR that serves as the egress MPLS node uses the label as an index into a table that has the information necessary to forward the packet from the MPLS domain. The forwarding actions at the egress LSR can be any of the following:

    • Forward the packet based on the inner header exposed after popping the label. This can be accomplished either by doing a routing table lookup or forwarding based on the exposed inner MPLS label.
    • Forward the packet to a particular neighbor as directed by the table entry, for example in a Martini layer 2 transport case.

    Note: Forwarding of traffic for labeled IPv6 unicast routes with native IPv6 next-hop addresses does not work.

    Figure 1 shows a simple MPLS domain, consisting of multiple LSRs. The LSRs serving as ingress and egress nodes are also referred to as label edge routers (LERs). The ingress router is sometimes referred to as the tunnel head end, or the head-end router. The egress router is sometimes referred to as the tunnel tail end, or the tail-end router. LSPs are unidirectional, carrying traffic only in the downstream direction from the ingress node to the egress node.

    Figure 1: Simple MPLS Domain

    Simple MPLS Domain


    Each LSR, also known as an MPLS node, must have the following:

    • At least one layer 3 routing protocol
    • A label distribution protocol
    • The ability to forward packets based on their labels

    The router can use BGP, IS-IS, or OSPF as its layer 3 routing protocol, and BGP, LDP, or RSVP-TE as its label distribution protocol.

    MPLS Label Switching: Push, Look Up, and Pop

    MPLS can label packets by using the existing layer 2 header or an encapsulation header that carries the MPLS label. During LSP negotiation, the LSRs in an MPLS domain agree on a labeling method. Labels have only local meaning; that is, meaning for two LSR peers. Each pair of LSRs—consisting of a label originator and a label acceptor—must use a label distribution protocol to agree on the label-to-FEC binding.

    Because of the local label assignment, packet labels typically change at each segment in the LSP path, as shown in Figure 2. The ingress node, LSR 1, receives an unlabeled data packet and prepends label d to the packet. LSR 2 receives the packet, removes label d and uses it as an index in its forwarding table to find the next label. LSR 2 prepends label e to the packet. LSR 3 does the same thing, removing label e and prepending label u. Finally, the egress node, LSR 4, removes label u and determines where to forward the packet outside the MPLS domain.

    Figure 2: Label Switching

    Label Switching

    Any packet can carry multiple labels. The labels are stacked in a last-in-first-out order. Each LSR forwards packets based on the outermost (top) label in the stack. An LSR pushes a label onto the stack when it prepends the label to a packet header. It pops the label when it pulls the label off the stack and compares it with the forwarding table. On determining the label for the next segment of the LSP, the LSR pushes the new label on the stack. A label swap consists of a pop, lookup, and push.

    When the egress router, such as LSR 4 in Figure 2, receives a packet, it may perform two lookups: it looks up the label and determines that the label must be popped, then it does another lookup based on the exposed header to determine where to forward the packet. This behavior is known as ultimate hop popping, and was the only possible action for the JunosE implementation before Release 7.3.0.

    Beginning with JunosE Release 7.3.0, an alternative behavior, known as penultimate hop popping (PHP), is the default when RSVP-TE is the signaling protocol. Beginning with JunosE Release 8.1.0, PHP is also the default when LDP is the signaling protocol. PHP reduces the number of lookups performed by the LER. In PHP, the LER requests its upstream neighbor (the penultimate hop) to pop the outermost label and send just the packet to the LER. The LER then performs only the lookup for the packet. The request to perform PHP is signaled by the LER when it includes an implicit null label in the label mapping message that it sends to its upstream neighbor. The implicit null label never appears in the encapsulation.

    You can still achieve ultimate hop popping by configuring the egress router to advertise an explicit null label to its upstream neighbor. This advertisement, performed by LDP or RSVP-TE, ensures that all MPLS packets traversing the LSP to the egress router include a label. Alternatively, you can configure the egress router to advertise real (non-null) labels, and achieve the same result.

    Regardless of whether the LSR advertises the implicit null label to achieve PHP on an upstream neighbor, if the LSR receives a PHP request from a downstream neighbor, then the LSR does perform the PHP for its neighbor.

    MPLS Label Stacking

    Figure 3 shows an LSP that uses label stacking. The ingress node, LSR 1, receives an unlabeled data packet and prepends label d to the packet. LSR 2 receives the packet, removes label d and uses it as an index in its forwarding table to find the next label, prepending label e to the packet. LSR 3 removes label e and prepends label s (negotiated with LSR 5) to the packet. LSR 3 pushes label x on top of label s. LSR 4 pops the top (outermost) label, x, and pushes label r on top of label s. LSR 5 pops label r, determines that it must pop label s, and pushes label z on the empty stack. Finally, the egress node, LSR 6, removes label z and determines where to forward the packet outside the MPLS domain.

    Figure 3: Label Stacking

    Label Stacking

    The configuration shown in Figure 3 is an example of an LSP within an LSP (a tunnel within a tunnel). The first LSP consists of LSR 1, LSR 2, LSR 3, LSR 5, and LSR 6. The second LSP consists of LSR 3, LSR 4, and LSR 5. The two LSPs have different ingress and egress points. LSR 1 and LSR 6 are LERs. Less obviously, LSR 3 and LSR 5 are also LERs, but for the internal LSP.

    Note: Label stacking is typically employed for LSR peers that are not directly connected. Figure 3 is a simplified example to illustrate the concept of label stacking.

    MPLS Labels and Label Spaces

    MPLS uses labels from either the platform label space or the interface label space. ATM AAL5 interfaces always use labels from only the interface label space. For every interface using the interface label space, you must define the range available to the router for labels in the interface label space. All other interface types always use labels from only the platform label space. You cannot configure the range for the platform label space.

    The platform label space is a large, single, unconfigurable pool of labels that can be shared by the platform—all MPLS interfaces on a given virtual router. By contrast, interface labels enable you to effectively create multiple smaller pools of labels, each used only by a particular interface. When you configure interface labels, you restrict only a given interface to a particular range of labels. Other interfaces in that VR can still use labels from that space unless you restrict them in turn to a different range of interface labels.

    In the interface label space, MPLS selects labels from interface resources, a VPI/VCI combination. You configure a VPI range and a VCI range available to the labels. When an upstream LSR requests a label, the downstream LSR allocates a VPI/VCI combination for use as a label between these two peers. Allocating labels on a per interface basis is necessary because the VPI/VCI ranges are limited. This enables you to use the same label on different interfaces without conflict.

    When you use the platform label space, the MPLS ingress node places labels in shim headers between the link-layer header and the payload. The shim header includes the following bits (Figure 4):

    • Label bits—Twenty bits
    • EXP bits—Three bits for class of service information; these bits are variously called the experimental bits, class of service (CoS) bits, or type of service (ToS) bits. The EXP bits are mapped from the IP packet at the ingress node and are mapped back into the IP packet at the egress node.
    • S bit—One bit to indicate whether the label is on the bottom of the label stack.
    • TTL bits—Eight bits for a time-to-live indicator. The TTL bits are mapped from the IP packet at the ingress node. The TTL bits in the shim header are decremented at each hop. The bits are mapped back into the IP packet at the egress node. See TTL Processing in the Platform Label Space Overview for more information.

      Figure 4: Shim Header

      Shim Header

    If you configure an MPLS interface to use the interface label space, the VPI/VCI combinations are used as labels, so there is no need to place them within a shim header. As the data travels along the LSP, the LSRs examine only the VPI/VCI combination. The shim header is used only to carry the TTL bits to the egress, and is not visible to intermediate LSRs. The ingress node learns the total hop count from signaling and then uses that count to decrement the TTL to the correct final value. The TTL is then carried in the shim header to the egress node without modification, arriving with the correct count.

    Published: 2014-08-18