8/9/2020
`
`RFC 3031 - Multiprotocol Label Switching Architecture
`
`Network Working Group
`Request for Comments: 3031
`Category: Standards Track
`
`E. Rosen
`Cisco Systems, Inc.
`A. Viswanathan
`Force10 Networks, Inc.
`R. Callon
`Juniper Networks, Inc.
`January 2001
`
`Multiprotocol Label Switching Architecture
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2001). All Rights Reserved.
`
`Abstract
`
` This document specifies the architecture for Multiprotocol Label
` Switching (MPLS).
`
`Table of Contents
`
` 1
` 2
` 2.1
` 2.2
` 2.3
` 2.4
` 3
` 3.1
` 3.2
` 3.3
` 3.4
` 3.5
` 3.6
` 3.7
` 3.8
` 3.9
` 3.10
` 3.11
`
`Specification ...................................... 3
`Introduction to MPLS ............................... 3
`Overview ........................................... 4
`Terminology ........................................ 6
`Acronyms and Abbreviations ......................... 9
`Acknowledgments .................................... 9
`MPLS Basics ........................................ 9
`Labels ............................................. 9
`Upstream and Downstream LSRs ....................... 10
`Labeled Packet ..................................... 11
`Label Assignment and Distribution .................. 11
`Attributes of a Label Binding ...................... 11
`Label Distribution Protocols ....................... 11
`Unsolicited Downstream vs. Downstream-on-Demand .... 12
`Label Retention Mode ............................... 12
`The Label Stack .................................... 13
`The Next Hop Label Forwarding Entry (NHLFE) ........ 13
`Incoming Label Map (ILM) ........................... 14
`
`Rosen, et al.
`
`Standards Track
`
`[Page 1]
`
`https://tools.ietf.org/html/rfc3031
`
`1/62
`
`Cloudflare - Exhibit 1014, page 1
`
`

`

`8/9/2020
`
`RFC 3031
`
`RFC 3031 - Multiprotocol Label Switching Architecture
`
`MPLS Architecture
`
`January 2001
`
`FEC-to-NHLFE Map (FTN) ............................. 14
` 3.12
` 3.13
`Label Swapping ..................................... 15
` 3.14
`Scope and Uniqueness of Labels ..................... 15
`Label Switched Path (LSP), LSP Ingress, LSP Egress . 16
` 3.15
` 3.16
`Penultimate Hop Popping ............................ 18
` 3.17
`LSP Next Hop ....................................... 20
` 3.18
`Invalid Incoming Labels ............................ 20
`LSP Control: Ordered versus Independent ............ 20
` 3.19
` 3.20
`Aggregation ........................................ 21
` 3.21
`Route Selection .................................... 23
` 3.22
`Lack of Outgoing Label ............................. 24
` 3.23
`Time-to-Live (TTL) ................................. 24
`Loop Control ....................................... 25
` 3.24
` 3.25
`Label Encodings .................................... 26
` 3.25.1 MPLS-specific Hardware and/or Software ............. 26
` 3.25.2 ATM Switches as LSRs ............................... 26
` 3.25.3 Interoperability among Encoding Techniques ......... 28
`Label Merging ...................................... 28
` 3.26
` 3.26.1 Non-merging LSRs ................................... 29
` 3.26.2 Labels for Merging and Non-Merging LSRs ............ 30
` 3.26.3 Merge over ATM ..................................... 31
` 3.26.3.1 Methods of Eliminating Cell Interleave ............. 31
` 3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 31
` 3.27
`Tunnels and Hierarchy .............................. 32
` 3.27.1 Hop-by-Hop Routed Tunnel ........................... 32
` 3.27.2 Explicitly Routed Tunnel ........................... 33
` 3.27.3 LSP Tunnels ........................................ 33
` 3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 33
` 3.27.5 Label Distribution Peering and Hierarchy ........... 34
`Label Distribution Protocol Transport .............. 35
` 3.28
` 3.29
`Why More than one Label Distribution Protocol? ..... 36
` 3.29.1 BGP and LDP ........................................ 36
` 3.29.2 Labels for RSVP Flowspecs .......................... 36
` 3.29.3 Labels for Explicitly Routed LSPs .................. 36
`Multicast .......................................... 37
` 3.30
` 4
`Some Applications of MPLS .......................... 37
` 4.1
`MPLS and Hop by Hop Routed Traffic ................. 37
` 4.1.1 Labels for Address Prefixes ........................ 37
` 4.1.2 Distributing Labels for Address Prefixes ........... 37
` 4.1.2.1 Label Distribution Peers for an Address Prefix ..... 37
` 4.1.2.2 Distributing Labels ................................ 38
` 4.1.3 Using the Hop by Hop path as the LSP ............... 39
` 4.1.4 LSP Egress and LSP Proxy Egress .................... 39
` 4.1.5 The Implicit NULL Label ............................ 40
` 4.1.6 Option: Egress-Targeted Label Assignment ........... 40
`MPLS and Explicitly Routed LSPs .................... 42
` 4.2
` 4.2.1 Explicitly Routed LSP Tunnels ...................... 42
` 4.3
`Label Stacks and Implicit Peering .................. 43
`
`Rosen, et al.
`
`Standards Track
`
`[Page 2]
`
`https://tools.ietf.org/html/rfc3031
`
`2/62
`
`Cloudflare - Exhibit 1014, page 2
`
`

`

