draft-ietf-mpls-arch-02.txt   draft-ietf-mpls-arch-03.txt 
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Expiration Date: January 1999 Expiration Date: August 1999
Arun Viswanathan Arun Viswanathan
Lucent Technologies Lucent Technologies
Ross Callon Ross Callon
IronBridge Networks, Inc. IronBridge Networks, Inc.
July 1998 February 1999
Multiprotocol Label Switching Architecture Multiprotocol Label Switching Architecture
draft-ietf-mpls-arch-02.txt draft-ietf-mpls-arch-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the To view the list Internet-Draft Shadow Directories, see
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/shadow.html.
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This internet draft specifies the architecture for multiprotocol This internet draft specifies the architecture for Multiprotocol
label switching (MPLS). The architecture is based on other label Label Switching (MPLS).
switching approaches [2-11] as well as on the MPLS Framework document
[1].
Table of Contents Table of Contents
1 Introduction to MPLS ............................... 4 1 Introduction to MPLS ............................... 4
1.1 Overview ........................................... 4 1.1 Overview ........................................... 4
1.2 Terminology ........................................ 6 1.2 Terminology ........................................ 6
1.3 Acronyms and Abbreviations ......................... 9 1.3 Acronyms and Abbreviations ......................... 9
1.4 Acknowledgments .................................... 10 1.4 Acknowledgments .................................... 10
2 Outline of Approach ................................ 10 2 MPLS Basics ........................................ 10
2.1 Labels ............................................. 11 2.1 Labels ............................................. 10
2.2 Upstream and Downstream LSRs ....................... 12 2.2 Upstream and Downstream LSRs ....................... 11
2.3 Labeled Packet ..................................... 12 2.3 Labeled Packet ..................................... 11
2.4 Label Assignment and Distribution .................. 12 2.4 Label Assignment and Distribution .................. 11
2.5 Attributes of a Label Binding ...................... 12 2.5 Attributes of a Label Binding ...................... 12
2.6 Label Distribution Protocol (LDP) .................. 13 2.6 Label Distribution Protocol (LDP) .................. 12
2.7 Downstream vs. Downstream-on-Demand ................ 13 2.7 Downstream vs. Downstream-on-Demand ................ 12
2.8 Label Retention Mode ............................... 13 2.8 Label Retention Mode ............................... 13
2.9 The Label Stack .................................... 14 2.9 The Label Stack .................................... 13
2.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 14 2.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 14
2.11 Incoming Label Map (ILM) ........................... 15 2.11 Incoming Label Map (ILM) ........................... 15
2.12 FEC-to-NHLFE Map (FTN) ............................. 15 2.12 FEC-to-NHLFE Map (FTN) ............................. 15
2.13 Label Swapping ..................................... 16 2.13 Label Swapping ..................................... 15
2.14 Scope and Uniqueness of Labels ..................... 16 2.14 Scope and Uniqueness of Labels ..................... 15
2.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 17 2.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 17
2.16 Penultimate Hop Popping ............................ 19 2.16 Penultimate Hop Popping ............................ 18
2.17 LSP Next Hop ....................................... 20 2.17 LSP Next Hop ....................................... 20
2.18 Invalid Incoming Labels ............................ 21 2.18 Invalid Incoming Labels ............................ 20
2.19 LSP Control: Ordered versus Independent ............ 21 2.19 LSP Control: Ordered versus Independent ............ 21
2.20 Aggregation ........................................ 22 2.20 Aggregation ........................................ 22
2.21 Route Selection .................................... 24 2.21 Route Selection .................................... 23
2.22 Time-to-Live (TTL) ................................. 25 2.22 Lack of Outgoing Label ............................. 24
2.23 Loop Control ....................................... 26 2.23 Time-to-Live (TTL) ................................. 24
2.23.1 Loop Prevention .................................... 27 2.24 Loop Control ....................................... 26
2.23.2 Interworking of Loop Control Options ............... 29 2.25 Label Encodings .................................... 26
2.24 Label Encodings .................................... 30 2.25.1 MPLS-specific Hardware and/or Software ............. 26
2.24.1 MPLS-specific Hardware and/or Software ............. 31 2.25.2 ATM Switches as LSRs ............................... 27
2.24.2 ATM Switches as LSRs ............................... 31 2.25.3 Interoperability among Encoding Techniques ......... 28
2.24.3 Interoperability among Encoding Techniques ......... 33 2.26 Label Merging ...................................... 29
2.25 Label Merging ...................................... 33 2.26.1 Non-merging LSRs ................................... 30
2.25.1 Non-merging LSRs ................................... 34 2.26.2 Labels for Merging and Non-Merging LSRs ............ 30
2.25.2 Labels for Merging and Non-Merging LSRs ............ 35 2.26.3 Merge over ATM ..................................... 31
2.25.3 Merge over ATM ..................................... 36 2.26.3.1 Methods of Eliminating Cell Interleave ............. 31
2.25.3.1 Methods of Eliminating Cell Interleave ............. 36 2.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 32
2.25.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 36 2.27 Tunnels and Hierarchy .............................. 33
2.26 Tunnels and Hierarchy .............................. 37 2.27.1 Hop-by-Hop Routed Tunnel ........................... 33
2.26.1 Hop-by-Hop Routed Tunnel ........................... 38 2.27.2 Explicitly Routed Tunnel ........................... 33
2.26.2 Explicitly Routed Tunnel ........................... 38 2.27.3 LSP Tunnels ........................................ 33
2.26.3 LSP Tunnels ........................................ 38 2.27.4 Hierarchy: LSP Tunnels within LSPs ................. 34
2.26.4 Hierarchy: LSP Tunnels within LSPs ................. 39 2.27.5 LDP Peering and Hierarchy .......................... 34
2.26.5 LDP Peering and Hierarchy .......................... 39 2.28 LDP Transport ...................................... 36
2.27 LDP Transport ...................................... 40 2.29 Multicast .......................................... 36
2.28 Multicast .......................................... 41 3 Some Applications of MPLS .......................... 36
3 Some Applications of MPLS .......................... 41 3.1 MPLS and Hop by Hop Routed Traffic ................. 36
3.1 MPLS and Hop by Hop Routed Traffic ................. 41 3.1.1 Labels for Address Prefixes ........................ 36
3.1.1 Labels for Address Prefixes ........................ 41 3.1.2 Distributing Labels for Address Prefixes ........... 37
3.1.2 Distributing Labels for Address Prefixes ........... 41 3.1.2.1 LDP Peers for a Particular Address Prefix .......... 37
3.1.2.1 LDP Peers for a Particular Address Prefix .......... 41 3.1.2.2 Distributing Labels ................................ 37
3.1.2.2 Distributing Labels ................................ 42 3.1.3 Using the Hop by Hop path as the LSP ............... 38
3.1.3 Using the Hop by Hop path as the LSP ............... 43 3.1.4 LSP Egress and LSP Proxy Egress .................... 39
3.1.4 LSP Egress and LSP Proxy Egress .................... 43 3.1.5 The Implicit NULL Label ............................ 39
3.1.5 The Implicit NULL Label ............................ 44 3.1.6 Option: Egress-Targeted Label Assignment ........... 40
3.1.6 Option: Egress-Targeted Label Assignment ........... 45 3.2 MPLS and Explicitly Routed LSPs .................... 42
3.2 MPLS and Explicitly Routed LSPs .................... 46 3.2.1 Explicitly Routed LSP Tunnels ...................... 42
3.2.1 Explicitly Routed LSP Tunnels: Traffic Engineering . 46 3.3 Label Stacks and Implicit Peering .................. 43
3.3 Label Stacks and Implicit Peering .................. 47 3.4 MPLS and Multi-Path Routing ........................ 44
3.4 MPLS and Multi-Path Routing ........................ 48 3.5 LSP Trees as Multipoint-to-Point Entities .......... 44
3.5 LSP Trees as Multipoint-to-Point Entities .......... 48 3.6 LSP Tunneling between BGP Border Routers ........... 45
3.6 LSP Tunneling between BGP Border Routers ........... 49 3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 46
3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 50 3.8 MPLS and Multicast ................................. 47
3.8 MPLS and Multicast ................................. 51 4 LDP Procedures for Hop-by-Hop Routed Traffic ....... 47
4 LDP Procedures for Hop-by-Hop Routed Traffic ....... 51 4.1 The Procedures for Advertising and Using labels .... 47
4.1 The Procedures for Advertising and Using labels .... 51 4.1.1 Downstream LSR: Distribution Procedure ............. 48
4.1.1 Downstream LSR: Distribution Procedure ............. 52 4.1.1.1 PushUnconditional .................................. 48
4.1.1.1 PushUnconditional .................................. 52 4.1.1.2 PushConditional .................................... 49
4.1.1.2 PushConditional .................................... 53 4.1.1.3 PulledUnconditional ................................ 49
4.1.1.3 PulledUnconditional ................................ 53 4.1.1.4 PulledConditional .................................. 50
4.1.1.4 PulledConditional .................................. 54 4.1.2 Upstream LSR: Request Procedure .................... 50
4.1.2 Upstream LSR: Request Procedure .................... 55 4.1.2.1 RequestNever ....................................... 51
4.1.2.1 RequestNever ....................................... 55 4.1.2.2 RequestWhenNeeded .................................. 51
4.1.2.2 RequestWhenNeeded .................................. 55 4.1.2.3 RequestOnRequest ................................... 51
4.1.2.3 RequestOnRequest ................................... 55 4.1.3 Upstream LSR: NotAvailable Procedure ............... 51
4.1.3 Upstream LSR: NotAvailable Procedure ............... 56 4.1.3.1 RequestRetry ....................................... 52
4.1.3.1 RequestRetry ....................................... 56 4.1.3.2 RequestNoRetry ..................................... 52
4.1.3.2 RequestNoRetry ..................................... 56 4.1.4 Upstream LSR: Release Procedure .................... 52
4.1.4 Upstream LSR: Release Procedure .................... 56 4.1.4.1 ReleaseOnChange .................................... 52
4.1.4.1 ReleaseOnChange .................................... 56 4.1.4.2 NoReleaseOnChange .................................. 52
4.1.4.2 NoReleaseOnChange .................................. 57 4.1.5 Upstream LSR: labelUse Procedure ................... 53
4.1.5 Upstream LSR: labelUse Procedure ................... 57 4.1.5.1 UseImmediate ....................................... 53
4.1.5.1 UseImmediate ....................................... 57 4.1.5.2 UseIfLoopNotDetected ............................... 53
4.1.5.2 UseIfLoopFree ...................................... 57 4.1.6 Downstream LSR: Withdraw Procedure ................. 53
4.1.5.3 UseIfLoopNotDetected ............................... 58 4.2 MPLS Schemes: Supported Combinations of Procedures . 54
4.1.6 Downstream LSR: Withdraw Procedure ................. 58 4.2.1 Schemes for LSRs that Support Label Merging ........ 55
4.2 MPLS Schemes: Supported Combinations of Procedures . 59 4.2.2 Schemes for LSRs that do not Support Label Merging . 56
4.2.1 TTL-capable LSP Segments ........................... 59 4.2.3 Interoperability Considerations .................... 57
4.2.2 Using ATM Switches as LSRs ......................... 60 5 Security Considerations ............................ 58
4.2.2.1 Without Label Merging .............................. 60 6 Intellectual Property .............................. 58
4.2.2.2 With Label Merging ................................. 61 7 Authors' Addresses ................................. 58
4.2.3 Interoperability Considerations .................... 62 8 References ......................................... 59
5 Security Considerations ............................ 63
6 Authors' Addresses ................................. 63
7 References ......................................... 64
1. Introduction to MPLS 1. Introduction to MPLS
1.1. Overview 1.1. Overview
In connectionless network layer protocols, as a packet travels from As a packet of a connectionless network layer protocol travels from
one router hop to the next, an independent forwarding decision is one router to the next, each router makes an independent forwarding
made at each hop. Each router runs a network layer routing decision for that packet. That is, each router analyzes the packet's
algorithm. As a packet travels through the network, each router header, and each router runs a network layer routing algorithm. Each
analyzes the packet header. The choice of next hop for a packet is router independently chooses a next hop for the packet, based on its
based on the header analysis and the result of running the routing analysis of the packet's header and the results of running the
algorithm. routing algorithm.
Packet headers contain considerably more information than is needed Packet headers contain considerably more information than is needed
simply to choose the next hop. Choosing the next hop can therefore be simply to choose the next hop. Choosing the next hop can therefore be
thought of as the composition of two functions. The first function thought of as the composition of two functions. The first function
partitions the entire set of possible packets into a set of partitions the entire set of possible packets into a set of
"Forwarding Equivalence Classes (FECs)". The second maps each FEC to "Forwarding Equivalence Classes (FECs)". The second maps each FEC to
a next hop. Insofar as the forwarding decision is concerned, a next hop. Insofar as the forwarding decision is concerned,
different packets which get mapped into the same FEC are different packets which get mapped into the same FEC are
indistinguishable. All packets which belong to a particular FEC and indistinguishable. All packets which belong to a particular FEC and
which travel from a particular node will follow the same path. 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 In conventional IP forwarding, a particular router will typically
consider two packets to be in the same FEC if there is some address 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 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 match" for each packet's destination address. As the packet traverses
the network, each hop in turn reexamines the packet and assigns it to the network, each hop in turn reexamines the packet and assigns it to
a FEC. a FEC.
In MPLS, the assignment of a particular packet to a particular FEC is 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 done just once, as the packet enters the network. The FEC to which
the packet is assigned is encoded with a short fixed length value the packet is assigned is encoded as a short fixed length value known
known as a "label". When a packet is forwarded to its next hop, the as a "label". When a packet is forwarded to its next hop, the label
label is sent along with it; that is, the packets are "labeled". 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 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 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 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 is replaced with the new label, and the packet is forwarded to its
next hop. If assignment to a FEC is based on a "longest match", this next hop.
eliminates the need to perform a longest match computation for each
packet at each hop; the computation can be performed just once. 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.
- 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 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 choose the packet's next hop, but also to determine a packet's
"precedence" or "class of service", in order to apply different "precedence" or "class of service". They may then apply different
discard thresholds or scheduling disciplines to different packets. discard thresholds or scheduling disciplines to different packets.
MPLS allows the precedence or class of service to be inferred from
the label, so that no further header analysis is needed; in some
cases MPLS provides a way to explicitly encode a class of service in
the "label header".
The fact that a packet is assigned to a FEC just once, rather than at MPLS allows (but does not require) the precedence or class of service
every hop, allows the use of sophisticated forwarding paradigms. A to be fully or partially inferred from the label. In this case, one
packet that enters the network at a particular router can be labeled may say that the label represents the combination of a FEC and a
differently than the same packet entering the network at a different precedence or class of service.
router, and as a result forwarding decisions that depend on the
ingress point ("policy routing") can be easily made. In fact, the
policy used to assign a packet to a FEC need not have only the
network layer header as input; it may use arbitrary information about
the packet, and/or arbitrary policy information as input. Since this
decouples forwarding from routing, it allows one to use MPLS to
support a large variety of routing policies that are difficult or
impossible to support with just conventional network layer
forwarding.
Similarly, MPLS facilitates the use of explicit routing, without
requiring that each IP packet carry the explicit route. Explicit
routes may be useful to support policy routing and traffic
engineering.
MPLS makes use of a routing approach whereby the normal mode of
operation is that L3 routing (e.g., existing IP routing protocols
and/or new IP routing protocols) is used by all nodes to determine
the routed path.
MPLS stands for "Multiprotocol" Label Switching, multiprotocol MPLS stands for "Multiprotocol" Label Switching, multiprotocol
because its techniques are applicable to ANY network layer protocol. because its techniques are applicable to ANY network layer protocol.
In this document, however, we focus on the use of IP as the network In this document, however, we focus on the use of IP as the network
layer protocol. layer protocol.
A router which supports MPLS is known as a "Label Switching Router", A router which supports MPLS is known as a "Label Switching Router",
or LSR. or LSR.
A general discussion of issues related to MPLS is presented in "A A general discussion of issues related to MPLS is presented in "A
Framework for Multiprotocol Label Switching" [1]. Framework for Multiprotocol Label Switching" [MPLS-FRMWRK].
1.2. Terminology 1.2. Terminology
This section gives a general conceptual overview of the terms used in This section gives a general conceptual overview of the terms used in
this document. Some of these terms are more precisely defined in this document. Some of these terms are more precisely defined in
later sections of the document. later sections of the document.
DLCI a label used in Frame Relay networks to DLCI a label used in Frame Relay networks to
identify frame relay circuits identify frame relay circuits
flow a single instance of an application to
application flow of data (as in the RSVP
and IFMP use of the term "flow")
forwarding equivalence class a group of IP packets which are forwarding equivalence class a group of IP packets which are
forwarded in the same manner (e.g., forwarded in the same manner (e.g.,
over the same path, with the same over the same path, with the same
forwarding treatment) forwarding treatment)
frame merge label merging, when it is applied to frame merge label merging, when it is applied to
operation over frame based media, so that operation over frame based media, so that
the potential problem of cell interleave the potential problem of cell interleave
is not an issue. is not an issue.
skipping to change at page 7, line 8 skipping to change at page 7, line 19
label swapping a forwarding paradigm allowing label swapping a forwarding paradigm allowing
streamlined forwarding of data by using streamlined forwarding of data by using
labels to identify classes of data labels to identify classes of data
packets which are treated packets which are treated
indistinguishably when forwarding. indistinguishably when forwarding.
label switched hop the hop between two MPLS nodes, on which label switched hop the hop between two MPLS nodes, on which
forwarding is done using labels. forwarding is done using labels.
label switched path the path created by the concatenation of label switched path The path through one or more LSRs at one
one or more label switched hops, allowing level of the hierarchy followed by a
a packet to be forwarded by swapping packets in a particular FEC.
labels from an MPLS node to another MPLS
node. label switching router an MPLS node which is capable of
forwarding native L3 packets
layer 2 the protocol layer under layer 3 (which layer 2 the protocol layer under layer 3 (which
therefore offers the services used by therefore offers the services used by
layer 3). Forwarding, when done by the layer 3). Forwarding, when done by the
swapping of short fixed length labels, swapping of short fixed length labels,
occurs at layer 2 regardless of whether occurs at layer 2 regardless of whether
the label being examined is an ATM the label being examined is an ATM
VPI/VCI, a frame relay DLCI, or an MPLS VPI/VCI, a frame relay DLCI, or an MPLS
label. label.
layer 3 the protocol layer at which IP and its layer 3 the protocol layer at which IP and its
associated routing protocols operate link associated routing protocols operate link
layer synonymous with layer 2 layer synonymous with layer 2
loop detection a method of dealing with loops in which loop detection a method of dealing with loops in which
loops are allowed to be set up, and data loops are allowed to be set up, and data
may be transmitted over the loop, but the may be transmitted over the loop, but the
loop is later detected and closed loop is later detected
loop prevention a method of dealing with loops in which loop prevention a method of dealing with loops in which
data is never transmitted over a loop data is never transmitted over a loop
label stack an ordered set of labels label stack an ordered set of labels
loop survival a method of dealing with loops in which
data may be transmitted over a loop, but
means are employed to limit the amount of
network resources which may be consumed
by the looping data
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
merge point a node at which label merging is done merge point a node at which label merging is done
MPLS core standards the standards which describe the core
MPLS technology
MPLS domain a contiguous set of nodes which operate MPLS domain a contiguous set of nodes which operate
MPLS routing and forwarding and which are MPLS routing and forwarding and which are
also in one Routing or Administrative also in one Routing or Administrative
Domain Domain
MPLS edge node an MPLS node that connects an MPLS domain MPLS edge node an MPLS node that connects an MPLS domain
with a node which is outside of the with a node which is outside of the
domain, either because it does not run domain, either because it does not run
MPLS, and/or because it is in a different MPLS, and/or because it is in a different
domain. Note that if an LSR has a domain. Note that if an LSR has a
skipping to change at page 9, line 31 skipping to change at page 9, line 25
originated from the same node. This originated from the same node. This
allows cells from different sources to be allows cells from different sources to be
distinguished via the VCI. distinguished via the VCI.
VPI/VCI a label used in ATM networks to identify VPI/VCI a label used in ATM networks to identify
circuits circuits
1.3. Acronyms and Abbreviations 1.3. Acronyms and Abbreviations
ATM Asynchronous Transfer Mode ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol BGP Border Gateway Protocol
DLCI Data Link Circuit Identifier DLCI Data Link Circuit Identifier
FEC Forwarding Equivalence Class FEC Forwarding Equivalence Class
FTN FEC to NHLFE Map FTN FEC to NHLFE Map
IGP Interior Gateway Protocol IGP Interior Gateway Protocol
ILM Incoming Label Map ILM Incoming Label Map
IP Internet Protocol IP Internet Protocol
LDP Label Distribution Protocol LDP Label Distribution Protocol
L2 Layer 2 L3 Layer 3
L2 Layer 2
L3 Layer 3
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
MPLS MultiProtocol Label Switching MPLS MultiProtocol Label Switching
MPT Multipoint to Point Tree
NHLFE Next Hop Label Forwarding Entry NHLFE Next Hop Label Forwarding Entry
SVC Switched Virtual Circuit SVC Switched Virtual Circuit
SVP Switched Virtual Path SVP Switched Virtual Path
TTL Time-To-Live TTL Time-To-Live
VC Virtual Circuit VC Virtual Circuit
VCI Virtual Circuit Identifier VCI Virtual Circuit Identifier
VP Virtual Path VP Virtual Path
VPI Virtual Path Identifier VPI Virtual Path Identifier
1.4. Acknowledgments 1.4. Acknowledgments
The ideas and text in this document have been collected from a number 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, of sources and comments received. We would like to thank Rick Boivie,
Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan, and Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan, and
George Swallow for their inputs and ideas. George Swallow for their inputs and ideas.
2. Outline of Approach 2. MPLS Basics
In this section, we introduce some of the basic concepts of MPLS and In this section, we introduce some of the basic concepts of MPLS and
describe the general approach to be used. describe the general approach to be used.
2.1. Labels 2.1. Labels
A label is a short, fixed length, locally significant identifier A label is a short, fixed length, locally significant identifier
which is used to identify a FEC. The label which is put on a which is used to identify a FEC. The label which is put on a
particular packet represents the Forwarding Equivalence Class to particular packet represents the Forwarding Equivalence Class to
which that packet is assigned. which that packet is assigned.
Most commonly, packets are assigned to FECS based on their Most commonly, a packet is assigned to a FEC based (completely or
destination network layer addresses. However, the label is never an partially) on its network layer destination address. However, the
encoding of the destination network layer address. label is never an encoding of that address.
If Ru and Rd are LSRs, they may agree that when Ru transmits a packet 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 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 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 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 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 "outgoing label" representing FEC F, and L becomes Rd's "incoming
label" representing FEC F. label" representing FEC F.
Note that L does not necessarily represent FEC F for any packets 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 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. arbitrary value whose binding to F is local to Ru and Rd.
When we speak above of packets "being sent" from Ru to to Rd, we do When we speak above of packets "being sent" from Ru to Rd, we do not
not imply either that the packet originated at Ru or that its imply either that the packet originated at Ru or that its destination
destination is Rd. Rather, we mean to include packets which are is Rd. Rather, we mean to include packets which are "transit
"transit packets" at one or both of the LSRs. packets" at one or both of the LSRs.
Sometimes it may be difficult or even impossible for Rd to tell, of 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 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 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 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 such cases, Rd must make sure that the binding from label to FEC is
one-to-one. That is, in such cases, Rd must not agree with Ru1 to one-to-one. That is, Rd MUST NOT agree with Ru1 to bind L to FEC F1,
bind L to FEC F1, while also agreeing with some other LSR Ru2 to bind while also agreeing with some other LSR Ru2 to bind L to a different
L to a different FEC F2. It is the responsibility of each LSR to FEC F2, UNLESS Rd can always tell, when it receives a packet with
ensure that it can uniquely interpret its incoming labels. incoming label L, whether the label was put on the packet by Ru1 or
whether it was put on by Ru2.
It is the responsibility of each LSR to ensure that it can uniquely
interpret its incoming labels.
2.2. Upstream and Downstream LSRs 2.2. Upstream and Downstream LSRs
Suppose Ru and Rd have agreed to bind label L to FEC F, for packets 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 sent from Ru to Rd. Then with respect to this binding, Ru is the
"upstream LSR", and Rd is the "downstream LSR". "upstream LSR", and Rd is the "downstream LSR".
To say that one node is upstream and one is downstream with respect 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 to a given binding means only that a particular label represents a
particular FEC in packets travelling from the upstream node to the particular FEC in packets travelling from the upstream node to the
skipping to change at page 12, line 37 skipping to change at page 11, line 44
2.4. Label Assignment and Distribution 2.4. Label Assignment and Distribution
In the MPLS architecture, the decision to bind a particular label L 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 to a particular FEC F is made by the LSR which is DOWNSTREAM with
respect to that binding. The downstream LSR then informs the respect to that binding. The downstream LSR then informs the
upstream LSR of the binding. Thus labels are "downstream-assigned", upstream LSR of the binding. Thus labels are "downstream-assigned",
and label bindings are distributed in the "downstream to upstream" and label bindings are distributed in the "downstream to upstream"
direction. direction.
If an LSR has been designed so that it can only look up labels that
fall into a certain numeric range, then it merely needs to ensure
that it only binds labels that are in that range.
2.5. Attributes of a Label Binding 2.5. Attributes of a Label Binding
A particular binding of label L to FEC F, distributed by Rd to Ru, 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, may have associated "attributes". If Ru, acting as a downstream LSR,
also distributes a binding of a label to FEC F, then under certain also distributes a binding of a label to FEC F, then under certain
conditions, it may be required to also distribute the corresponding conditions, it may be required to also distribute the corresponding
attribute that it received from Rd. attribute that it received from Rd.
2.6. Label Distribution Protocol (LDP) 2.6. Label Distribution Protocol (LDP)
skipping to change at page 13, line 20 skipping to change at page 12, line 28
known as "LDP Peers" with respect to the binding information they 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 exchange. If two LSRs are LDP Peers, we will speak of there being an
"LDP Adjacency" between them. "LDP Adjacency" between them.
(N.B.: two LSRs may be LDP Peers with respect to some set of (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.) bindings, but not with respect to some other set of bindings.)
The LDP also encompasses any negotiations in which two LDP Peers need The LDP also encompasses any negotiations in which two LDP Peers need
to engage in order to learn of each other's MPLS capabilities. 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.
2.7. Downstream vs. Downstream-on-Demand 2.7. Downstream vs. Downstream-on-Demand
The MPLS architecture allows an LSR to explicitly request, from its 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 next hop for a particular FEC, a label binding for that FEC. This is
known as "downstream-on-demand" label distribution. known as "downstream-on-demand" label distribution.
The MPLS architecture also allows an LSR to distribute bindings to The MPLS architecture also allows an LSR to distribute bindings to
LSRs that have not explicitly requested them. This is known as LSRs that have not explicitly requested them. This is known as
"downstream" label distribution. "downstream" label distribution.
skipping to change at page 14, line 7 skipping to change at page 13, line 24
eventually becomes its next hop for the FEC in question. If Ru eventually becomes its next hop for the FEC in question. If Ru
discards such bindings, then if Rd later becomes the next hop, the discards such bindings, then if Rd later becomes the next hop, the
binding will have to be reacquired. binding will have to be reacquired.
If an LSR supports "Liberal Label Retention Mode", it maintains the If an LSR supports "Liberal Label Retention Mode", it maintains the
bindings between a label and a FEC which are received from LSRs which bindings between a label and a FEC which are received from LSRs which
are not its next hop for that FEC. If an LSR supports "Conservative are not its next hop for that FEC. If an LSR supports "Conservative
Label Retention Mode", it discards such bindings. Label Retention Mode", it discards such bindings.
Liberal label retention mode allows for quicker adaptation to routing Liberal label retention mode allows for quicker adaptation to routing
changes, especially if loop prevention (see section 2.23) is not changes, but conservative label retention mode though requires an LSR
being used. Conservative label retention mode though requires an LSR
to maintain many fewer labels. to maintain many fewer labels.
2.9. The Label Stack 2.9. The Label Stack
So far, we have spoken as if a labeled packet carries only a single 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 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 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". last-in, first-out stack. We refer to this as a "label stack".
IN MPLS, EVERY FORWARDING DECISION IS BASED EXCLUSIVELY ON THE LABEL IN MPLS, EVERY FORWARDING DECISION IS BASED EXCLUSIVELY ON THE LABEL
skipping to change at page 14, line 37 skipping to change at page 14, line 6
An unlabeled packet can be thought of as a packet whose label stack An unlabeled packet can be thought of as a packet whose label stack
is empty (i.e., whose label stack has depth 0). is empty (i.e., whose label stack has depth 0).
If a packet's label stack is of depth m, we refer to the label at the If a packet's label stack is of depth m, we refer to the label at the
bottom of the stack as the level 1 label, to the label above it (if bottom of the stack as the level 1 label, to the label above it (if
such exists) as the level 2 label, and to the label at the top of the such exists) as the level 2 label, and to the label at the top of the
stack as the level m label. stack as the level m label.
The utility of the label stack will become clear when we introduce The utility of the label stack will become clear when we introduce
the notion of LSP Tunnel and the MPLS Hierarchy (section 2.26). the notion of LSP Tunnel and the MPLS Hierarchy (section 2.27).
2.10. The Next Hop Label Forwarding Entry (NHLFE) 2.10. The Next Hop Label Forwarding Entry (NHLFE)
The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
a labeled packet. It contains the following information: a labeled packet. It contains the following information:
1. the packet's next hop 1. the packet's next hop
2. the data link encapsulation to use when transmitting the packet 2. the operation to perform on the packet's label stack; this is
3. the way to encode the label stack when transmitting the packet
4. the operation to perform on the packet's label stack; this is
one of the following operations: one of the following operations:
a) replace the label at the top of the label stack with a a) replace the label at the top of the label stack with a
specified new label specified new label
b) pop the label stack b) pop the label stack
c) replace the label at the top of the label stack with a c) replace the label at the top of the label stack with a
specified new label, and then push one or more specified specified new label, and then push one or more specified
new labels onto the label stack. new labels onto the label stack.
It may also contain:
d) the data link encapsulation to use when transmitting the packet
e) the way to encode the label stack when transmitting the packet
f) any other information needed in order to properly dispose of
the packet.
Note that at a given LSR, the packet's "next hop" might be that LSR Note that at a given LSR, the packet's "next hop" might be that LSR
itself. In this case, the LSR would need to pop the top level label, itself. In this case, the LSR would need to pop the top level label,
and then "forward" the resulting packet to itself. It would then and then "forward" the resulting packet to itself. It would then
make another forwarding decision, based on what remains after the make another forwarding decision, based on what remains after the
label stacked is popped. This may still be a labeled packet, or it label stacked is popped. This may still be a labeled packet, or it
may be the native IP packet. may be the native IP packet.
This implies that in some cases the LSR may need to operate on the IP This implies that in some cases the LSR may need to operate on the IP
header in order to forward the packet. header in order to forward the packet.
skipping to change at page 16, line 41 skipping to change at page 16, line 7
A given LSR Rd may bind label L1 to FEC F, and distribute that 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 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 distribute that binding to LDP peer Ru2. Whether or not L1 == L2 is
not determined by the architecture; this is a local matter. not determined by the architecture; this is a local matter.
A given LSR Rd may bind label L to FEC F1, and distribute that 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 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 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 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 LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN THE ARCHITECTURE DOES NOT
REQUIRE THAT F1 == F2. 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 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 particular label value L at the top of the label stack if the
following conditions hold: following conditions hold:
- Ru1 and Ru2 are the only LDP peers to which Rd distributed a - Ru1 and Ru2 are the only LDP peers to which Rd distributed a
binding of label value L, and binding of label value L, and
- Ru1 and Ru2 are each directly connected to Rd via a point-to- - Ru1 and Ru2 are each directly connected to Rd via a point-to-
point interface. point interface.
When these conditions hold, an LSR may use labels that have "per When these conditions hold, an LSR may use labels that have "per
interface" scope, i.e., which are only unique per interface. When interface" scope, i.e., which are only unique per interface. We may
these conditions do not hold, the labels must be unique over the LSR say that the LSR is using a "per-interface label space". When these
which has assigned them. conditions do not hold, the labels must be unique over the LSR which
has assigned them, and we may say that the LSR is using a "per-
platform label space."
If a particular LSR Rd is attached to a particular LSR Ru over two If a particular LSR Rd is attached to a particular LSR Ru over two
point-to-point interfaces, then Rd may distribute to Rd a binding of point-to-point interfaces, then Rd may distribute to Ru a binding of
label L to FEC F1, as well as a binding of label L to FEC F2, F1 != label L to FEC F1, as well as a binding of label L to FEC F2, F1 !=
F2, if and only if each binding is valid only for packets which Ru F2, if and only if each binding is valid only for packets which Ru
sends to Rd over a particular one of the interfaces. In all other sends to Rd over a particular one of the interfaces. In all other
cases, Rd MUST NOT distribute to Ru bindings of the same label value cases, Rd MUST NOT distribute to Ru bindings of the same label value
to two different FECs. to two different FECs.
This prohibition holds even if the bindings are regarded as being at This prohibition holds even if the bindings are regarded as being at
different "levels of hierarchy". In MPLS, there is no notion of different "levels of hierarchy". In MPLS, there is no notion of
having a different label space for different levels of the hierarchy; having a different label space for different levels of the hierarchy;
when interpreting a label, the level of the label is irrelevant. when interpreting a label, the level of the label is irrelevant.
The question arises as to whether it is possible for an LSR to use
multiple per-platform label spaces, or to use multiple per-interface
label spaces for the same interface. This is not prohibited by the
architecture. However, in such cases the LSR must have some means,
not specified by the architecture, of determining, for a particular
incoming label, which label space that label belongs to. For
example, [MPLS-SHIM] specifies that a different label space is used
for unicast packets than for multicast packets, and uses a data link
layer codepoint to distinguish the two label spaces.
2.15. Label Switched Path (LSP), LSP Ingress, LSP Egress 2.15. Label Switched Path (LSP), LSP Ingress, LSP Egress
A "Label Switched Path (LSP) of level m" for a particular packet P is A "Label Switched Path (LSP) of level m" for a particular packet P is
a sequence of routers, a sequence of routers,
<R1, ..., Rn> <R1, ..., Rn>
with the following properties: with the following properties:
1. R1, the "LSP Ingress", is an LSR which pushes a label onto P's 1. R1, the "LSP Ingress", is an LSR which pushes a label onto P's
skipping to change at page 21, line 18 skipping to change at page 20, line 37
particular incoming label, but has no binding for that label? It is particular incoming label, but has no binding for that label? It is
tempting to think that the labels can just be removed, and the packet tempting to think that the labels can just be removed, and the packet
forwarded as an unlabeled IP packet. However, in some cases, doing forwarded as an unlabeled IP packet. However, in some cases, doing
so could cause a loop. If the upstream LSR thinks the label is bound so could cause a loop. If the upstream LSR thinks the label is bound
to an explicit route, and the downstream LSR doesn't think the label to an explicit route, and the downstream LSR doesn't think the label
is bound to anything, and if the hop by hop routing of the unlabeled is bound to anything, and if the hop by hop routing of the unlabeled
IP packet brings the packet back to the upstream LSR, then a loop is IP packet brings the packet back to the upstream LSR, then a loop is
formed. formed.
It is also possible that the label was intended to represent a route It is also possible that the label was intended to represent a route
which the cannot be inferred the IP header. which cannot be inferred from the IP header.
Therefore, when a labeled packet is received with an invalid incoming Therefore, when a labeled packet is received with an invalid incoming
label, it MUST be discarded, UNLESS it is determined by some means label, it MUST be discarded, UNLESS it is determined by some means
(not within the scope of the current document) that forwarding it (not within the scope of the current document) that forwarding it
unlabeled cannot cause any harm. unlabeled cannot cause any harm.
2.19. LSP Control: Ordered versus Independent 2.19. LSP Control: Ordered versus Independent
Some FECs correspond to address prefixes which are distributed via a Some FECs correspond to address prefixes which are distributed via a
dynamic routing algorithm. The setup of the LSPs for these FECs can dynamic routing algorithm. The setup of the LSPs for these FECs can
skipping to change at page 24, line 30 skipping to change at page 24, line 8
single LSR specifies the entire LSP, the LSP is "strictly" explicitly single LSR specifies the entire LSP, the LSP is "strictly" explicitly
routed. If a single LSR specifies only some of the LSP, the LSP is routed. If a single LSR specifies only some of the LSP, the LSP is
"loosely" explicitly routed. "loosely" explicitly routed.
The sequence of LSRs followed by an explicitly routed LSP may be The sequence of LSRs followed by an explicitly routed LSP may be
chosen by configuration, or may be selected dynamically by a single chosen by configuration, or may be selected dynamically by a single
node (for example, the egress node may make use of the topological node (for example, the egress node may make use of the topological
information learned from a link state database in order to compute information learned from a link state database in order to compute
the entire path for the tree ending at that egress node). the entire path for the tree ending at that egress node).
Explicit routing may be useful for a number of purposes such as Explicit routing may be useful for a number of purposes, such as
policy routing or traffic engineering. With MPLS the explicit route policy routing or traffic engineering. In MPLS, the explicit route
needs to be specified at the time that labels are assigned, but the needs to be specified at the time that labels are assigned, but the
explicit route does not have to be specified with each IP packet. explicit route does not have to be specified with each IP packet.
This makes MPLS explicit routing much more efficient than the This makes MPLS explicit routing much more efficient than the
alternative of IP source routing. alternative of IP source routing.
When an LSP is explicitly routed (either loosely or strictly), it is 2.22. Lack of Outgoing Label
essential that packets travelling along the LSP reach its end before
they revert to hop by hop routing. Otherwise inconsistent routing
and loops might form.
It is not necessary for a node to be able to create an explicit When a labeled packet is traveling along an LSP, it may occasionally
route. However, in order to ensure interoperability it is necessary happen that it reaches an LSR at which the ILM does not map the
to ensure that either (i) Every node knows how to use hop by hop packet's incoming label into an NHLFE, even though the incoming label
routing; or (ii) Every node knows how to create and follow an is itself valid. This can happen due to transient conditions, or due
explicit route. We propose that due to the common use of hop by hop to an error at the LSR which should be the packet's next hop.
routing in networks today, it is reasonable to make hop by hop
routing the default that all nodes need to be able to use.
2.22. Time-to-Live (TTL) It is tempting in such cases to strip off the label stack and attempt
to forward the packet further via conventional forwarding, based on
its network layer header. However, in general this is not a safe
procedure:
- If the packet has been following an explicitly routed LSP, this
could result in a loop.
- The packet's network header may not contain enough information to
enable this particular LSR to forward it correctly.
Unless it can be determined (through some means outside the scope of
this document) that neither of these situations obtains, the only
safe procedure is to discard the packet.
2.23. Time-to-Live (TTL)
In conventional IP forwarding, each packet carries a "Time To Live" In conventional IP forwarding, each packet carries a "Time To Live"
(TTL) value in its header. Whenever a packet passes through a (TTL) value in its header. Whenever a packet passes through a
router, its TTL gets decremented by 1; if the TTL reaches 0 before router, its TTL gets decremented by 1; if the TTL reaches 0 before
the packet has reached its destination, the packet gets discarded. the packet has reached its destination, the packet gets discarded.
This provides some level of protection against forwarding loops that This provides some level of protection against forwarding loops that
may exist due to misconfigurations, or due to failure or slow may exist due to misconfigurations, or due to failure or slow
convergence of the routing algorithm. TTL is sometimes used for other convergence of the routing algorithm. TTL is sometimes used for other
functions as well, such as multicast scoping, and supporting the functions as well, such as multicast scoping, and supporting the
skipping to change at page 25, line 29 skipping to change at page 25, line 16
limiting the scope of a packet. limiting the scope of a packet.
When a packet travels along an LSP, it SHOULD emerge with the same When a packet travels along an LSP, it SHOULD emerge with the same
TTL value that it would have had if it had traversed the same TTL value that it would have had if it had traversed the same
sequence of routers without having been label switched. If the sequence of routers without having been label switched. If the
packet travels along a hierarchy of LSPs, the total number of LSR- packet travels along a hierarchy of LSPs, the total number of LSR-
hops traversed SHOULD be reflected in its TTL value when it emerges hops traversed SHOULD be reflected in its TTL value when it emerges
from the hierarchy of LSPs. from the hierarchy of LSPs.
The way that TTL is handled may vary depending upon whether the MPLS The way that TTL is handled may vary depending upon whether the MPLS
label values are carried in an MPLS-specific "shim" header, or if the label values are carried in an MPLS-specific "shim" header [MPLS-
MPLS labels are carried in an L2 header, such as an ATM header or a SHIM], or if the MPLS labels are carried in an L2 header, such as an
frame relay header. ATM header [MPLS-ATM] or a frame relay header [MPLS-FRMRLY].
If the label values are encoded in a "shim" that sits between the If the label values are encoded in a "shim" that sits between the
data link and network layer headers, then this shim MUST have a TTL data link and network layer headers, then this shim MUST have a TTL
field that SHOULD be initially loaded from the network layer header field that SHOULD be initially loaded from the network layer header
TTL field, SHOULD be decremented at each LSR-hop, and SHOULD be TTL field, SHOULD be decremented at each LSR-hop, and SHOULD be
copied into the network layer header TTL field when the packet copied into the network layer header TTL field when the packet
emerges from its LSP. emerges from its LSP.
If the label values are encoded in a data link layer header (e.g., If the label values are encoded in a data link layer header (e.g.,
the VPI/VCI field in ATM's AAL5 header), and the labeled packets are the VPI/VCI field in ATM's AAL5 header), and the labeled packets are
skipping to change at page 26, line 13 skipping to change at page 26, line 5
TTL value before forwarding packets into a non-TTL LSP segment. TTL value before forwarding packets into a non-TTL LSP segment.
Sometimes it can be determined, upon ingress to a non-TTL LSP Sometimes it can be determined, upon ingress to a non-TTL LSP
segment, that a particular packet's TTL will expire before the packet segment, that a particular packet's TTL will expire before the packet
reaches the egress of that non-TTL LSP segment. In this case, the LSR reaches the egress of that non-TTL LSP segment. In this case, the LSR
at the ingress to the non-TTL LSP segment must not label switch the at the ingress to the non-TTL LSP segment must not label switch the
packet. This means that special procedures must be developed to packet. This means that special procedures must be developed to
support traceroute functionality, for example, traceroute packets may support traceroute functionality, for example, traceroute packets may
be forwarded using conventional hop by hop forwarding. be forwarded using conventional hop by hop forwarding.
2.23. Loop Control 2.24. Loop Control
On a non-TTL LSP segment, by definition, TTL cannot be used to On a non-TTL LSP segment, by definition, TTL cannot be used to
protect against forwarding loops. The importance of loop control may protect against forwarding loops. The importance of loop control may
depend on the particular hardware being used to provide the LSR depend on the particular hardware being used to provide the LSR
functions along the non-TTL LSP segment. functions along the non-TTL LSP segment.
Suppose, for instance, that ATM switching hardware is being used to Suppose, for instance, that ATM switching hardware is being used to
provide MPLS switching functions, with the label being carried in the provide MPLS switching functions, with the label being carried in the
VPI/VCI field. Since ATM switching hardware cannot decrement TTL, VPI/VCI field. Since ATM switching hardware cannot decrement TTL,
there is no protection against loops. If the ATM hardware is capable there is no protection against loops. If the ATM hardware is capable
of providing fair access to the buffer pool for incoming cells of providing fair access to the buffer pool for incoming cells
carrying different VPI/VCI values, this looping may not have any carrying different VPI/VCI values, this looping may not have any
deleterious effect on other traffic. If the ATM hardware cannot deleterious effect on other traffic. If the ATM hardware cannot
provide fair buffer access of this sort, however, then even transient provide fair buffer access of this sort, however, then even transient
loops may cause severe degradation of the LSR's total performance. loops may cause severe degradation of the LSR's total performance.
Even if fair buffer access can be provided, it is still worthwhile to Even if fair buffer access can be provided, it is still worthwhile to
have some means of detecting loops that last "longer than possible". have some means of detecting loops that last "longer than possible".
In addition, even where TTL and/or per-VC fair queuing provides a In addition, even where TTL and/or per-VC fair queuing provides a
means for surviving loops, it still may be desirable where practical means for surviving loops, it still may be desirable where practical
to avoid setting up LSPs which loop. to avoid setting up LSPs which loop. All LSRs that may attach to
non-TTL LSP segments will therefore be required to support a common
The MPLS architecture will therefore provide a technique for ensuring technique for loop detection; however, use of the loop detection
that looping LSP segments can be detected, and a technique for technique is optional. The loop detection technique is specified in
ensuring that looping LSP segments are never created. [MPLS-ATM] and [MPLS-LDP].
All LSRs will be required to support a common technique for loop
detection. Support for the loop prevention technique is optional,
though it is recommended in ATM-LSRs that have no other way to
protect themselves against the effects of looping data packets. Use
of the loop prevention technique, when supported, is optional.
The loop prevention technique presupposes the use of Ordered LSP
Control. The loop detection technique, on the other hand, works with
either Independent or Ordered LSP Control.
2.23.1. Loop Prevention
NOTE: The loop prevention technique described here is being
reconsidered, and may be changed.
LSR's maintain for each of their LSP's an LSR id list. This list is a
list of all the LSR's downstream from this LSR on a given LSP. The
LSR id list is used to prevent the formation of switched path loops.
The LSR ID list is propagated upstream from a node to its neighbor
nodes. The LSR ID list is used to prevent loops as follows:
When a node, R, detects a change in the next hop for a given FEC, it
asks its new next hop for a label and the associated LSR ID list for
that FEC.
The new next hop responds with a label for the FEC and an associated
LSR id list.
R looks in the LSR id list. If R determines that it, R, is in the
list then we have a route loop. In this case, we do nothing and the
old LSP will continue to be used until the route protocols break the
loop. The means by which the old LSP is replaced by a new LSP after
the route protocols breathe loop is described below.
If R is not in the LSR id list, R will start a "diffusion"
computation [12]. The purpose of the diffusion computation is to
prune the tree upstream of R so that we remove all LSR's from the
tree that would be on a looping path if R were to switch over to the
new LSP. After those LSR's are removed from the tree, it is safe for
R to replace the old LSP with the new LSP (and the old LSP can be
released).
The diffusion computation works as follows:
R adds its LSR id to the list and sends a query message to each of
its "upstream" neighbors (i.e. to each of its neighbors that is not
the new "downstream" next hop).
A node S that receives such a query will process the query as
follows:
- If node R is not node S's next hop for the given FEC, node S will
respond to node R will an "OK" message meaning that as far as
node S is concerned it is safe for node R to switch over to the
new LSP.
- If node R is node S's next hop for the FEC, node S will check to
see if it, node S, is in the LSR id list that it received from
node R. If it is, we have a route loop and S will respond with a
"LOOP" message. R will unsplice the connection to S pruning S
from the tree. The mechanism by which S will get a new LSP for
the FEC after the route protocols break the loop is described
below.
- If node S is not in the LSR id list, S will add its LSR id to the
LSR id list and send a new query message further upstream. The
diffusion computation will continue to propagate upstream along
each of the paths in the tree upstream of S until either a loop
is detected, in which case the node is pruned as described above
or we get to a point where a node gets a response ("OK" or
"LOOP") from each of its neighbors perhaps because none of those
neighbors considers the node in question to be its downstream
next hop. Once a node has received a response from each of its
upstream neighbors, it returns an "OK" message to its downstream
neighbor. When the original node, node R, gets a response from
each of its neighbors, it is safe to replace the old LSP with the
new one because all the paths that would loop have been pruned
from the tree.
There are a couple of details to discuss:
- First, we need to do something about nodes that for one reason or
another do not produce a timely response in response to a query
message. If a node Y does not respond to a query from node X
because of a failure of some kind, X will not be able to respond
to its downstream neighbors (if any) or switch over to a new LSP
if X is, like R above, the node that has detected the route
change. This problem is handled by timing out the query message.
If a node doesn't receive a response within a "reasonable" period
of time, it "unsplices" its VC to the upstream neighbor that is
not responding and proceeds as it would if it had received the
"LOOP" message.
- We also need to be concerned about multiple concurrent routing
updates. What happens, for example, when a node M receives a
request for an LSP from an upstream neighbor, N, when M is in the
middle of a diffusion computation i.e., it has sent a query
upstream but hasn't received all the responses. Since a
downstream node, node R is about to change from one LSP to
another, M needs to pass to N an LSR id list corresponding to the
union of the old and new LSP's if it is to avoid loops both
before and after the transition. This is easily accomplished
since M already has the LSR id list for the old LSP and it gets
the LSR id list for the new LSP in the query message. After R
makes the switch from the old LSP to the new one, R sends a new
establish message upstream with the LSR id list of (just) the new
LSP. At this point, the nodes upstream of R know that R has
switched over to the new LSP and that they can return the id list
for (just) the new LSP in response to any new requests for LSP's.
They can also grow the tree to include additional nodes that
would not have been valid for the combined LSR id list.
- We also need to discuss how a node that doesn't have an LSP for a
given stream at the end of a diffusion computation (because it
would have been on a looping LSP) gets one after the routing
protocols break the loop. If node L has been pruned from the
tree and its local route protocol processing entity breaks the
loop by changing L's next hop, L will request a new LSP from its
new downstream neighbor which it will use once it executes the
diffusion computation as described above. If the loop is broken
by a route change at another point in the loop, i.e. at a point
"downstream" of L, L will get a new LSP as the new LSP tree grows
upstream from the point of the route change as discussed in the
previous paragraph.
- Note that when a node is pruned from the tree, the switched path
upstream of that node remains "connected". This is important
since it allows the switched path to get "reconnected" to a
downstream switched path after a route change with a minimal
amount of unsplicing and resplicing once the appropriate
diffusion computation(s) have taken place.
The LSR Id list can also be used to provide a "loop detection"
capability. To use it in this manner, an LSR which sees that it is
already in the LSR Id list for a particular FEC will immediately
unsplice itself from the switched path for that FEC, and will NOT
pass the LSR Id list further upstream. The LSR can rejoin a switched
path for the FEC when it changes its next hop for that FEC, or when
it receives a new LSR Id list from its current next hop, in which it
is not contained. The diffusion computation would be omitted.
2.23.2. Interworking of Loop Control Options
The MPLS protocol architecture allows some nodes to be using loop
prevention, while some other nodes are not (i.e., the choice of
whether or not to use loop prevention may be a local decision). When
this mix is used, it is not possible for a loop to form which
includes only nodes which do loop prevention. However, it is possible
for loops to form which contain a combination of some nodes which do
loop prevention, and some nodes which do not.
There are at least four identified cases in which it makes sense to
combine nodes which do loop prevention with nodes which do not: (i)
For transition, in intermediate states while transitioning from all
non-loop-prevention to all loop prevention, or vice versa; (ii) For
interoperability, where one vendor implements loop prevention but
another vendor does not; (iii) Where there is a mixed ATM and
datagram media network, and where loop prevention is desired over the
ATM portions of the network but not over the datagram portions; (iv)
where some of the ATM switches can do fair access to the buffer pool
on a per-VC basis, and some cannot, and loop prevention is desired
over the ATM portions of the network which cannot.
Note that interworking is straightforward. If an LSR is not doing
loop prevention, and it receives from a downstream LSR a label
binding which contains loop prevention information, it (a) accepts
the label binding, (b) does NOT pass the loop prevention information
upstream, and (c) informs the downstream neighbor that the path is
loop-free.
Similarly, if an LSR R which is doing loop prevention receives from a
downstream LSR a label binding which does not contain any loop
prevention information, then R passes the label binding upstream with
loop prevention information included as if R were the egress for the
specified FEC.
Optionally, a node is permitted to implement the ability of either
doing or not doing loop prevention as options, and is permitted to
choose which to use for any one particular LSP based on the
information obtained from downstream nodes. When the label binding
arrives from downstream, then the node may choose whether to use loop
prevention so as to continue to use the same approach as was used in
the information passed to it. Note that regardless of whether loop
prevention is used the egress nodes (for any particular LSP) always
initiates exchange of label binding information without waiting for
other nodes to act.
2.24. Label Encodings 2.25. Label Encodings
In order to transmit a label stack along with the packet whose label In order to transmit a label stack along with the packet whose label
stack it is, it is necessary to define a concrete encoding of the stack it is, it is necessary to define a concrete encoding of the
label stack. The architecture supports several different encoding label stack. The architecture supports several different encoding
techniques; the choice of encoding technique depends on the techniques; the choice of encoding technique depends on the
particular kind of device being used to forward labeled packets. particular kind of device being used to forward labeled packets.
2.24.1. MPLS-specific Hardware and/or Software 2.25.1. MPLS-specific Hardware and/or Software
If one is using MPLS-specific hardware and/or software to forward If one is using MPLS-specific hardware and/or software to forward
labeled packets, the most obvious way to encode the label stack is to labeled packets, the most obvious way to encode the label stack is to
define a new protocol to be used as a "shim" between the data link define a new protocol to be used as a "shim" between the data link
layer and network layer headers. This shim would really be just an layer and network layer headers. This shim would really be just an
encapsulation of the network layer packet; it would be "protocol- encapsulation of the network layer packet; it would be "protocol-
independent" such that it could be used to encapsulate any network independent" such that it could be used to encapsulate any network
layer. Hence we will refer to it as the "generic MPLS layer. Hence we will refer to it as the "generic MPLS
encapsulation". encapsulation".
The generic MPLS encapsulation would in turn be encapsulated in a The generic MPLS encapsulation would in turn be encapsulated in a
data link layer protocol. data link layer protocol.
The generic MPLS encapsulation should contain the following fields: The MPLS generic encapsulation is specified in [MPLS-SHIM].
1. the label stack,
2. a Time-to-Live (TTL) field
3. a Class of Service (CoS) field
The TTL field permits MPLS to provide a TTL function similar to what
is provided by IP.
The CoS field permits LSRs to apply various scheduling packet
disciplines to labeled packets, without requiring separate labels for
separate disciplines.
2.24.2. ATM Switches as LSRs 2.25.2. ATM Switches as LSRs
It will be noted that MPLS forwarding procedures are similar to those It will be noted that MPLS forwarding procedures are similar to those
of legacy "label swapping" switches such as ATM switches. ATM of legacy "label swapping" switches such as ATM switches. ATM
switches use the input port and the incoming VPI/VCI value as the switches use the input port and the incoming VPI/VCI value as the
index into a "cross-connect" table, from which they obtain an output index into a "cross-connect" table, from which they obtain an output
port and an outgoing VPI/VCI value. Therefore if one or more labels port and an outgoing VPI/VCI value. Therefore if one or more labels
can be encoded directly into the fields which are accessed by these can be encoded directly into the fields which are accessed by these
legacy switches, then the legacy switches can, with suitable software legacy switches, then the legacy switches can, with suitable software
upgrades, be used as LSRs. We will refer to such devices as "ATM- upgrades, be used as LSRs. We will refer to such devices as "ATM-
LSRs". LSRs".
skipping to change at page 32, line 40 skipping to change at page 28, line 14
3. SVP Multipoint Encoding 3. SVP Multipoint Encoding
Use the VPI field to encode the label which is at the top of Use the VPI field to encode the label which is at the top of
the label stack, use part of the VCI field to encode the second the label stack, use part of the VCI field to encode the second
label on the stack, if one is present, and use the remainder of label on the stack, if one is present, and use the remainder of
the VCI field to identify the LSP ingress. If this technique the VCI field to identify the LSP ingress. If this technique
is used, conventional ATM VP-switching capabilities can be used is used, conventional ATM VP-switching capabilities can be used
to provide multipoint-to-point VPs. Cells from different to provide multipoint-to-point VPs. Cells from different
packets will then carry different VCI values. As we shall see packets will then carry different VCI values. As we shall see
in section 2.25, this enables us to do label merging, without in section 2.26, this enables us to do label merging, without
running into any cell interleaving problems, on ATM switches running into any cell interleaving problems, on ATM switches
which can provide multipoint-to-point VPs, but which do not which can provide multipoint-to-point VPs, but which do not
have the VC merge capability. have the VC merge capability.
This technique depends on the existence of a capability for This technique depends on the existence of a capability for
assigning small unique values to each ATM switch. assigning 16-bit VCI values to each ATM switch such that no
single VCI value is assigned to two different switches. (If an
adequate number of such values could be assigned to each
switch, it would be possible to also treat the VCI value as the
second label in the stack.)
If there are more labels on the stack than can be encoded in the ATM If there are more labels on the stack than can be encoded in the ATM
header, the ATM encodings must be combined with the generic header, the ATM encodings must be combined with the generic
encapsulation. encapsulation.
2.24.3. Interoperability among Encoding Techniques 2.25.3. Interoperability among Encoding Techniques
If <R1, R2, R3> is a segment of a LSP, it is possible that R1 will If <R1, R2, R3> is a segment of a LSP, it is possible that R1 will
use one encoding of the label stack when transmitting packet P to R2, use one encoding of the label stack when transmitting packet P to R2,
but R2 will use a different encoding when transmitting a packet P to but R2 will use a different encoding when transmitting a packet P to
R3. In general, the MPLS architecture supports LSPs with different R3. In general, the MPLS architecture supports LSPs with different
label stack encodings used on different hops. Therefore, when we label stack encodings used on different hops. Therefore, when we
discuss the procedures for processing a labeled packet, we speak in discuss the procedures for processing a labeled packet, we speak in
abstract terms of operating on the packet's label stack. When a abstract terms of operating on the packet's label stack. When a
labeled packet is received, the LSR must decode it to determine the labeled packet is received, the LSR must decode it to determine the
current value of the label stack, then must operate on the label current value of the label stack, then must operate on the label
skipping to change at page 33, line 35 skipping to change at page 29, line 12
Naturally there will be MPLS networks which contain a combination of Naturally there will be MPLS networks which contain a combination of
ATM switches operating as LSRs, and other LSRs which operate using an ATM switches operating as LSRs, and other LSRs which operate using an
MPLS shim header. In such networks there may be some LSRs which have MPLS shim header. In such networks there may be some LSRs which have
ATM interfaces as well as "MPLS Shim" interfaces. This is one example ATM interfaces as well as "MPLS Shim" interfaces. This is one example
of an LSR with different label stack encodings on different hops. of an LSR with different label stack encodings on different hops.
Such an LSR may swap off an ATM encoded label stack on an incoming Such an LSR may swap off an ATM encoded label stack on an incoming
interface and replace it with an MPLS shim header encoded label stack interface and replace it with an MPLS shim header encoded label stack
on the outgoing interface. on the outgoing interface.
2.25. Label Merging 2.26. Label Merging
Suppose that an LSR has bound multiple incoming labels to a Suppose that an LSR has bound multiple incoming labels to a
particular FEC. When forwarding packets in that FEC, one would like particular FEC. When forwarding packets in that FEC, one would like
to have a single outgoing label which is applied to all such packets. to have a single outgoing label which is applied to all such packets.
The fact that two different packets in the FEC arrived with different The fact that two different packets in the FEC arrived with different
incoming labels is irrelevant; one would like to forward them with incoming labels is irrelevant; one would like to forward them with
the same outgoing label. The capability to do so is known as "label the same outgoing label. The capability to do so is known as "label
merging". merging".
Let us say that an LSR is capable of label merging if it can receive Let us say that an LSR is capable of label merging if it can receive
two packets from different incoming interfaces, and/or with different two packets from different incoming interfaces, and/or with different
labels, and send both packets out the same outgoing interface with labels, and send both packets out the same outgoing interface with
the same label. Once the packets are transmitted, the information the same label. Once the packets are transmitted, the information
that they arrived from different interfaces and/or with different that they arrived from different interfaces and/or with different
incoming labels is lost. incoming labels is lost.
Let us say that an LSR is not capable of label merging if, for any Let us say that an LSR is not capable of label merging if, for any
two packets which arrive from different interfaces, or with different two packets which arrive from different interfaces, or with different
labels, the packets must either be transmitted out different labels, the packets must either be transmitted out different
interfaces, or must have different labels. interfaces, or must have different labels. ATM-LSRs using the SVC or
SVP Encodings cannot perform label merging. This is discussed in
Label merging would be a requirement of the MPLS architecture, if not more detail in the next section.
for the fact that ATM-LSRs using the SVC or SVP Encodings cannot
perform label merging. This is discussed in more detail in the next
section.
If a particular LSR cannot perform label merging, then if two packets If a particular LSR cannot perform label merging, then if two packets
in the same FEC arrive with different incoming labels, they must be in the same FEC arrive with different incoming labels, they must be
forwarded with different outgoing labels. With label merging, the forwarded with different outgoing labels. With label merging, the
number of outgoing labels per FEC need only be 1; without label 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 merging, the number of outgoing labels per FEC could be as large as
the number of nodes in the network. the number of nodes in the network.
With label merging, the number of incoming labels per FEC that a With label merging, the number of incoming labels per FEC that a
particular LSR needs is never be larger than the number of LDP particular LSR needs is never be larger than the number of LDP
skipping to change at page 34, line 38 skipping to change at page 30, line 13
many such incoming labels it must support for a particular FEC. many such incoming labels it must support for a particular FEC.
The MPLS architecture accommodates both merging and non-merging LSRs, The MPLS architecture accommodates both merging and non-merging LSRs,
but allows for the fact that there may be LSRs which do not support but allows for the fact that there may be LSRs which do not support
label merging. This leads to the issue of ensuring correct label merging. This leads to the issue of ensuring correct
interoperation between merging LSRs and non-merging LSRs. The issue interoperation between merging LSRs and non-merging LSRs. The issue
is somewhat different in the case of datagram media versus the case is somewhat different in the case of datagram media versus the case
of ATM. The different media types will therefore be discussed of ATM. The different media types will therefore be discussed
separately. separately.
2.25.1. Non-merging LSRs 2.26.1. Non-merging LSRs
The MPLS forwarding procedures is very similar to the forwarding The MPLS forwarding procedures is very similar to the forwarding
procedures used by such technologies as ATM and Frame Relay. That is, 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 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 "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 chosen, and the label value is rewritten. In fact, it is possible to
use such technologies for MPLS forwarding; LDP can be used as the use such technologies for MPLS forwarding; an LDP can be used as the
"signalling protocol" for setting up the cross-connect tables. "signalling protocol" for setting up the cross-connect tables.
Unfortunately, these technologies do not necessarily support the Unfortunately, these technologies do not necessarily support the
label merging capability. In ATM, if one attempts to perform label label merging capability. In ATM, if one attempts to perform label
merging, the result may be the interleaving of cells from various merging, the result may be the interleaving of cells from various
packets. If cells from different packets get interleaved, it is packets. If cells from different packets get interleaved, it is
impossible to reassemble the packets. Some Frame Relay switches use impossible to reassemble the packets. Some Frame Relay switches use
cell switching on their backplanes. These switches may also be cell switching on their backplanes. These switches may also be
incapable of supporting label merging, for the same reason -- cells incapable of supporting label merging, for the same reason -- cells
of different packets may get interleaved, and there is then no way to of different packets may get interleaved, and there is then no way to
reassemble the packets. reassemble the packets.
We propose to support two solutions to this problem. First, MPLS will We propose to support two solutions to this problem. First, MPLS will
contain procedures which allow the use of non-merging LSRs. Second, contain procedures which allow the use of non-merging LSRs. Second,
MPLS will support procedures which allow certain ATM switches to MPLS will support procedures which allow certain ATM switches to
function as merging LSRs. function as merging LSRs.
Since MPLS supports both merging and non-merging LSRs, MPLS also Since MPLS supports both merging and non-merging LSRs, MPLS also
contains procedures to ensure correct interoperation between them. contains procedures to ensure correct interoperation between them.
2.25.2. Labels for Merging and Non-Merging LSRs 2.26.2. Labels for Merging and Non-Merging LSRs
An upstream LSR which supports label merging needs to be sent only An upstream LSR which supports label merging needs to be sent only
one label per FEC. An upstream neighbor which does not support label one label per FEC. An upstream neighbor which does not support label
merging needs to be sent multiple labels per FEC. However, there is merging needs to be sent multiple labels per FEC. However, there is
no way of knowing a priori how many labels it needs. This will depend no way of knowing a priori how many labels it needs. This will depend
on how many LSRs are upstream of it with respect to the FEC in on how many LSRs are upstream of it with respect to the FEC in
question. question.
In the MPLS architecture, if a particular upstream neighbor does not In the MPLS architecture, if a particular upstream neighbor does not
support label merging, it is not sent any labels for a particular FEC support label merging, it is not sent any labels for a particular FEC
skipping to change at page 36, line 5 skipping to change at page 31, line 23
merging, but can only merge a limited number of incoming labels into merging, but can only merge a limited number of incoming labels into
a single outgoing label. Suppose for example that due to some a single outgoing label. Suppose for example that due to some
hardware limitation a node is capable of merging four incoming labels hardware limitation a node is capable of merging four incoming labels
into a single outgoing label. Suppose however, that this particular into a single outgoing label. Suppose however, that this particular
node has six incoming labels arriving at it for a particular FEC. In node has six incoming labels arriving at it for a particular FEC. In
this case, this node may merge these into two outgoing labels. this case, this node may merge these into two outgoing labels.
Whether label merging is applicable to explicitly routed LSPs is for Whether label merging is applicable to explicitly routed LSPs is for
further study. further study.
2.25.3. Merge over ATM 2.26.3. Merge over ATM
2.25.3.1. Methods of Eliminating Cell Interleave 2.26.3.1. Methods of Eliminating Cell Interleave
There are several methods that can be used to eliminate the cell There are several methods that can be used to eliminate the cell
interleaving problem in ATM, thereby allowing ATM switches to support interleaving problem in ATM, thereby allowing ATM switches to support
stream merge: : stream merge:
1. VP merge, using the SVP Multipoint Encoding 1. VP merge, using the SVP Multipoint Encoding
When VP merge is used, multiple virtual paths are merged into a When VP merge is used, multiple virtual paths are merged into a
virtual path, but packets from different sources are virtual path, but packets from different sources are
distinguished by using different VCs within the VP. distinguished by using different VCIs within the VP.
2. VC merge 2. VC merge
When VC merge is used, switches are required to buffer cells When VC merge is used, switches are required to buffer cells
from one packet until the entire packet is received (this may from one packet until the entire packet is received (this may
be determined by looking for the AAL5 end of frame indicator). be determined by looking for the AAL5 end of frame indicator).
VP merge has the advantage that it is compatible with a higher VP merge has the advantage that it is compatible with a higher
percentage of existing ATM switch implementations. This makes it more percentage of existing ATM switch implementations. This makes it more
likely that VP merge can be used in existing networks. Unlike VC likely that VP merge can be used in existing networks. Unlike VC
skipping to change at page 36, line 40 skipping to change at page 32, line 11
disadvantage that it requires coordination of the VCI space within disadvantage that it requires coordination of the VCI space within
each VP. There are a number of ways that this can be accomplished. each VP. There are a number of ways that this can be accomplished.
Selection of one or more methods is for further study. Selection of one or more methods is for further study.
This tradeoff between compatibility with existing equipment versus This tradeoff between compatibility with existing equipment versus
protocol complexity and scalability implies that it is desirable for protocol complexity and scalability implies that it is desirable for
the MPLS protocol to support both VP merge and VC merge. In order to the MPLS protocol to support both VP merge and VC merge. In order to
do so each ATM switch participating in MPLS needs to know whether its do so each ATM switch participating in MPLS needs to know whether its
immediate ATM neighbors perform VP merge, VC merge, or no merge. immediate ATM neighbors perform VP merge, VC merge, or no merge.
2.25.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge 2.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge
The interoperation of the various forms of merging over ATM is most The interoperation of the various forms of merging over ATM is most
easily described by first describing the interoperation of VC merge easily described by first describing the interoperation of VC merge
with non-merge. with non-merge.
In the case where VC merge and non-merge nodes are interconnected the In the case where VC merge and non-merge nodes are interconnected the
forwarding of cells is based in all cases on a VC (i.e., the forwarding of cells is based in all cases on a VC (i.e., the
concatenation of the VPI and VCI). For each node, if an upstream concatenation of the VPI and VCI). For each node, if an upstream
neighbor is doing VC merge then that upstream neighbor requires only neighbor is doing VC merge then that upstream neighbor requires only
a single VPI/VCI for a particular stream (this is analogous to the a single VPI/VCI for a particular stream (this is analogous to the
skipping to change at page 37, line 35 skipping to change at page 33, line 6
of VCs (identified by a set of VCIs which are significant within a of VCs (identified by a set of VCIs which are significant within a
VP). VP merge nodes would therefore request one VP, with a contained VP). VP merge nodes would therefore request one VP, with a contained
VCI for traffic that it originates (if appropriate) plus a VCI for VCI for traffic that it originates (if appropriate) plus a VCI for
each VC requested from above (regardless of whether or not the VC is each VC requested from above (regardless of whether or not the VC is
part of a containing VP). VC merge node would request only a single part of a containing VP). VC merge node would request only a single
VPI/VCI (since they can merge all upstream traffic into a single VC). VPI/VCI (since they can merge all upstream traffic into a single VC).
Non-merge nodes would pass on any requests that they get from above, Non-merge nodes would pass on any requests that they get from above,
plus request a VPI/VCI for traffic that they originate (if plus request a VPI/VCI for traffic that they originate (if
appropriate). appropriate).
2.26. Tunnels and Hierarchy 2.27. Tunnels and Hierarchy
Sometimes a router Ru takes explicit action to cause a particular Sometimes a router Ru takes explicit action to cause a particular
packet to be delivered to another router Rd, even though Ru and Rd packet to be delivered to another router Rd, even though Ru and Rd
are not consecutive routers on the Hop-by-hop path for that packet, are not consecutive routers on the Hop-by-hop path for that packet,
and Rd is not the packet's ultimate destination. For example, this and Rd is not the packet's ultimate destination. For example, this
may be done by encapsulating the packet inside a network layer packet may be done by encapsulating the packet inside a network layer packet
whose destination address is the address of Rd itself. This creates a whose destination address is the address of Rd itself. This creates a
"tunnel" from Ru to Rd. We refer to any packet so handled as a "tunnel" from Ru to Rd. We refer to any packet so handled as a
"Tunneled Packet". "Tunneled Packet".
2.26.1. Hop-by-Hop Routed Tunnel 2.27.1. Hop-by-Hop Routed Tunnel
If a Tunneled Packet follows the Hop-by-hop path from Ru to Rd, we If a Tunneled Packet follows the Hop-by-hop path from Ru to Rd, we
say that it is in an "Hop-by-Hop Routed Tunnel" whose "transmit say that it is in an "Hop-by-Hop Routed Tunnel" whose "transmit
endpoint" is Ru and whose "receive endpoint" is Rd. endpoint" is Ru and whose "receive endpoint" is Rd.
2.26.2. Explicitly Routed Tunnel 2.27.2. Explicitly Routed Tunnel
If a Tunneled Packet travels from Ru to Rd over a path other than the If a Tunneled Packet travels from Ru to Rd over a path other than the
Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel" Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel"
whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd. whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd.
For example, we might send a packet through an Explicitly Routed For example, we might send a packet through an Explicitly Routed
Tunnel by encapsulating it in a packet which is source routed. Tunnel by encapsulating it in a packet which is source routed.
2.26.3. LSP Tunnels 2.27.3. LSP Tunnels
It is possible to implement a tunnel as a LSP, and use label It is possible to implement a tunnel as a LSP, and use label
switching rather than network layer encapsulation to cause the packet switching rather than network layer encapsulation to cause the packet
to travel through the tunnel. The tunnel would be a LSP <R1, ..., to travel through the tunnel. The tunnel would be a LSP <R1, ...,
Rn>, where R1 is the transmit endpoint of the tunnel, and Rn is the Rn>, where R1 is the transmit endpoint of the tunnel, and Rn is the
receive endpoint of the tunnel. This is called a "LSP Tunnel". receive endpoint of the tunnel. This is called a "LSP Tunnel".
The set of packets which are to be sent though the LSP tunnel The set of packets which are to be sent though the LSP tunnel
constitutes a FEC, and each LSR in the tunnel must assign a label to constitutes a FEC, and each LSR in the tunnel must assign a label to
that FEC (i.e., must assign a label to the tunnel). The criteria for that FEC (i.e., must assign a label to the tunnel). The criteria for
skipping to change at page 39, line 5 skipping to change at page 34, line 17
discussed earlier, the label stack may be popped at the penultimate discussed earlier, the label stack may be popped at the penultimate
LSR in the tunnel. LSR in the tunnel.
A "Hop-by-Hop Routed LSP Tunnel" is a Tunnel that is implemented as A "Hop-by-Hop Routed LSP Tunnel" is a Tunnel that is implemented as
an hop-by-hop routed LSP between the transmit endpoint and the an hop-by-hop routed LSP between the transmit endpoint and the
receive endpoint. receive endpoint.
An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an
Explicitly Routed LSP. Explicitly Routed LSP.
2.26.4. Hierarchy: LSP Tunnels within LSPs 2.27.4. Hierarchy: LSP Tunnels within LSPs
Consider a LSP <R1, R2, R3, R4>. Let us suppose that R1 receives Consider a LSP <R1, R2, R3, R4>. Let us suppose that R1 receives
unlabeled packet P, and pushes on its label stack the label to cause unlabeled packet P, and pushes on its label stack the label to cause
it to follow this path, and that this is in fact the Hop-by-hop path. it to follow this path, and that this is in fact the Hop-by-hop path.
However, let us further suppose that R2 and R3 are not directly However, let us further suppose that R2 and R3 are not directly
connected, but are "neighbors" by virtue of being the endpoints of an connected, but are "neighbors" by virtue of being the endpoints of an
LSP tunnel. So the actual sequence of LSRs traversed by P is <R1, R2, LSP tunnel. So the actual sequence of LSRs traversed by P is <R1, R2,
R21, R22, R23, R3, R4>. R21, R22, R23, R3, R4>.
When P travels from R1 to R2, it will have a label stack of depth 1. When P travels from R1 to R2, it will have a label stack of depth 1.
skipping to change at page 39, line 28 skipping to change at page 34, line 40
to R3. Then it pushes on a new label. This level 2 label has a value 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 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, 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 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. 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 Since R3 is the penultimate hop in P's level 1 LSP, it pops the label
stack, and R4 receives P unlabeled. stack, and R4 receives P unlabeled.
The label stack mechanism allows LSP tunneling to nest to any depth. The label stack mechanism allows LSP tunneling to nest to any depth.
2.26.5. LDP Peering and Hierarchy 2.27.5. LDP Peering and Hierarchy
Suppose that packet P travels along a Level 1 LSP <R1, R2, R3, R4>, Suppose that packet P travels along a Level 1 LSP <R1, R2, R3, R4>,
and when going from R2 to R3 travels along a Level 2 LSP <R2, R21, and when going from R2 to R3 travels along a Level 2 LSP <R2, R21,
R22, R3>. From the perspective of the Level 2 LSP, R2's LDP peer is R22, R3>. 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 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 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. 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 Note that in this example, R2 and R21 must be IGP neighbors, but R2
and R3 need not be. and R3 need not be.
skipping to change at page 40, line 41 skipping to change at page 36, line 5
Peers is large. Implicit peering does not require a n-square Peers is large. Implicit peering does not require a n-square
peering mesh to distribute labels to the remote LDP peers peering mesh to distribute labels to the remote LDP peers
because the information is piggybacked through the local LDP because the information is piggybacked through the local LDP
peering. However, implicit peering requires the intermediate peering. However, implicit peering requires the intermediate
nodes to store information that they might not be directly nodes to store information that they might not be directly
interested in. interested in.
An example of the use of implicit peering is found in section An example of the use of implicit peering is found in section
3.3. 3.3.
2.27. LDP Transport 2.28. LDP Transport
LDP is used between nodes in an MPLS network to establish and LDP is used between nodes in an MPLS network to establish and
maintain the label bindings. In order for LDP to operate correctly, maintain the label bindings. In order for LDP to operate correctly,
LDP information needs to be transmitted reliably, and the LDP LDP information needs to be transmitted reliably, and the LDP
messages pertaining to a particular FEC need to be transmitted in messages pertaining to a particular FEC need to be transmitted in
sequence. Flow control is also required, as is the capability to sequence. Flow control is also required, as is the capability to
carry multiple LDP messages in a single datagram. carry multiple LDP messages in a single datagram.
These goals will be met by using TCP as the underlying transport for These goals will be met by using TCP as the underlying transport for
LDP. LDP.
(The use of multicast techniques to distribute label bindings is for (The use of multicast techniques to distribute label bindings is for
further study.) further study.)
2.28. Multicast 2.29. Multicast
This section is for further study This section is for further study
3. Some Applications of MPLS 3. Some Applications of MPLS
3.1. MPLS and Hop by Hop Routed Traffic 3.1. MPLS and Hop by Hop Routed Traffic
One use of MPLS is to simplify the process of forwarding packets A number of uses of MPLS require that packets with a certain label be
using hop by hop routing. forwarded along the same hop-by-hop routed path that would be used
for forwarding a packet with a specified address in its network layer
destination address field.
3.1.1. Labels for Address Prefixes 3.1.1. Labels for Address Prefixes
In general, router R determines the next hop for packet P by finding In general, router R determines the next hop for packet P by finding
the address prefix X in its routing table which is the longest match the address prefix X in its routing table which is the longest match
for P's destination address. That is, the packets in a given FEC are 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 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. table. In this case, a FEC can be identified with an address prefix.
If packet P must traverse a sequence of routers, and at each router Note that a packet P may be assigned to FEC F, and FEC F may be
in the sequence P matches the same address prefix, MPLS simplifies identified with address prefix X, even if P's destination address
the forwarding process by enabling all routers but the first to avoid does not match X.
executing the best match algorithm; they need only look up the label.
3.1.2. Distributing Labels for Address Prefixes 3.1.2. Distributing Labels for Address Prefixes
3.1.2.1. LDP Peers for a Particular Address Prefix 3.1.2.1. LDP Peers for a Particular Address Prefix
LSRs R1 and R2 are considered to be LDP Peers for address prefix X if LSRs R1 and R2 are considered to be LDP Peers for address prefix X if
and only if one of the following conditions holds: and only if one of the following conditions holds:
1. R1's route to X is a route which it learned about via a 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 particular instance of a particular IGP, and R2 is a neighbor
skipping to change at page 42, line 23 skipping to change at page 37, line 40
In general, these rules ensure that if the route to a particular 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 is distributed via an IGP, the LDP peers for that
address prefix are the IGP neighbors. If the route to a particular address prefix are the IGP neighbors. If the route to a particular
address prefix is distributed via BGP, the LDP peers for that address address prefix is distributed via BGP, the LDP peers for that address
prefix are the BGP peers. In other cases of LSP tunneling, the prefix are the BGP peers. In other cases of LSP tunneling, the
tunnel endpoints are LDP peers. tunnel endpoints are LDP peers.
3.1.2.2. Distributing Labels 3.1.2.2. Distributing Labels
In order to use MPLS for the forwarding of normally routed traffic, In order to use MPLS for the forwarding of packets according to the
each LSR MUST: 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 1. bind one or more labels to each address prefix that appears in
its routing table; its routing table;
2. for each such address prefix X, use an LDP to distribute the 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. binding of a label to X to each of its LDP Peers for X.
There is also one circumstance in which an LSR must distribute a 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 label binding for an address prefix, even if it is not the LSR which
bound that label to that address prefix: bound that label to that address prefix:
3. If R1 uses BGP to distribute a route to X, naming some other 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 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 assigned label L to X, then R1 must distribute the binding
between T and X to any BGP peer to which it distributes that between L and X to any BGP peer to which it distributes that
route. route.
These rules ensure that labels corresponding to address prefixes These rules ensure that labels corresponding to address prefixes
which correspond to BGP routes are distributed to IGP neighbors if which correspond to BGP routes are distributed to IGP neighbors if
and only if the BGP routes are distributed into the IGP. Otherwise, and only if the BGP routes are distributed into the IGP. Otherwise,
the labels bound to BGP routes are distributed only to the other BGP the labels bound to BGP routes are distributed only to the other BGP
speakers. speakers.
These rules are intended only to indicate which label bindings must These rules are intended only to indicate which label bindings must
be distributed by a given LSR to which other LSRs. be distributed by a given LSR to which other LSRs.
skipping to change at page 43, line 36 skipping to change at page 39, line 10
advertising an "aggregated route" to R1. In this situation, packet P advertising an "aggregated route" to R1. In this situation, packet P
can be label Switched until it reaches R2, but since R2 has performed can be label Switched until it reaches R2, but since R2 has performed
route aggregation, it must execute the best match algorithm to find route aggregation, it must execute the best match algorithm to find
P's FEC. P's FEC.
3.1.4. LSP Egress and LSP Proxy Egress 3.1.4. LSP Egress and LSP Proxy Egress
An LSR R is considered to be an "LSP Egress" LSR for address prefix X An LSR R is considered to be an "LSP Egress" LSR for address prefix X
if and only if one of the following conditions holds: if and only if one of the following conditions holds:
1. R1 has an address Y, such that X is the address prefix in R1's 1. R has an address Y, such that X is the address prefix in R's
routing table which is the longest match for Y, or routing table which is the longest match for Y, or
2. R contains in its routing tables one or more address prefixes Y 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 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 previous hops" for X do not contain any such address prefixes
Y; that is, R2 is a "deaggregation point" for address prefix X. 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 An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address
prefix X if and only if: prefix X if and only if:
1. R1's next hop for X is R2 R1 and R2 are not LDP Peers with 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 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 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 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 does not support MPLS; in this case the penultimate node in the LSP
is the Proxy Egress. is the Proxy Egress.
3.1.5. The Implicit NULL Label 3.1.5. The Implicit NULL Label
The Implicit NULL label is a label with special semantics which an The Implicit NULL label is a label with special semantics which an
LSR can bind to an address prefix. If LSR Ru, by consulting its ILM, LSR can bind to an address prefix. If LSR Ru, by consulting its ILM,
skipping to change at page 45, line 10 skipping to change at page 40, line 28
If the penultimate LSR in an LSP for address prefix X is an LSP Proxy If the penultimate LSR in an LSP for address prefix X is an LSP Proxy
Egress, it acts just as if the LSP Egress had distributed a binding Egress, it acts just as if the LSP Egress had distributed a binding
of Implicit NULL for X. of Implicit NULL for X.
3.1.6. Option: Egress-Targeted Label Assignment 3.1.6. Option: Egress-Targeted Label Assignment
There are situations in which an LSP Ingress, Ri, knows that packets There are situations in which an LSP Ingress, Ri, knows that packets
of several different FECs must all follow the same LSP, terminating of several different FECs must all follow the same LSP, terminating
at, say, LSP Egress Re. In this case, proper routing can be achieved at, say, LSP Egress Re. In this case, proper routing can be achieved
by using a single label can be used for all such FECs; it is not by using a single label for all such FECs; it is not necessary to
necessary to have a distinct label for each FEC. If (and only if) have a distinct label for each FEC. If (and only if) the following
the following conditions hold: conditions hold:
1. the address of LSR Re is itself in the routing table as a "host 1. the address of LSR Re is itself in the routing table as a "host
route", and route", and
2. there is some way for Ri to determine that Re is the LSP egress 2. there is some way for Ri to determine that Re is the LSP egress
for all packets in a particular set of FECs for all packets in a particular set of FECs
Then Ri may bind a single label to all FECS in the set. This is Then Ri may bind a single label to all FECS in the set. This is
known as "Egress-Targeted Label Assignment." known as "Egress-Targeted Label Assignment."
How can LSR Ri determine that an LSR Re is the LSP Egress for all How can LSR Ri determine that an LSR Re is the LSP Egress for all
packets in a particular FEC? There are a couple of possible ways: packets in a particular FEC? There are a number of possible ways:
- If the network is running a link state routing algorithm, and all - If the network is running a link state routing algorithm, and all
nodes in the area support MPLS, then the routing algorithm nodes in the area support MPLS, then the routing algorithm
provides Ri with enough information to determine the routers provides Ri with enough information to determine the routers
through which packets in that FEC must leave the routing domain through which packets in that FEC must leave the routing domain
or area. or area.
- It is possible to use LDP to pass information about which address - If the network is running BGP, Ri may be able to determine that
prefixes are "attached" to which egress LSRs. This method has the packets in a particular FEC must leave the network via some
the advantage of not depending on the presence of link state particular router which is the "BGP Next Hop" for that FEC.
routing.
- 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.
If egress-targeted label assignment is used, the number of labels If egress-targeted label assignment is used, the number of labels
that need to be supported throughout the network may be greatly that need to be supported throughout the network may be greatly
reduced. This may be significant if one is using legacy switching reduced. This may be significant if one is using legacy switching
hardware to do MPLS, and the switching hardware can support only a hardware to do MPLS, and the switching hardware can support only a
limited number of labels. limited number of labels.
One possible approach would be to configure the network to use One possible approach would be to configure the network to use
egress-targeted label assignment by default, but to configure egress-targeted label assignment by default, but to configure
particular LSRs to NOT use egress-targeted label assignment for one particular LSRs to NOT use egress-targeted label assignment for one
skipping to change at page 46, line 36 skipping to change at page 42, line 14
Egress or Proxy Egress, forwarding will still be done correctly. Ru Egress or Proxy Egress, forwarding will still be done correctly. Ru
will just map the incoming label to the label which Rd has assigned will just map the incoming label to the label which Rd has assigned
to the address of that LSP Egress. to the address of that LSP Egress.
3.2. MPLS and Explicitly Routed LSPs 3.2. MPLS and Explicitly Routed LSPs
There are a number of reasons why it may be desirable to use explicit There are a number of reasons why it may be desirable to use explicit
routing instead of hop by hop routing. For example, this allows routing instead of hop by hop routing. For example, this allows
routes to be based on administrative policies, and allows the routes routes to be based on administrative policies, and allows the routes
that LSPs take to be carefully designed to allow traffic engineering that LSPs take to be carefully designed to allow traffic engineering
(i.e., to allow intentional management of the loading of the [MPLS-TRFENG].
bandwidth through the nodes and links in the network).
3.2.1. Explicitly Routed LSP Tunnels: Traffic Engineering 3.2.1. Explicitly Routed LSP Tunnels
In some situations, the network administrators may desire to forward In some situations, the network administrators may desire to forward
certain classes of traffic along certain pre-specified paths, where certain classes of traffic along certain pre-specified paths, where
these paths differ from the Hop-by-hop path that the traffic would these paths differ from the Hop-by-hop path that the traffic would
ordinarily follow. This is known as Traffic Engineering. ordinarily follow. This can be done in support of policy routing,
or in support of traffic engineering. The explicit route may be a
configured one, or it may be determined dynamically by some means,
e.g., by constraint-based routing.
MPLS allows this to be easily done by means of Explicitly Routed LSP MPLS allows this to be easily done by means of Explicitly Routed LSP
Tunnels. All that is needed is: Tunnels. All that is needed is:
1. A means of selecting the packets that are to be sent into the 1. A means of selecting the packets that are to be sent into the
Explicitly Routed LSP Tunnel; Explicitly Routed LSP Tunnel;
2. A means of setting up the Explicitly Routed LSP Tunnel; 2. A means of setting up the Explicitly Routed LSP Tunnel;
3. A means of ensuring that packets sent into the Tunnel will not 3. A means of ensuring that packets sent into the Tunnel will not
skipping to change at page 47, line 47 skipping to change at page 43, line 30
order to forward the packets. However, it can result in the use of a order to forward the packets. However, it can result in the use of a
large number of labels. large number of labels.
An alternative would be to bind all 10 address prefixes to the same An alternative would be to bind all 10 address prefixes to the same
level 1 label (which is also bound to the address of the LSR itself), level 1 label (which is also bound to the address of the LSR itself),
and then to bind each address prefix to a distinct level 2 label. The and then to bind each address prefix to a distinct level 2 label. The
level 2 label would be treated as an attribute of the level 1 label level 2 label would be treated as an attribute of the level 1 label
binding, which we call the "Stack Attribute". We impose the binding, which we call the "Stack Attribute". We impose the
following rules: following rules:
- When LSR Ru initially labels an untagged packet, if the longest - When LSR Ru initially labels a hitherto unlabeled packet, if the
match for the packet's destination address is X, and R's LSP next longest match for the packet's destination address is X, and Ru's
hop for X is Rd, and Rd has distributed to R1 a binding of label LSP next hop for X is Rd, and Rd has distributed to Ru a binding
L1 X, along with a stack attribute of L2, then 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, 1. Ru must push L2 and then L1 onto the packet's label stack,
and then forward the packet to Rd; and then forward the packet to Rd;
2. When Ru distributes label bindings for X to its LDP peers, 2. When Ru distributes label bindings for X to its LDP peers,
it must include L2 as the stack attribute. it must include L2 as the stack attribute.
3. Whenever the stack attribute changes (possibly as a result 3. Whenever the stack attribute changes (possibly as a result
of a change in Ru's LSP next hop for X), Ru must distribute of a change in Ru's LSP next hop for X), Ru must distribute
the new stack attribute. the new stack attribute.
skipping to change at page 49, line 13 skipping to change at page 44, line 41
distinguished. Thus instead of talking about two distinct LSPs, <R1, distinguished. Thus instead of talking about two distinct LSPs, <R1,
R2, R3> and <R4, R2, R3>, we might talk of a single "Multipoint-to- R2, R3> and <R4, R2, R3>, we might talk of a single "Multipoint-to-
Point LSP Tree", which we might denote as <{R1, R4}, R2, R3>. Point LSP Tree", which we might denote as <{R1, R4}, R2, R3>.
This creates a difficulty when we attempt to use conventional ATM This creates a difficulty when we attempt to use conventional ATM
switches as LSRs. Since conventional ATM switches do not support switches as LSRs. Since conventional ATM switches do not support
multipoint-to-point connections, there must be procedures to ensure multipoint-to-point connections, there must be procedures to ensure
that each LSP is realized as a point-to-point VC. However, if ATM that each LSP is realized as a point-to-point VC. However, if ATM
switches which do support multipoint-to-point VCs are in use, then switches which do support multipoint-to-point VCs are in use, then
the LSPs can be most efficiently realized as multipoint-to-point VCs. the LSPs can be most efficiently realized as multipoint-to-point VCs.
Alternatively, if the SVP Multipoint Encoding (section 2.24.2) can be Alternatively, if the SVP Multipoint Encoding (section 2.25.2) can be
used, the LSPs can be realized as multipoint-to-point SVPs. used, the LSPs can be realized as multipoint-to-point SVPs.
3.6. LSP Tunneling between BGP Border Routers 3.6. LSP Tunneling between BGP Border Routers
Consider the case of an Autonomous System, A, which carries transit Consider the case of an Autonomous System, A, which carries transit
traffic between other Autonomous Systems. Autonomous System A will traffic between other Autonomous Systems. Autonomous System A will
have a number of BGP Border Routers, and a mesh of BGP connections have a number of BGP Border Routers, and a mesh of BGP connections
among them, over which BGP routes are distributed. In many such among them, over which BGP routes are distributed. In many such
cases, it is desirable to avoid distributing the BGP routes to cases, it is desirable to avoid distributing the BGP routes to
routers which are not BGP Border Routers. If this can be avoided, routers which are not BGP Border Routers. If this can be avoided,
skipping to change at page 51, line 43 skipping to change at page 47, line 34
4. LDP Procedures for Hop-by-Hop Routed Traffic 4. LDP Procedures for Hop-by-Hop Routed Traffic
4.1. The Procedures for Advertising and Using labels 4.1. The Procedures for Advertising and Using labels
In this section, we consider only label bindings that are used for 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 traffic to be label switched along its hop-by-hop routed path. In
these cases, the label in question will correspond to an address these cases, the label in question will correspond to an address
prefix in the routing table. prefix in the routing table.
There are a number of different procedures that may be used to There are a number of different procedures that may be used to
distribute label bindings. One such procedure is executed by the distribute label bindings. Some are executed by the downstream LSR,
downstream LSR, and the others by the upstream LSR. and some by the upstream LSR.
The downstream LSR must perform: The downstream LSR must perform:
- The Distribution Procedure, and - The Distribution Procedure, and
- the Withdrawal Procedure. - the Withdrawal Procedure.
The upstream LSR must perform: The upstream LSR must perform:
- The Request Procedure, and - The Request Procedure, and
skipping to change at page 55, line 32 skipping to change at page 51, line 18
PushConditional procedure or the PushUnconditional procedure, but is PushConditional procedure or the PushUnconditional procedure, but is
not useful if the downstream LSR uses the PulledUnconditional not useful if the downstream LSR uses the PulledUnconditional
procedure or the the PulledConditional procedures. procedure or the the PulledConditional procedures.
This procedure would be used by an LSR when downstream label This procedure would be used by an LSR when downstream label
distribution and Liberal Label Retention Mode are being used. distribution and Liberal Label Retention Mode are being used.
4.1.2.2. RequestWhenNeeded 4.1.2.2. RequestWhenNeeded
Make a request whenever the L3 next hop to the address prefix Make a request whenever the L3 next hop to the address prefix
changes, and one doesn't already have a label binding from that next changes, or when a new address prefix is learned, and one doesn't
hop for the given address prefix. 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 This procedure would be used by an LSR whenever Conservative Label
Retention Mode is being used. Retention Mode is being used.
4.1.2.3. RequestOnRequest 4.1.2.3. RequestOnRequest
Issue a request whenever a request is received, in addition to Issue a request whenever a request is received, in addition to
issuing a request when needed (as described in section 4.1.2.2). If issuing a request when needed (as described in section 4.1.2.2). If
Rd receives such a request from Ru, for an address prefix for which Ru is not capable of being an LSP ingress, it may issue a request
Rd has already distributed Ru a label, Rd shall assign a new only when it receives a request from upstream.
If Rd receives such a request from Ru, for an address prefix for
which Rd has already distributed Ru a label, Rd shall assign a new
(distinct) label, bind it to X, and distribute that binding. (distinct) label, bind it to X, and distribute that binding.
(Whether Rd can distribute this binding to Ru immediately or not (Whether Rd can distribute this binding to Ru immediately or not
depends on the Distribution Procedure being used.) depends on the Distribution Procedure being used.)
This procedure would be used by an LSR which doing downstream-on- This procedure would be used by an LSR which is doing downstream-on-
demand label distribution, but is not doing label merging, e.g., an demand label distribution, but is not doing label merging, e.g., an
ATM-LSR which is not capable of VC merge. ATM-LSR which is not capable of VC merge.
4.1.3. Upstream LSR: NotAvailable Procedure 4.1.3. Upstream LSR: NotAvailable Procedure
If Ru and Rd are respectively upstream and downstream label If Ru and Rd are respectively upstream and downstream label
distribution peers for address prefix X, and Rd is Ru's L3 next hop distribution peers for address prefix X, and Rd is Ru's L3 next hop
for X, and Ru requests a binding for X from Rd, but Rd replies that for X, and Ru requests a binding for X from Rd, but Rd replies that
it cannot provide a binding at this time, then the NotAvailable it cannot provide a binding at this time, because it has no next hop
procedure determines how Ru responds. There are two possible for X, then the NotAvailable procedure determines how Ru responds.
procedures governing Ru's behavior:
There are two possible procedures governing Ru's behavior:
4.1.3.1. RequestRetry 4.1.3.1. RequestRetry
Ru should issue the request again at a later time. That is, the Ru should issue the request again at a later time. That is, the
requester is responsible for trying again later to obtain the needed requester is responsible for trying again later to obtain the needed
binding. This procedure would be used when downstream-on-demand binding. This procedure would be used when downstream-on-demand
label distribution is used. label distribution is used.
4.1.3.2. RequestNoRetry 4.1.3.2. RequestNoRetry
Ru should never reissue the request, instead assuming that Rd will Ru should never reissue the request, instead assuming that Rd will
provide the binding automatically when it is available. This is provide the binding automatically when it is available. This is
useful if Rd uses the PushUnconditional procedure or the useful if Rd uses the PushUnconditional procedure or the
PushConditional procedure, i.e., if downstream label distribution is PushConditional procedure, i.e., if downstream label distribution is
used. 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 4.1.4. Upstream LSR: Release Procedure
Suppose that Rd is an LSR which has bound a label to address prefix Suppose that Rd is an LSR which has bound a label to address prefix
X, and has distributed that binding to LSR Ru. If Rd does not happen X, and has distributed that binding to LSR Ru. If Rd does not happen
to be Ru's L3 next hop for address prefix X, or has ceased to be Ru's to be Ru's L3 next hop for address prefix X, or has ceased to be Ru's
L3 next hop for address prefix X, then Rd will not be using the L3 next hop for address prefix X, then Ru will not be using the
label. The Release Procedure determines how Ru acts in this case. label. The Release Procedure determines how Ru acts in this case.
There are two possible procedures governing Ru's behavior: There are two possible procedures governing Ru's behavior:
4.1.4.1. ReleaseOnChange 4.1.4.1. ReleaseOnChange
Ru should release the binding, and inform Rd that it has done so. Ru should release the binding, and inform Rd that it has done so.
This procedure would be used to implement Conservative Label This procedure would be used to implement Conservative Label
Retention Mode. Retention Mode.
4.1.4.2. NoReleaseOnChange 4.1.4.2. NoReleaseOnChange
skipping to change at page 57, line 26 skipping to change at page 53, line 20
Ru will make use of the binding if Rd is Ru's L3 next hop for X. If, Ru will make use of the binding if Rd is Ru's L3 next hop for X. If,
at the time the binding is received by Ru, Rd is NOT Ru's L3 next hop at the time the binding is received by Ru, Rd is NOT Ru's L3 next hop
for X, Ru does not make any use of the binding at that time. Ru may for X, Ru does not make any use of the binding at that time. Ru may
however start using the binding at some later time, if Rd becomes however start using the binding at some later time, if Rd becomes
Ru's L3 next hop for X. Ru's L3 next hop for X.
The labelUse Procedure determines just how Ru makes use of Rd's The labelUse Procedure determines just how Ru makes use of Rd's
binding. binding.
There are three procedures which Ru may use: There are two procedures which Ru may use:
4.1.5.1. UseImmediate 4.1.5.1. UseImmediate
Ru may put the binding into use immediately. At any time when Ru has 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 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 neither also be Ru's LSP next hop for X. This procedure is used when loop
loop prevention nor loop detection are in use. detection is not in use.
4.1.5.2. UseIfLoopFree
Ru will use the binding only if it determines that by doing so, it
will not cause a forwarding loop.
If Ru has a binding for X from Rd, and Rd is (or becomes) Ru's L3
next hop for X, but Rd is NOT Ru's current LSP next hop for X, Ru
does NOT immediately make Rd its LSP next hop. Rather, it initiates
a loop prevention algorithm. If, upon the completion of this
algorithm, Rd is still the L3 next hop for X, Ru will make Rd the LSP
next hop for X, and use L as the outgoing label.
This procedure is used when loop prevention is in use.
The loop prevention algorithm to be used is still under
consideration.
4.1.5.3. UseIfLoopNotDetected 4.1.5.2. UseIfLoopNotDetected
This procedure is the same as UseImmediate, unless Ru has detected a 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 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. packets that would otherwise have been labeled with L and sent to Rd.
This procedure is used when loop detection, but not loop prevention, This procedure is used when loop detection is in use.
is in use.
This will continue until the next hop for X changes, or until the This will continue until the next hop for X changes, or until the
loop is no longer detected. loop is no longer detected.
4.1.6. Downstream LSR: Withdraw Procedure 4.1.6. Downstream LSR: Withdraw Procedure
In this case, there is only a single procedure. In this case, there is only a single procedure.
When LSR Rd decides to break the binding between label L and address When LSR Rd decides to break the binding between label L and address
prefix X, then this unbinding must be distributed to all LSRs to prefix X, then this unbinding must be distributed to all LSRs to
which the binding was distributed. which the binding was distributed.
It is desirable, though not required, that the unbinding of L from X It is required that the unbinding of L from X be distributed by Rd to
be distributed by Rd to a LSR Ru before Rd distributes to Ru any new a LSR Ru before Rd distributes to Ru any new binding of L to any
binding of L to any other address prefix Y, where X != Y. If Ru other address prefix Y, where X != Y. If Ru were to learn of the new
learns of the new binding of L to Y before it learns of the unbinding binding of L to Y before it learned of the unbinding of L from X, and
of L from X, and if packets matching both X and Y are forwarded by Ru if packets matching both X and Y were forwarded by Ru to Rd, then for
to Rd, then for a period of time, Ru will label both packets matching a period of time, Ru would label both packets matching X and packets
X and packets matching Y with label L. matching Y with label L.
The distribution and withdrawal of label bindings is done via a label 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 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, 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 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 as a result of failure or as a matter of normal operation), then all
bindings learned over that instance of the protocol must be bindings learned over that instance of the protocol must be
considered to have been withdrawn. considered to have been withdrawn.
As long as the relevant LDP connection remains open, label bindings As long as the relevant LDP connection remains open, label bindings
skipping to change at page 59, line 24 skipping to change at page 55, line 5
labelUse Procedure>. (Since there is only one Withdraw Procedure, it labelUse Procedure>. (Since there is only one Withdraw Procedure, it
need not be mentioned.) A "*" appearing in one of the positions is a need not be mentioned.) A "*" appearing in one of the positions is a
wild-card, meaning that any procedure in that category may be wild-card, meaning that any procedure in that category may be
present; an "N/A" appearing in a particular position indicates that present; an "N/A" appearing in a particular position indicates that
no procedure in that category is needed. no procedure in that category is needed.
Only the MPLS schemes which are specified below are supported by the Only the MPLS schemes which are specified below are supported by the
MPLS Architecture. Other schemes may be added in the future, if a MPLS Architecture. Other schemes may be added in the future, if a
need for them is shown. need for them is shown.
4.2.1. TTL-capable LSP Segments 4.2.1. Schemes for LSRs that Support Label Merging
If Ru and Rd are MPLS peers, and both are capable of decrementing a If Ru and Rd are label distribution peers, and both support label
TTL field in the MPLS header, then the MPLS scheme in use between Ru merging, one of the following schemes must be used:
and Rd must be one of the following:
1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, 1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
UseImmediate> UseImmediate>
This is downstream label distribution with independent control, This is downstream label distribution with independent control,
liberal label retention mode, and no loop detection. liberal label retention mode, and no loop detection.
2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, 2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
UseIfLoopNotDetected> UseIfLoopNotDetected>
This is downstream label distribution with independent control, This is downstream label distribution with independent control,
liberal label retention, and loop detection. liberal label retention, and loop detection.
3. <PushConditional, RequestWhenNeeded, RequestNoRetry, 3. <PushConditional, RequestWhenNeeded, RequestNoRetry,
ReleaseOnChange, *> ReleaseOnChange, *>
This is downstream label distribution with ordered control and This is downstream label distribution with ordered control
conservative label retention mode. Loop prevention and loop (from the egress) and conservative label retention mode. Loop
detection are optional. detection is optional.
4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *> 4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>
This is downstream label distribution with ordered control and This is downstream label distribution with ordered control
liberal label retention mode. Loop prevention and loop (from the egress) and liberal label retention mode. Loop
detection are optional. detection is optional.
4.2.2. Using ATM Switches as LSRs 5. <PulledConditional, RequestWhenNeeded, RequestRetry,
ReleaseOnChange, *>
The procedures for using ATM switches as LSRs depends on whether the This is downstream-on-demand label distribution with ordered
ATM switches can realize LSP trees as multipoint-to-point VCs or VPs. control (initiated by the ingress), conservative label
retention mode, and optional loop detection.
Most ATM switches existing today do NOT have a multipoint-to-point 6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
VC-switching capability. Their cross-connect tables could easily be UseImmediate>
programmed to move cells from multiple incoming VCs to a single
outgoing VC, but the result would be that cells from different
packets get interleaved.
Some ATM switches do support a multipoint-to-point VC-switching This is downstream-on-demand label distribution with
capability. These switches will queue up all the incoming cells from independent control and conservative label retention mode,
an incoming VC until a packet boundary is reached. Then they will without loop detection.
transmit the entire sequence of cells on the outgoing VC, without
allowing cells from any other packet to be interleaved.
Many ATM switches do support a multipoint-to-point VP-switching 7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
capability, which can be used if the Multipoint SVP label encoding is UseIfLoopNotDetected>
used.
4.2.2.1. Without Label Merging This is downstream-on-demand label distribution with
independent control and conservative label retention mode, with
loop detection.
4.2.2. Schemes for LSRs that do not Support Label Merging
Suppose that R1, R2, R3, and R4 are ATM switches which do not support Suppose that R1, R2, R3, and R4 are ATM switches which do not support
label merging, but are being used as LSRs. Suppose further that the label merging, but are being used as LSRs. Suppose further that the
L3 hop-by-hop path for address prefix X is <R1, R2, R3, R4>, and that L3 hop-by-hop path for address prefix X is <R1, R2, R3, R4>, and that
packets destined for X can enter the network at any of these LSRs. packets destined for X can enter the network at any of these LSRs.
Since there is no multipoint-to-point capability, the LSPs must be Since there is no multipoint-to-point capability, the LSPs must be
realized as point-to-point VCs, which means that there needs to be realized as point-to-point VCs, which means that there needs to be
three such VCs for address prefix X: <R1, R2, R3, R4>, <R2, R3, R4>, three such VCs for address prefix X: <R1, R2, R3, R4>, <R2, R3, R4>,
and <R3, R4>. and <R3, R4>.
Therefore, if R1 and R2 are MPLS peers, and either is an LSR which is Therefore, if R1 and R2 are MPLS peers, and either is an LSR which is
implemented using conventional ATM switching hardware (i.e., no cell implemented using conventional ATM switching hardware (i.e., no cell
interleave suppression), the MPLS scheme in use between R1 and R2 interleave suppression), or is otherwise incapable of performing
must be one of the following: label merging, the MPLS scheme in use between R1 and R2 must be one
of the following:
1. <PulledUnconditional, RequestOnRequest, RequestRetry,
ReleaseOnChange, UseImmediate>
This is downstream-on-demand label distribution with
independent control and conservative label retention mode,
without loop prevention or detection.
2. <PulledUnconditional, RequestOnRequest, RequestRetry,
ReleaseOnChange, UseIfLoopNotDetected>
This is downstream-on-demand label distribution with
independent control and conservative label retention mode, with
loop detection.
3. <PulledConditional, RequestOnRequest, RequestNoRetry, 1. <PulledConditional, RequestOnRequest, RequestRetry,
ReleaseOnChange, *> ReleaseOnChange, *>
This is downstream-on-demand label distribution with ordered This is downstream-on-demand label distribution with ordered
control (initiated by the ingress), conservative label control (initiated by the ingress), conservative label
retention mode, and optional loop detection or loop prevention. retention mode, and optional loop detection.
The use of the RequestOnRequest procedure will cause R4 to The use of the RequestOnRequest procedure will cause R4 to
distribute three labels for X to R3; R3 will distribute 2 distribute three labels for X to R3; R3 will distribute 2
labels for X to R2, and R2 will distribute one label for X to labels for X to R2, and R2 will distribute one label for X to
R1. R1.
4.2.2.2. With Label Merging 2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange,
UseImmediate>
If R1 and R2 are MPLS peers, at least one of which is an ATM-LSR
which supports label merging, then the MPLS scheme in use between R1
and R2 must be one of the following:
1. <PulledConditional, RequestOnRequest, RequestNoRetry,
ReleaseOnChange, *>
This is downstream-on-demand label distribution with This is downstream-on-demand label distribution with
independent control and conservative label retention mode,
without loop detection.
<PushConditional, RequestWhenNeeded, RequestNoRetry, *, *> 3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange,
UseIfLoopNotDetected>
<PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
UseImmediate>
The first of these is an ordered control scheme. The second is This is downstream-on-demand label distribution with
is the "downstream" variant of independent control. The third independent control and conservative label retention mode, with
is the "conservative downstream-on-demand" variant of loop detection.
independent control.
4.2.3. Interoperability Considerations 4.2.3. Interoperability Considerations
It is easy to see that certain quintuples do NOT yield viable MPLS It is easy to see that certain quintuples do NOT yield viable MPLS
schemes. For example: schemes. For example:
- <PulledUnconditional, RequestNever, *, *, *> - <PulledUnconditional, RequestNever, *, *, *>
<PulledConditional, RequestNever, *, *, *> <PulledConditional, RequestNever, *, *, *>
In these MPLS schemes, the downstream LSR Rd distributes label In these MPLS schemes, the downstream LSR Rd distributes label
skipping to change at page 62, line 31 skipping to change at page 57, line 31
In these MPLS schemes, Rd releases bindings when it isn't using 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 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 need for them. These schemes thus do not ensure that label
bindings get properly distributed. bindings get properly distributed.
In this section, we specify rules to prevent a pair of LDP peers from In this section, we specify rules to prevent a pair of LDP peers from
adopting procedures which lead to infeasible MPLS Schemes. These adopting procedures which lead to infeasible MPLS Schemes. These
rules require the exchange of information between LDP peers during rules require the exchange of information between LDP peers during
the initialization of the LDP connection between them. the initialization of the LDP connection between them.
1. Each must state whether it is an ATM-LSR, and if so, whether it 1. Each must state whether it supports label merging.
has cell interleave suppression (i.e., VC merging).
2. If Rd is an ATM switch without cell interleave suppression, it 2. If Rd does not support label merging, Rd must choose either the
must state whether it intends to use the PulledUnconditional PulledUnconditional procedure or the PulledConditional
procedure or the Pulledconditional procedure. If the former, procedure. If Rd chooses PulledConditional, Ru is forced to
Ru MUST use the RequestRetry procedure; if the latter, Ru MUST use the RequestRetry procedure.
use the RequestNoRetry procedure.
3. If Ru is an ATM switch without cell interleave suppression, it That is, if the downstream LSR does not support label merging,
must state whether it intends to use the RequestRetry or the its preferences take priority when the MPLS scheme is chosen.
RequestNoRetry procedure. If Rd is an ATM switch without cell
interleave suppression, Rd is not bound by this, and in fact Ru
MUST adopt Rd's preferences. However, if Rd is NOT an ATM
switch without cell interleave suppression, then if Ru chooses
RequestRetry, Rd must use PulledUnconditional, and if Ru
chooses RequestNoRetry, Rd MUST use PulledConditional.
4. If Rd is an ATM switch with cell interleave suppression, it 3. If Ru does not support label merging, but Rd does, Ru must
must specify whether it prefers to use PushConditional, choose either the RequestRetry or RequestNoRetry procedure.
PushUnconditional, or PulledConditional. If Ru is not an ATM This forces Rd to use the PulledConditional or
switch without cell interleave suppression, it must then use PulledUnConditional procedure respectively.
RequestWhenNeeded and RequestNoRetry, or else RequestNever and
NoReleaseOnChange, respectively.
5. If Ru is an ATM switch with cell interleave suppression, it That is, if only one of the LSRs doesn't support label merging,
must specify whether it prefers to use RequestWhenNeeded and its preferences take priority when the MPLS scheme is chosen.
RequestNoRetry, or else RequestNever and NoReleaseOnChange. If
Rd is NOT an ATM switch with cell interleave suppression, it 4. If both Ru and Rd both support label merging, then the choice
must then use either PushConditional or PushUnconditional, between liberal and conservative label retention mode belongs
respectively. to Ru. That is, Ru gets to choose either to use
RequestWhenNeeded/ReleaseOnChange (conservative) , or to use
RequestNever/NoReleaseOnChange (liberal). However, the choice
of "push" vs. "pull" and "conditional" vs. "unconditional"
belongs to Rd. If Ru chooses liberal label retention mode, Rd
can choose either PushUnconditional or PushConditional. If Ru
chooses conservative label retention mode, Rd can choose
PushConditional, PulledConditional, or PulledUnconditional.
These choices together determine the MPLS scheme in use.
5. Security Considerations 5. Security Considerations
Security considerations are not discussed in this version of this Some routers may implement security procedures which depend on the
draft. 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.
6. Authors' Addresses 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
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
7. Authors' Addresses
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA, 01824 Chelmsford, MA, 01824
E-mail: erosen@cisco.com E-mail: erosen@cisco.com
Arun Viswanathan Arun Viswanathan
Lucent Technologies Lucent Technologies
101 Crawford Corner Rd., #4D-537 101 Crawford Corner Rd., #4D-537
Holmdel, NJ 07733 Holmdel, NJ 07733
732-332-5163 732-332-5163
E-mail: arunv@dnrc.bell-labs.com E-mail: arunv@dnrc.bell-labs.com
Ross Callon Ross Callon
IronBridge Networks IronBridge Networks
55 Hayden Avenue, 55 Hayden Avenue,
Lexington, MA 02173 Lexington, MA 02173
+1-781-402-8017 +1-781-372-8117
E-mail: rcallon@ironbridgenetworks.com E-mail: rcallon@ironbridgenetworks.com
7. References 8. References
[1] "A Framework for Multiprotocol Label Switching", R.Callon,
P.Doolan, N.Feldman, A.Fredette, G.Swallow, and A.Viswanathan, work
in progress, Internet Draft <draft-ietf-mpls-framework-02.txt>,
November 1997.
[2] "ARIS: Aggregate Route-Based IP Switching", A. Viswanathan, N.
Feldman, R. Boivie, R. Woundy, work in progress, Internet Draft
<draft-viswanathan-aris-overview-00.txt>, March 1997.
[3] "ARIS Specification", N. Feldman, A. Viswanathan, work in [MPLS-ATM] "MPLS using ATM VC Switching", Davie, Doolan, Lawrence,
progress, Internet Draft <draft-feldman-aris-spec-00.txt>, March McGloghrie, Rekhter, Rosen, Swallow, work in progress, Internet Draft
1997. <draft-ietf-mpls-atm-01.txt>, November 1998.
[4] "Tag Switching Architecture - Overview", Rekhter, Davie, Katz, [MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen,
Rosen, Swallow, Farinacci, work in progress, Internet Draft <draft- work in progress, Internet Draft <draft-ietf-mpls-bgp4-mpls-01.txt>,
rekhter-tagswitch-arch-00.txt>, January, 1997. August 1998.
[5] "Tag distribution Protocol", Doolan, Davie, Katz, Rekhter, Rosen, [MPLS-FRMWRK] "A Framework for Multiprotocol Label Switching",
work in progress, Internet Draft <draft-doolan-tdp-spec-01.txt>, May, Callon, Doolan, Feldman, Fredette, Swallow, Viswanathan, work in
1997. progress, Internet Draft <draft-ietf-mpls-framework-02.txt>, November
1997
[6] "Use of Tag Switching with ATM", Davie, Doolan, Lawrence, [MPLS-FRMRLY] "Use of Label Switching on Frame Relay Networks",
McGloghrie, Rekhter, Rosen, Swallow, work in progress, Internet Draft Conta, Doolan, Malis, work in progress, Internet Draft <draft-ietf-
<draft-davie-tag-switching-atm-01.txt>, January, 1997. mpls-fr-03.txt>, November 1998
[7] "Label Switching: Label Stack Encodings", Rosen, Rekhter, Tappan, [MPLS-LDP], "LDP Specification", Andersson, Doolan, Feldman,
Farinacci, Fedorkow, Li, Conta, work in progress, Internet Draft Fredette, Thomas, work in progress, Internet Draft <draft-ietf-mpls-
<draft-ietf-mpls-label-encaps-01.txt>, February, 1998. ldp-02.txt>
[8] "Partitioning Tag Space among Multicast Routers on a Common [MPLS-RSVP] "Use of Label Switching with RSVP", Davie, Rekhter,
Subnet", Farinacci, work in progress, internet draft <draft- Rosen, Viswanathan, Srinivasan, work in progress, Internet Draft
farinacci-multicast-tag-part-00.txt>, December, 1996. <draft-ietf-mpls-rsvp-00.txt>, March 1998.
[9] "Multicast Tag Binding and Distribution using PIM", Farinacci, [MPLS-RSVP-TUNNELS], "Extensions to RSVP for LSP Tunnels", Awduche,
Rekhter, work in progress, internet draft <draft-farinacci- Berger, Gan, Li, Swallow, Srinvasan, work in progress, Internet Draft
multicast-tagsw-00.txt>, December, 1996. <draft-ietf-mpls-rsvp-lsp-tunnel-00.txt>, November 1998
[10] "Toshiba's Router Architecture Extensions for ATM: Overview", [MPLS-SHIM] "MPLS Label Stack Encodings", Rosen, Rekhter, Tappan,
Katsube, Nagami, Esaki, RFC 2098, February, 1997. Farinacci, Fedorkow, Li, Conta, work in progress, Internet Draft
<draft-ietf-mpls-label-encaps-03.txt>, September, 1998
[11] "Loop-Free Routing Using Diffusing Computations", J.J. Garcia- [MPLS-TRFENG] "Requirements for Traffic Engineering Over MPLS",
Luna-Aceves, IEEE/ACM Transactions on Networking, Vol. 1, No. 1, Awduche, Malcolm, Agogbua, O'Dell, McManus, work in progress,
February 1993. Internet Draft <draft-ietf-mpls-traffic-eng-00.txt>
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/