--- 1/draft-ietf-mpls-arch-05.txt 2006-02-05 00:37:11.000000000 +0100 +++ 2/draft-ietf-mpls-arch-06.txt 2006-02-05 00:37:11.000000000 +0100 @@ -1,24 +1,24 @@ Network Working Group Eric C. Rosen Internet Draft Cisco Systems, Inc. -Expiration Date: October 1999 +Expiration Date: February 2000 Arun Viswanathan Lucent Technologies Ross Callon IronBridge Networks, Inc. - April 1999 + August 1999 Multiprotocol Label Switching Architecture - draft-ietf-mpls-arch-05.txt + draft-ietf-mpls-arch-06.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -34,123 +34,135 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This internet draft specifies the architecture for Multiprotocol Label Switching (MPLS). Table of Contents - 1 Introduction to MPLS ............................... 4 - 1.1 Overview ........................................... 4 - 1.2 Terminology ........................................ 6 - 1.3 Acronyms and Abbreviations ......................... 9 - 1.4 Acknowledgments .................................... 10 - 2 MPLS Basics ........................................ 10 - 2.1 Labels ............................................. 10 - 2.2 Upstream and Downstream LSRs ....................... 11 - 2.3 Labeled Packet ..................................... 11 - 2.4 Label Assignment and Distribution .................. 11 - 2.5 Attributes of a Label Binding ...................... 12 - 2.6 Label Distribution Protocols ....................... 12 - 2.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12 - 2.8 Label Retention Mode ............................... 13 - 2.9 The Label Stack .................................... 13 - 2.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 14 - 2.11 Incoming Label Map (ILM) ........................... 15 - 2.12 FEC-to-NHLFE Map (FTN) ............................. 15 - 2.13 Label Swapping ..................................... 15 - 2.14 Scope and Uniqueness of Labels ..................... 16 - 2.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 17 - 2.16 Penultimate Hop Popping ............................ 19 - 2.17 LSP Next Hop ....................................... 20 - 2.18 Invalid Incoming Labels ............................ 21 - 2.19 LSP Control: Ordered versus Independent ............ 21 - 2.20 Aggregation ........................................ 22 - 2.21 Route Selection .................................... 24 - 2.22 Lack of Outgoing Label ............................. 24 - 2.23 Time-to-Live (TTL) ................................. 25 - 2.24 Loop Control ....................................... 26 - 2.25 Label Encodings .................................... 27 - 2.25.1 MPLS-specific Hardware and/or Software ............. 27 - 2.25.2 ATM Switches as LSRs ............................... 27 - 2.25.3 Interoperability among Encoding Techniques ......... 29 - 2.26 Label Merging ...................................... 29 - 2.26.1 Non-merging LSRs ................................... 30 - 2.26.2 Labels for Merging and Non-Merging LSRs ............ 31 - 2.26.3 Merge over ATM ..................................... 32 - 2.26.3.1 Methods of Eliminating Cell Interleave ............. 32 - 2.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 32 - 2.27 Tunnels and Hierarchy .............................. 33 - 2.27.1 Hop-by-Hop Routed Tunnel ........................... 34 - 2.27.2 Explicitly Routed Tunnel ........................... 34 - 2.27.3 LSP Tunnels ........................................ 34 - 2.27.4 Hierarchy: LSP Tunnels within LSPs ................. 35 - 2.27.5 Label Distribution Peering and Hierarchy ........... 35 - 2.28 Label Distribution Protocol Transport .............. 37 - 2.29 Why More than one Label Distribution Protocol? ..... 37 - 2.29.1 BGP and LDP ........................................ 37 - 2.29.2 Labels for RSVP Flowspecs .......................... 37 - 2.29.3 Labels for Explicitly Routed LSPs .................. 38 - 2.30 Multicast .......................................... 38 - 3 Some Applications of MPLS .......................... 38 - 3.1 MPLS and Hop by Hop Routed Traffic ................. 38 - 3.1.1 Labels for Address Prefixes ........................ 38 - 3.1.2 Distributing Labels for Address Prefixes ........... 39 - 3.1.2.1 Label Distribution Peers for an Address Prefix ..... 39 - 3.1.2.2 Distributing Labels ................................ 39 - 3.1.3 Using the Hop by Hop path as the LSP ............... 40 - 3.1.4 LSP Egress and LSP Proxy Egress .................... 41 - 3.1.5 The Implicit NULL Label ............................ 41 - 3.1.6 Option: Egress-Targeted Label Assignment ........... 42 - 3.2 MPLS and Explicitly Routed LSPs .................... 44 - 3.2.1 Explicitly Routed LSP Tunnels ...................... 44 - 3.3 Label Stacks and Implicit Peering .................. 45 - 3.4 MPLS and Multi-Path Routing ........................ 46 - 3.5 LSP Trees as Multipoint-to-Point Entities .......... 46 - 3.6 LSP Tunneling between BGP Border Routers ........... 47 - 3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 49 - 3.8 MPLS and Multicast ................................. 49 - 4 Label Distribution Procedures (Hop-by-Hop) ......... 50 - 4.1 The Procedures for Advertising and Using labels .... 50 - 4.1.1 Downstream LSR: Distribution Procedure ............. 50 - 4.1.1.1 PushUnconditional .................................. 51 - 4.1.1.2 PushConditional .................................... 51 - 4.1.1.3 PulledUnconditional ................................ 52 - 4.1.1.4 PulledConditional .................................. 52 - 4.1.2 Upstream LSR: Request Procedure .................... 53 - 4.1.2.1 RequestNever ....................................... 53 - 4.1.2.2 RequestWhenNeeded .................................. 53 - 4.1.2.3 RequestOnRequest ................................... 54 - 4.1.3 Upstream LSR: NotAvailable Procedure ............... 54 - 4.1.3.1 RequestRetry ....................................... 54 - 4.1.3.2 RequestNoRetry ..................................... 54 - 4.1.4 Upstream LSR: Release Procedure .................... 55 - 4.1.4.1 ReleaseOnChange .................................... 55 - 4.1.4.2 NoReleaseOnChange .................................. 55 - 4.1.5 Upstream LSR: labelUse Procedure ................... 55 - 4.1.5.1 UseImmediate ....................................... 56 - 4.1.5.2 UseIfLoopNotDetected ............................... 56 - 4.1.6 Downstream LSR: Withdraw Procedure ................. 56 - 4.2 MPLS Schemes: Supported Combinations of Procedures . 57 - 4.2.1 Schemes for LSRs that Support Label Merging ........ 57 - 4.2.2 Schemes for LSRs that do not Support Label Merging . 58 - 4.2.3 Interoperability Considerations .................... 59 - 5 Security Considerations ............................ 61 - 6 Intellectual Property .............................. 61 - 7 Authors' Addresses ................................. 61 - 8 References ......................................... 62 + 1 Specification ...................................... 4 + 2 Introduction to MPLS ............................... 4 + 2.1 Overview ........................................... 4 + 2.2 Terminology ........................................ 6 + 2.3 Acronyms and Abbreviations ......................... 9 + 2.4 Acknowledgments .................................... 10 + 3 MPLS Basics ........................................ 10 + 3.1 Labels ............................................. 10 + 3.2 Upstream and Downstream LSRs ....................... 11 + 3.3 Labeled Packet ..................................... 11 + 3.4 Label Assignment and Distribution .................. 12 + 3.5 Attributes of a Label Binding ...................... 12 + 3.6 Label Distribution Protocols ....................... 12 + 3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 13 + 3.8 Label Retention Mode ............................... 13 + 3.9 The Label Stack .................................... 14 + 3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 14 + 3.11 Incoming Label Map (ILM) ........................... 15 + 3.12 FEC-to-NHLFE Map (FTN) ............................. 15 + 3.13 Label Swapping ..................................... 16 + 3.14 Scope and Uniqueness of Labels ..................... 16 + 3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 17 + 3.16 Penultimate Hop Popping ............................ 19 + 3.17 LSP Next Hop ....................................... 21 + 3.18 Invalid Incoming Labels ............................ 21 + 3.19 LSP Control: Ordered versus Independent ............ 21 + 3.20 Aggregation ........................................ 22 + 3.21 Route Selection .................................... 24 + 3.22 Lack of Outgoing Label ............................. 25 + 3.23 Time-to-Live (TTL) ................................. 25 + 3.24 Loop Control ....................................... 26 + 3.25 Label Encodings .................................... 27 + 3.25.1 MPLS-specific Hardware and/or Software ............. 27 + 3.25.2 ATM Switches as LSRs ............................... 27 + 3.25.3 Interoperability among Encoding Techniques ......... 29 + 3.26 Label Merging ...................................... 30 + 3.26.1 Non-merging LSRs ................................... 31 + 3.26.2 Labels for Merging and Non-Merging LSRs ............ 31 + 3.26.3 Merge over ATM ..................................... 32 + 3.26.3.1 Methods of Eliminating Cell Interleave ............. 32 + 3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 33 + 3.27 Tunnels and Hierarchy .............................. 34 + 3.27.1 Hop-by-Hop Routed Tunnel ........................... 34 + 3.27.2 Explicitly Routed Tunnel ........................... 34 + 3.27.3 LSP Tunnels ........................................ 34 + 3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 35 + 3.27.5 Label Distribution Peering and Hierarchy ........... 35 + 3.28 Label Distribution Protocol Transport .............. 37 + 3.29 Why More than one Label Distribution Protocol? ..... 37 + 3.29.1 BGP and LDP ........................................ 37 + 3.29.2 Labels for RSVP Flowspecs .......................... 37 + 3.29.3 Labels for Explicitly Routed LSPs .................. 38 + 3.30 Multicast .......................................... 38 + 4 Some Applications of MPLS .......................... 38 + 4.1 MPLS and Hop by Hop Routed Traffic ................. 38 + 4.1.1 Labels for Address Prefixes ........................ 38 + 4.1.2 Distributing Labels for Address Prefixes ........... 39 + 4.1.2.1 Label Distribution Peers for an Address Prefix ..... 39 + 4.1.2.2 Distributing Labels ................................ 39 + 4.1.3 Using the Hop by Hop path as the LSP ............... 40 + 4.1.4 LSP Egress and LSP Proxy Egress .................... 41 + 4.1.5 The Implicit NULL Label ............................ 41 + 4.1.6 Option: Egress-Targeted Label Assignment ........... 42 + 4.2 MPLS and Explicitly Routed LSPs .................... 44 + 4.2.1 Explicitly Routed LSP Tunnels ...................... 44 + 4.3 Label Stacks and Implicit Peering .................. 45 + 4.4 MPLS and Multi-Path Routing ........................ 46 + 4.5 LSP Trees as Multipoint-to-Point Entities .......... 46 + 4.6 LSP Tunneling between BGP Border Routers ........... 47 + 4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 49 + 4.8 MPLS and Multicast ................................. 49 + 5 Label Distribution Procedures (Hop-by-Hop) ......... 50 + 5.1 The Procedures for Advertising and Using labels .... 50 + 5.1.1 Downstream LSR: Distribution Procedure ............. 50 + 5.1.1.1 PushUnconditional .................................. 51 + 5.1.1.2 PushConditional .................................... 51 + 5.1.1.3 PulledUnconditional ................................ 52 + 5.1.1.4 PulledConditional .................................. 52 + 5.1.2 Upstream LSR: Request Procedure .................... 53 + 5.1.2.1 RequestNever ....................................... 53 + 5.1.2.2 RequestWhenNeeded .................................. 53 + 5.1.2.3 RequestOnRequest ................................... 54 + 5.1.3 Upstream LSR: NotAvailable Procedure ............... 54 + 5.1.3.1 RequestRetry ....................................... 54 + 5.1.3.2 RequestNoRetry ..................................... 54 + 5.1.4 Upstream LSR: Release Procedure .................... 55 + 5.1.4.1 ReleaseOnChange .................................... 55 + 5.1.4.2 NoReleaseOnChange .................................. 55 + 5.1.5 Upstream LSR: labelUse Procedure ................... 55 + 5.1.5.1 UseImmediate ....................................... 56 + 5.1.5.2 UseIfLoopNotDetected ............................... 56 + 5.1.6 Downstream LSR: Withdraw Procedure ................. 56 + 5.2 MPLS Schemes: Supported Combinations of Procedures . 57 + 5.2.1 Schemes for LSRs that Support Label Merging ........ 57 + 5.2.2 Schemes for LSRs that do not Support Label Merging . 58 + 5.2.3 Interoperability Considerations .................... 59 + 6 Security Considerations ............................ 61 + 7 Intellectual Property .............................. 61 + 8 Authors' Addresses ................................. 61 + 9 References ......................................... 62 -1. Introduction to MPLS +1. Specification -1.1. Overview + 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 internet draft specifies the architecture for Multiprotocol + Label Switching (MPLS). + + Note that the use of MPLS for multicast is left for further study. + +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 @@ -239,29 +251,28 @@ 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. A general discussion of issues related to MPLS is presented in "A Framework for Multiprotocol Label Switching" [MPLS-FRMWRK]. -1.2. Terminology +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. @@ -375,21 +387,21 @@ 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. VPI/VCI a label used in ATM networks to identify circuits -1.3. Acronyms and Abbreviations +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 @@ -399,33 +411,33 @@ 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 -1.4. Acknowledgments +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. -2. MPLS Basics +3. MPLS Basics In this section, we introduce some of the basic concepts of MPLS and describe the general approach to be used. -2.1. Labels +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. 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. @@ -453,65 +465,65 @@ 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. -2.2. Upstream and Downstream LSRs +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. -2.3. Labeled Packet +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. -2.4. Label Assignment and Distribution +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. -2.5. Attributes of a Label Binding +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. -2.6. Label Distribution Protocols +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 @@ -526,41 +538,41 @@ 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], [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. -2.7. Unsolicited Downstream vs. Downstream-on-Demand +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. -2.8. Label Retention Mode +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 @@ -568,21 +580,21 @@ 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. -2.9. The Label Stack +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 @@ -591,23 +603,23 @@ 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 2.27). + the notion of LSP Tunnel and the MPLS Hierarchy (section 3.27). -2.10. The Next Hop Label Forwarding Entry (NHLFE) +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 @@ -634,49 +646,49 @@ 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". -2.11. Incoming Label Map (ILM) +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. -2.12. FEC-to-NHLFE Map (FTN) +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. 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. -2.13. Label Swapping +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. @@ -686,21 +698,21 @@ 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. -2.14. Scope and Uniqueness of Labels +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. @@ -743,21 +755,21 @@ 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. -2.15. Label Switched Path (LSP), LSP Ingress, LSP Egress +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: 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; @@ -809,23 +822,23 @@ 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. -2.16. Penultimate Hop Popping +3.16. Penultimate Hop Popping - Note that according to the definitions of section 2.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. @@ -887,58 +900,58 @@ 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 2.14 + 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. -2.17. LSP Next Hop +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 entry indexed by a label which corresponds to that FEC. Note that the LSP Next Hop may differ from the next hop which would be chosen by the network layer routing algorithm. We will use the term "L3 next hop" when we refer to the latter. -2.18. Invalid Incoming Labels +3.18. Invalid Incoming Labels What should an LSR do if it receives a labeled packet with a particular incoming label, but has no binding for that label? It is tempting to think that the labels can just be removed, and the packet forwarded as an unlabeled IP packet. However, in some cases, doing so could cause a loop. If the upstream LSR thinks the label is bound to an explicit route, and the downstream LSR doesn't think the label is bound to anything, and if the hop by hop routing of the unlabeled IP packet brings the packet back to the upstream LSR, then a loop is formed. It is also possible that the label was intended to represent a route which cannot be inferred from the IP header. Therefore, when a labeled packet is received with an invalid incoming label, it MUST be discarded, UNLESS it is determined by some means (not within the scope of the current document) that forwarding it unlabeled cannot cause any harm. -2.19. LSP Control: Ordered versus Independent +3.19. LSP Control: Ordered versus Independent Some FECs correspond to address prefixes which are distributed via a dynamic routing algorithm. The setup of the LSPs for these FECs can be done in one of two ways: Independent LSP Control or Ordered LSP Control. In Independent LSP Control, each LSR, upon noting that it recognizes a particular FEC, makes an independent decision to bind a label to that FEC and to distribute that binding to its label distribution peers. This corresponds to the way that conventional IP datagram @@ -971,21 +984,21 @@ control, since one cannot be sure that an LSP is not used until it is fully set up. This architecture allows the choice between independent control and ordered control to be a local matter. Since the two methods interwork, a given LSR need support only one or the other. Generally speaking, the choice of independent versus ordered control does not appear to have any effect on the label distribution mechanisms which need to be defined. -2.20. Aggregation +3.20. Aggregation One way of partitioning traffic into FECs is to create a separate FEC for each address prefix which appears in the routing table. However, within a particular MPLS domain, this may result in a set of FECs such that all traffic in all those FECs follows the same route. For example, a set of distinct address prefixes might all have the same egress node, and label swapping might be used only to get the the traffic to the egress node. In this case, within the MPLS domain, the union of those FECs is itself a FEC. This creates a choice: should a distinct label be bound to each component FEC, or should a @@ -1046,21 +1058,21 @@ In any event, every LSR needs to know (by configuration) what granularity to use for labels that it assigns. Where ordered control is used, this requires each node to know the granularity only for FECs which leave the MPLS network at that node. For independent control, best results may be obtained by ensuring that all LSRs are consistently configured to know the granularity for each FEC. However, in many cases this may be done by using a single level of granularity which applies to all FECs (such as "one label per IP prefix in the forwarding table", or "one label per egress node"). -2.21. Route Selection +3.21. Route Selection Route selection refers to the method used for selecting the LSP for a particular FEC. The proposed MPLS protocol architecture supports two options for Route Selection: (1) hop by hop routing, and (2) explicit routing. Hop by hop routing allows each node to independently choose the next hop for each FEC. This is the usual mode today in existing IP networks. A "hop by hop routed LSP" is an LSP whose route is selected using hop by hop routing. @@ -1081,21 +1093,21 @@ Explicit routing may be useful for a number of purposes, such as policy routing or traffic engineering. In MPLS, the explicit route needs to be specified at the time that labels are assigned, but the explicit route does not have to be specified with each IP packet. This makes MPLS explicit routing much more efficient than the alternative of IP source routing. The procedures for making use of explicit routes, either strict or loose, are beyond the scope of this document. -2.22. Lack of Outgoing Label +3.22. Lack of Outgoing Label When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop. It is tempting in such cases to strip off the label stack and attempt to forward the packet further via conventional forwarding, based on its network layer header. However, in general this is not a safe @@ -1104,21 +1116,21 @@ - If the packet has been following an explicitly routed LSP, this could result in a loop. - The packet's network header may not contain enough information to enable this particular LSR to forward it correctly. Unless it can be determined (through some means outside the scope of this document) that neither of these situations obtains, the only safe procedure is to discard the packet. -2.23. Time-to-Live (TTL) +3.23. Time-to-Live (TTL) In conventional IP forwarding, each packet carries a "Time To Live" (TTL) value in its header. Whenever a packet passes through a router, its TTL gets decremented by 1; if the TTL reaches 0 before the packet has reached its destination, the packet gets discarded. This provides some level of protection against forwarding loops that may exist due to misconfigurations, or due to failure or slow convergence of the routing algorithm. TTL is sometimes used for other functions as well, such as multicast scoping, and supporting the @@ -1161,21 +1173,21 @@ TTL value before forwarding packets into a non-TTL LSP segment. Sometimes it can be determined, upon ingress to a non-TTL LSP segment, that a particular packet's TTL will expire before the packet reaches the egress of that non-TTL LSP segment. In this case, the LSR at the ingress to the non-TTL LSP segment must not label switch the packet. This means that special procedures must be developed to support traceroute functionality, for example, traceroute packets may be forwarded using conventional hop by hop forwarding. -2.24. Loop Control +3.24. Loop Control On a non-TTL LSP segment, by definition, TTL cannot be used to protect against forwarding loops. The importance of loop control may depend on the particular hardware being used to provide the LSR functions along the non-TTL LSP segment. Suppose, for instance, that ATM switching hardware is being used to provide MPLS switching functions, with the label being carried in the VPI/VCI field. Since ATM switching hardware cannot decrement TTL, there is no protection against loops. If the ATM hardware is capable @@ -1188,45 +1200,45 @@ Even if fair buffer access can be provided, it is still worthwhile to have some means of detecting loops that last "longer than possible". In addition, even where TTL and/or per-VC fair queuing provides a means for surviving loops, it still may be desirable where practical to avoid setting up LSPs which loop. All LSRs that may attach to non-TTL LSP segments will therefore be required to support a common technique for loop detection; however, use of the loop detection technique is optional. The loop detection technique is specified in [MPLS-ATM] and [MPLS-LDP]. -2.25. Label Encodings +3.25. Label Encodings In order to transmit a label stack along with the packet whose label stack it is, it is necessary to define a concrete encoding of the label stack. The architecture supports several different encoding techniques; the choice of encoding technique depends on the particular kind of device being used to forward labeled packets. -2.25.1. MPLS-specific Hardware and/or Software +3.25.1. MPLS-specific Hardware and/or Software If one is using MPLS-specific hardware and/or software to forward labeled packets, the most obvious way to encode the label stack is to define a new protocol to be used as a "shim" between the data link layer and network layer headers. This shim would really be just an encapsulation of the network layer packet; it would be "protocol- independent" such that it could be used to encapsulate any network layer. Hence we will refer to it as the "generic MPLS encapsulation". The generic MPLS encapsulation would in turn be encapsulated in a data link layer protocol. The MPLS generic encapsulation is specified in [MPLS-SHIM]. -2.25.2. ATM Switches as LSRs +3.25.2. ATM Switches as LSRs It will be noted that MPLS forwarding procedures are similar to those of legacy "label swapping" switches such as ATM switches. ATM switches use the input port and the incoming VPI/VCI value as the index into a "cross-connect" table, from which they obtain an output port and an outgoing VPI/VCI value. Therefore if one or more labels can be encoded directly into the fields which are accessed by these legacy switches, then the legacy switches can, with suitable software upgrades, be used as LSRs. We will refer to such devices as "ATM- LSRs". @@ -1264,37 +1276,37 @@ 3. SVP Multipoint Encoding Use the VPI field to encode the label which is at the top of the label stack, use part of the VCI field to encode the second label on the stack, if one is present, and use the remainder of the VCI field to identify the LSP ingress. If this technique is used, conventional ATM VP-switching capabilities can be used to provide multipoint-to-point VPs. Cells from different packets will then carry different VCI values. As we shall see - in section 2.26, this enables us to do label merging, without + in section 3.26, this enables us to do label merging, without running into any cell interleaving problems, on ATM switches which can provide multipoint-to-point VPs, but which do not have the VC merge capability. This technique depends on the existence of a capability for assigning 16-bit VCI values to each ATM switch such that no single VCI value is assigned to two different switches. (If an adequate number of such values could be assigned to each switch, it would be possible to also treat the VCI value as the second label in the stack.) If there are more labels on the stack than can be encoded in the ATM header, the ATM encodings must be combined with the generic encapsulation. -2.25.3. Interoperability among Encoding Techniques +3.25.3. Interoperability among Encoding Techniques If is a segment of a LSP, it is possible that R1 will use one encoding of the label stack when transmitting packet P to R2, but R2 will use a different encoding when transmitting a packet P to R3. In general, the MPLS architecture supports LSPs with different label stack encodings used on different hops. Therefore, when we discuss the procedures for processing a labeled packet, we speak in abstract terms of operating on the packet's label stack. When a labeled packet is received, the LSR must decode it to determine the current value of the label stack, then must operate on the label @@ -1310,21 +1322,21 @@ Naturally there will be MPLS networks which contain a combination of ATM switches operating as LSRs, and other LSRs which operate using an MPLS shim header. In such networks there may be some LSRs which have ATM interfaces as well as "MPLS Shim" interfaces. This is one example of an LSR with different label stack encodings on different hops. Such an LSR may swap off an ATM encoded label stack on an incoming interface and replace it with an MPLS shim header encoded label stack on the outgoing interface. -2.26. Label Merging +3.26. Label Merging Suppose that an LSR has bound multiple incoming labels to a particular FEC. When forwarding packets in that FEC, one would like to have a single outgoing label which is applied to all such packets. The fact that two different packets in the FEC arrived with different incoming labels is irrelevant; one would like to forward them with the same outgoing label. The capability to do so is known as "label merging". Let us say that an LSR is capable of label merging if it can receive @@ -1358,21 +1370,21 @@ particular FEC. The MPLS architecture accommodates both merging and non-merging LSRs, but allows for the fact that there may be LSRs which do not support label merging. This leads to the issue of ensuring correct interoperation between merging LSRs and non-merging LSRs. The issue is somewhat different in the case of datagram media versus the case of ATM. The different media types will therefore be discussed separately. -2.26.1. Non-merging LSRs +3.26.1. Non-merging LSRs The MPLS forwarding procedures is very similar to the forwarding procedures used by such technologies as ATM and Frame Relay. That is, a unit of data arrives, a label (VPI/VCI or DLCI) is looked up in a "cross-connect table", on the basis of that lookup an output port is chosen, and the label value is rewritten. In fact, it is possible to use such technologies for MPLS forwarding; a label distribution protocol can be used as the "signalling protocol" for setting up the cross-connect tables. @@ -1387,21 +1399,21 @@ reassemble the packets. We propose to support two solutions to this problem. First, MPLS will contain procedures which allow the use of non-merging LSRs. Second, MPLS will support procedures which allow certain ATM switches to function as merging LSRs. Since MPLS supports both merging and non-merging LSRs, MPLS also contains procedures to ensure correct interoperation between them. -2.26.2. Labels for Merging and Non-Merging LSRs +3.26.2. Labels for Merging and Non-Merging LSRs An upstream LSR which supports label merging needs to be sent only one label per FEC. An upstream neighbor which does not support label merging needs to be sent multiple labels per FEC. However, there is no way of knowing a priori how many labels it needs. This will depend on how many LSRs are upstream of it with respect to the FEC in question. In the MPLS architecture, if a particular upstream neighbor does not support label merging, it is not sent any labels for a particular FEC @@ -1416,23 +1428,23 @@ merging, but can only merge a limited number of incoming labels into a single outgoing label. Suppose for example that due to some hardware limitation a node is capable of merging four incoming labels into a single outgoing label. Suppose however, that this particular node has six incoming labels arriving at it for a particular FEC. In this case, this node may merge these into two outgoing labels. Whether label merging is applicable to explicitly routed LSPs is for further study. -2.26.3. Merge over ATM +3.26.3. Merge over ATM -2.26.3.1. Methods of Eliminating Cell Interleave +3.26.3.1. Methods of Eliminating Cell Interleave There are several methods that can be used to eliminate the cell interleaving problem in ATM, thereby allowing ATM switches to support stream merge: 1. VP merge, using the SVP Multipoint Encoding When VP merge is used, multiple virtual paths are merged into a virtual path, but packets from different sources are distinguished by using different VCIs within the VP. @@ -1451,21 +1463,21 @@ disadvantage that it requires coordination of the VCI space within each VP. There are a number of ways that this can be accomplished. Selection of one or more methods is for further study. This tradeoff between compatibility with existing equipment versus protocol complexity and scalability implies that it is desirable for the MPLS protocol to support both VP merge and VC merge. In order to do so each ATM switch participating in MPLS needs to know whether its immediate ATM neighbors perform VP merge, VC merge, or no merge. -2.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge +3.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge The interoperation of the various forms of merging over ATM is most easily described by first describing the interoperation of VC merge with non-merge. In the case where VC merge and non-merge nodes are interconnected the forwarding of cells is based in all cases on a VC (i.e., the concatenation of the VPI and VCI). For each node, if an upstream neighbor is doing VC merge then that upstream neighbor requires only a single VPI/VCI for a particular stream (this is analogous to the @@ -1494,46 +1506,46 @@ of VCs (identified by a set of VCIs which are significant within a VP). VP merge nodes would therefore request one VP, with a contained VCI for traffic that it originates (if appropriate) plus a VCI for each VC requested from above (regardless of whether or not the VC is part of a containing VP). VC merge node would request only a single VPI/VCI (since they can merge all upstream traffic into a single VC). Non-merge nodes would pass on any requests that they get from above, plus request a VPI/VCI for traffic that they originate (if appropriate). -2.27. Tunnels and Hierarchy +3.27. Tunnels and Hierarchy Sometimes a router Ru takes explicit action to cause a particular packet to be delivered to another router Rd, even though Ru and Rd are not consecutive routers on the Hop-by-hop path for that packet, and Rd is not the packet's ultimate destination. For example, this may be done by encapsulating the packet inside a network layer packet whose destination address is the address of Rd itself. This creates a "tunnel" from Ru to Rd. We refer to any packet so handled as a "Tunneled Packet". -2.27.1. Hop-by-Hop Routed Tunnel +3.27.1. Hop-by-Hop Routed Tunnel If a Tunneled Packet follows the Hop-by-hop path from Ru to Rd, we say that it is in an "Hop-by-Hop Routed Tunnel" whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd. -2.27.2. Explicitly Routed Tunnel +3.27.2. Explicitly Routed Tunnel If a Tunneled Packet travels from Ru to Rd over a path other than the Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel" whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd. For example, we might send a packet through an Explicitly Routed Tunnel by encapsulating it in a packet which is source routed. -2.27.3. LSP Tunnels +3.27.3. LSP Tunnels It is possible to implement a tunnel as a LSP, and use label switching rather than network layer encapsulation to cause the packet to travel through the tunnel. The tunnel would be a LSP , where R1 is the transmit endpoint of the tunnel, and Rn is the receive endpoint of the tunnel. This is called a "LSP Tunnel". The set of packets which are to be sent though the LSP tunnel constitutes a FEC, and each LSR in the tunnel must assign a label to that FEC (i.e., must assign a label to the tunnel). The criteria for @@ -1547,21 +1559,21 @@ discussed earlier, the label stack may be popped at the penultimate LSR in the tunnel. A "Hop-by-Hop Routed LSP Tunnel" is a Tunnel that is implemented as an hop-by-hop routed LSP between the transmit endpoint and the receive endpoint. An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an Explicitly Routed LSP. -2.27.4. Hierarchy: LSP Tunnels within LSPs +3.27.4. Hierarchy: LSP Tunnels within LSPs Consider a LSP . Let us suppose that R1 receives unlabeled packet P, and pushes on its label stack the label to cause it to follow this path, and that this is in fact the Hop-by-hop path. However, let us further suppose that R2 and R3 are not directly connected, but are "neighbors" by virtue of being the endpoints of an LSP tunnel. So the actual sequence of LSRs traversed by P is . When P travels from R1 to R2, it will have a label stack of depth 1. @@ -1570,29 +1582,29 @@ to R3. Then it pushes on a new label. This level 2 label has a value which is meaningful to R21. Switching is done on the level 2 label by R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel, pops the label stack before forwarding the packet to R3. When R3 sees packet P, P has only a level 1 label, having now exited the tunnel. Since R3 is the penultimate hop in P's level 1 LSP, it pops the label stack, and R4 receives P unlabeled. The label stack mechanism allows LSP tunneling to nest to any depth. -2.27.5. Label Distribution Peering and Hierarchy +3.27.5. Label Distribution Peering and Hierarchy Suppose that packet P travels along a Level 1 LSP , and when going from R2 to R3 travels along a Level 2 LSP . From the perspective of the Level 2 LSP, R2's label distribution peer is R21. From the perspective of the Level 1 LSP, R2's label distribution peers are R1 and R3. One can have label distribution peers at each layer of hierarchy. We will see in - sections 3.6 and 3.7 some ways to make use of this hierarchy. Note + sections 4.6 and 4.7 some ways to make use of this hierarchy. Note that in this example, R2 and R21 must be IGP neighbors, but R2 and R3 need not be. When two LSRs are IGP neighbors, we will refer to them as "local label distribution peers". When two LSRs may be label distribution peers, but are not IGP neighbors, we will refer to them as "remote label distribution peers". In the above example, R2 and R21 are local label distribution peers, but R2 and R3 are remote label distribution peers. @@ -1608,24 +1620,24 @@ 1. Explicit Peering In explicit peering, one distributes labels to a peer by sending label distribution protocol messages which are addressed to the peer, exactly as one would do for local label distribution peers. This technique is most useful when the number of remote label distribution peers is small, or the number of higher level label bindings is large, or the remote label distribution peers are in distinct routing areas or domains. Of course, one needs to know which labels to - distribute to which peers; this is addressed in section 3.1.2. + distribute to which peers; this is addressed in section 4.1.2. Examples of the use of explicit peering is found in sections - 3.2.1 and 3.6. + 4.2.1 and 4.6. 2. Implicit Peering In Implicit Peering, one does not send label distribution protocol messages which are addressed to one's peer. Rather, to distribute higher level labels to ones remote label distribution peers, one encodes a higher level label as an attribute of a lower level label, and then distributes the lower level label, along with this attribute, to one's local label distribution peers. The local label distribution peers @@ -1635,115 +1647,115 @@ This technique is most useful when the number of remote label distribution peers is large. Implicit peering does not require an n-square peering mesh to distribute labels to the remote label distribution peers because the information is piggybacked through the local label distribution peering. However, implicit peering requires the intermediate nodes to store information that they might not be directly interested in. An example of the use of implicit peering is found in section - 3.3. + 4.3. -2.28. Label Distribution Protocol Transport +3.28. Label Distribution Protocol Transport A label distribution protocol is used between nodes in an MPLS network to establish and maintain the label bindings. In order for MPLS to operate correctly, label distribution information needs to be transmitted reliably, and the label distribution protocol messages pertaining to a particular FEC need to be transmitted in sequence. Flow control is also desirable, as is the capability to carry multiple label messages in a single datagram. One way to meet these goals is to use TCP as the underlying transport, as is done in [MPLS-LDP] and [MPLS-BGP]. -2.29. Why More than one Label Distribution Protocol? +3.29. Why More than one Label Distribution Protocol? This architecture does not establish hard and fast rules for choosing which label distribution protocol to use in which circumstances. However, it is possible to point out some of the considerations. -2.29.1. BGP and LDP +3.29.1. BGP and LDP In many scenarios, it is desirable to bind labels to FECs which can - be identified with routes to address prefixes (see section 3.1). If + be identified with routes to address prefixes (see section 4.1). If there is a standard, widely deployed routing algorithm which distributes those routes, it can be argued that label distribution is best achieved by piggybacking the label distribution on the distribution of the routes themselves. For example, BGP distributes such routes, and if a BGP speaker needs to also distribute labels to its BGP peers, using BGP to do the label distribution (see [MPLS-BGP]) has a number of advantages. In particular, it permits BGP route reflectors to distribute labels, thus providing a significant scalability advantage over using LDP to distribute labels between BGP peers. -2.29.2. Labels for RSVP Flowspecs +3.29.2. Labels for RSVP Flowspecs When RSVP is used to set up resource reservations for particular flows, it can be desirable to label the packets in those flows, so that the RSVP filterspec does not need to be applied at each hop. It can be argued that having RSVP distribute the labels as part of its path/reservation setup process is the most efficient method of distributing labels for this purpose. -2.29.3. Labels for Explicitly Routed LSPs +3.29.3. Labels for Explicitly Routed LSPs In some applications of MPLS, particularly those related to traffic engineering, it is desirable to set up an explicitly routed path, from ingress to egress. It is also desirable to apply resource reservations along that path. One can imagine two approaches to this: - Start with an existing protocol that is used for setting up resource reservations, and extend it to support explicit routing and label distribution. - Start with an existing protocol that is used for label distribution, and extend it to support explicit routing and resource reservations. The first approach has given rise to the protocol specified in [MPLS-RSVP-TUNNELS], the second to the approach specified in [MPLS- CR-LDP]. -2.30. Multicast +3.30. Multicast This section is for further study -3. Some Applications of MPLS +4. Some Applications of MPLS -3.1. MPLS and Hop by Hop Routed Traffic +4.1. MPLS and Hop by Hop Routed Traffic A number of uses of MPLS require that packets with a certain label be forwarded along the same hop-by-hop routed path that would be used for forwarding a packet with a specified address in its network layer destination address field. -3.1.1. Labels for Address Prefixes +4.1.1. Labels for Address Prefixes In general, router R determines the next hop for packet P by finding the address prefix X in its routing table which is the longest match for P's destination address. That is, the packets in a given FEC are just those packets which match a given address prefix in R's routing table. In this case, a FEC can be identified with an address prefix. Note that a packet P may be assigned to FEC F, and FEC F may be identified with address prefix X, even if P's destination address does not match X. -3.1.2. Distributing Labels for Address Prefixes +4.1.2. Distributing Labels for Address Prefixes -3.1.2.1. Label Distribution Peers for an Address Prefix +4.1.2.1. Label Distribution Peers for an Address Prefix LSRs R1 and R2 are considered to be label distribution peers for address prefix X if and only if one of the following conditions holds: 1. R1's route to X is a route which it learned about via a particular instance of a particular IGP, and R2 is a neighbor of R1 in that instance of that IGP 2. R1's route to X is a route which it learned about by some @@ -1762,21 +1774,21 @@ R2 is a BGP peer of R1 In general, these rules ensure that if the route to a particular address prefix is distributed via an IGP, the label distribution peers for that address prefix are the IGP neighbors. If the route to a particular address prefix is distributed via BGP, the label distribution peers for that address prefix are the BGP peers. In other cases of LSP tunneling, the tunnel endpoints are label distribution peers. -3.1.2.2. Distributing Labels +4.1.2.2. Distributing Labels In order to use MPLS for the forwarding of packets according to the hop-by-hop route corresponding to any address prefix, each LSR MUST: 1. bind one or more labels to each address prefix that appears in its routing table; 2. for each such address prefix X, use a label distribution protocol to distribute the binding of a label to X to each of its label distribution peers for X. @@ -1793,47 +1805,47 @@ These rules ensure that labels corresponding to address prefixes which correspond to BGP routes are distributed to IGP neighbors if and only if the BGP routes are distributed into the IGP. Otherwise, the labels bound to BGP routes are distributed only to the other BGP speakers. These rules are intended only to indicate which label bindings must be distributed by a given LSR to which other LSRs. -3.1.3. Using the Hop by Hop path as the LSP +4.1.3. Using the Hop by Hop path as the LSP If the hop-by-hop path that packet P needs to follow is , then can be an LSP as long as: 1. there is a single address prefix X, such that, for all i, 1<=i, and the Hop-by-hop path for P2 is . Let's suppose that R3 binds label L3 to X, and distributes this binding to R2. R2 binds label L2 to X, and distributes this binding to both R1 and R4. When R2 receives packet P1, its incoming label will be L2. R2 will overwrite L2 with L3, and send P1 to R3. When R2 receives packet P2, its incoming label will also be L2. R2 @@ -2084,24 +2097,24 @@ distinguished. Thus instead of talking about two distinct LSPs, and , we might talk of a single "Multipoint-to- Point LSP Tree", which we might denote as <{R1, R4}, R2, R3>. This creates a difficulty when we attempt to use conventional ATM switches as LSRs. Since conventional ATM switches do not support multipoint-to-point connections, there must be procedures to ensure that each LSP is realized as a point-to-point VC. However, if ATM switches which do support multipoint-to-point VCs are in use, then the LSPs can be most efficiently realized as multipoint-to-point VCs. - Alternatively, if the SVP Multipoint Encoding (section 2.25.2) can be + Alternatively, if the SVP Multipoint Encoding (section 3.25.2) can be used, the LSPs can be realized as multipoint-to-point SVPs. -3.6. LSP Tunneling between BGP Border Routers +4.6. LSP Tunneling between BGP Border Routers Consider the case of an Autonomous System, A, which carries transit traffic between other Autonomous Systems. Autonomous System A will have a number of BGP Border Routers, and a mesh of BGP connections among them, over which BGP routes are distributed. In many such cases, it is desirable to avoid distributing the BGP routes to routers which are not BGP Border Routers. If this can be avoided, the "route distribution load" on those routers is significantly reduced. However, there must be some means of ensuring that the transit traffic will be delivered from Border Router to Border Router @@ -2174,68 +2187,68 @@ - B3 distributes routes to B2 (using EBGP), optionally assigning labels to address prefixes; - B2 redistributes those routes to B1 (using IBGP), indicating that the BGP next hop for each such route is B3. If B3 has assigned labels to address prefixes, B2 passes these labels along, unchanged, to B1. - The IGP of AS1 has a host route for B3. -3.7. Other Uses of Hop-by-Hop Routed LSP Tunnels +4.7. Other Uses of Hop-by-Hop Routed LSP Tunnels The use of Hop-by-Hop Routed LSP Tunnels is not restricted to tunnels between BGP Next Hops. Any situation in which one might otherwise have used an encapsulation tunnel is one in which it is appropriate to use a Hop-by-Hop Routed LSP Tunnel. Instead of encapsulating the packet with a new header whose destination address is the address of the tunnel's receive endpoint, the label corresponding to the address prefix which is the longest match for the address of the tunnel's receive endpoint is pushed on the packet's label stack. The packet which is sent into the tunnel may or may not already be labeled. If the transmit endpoint of the tunnel wishes to put a labeled packet into the tunnel, it must first replace the label value at the top of the stack with a label value that was distributed to it by the tunnel's receive endpoint. Then it must push on the label which corresponds to the tunnel itself, as distributed to it by the next hop along the tunnel. To allow this, the tunnel endpoints should be explicit label distribution peers. The label bindings they need to exchange are of no interest to the LSRs along the tunnel. -3.8. MPLS and Multicast +4.8. MPLS and Multicast Multicast routing proceeds by constructing multicast trees. The tree along which a particular multicast packet must get forwarded depends in general on the packet's source address and its destination address. Whenever a particular LSR is a node in a particular multicast tree, it binds a label to that tree. It then distributes that binding to its parent on the multicast tree. (If the node in question is on a LAN, and has siblings on that LAN, it must also distribute the binding to its siblings. This allows the parent to use a single label value when multicasting to all children on the LAN.) When a multicast labeled packet arrives, the NHLFE corresponding to the label indicates the set of output interfaces for that packet, as well as the outgoing label. If the same label encoding technique is used on all the outgoing interfaces, the very same packet can be sent to all the children. -4. Label Distribution Procedures (Hop-by-Hop) +5. Label Distribution Procedures (Hop-by-Hop) In this section, we consider only label bindings that are used for traffic to be label switched along its hop-by-hop routed path. In these cases, the label in question will correspond to an address prefix in the routing table. -4.1. The Procedures for Advertising and Using labels +5.1. The Procedures for Advertising and Using labels There are a number of different procedures that may be used to distribute label bindings. Some are executed by the downstream LSR, and some by the upstream LSR. The downstream LSR must perform: - The Distribution Procedure, and - the Withdrawal Procedure. @@ -2247,59 +2260,59 @@ - the NotAvailable Procedure, and - the Release Procedure, and - the labelUse Procedure. The MPLS architecture supports several variants of each procedure. However, the MPLS architecture does not support all possible combinations of all possible variants. The set of supported - combinations will be described in section 4.2, where the + combinations will be described in section 5.2, where the interoperability between different combinations will also be discussed. -4.1.1. Downstream LSR: Distribution Procedure +5.1.1. Downstream LSR: Distribution Procedure The Distribution Procedure is used by a downstream LSR to determine when it should distribute a label binding for a particular address prefix to its label distribution peers. The architecture supports four different distribution procedures. Irrespective of the particular procedure that is used, if a label binding for a particular address prefix has been distributed by a downstream LSR Rd to an upstream LSR Ru, and if at any time the attributes (as defined above) of that binding change, then Rd must inform Ru of the new attributes. If an LSR is maintaining multiple routes to a particular address prefix, it is a local matter as to whether that LSR binds multiple labels to the address prefix (one per route), and hence distributes multiple bindings. -4.1.1.1. PushUnconditional +5.1.1.1. PushUnconditional Let Rd be an LSR. Suppose that: 1. X is an address prefix in Rd's routing table 2. Ru is a label distribution peer of Rd with respect to X Whenever these conditions hold, Rd must bind a label to X and distribute that binding to Ru. It is the responsibility of Rd to keep track of the bindings which it has distributed to Ru, and to make sure that Ru always has these bindings. This procedure would be used by LSRs which are performing unsolicited downstream label assignment in the Independent LSP Control Mode. -4.1.1.2. PushConditional +5.1.1.2. PushConditional Let Rd be an LSR. Suppose that: 1. X is an address prefix in Rd's routing table 2. Ru is a label distribution peer of Rd with respect to X 3. Rd is either an LSP Egress or an LSP Proxy Egress for X, or Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and Rn has bound a label to X and distributed that binding to Rd. @@ -2309,21 +2322,21 @@ Whereas PushUnconditional causes the distribution of label bindings for all address prefixes in the routing table, PushConditional causes the distribution of label bindings only for those address prefixes for which one has received label bindings from one's LSP next hop, or for which one does not have an MPLS-capable L3 next hop. This procedure would be used by LSRs which are performing unsolicited downstream label assignment in the Ordered LSP Control Mode. -4.1.1.3. PulledUnconditional +5.1.1.3. PulledUnconditional Let Rd be an LSR. Suppose that: 1. X is an address prefix in Rd's routing table 2. Ru is a label distribution peer of Rd with respect to X 3. Ru has explicitly requested that Rd bind a label to X and distribute the binding to Ru @@ -2333,21 +2346,21 @@ that it cannot provide a binding at this time. If Rd has already distributed a binding for address prefix X to Ru, and it receives a new request from Ru for a binding for address prefix X, it will bind a second label, and distribute the new binding to Ru. The first label binding remains in effect. This procedure would be used by LSRs performing downstream-on-demand label distribution using the Independent LSP Control Mode. -4.1.1.4. PulledConditional +5.1.1.4. PulledConditional Let Rd be an LSR. Suppose that: 1. X is an address prefix in Rd's routing table 2. Ru is a label distribution peer of Rd with respect to X 3. Ru has explicitly requested that Rd bind a label to X and distribute the binding to Ru @@ -2367,155 +2380,155 @@ until such time as it has receiving a binding from Rn. If Rd has distributed a label binding for address prefix X to Ru, and at some later time, any attribute of the label binding changes, then Rd must redistribute the label binding to Ru, with the new attribute. It must do this even though Ru does not issue a new Request. This procedure would be used by LSRs that are performing downstream- on-demand label allocation in the Ordered LSP Control Mode. - In section 4.2, we will discuss how to choose the particular + In section 5.2, we will discuss how to choose the particular procedure to be used at any given time, and how to ensure interoperability among LSRs that choose different procedures. -4.1.2. Upstream LSR: Request Procedure +5.1.2. Upstream LSR: Request Procedure The Request Procedure is used by the upstream LSR for an address prefix to determine when to explicitly request that the downstream LSR bind a label to that prefix and distribute the binding. There are three possible procedures that can be used. -4.1.2.1. RequestNever +5.1.2.1. RequestNever Never make a request. This is useful if the downstream LSR uses the PushConditional procedure or the PushUnconditional procedure, but is not useful if the downstream LSR uses the PulledUnconditional procedure or the the PulledConditional procedures. This procedure would be used by an LSR when unsolicited downstream label distribution and Liberal Label Retention Mode are being used. -4.1.2.2. RequestWhenNeeded +5.1.2.2. RequestWhenNeeded Make a request whenever the L3 next hop to the address prefix changes, or when a new address prefix is learned, and one doesn't already have a label binding from that next hop for the given address prefix. This procedure would be used by an LSR whenever Conservative Label Retention Mode is being used. -4.1.2.3. RequestOnRequest +5.1.2.3. RequestOnRequest Issue a request whenever a request is received, in addition to - issuing a request when needed (as described in section 4.1.2.2). If + issuing a request when needed (as described in section 5.1.2.2). If Ru is not capable of being an LSP ingress, it may issue a request only when it receives a request from upstream. If Rd receives such a request from Ru, for an address prefix for which Rd has already distributed Ru a label, Rd shall assign a new (distinct) label, bind it to X, and distribute that binding. (Whether Rd can distribute this binding to Ru immediately or not depends on the Distribution Procedure being used.) This procedure would be used by an LSR which is doing downstream-on- demand label distribution, but is not doing label merging, e.g., an ATM-LSR which is not capable of VC merge. -4.1.3. Upstream LSR: NotAvailable Procedure +5.1.3. Upstream LSR: NotAvailable Procedure If Ru and Rd are respectively upstream and downstream label distribution peers for address prefix X, and Rd is Ru's L3 next hop for X, and Ru requests a binding for X from Rd, but Rd replies that it cannot provide a binding at this time, because it has no next hop for X, then the NotAvailable procedure determines how Ru responds. There are two possible procedures governing Ru's behavior: -4.1.3.1. RequestRetry +5.1.3.1. RequestRetry Ru should issue the request again at a later time. That is, the requester is responsible for trying again later to obtain the needed binding. This procedure would be used when downstream-on-demand label distribution is used. -4.1.3.2. RequestNoRetry +5.1.3.2. RequestNoRetry Ru should never reissue the request, instead assuming that Rd will provide the binding automatically when it is available. This is useful if Rd uses the PushUnconditional procedure or the PushConditional procedure, i.e., if unsolicited downstream label distribution is used. Note that if Rd replies that it cannot provide a binding to Ru, because of some error condition, rather than because Rd has no next hop, the behavior of Ru will be governed by the error recovery conditions of the label distribution protocol, rather than by the NotAvailable procedure. -4.1.4. Upstream LSR: Release Procedure +5.1.4. Upstream LSR: Release Procedure Suppose that Rd is an LSR which has bound a label to address prefix X, and has distributed that binding to LSR Ru. If Rd does not happen to be Ru's L3 next hop for address prefix X, or has ceased to be Ru's L3 next hop for address prefix X, then Ru will not be using the label. The Release Procedure determines how Ru acts in this case. There are two possible procedures governing Ru's behavior: -4.1.4.1. ReleaseOnChange +5.1.4.1. ReleaseOnChange Ru should release the binding, and inform Rd that it has done so. This procedure would be used to implement Conservative Label Retention Mode. -4.1.4.2. NoReleaseOnChange +5.1.4.2. NoReleaseOnChange Ru should maintain the binding, so that it can use it again immediately if Rd later becomes Ru's L3 next hop for X. This procedure would be used to implement Liberal Label Retention Mode. -4.1.5. Upstream LSR: labelUse Procedure +5.1.5. Upstream LSR: labelUse Procedure Suppose Ru is an LSR which has received label binding L for address prefix X from LSR Rd, and Ru is upstream of Rd with respect to X, and in fact Rd is Ru's L3 next hop for X. Ru will make use of the binding if Rd is Ru's L3 next hop for X. If, at the time the binding is received by Ru, Rd is NOT Ru's L3 next hop for X, Ru does not make any use of the binding at that time. Ru may however start using the binding at some later time, if Rd becomes Ru's L3 next hop for X. The labelUse Procedure determines just how Ru makes use of Rd's binding. There are two procedures which Ru may use: -4.1.5.1. UseImmediate +5.1.5.1. UseImmediate Ru may put the binding into use immediately. At any time when Ru has a binding for X from Rd, and Rd is Ru's L3 next hop for X, Rd will also be Ru's LSP next hop for X. This procedure is used when loop detection is not in use. -4.1.5.2. UseIfLoopNotDetected +5.1.5.2. UseIfLoopNotDetected This procedure is the same as UseImmediate, unless Ru has detected a loop in the LSP. If a loop has been detected, Ru will discontinue the use of label L for forwarding packets to Rd. This procedure is used when loop detection is in use. This will continue until the next hop for X changes, or until the loop is no longer detected. -4.1.6. Downstream LSR: Withdraw Procedure +5.1.6. Downstream LSR: Withdraw Procedure In this case, there is only a single procedure. When LSR Rd decides to break the binding between label L and address prefix X, then this unbinding must be distributed to all LSRs to which the binding was distributed. It is required that the unbinding of L from X be distributed by Rd to a LSR Ru before Rd distributes to Ru any new binding of L to any other address prefix Y, where X != Y. If Ru were to learn of the new @@ -2536,40 +2549,40 @@ As long as the relevant label distribution adjacency remains in place, label bindings that are withdrawn must always be withdrawn explicitly. If a second label is bound to an address prefix, the result is not to implicitly withdraw the first label, but to bind both labels; this is needed to support multi-path routing. If a second address prefix is bound to a label, the result is not to implicitly withdraw the binding of that label to the first address prefix, but to use that label for both address prefixes. -4.2. MPLS Schemes: Supported Combinations of Procedures +5.2. MPLS Schemes: Supported Combinations of Procedures Consider two LSRs, Ru and Rd, which are label distribution peers with respect to some set of address prefixes, where Ru is the upstream peer and Rd is the downstream peer. The MPLS scheme which governs the interaction of Ru and Rd can be described as a quintuple of procedures: . (Since there is only one Withdraw Procedure, it need not be mentioned.) A "*" appearing in one of the positions is a wild-card, meaning that any procedure in that category may be present; an "N/A" appearing in a particular position indicates that no procedure in that category is needed. Only the MPLS schemes which are specified below are supported by the MPLS Architecture. Other schemes may be added in the future, if a need for them is shown. -4.2.1. Schemes for LSRs that Support Label Merging +5.2.1. Schemes for LSRs that Support Label Merging If Ru and Rd are label distribution peers, and both support label merging, one of the following schemes must be used: 1. This is unsolicited downstream label distribution with independent control, liberal label retention mode, and no loop detection. @@ -2608,21 +2621,21 @@ independent control and conservative label retention mode, without loop detection. 7. This is downstream-on-demand label distribution with independent control and conservative label retention mode, with loop detection. -4.2.2. Schemes for LSRs that do not Support Label Merging +5.2.2. Schemes for LSRs that do not Support Label Merging Suppose that R1, R2, R3, and R4 are ATM switches which do not support label merging, but are being used as LSRs. Suppose further that the L3 hop-by-hop path for address prefix X is , and that packets destined for X can enter the network at any of these LSRs. Since there is no multipoint-to-point capability, the LSPs must be realized as point-to-point VCs, which means that there needs to be three such VCs for address prefix X: , , and . @@ -2651,21 +2664,21 @@ independent control and conservative label retention mode, without loop detection. 3. This is downstream-on-demand label distribution with independent control and conservative label retention mode, with loop detection. -4.2.3. Interoperability Considerations +5.2.3. Interoperability Considerations It is easy to see that certain quintuples do NOT yield viable MPLS schemes. For example: - In these MPLS schemes, the downstream LSR Rd distributes label bindings to upstream LSR Ru only upon request from Ru, but Ru never makes any such requests. Obviously, these schemes are not @@ -2710,65 +2723,65 @@ RequestWhenNeeded/ReleaseOnChange (conservative) , or to use RequestNever/NoReleaseOnChange (liberal). However, the choice of "push" vs. "pull" and "conditional" vs. "unconditional" belongs to Rd. If Ru chooses liberal label retention mode, Rd can choose either PushUnconditional or PushConditional. If Ru chooses conservative label retention mode, Rd can choose PushConditional, PulledConditional, or PulledUnconditional. These choices together determine the MPLS scheme in use. -5. Security Considerations +6. Security Considerations Some routers may implement security procedures which depend on the network layer header being in a fixed place relative to the data link layer header. The MPLS generic encapsulation inserts a shim between the data link layer header and the network layer header. This may - cause such any such security procedures to fail. + cause any such security procedures to fail. An MPLS label has its meaning by virtue of an agreement between the LSR that puts the label in the label stack (the "label writer") , and the LSR that interprets that label (the "label reader"). If labeled packets are accepted from untrusted sources, or if a particular incoming label is accepted from an LSR to which that label has not been distributed, then packets may be routed in an illegitimate manner. -6. Intellectual Property +7. Intellectual Property The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. -7. Authors' Addresses +8. Authors' Addresses Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: erosen@cisco.com Arun Viswanathan Lucent Technologies 101 Crawford Corner Rd., #4D-537 Holmdel, NJ 07733 732-332-5163 E-mail: arunv@dnrc.bell-labs.com Ross Callon IronBridge Networks 55 Hayden Avenue, Lexington, MA 02173 +1-781-372-8117 E-mail: rcallon@ironbridgenetworks.com -8. References +9. References [MPLS-ATM] "MPLS using LDP and ATM VC Switching", Davie, Doolan, Lawrence, McGloghrie, Rekhter, Rosen, Swallow, work in progress, April 1999. [MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, work in progress, February 1999. [MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, editor, work in progress, March 1999.