`RFC 3031 - Multiprotocol Label Switching Architecture
`
`8/9/2020
`
`RFC 3031 MPLS Architecture January 2001
`
`
` 4.4 MPLS and Multi-Path Routing ........................ 44
` 4.5 LSP Trees as Multipoint-to-Point Entities .......... 44
` 4.6 LSP Tunneling between BGP Border Routers ........... 45
` 4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 47
` 4.8 MPLS and Multicast ................................. 47
` 5 Label Distribution Procedures (Hop-by-Hop) ......... 47
` 5.1 The Procedures for Advertising and Using labels .... 48
` 5.1.1 Downstream LSR: Distribution Procedure ............. 48
` 5.1.1.1 PushUnconditional .................................. 49
` 5.1.1.2 PushConditional .................................... 49
` 5.1.1.3 PulledUnconditional ................................ 49
` 5.1.1.4 PulledConditional .................................. 50
` 5.1.2 Upstream LSR: Request Procedure .................... 51
` 5.1.2.1 RequestNever ....................................... 51
` 5.1.2.2 RequestWhenNeeded .................................. 51
` 5.1.2.3 RequestOnRequest ................................... 51
` 5.1.3 Upstream LSR: NotAvailable Procedure ............... 52
` 5.1.3.1 RequestRetry ....................................... 52
` 5.1.3.2 RequestNoRetry ..................................... 52
` 5.1.4 Upstream LSR: Release Procedure .................... 52
` 5.1.4.1 ReleaseOnChange .................................... 52
` 5.1.4.2 NoReleaseOnChange .................................. 53
` 5.1.5 Upstream LSR: labelUse Procedure ................... 53
` 5.1.5.1 UseImmediate ....................................... 53
` 5.1.5.2 UseIfLoopNotDetected ............................... 53
` 5.1.6 Downstream LSR: Withdraw Procedure ................. 53
` 5.2 MPLS Schemes: Supported Combinations of Procedures . 54
` 5.2.1 Schemes for LSRs that Support Label Merging ........ 55
` 5.2.2 Schemes for LSRs that do not Support Label Merging . 56
` 5.2.3 Interoperability Considerations .................... 57
` 6 Security Considerations ............................ 58
` 7 Intellectual Property .............................. 58
` 8 Authors' Addresses ................................. 59
` 9 References ......................................... 59
` 10 Full Copyright Statement ........................... 61
`
`1. Specification
`
` The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
` "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
` document are to be interpreted as described in RFC 2119.
`
`2. Introduction to MPLS
`
` This document specifies the architecture for Multiprotocol Label
` Switching (MPLS).
`
` Note that the use of MPLS for multicast is left for further study.
`
`
`
`Rosen, et al. Standards Track [Page 3]
`
`https://tools.ietf.org/html/rfc3031
`
`3/62
`
`Cloudflare - Exhibit 1014, page 3
`
`

`

`RFC 3031 - Multiprotocol Label Switching Architecture
`
`8/9/2020
`
`RFC 3031 MPLS Architecture January 2001
`
`
`2.1. Overview
`
` As a packet of a connectionless network layer protocol travels from
` one router to the next, each router makes an independent forwarding
` decision for that packet. That is, each router analyzes the packet's
` header, and each router runs a network layer routing algorithm. Each
` router independently chooses a next hop for the packet, based on its
` analysis of the packet's header and the results of running the
` routing algorithm.
`
` Packet headers contain considerably more information than is needed
` simply to choose the next hop. Choosing the next hop can therefore
` be thought of as the composition of two functions. The first
` function partitions the entire set of possible packets into a set of
` "Forwarding Equivalence Classes (FECs)". The second maps each FEC to
` a next hop. Insofar as the forwarding decision is concerned,
` different packets which get mapped into the same FEC are
` indistinguishable. All packets which belong to a particular FEC and
` which travel from a particular node will follow the same path (or if
` certain kinds of multi-path routing are in use, they will all follow
` one of a set of paths associated with the FEC).
`
` In conventional IP forwarding, a particular router will typically
` consider two packets to be in the same FEC if there is some address
` prefix X in that router's routing tables such that X is the "longest
` match" for each packet's destination address. As the packet
` traverses the network, each hop in turn reexamines the packet and
` assigns it to a FEC.
`
` In MPLS, the assignment of a particular packet to a particular FEC is
` done just once, as the packet enters the network. The FEC to which
` the packet is assigned is encoded as a short fixed length value known
` as a "label". When a packet is forwarded to its next hop, the label
` is sent along with it; that is, the packets are "labeled" before they
` are forwarded.
`
` At subsequent hops, there is no further analysis of the packet's
` network layer header. Rather, the label is used as an index into a
` table which specifies the next hop, and a new label. The old label
` is replaced with the new label, and the packet is forwarded to its
` next hop.
`
` In the MPLS forwarding paradigm, once a packet is assigned to a FEC,
` no further header analysis is done by subsequent routers; all
` forwarding is driven by the labels. This has a number of advantages
` over conventional network layer forwarding.
`
`
`
`
`
`Rosen, et al. Standards Track [Page 4]
`
`https://tools.ietf.org/html/rfc3031
`
`4/62
`
`Cloudflare - Exhibit 1014, page 4
`
`

`

`RFC 3031 - Multiprotocol Label Switching Architecture
`
`8/9/2020
`
`RFC 3031 MPLS Architecture January 2001
`
`
` - MPLS forwarding can be done by switches which are capable of
` doing label lookup and replacement, but are either not capable
` of analyzing the network layer headers, or are not capable of
` analyzing the network layer headers at adequate speed.
`
` - Since a packet is assigned to a FEC when it enters the network,
` the ingress router may use, in determining the assignment, any
` information it has about the packet, even if that information
` cannot be gleaned from the network layer header. For example,
` packets arriving on different ports may be assigned to
` different FECs. Conventional forwarding, on the other hand,
` can only consider information which travels with the packet in
` the packet header.
`
` - A packet that enters the network at a particular router can be
` labeled differently than the same packet entering the network
` at a different router, and as a result forwarding decisions
` that depend on the ingress router can be easily made. This
` cannot be done with conventional forwarding, since the identity
` of a packet's ingress router does not travel with the packet.
`
` - The considerations that determine how a packet is assigned to a
` FEC can become ever more and more complicated, without any
` impact at all on the routers that merely forward labeled
` packets.
`
` - Sometimes it is desirable to force a packet to follow a
` particular route which is explicitly chosen at or before the
` time the packet enters the network, rather than being chosen by
` the normal dynamic routing algorithm as the packet travels
` through the network. This may be done as a matter of policy,
` or to support traffic engineering. In conventional forwarding,
` this requires the packet to carry an encoding of its route
` along with it ("source routing"). In MPLS, a label can be used
` to represent the route, so that the identity of the explicit
` route need not be carried with the packet.
`
` Some routers analyze a packet's network layer header not merely to
` choose the packet's next hop, but also to determine a packet's
` "precedence" or "class of service". They may then apply different
` discard thresholds or scheduling disciplines to different packets.
` MPLS allows (but does not require) the precedence or class of service
` to be fully or partially inferred from the label. In this case, one
` may say that the label represents the combination of a FEC and a
` precedence or class of service.
`
`
`
`
`
`
`Rosen, et al. Standards Track [Page 5]
`
`https://tools.ietf.org/html/rfc3031
`
`5/62
`
`Cloudflare - Exhibit 1014, page 5
`
`

`

`RFC 3031 - Multiprotocol Label Switching Architecture
`
`8/9/2020
`
`RFC 3031 MPLS Architecture January 2001
`
`
` MPLS stands for "Multiprotocol" Label Switching, multiprotocol
` because its techniques are applicable to ANY network layer protocol.
` In this document, however, we focus on the use of IP as the network
` layer protocol.
`
` A router which supports MPLS is known as a "Label Switching Router",
` or LSR.
`
`2.2. Terminology
`
` This section gives a general conceptual overview of the terms used in
` this document. Some of these terms are more precisely defined in
` later sections of the document.
`
` DLCI a label used in Frame Relay networks to
` identify frame relay circuits
`
` forwarding equivalence class a group of IP packets which are
` forwarded in the same manner (e.g.,
` over the same path, with the same
` forwarding treatment)
`
` frame merge label merging, when it is applied to
` operation over frame based media, so
` that the potential problem of cell
` interleave is not an issue.
`
` label a short fixed length physically
` contiguous identifier which is used to
` identify a FEC, usually of local
` significance.
`
`
` label merging the replacement of multiple incoming
` labels for a particular FEC with a
` single outgoing label
`
` label swap the basic forwarding operation
` consisting of looking up an incoming
` label to determine the outgoing label,
` encapsulation, port, and other data
` handling information.
`
` label swapping a forwarding paradigm allowing
` streamlined forwarding of data by using
` labels to identify classes of data
` packets which are treated
` indistinguishably when forwarding.
`
`
`
`Rosen, et al. Standards Track [Page 6]
`
`https://tools.ietf.org/html/rfc3031
`
`6/62
`
`Cloudflare - Exhibit 1014, page 6
`
`

`

`RFC 3031 - Multiprotocol Label Switching Architecture
`
`8/9/2020
`
`RFC 3031 MPLS Architecture January 2001
`
`
` label switched hop the hop between two MPLS nodes, on which
` forwarding is done using labels.
`
` label switched path The path through one or more LSRs at one
` level of the hierarchy followed by a
` packets in a particular FEC.
`
` label switching router an MPLS node which is capable of
` forwarding native L3 packets
`
` layer 2 the protocol layer under layer 3 (which
` therefore offers the services used by
` layer 3). Forwarding, when done by the
` swapping of short fixed length labels,
` occurs at layer 2 regardless of whether
` the label being examined is an ATM
` VPI/VCI, a frame relay DLCI, or an MPLS
` label.
`
` layer 3 the protocol layer at which IP and its
` associated routing protocols operate
` link layer synonymous with layer 2
`
` loop detection a method of dealing with loops in which
` loops are allowed to be set up, and data
` may be transmitted over the loop, but
` the loop is later detected
`
` loop prevention a method of dealing with loops in which
` data is never transmitted over a loop
`
` label stack an ordered set of labels
`
` merge point a node at which label merging is done
`
` MPLS domain a contiguous set of nodes which operate
` MPLS routing and forwarding and which
` are also in one Routing or
` Administrative Domain
`
` MPLS edge node an MPLS node that connects an MPLS
` domain with a node which is outside of
` the domain, either because it does not
` run MPLS, and/or because it is in a
` different domain. Note that if an LSR
` has a neighboring host which is not
` running MPLS, that that LSR is an MPLS
` edge node.
`
`
`
`Rosen, et al. Standards Track [Page 7]
`
`https://tools.ietf.org/html/rfc3031
`
`7/62
`
`Cloudflare - Exhibit 1014, page 7
`
`

`

