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:
Figure 47 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 47: Simple MPLS Domain
Each LSR, also known as an MPLS node, must have the following:
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 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 48. 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 48: 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 48, 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.
Figure 49 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 49: Label Stacking
The configuration shown in Figure 49 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 49 is a simplified example to illustrate the concept of label stacking. |
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 50):
Figure 50: 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.
JUNOSe MPLS TTL processing is compliant with RFC 3443. The details of TTL processing vary with the tunnel model that is configured for TTL processing, pipe or uniform.
To keep backward compatibility with earlier JUNOSe releases, you do not use the mpls tunnel-model command to configure the tunnel model for TTL processing, That command is used instead to configure the tunnel model for EXP bits processing. The default tunnel model varies between TTL and EXP processing; for EXP processing, the default tunnel model is pipe, while for TTL processing the default tunnel model is uniform.
You can issue the no mpls ip propagate-ttl command to change the TTL processing tunnel model from the default uniform model to the pipe model. Issue the no mpls ip propagate-ttl local command to set the tunnel model to pipe for locally originated packets. Issue the no mpls ip propagate-ttl forwarded command to set the tunnel model to pipe for forwarded packets.
The flow chart on Figure 51 (Figure 51) illustrates TTL processing on incoming MPLS packets. On a transit LSR or an egress LER, MPLS pops one or more labels and can push one or more labels. The incoming TTL of the packet is determined by the configured TTL processing tunnel model.
When all of the following conditions are met, the incoming TTL is set to the TTL value found in the immediate inner header:
If any of those conditions is not met, then the incoming TTL is set to the TTL value found in the outermost label. In all cases, the TTL values of any further inner labels are ignored.
When an IP packet is exposed after MPLS pops all the labels that should be popped, MPLS passes the packet to IP for further processing, including TTL checking. When the uniform tunnel model for TTL processing is in effect, MPLS sets the TTL value of the IP packet to the incoming TTL value that was just set. In other words, the TTL value is copied from the outermost label to the IP packet. When the pipe model for TTL processing is in effect, the TTL value in the IP header is left unchanged.
If an IP packet is not exposed by the label popping, then MPLS performs the TTL validation. If the incoming TTL is less than 2, the packet is dropped. If innermost packet is IP, an ICMP packet is built and sent. If the TTL does not expire and the packet needs to be sent out, the outgoing TTL is determined by the rules for outgoing MPLS packets.
Figure 51: TTL Processing on Incoming MPLS Packets
The flow chart on Figure 52 (Figure 52) illustrates TTL processing on outgoing MPLS packets.
On an LSR—where an MPLS packet is label-switched after processing on the line module—the TTL value in the swapped-to label is decremented by 1 from the incoming TTL value when the swapped-to label is not implicit-null. When the swapped-to label is implicit-null (for example, in a PHP configuration), the inner or exposed header's TTL is either left unchanged (when the forwarded option for the mpls ip propagate-ttl command has been configured) or is decremented by 1 from the incoming TTL value. If MPLS needs to push more labels, it sets the TTL for each label according to the following LER rules, because for those labels the router effectively is an ingress LER.
On an LER, when the packet is a locally originated IP packet, MPLS copies the TTL of all pushed MPLS labels from the IP header when the local option for the mpls ip propagate-ttl command has been configured. When the no mpls ip propagate-ttl local command has been configured, MPLS sets the TTL to 255.
When the packet is a forwarded IP or MPLS packet, MPLS copies the TTL of all pushed labels from the inner IP or MPLS header when the forwarded option for the mpls ip propagate-ttl command has been configured. When the no mpls ip propagate-ttl forwarded command has been configured, MPLS sets the TTL for these pushed labels to 255.
When the packet is neither IP nor MPLS, such as a Martini packet, MPLS sets the TTL of all pushed labels to 255.
Figure 52: TTL Processing on Outgoing MPLS Packets
MPLS takes the following actions when the TTL in a MPLS label of a received MPLS packet expires:
The ICMP packet is label-switched to the end of the LSP. From that location, the packet is forwarded back to the source of the IP packet. This behavior enables IP trace-route to work even when the LSR in the middle of the LSP does not have an IP route to the source address of the IP packet.
 | Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |