Network Working Group E. Rosen Request for Comments: 3031 Cisco Systems, Inc. Category: Standards Track A. Viswanathan Force10 Networks, Inc. R. Callon Juniper Networks, Inc. January 2001 Multiprotocol Label Switching Architecture Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document specifies the architecture for Multiprotocol Label Switching (MPLS). Table of Contents 1 Specification ...................................... 3 2 Introduction to MPLS ............................... 3 2.1 Overview ........................................... 4 2.2 Terminology ........................................ 6 2.3 Acronyms and Abbreviations ......................... 9 2.4 Acknowledgments .................................... 9 3 MPLS Basics ........................................ 9 3.1 Labels ............................................. 9 3.2 Upstream and Downstream LSRs ....................... 10 3.3 Labeled Packet ..................................... 11 3.4 Label Assignment and Distribution .................. 11 3.5 Attributes of a Label Binding ...................... 11 3.6 Label Distribution Protocols ....................... 11 3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12 3.8 Label Retention Mode ............................... 12 3.9 The Label Stack .................................... 13 3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 13 3.11 Incoming Label Map (ILM) ........................... 14 Rosen, et al. Standards Track [Page 1] RFC 3031 MPLS Architecture January 2001 3.12 FEC-to-NHLFE Map (FTN) ............................. 14 3.13 Label Swapping ..................................... 15 3.14 Scope and Uniqueness of Labels ..................... 15 3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 16 3.16 Penultimate Hop Popping ............................ 18 3.17 LSP Next Hop ....................................... 20 3.18 Invalid Incoming Labels ............................ 20 3.19 LSP Control: Ordered versus Independent ............ 20 3.20 Aggregation ........................................ 21 3.21 Route Selection .................................... 23 3.22 Lack of Outgoing Label ............................. 24 3.23 Time-to-Live (TTL) ................................. 24 3.24 Loop Control ....................................... 25 3.25 Label Encodings .................................... 26 3.25.1 MPLS-specific Hardware and/or Software ............. 26 3.25.2 ATM Switches as LSRs ............................... 26 3.25.3 Interoperability among Encoding Techniques ......... 28 3.26 Label Merging ...................................... 28 3.26.1 Non-merging LSRs ................................... 29 3.26.2 Labels for Merging and Non-Merging LSRs ............ 30 3.26.3 Merge over ATM ..................................... 31 3.26.3.1 Methods of Eliminating Cell Interleave ............. 31 3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 31 3.27 Tunnels and Hierarchy .............................. 32 3.27.1 Hop-by-Hop Routed Tunnel ........................... 32 3.27.2 Explicitly Routed Tunnel ........................... 33 3.27.3 LSP Tunnels ........................................ 33 3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 33 3.27.5 Label Distribution Peering and Hierarchy ........... 34 3.28 Label Distribution Protocol Transport .............. 35 3.29 Why More than one Label Distribution Protocol? ..... 36 3.29.1 BGP and LDP ........................................ 36 3.29.2 Labels for RSVP Flowspecs .......................... 36 3.29.3 Labels for Explicitly Routed LSPs .................. 36 3.30 Multicast .......................................... 37 4 Some Applications of MPLS .......................... 37 4.1 MPLS and Hop by Hop Routed Traffic ................. 37 4.1.1 Labels for Address Prefixes ........................ 37 4.1.2 Distributing Labels for Address Prefixes ........... 37 4.1.2.1 Label Distribution Peers for an Address Prefix ..... 37 4.1.2.2 Distributing Labels ................................ 38 4.1.3 Using the Hop by Hop path as the LSP ............... 39 4.1.4 LSP Egress and LSP Proxy Egress .................... 39 4.1.5 The Implicit NULL Label ............................ 40 4.1.6 Option: Egress-Targeted Label Assignment ........... 40 4.2 MPLS and Explicitly Routed LSPs .................... 42 4.2.1 Explicitly Routed LSP Tunnels ...................... 42 4.3 Label Stacks and Implicit Peering .................. 43 Rosen, et al. Standards Track [Page 2] RFC 3031 MPLS Architecture January 2001 4.4 MPLS and Multi-Path Routing ........................ 44 4.5 LSP Trees as Multipoint-to-Point Entities .......... 44 4.6 LSP Tunneling between BGP Border Routers ........... 45 4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 47 4.8 MPLS and Multicast ................................. 47 5 Label Distribution Procedures (Hop-by-Hop) ......... 47 5.1 The Procedures for Advertising and Using labels .... 48 5.1.1 Downstream LSR: Distribution Procedure ............. 48 5.1.1.1 PushUnconditional .................................. 49 5.1.1.2 PushConditional .................................... 49 5.1.1.3 PulledUnconditional ................................ 49 5.1.1.4 PulledConditional .................................. 50 5.1.2 Upstream LSR: Request Procedure .................... 51 5.1.2.1 RequestNever ....................................... 51 5.1.2.2 RequestWhenNeeded .................................. 51 5.1.2.3 RequestOnRequest ................................... 51 5.1.3 Upstream LSR: NotAvailable Procedure ............... 52 5.1.3.1 RequestRetry ....................................... 52 5.1.3.2 RequestNoRetry ..................................... 52 5.1.4 Upstream LSR: Release Procedure .................... 52 5.1.4.1 ReleaseOnChange .................................... 52 5.1.4.2 NoReleaseOnChange .................................. 53 5.1.5 Upstream LSR: labelUse Procedure ................... 53 5.1.5.1 UseImmediate ....................................... 53 5.1.5.2 UseIfLoopNotDetected ............................... 53 5.1.6 Downstream LSR: Withdraw Procedure ................. 53 5.2 MPLS Schemes: Supported Combinations of Procedures . 54 5.2.1 Schemes for LSRs that Support Label Merging ........ 55 5.2.2 Schemes for LSRs that do not Support Label Merging . 56 5.2.3 Interoperability Considerations .................... 57 6 Security Considerations ............................ 58 7 Intellectual Property .............................. 58 8 Authors' Addresses ................................. 59 9 References ......................................... 59 10 Full Copyright Statement ........................... 61 1. Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Introduction to MPLS This document specifies the architecture for Multiprotocol Label Switching (MPLS). Note that the use of MPLS for multicast is left for further study. Rosen, et al. Standards Track [Page 3] RFC 3031 MPLS Architecture January 2001 2.1. Overview As a packet of a connectionless network layer protocol travels from one router to the next, each router makes an independent forwarding decision for that packet. That is, each router analyzes the packet's header, and each router runs a network layer routing algorithm. Each router independently chooses a next hop for the packet, based on its analysis of the packet's header and the results of running the routing algorithm. Packet headers contain considerably more information than is needed simply to choose the next hop. Choosing the next hop can therefore be thought of as the composition of two functions. The first function partitions the entire set of possible packets into a set of "Forwarding Equivalence Classes (FECs)". The second maps each FEC to a next hop. Insofar as the forwarding decision is concerned, different packets which get mapped into the same FEC are indistinguishable. All packets which belong to a particular FEC and which travel from a particular node will follow the same path (or if certain kinds of multi-path routing are in use, they will all follow one of a set of paths associated with the FEC). In conventional IP forwarding, a particular router will typically consider two packets to be in the same FEC if there is some address prefix X in that router's routing tables such that X is the "longest match" for each packet's destination address. As the packet traverses the network, each hop in turn reexamines the packet and assigns it to a FEC. In MPLS, the assignment of a particular packet to a particular FEC is done just once, as the packet enters the network. The FEC to which the packet is assigned is encoded as a short fixed length value known as a "label". When a packet is forwarded to its next hop, the label is sent along with it; that is, the packets are "labeled" before they are forwarded. At subsequent hops, there is no further analysis of the packet's network layer header. Rather, the label is used as an index into a table which specifies the next hop, and a new label. The old label is replaced with the new label, and the packet is forwarded to its next hop. In the MPLS forwarding paradigm, once a packet is assigned to a FEC, no further header analysis is done by subsequent routers; all forwarding is driven by the labels. This has a number of advantages over conventional network layer forwarding. Rosen, et al. Standards Track [Page 4] RFC 3031 MPLS Architecture January 2001 - MPLS forwarding can be done by switches which are capable of doing label lookup and replacement, but are either not capable of analyzing the network layer headers, or are not capable of analyzing the network layer headers at adequate speed. - Since a packet is assigned to a FEC when it enters the network, the ingress router may use, in determining the assignment, any information it has about the packet, even if that information cannot be gleaned from the network layer header. For example, packets arriving on different ports may be assigned to different FECs. Conventional forwarding, on the other hand, can only consider information which travels with the packet in the packet header. - A packet that enters the network at a particular router can be labeled differently than the same packet entering the network at a different router, and as a result forwarding decisions that depend on the ingress router can be easily made. This cannot be done with conventional forwarding, since the identity of a packet's ingress router does not travel with the packet. - The considerations that determine how a packet is assigned to a FEC can become ever more and more complicated, without any impact at all on the routers that merely forward labeled packets. - Sometimes it is desirable to force a packet to follow a particular route which is explicitly chosen at or before the time the packet enters the network, rather than being chosen by the normal dynamic routing algorithm as the packet travels through the network. This may be done as a matter of policy, or to support traffic engineering. In conventional forwarding, this requires the packet to carry an encoding of its route along with it ("source routing"). In MPLS, a label can be used to represent the route, so that the identity of the explicit route need not be carried with the packet. Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label. In this case, one may say that the label represents the combination of a FEC and a precedence or class of service. Rosen, et al. Standards Track [Page 5] RFC 3031 MPLS Architecture January 2001 MPLS stands for "Multiprotocol" Label Switching, multiprotocol because its techniques are applicable to ANY network layer protocol. In this document, however, we focus on the use of IP as the network layer protocol. A router which supports MPLS is known as a "Label Switching Router", or LSR. 2.2. Terminology This section gives a general conceptual overview of the terms used in this document. Some of these terms are more precisely defined in later sections of the document. DLCI a label used in Frame Relay networks to identify frame relay circuits forwarding equivalence class a group of IP packets which are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment) frame merge label merging, when it is applied to operation over frame based media, so that the potential problem of cell interleave is not an issue. label a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance. label merging the replacement of multiple incoming labels for a particular FEC with a single outgoing label label swap the basic forwarding operation consisting of looking up an incoming label to determine the outgoing label, encapsulation, port, and other data handling information. label swapping a forwarding paradigm allowing streamlined forwarding of data by using labels to identify classes of data packets which are treated indistinguishably when forwarding. Rosen, et al. Standards Track [Page 6] RFC 3031 MPLS Architecture January 2001 label switched hop the hop between two MPLS nodes, on which forwarding is done using labels. label switched path The path through one or more LSRs at one level of the hierarchy followed by a packets in a particular FEC. label switching router an MPLS node which is capable of forwarding native L3 packets layer 2 the protocol layer under layer 3 (which therefore offers the services used by layer 3). Forwarding, when done by the swapping of short fixed length labels, occurs at layer 2 regardless of whether the label being examined is an ATM VPI/VCI, a frame relay DLCI, or an MPLS label. layer 3 the protocol layer at which IP and its associated routing protocols operate link layer synonymous with layer 2 loop detection a method of dealing with loops in which loops are allowed to be set up, and data may be transmitted over the loop, but the loop is later detected loop prevention a method of dealing with loops in which data is never transmitted over a loop label stack an ordered set of labels merge point a node at which label merging is done MPLS domain a contiguous set of nodes which operate MPLS routing and forwarding and which are also in one Routing or Administrative Domain MPLS edge node an MPLS node that connects an MPLS domain with a node which is outside of the domain, either because it does not run MPLS, and/or because it is in a different domain. Note that if an LSR has a neighboring host which is not running MPLS, that that LSR is an MPLS edge node. Rosen, et al. Standards Track [Page 7] RFC 3031 MPLS Architecture January 2001 MPLS egress node an MPLS edge node in its role in handling traffic as it leaves an MPLS domain MPLS ingress node an MPLS edge node in its role in handling traffic as it enters an MPLS domain MPLS label a label which is carried in a packet header, and which represents the packet's FEC MPLS node a node which is running MPLS. An MPLS node will be aware of MPLS control protocols, will operate one or more L3 routing protocols, and will be capable of forwarding packets based on labels. An MPLS node may optionally be also capable of forwarding native L3 packets. MultiProtocol Label Switching an IETF working group and the effort associated with the working group network layer synonymous with layer 3 stack synonymous with label stack switched path synonymous with label switched path virtual circuit a circuit used by a connection-oriented layer 2 technology such as ATM or Frame Relay, requiring the maintenance of state information in layer 2 switches. VC merge label merging where the MPLS label is carried in the ATM VCI field (or combined VPI/VCI field), so as to allow multiple VCs to merge into one single VC VP merge label merging where the MPLS label is carried din the ATM VPI field, so as to allow multiple VPs to be merged into one single VP. In this case two cells would have the same VCI value only if they originated from the same node. This allows cells from different sources to be distinguished via the VCI. Rosen, et al. Standards Track [Page 8] RFC 3031 MPLS Architecture January 2001 VPI/VCI a label used in ATM networks to identify circuits 2.3. Acronyms and Abbreviations ATM Asynchronous Transfer Mode BGP Border Gateway Protocol DLCI Data Link Circuit Identifier FEC Forwarding Equivalence Class FTN FEC to NHLFE Map IGP Interior Gateway Protocol ILM Incoming Label Map IP Internet Protocol LDP Label Distribution Protocol L2 Layer 2 L3 Layer 3 LSP Label Switched Path LSR Label Switching Router MPLS MultiProtocol Label Switching NHLFE Next Hop Label Forwarding Entry SVC Switched Virtual Circuit SVP Switched Virtual Path TTL Time-To-Live VC Virtual Circuit VCI Virtual Circuit Identifier VP Virtual Path VPI Virtual Path Identifier 2.4. Acknowledgments The ideas and text in this document have been collected from a number of sources and comments received. We would like to thank Rick Boivie, Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan, and George Swallow for their inputs and ideas. 3. MPLS Basics In this section, we introduce some of the basic concepts of MPLS and describe the general approach to be used. 3.1. Labels 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. Rosen, et al. Standards Track [Page 9] RFC 3031 MPLS Architecture January 2001 Most commonly, a packet is assigned to a FEC based (completely or partially) on its network layer destination address. However, the label is never an encoding of that address. If Ru and Rd are LSRs, they may agree that when Ru transmits a packet to Rd, Ru will label with packet with label value L if and only if the packet is a member of a particular FEC F. That is, they can agree to a "binding" between label L and FEC F for packets moving from Ru to Rd. As a result of such an agreement, L becomes Ru's "outgoing label" representing FEC F, and L becomes Rd's "incoming label" representing FEC F. Note that L does not necessarily represent FEC F for any packets other than those which are being sent from Ru to Rd. L is an arbitrary value whose binding to F is local to Ru and Rd. When we speak above of packets "being sent" from Ru to Rd, we do not imply either that the packet originated at Ru or that its destination is Rd. Rather, we mean to include packets which are "transit packets" at one or both of the LSRs. Sometimes it may be difficult or even impossible for Rd to tell, of an arriving packet carrying label L, that the label L was placed in the packet by Ru, rather than by some other LSR. (This will typically be the case when Ru and Rd are not direct neighbors.) In such cases, Rd must make sure that the binding from label to FEC is one-to-one. That is, Rd MUST NOT agree with Ru1 to bind L to FEC F1, while also agreeing with some other LSR Ru2 to bind L to a different FEC F2, UNLESS Rd can always tell, when it receives a packet with incoming label L, whether the label was put on the packet by Ru1 or whether it was put on by Ru2. It is the responsibility of each LSR to ensure that it can uniquely interpret its incoming labels. 3.2. Upstream and Downstream LSRs Suppose Ru and Rd have agreed to bind label L to FEC F, for packets sent from Ru to Rd. Then with respect to this binding, Ru is the "upstream LSR", and Rd is the "downstream LSR". To say that one node is upstream and one is downstream with respect to a given binding means only that a particular label represents a particular FEC in packets travelling from the upstream node to the downstream node. This is NOT meant to imply that packets in that FEC would actually be routed from the upstream node to the downstream node. Rosen, et al. Standards Track [Page 10] RFC 3031 MPLS Architecture January 2001 3.3. Labeled Packet A "labeled packet" is a packet into which a label has been encoded. In some cases, the label resides in an encapsulation header which exists specifically for this purpose. In other cases, the label may reside in an existing data link or network layer header, as long as there is a field which is available for that purpose. The particular encoding technique to be used must be agreed to by both the entity which encodes the label and the entity which decodes the label. 3.4. Label Assignment and Distribution In the MPLS architecture, the decision to bind a particular label L to a particular FEC F is made by the LSR which is DOWNSTREAM with respect to that binding. The downstream LSR then informs the upstream LSR of the binding. Thus labels are "downstream-assigned", and label bindings are distributed in the "downstream to upstream" direction. If an LSR has been designed so that it can only look up labels that fall into a certain numeric range, then it merely needs to ensure that it only binds labels that are in that range. 3.5. Attributes of a Label Binding A particular binding of label L to FEC F, distributed by Rd to Ru, may have associated "attributes". If Ru, acting as a downstream LSR, also distributes a binding of a label to FEC F, then under certain conditions, it may be required to also distribute the corresponding attribute that it received from Rd. 3.6. Label Distribution Protocols A label distribution protocol is a set of procedures by which one LSR informs another of the label/FEC bindings it has made. Two LSRs which use a label distribution protocol to exchange label/FEC binding information are known as "label distribution peers" with respect to the binding information they exchange. If two LSRs are label distribution peers, we will speak of there being a "label distribution adjacency" between them. (N.B.: two LSRs may be label distribution peers with respect to some set of bindings, but not with respect to some other set of bindings.) The label distribution protocol also encompasses any negotiations in which two label distribution peers need to engage in order to learn of each other's MPLS capabilities. Rosen, et al. Standards Track [Page 11] RFC 3031 MPLS Architecture January 2001 THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL DISTRIBUTION PROTOCOL. In fact, a number of different label distribution protocols are being standardized. Existing protocols have been extended so that label distribution can be piggybacked on them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). New protocols have also been defined for the explicit purpose of distributing labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP]. In this document, we try to use the acronym "LDP" to refer specifically to the protocol defined in [MPLS-LDP]; when speaking of label distribution protocols in general, we try to avoid the acronym. 3.7. Unsolicited Downstream vs. Downstream-on-Demand The MPLS architecture allows an LSR to explicitly request, from its next hop for a particular FEC, a label binding for that FEC. This is known as "downstream-on-demand" label distribution. The MPLS architecture also allows an LSR to distribute bindings to LSRs that have not explicitly requested them. This is known as "unsolicited downstream" label distribution. It is expected that some MPLS implementations will provide only downstream-on-demand label distribution, and some will provide only unsolicited downstream label distribution, and some will provide both. Which is provided may depend on the characteristics of the interfaces which are supported by a particular implementation. However, both of these label distribution techniques may be used in the same network at the same time. On any given label distribution adjacency, the upstream LSR and the downstream LSR must agree on which technique is to be used. 3.8. Label Retention Mode An LSR Ru may receive (or have received) a label binding for a particular FEC from an LSR Rd, even though Rd is not Ru's next hop (or is no longer Ru's next hop) for that FEC. Ru then has the choice of whether to keep track of such bindings, or whether to discard such bindings. If Ru keeps track of such bindings, then it may immediately begin using the binding again if Rd eventually becomes its next hop for the FEC in question. If Ru discards such bindings, then if Rd later becomes the next hop, the binding will have to be reacquired. Rosen, et al. Standards Track [Page 12] RFC 3031 MPLS Architecture January 2001 If an LSR supports "Liberal Label Retention Mode", it maintains the bindings between a label and a FEC which are received from LSRs which are not its next hop for that FEC. If an LSR supports "Conservative Label Retention Mode", it discards such bindings. Liberal label retention mode allows for quicker adaptation to routing changes, but conservative label retention mode though requires an LSR to maintain many fewer labels. 3.9. The Label Stack So far, we have spoken as if a labeled packet carries only a single label. As we shall see, it is useful to have a more general model in which a labeled packet carries a number of labels, organized as a last-in, first-out stack. We refer to this as a "label stack". Although, as we shall see, MPLS supports a hierarchy, the processing of a labeled packet is completely independent of the level of hierarchy. The processing is always based on the top label, without regard for the possibility that some number of other labels may have been "above it" in the past, or that some number of other labels may be below it at present. An unlabeled packet can be thought of as a packet whose label stack is empty (i.e., whose label stack has depth 0). If a packet's label stack is of depth m, we refer to the label at the bottom of the stack as the level 1 label, to the label above it (if such exists) as the level 2 label, and to the label at the top of the stack as the level m label. The utility of the label stack will become clear when we introduce the notion of LSP Tunnel and the MPLS Hierarchy (section 3.27). 3.10. The Next Hop Label Forwarding Entry (NHLFE) The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding a labeled packet. It contains the following information: 1. the packet's next hop 2. the operation to perform on the packet's label stack; this is one of the following operations: a) replace the label at the top of the label stack with a specified new label b) pop the label stack Rosen, et al. Standards Track [Page 13] RFC 3031 MPLS Architecture January 2001 c) replace the label at the top of the label stack with a specified new label, and then push one or more specified new labels onto the label stack. It may also contain: d) the data link encapsulation to use when transmitting the packet e) the way to encode the label stack when transmitting the packet f) any other information needed in order to properly dispose of the packet. Note that at a given LSR, the packet's "next hop" might be that LSR itself. In this case, the LSR would need to pop the top level label, and then "forward" the resulting packet to itself. It would then make another forwarding decision, based on what remains after the label stacked is popped. This may still be a labeled packet, or it may be the native IP packet. This implies that in some cases the LSR may need to operate on the IP header in order to forward the packet. If the packet's "next hop" is the current LSR, then the label stack operation MUST be to "pop the stack". 3.11. Incoming Label Map (ILM) The "Incoming Label Map" (ILM) maps each incoming label to a set of NHLFEs. It is used when forwarding packets that arrive as labeled packets. If the ILM maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM map a label to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths. 3.12. FEC-to-NHLFE Map (FTN) The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used when forwarding packets that arrive unlabeled, but which are to be labeled before being forwarded. Rosen, et al. Standards Track [Page 14] RFC 3031 MPLS Architecture January 2001 If the FTN maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the FTN map a label to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths. 3.13. Label Swapping Label swapping is the use of the following procedures to forward a packet. In order to forward a labeled packet, a LSR examines the label at the top of the label stack. It uses the ILM to map this label to an NHLFE. Using the information in the NHLFE, it determines where to forward the packet, and performs an operation on the packet's label stack. It then encodes the new label stack into the packet, and forwards the result. In order to forward an unlabeled packet, a LSR analyzes the network layer header, to determine the packet's FEC. It then uses the FTN to map this to an NHLFE. Using the information in the NHLFE, it determines where to forward the packet, and performs an operation on the packet's label stack. (Popping the label stack would, of course, be illegal in this case.) It then encodes the new label stack into the packet, and forwards the result. IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE. 3.14. Scope and Uniqueness of Labels A given LSR Rd may bind label L1 to FEC F, and distribute that binding to label distribution peer Ru1. Rd may also bind label L2 to FEC F, and distribute that binding to label distribution peer Ru2. Whether or not L1 == L2 is not determined by the architecture; this is a local matter. A given LSR Rd may bind label L to FEC F1, and distribute that binding to label distribution peer Ru1. Rd may also bind label L to FEC F2, and distribute that binding to label distribution peer Ru2. IF (AND ONLY IF) RD CAN TELL, WHEN IT RECEIVES A PACKET WHOSE TOP LABEL IS L, WHETHER THE LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN THE ARCHITECTURE DOES NOT REQUIRE THAT F1 == F2. In such cases, we may say that Rd is using a different "label space" for the labels it distributes to Ru1 than for the labels it distributes to Ru2. Rosen, et al. Standards Track [Page 15] RFC 3031 MPLS Architecture January 2001 In general, Rd can only tell whether it was Ru1 or Ru2 that put the particular label value L at the top of the label stack if the following conditions hold: - Ru1 and Ru2 are the only label distribution peers to which Rd distributed a binding of label value L, and - Ru1 and Ru2 are each directly connected to Rd via a point-to- point interface. When these conditions hold, an LSR may use labels that have "per interface" scope, i.e., which are only unique per interface. We may say that the LSR is using a "per-interface label space". When these conditions do not hold, the labels must be unique over the LSR which has assigned them, and we may say that the LSR is using a "per- platform label space." If a particular LSR Rd is attached to a particular LSR Ru over two point-to-point interfaces, then Rd may distribute to Ru a binding of label L to FEC F1, as well as a binding of label L to FEC F2, F1 != F2, if and only if each binding is valid only for packets which Ru sends to Rd over a particular one of the interfaces. In all other cases, Rd MUST NOT distribute to Ru bindings of the same label value to two different FECs. This prohibition holds even if the bindings are regarded as being at different "levels of hierarchy". In MPLS, there is no notion of having a different label space for different levels of the hierarchy; when interpreting a label, the level of the label is irrelevant. The question arises as to whether it is possible for an LSR to use multiple per-platform label spaces, or to use multiple per-interface label spaces for the same interface. This is not prohibited by the architecture. However, in such cases the LSR must have some means, not specified by the architecture, of determining, for a particular incoming label, which label space that label belongs to. For example, [MPLS-SHIM] specifies that a different label space is used for unicast packets than for multicast packets, and uses a data link layer codepoint to distinguish the two label spaces. 3.15. Label Switched Path (LSP), LSP Ingress, LSP Egress A "Label Switched Path (LSP) of level m" for a particular packet P is a sequence of routers, with the following properties: Rosen, et al. Standards Track [Page 16] RFC 3031 MPLS Architecture January 2001 1. R1, the "LSP Ingress", is an LSR which pushes a label onto P's label stack, resulting in a label stack of depth m; 2. For all i, 10). In other words, we can speak of the level m LSP for Packet P as the sequence of routers: 1. which begins with an LSR (an "LSP Ingress") that pushes on a level m label, 2. all of whose intermediate LSRs make their forwarding decision by label Switching on a level m label, 3. which ends (at an "LSP Egress") when a forwarding decision is made by label Switching on a level m-k label, where k>0, or when a forwarding decision is made by "ordinary", non-MPLS forwarding procedures. A consequence (or perhaps a presupposition) of this is that whenever an LSR pushes a label onto an already labeled packet, it needs to make sure that the new label corresponds to a FEC whose LSP Egress is the LSR that assigned the label which is now second in the stack. Rosen, et al. Standards Track [Page 17] RFC 3031 MPLS Architecture January 2001 We will call a sequence of LSRs the "LSP for a particular FEC F" if it is an LSP of level m for a particular packet P when P's level m label is a label corresponding to FEC F. Consider the set of nodes which may be LSP ingress nodes for FEC F. Then there is an LSP for FEC F which begins with each of those nodes. If a number of those LSPs have the same LSP egress, then one can consider the set of such LSPs to be a tree, whose root is the LSP egress. (Since data travels along this tree towards the root, this may be called a multipoint-to-point tree.) We can thus speak of the "LSP tree" for a particular FEC F. 3.16. Penultimate Hop Popping Note that according to the definitions of section 3.15, if is a level m LSP for packet P, P may be transmitted from R[n-1] to Rn with a label stack of depth m-1. That is, the label stack may be popped at the penultimate LSR of the LSP, rather than at the LSP Egress. From an architectural perspective, this is perfectly appropriate. The purpose of the level m label is to get the packet to Rn. Once R[n-1] has decided to send the packet to Rn, the label no longer has any function, and need no longer be carried. There is also a practical advantage to doing penultimate hop popping. If one does not do this, then when the LSP egress receives a packet, it first looks up the top label, and determines as a result of that lookup that it is indeed the LSP egress. Then it must pop the stack, and examine what remains of the packet. If there is another label on the stack, the egress will look this up and forward the packet based on this lookup. (In this case, the egress for the packet's level m LSP is also an intermediate node for its level m-1 LSP.) If there is no other label on the stack, then the packet is forwarded according to its network layer destination address. Note that this would require the egress to do TWO lookups, either two label lookups or a label lookup followed by an address lookup. If, on the other hand, penultimate hop popping is used, then when the penultimate hop looks up the label, it determines: - that it is the penultimate hop, and - who the next hop is. The penultimate node then pops the stack, and forwards the packet based on the information gained by looking up the label that was previously at the top of the stack. When the LSP egress receives the Rosen, et al. Standards Track [Page 18] RFC 3031 MPLS Architecture January 2001 packet, the label which is now at the top of the stack will be the label which it needs to look up in order to make its own forwarding decision. Or, if the packet was only carrying a single label, the LSP egress will simply see the network layer packet, which is just what it needs to see in order to make its forwarding decision. This technique allows the egress to do a single lookup, and also requires only a single lookup by the penultimate node. The creation of the forwarding "fastpath" in a label switching product may be greatly aided if it is known that only a single lookup is ever required: - the code may be simplified if it can assume that only a single lookup is ever needed - the code can be based on a "time budget" that assumes that only a single lookup is ever needed. In fact, when penultimate hop popping is done, the LSP Egress need not even be an LSR. However, some hardware switching engines may not be able to pop the label stack, so this cannot be universally required. There may also be some situations in which penultimate hop popping is not desirable. Therefore the penultimate node pops the label stack only if this is specifically requested by the egress node, OR if the next node in the LSP does not support MPLS. (If the next node in the LSP does support MPLS, but does not make such a request, the penultimate node has no way of knowing that it in fact is the penultimate node.) An LSR which is capable of popping the label stack at all MUST do penultimate hop popping when so requested by its downstream label distribution peer. Initial label distribution protocol negotiations MUST allow each LSR to determine whether its neighboring LSRS are capable of popping the label stack. A LSR MUST NOT request a label distribution peer to pop the label stack unless it is capable of doing so. It may be asked whether the egress node can always interpret the top label of a received packet properly if penultimate hop popping is used. As long as the uniqueness and scoping rules of section 3.14 are obeyed, it is always possible to interpret the top label of a received packet unambiguously. Rosen, et al. Standards Track [Page 19] RFC 3031 MPLS Architecture January 2001 3.17. LSP Next Hop The LSP Next Hop for a particular labeled packet in a particular LSR is the LSR which is the next hop, as selected by the NHLFE entry used for forwarding that packet. The LSP Next Hop for a particular FEC is the next hop as selected by the NHLFE ent