`RFC 3031 - Multiprotocol Label Switching Architecture
`
`8/9/2020
`
`RFC 3031 MPLS Architecture January 2001
`
`
` MPLS egress node an MPLS edge node in its role in
` handling traffic as it leaves an MPLS
` domain
`
` MPLS ingress node an MPLS edge node in its role in
` handling traffic as it enters an MPLS
` domain
`
` MPLS label a label which is carried in a packet
` header, and which represents the
` packet's FEC
`
` MPLS node a node which is running MPLS. An MPLS
` node will be aware of MPLS control
` protocols, will operate one or more L3
` routing protocols, and will be capable
` of forwarding packets based on labels.
` An MPLS node may optionally be also
` capable of forwarding native L3 packets.
`
` MultiProtocol Label Switching an IETF working group and the
` effort associated with the working
` group
`
` network layer synonymous with layer 3
`
` stack synonymous with label stack
`
` switched path synonymous with label switched path
`
` virtual circuit a circuit used by a connection-oriented
` layer 2 technology such as ATM or Frame
` Relay, requiring the maintenance of
` state information in layer 2 switches.
`
` VC merge label merging where the MPLS label is
` carried in the ATM VCI field (or
` combined VPI/VCI field), so as to allow
` multiple VCs to merge into one single VC
`
` VP merge label merging where the MPLS label is
` carried din the ATM VPI field, so as to
` allow multiple VPs to be merged into one
` single VP. In this case two cells would
` have the same VCI value only if they
` originated from the same node. This
` allows cells from different sources to
` be distinguished via the VCI.
`
`
`
`Rosen, et al. Standards Track [Page 8]
`
`https://tools.ietf.org/html/rfc3031
`
`8/62
`
`Cloudflare - Exhibit 1014, page 8
`
`

`

`RFC 3031 - Multiprotocol Label Switching Architecture
`
`8/9/2020
`
`RFC 3031 MPLS Architecture January 2001
`
`
` VPI/VCI a label used in ATM networks to identify
` circuits
`
`2.3. Acronyms and Abbreviations
`
` ATM Asynchronous Transfer Mode
` BGP Border Gateway Protocol
` DLCI Data Link Circuit Identifier
` FEC Forwarding Equivalence Class
` FTN FEC to NHLFE Map
` IGP Interior Gateway Protocol
` ILM Incoming Label Map
` IP Internet Protocol
` LDP Label Distribution Protocol
` L2 Layer 2 L3 Layer 3
` LSP Label Switched Path
` LSR Label Switching Router
` MPLS MultiProtocol Label Switching
` NHLFE Next Hop Label Forwarding Entry
` SVC Switched Virtual Circuit
` SVP Switched Virtual Path
` TTL Time-To-Live
` VC Virtual Circuit
` VCI Virtual Circuit Identifier
` VP Virtual Path
` VPI Virtual Path Identifier
`
`2.4. Acknowledgments
`
` The ideas and text in this document have been collected from a number
` of sources and comments received. We would like to thank Rick
` Boivie, Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan,
` and George Swallow for their inputs and ideas.
`
`3. MPLS Basics
`
` In this section, we introduce some of the basic concepts of MPLS and
` describe the general approach to be used.
`
`3.1. Labels
`
` A label is a short, fixed length, locally significant identifier
` which is used to identify a FEC. The label which is put on a
` particular packet represents the Forwarding Equivalence Class to
` which that packet is assigned.
`
`
`
`
`
`
`Rosen, et al. Standards Track [Page 9]
`
`https://tools.ietf.org/html/rfc3031
`
`9/62
`
`Cloudflare - Exhibit 1014, page 9
`
`

`

`RFC 3031 - Multiprotocol Label Switching Architecture
`
`8/9/2020
`
`RFC 3031 MPLS Architecture January 2001
`
`
` Most commonly, a packet is assigned to a FEC based (completely or
` partially) on its network layer destination address. However, the
` label is never an encoding of that address.
`
` If Ru and Rd are LSRs, they may agree that when Ru transmits a packet
` to Rd, Ru will label with packet with label value L if and only if
` the packet is a member of a particular FEC F. That is, they can
` agree to a "binding" between label L and FEC F for packets moving
` from Ru to Rd. As a result of such an agreement, L becomes Ru's
` "outgoing label" representing FEC F, and L becomes Rd's "incoming
` label" representing FEC F.
`
` Note that L does not necessarily represent FEC F for any packets
` other than those which are being sent from Ru to Rd. L is an
` arbitrary value whose binding to F is local to Ru and Rd.
`
` When we speak above of packets "being sent" from Ru to Rd, we do not
` imply either that the packet originated at Ru or that its destination
` is Rd. Rather, we mean to include packets which are "transit
` packets" at one or both of the LSRs.
`
` Sometimes it may be difficult or even impossible for Rd to tell, of
` an arriving packet carrying label L, that the label L was placed in
` the packet by Ru, rather than by some other LSR. (This will
` typically be the case when Ru and Rd are not direct neighbors.) In
` such cases, Rd must make sure that the binding from label to FEC is
` one-to-one. That is, Rd MUST NOT agree with Ru1 to bind L to FEC F1,
` while also agreeing with some other LSR Ru2 to bind L to a different
` FEC F2, UNLESS Rd can always tell, when it receives a packet with
` incoming label L, whether the label was put on the packet by Ru1 or
` whether it was put on by Ru2.
`
` It is the responsibility of each LSR to ensure that it can uniquely
` interpret its incoming labels.
`
`3.2. Upstream and Downstream LSRs
`
` Suppose Ru and Rd have agreed to bind label L to FEC F, for packets
` sent from Ru to Rd. Then with respect to this binding, Ru is the
` "upstream LSR", and Rd is the "downstream LSR".
`
` To say that one node is upstream and one is downstream with respect
` to a given binding means only that a particular label represents a
` particular FEC in packets travelling from the upstream node to the
` downstream node. This is NOT meant to imply that packets in that FEC
` would actually be routed from the upstream node to the downstream
` node.
`
`
`
`
`Rosen, et al. Standards Track [Page 10]
`
`https://tools.ietf.org/html/rfc3031
`
`10/62
`
`Cloudflare - Exhibit 1014, page 10
`
`

`

`RFC 3031 - Multiprotocol Label Switching Architecture
`
`8/9/2020
`
`RFC 3031 MPLS Architecture January 2001
`
`
`3.3. Labeled Packet
`
` A "labeled packet" is a packet into which a label has been encoded.
` In some cases, the label resides in an encapsulation header which
` exists specifically for this purpose. In other cases, the label may
` reside in an existing data link or network layer header, as long as
` there is a field which is available for that purpose. The particular
` encoding technique to be used must be agreed to by both the entity
` which encodes the label and the entity which decodes the label.
`
`3.4. Label Assignment and Distribution
`
` In the MPLS architecture, the decision to bind a particular label L
` to a particular FEC F is made by the LSR which is DOWNSTREAM with
` respect to that binding. The downstream LSR then informs the
` upstream LSR of the binding. Thus labels are "downstream-assigned",
` and label bindings are distributed in the "downstream to upstream"
` direction.
`
` If an LSR has been designed so that it can only look up labels that
` fall into a certain numeric range, then it merely needs to ensure
` that it only binds labels that are in that range.
`
`3.5. Attributes of a Label Binding
`
` A particular binding of label L to FEC F, distributed by Rd to Ru,
` may have associated "attributes". If Ru, acting as a downstream LSR,
` also distributes a binding of a label to FEC F, then under certain
` conditions, it may be required to also distribute the corresponding
` attribute that it received from Rd.
`
`3.6. Label Distribution Protocols
`
` A label distribution protocol is a set of procedures by which one LSR
` informs another of the label/FEC bindings it has made. Two LSRs
` which use a label distribution protocol to exchange label/FEC binding
` information are known as "label distribution peers" with respect to
` the binding information they exchange. If two LSRs are label
` distribution peers, we will speak of there being a "label
` distribution adjacency" between them.
`
` (N.B.: two LSRs may be label distribution peers with respect to some
` set of bindings, but not with respect to some other set of bindings.)
`
` The label distribution protocol also encompasses any negotiations in
` which two label distribution peers need to engage in order to learn
` of each other's MPLS capabilities.
`
`
`
`
`Rosen, et al. Standards Track [Page 11]
`
`https://tools.ietf.org/html/rfc3031
`
`11/62
`
`Cloudflare - Exhibit 1014, page 11
`
`

`

