--- 1/draft-ietf-mpls-arch-03.txt 2006-02-05 00:37:08.000000000 +0100 +++ 2/draft-ietf-mpls-arch-04.txt 2006-02-05 00:37:08.000000000 +0100 @@ -5,21 +5,21 @@ Arun Viswanathan Lucent Technologies Ross Callon IronBridge Networks, Inc. February 1999 Multiprotocol Label Switching Architecture - draft-ietf-mpls-arch-03.txt + draft-ietf-mpls-arch-04.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. @@ -43,104 +43,108 @@ 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 Protocol (LDP) .................. 12 + 2.6 Label Distribution Protocols ....................... 12 2.7 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 ..................... 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 ............................ 18 2.17 LSP Next Hop ....................................... 20 2.18 Invalid Incoming Labels ............................ 20 2.19 LSP Control: Ordered versus Independent ............ 21 2.20 Aggregation ........................................ 22 2.21 Route Selection .................................... 23 2.22 Lack of Outgoing Label ............................. 24 - 2.23 Time-to-Live (TTL) ................................. 24 + 2.23 Time-to-Live (TTL) ................................. 25 2.24 Loop Control ....................................... 26 2.25 Label Encodings .................................... 26 - 2.25.1 MPLS-specific Hardware and/or Software ............. 26 + 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 ......... 28 2.26 Label Merging ...................................... 29 2.26.1 Non-merging LSRs ................................... 30 - 2.26.2 Labels for Merging and Non-Merging LSRs ............ 30 + 2.26.2 Labels for Merging and Non-Merging LSRs ............ 31 2.26.3 Merge over ATM ..................................... 31 2.26.3.1 Methods of Eliminating Cell Interleave ............. 31 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 ........................... 33 2.27.2 Explicitly Routed Tunnel ........................... 33 - 2.27.3 LSP Tunnels ........................................ 33 + 2.27.3 LSP Tunnels ........................................ 34 2.27.4 Hierarchy: LSP Tunnels within LSPs ................. 34 - 2.27.5 LDP Peering and Hierarchy .......................... 34 - 2.28 LDP Transport ...................................... 36 - 2.29 Multicast .......................................... 36 - 3 Some Applications of MPLS .......................... 36 - 3.1 MPLS and Hop by Hop Routed Traffic ................. 36 - 3.1.1 Labels for Address Prefixes ........................ 36 - 3.1.2 Distributing Labels for Address Prefixes ........... 37 - 3.1.2.1 LDP Peers for a Particular Address Prefix .......... 37 - 3.1.2.2 Distributing Labels ................................ 37 - 3.1.3 Using the Hop by Hop path as the LSP ............... 38 - 3.1.4 LSP Egress and LSP Proxy Egress .................... 39 - 3.1.5 The Implicit NULL Label ............................ 39 - 3.1.6 Option: Egress-Targeted Label Assignment ........... 40 - 3.2 MPLS and Explicitly Routed LSPs .................... 42 - 3.2.1 Explicitly Routed LSP Tunnels ...................... 42 - 3.3 Label Stacks and Implicit Peering .................. 43 - 3.4 MPLS and Multi-Path Routing ........................ 44 - 3.5 LSP Trees as Multipoint-to-Point Entities .......... 44 - 3.6 LSP Tunneling between BGP Border Routers ........... 45 - 3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 46 - 3.8 MPLS and Multicast ................................. 47 - 4 LDP Procedures for Hop-by-Hop Routed Traffic ....... 47 - 4.1 The Procedures for Advertising and Using labels .... 47 - 4.1.1 Downstream LSR: Distribution Procedure ............. 48 - 4.1.1.1 PushUnconditional .................................. 48 - 4.1.1.2 PushConditional .................................... 49 - 4.1.1.3 PulledUnconditional ................................ 49 - 4.1.1.4 PulledConditional .................................. 50 - 4.1.2 Upstream LSR: Request Procedure .................... 50 - 4.1.2.1 RequestNever ....................................... 51 - 4.1.2.2 RequestWhenNeeded .................................. 51 - 4.1.2.3 RequestOnRequest ................................... 51 - 4.1.3 Upstream LSR: NotAvailable Procedure ............... 51 - 4.1.3.1 RequestRetry ....................................... 52 - 4.1.3.2 RequestNoRetry ..................................... 52 - 4.1.4 Upstream LSR: Release Procedure .................... 52 - 4.1.4.1 ReleaseOnChange .................................... 52 - 4.1.4.2 NoReleaseOnChange .................................. 52 - 4.1.5 Upstream LSR: labelUse Procedure ................... 53 - 4.1.5.1 UseImmediate ....................................... 53 - 4.1.5.2 UseIfLoopNotDetected ............................... 53 - 4.1.6 Downstream LSR: Withdraw Procedure ................. 53 - 4.2 MPLS Schemes: Supported Combinations of Procedures . 54 - 4.2.1 Schemes for LSRs that Support Label Merging ........ 55 - 4.2.2 Schemes for LSRs that do not Support Label Merging . 56 - 4.2.3 Interoperability Considerations .................... 57 - 5 Security Considerations ............................ 58 - 6 Intellectual Property .............................. 58 - 7 Authors' Addresses ................................. 58 - 8 References ......................................... 59 + 2.27.5 Label Distribution Peering and Hierarchy ........... 35 + 2.28 Label Distribution Protocol Transport .............. 36 + 2.29 Why More than one Label Distribution Protocol? ..... 36 + 2.29.1 BGP and LDP ........................................ 37 + 2.29.2 Labels for RSVP Flowspecs .......................... 37 + 2.29.3 Labels for Explicitly Routed LSPs .................. 37 + 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 ........... 38 + 3.1.2.1 Label Distribution Peers for an Address Prefix ..... 38 + 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 .................... 40 + 3.1.5 The Implicit NULL Label ............................ 41 + 3.1.6 Option: Egress-Targeted Label Assignment ........... 42 + 3.2 MPLS and Explicitly Routed LSPs .................... 43 + 3.2.1 Explicitly Routed LSP Tunnels ...................... 43 + 3.3 Label Stacks and Implicit Peering .................. 44 + 3.4 MPLS and Multi-Path Routing ........................ 45 + 3.5 LSP Trees as Multipoint-to-Point Entities .......... 45 + 3.6 LSP Tunneling between BGP Border Routers ........... 46 + 3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 48 + 3.8 MPLS and Multicast ................................. 48 + 4 Label Distribution Procedures (Hop-by-Hop) ......... 49 + 4.1 The Procedures for Advertising and Using labels .... 49 + 4.1.1 Downstream LSR: Distribution Procedure ............. 50 + 4.1.1.1 PushUnconditional .................................. 50 + 4.1.1.2 PushConditional .................................... 50 + 4.1.1.3 PulledUnconditional ................................ 51 + 4.1.1.4 PulledConditional .................................. 51 + 4.1.2 Upstream LSR: Request Procedure .................... 52 + 4.1.2.1 RequestNever ....................................... 52 + 4.1.2.2 RequestWhenNeeded .................................. 53 + 4.1.2.3 RequestOnRequest ................................... 53 + 4.1.3 Upstream LSR: NotAvailable Procedure ............... 53 + 4.1.3.1 RequestRetry ....................................... 53 + 4.1.3.2 RequestNoRetry ..................................... 54 + 4.1.4 Upstream LSR: Release Procedure .................... 54 + 4.1.4.1 ReleaseOnChange .................................... 54 + 4.1.4.2 NoReleaseOnChange .................................. 54 + 4.1.5 Upstream LSR: labelUse Procedure ................... 54 + 4.1.5.1 UseImmediate ....................................... 55 + 4.1.5.2 UseIfLoopNotDetected ............................... 55 + 4.1.6 Downstream LSR: Withdraw Procedure ................. 55 + 4.2 MPLS Schemes: Supported Combinations of Procedures . 56 + 4.2.1 Schemes for LSRs that Support Label Merging ........ 56 + 4.2.2 Schemes for LSRs that do not Support Label Merging . 58 + 4.2.3 Interoperability Considerations .................... 59 + 5 Security Considerations ............................ 60 + 6 Intellectual Property .............................. 60 + 7 Authors' Addresses ................................. 60 + 8 References ......................................... 61 1. Introduction to MPLS 1.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 @@ -491,54 +495,63 @@ that it only binds labels that are in that range. 2.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 Protocol (LDP) +2.6. Label Distribution Protocols - A Label Distribution Protocol (LDP) is a set of procedures by which - one LSR informs another of the label/FEC bindings it has made. Two - LSRs which use an LDP to exchange label/FEC binding information are - known as "LDP Peers" with respect to the binding information they - exchange. If two LSRs are LDP Peers, we will speak of there being an - "LDP Adjacency" between them. + 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 LDP Peers with respect to some set of - bindings, but not with respect to some other set of bindings.) + (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 LDP also encompasses any negotiations in which two LDP Peers need - to engage in order to learn of each other's MPLS capabilities. + 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. - The architecture does not assume that there is only a single Label - Distribution Protocol. Different label distribution protocols might - be used for different purposes or in different environments. See, - e.g., [MPLS-LDP], [MPLS-BGP], [MPLS-RSVP], [MPLS-RSVP-TUNNELS], etc. + 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], [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. 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 "downstream" label distribution. Both of these label distribution techniques may be used in the same - network at the same time. However, on any given LDP adjacency, the - upstream LSR and the downstream LSR must agree on which technique is - to be used. + network at the same time. However, 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 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 @@ -555,23 +568,20 @@ changes, but conservative label retention mode though requires an LSR to maintain many fewer labels. 2.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". - IN MPLS, EVERY FORWARDING DECISION IS BASED EXCLUSIVELY ON THE LABEL - AT THE TOP OF THE 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). @@ -619,30 +629,46 @@ 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) - The "Incoming Label Map" (ILM) is a mapping from incoming labels to + 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) - The "FEC-to-NHLFE" (FTN) is a mapping from FECs to NHLFEs. It is used + 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 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 @@ -656,39 +682,40 @@ 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 A given LSR Rd may bind label L1 to FEC F, and distribute that - binding to LDP peer Ru1. Rd may also bind label L2 to FEC F, and - distribute that binding to LDP peer Ru2. Whether or not L1 == L2 is - not determined by the architecture; this is a local matter. + 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 LDP peer Ru1. Rd may also bind label L to FEC F2, and - distribute that binding to LDP 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. + 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. 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 LDP peers to which Rd distributed a - binding of label value L, and + - 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." @@ -843,26 +872,27 @@ 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 LDP peer. + penultimate hop popping when so requested by its downstream label + distribution peer. - Initial LDP negotiations MUST allow each LSR to determine whether its - neighboring LSRS are capable of popping the label stack. A LSR MUST - NOT request an LDP peer to pop the label stack unless it is capable - of doing so. + 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 are obeyed, it is always possible to interpret the top label of a received packet unambiguously. 2.17. LSP Next Hop The LSP Next Hop for a particular labeled packet in a particular LSR @@ -898,25 +928,25 @@ 2.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 LDP peers. This - corresponds to the way that conventional IP datagram routing works; - each node makes an independent decision as to how to treat each - packet, and relies on the routing algorithm to converge rapidly so as - to ensure that each datagram is correctly delivered. + that FEC and to distribute that binding to its label distribution + peers. This corresponds to the way that conventional IP datagram + routing works; each node makes an independent decision as to how to + treat each packet, and relies on the routing algorithm to converge + rapidly so as to ensure that each datagram is correctly delivered. In Ordered LSP Control, an LSR only binds a label to a particular FEC if it is the egress LSR for that FEC, or if it has already received a label binding for that FEC from its next hop for that FEC. If one wants to ensure that traffic in a particular FEC follows a path with some specified set of properties (e.g., that the traffic does not traverse any node twice, that a specified amount of resources are available to the traffic, that the traffic follows an explicitly specified path, etc.) ordered control must be used. With @@ -933,43 +963,44 @@ Ordered control and independent control are fully interoperable. However, unless all LSRs in an LSP are using ordered control, the overall effect on network behavior is largely that of independent 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 LDP mechanisms which need to be - defined. + appear to have any effect on the label distribution mechanisms which + need to be defined. 2.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 single label be bound to the union, and that label applied to all traffic in the union? The procedure of binding a single label to a union of FECs which is itself a FEC (within some domain), and of applying that label to all traffic in the union, is known as "aggregation". The MPLS architecture allows aggregation. Aggregation may reduce the number of labels which are needed to handle a particular set of packets, and - may also reduce the amount of LDP control traffic needed. + may also reduce the amount of label distribution control traffic + needed. Given a set of FECs which are "aggregatable" into a single FEC, it is possible to (a) aggregate them into a single FEC, (b) aggregate them into a set of FECs, or (c) not aggregate them at all. Thus we can speak of the "granularity" of aggregation, with (a) being the "coarsest granularity", and (c) being the "finest granularity". When order control is used, each LSR should adopt, for a given set of FECs, the granularity used by its next hop for those FECs. @@ -1193,32 +1225,34 @@ LSRs". There are three obvious ways to encode labels in the ATM cell header (presuming the use of AAL5): 1. SVC Encoding Use the VPI/VCI field to encode the label which is at the top of the label stack. This technique can be used in any network. With this encoding technique, each LSP is realized as an ATM - SVC, and the LDP becomes the ATM "signaling" protocol. With - this encoding technique, the ATM-LSRs cannot perform "push" or - "pop" operations on the label stack. + SVC, and the label distribution protocol becomes the ATM + "signaling" protocol. With this encoding technique, the ATM- + LSRs cannot perform "push" or "pop" operations on the label + stack. 2. SVP Encoding Use the VPI field to encode the label which is at the top of the label stack, and the VCI field to encode the second label on the stack, if one is present. This technique some advantages over the previous one, in that it permits the use of ATM "VP- switching". That is, the LSPs are realized as ATM SVPs, with - LDP serving as the ATM signaling protocol. + the label distribution protocol serving as the ATM signaling + protocol. However, this technique cannot always be used. If the network includes an ATM Virtual Path through a non-MPLS ATM network, then the VPI field is not necessarily available for use by MPLS. When this encoding technique is used, the ATM-LSR at the egress of the VP effectively does a "pop" operation. 3. SVP Multipoint Encoding @@ -1301,44 +1335,46 @@ more detail in the next section. If a particular LSR cannot perform label merging, then if two packets in the same FEC arrive with different incoming labels, they must be forwarded with different outgoing labels. With label merging, the number of outgoing labels per FEC need only be 1; without label merging, the number of outgoing labels per FEC could be as large as the number of nodes in the network. With label merging, the number of incoming labels per FEC that a - particular LSR needs is never be larger than the number of LDP - adjacencies. Without label merging, the number of incoming labels - per FEC that a particular LSR needs is as large as the number of - upstream nodes which forward traffic in the FEC to the LSR in - question. In fact, it is difficult for an LSR to even determine how - many such incoming labels it must support for a particular FEC. + particular LSR needs is never be larger than the number of label + distribution adjacencies. Without label merging, the number of + incoming labels per FEC that a particular LSR needs is as large as + the number of upstream nodes which forward traffic in the FEC to the + LSR in question. In fact, it is difficult for an LSR to even + determine how many such incoming labels it must support for a + 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 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; an LDP can be used as the - "signalling protocol" for setting up the cross-connect tables. + use such technologies for MPLS forwarding; a label distribution + protocol can be used as the "signalling protocol" for setting up the + cross-connect tables. Unfortunately, these technologies do not necessarily support the label merging capability. In ATM, if one attempts to perform label merging, the result may be the interleaving of cells from various packets. If cells from different packets get interleaved, it is impossible to reassemble the packets. Some Frame Relay switches use cell switching on their backplanes. These switches may also be incapable of supporting label merging, for the same reason -- cells of different packets may get interleaved, and there is then no way to reassemble the packets. @@ -1527,96 +1563,153 @@ 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. LDP Peering and Hierarchy +2.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 LDP peer is - R21. From the perspective of the Level 1 LSP, R2's LDP peers are R1 - and R3. One can have LDP 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 that in this example, R2 and R21 must be IGP neighbors, but R2 - and R3 need not be. + R22, R3>. 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 + 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 LDP - Peers". When two LSRs may be LDP peers, but are not IGP neighbors, - we will refer to them as "Remote LDP Peers". In the above example, - R2 and R21 are local LDP peers, but R2 and R3 are remote LDP peers. + 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. The MPLS architecture supports two ways to distribute labels at different layers of the hierarchy: Explicit Peering and Implicit Peering. - One performs label Distribution with one's Local LDP Peers by opening - LDP connections to them. One can perform label Distribution with - one's Remote LDP Peers in one of two ways: + One performs label distribution with one's local label distribution + peer by sending label distribution protocol messages which are + addressed to the peer. One can perform label distribution with one's + remote label distribution peers in one of two ways: 1. Explicit Peering - In explicit peering, one sets up LDP connections between Remote - LDP Peers, exactly as one would do for Local LDP Peers. This - technique is most useful when the number of Remote LDP Peers is - small, or the number of higher level label bindings is large, - or the Remote LDP Peers are in distinct routing areas or + 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. Examples of the use of explicit peering is found in sections 3.2.1 and 3.6. 2. Implicit Peering - In Implicit Peering, one does not have LDP connections to one's - remote LDP peers, but only to one's local LDP peers. To - distribute higher level labels to ones remote LDP peers, one - encodes the higher level labels as an attribute of the lower - level labels, and distributes the lower level label, along with - this attribute, to the local LDP peers. The local LDP peers - then propagate the information to their peers. This process - continues till the information reaches remote LDP peers. Note - that the intermediary nodes may also be remote LDP peers. + 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 + then propagate the information to their local label + distribution peers. This process continues till the information + reaches the remote peer. - This technique is most useful when the number of Remote LDP - Peers is large. Implicit peering does not require a n-square - peering mesh to distribute labels to the remote LDP peers - because the information is piggybacked through the local LDP - peering. However, implicit peering requires the intermediate - nodes to store information that they might not be directly - interested in. + 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. -2.28. LDP Transport +2.28. Label Distribution Protocol Transport - LDP is used between nodes in an MPLS network to establish and - maintain the label bindings. In order for LDP to operate correctly, - LDP information needs to be transmitted reliably, and the LDP - messages pertaining to a particular FEC need to be transmitted in - sequence. Flow control is also required, as is the capability to - carry multiple LDP messages in a single datagram. + 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. - These goals will be met by using TCP as the underlying transport for - LDP. + One way to meet these goals is to use TCP as the underlying + transport, as is done in [MPLS-LDP] and [MPLS-BGP]. - (The use of multicast techniques to distribute label bindings is for - further study.) +2.29. Why More than one Label Distribution Protocol? -2.29. Multicast + 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 + + 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 + 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 + + 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 + + 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 This section is for further study 3. Some Applications of MPLS 3.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 @@ -1629,34 +1722,34 @@ 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 -3.1.2.1. LDP Peers for a Particular Address Prefix +3.1.2.1. Label Distribution Peers for an Address Prefix - LSRs R1 and R2 are considered to be LDP Peers for address prefix X if - and only if one of the following conditions holds: + 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 instance of routing algorithm A1, and that route is redistributed into an instance of routing algorithm A2, and R2 is a neighbor of R1 in that instance of A2 - 3. R1 is the receive endpoint of an LSP Tunnel that is within another LSP, and R2 is a transmit endpoint of that tunnel, and R1 and R2 are participants in a common instance of an IGP, and are in the same IGP area (if the IGP in question has areas), and R1's route to X was learned via that IGP instance, or is redistributed by R1 into that IGP instance 4. R1's route to X is a route which it learned about via BGP, and R2 is a BGP peer of R1 @@ -1654,36 +1747,38 @@ another LSP, and R2 is a transmit endpoint of that tunnel, and R1 and R2 are participants in a common instance of an IGP, and are in the same IGP area (if the IGP in question has areas), and R1's route to X was learned via that IGP instance, or is redistributed by R1 into that IGP instance 4. R1's route to X is a route which it learned about via BGP, and 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 LDP peers for that - address prefix are the IGP neighbors. If the route to a particular - address prefix is distributed via BGP, the LDP peers for that address - prefix are the BGP peers. In other cases of LSP tunneling, the - tunnel endpoints are LDP peers. + 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 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 an LDP to distribute the - binding of a label to X to each of its LDP Peers for X. + 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. There is also one circumstance in which an LSR must distribute a label binding for an address prefix, even if it is not the LSR which bound that label to that address prefix: 3. If R1 uses BGP to distribute a route to X, naming some other LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has assigned label L to X, then R1 must distribute the binding between L and X to any BGP peer to which it distributes that route. @@ -1732,22 +1827,23 @@ routing table which is the longest match for Y, or 2. R contains in its routing tables one or more address prefixes Y such that X is a proper initial substring of Y, but R's "LSP previous hops" for X do not contain any such address prefixes Y; that is, R is a "deaggregation point" for address prefix X. An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address prefix X if and only if: - 1. R1's next hop for X is R2, and R1 and R2 are not LDP Peers with - respect to X (perhaps because R2 does not support MPLS), or + 1. R1's next hop for X is R2, and R1 and R2 are not label + distribution peers with respect to X (perhaps because R2 does + not support MPLS), or 2. R1 has been configured to act as an LSP Proxy Egress for X The definition of LSP allows for the LSP Egress to be a node which does not support MPLS; in this case the penultimate node in the LSP is the Proxy Egress. 3.1.5. The Implicit NULL Label The Implicit NULL label is a label with special semantics which an @@ -1757,23 +1853,23 @@ address prefix, then instead of replacing the value of the label on top of the label stack, Ru pops the label stack, and then forwards the resulting packet to Rd. LSR Rd distributes a binding between Implicit NULL and an address prefix X to LSR Ru if and only if: 1. the rules of Section 3.1.2 indicate that Rd distributes to Ru a label binding for X, and - 2. when the LDP connection between Ru and Rd was opened, Ru - indicated that it could support the Implicit NULL label (i.e., + 2. Rd knows that Ru can support the Implicit NULL label (i.e., that it can pop the label stack), and + 3. Rd is an LSP Egress (not proxy egress) for X. This causes the penultimate LSR on a LSP to pop the label stack. This is quite appropriate; if the LSP Egress is an MPLS Egress for X, then if the penultimate LSR does not pop the label stack, the LSP Egress will need to look up the label, pop the label stack, and then look up the next label (or look up the L3 address, if no more labels are present). By having the penultimate LSR pop the label stack, the LSP Egress is saved the work of having to look up two labels in order to make its forwarding decision. @@ -1810,24 +1906,24 @@ - If the network is running a link state routing algorithm, and all nodes in the area support MPLS, then the routing algorithm provides Ri with enough information to determine the routers through which packets in that FEC must leave the routing domain or area. - If the network is running BGP, Ri may be able to determine that the packets in a particular FEC must leave the network via some particular router which is the "BGP Next Hop" for that FEC. - - It is possible to use the LDP to pass information about which - address prefixes are "attached" to which egress LSRs. This - method has the advantage of not depending on the presence of link - state routing. + - It is possible to use the label distribution protocol to pass + information about which address prefixes are "attached" to which + egress LSRs. This method has the advantage of not depending on + the presence of link state routing. If egress-targeted label assignment is used, the number of labels that need to be supported throughout the network may be greatly reduced. This may be significant if one is using legacy switching hardware to do MPLS, and the switching hardware can support only a limited number of labels. One possible approach would be to configure the network to use egress-targeted label assignment by default, but to configure particular LSRs to NOT use egress-targeted label assignment for one @@ -1892,22 +1988,22 @@ 3. A means of ensuring that packets sent into the Tunnel will not loop from the receive endpoint back to the transmit endpoint. 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 LDP peers. The label bindings they need to exchange are of - no interest to the LSRs along the tunnel. + explicit label distribution peers. The label bindings they need to + exchange are of no interest to the LSRs along the tunnel. 3.3. Label Stacks and Implicit Peering Suppose a particular LSR Re is an LSP proxy egress for 10 address prefixes, and it reaches each address prefix through a distinct interface. One could assign a single label to all 10 address prefixes. Then Re is an LSP egress for all 10 address prefixes. This ensures that packets for all 10 address prefixes get delivered to Re. However, Re @@ -1928,22 +2024,23 @@ following rules: - When LSR Ru initially labels a hitherto unlabeled packet, if the longest match for the packet's destination address is X, and Ru's LSP next hop for X is Rd, and Rd has distributed to Ru a binding of label L1 to X, along with a stack attribute of L2, then 1. Ru must push L2 and then L1 onto the packet's label stack, and then forward the packet to Rd; - 2. When Ru distributes label bindings for X to its LDP peers, - it must include L2 as the stack attribute. + 2. When Ru distributes label bindings for X to its label + distribution peers, it must include L2 as the stack + attribute. 3. Whenever the stack attribute changes (possibly as a result of a change in Ru's LSP next hop for X), Ru must distribute the new stack attribute. Note that although the label value bound to X may be different at each hop along the LSP, the stack attribute value is passed unchanged, and is set by the LSP proxy egress. Thus the LSP proxy egress for X becomes an "implicit peer" with each @@ -2049,71 +2148,90 @@ With these procedures, a given packet P follows a level 1 LSP all of whose members are BGP Border Routers, and between each pair of BGP Border Routers in the level 1 LSP, it follows a level 2 LSP. These procedures effectively create a Hop-by-Hop Routed LSP Tunnel between the BGP Border Routers. Since the BGP border routers are exchanging label bindings for address prefixes that are not even known to the IGP routing, the BGP - routers should become explicit LDP peers with each other. + routers should become explicit label distribution peers with each + other. + + It is sometimes possible to create Hop-by-Hop Routed LSP Tunnels + between two BGP Border Routers, even if they are not in the same + Autonomous System. Suppose, for example, that B1 and B2 are in AS 1. + Suppose that B3 is an EBGP neighbor of B2, and is in AS2. Finally, + suppose that B2 and B3 are on some network which is common to both + Autonomous Systems (a "Demilitarized Zone"). In this case, an LSP + tunnel can be set up directly between B1 and B3 as follows: + + - 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 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 LDP peers. The label bindings they need to exchange are of - no interest to the LSRs along the tunnel. + 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 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. LDP Procedures for Hop-by-Hop Routed Traffic - -4.1. The Procedures for Advertising and Using labels +4. 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 + 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. @@ -2131,89 +2250,89 @@ 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 interoperability between different combinations will also be discussed. 4.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 LDP peers. The architecture supports four different - distribution procedures. + 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 Let Rd be an LSR. Suppose that: 1. X is an address prefix in Rd's routing table - 2. Ru is an LDP Peer of Rd with respect to X + 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 downstream - label assignment in the Independent LSP Control Mode. + 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 Let Rd be an LSR. Suppose that: 1. X is an address prefix in Rd's routing table - 2. Ru is an LDP Peer of Rd with respect to X + 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. Then as soon as these conditions all hold, Rd should bind a label to X and distribute that binding to Ru. 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 downstream - label assignment in the Ordered LSP Control Mode. + 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 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 Then Rd should bind a label to X and distribute that binding to Ru. - Note that if X is not in Rd's routing table, or if Rd is not an LDP - peer of Ru with respect to X, then Rd must inform Ru that it cannot - provide a binding at this time. + Note that if X is not in Rd's routing table, or if Rd is not a label + distribution peer of Ru with respect to X, then Rd must inform Ru + 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 @@ -2216,33 +2335,33 @@ This procedure would be used by LSRs performing downstream-on-demand label distribution using the Independent LSP Control Mode. 4.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 4. 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 Then as soon as these conditions all hold, Rd should bind a label to X and distribute that binding to Ru. Note that if X is not in Rd's - routing table, or if Rd is not a label distribution peer of Ru with - respect to X, then Rd must inform Ru that it cannot provide a binding - at this time. + routing table and a binding for X is not obtainable via Rd's next hop + for X, or if Rd is not a label distribution peer of Ru with respect + to X, then Rd must inform Ru that it cannot provide a binding at this + time. However, if the only condition that fails to hold is that Rn has not yet provided a label to Rd, then Rd must defer any response to Ru 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. @@ -2260,22 +2379,22 @@ 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 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 downstream label - distribution and Liberal Label Retention Mode are being used. + 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 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. @@ -2312,22 +2430,22 @@ 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 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 downstream label distribution is - used. + 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 Suppose that Rd is an LSR which has bound a label to address prefix @@ -2369,22 +2487,22 @@ 4.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 This procedure is the same as UseImmediate, unless Ru has detected a - loop in the LSP. If a loop has been detected, Ru will discard - packets that would otherwise have been labeled with L and sent to Rd. + 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 In this case, there is only a single procedure. @@ -2394,35 +2512,37 @@ 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 binding of L to Y before it learned of the unbinding of L from X, and if packets matching both X and Y were forwarded by Ru to Rd, then for a period of time, Ru would label both packets matching X and packets matching Y with label L. The distribution and withdrawal of label bindings is done via a label - distribution protocol, or LDP. LDP is a two-party protocol. If LSR R1 - has received label bindings from LSR R2 via an instance of an LDP, - and that instance of that protocol is closed by either end (whether - as a result of failure or as a matter of normal operation), then all - bindings learned over that instance of the protocol must be + distribution protocol. All label distribution protocols require that + a label distribution adjacency be established between two label + distribution peers (except implicit peers). If LSR R1 has a label + distribution adjacency to LSR R2, and has received label bindings + from LSR R2 via that adjacency, then if adjacency is brought down by + either peer (whether as a result of failure or as a matter of normal + operation), all bindings received over that adjacency must be considered to have been withdrawn. - As long as the relevant LDP connection remains open, 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. + 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 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: - This is downstream label distribution with independent control, - liberal label retention mode, and no loop detection. + This is unsolicited downstream label distribution with + independent control, liberal label retention mode, and no loop + detection. 2. - This is downstream label distribution with independent control, - liberal label retention, and loop detection. + This is unsolicited downstream label distribution with + independent control, liberal label retention, and loop + detection. 3. - This is downstream label distribution with ordered control - (from the egress) and conservative label retention mode. Loop - detection is optional. + This is unsolicited downstream label distribution with ordered + control (from the egress) and conservative label retention + mode. Loop detection is optional. 4. - This is downstream label distribution with ordered control - (from the egress) and liberal label retention mode. Loop - detection is optional. + This is unsolicited downstream label distribution with ordered + control (from the egress) and liberal label retention mode. + Loop detection is optional. 5. This is downstream-on-demand label distribution with ordered control (initiated by the ingress), conservative label retention mode, and optional loop detection. 6. @@ -2544,24 +2666,26 @@ viable, since they will not result in the proper distribution of label bindings. - <*, RequestNever, *, *, ReleaseOnChange> In these MPLS schemes, Rd releases bindings when it isn't using them, but it never asks for them again, even if it later has a need for them. These schemes thus do not ensure that label bindings get properly distributed. - In this section, we specify rules to prevent a pair of LDP peers from - adopting procedures which lead to infeasible MPLS Schemes. These - rules require the exchange of information between LDP peers during - the initialization of the LDP connection between them. + In this section, we specify rules to prevent a pair of label + distribution peers from adopting procedures which lead to infeasible + MPLS Schemes. These rules require either the exchange of information + between label distribution peers during the initialization of the + label distribution adjacency, or apriori knowledge of the information + (obtained through a means outside the scope of this document). 1. Each must state whether it supports label merging. 2. If Rd does not support label merging, Rd must choose either the PulledUnconditional procedure or the PulledConditional procedure. If Rd chooses PulledConditional, Ru is forced to use the RequestRetry procedure. That is, if the downstream LSR does not support label merging, its preferences take priority when the MPLS scheme is chosen. @@ -2586,21 +2710,21 @@ PushConditional, PulledConditional, or PulledUnconditional. These choices together determine the MPLS scheme in use. 5. 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 security procedures to fail. + cause such 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 @@ -2635,20 +2758,25 @@ 8. References [MPLS-ATM] "MPLS using ATM VC Switching", Davie, Doolan, Lawrence, McGloghrie, Rekhter, Rosen, Swallow, work in progress, Internet Draft , November 1998. [MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, work in progress, Internet Draft , August 1998. + [MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Andersson, + Fredette, Jamoussi, Callon, Doolan, Feldman, Gray, Halpern, Heinanen, + Kilty, Malis, Girish, Sundell, Vaananen, Worster, Wu, Dantu, Internet + Draft , January 1999. + [MPLS-FRMWRK] "A Framework for Multiprotocol Label Switching", Callon, Doolan, Feldman, Fredette, Swallow, Viswanathan, work in progress, Internet Draft , November 1997 [MPLS-FRMRLY] "Use of Label Switching on Frame Relay Networks", Conta, Doolan, Malis, work in progress, Internet Draft , November 1998 [MPLS-LDP], "LDP Specification", Andersson, Doolan, Feldman,