`RFC 3031 - Multiprotocol Label Switching Architecture
`
`8/9/2020
`
`RFC 3031 MPLS Architecture January 2001
`
`
` THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL
` DISTRIBUTION PROTOCOL. In fact, a number of different label
` distribution protocols are being standardized. Existing protocols
` have been extended so that label distribution can be piggybacked on
` them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). New protocols
` have also been defined for the explicit purpose of distributing
` labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].
`
` In this document, we try to use the acronym "LDP" to refer
` specifically to the protocol defined in [MPLS-LDP]; when speaking of
` label distribution protocols in general, we try to avoid the acronym.
`
`3.7. Unsolicited Downstream vs. Downstream-on-Demand
`
` The MPLS architecture allows an LSR to explicitly request, from its
` next hop for a particular FEC, a label binding for that FEC. This is
` known as "downstream-on-demand" label distribution.
`
` The MPLS architecture also allows an LSR to distribute bindings to
` LSRs that have not explicitly requested them. This is known as
` "unsolicited downstream" label distribution.
`
` It is expected that some MPLS implementations will provide only
` downstream-on-demand label distribution, and some will provide only
` unsolicited downstream label distribution, and some will provide
` both. Which is provided may depend on the characteristics of the
` interfaces which are supported by a particular implementation.
` However, both of these label distribution techn