draft-ietf-mpls-arch-05.txt   draft-ietf-mpls-arch-06.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: October 1999 Expiration Date: February 2000
Arun Viswanathan Arun Viswanathan
Lucent Technologies Lucent Technologies
Ross Callon Ross Callon
IronBridge Networks, Inc. IronBridge Networks, Inc.
April 1999 August 1999
Multiprotocol Label Switching Architecture Multiprotocol Label Switching Architecture
draft-ietf-mpls-arch-05.txt draft-ietf-mpls-arch-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This internet draft specifies the architecture for Multiprotocol This internet draft specifies the architecture for Multiprotocol
Label Switching (MPLS). Label Switching (MPLS).
Table of Contents Table of Contents
1 Introduction to MPLS ............................... 4 1 Specification ...................................... 4
1.1 Overview ........................................... 4 2 Introduction to MPLS ............................... 4
1.2 Terminology ........................................ 6 2.1 Overview ........................................... 4
1.3 Acronyms and Abbreviations ......................... 9 2.2 Terminology ........................................ 6
1.4 Acknowledgments .................................... 10 2.3 Acronyms and Abbreviations ......................... 9
2 MPLS Basics ........................................ 10 2.4 Acknowledgments .................................... 10
2.1 Labels ............................................. 10 3 MPLS Basics ........................................ 10
2.2 Upstream and Downstream LSRs ....................... 11 3.1 Labels ............................................. 10
2.3 Labeled Packet ..................................... 11 3.2 Upstream and Downstream LSRs ....................... 11
2.4 Label Assignment and Distribution .................. 11 3.3 Labeled Packet ..................................... 11
2.5 Attributes of a Label Binding ...................... 12 3.4 Label Assignment and Distribution .................. 12
2.6 Label Distribution Protocols ....................... 12 3.5 Attributes of a Label Binding ...................... 12
2.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12 3.6 Label Distribution Protocols ....................... 12
2.8 Label Retention Mode ............................... 13 3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 13
2.9 The Label Stack .................................... 13 3.8 Label Retention Mode ............................... 13
2.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 14 3.9 The Label Stack .................................... 14
2.11 Incoming Label Map (ILM) ........................... 15 3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 14
2.12 FEC-to-NHLFE Map (FTN) ............................. 15 3.11 Incoming Label Map (ILM) ........................... 15
2.13 Label Swapping ..................................... 15 3.12 FEC-to-NHLFE Map (FTN) ............................. 15
2.14 Scope and Uniqueness of Labels ..................... 16 3.13 Label Swapping ..................................... 16
2.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 17 3.14 Scope and Uniqueness of Labels ..................... 16
2.16 Penultimate Hop Popping ............................ 19 3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 17
2.17 LSP Next Hop ....................................... 20 3.16 Penultimate Hop Popping ............................ 19
2.18 Invalid Incoming Labels ............................ 21 3.17 LSP Next Hop ....................................... 21
2.19 LSP Control: Ordered versus Independent ............ 21 3.18 Invalid Incoming Labels ............................ 21
2.20 Aggregation ........................................ 22 3.19 LSP Control: Ordered versus Independent ............ 21
2.21 Route Selection .................................... 24 3.20 Aggregation ........................................ 22
2.22 Lack of Outgoing Label ............................. 24 3.21 Route Selection .................................... 24
2.23 Time-to-Live (TTL) ................................. 25 3.22 Lack of Outgoing Label ............................. 25
2.24 Loop Control ....................................... 26 3.23 Time-to-Live (TTL) ................................. 25
2.25 Label Encodings .................................... 27 3.24 Loop Control ....................................... 26
2.25.1 MPLS-specific Hardware and/or Software ............. 27 3.25 Label Encodings .................................... 27
2.25.2 ATM Switches as LSRs ............................... 27 3.25.1 MPLS-specific Hardware and/or Software ............. 27
2.25.3 Interoperability among Encoding Techniques ......... 29 3.25.2 ATM Switches as LSRs ............................... 27
2.26 Label Merging ...................................... 29 3.25.3 Interoperability among Encoding Techniques ......... 29
2.26.1 Non-merging LSRs ................................... 30 3.26 Label Merging ...................................... 30
2.26.2 Labels for Merging and Non-Merging LSRs ............ 31 3.26.1 Non-merging LSRs ................................... 31
2.26.3 Merge over ATM ..................................... 32 3.26.2 Labels for Merging and Non-Merging LSRs ............ 31
2.26.3.1 Methods of Eliminating Cell Interleave ............. 32 3.26.3 Merge over ATM ..................................... 32
2.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 32 3.26.3.1 Methods of Eliminating Cell Interleave ............. 32
2.27 Tunnels and Hierarchy .............................. 33 3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 33
2.27.1 Hop-by-Hop Routed Tunnel ........................... 34 3.27 Tunnels and Hierarchy .............................. 34
2.27.2 Explicitly Routed Tunnel ........................... 34 3.27.1 Hop-by-Hop Routed Tunnel ........................... 34
2.27.3 LSP Tunnels ........................................ 34 3.27.2 Explicitly Routed Tunnel ........................... 34
2.27.4 Hierarchy: LSP Tunnels within LSPs ................. 35 3.27.3 LSP Tunnels ........................................ 34
2.27.5 Label Distribution Peering and Hierarchy ........... 35 3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 35
2.28 Label Distribution Protocol Transport .............. 37 3.27.5 Label Distribution Peering and Hierarchy ........... 35
2.29 Why More than one Label Distribution Protocol? ..... 37 3.28 Label Distribution Protocol Transport .............. 37
2.29.1 BGP and LDP ........................................ 37 3.29 Why More than one Label Distribution Protocol? ..... 37
2.29.2 Labels for RSVP Flowspecs .......................... 37 3.29.1 BGP and LDP ........................................ 37
2.29.3 Labels for Explicitly Routed LSPs .................. 38 3.29.2 Labels for RSVP Flowspecs .......................... 37
2.30 Multicast .......................................... 38 3.29.3 Labels for Explicitly Routed LSPs .................. 38
3 Some Applications of MPLS .......................... 38 3.30 Multicast .......................................... 38
3.1 MPLS and Hop by Hop Routed Traffic ................. 38 4 Some Applications of MPLS .......................... 38
3.1.1 Labels for Address Prefixes ........................ 38 4.1 MPLS and Hop by Hop Routed Traffic ................. 38
3.1.2 Distributing Labels for Address Prefixes ........... 39 4.1.1 Labels for Address Prefixes ........................ 38
3.1.2.1 Label Distribution Peers for an Address Prefix ..... 39 4.1.2 Distributing Labels for Address Prefixes ........... 39
3.1.2.2 Distributing Labels ................................ 39 4.1.2.1 Label Distribution Peers for an Address Prefix ..... 39
3.1.3 Using the Hop by Hop path as the LSP ............... 40 4.1.2.2 Distributing Labels ................................ 39
3.1.4 LSP Egress and LSP Proxy Egress .................... 41 4.1.3 Using the Hop by Hop path as the LSP ............... 40
3.1.5 The Implicit NULL Label ............................ 41 4.1.4 LSP Egress and LSP Proxy Egress .................... 41
3.1.6 Option: Egress-Targeted Label Assignment ........... 42 4.1.5 The Implicit NULL Label ............................ 41
3.2 MPLS and Explicitly Routed LSPs .................... 44 4.1.6 Option: Egress-Targeted Label Assignment ........... 42
3.2.1 Explicitly Routed LSP Tunnels ...................... 44 4.2 MPLS and Explicitly Routed LSPs .................... 44
3.3 Label Stacks and Implicit Peering .................. 45 4.2.1 Explicitly Routed LSP Tunnels ...................... 44
3.4 MPLS and Multi-Path Routing ........................ 46 4.3 Label Stacks and Implicit Peering .................. 45
3.5 LSP Trees as Multipoint-to-Point Entities .......... 46 4.4 MPLS and Multi-Path Routing ........................ 46
3.6 LSP Tunneling between BGP Border Routers ........... 47 4.5 LSP Trees as Multipoint-to-Point Entities .......... 46
3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 49 4.6 LSP Tunneling between BGP Border Routers ........... 47
3.8 MPLS and Multicast ................................. 49 4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 49
4 Label Distribution Procedures (Hop-by-Hop) ......... 50 4.8 MPLS and Multicast ................................. 49
4.1 The Procedures for Advertising and Using labels .... 50 5 Label Distribution Procedures (Hop-by-Hop) ......... 50
4.1.1 Downstream LSR: Distribution Procedure ............. 50 5.1 The Procedures for Advertising and Using labels .... 50
4.1.1.1 PushUnconditional .................................. 51 5.1.1 Downstream LSR: Distribution Procedure ............. 50
4.1.1.2 PushConditional .................................... 51 5.1.1.1 PushUnconditional .................................. 51
4.1.1.3 PulledUnconditional ................................ 52 5.1.1.2 PushConditional .................................... 51
4.1.1.4 PulledConditional .................................. 52 5.1.1.3 PulledUnconditional ................................ 52
4.1.2 Upstream LSR: Request Procedure .................... 53 5.1.1.4 PulledConditional .................................. 52
4.1.2.1 RequestNever ....................................... 53 5.1.2 Upstream LSR: Request Procedure .................... 53
4.1.2.2 RequestWhenNeeded .................................. 53 5.1.2.1 RequestNever ....................................... 53
4.1.2.3 RequestOnRequest ................................... 54 5.1.2.2 RequestWhenNeeded .................................. 53
4.1.3 Upstream LSR: NotAvailable Procedure ............... 54 5.1.2.3 RequestOnRequest ................................... 54
4.1.3.1 RequestRetry ....................................... 54 5.1.3 Upstream LSR: NotAvailable Procedure ............... 54
4.1.3.2 RequestNoRetry ..................................... 54 5.1.3.1 RequestRetry ....................................... 54
4.1.4 Upstream LSR: Release Procedure .................... 55 5.1.3.2 RequestNoRetry ..................................... 54
4.1.4.1 ReleaseOnChange .................................... 55 5.1.4 Upstream LSR: Release Procedure .................... 55
4.1.4.2 NoReleaseOnChange .................................. 55 5.1.4.1 ReleaseOnChange .................................... 55
4.1.5 Upstream LSR: labelUse Procedure ................... 55 5.1.4.2 NoReleaseOnChange .................................. 55
4.1.5.1 UseImmediate ....................................... 56 5.1.5 Upstream LSR: labelUse Procedure ................... 55
4.1.5.2 UseIfLoopNotDetected ............................... 56 5.1.5.1 UseImmediate ....................................... 56
4.1.6 Downstream LSR: Withdraw Procedure ................. 56 5.1.5.2 UseIfLoopNotDetected ............................... 56
4.2 MPLS Schemes: Supported Combinations of Procedures . 57 5.1.6 Downstream LSR: Withdraw Procedure ................. 56
4.2.1 Schemes for LSRs that Support Label Merging ........ 57 5.2 MPLS Schemes: Supported Combinations of Procedures . 57
4.2.2 Schemes for LSRs that do not Support Label Merging . 58 5.2.1 Schemes for LSRs that Support Label Merging ........ 57
4.2.3 Interoperability Considerations .................... 59 5.2.2 Schemes for LSRs that do not Support Label Merging . 58
5 Security Considerations ............................ 61 5.2.3 Interoperability Considerations .................... 59
6 Intellectual Property .............................. 61 6 Security Considerations ............................ 61
7 Authors' Addresses ................................. 61 7 Intellectual Property .............................. 61
8 References ......................................... 62 8 Authors' Addresses ................................. 61
9 References ......................................... 62
1. Introduction to MPLS 1. Specification
1.1. Overview The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Introduction to MPLS
This internet draft specifies the architecture for Multiprotocol
Label Switching (MPLS).
Note that the use of MPLS for multicast is left for further study.
2.1. Overview
As a packet of a connectionless network layer protocol travels from As a packet of a connectionless network layer protocol travels from
one router to the next, each router makes an independent forwarding one router to the next, each router makes an independent forwarding
decision for that packet. That is, each router analyzes the packet's decision for that packet. That is, each router analyzes the packet's
header, and each router runs a network layer routing algorithm. Each header, and each router runs a network layer routing algorithm. Each
router independently chooses a next hop for the packet, based on its router independently chooses a next hop for the packet, based on its
analysis of the packet's header and the results of running the analysis of the packet's header and the results of running the
routing algorithm. routing algorithm.
Packet headers contain considerably more information than is needed Packet headers contain considerably more information than is needed
skipping to change at page 6, line 23 skipping to change at page 6, line 40
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" [MPLS-FRMWRK]. Framework for Multiprotocol Label Switching" [MPLS-FRMWRK].
1.2. Terminology 2.2. Terminology
This section gives a general conceptual overview of the terms used in This 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
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 9, line 22 skipping to change at page 9, line 37
allow multiple VPs to be merged into one allow multiple VPs to be merged into one
single VP. In this case two cells would single VP. In this case two cells would
have the same VCI value only if they have the same VCI value only if they
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 2.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
skipping to change at page 10, line 5 skipping to change at page 10, line 14
MPLS MultiProtocol Label Switching MPLS MultiProtocol Label Switching
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 2.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. MPLS Basics 3. 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 3.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, a packet is assigned to a FEC based (completely or Most commonly, a packet is assigned to a FEC based (completely or
partially) on its network layer destination address. However, the partially) on its network layer destination address. However, the
label is never an encoding of that address. label is never an encoding of that address.
skipping to change at page 11, line 12 skipping to change at page 11, line 24
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, Rd MUST NOT agree with Ru1 to bind L to FEC F1, one-to-one. That is, Rd MUST NOT agree with Ru1 to bind L to FEC F1,
while also agreeing with some other LSR Ru2 to bind L to a different while also agreeing with some other LSR Ru2 to bind L to a different
FEC F2, UNLESS Rd can always tell, when it receives a packet with FEC F2, UNLESS Rd can always tell, when it receives a packet with
incoming label L, whether the label was put on the packet by Ru1 or incoming label L, whether the label was put on the packet by Ru1 or
whether it was put on by Ru2. whether it was put on by Ru2.
It is the responsibility of each LSR to ensure that it can uniquely It is the responsibility of each LSR to ensure that it can uniquely
interpret its incoming labels. interpret its incoming labels.
2.2. Upstream and Downstream LSRs 3.2. Upstream and Downstream LSRs
Suppose Ru and Rd have agreed to bind label L to FEC F, for packets 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
downstream node. This is NOT meant to imply that packets in that FEC downstream node. This is NOT meant to imply that packets in that FEC
would actually be routed from the upstream node to the downstream would actually be routed from the upstream node to the downstream
node. node.
2.3. Labeled Packet 3.3. Labeled Packet
A "labeled packet" is a packet into which a label has been encoded. A "labeled packet" is a packet into which a label has been encoded.
In some cases, the label resides in an encapsulation header which In some cases, the label resides in an encapsulation header which
exists specifically for this purpose. In other cases, the label may exists specifically for this purpose. In other cases, the label may
reside in an existing data link or network layer header, as long as reside in an existing data link or network layer header, as long as
there is a field which is available for that purpose. The particular there is a field which is available for that purpose. The particular
encoding technique to be used must be agreed to by both the entity encoding technique to be used must be agreed to by both the entity
which encodes the label and the entity which decodes the label. which encodes the label and the entity which decodes the label.
2.4. Label Assignment and Distribution 3.4. Label Assignment and Distribution
In the MPLS architecture, the decision to bind a particular label L 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 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 fall into a certain numeric range, then it merely needs to ensure
that it only binds labels that are in that range. that it only binds labels that are in that range.
2.5. Attributes of a Label Binding 3.5. Attributes of a Label Binding
A particular binding of label L to FEC F, distributed by Rd to Ru, 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 Protocols 3.6. Label Distribution Protocols
A label distribution protocol is a set of procedures by which one LSR A label distribution protocol is a set of procedures by which one LSR
informs another of the label/FEC bindings it has made. Two LSRs informs another of the label/FEC bindings it has made. Two LSRs
which use a label distribution protocol to exchange label/FEC binding which use a label distribution protocol to exchange label/FEC binding
information are known as "label distribution peers" with respect to information are known as "label distribution peers" with respect to
the binding information they exchange. If two LSRs are label the binding information they exchange. If two LSRs are label
distribution peers, we will speak of there being a "label distribution peers, we will speak of there being a "label
distribution adjacency" between them. distribution adjacency" between them.
(N.B.: two LSRs may be label distribution peers with respect to some (N.B.: two LSRs may be label distribution peers with respect to some
skipping to change at page 12, line 42 skipping to change at page 13, line 9
distribution protocols are being standardized. Existing protocols distribution protocols are being standardized. Existing protocols
have been extended so that label distribution can be piggybacked on have been extended so that label distribution can be piggybacked on
them (see, e.g., [MPLS-BGP], [MPLS-RSVP], [MPLS-RSVP-TUNNELS]). New them (see, e.g., [MPLS-BGP], [MPLS-RSVP], [MPLS-RSVP-TUNNELS]). New
protocols have also been defined for the explicit purpose of protocols have also been defined for the explicit purpose of
distributing labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP]. distributing labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].
In this document, we try to use the acronym "LDP" to refer In this document, we try to use the acronym "LDP" to refer
specifically to the protocol defined in [MPLS-LDP]; when speaking of specifically to the protocol defined in [MPLS-LDP]; when speaking of
label distribution protocols in general, we try to avoid the acronym. label distribution protocols in general, we try to avoid the acronym.
2.7. Unsolicited Downstream vs. Downstream-on-Demand 3.7. Unsolicited Downstream vs. Downstream-on-Demand
The MPLS architecture allows an LSR to explicitly request, from its 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
"unsolicited downstream" label distribution. "unsolicited downstream" label distribution.
It is expected that some MPLS implementations will provide only It is expected that some MPLS implementations will provide only
downstream-on-demand label distribution, and some will provide only downstream-on-demand label distribution, and some will provide only
unsolicited downstream label distribution, and some will provide unsolicited downstream label distribution, and some will provide
both. Which is provided may depend on the characteristics of the both. Which is provided may depend on the characteristics of the
interfaces which are supported by a particular implementation. interfaces which are supported by a particular implementation.
However, both of these label distribution techniques may be used in However, both of these label distribution techniques may be used in
the same network at the same time. On any given label distribution the same network at the same time. On any given label distribution
adjacency, the upstream LSR and the downstream LSR must agree on adjacency, the upstream LSR and the downstream LSR must agree on
which technique is to be used. which technique is to be used.
2.8. Label Retention Mode 3.8. Label Retention Mode
An LSR Ru may receive (or have received) a label binding for a An LSR Ru may receive (or have received) a label binding for a
particular FEC from an LSR Rd, even though Rd is not Ru's next hop particular FEC from an LSR Rd, even though Rd is not Ru's next hop
(or is no longer Ru's next hop) for that FEC. (or is no longer Ru's next hop) for that FEC.
Ru then has the choice of whether to keep track of such bindings, or Ru then has the choice of whether to keep track of such bindings, or
whether to discard such bindings. If Ru keeps track of such whether to discard such bindings. If Ru keeps track of such
bindings, then it may immediately begin using the binding again if Rd bindings, then it may immediately begin using the binding again if Rd
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
skipping to change at page 13, line 37 skipping to change at page 14, line 5
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, but conservative label retention mode though requires an LSR changes, but conservative label retention mode though requires an LSR
to maintain many fewer labels. to maintain many fewer labels.
2.9. The Label Stack 3.9. The Label Stack
So far, we have spoken as if a labeled packet carries only a single 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".
Although, as we shall see, MPLS supports a hierarchy, the processing Although, as we shall see, MPLS supports a hierarchy, the processing
of a labeled packet is completely independent of the level of of a labeled packet is completely independent of the level of
hierarchy. The processing is always based on the top label, without hierarchy. The processing is always based on the top label, without
regard for the possibility that some number of other labels may have regard for the possibility that some number of other labels may have
skipping to change at page 14, line 14 skipping to change at page 14, line 28
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.27). the notion of LSP Tunnel and the MPLS Hierarchy (section 3.27).
2.10. The Next Hop Label Forwarding Entry (NHLFE) 3.10. The Next Hop Label Forwarding Entry (NHLFE)
The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding 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 operation to perform on the packet's label stack; this is 2. 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
skipping to change at page 15, line 9 skipping to change at page 15, line 25
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.
If the packet's "next hop" is the current LSR, then the label stack If the packet's "next hop" is the current LSR, then the label stack
operation MUST be to "pop the stack". operation MUST be to "pop the stack".
2.11. Incoming Label Map (ILM) 3.11. Incoming Label Map (ILM)
The "Incoming Label Map" (ILM) maps each incoming label to a set of The "Incoming Label Map" (ILM) maps each incoming label to a set of
NHLFEs. It is used when forwarding packets that arrive as labeled NHLFEs. It is used when forwarding packets that arrive as labeled
packets. packets.
If the ILM maps a particular label to a set of NHLFEs that contains If the ILM maps a particular label to a set of NHLFEs that contains
more than one element, exactly one element of the set must be chosen more than one element, exactly one element of the set must be chosen
before the packet is forwarded. The procedures for choosing an before the packet is forwarded. The procedures for choosing an
element from the set are beyond the scope of this document. Having element from the set are beyond the scope of this document. Having
the ILM map a label to a set containing more than one NHLFE may be the ILM map a label to a set containing more than one NHLFE may be
useful if, e.g., it is desired to do load balancing over multiple useful if, e.g., it is desired to do load balancing over multiple
equal-cost paths. equal-cost paths.
2.12. FEC-to-NHLFE Map (FTN) 3.12. FEC-to-NHLFE Map (FTN)
The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used
when forwarding packets that arrive unlabeled, but which are to be when forwarding packets that arrive unlabeled, but which are to be
labeled before being forwarded. labeled before being forwarded.
If the FTN maps a particular label to a set of NHLFEs that contains If the FTN maps a particular label to a set of NHLFEs that contains
more than one element, exactly one element of the set must be chosen more than one element, exactly one element of the set must be chosen
before the packet is forwarded. The procedures for choosing an before the packet is forwarded. The procedures for choosing an
element from the set are beyond the scope of this document. Having element from the set are beyond the scope of this document. Having
the FTN map a label to a set containing more than one NHLFE may be the FTN map a label to a set containing more than one NHLFE may be
useful if, e.g., it is desired to do load balancing over multiple useful if, e.g., it is desired to do load balancing over multiple
equal-cost paths. equal-cost paths.
2.13. Label Swapping 3.13. Label Swapping
Label swapping is the use of the following procedures to forward a Label swapping is the use of the following procedures to forward a
packet. packet.
In order to forward a labeled packet, a LSR examines the label at the In order to forward a labeled packet, a LSR examines the label at the
top of the label stack. It uses the ILM to map this label to an top of the label stack. It uses the ILM to map this label to an
NHLFE. Using the information in the NHLFE, it determines where to NHLFE. Using the information in the NHLFE, it determines where to
forward the packet, and performs an operation on the packet's label forward the packet, and performs an operation on the packet's label
stack. It then encodes the new label stack into the packet, and stack. It then encodes the new label stack into the packet, and
forwards the result. forwards the result.
skipping to change at page 16, line 17 skipping to change at page 16, line 30
map this to an NHLFE. Using the information in the NHLFE, it map this to an NHLFE. Using the information in the NHLFE, it
determines where to forward the packet, and performs an operation on determines where to forward the packet, and performs an operation on
the packet's label stack. (Popping the label stack would, of course, the packet's label stack. (Popping the label stack would, of course,
be illegal in this case.) It then encodes the new label stack into be illegal in this case.) It then encodes the new label stack into
the packet, and forwards the result. the packet, and forwards the result.
IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT
HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE
DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE. DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE.
2.14. Scope and Uniqueness of Labels 3.14. Scope and Uniqueness of Labels
A given LSR Rd may bind label L1 to FEC F, and distribute that A given LSR Rd may bind label L1 to FEC F, and distribute that
binding to label distribution peer Ru1. Rd may also bind label L2 to binding to label distribution peer Ru1. Rd may also bind label L2 to
FEC F, and distribute that binding to label distribution peer Ru2. FEC F, and distribute that binding to label distribution peer Ru2.
Whether or not L1 == L2 is not determined by the architecture; this Whether or not L1 == L2 is not determined by the architecture; this
is a local matter. 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 label distribution peer Ru1. Rd may also bind label L to binding to label distribution peer Ru1. Rd may also bind label L to
FEC F2, and distribute that binding to label distribution peer Ru2. FEC F2, and distribute that binding to label distribution peer Ru2.
skipping to change at page 17, line 26 skipping to change at page 17, line 41
The question arises as to whether it is possible for an LSR to use 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 multiple per-platform label spaces, or to use multiple per-interface
label spaces for the same interface. This is not prohibited by the label spaces for the same interface. This is not prohibited by the
architecture. However, in such cases the LSR must have some means, architecture. However, in such cases the LSR must have some means,
not specified by the architecture, of determining, for a particular not specified by the architecture, of determining, for a particular
incoming label, which label space that label belongs to. For incoming label, which label space that label belongs to. For
example, [MPLS-SHIM] specifies that a different label space is used example, [MPLS-SHIM] specifies that a different label space is used
for unicast packets than for multicast packets, and uses a data link for unicast packets than for multicast packets, and uses a data link
layer codepoint to distinguish the two label spaces. layer codepoint to distinguish the two label spaces.
2.15. Label Switched Path (LSP), LSP Ingress, LSP Egress 3.15. Label Switched Path (LSP), LSP Ingress, LSP Egress
A "Label Switched Path (LSP) of level m" for a particular packet P is A "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
label stack, resulting in a label stack of depth m; label stack, resulting in a label stack of depth m;
skipping to change at page 19, line 5 skipping to change at page 19, line 14
label is a label corresponding to FEC F. label is a label corresponding to FEC F.
Consider the set of nodes which may be LSP ingress nodes for FEC F. Consider the set of nodes which may be LSP ingress nodes for FEC F.
Then there is an LSP for FEC F which begins with each of those nodes. Then there is an LSP for FEC F which begins with each of those nodes.
If a number of those LSPs have the same LSP egress, then one can If a number of those LSPs have the same LSP egress, then one can
consider the set of such LSPs to be a tree, whose root is the LSP consider the set of such LSPs to be a tree, whose root is the LSP
egress. (Since data travels along this tree towards the root, this egress. (Since data travels along this tree towards the root, this
may be called a multipoint-to-point tree.) We can thus speak of the may be called a multipoint-to-point tree.) We can thus speak of the
"LSP tree" for a particular FEC F. "LSP tree" for a particular FEC F.
2.16. Penultimate Hop Popping 3.16. Penultimate Hop Popping
Note that according to the definitions of section 2.15, if <R1, ..., Note that according to the definitions of section 3.15, if <R1, ...,
Rn> is a level m LSP for packet P, P may be transmitted from R[n-1] Rn> is a level m LSP for packet P, P may be transmitted from R[n-1]
to Rn with a label stack of depth m-1. That is, the label stack may to Rn with a label stack of depth m-1. That is, the label stack may
be popped at the penultimate LSR of the LSP, rather than at the LSP be popped at the penultimate LSR of the LSP, rather than at the LSP
Egress. Egress.
From an architectural perspective, this is perfectly appropriate. From an architectural perspective, this is perfectly appropriate.
The purpose of the level m label is to get the packet to Rn. Once The purpose of the level m label is to get the packet to Rn. Once
R[n-1] has decided to send the packet to Rn, the label no longer has R[n-1] has decided to send the packet to Rn, the label no longer has
any function, and need no longer be carried. any function, and need no longer be carried.
skipping to change at page 20, line 34 skipping to change at page 20, line 45
penultimate hop popping when so requested by its downstream label penultimate hop popping when so requested by its downstream label
distribution peer. distribution peer.
Initial label distribution protocol negotiations MUST allow each LSR Initial label distribution protocol negotiations MUST allow each LSR
to determine whether its neighboring LSRS are capable of popping the to determine whether its neighboring LSRS are capable of popping the
label stack. A LSR MUST NOT request a label distribution peer to pop label stack. A LSR MUST NOT request a label distribution peer to pop
the label stack unless it is capable of doing so. the label stack unless it is capable of doing so.
It may be asked whether the egress node can always interpret the top It may be asked whether the egress node can always interpret the top
label of a received packet properly if penultimate hop popping is label of a received packet properly if penultimate hop popping is
used. As long as the uniqueness and scoping rules of section 2.14 used. As long as the uniqueness and scoping rules of section 3.14
are obeyed, it is always possible to interpret the top label of a are obeyed, it is always possible to interpret the top label of a
received packet unambiguously. received packet unambiguously.
2.17. LSP Next Hop 3.17. LSP Next Hop
The LSP Next Hop for a particular labeled packet in a particular LSR The LSP Next Hop for a particular labeled packet in a particular LSR
is the LSR which is the next hop, as selected by the NHLFE entry used is the LSR which is the next hop, as selected by the NHLFE entry used
for forwarding that packet. for forwarding that packet.
The LSP Next Hop for a particular FEC is the next hop as selected by The LSP Next Hop for a particular FEC is the next hop as selected by
the NHLFE entry indexed by a label which corresponds to that FEC. the NHLFE entry indexed by a label which corresponds to that FEC.
Note that the LSP Next Hop may differ from the next hop which would Note that the LSP Next Hop may differ from the next hop which would
be chosen by the network layer routing algorithm. We will use the be chosen by the network layer routing algorithm. We will use the
term "L3 next hop" when we refer to the latter. term "L3 next hop" when we refer to the latter.
2.18. Invalid Incoming Labels 3.18. Invalid Incoming Labels
What should an LSR do if it receives a labeled packet with a What should an LSR do if it receives a labeled packet with a
particular incoming label, but has no binding for that label? It is 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 cannot be inferred from 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 3.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
be done in one of two ways: Independent LSP Control or Ordered LSP be done in one of two ways: Independent LSP Control or Ordered LSP
Control. Control.
In Independent LSP Control, each LSR, upon noting that it recognizes In Independent LSP Control, each LSR, upon noting that it recognizes
a particular FEC, makes an independent decision to bind a label to a particular FEC, makes an independent decision to bind a label to
that FEC and to distribute that binding to its label distribution that FEC and to distribute that binding to its label distribution
peers. This corresponds to the way that conventional IP datagram peers. This corresponds to the way that conventional IP datagram
skipping to change at page 22, line 24 skipping to change at page 22, line 38
control, since one cannot be sure that an LSP is not used until it is control, since one cannot be sure that an LSP is not used until it is
fully set up. fully set up.
This architecture allows the choice between independent control and This architecture allows the choice between independent control and
ordered control to be a local matter. Since the two methods ordered control to be a local matter. Since the two methods
interwork, a given LSR need support only one or the other. Generally interwork, a given LSR need support only one or the other. Generally
speaking, the choice of independent versus ordered control does not speaking, the choice of independent versus ordered control does not
appear to have any effect on the label distribution mechanisms which appear to have any effect on the label distribution mechanisms which
need to be defined. need to be defined.
2.20. Aggregation 3.20. Aggregation
One way of partitioning traffic into FECs is to create a separate FEC One way of partitioning traffic into FECs is to create a separate FEC
for each address prefix which appears in the routing table. However, for each address prefix which appears in the routing table. However,
within a particular MPLS domain, this may result in a set of FECs within a particular MPLS domain, this may result in a set of FECs
such that all traffic in all those FECs follows the same route. For such that all traffic in all those FECs follows the same route. For
example, a set of distinct address prefixes might all have the same example, a set of distinct address prefixes might all have the same
egress node, and label swapping might be used only to get the the egress node, and label swapping might be used only to get the the
traffic to the egress node. In this case, within the MPLS domain, traffic to the egress node. In this case, within the MPLS domain,
the union of those FECs is itself a FEC. This creates a choice: the union of those FECs is itself a FEC. This creates a choice:
should a distinct label be bound to each component FEC, or should a should a distinct label be bound to each component FEC, or should a
skipping to change at page 24, line 5 skipping to change at page 24, line 17
In any event, every LSR needs to know (by configuration) what In any event, every LSR needs to know (by configuration) what
granularity to use for labels that it assigns. Where ordered control granularity to use for labels that it assigns. Where ordered control
is used, this requires each node to know the granularity only for is used, this requires each node to know the granularity only for
FECs which leave the MPLS network at that node. For independent FECs which leave the MPLS network at that node. For independent
control, best results may be obtained by ensuring that all LSRs are control, best results may be obtained by ensuring that all LSRs are
consistently configured to know the granularity for each FEC. consistently configured to know the granularity for each FEC.
However, in many cases this may be done by using a single level of However, in many cases this may be done by using a single level of
granularity which applies to all FECs (such as "one label per IP granularity which applies to all FECs (such as "one label per IP
prefix in the forwarding table", or "one label per egress node"). prefix in the forwarding table", or "one label per egress node").
2.21. Route Selection 3.21. Route Selection
Route selection refers to the method used for selecting the LSP for a Route selection refers to the method used for selecting the LSP for a
particular FEC. The proposed MPLS protocol architecture supports two particular FEC. The proposed MPLS protocol architecture supports two
options for Route Selection: (1) hop by hop routing, and (2) explicit options for Route Selection: (1) hop by hop routing, and (2) explicit
routing. routing.
Hop by hop routing allows each node to independently choose the next Hop by hop routing allows each node to independently choose the next
hop for each FEC. This is the usual mode today in existing IP hop for each FEC. This is the usual mode today in existing IP
networks. A "hop by hop routed LSP" is an LSP whose route is selected networks. A "hop by hop routed LSP" is an LSP whose route is selected
using hop by hop routing. using hop by hop routing.
skipping to change at page 24, line 40 skipping to change at page 25, line 5
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. In 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.
The procedures for making use of explicit routes, either strict or The procedures for making use of explicit routes, either strict or
loose, are beyond the scope of this document. loose, are beyond the scope of this document.
2.22. Lack of Outgoing Label 3.22. Lack of Outgoing Label
When a labeled packet is traveling along an LSP, it may occasionally When a labeled packet is traveling along an LSP, it may occasionally
happen that it reaches an LSR at which the ILM does not map the happen that it reaches an LSR at which the ILM does not map the
packet's incoming label into an NHLFE, even though the incoming label packet's incoming label into an NHLFE, even though the incoming label
is itself valid. This can happen due to transient conditions, or due is itself valid. This can happen due to transient conditions, or due
to an error at the LSR which should be the packet's next hop. to an error at the LSR which should be the packet's next hop.
It is tempting in such cases to strip off the label stack and attempt It is tempting in such cases to strip off the label stack and attempt
to forward the packet further via conventional forwarding, based on to forward the packet further via conventional forwarding, based on
its network layer header. However, in general this is not a safe its network layer header. However, in general this is not a safe
skipping to change at page 25, line 15 skipping to change at page 25, line 28
- If the packet has been following an explicitly routed LSP, this - If the packet has been following an explicitly routed LSP, this
could result in a loop. could result in a loop.
- The packet's network header may not contain enough information to - The packet's network header may not contain enough information to
enable this particular LSR to forward it correctly. enable this particular LSR to forward it correctly.
Unless it can be determined (through some means outside the scope of Unless it can be determined (through some means outside the scope of
this document) that neither of these situations obtains, the only this document) that neither of these situations obtains, the only
safe procedure is to discard the packet. safe procedure is to discard the packet.
2.23. Time-to-Live (TTL) 3.23. Time-to-Live (TTL)
In conventional IP forwarding, each packet carries a "Time To Live" 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 26, line 24 skipping to change at page 26, line 37
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.24. Loop Control 3.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
skipping to change at page 27, line 5 skipping to change at page 27, line 17
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. All LSRs that may attach to 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 non-TTL LSP segments will therefore be required to support a common
technique for loop detection; however, use of the loop detection technique for loop detection; however, use of the loop detection
technique is optional. The loop detection technique is specified in technique is optional. The loop detection technique is specified in
[MPLS-ATM] and [MPLS-LDP]. [MPLS-ATM] and [MPLS-LDP].
2.25. Label Encodings 3.25. Label Encodings
In order to transmit a label stack along with the packet whose label 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.25.1. MPLS-specific Hardware and/or Software 3.25.1. MPLS-specific Hardware and/or Software
If one is using MPLS-specific hardware and/or software to forward 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 MPLS generic encapsulation is specified in [MPLS-SHIM]. The MPLS generic encapsulation is specified in [MPLS-SHIM].
2.25.2. ATM Switches as LSRs 3.25.2. ATM Switches as LSRs
It will be noted that MPLS forwarding procedures are similar to those 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 28, line 34 skipping to change at page 28, line 48
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.26, this enables us to do label merging, without in section 3.26, this enables us to do label merging, without
running into any cell interleaving problems, on ATM switches 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 16-bit VCI values to each ATM switch such that no assigning 16-bit VCI values to each ATM switch such that no
single VCI value is assigned to two different switches. (If an single VCI value is assigned to two different switches. (If an
adequate number of such values could be assigned to each adequate number of such values could be assigned to each
switch, it would be possible to also treat the VCI value as the switch, it would be possible to also treat the VCI value as the
second label in the stack.) 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.25.3. Interoperability among Encoding Techniques 3.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 29, line 35 skipping to change at page 30, line 5
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.26. Label Merging 3.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
skipping to change at page 30, line 36 skipping to change at page 31, line 5
particular FEC. 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.26.1. Non-merging LSRs 3.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; a label distribution use such technologies for MPLS forwarding; a label distribution
protocol can be used as the "signalling protocol" for setting up the protocol can be used as the "signalling protocol" for setting up the
cross-connect tables. cross-connect tables.
skipping to change at page 31, line 17 skipping to change at page 31, line 34
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.26.2. Labels for Merging and Non-Merging LSRs 3.26.2. Labels for Merging and Non-Merging LSRs
An upstream LSR which supports label merging needs to be sent only 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 32, line 5 skipping to change at page 32, line 16
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.26.3. Merge over ATM 3.26.3. Merge over ATM
2.26.3.1. Methods of Eliminating Cell Interleave 3.26.3.1. Methods of Eliminating Cell Interleave
There are several methods that can be used to eliminate the cell 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 VCIs within the VP. distinguished by using different VCIs within the VP.
skipping to change at page 32, line 40 skipping to change at page 33, line 5
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.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge 3.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge
The interoperation of the various forms of merging over ATM is most 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 33, line 35 skipping to change at page 34, line 5
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.27. Tunnels and Hierarchy 3.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.27.1. Hop-by-Hop Routed Tunnel 3.27.1. Hop-by-Hop Routed Tunnel
If a Tunneled Packet follows the Hop-by-hop path from Ru to Rd, we 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.27.2. Explicitly Routed Tunnel 3.27.2. Explicitly Routed Tunnel
If a Tunneled Packet travels from Ru to Rd over a path other than the 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.27.3. LSP Tunnels 3.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 35, line 5 skipping to change at page 35, line 12
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.27.4. Hierarchy: LSP Tunnels within LSPs 3.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 35, line 28 skipping to change at page 35, line 35
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.27.5. Label Distribution Peering and Hierarchy 3.27.5. Label Distribution Peering and Hierarchy
Suppose that packet P travels along a Level 1 LSP <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 label R22, R3>. From the perspective of the Level 2 LSP, R2's label
distribution peer is R21. From the perspective of the Level 1 LSP, distribution peer is R21. From the perspective of the Level 1 LSP,
R2's label distribution peers are R1 and R3. One can have label R2's label distribution peers are R1 and R3. One can have label
distribution peers at each layer of hierarchy. We will see in distribution peers at each layer of hierarchy. We will see in
sections 3.6 and 3.7 some ways to make use of this hierarchy. Note sections 4.6 and 4.7 some ways to make use of this hierarchy. Note
that in this example, R2 and R21 must be IGP neighbors, but R2 and R3 that in this example, R2 and R21 must be IGP neighbors, but R2 and R3
need not be. need not be.
When two LSRs are IGP neighbors, we will refer to them as "local When two LSRs are IGP neighbors, we will refer to them as "local
label distribution peers". When two LSRs may be label distribution label distribution peers". When two LSRs may be label distribution
peers, but are not IGP neighbors, we will refer to them as "remote peers, but are not IGP neighbors, we will refer to them as "remote
label distribution peers". In the above example, R2 and R21 are label distribution peers". In the above example, R2 and R21 are
local label distribution peers, but R2 and R3 are remote label local label distribution peers, but R2 and R3 are remote label
distribution peers. distribution peers.
skipping to change at page 36, line 18 skipping to change at page 36, line 26
1. Explicit Peering 1. Explicit Peering
In explicit peering, one distributes labels to a peer by In explicit peering, one distributes labels to a peer by
sending label distribution protocol messages which are sending label distribution protocol messages which are
addressed to the peer, exactly as one would do for local label addressed to the peer, exactly as one would do for local label
distribution peers. This technique is most useful when the distribution peers. This technique is most useful when the
number of remote label distribution peers is small, or the number of remote label distribution peers is small, or the
number of higher level label bindings is large, or the remote number of higher level label bindings is large, or the remote
label distribution peers are in distinct routing areas or label distribution peers are in distinct routing areas or
domains. Of course, one needs to know which labels to domains. Of course, one needs to know which labels to
distribute to which peers; this is addressed in section 3.1.2. distribute to which peers; this is addressed in section 4.1.2.
Examples of the use of explicit peering is found in sections Examples of the use of explicit peering is found in sections
3.2.1 and 3.6. 4.2.1 and 4.6.
2. Implicit Peering 2. Implicit Peering
In Implicit Peering, one does not send label distribution In Implicit Peering, one does not send label distribution
protocol messages which are addressed to one's peer. Rather, protocol messages which are addressed to one's peer. Rather,
to distribute higher level labels to ones remote label to distribute higher level labels to ones remote label
distribution peers, one encodes a higher level label as an distribution peers, one encodes a higher level label as an
attribute of a lower level label, and then distributes the attribute of a lower level label, and then distributes the
lower level label, along with this attribute, to one's local lower level label, along with this attribute, to one's local
label distribution peers. The local label distribution peers label distribution peers. The local label distribution peers
skipping to change at page 36, line 45 skipping to change at page 37, line 6
This technique is most useful when the number of remote label This technique is most useful when the number of remote label
distribution peers is large. Implicit peering does not require distribution peers is large. Implicit peering does not require
an n-square peering mesh to distribute labels to the remote an n-square peering mesh to distribute labels to the remote
label distribution peers because the information is piggybacked label distribution peers because the information is piggybacked
through the local label distribution peering. However, through the local label distribution peering. However,
implicit peering requires the intermediate nodes to store implicit peering requires the intermediate nodes to store
information that they might not be directly interested in. information that they might not be directly 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. 4.3.
2.28. Label Distribution Protocol Transport 3.28. Label Distribution Protocol Transport
A label distribution protocol is used between nodes in an MPLS A label distribution protocol is used between nodes in an MPLS
network to establish and maintain the label bindings. In order for network to establish and maintain the label bindings. In order for
MPLS to operate correctly, label distribution information needs to be MPLS to operate correctly, label distribution information needs to be
transmitted reliably, and the label distribution protocol messages transmitted reliably, and the label distribution protocol messages
pertaining to a particular FEC need to be transmitted in sequence. pertaining to a particular FEC need to be transmitted in sequence.
Flow control is also desirable, as is the capability to carry Flow control is also desirable, as is the capability to carry
multiple label messages in a single datagram. multiple label messages in a single datagram.
One way to meet these goals is to use TCP as the underlying One way to meet these goals is to use TCP as the underlying
transport, as is done in [MPLS-LDP] and [MPLS-BGP]. transport, as is done in [MPLS-LDP] and [MPLS-BGP].
2.29. Why More than one Label Distribution Protocol? 3.29. Why More than one Label Distribution Protocol?
This architecture does not establish hard and fast rules for choosing This architecture does not establish hard and fast rules for choosing
which label distribution protocol to use in which circumstances. which label distribution protocol to use in which circumstances.
However, it is possible to point out some of the considerations. However, it is possible to point out some of the considerations.
2.29.1. BGP and LDP 3.29.1. BGP and LDP
In many scenarios, it is desirable to bind labels to FECs which can In many scenarios, it is desirable to bind labels to FECs which can
be identified with routes to address prefixes (see section 3.1). If be identified with routes to address prefixes (see section 4.1). If
there is a standard, widely deployed routing algorithm which there is a standard, widely deployed routing algorithm which
distributes those routes, it can be argued that label distribution is distributes those routes, it can be argued that label distribution is
best achieved by piggybacking the label distribution on the best achieved by piggybacking the label distribution on the
distribution of the routes themselves. distribution of the routes themselves.
For example, BGP distributes such routes, and if a BGP speaker needs For example, BGP distributes such routes, and if a BGP speaker needs
to also distribute labels to its BGP peers, using BGP to do the label to also distribute labels to its BGP peers, using BGP to do the label
distribution (see [MPLS-BGP]) has a number of advantages. In distribution (see [MPLS-BGP]) has a number of advantages. In
particular, it permits BGP route reflectors to distribute labels, particular, it permits BGP route reflectors to distribute labels,
thus providing a significant scalability advantage over using LDP to thus providing a significant scalability advantage over using LDP to
distribute labels between BGP peers. distribute labels between BGP peers.
2.29.2. Labels for RSVP Flowspecs 3.29.2. Labels for RSVP Flowspecs
When RSVP is used to set up resource reservations for particular When RSVP is used to set up resource reservations for particular
flows, it can be desirable to label the packets in those flows, so flows, it can be desirable to label the packets in those flows, so
that the RSVP filterspec does not need to be applied at each hop. It that the RSVP filterspec does not need to be applied at each hop. It
can be argued that having RSVP distribute the labels as part of its can be argued that having RSVP distribute the labels as part of its
path/reservation setup process is the most efficient method of path/reservation setup process is the most efficient method of
distributing labels for this purpose. distributing labels for this purpose.
2.29.3. Labels for Explicitly Routed LSPs 3.29.3. Labels for Explicitly Routed LSPs
In some applications of MPLS, particularly those related to traffic In some applications of MPLS, particularly those related to traffic
engineering, it is desirable to set up an explicitly routed path, engineering, it is desirable to set up an explicitly routed path,
from ingress to egress. It is also desirable to apply resource from ingress to egress. It is also desirable to apply resource
reservations along that path. reservations along that path.
One can imagine two approaches to this: One can imagine two approaches to this:
- Start with an existing protocol that is used for setting up - Start with an existing protocol that is used for setting up
resource reservations, and extend it to support explicit routing resource reservations, and extend it to support explicit routing
and label distribution. and label distribution.
- Start with an existing protocol that is used for label - Start with an existing protocol that is used for label
distribution, and extend it to support explicit routing and distribution, and extend it to support explicit routing and
resource reservations. resource reservations.
The first approach has given rise to the protocol specified in The first approach has given rise to the protocol specified in
[MPLS-RSVP-TUNNELS], the second to the approach specified in [MPLS- [MPLS-RSVP-TUNNELS], the second to the approach specified in [MPLS-
CR-LDP]. CR-LDP].
2.30. Multicast 3.30. Multicast
This section is for further study This section is for further study
3. Some Applications of MPLS 4. Some Applications of MPLS
3.1. MPLS and Hop by Hop Routed Traffic 4.1. MPLS and Hop by Hop Routed Traffic
A number of uses of MPLS require that packets with a certain label be A number of uses of MPLS require that packets with a certain label be
forwarded along the same hop-by-hop routed path that would be used 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 for forwarding a packet with a specified address in its network layer
destination address field. destination address field.
3.1.1. Labels for Address Prefixes 4.1.1. Labels for Address Prefixes
In general, router R determines the next hop for packet P by finding 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.
Note that a packet P may be assigned to FEC F, and FEC F may be Note that a packet P may be assigned to FEC F, and FEC F may be
identified with address prefix X, even if P's destination address identified with address prefix X, even if P's destination address
does not match X. does not match X.
3.1.2. Distributing Labels for Address Prefixes 4.1.2. Distributing Labels for Address Prefixes
3.1.2.1. Label Distribution Peers for an Address Prefix 4.1.2.1. Label Distribution Peers for an Address Prefix
LSRs R1 and R2 are considered to be label distribution peers for LSRs R1 and R2 are considered to be label distribution peers for
address prefix X if and only if one of the following conditions address prefix X if and only if one of the following conditions
holds: 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
of R1 in that instance of that IGP of R1 in that instance of that IGP
2. R1's route to X is a route which it learned about by some 2. R1's route to X is a route which it learned about by some
skipping to change at page 39, line 40 skipping to change at page 39, line 44
R2 is a BGP peer of R1 R2 is a BGP peer of R1
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 label distribution address prefix is distributed via an IGP, the label distribution
peers for that address prefix are the IGP neighbors. If the route to peers for that address prefix are the IGP neighbors. If the route to
a particular address prefix is distributed via BGP, the label a particular address prefix is distributed via BGP, the label
distribution peers for that address prefix are the BGP peers. In distribution peers for that address prefix are the BGP peers. In
other cases of LSP tunneling, the tunnel endpoints are label other cases of LSP tunneling, the tunnel endpoints are label
distribution peers. distribution peers.
3.1.2.2. Distributing Labels 4.1.2.2. Distributing Labels
In order to use MPLS for the forwarding of packets according to the In order to use MPLS for the forwarding of packets according to the
hop-by-hop route corresponding to any address prefix, each LSR MUST: 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 a label distribution 2. for each such address prefix X, use a label distribution
protocol to distribute the binding of a label to X to each of protocol to distribute the binding of a label to X to each of
its label distribution peers for X. its label distribution peers for X.
skipping to change at page 40, line 24 skipping to change at page 40, line 31
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.
3.1.3. Using the Hop by Hop path as the LSP 4.1.3. Using the Hop by Hop path as the LSP
If the hop-by-hop path that packet P needs to follow is <R1, ..., If the hop-by-hop path that packet P needs to follow is <R1, ...,
Rn>, then <R1, ..., Rn> can be an LSP as long as: Rn>, then <R1, ..., Rn> can be an LSP as long as:
1. there is a single address prefix X, such that, for all i, 1. there is a single address prefix X, such that, for all i,
1<=i<n, X is the longest match in Ri's routing table for P's 1<=i<n, X is the longest match in Ri's routing table for P's
destination address; destination address;
2. for all i, 1<i<n, Ri has assigned a label to X and distributed 2. for all i, 1<i<n, Ri has assigned a label to X and distributed
that label to R[i-1]. that label to R[i-1].
Note that a packet's LSP can extend only until it encounters a router Note that a packet's LSP can extend only until it encounters a router
whose forwarding tables have a longer best match address prefix for whose forwarding tables have a longer best match address prefix for
the packet's destination address. At that point, the LSP must end and the packet's destination address. At that point, the LSP must end and
the best match algorithm must be performed again. the best match algorithm must be performed again.
Suppose, for example, that packet P, with destination address Suppose, for example, that packet P, with destination address
10.2.153.178 needs to go from R1 to R2 to R3. Suppose also that R2 10.2.153.178 needs to go from R1 to R2 to R3. Suppose also that R2
advertises address prefix 10.2/16 to R1, but R3 advertises advertises address prefix 10.2/16 to R1, but R3 advertises
10.2.153/22, 10.2.154/22, and 10.2/16 to R2. That is, R2 is 10.2.153/23, 10.2.154/23, and 10.2/16 to R2. That is, R2 is
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 4.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. R has an address Y, such that X is the address prefix in R'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
skipping to change at page 41, line 31 skipping to change at page 41, line 35
1. R1's next hop for X is R2, and R1 and R2 are not label 1. R1's next hop for X is R2, and R1 and R2 are not label
distribution peers with respect to X (perhaps because R2 does distribution peers with respect to X (perhaps because R2 does
not support MPLS), or 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 4.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,
sees that labeled packet P must be forwarded next to Rd, but that Rd sees that labeled packet P must be forwarded next to Rd, but that Rd
has distributed a binding of Implicit NULL to the corresponding has distributed a binding of Implicit NULL to the corresponding
address prefix, then instead of replacing the value of the label on address prefix, then instead of replacing the value of the label on
top of the label stack, Ru pops the label stack, and then forwards top of the label stack, Ru pops the label stack, and then forwards
the resulting packet to Rd. the resulting packet to Rd.
LSR Rd distributes a binding between Implicit NULL and an address LSR Rd distributes a binding between Implicit NULL and an address
prefix X to LSR Ru if and only if: prefix X to LSR Ru if and only if:
1. the rules of Section 3.1.2 indicate that Rd distributes to Ru a 1. the rules of Section 4.1.2 indicate that Rd distributes to Ru a
label binding for X, and label binding for X, and
2. Rd knows that Ru can support the Implicit NULL label (i.e., 2. Rd knows that Ru can support the Implicit NULL label (i.e.,
that it can pop the label stack), and that it can pop the label stack), and
3. Rd is an LSP Egress (not proxy egress) for X. 3. Rd is an LSP Egress (not proxy egress) for X.
This causes the penultimate LSR on a LSP to pop the label stack. This This causes the penultimate LSR on a LSP to pop the label stack. This
is quite appropriate; if the LSP Egress is an MPLS Egress for X, then is quite appropriate; if the LSP Egress is an MPLS Egress for X, then
if the penultimate LSR does not pop the label stack, the LSP Egress if the penultimate LSR does not pop the label stack, the LSP Egress
will need to look up the label, pop the label stack, and then look up will need to look up the label, pop the label stack, and then look up
the next label (or look up the L3 address, if no more labels are the next label (or look up the L3 address, if no more labels are
present). By having the penultimate LSR pop the label stack, the LSP present). By having the penultimate LSR pop the label stack, the LSP
Egress is saved the work of having to look up two labels in order to Egress is saved the work of having to look up two labels in order to
make its forwarding decision. make its forwarding decision.
skipping to change at page 42, line 23 skipping to change at page 42, line 30
make its forwarding decision. make its forwarding decision.
However, if the penultimate LSR is an ATM switch, it may not have the However, if the penultimate LSR is an ATM switch, it may not have the
capability to pop the label stack. Hence a binding of Implicit NULL capability to pop the label stack. Hence a binding of Implicit NULL
may be distributed only to LSRs which can support that function. may be distributed only to LSRs which can support that function.
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 4.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 for all such FECs; it is not necessary to by using a single label for all such FECs; it is not necessary to
have a distinct label for each FEC. If (and only if) the following have a distinct label for each FEC. If (and only if) 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
skipping to change at page 44, line 7 skipping to change at page 44, line 13
distinct labels to X1 and X2 while Rd assigns just one label to the distinct labels to X1 and X2 while Rd assigns just one label to the
both of them. This just means that R1 will map different incoming both of them. This just means that R1 will map different incoming
labels to the same outgoing label, an ordinary occurrence. labels to the same outgoing label, an ordinary occurrence.
Similarly, if Rd assigns distinct labels to X1 and X2, but Ru assigns Similarly, if Rd assigns distinct labels to X1 and X2, but Ru assigns
to them both the label corresponding to the address of their LSP to them both the label corresponding to the address of their LSP
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 4.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
[MPLS-TRFENG]. [MPLS-TRFENG].
3.2.1. Explicitly Routed LSP Tunnels 4.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 can be done in support of policy routing, ordinarily follow. This can be done in support of policy routing,
or in support of traffic engineering. The explicit route may be a or in support of traffic engineering. The explicit route may be a
configured one, or it may be determined dynamically by some means, configured one, or it may be determined dynamically by some means,
e.g., by constraint-based routing. 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
skipping to change at page 45, line 5 skipping to change at page 45, line 5
If the transmit endpoint of the tunnel wishes to put a labeled packet If the transmit endpoint of the tunnel wishes to put a labeled packet
into the tunnel, it must first replace the label value at the top of into the tunnel, it must first replace the label value at the top of
the stack with a label value that was distributed to it by the the stack with a label value that was distributed to it by the
tunnel's receive endpoint. Then it must push on the label which tunnel's receive endpoint. Then it must push on the label which
corresponds to the tunnel itself, as distributed to it by the next corresponds to the tunnel itself, as distributed to it by the next
hop along the tunnel. To allow this, the tunnel endpoints should be hop along the tunnel. To allow this, the tunnel endpoints should be
explicit label distribution peers. The label bindings they need to explicit label distribution peers. The label bindings they need to
exchange are of no interest to the LSRs along the tunnel. exchange are of no interest to the LSRs along the tunnel.
3.3. Label Stacks and Implicit Peering 4.3. Label Stacks and Implicit Peering
Suppose a particular LSR Re is an LSP proxy egress for 10 address Suppose a particular LSR Re is an LSP proxy egress for 10 address
prefixes, and it reaches each address prefix through a distinct prefixes, and it reaches each address prefix through a distinct
interface. interface.
One could assign a single label to all 10 address prefixes. Then Re One could assign a single label to all 10 address prefixes. Then Re
is an LSP egress for all 10 address prefixes. This ensures that is an LSP egress for all 10 address prefixes. This ensures that
packets for all 10 address prefixes get delivered to Re. However, Re packets for all 10 address prefixes get delivered to Re. However, Re
would then have to look up the network layer address of each such would then have to look up the network layer address of each such
packet in order to choose the proper interface to send the packet on. packet in order to choose the proper interface to send the packet on.
skipping to change at page 46, line 6 skipping to change at page 46, line 6
Note that although the label value bound to X may be different at Note that although the label value bound to X may be different at
each hop along the LSP, the stack attribute value is passed each hop along the LSP, the stack attribute value is passed
unchanged, and is set by the LSP proxy egress. unchanged, and is set by the LSP proxy egress.
Thus the LSP proxy egress for X becomes an "implicit peer" with each Thus the LSP proxy egress for X becomes an "implicit peer" with each
other LSR in the routing area or domain. In this case, explicit other LSR in the routing area or domain. In this case, explicit
peering would be too unwieldy, because the number of peers would peering would be too unwieldy, because the number of peers would
become too large. become too large.
3.4. MPLS and Multi-Path Routing 4.4. MPLS and Multi-Path Routing
If an LSR supports multiple routes for a particular stream, then it If an LSR supports multiple routes for a particular stream, then it
may assign multiple labels to the stream, one for each route. Thus may assign multiple labels to the stream, one for each route. Thus
the reception of a second label binding from a particular neighbor the reception of a second label binding from a particular neighbor
for a particular address prefix should be taken as meaning that for a particular address prefix should be taken as meaning that
either label can be used to represent that address prefix. either label can be used to represent that address prefix.
If multiple label bindings for a particular address prefix are If multiple label bindings for a particular address prefix are
specified, they may have distinct attributes. specified, they may have distinct attributes.
3.5. LSP Trees as Multipoint-to-Point Entities 4.5. LSP Trees as Multipoint-to-Point Entities
Consider the case of packets P1 and P2, each of which has a Consider the case of packets P1 and P2, each of which has a
destination address whose longest match, throughout a particular destination address whose longest match, throughout a particular
routing domain, is address prefix X. Suppose that the Hop-by-hop routing domain, is address prefix X. Suppose that the Hop-by-hop
path for P1 is <R1, R2, R3>, and the Hop-by-hop path for P2 is <R4, path for P1 is <R1, R2, R3>, and the Hop-by-hop path for P2 is <R4,
R2, R3>. Let's suppose that R3 binds label L3 to X, and distributes R2, R3>. Let's suppose that R3 binds label L3 to X, and distributes
this binding to R2. R2 binds label L2 to X, and distributes this this binding to R2. R2 binds label L2 to X, and distributes this
binding to both R1 and R4. When R2 receives packet P1, its incoming binding to both R1 and R4. When R2 receives packet P1, its incoming
label will be L2. R2 will overwrite L2 with L3, and send P1 to R3. label will be L2. R2 will overwrite L2 with L3, and send P1 to R3.
When R2 receives packet P2, its incoming label will also be L2. R2 When R2 receives packet P2, its incoming label will also be L2. R2
skipping to change at page 46, line 42 skipping to change at page 46, line 42
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.25.2) can be Alternatively, if the SVP Multipoint Encoding (section 3.25.2) can be
used, the LSPs can be realized as multipoint-to-point SVPs. used, the LSPs can be realized as multipoint-to-point SVPs.
3.6. LSP Tunneling between BGP Border Routers 4.6. LSP Tunneling between BGP Border Routers
Consider the case of an Autonomous System, A, which carries transit 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,
the "route distribution load" on those routers is significantly the "route distribution load" on those routers is significantly
reduced. However, there must be some means of ensuring that the reduced. However, there must be some means of ensuring that the
transit traffic will be delivered from Border Router to Border Router transit traffic will be delivered from Border Router to Border Router
skipping to change at page 49, line 5 skipping to change at page 49, line 5
- B3 distributes routes to B2 (using EBGP), optionally assigning - B3 distributes routes to B2 (using EBGP), optionally assigning
labels to address prefixes; labels to address prefixes;
- B2 redistributes those routes to B1 (using IBGP), indicating that - B2 redistributes those routes to B1 (using IBGP), indicating that
the BGP next hop for each such route is B3. If B3 has assigned the BGP next hop for each such route is B3. If B3 has assigned
labels to address prefixes, B2 passes these labels along, labels to address prefixes, B2 passes these labels along,
unchanged, to B1. unchanged, to B1.
- The IGP of AS1 has a host route for B3. - The IGP of AS1 has a host route for B3.
3.7. Other Uses of Hop-by-Hop Routed LSP Tunnels 4.7. Other Uses of Hop-by-Hop Routed LSP Tunnels
The use of Hop-by-Hop Routed LSP Tunnels is not restricted to tunnels The use of Hop-by-Hop Routed LSP Tunnels is not restricted to tunnels
between BGP Next Hops. Any situation in which one might otherwise between BGP Next Hops. Any situation in which one might otherwise
have used an encapsulation tunnel is one in which it is appropriate have used an encapsulation tunnel is one in which it is appropriate
to use a Hop-by-Hop Routed LSP Tunnel. Instead of encapsulating the to use a Hop-by-Hop Routed LSP Tunnel. Instead of encapsulating the
packet with a new header whose destination address is the address of packet with a new header whose destination address is the address of
the tunnel's receive endpoint, the label corresponding to the address the tunnel's receive endpoint, the label corresponding to the address
prefix which is the longest match for the address of the tunnel's prefix which is the longest match for the address of the tunnel's
receive endpoint is pushed on the packet's label stack. The packet receive endpoint is pushed on the packet's label stack. The packet
which is sent into the tunnel may or may not already be labeled. which is sent into the tunnel may or may not already be labeled.
If the transmit endpoint of the tunnel wishes to put a labeled packet If the transmit endpoint of the tunnel wishes to put a labeled packet
into the tunnel, it must first replace the label value at the top of into the tunnel, it must first replace the label value at the top of
the stack with a label value that was distributed to it by the the stack with a label value that was distributed to it by the
tunnel's receive endpoint. Then it must push on the label which tunnel's receive endpoint. Then it must push on the label which
corresponds to the tunnel itself, as distributed to it by the next corresponds to the tunnel itself, as distributed to it by the next
hop along the tunnel. To allow this, the tunnel endpoints should be hop along the tunnel. To allow this, the tunnel endpoints should be
explicit label distribution peers. The label bindings they need to explicit label distribution peers. The label bindings they need to
exchange are of no interest to the LSRs along the tunnel. exchange are of no interest to the LSRs along the tunnel.
3.8. MPLS and Multicast 4.8. MPLS and Multicast
Multicast routing proceeds by constructing multicast trees. The tree Multicast routing proceeds by constructing multicast trees. The tree
along which a particular multicast packet must get forwarded depends along which a particular multicast packet must get forwarded depends
in general on the packet's source address and its destination in general on the packet's source address and its destination
address. Whenever a particular LSR is a node in a particular address. Whenever a particular LSR is a node in a particular
multicast tree, it binds a label to that tree. It then distributes multicast tree, it binds a label to that tree. It then distributes
that binding to its parent on the multicast tree. (If the node in that binding to its parent on the multicast tree. (If the node in
question is on a LAN, and has siblings on that LAN, it must also question is on a LAN, and has siblings on that LAN, it must also
distribute the binding to its siblings. This allows the parent to distribute the binding to its siblings. This allows the parent to
use a single label value when multicasting to all children on the use a single label value when multicasting to all children on the
LAN.) LAN.)
When a multicast labeled packet arrives, the NHLFE corresponding to When a multicast labeled packet arrives, the NHLFE corresponding to
the label indicates the set of output interfaces for that packet, as the label indicates the set of output interfaces for that packet, as
well as the outgoing label. If the same label encoding technique is well as the outgoing label. If the same label encoding technique is
used on all the outgoing interfaces, the very same packet can be sent used on all the outgoing interfaces, the very same packet can be sent
to all the children. to all the children.
4. Label Distribution Procedures (Hop-by-Hop) 5. Label Distribution Procedures (Hop-by-Hop)
In this section, we consider only label bindings that are used for 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.
4.1. The Procedures for Advertising and Using labels 5.1. The Procedures for Advertising and Using labels
There are a number of different procedures that may be used to There are a number of different procedures that may be used to
distribute label bindings. Some are executed by the downstream LSR, distribute label bindings. Some are executed by the downstream LSR,
and some 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.
skipping to change at page 50, line 38 skipping to change at page 50, line 38
- the NotAvailable Procedure, and - the NotAvailable Procedure, and
- the Release Procedure, and - the Release Procedure, and
- the labelUse Procedure. - the labelUse Procedure.
The MPLS architecture supports several variants of each procedure. The MPLS architecture supports several variants of each procedure.
However, the MPLS architecture does not support all possible However, the MPLS architecture does not support all possible
combinations of all possible variants. The set of supported combinations of all possible variants. The set of supported
combinations will be described in section 4.2, where the combinations will be described in section 5.2, where the
interoperability between different combinations will also be interoperability between different combinations will also be
discussed. discussed.
4.1.1. Downstream LSR: Distribution Procedure 5.1.1. Downstream LSR: Distribution Procedure
The Distribution Procedure is used by a downstream LSR to determine The Distribution Procedure is used by a downstream LSR to determine
when it should distribute a label binding for a particular address when it should distribute a label binding for a particular address
prefix to its label distribution peers. The architecture supports prefix to its label distribution peers. The architecture supports
four different distribution procedures. four different distribution procedures.
Irrespective of the particular procedure that is used, if a label Irrespective of the particular procedure that is used, if a label
binding for a particular address prefix has been distributed by a binding for a particular address prefix has been distributed by a
downstream LSR Rd to an upstream LSR Ru, and if at any time the downstream LSR Rd to an upstream LSR Ru, and if at any time the
attributes (as defined above) of that binding change, then Rd must attributes (as defined above) of that binding change, then Rd must
inform Ru of the new attributes. inform Ru of the new attributes.
If an LSR is maintaining multiple routes to a particular address If an LSR is maintaining multiple routes to a particular address
prefix, it is a local matter as to whether that LSR binds multiple prefix, it is a local matter as to whether that LSR binds multiple
labels to the address prefix (one per route), and hence distributes labels to the address prefix (one per route), and hence distributes
multiple bindings. multiple bindings.
4.1.1.1. PushUnconditional 5.1.1.1. PushUnconditional
Let Rd be an LSR. Suppose that: Let Rd be an LSR. Suppose that:
1. X is an address prefix in Rd's routing table 1. X is an address prefix in Rd's routing table
2. Ru is a label distribution peer of Rd with respect to X 2. Ru is a label distribution peer of Rd with respect to X
Whenever these conditions hold, Rd must bind a label to X and Whenever these conditions hold, Rd must bind a label to X and
distribute that binding to Ru. It is the responsibility of Rd to distribute that binding to Ru. It is the responsibility of Rd to
keep track of the bindings which it has distributed to Ru, and to keep track of the bindings which it has distributed to Ru, and to
make sure that Ru always has these bindings. make sure that Ru always has these bindings.
This procedure would be used by LSRs which are performing unsolicited This procedure would be used by LSRs which are performing unsolicited
downstream label assignment in the Independent LSP Control Mode. downstream label assignment in the Independent LSP Control Mode.
4.1.1.2. PushConditional 5.1.1.2. PushConditional
Let Rd be an LSR. Suppose that: Let Rd be an LSR. Suppose that:
1. X is an address prefix in Rd's routing table 1. X is an address prefix in Rd's routing table
2. Ru is a label distribution peer of Rd with respect to X 2. Ru is a label distribution peer of Rd with respect to X
3. Rd is either an LSP Egress or an LSP Proxy Egress for X, or 3. Rd is either an LSP Egress or an LSP Proxy Egress for X, or
Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and
Rn has bound a label to X and distributed that binding to Rd. Rn has bound a label to X and distributed that binding to Rd.
skipping to change at page 52, line 8 skipping to change at page 52, line 8
Whereas PushUnconditional causes the distribution of label bindings Whereas PushUnconditional causes the distribution of label bindings
for all address prefixes in the routing table, PushConditional causes for all address prefixes in the routing table, PushConditional causes
the distribution of label bindings only for those address prefixes the distribution of label bindings only for those address prefixes
for which one has received label bindings from one's LSP next hop, or for which one has received label bindings from one's LSP next hop, or
for which one does not have an MPLS-capable L3 next hop. for which one does not have an MPLS-capable L3 next hop.
This procedure would be used by LSRs which are performing unsolicited This procedure would be used by LSRs which are performing unsolicited
downstream label assignment in the Ordered LSP Control Mode. downstream label assignment in the Ordered LSP Control Mode.
4.1.1.3. PulledUnconditional 5.1.1.3. PulledUnconditional
Let Rd be an LSR. Suppose that: Let Rd be an LSR. Suppose that:
1. X is an address prefix in Rd's routing table 1. X is an address prefix in Rd's routing table
2. Ru is a label distribution peer of Rd with respect to X 2. Ru is a label distribution peer of Rd with respect to X
3. Ru has explicitly requested that Rd bind a label to X and 3. Ru has explicitly requested that Rd bind a label to X and
distribute the binding to Ru distribute the binding to Ru
skipping to change at page 52, line 32 skipping to change at page 52, line 32
that it cannot provide a binding at this time. that it cannot provide a binding at this time.
If Rd has already distributed a binding for address prefix X to Ru, If Rd has already distributed a binding for address prefix X to Ru,
and it receives a new request from Ru for a binding for address and it receives a new request from Ru for a binding for address
prefix X, it will bind a second label, and distribute the new binding prefix X, it will bind a second label, and distribute the new binding
to Ru. The first label binding remains in effect. to Ru. The first label binding remains in effect.
This procedure would be used by LSRs performing downstream-on-demand This procedure would be used by LSRs performing downstream-on-demand
label distribution using the Independent LSP Control Mode. label distribution using the Independent LSP Control Mode.
4.1.1.4. PulledConditional 5.1.1.4. PulledConditional
Let Rd be an LSR. Suppose that: Let Rd be an LSR. Suppose that:
1. X is an address prefix in Rd's routing table 1. X is an address prefix in Rd's routing table
2. Ru is a label distribution peer of Rd with respect to X 2. Ru is a label distribution peer of Rd with respect to X
3. Ru has explicitly requested that Rd bind a label to X and 3. Ru has explicitly requested that Rd bind a label to X and
distribute the binding to Ru distribute the binding to Ru
skipping to change at page 53, line 20 skipping to change at page 53, line 20
until such time as it has receiving a binding from Rn. until such time as it has receiving a binding from Rn.
If Rd has distributed a label binding for address prefix X to Ru, and If Rd has distributed a label binding for address prefix X to Ru, and
at some later time, any attribute of the label binding changes, then at some later time, any attribute of the label binding changes, then
Rd must redistribute the label binding to Ru, with the new attribute. Rd must redistribute the label binding to Ru, with the new attribute.
It must do this even though Ru does not issue a new Request. It must do this even though Ru does not issue a new Request.
This procedure would be used by LSRs that are performing downstream- This procedure would be used by LSRs that are performing downstream-
on-demand label allocation in the Ordered LSP Control Mode. on-demand label allocation in the Ordered LSP Control Mode.
In section 4.2, we will discuss how to choose the particular In section 5.2, we will discuss how to choose the particular
procedure to be used at any given time, and how to ensure procedure to be used at any given time, and how to ensure
interoperability among LSRs that choose different procedures. interoperability among LSRs that choose different procedures.
4.1.2. Upstream LSR: Request Procedure 5.1.2. Upstream LSR: Request Procedure
The Request Procedure is used by the upstream LSR for an address The Request Procedure is used by the upstream LSR for an address
prefix to determine when to explicitly request that the downstream prefix to determine when to explicitly request that the downstream
LSR bind a label to that prefix and distribute the binding. There LSR bind a label to that prefix and distribute the binding. There
are three possible procedures that can be used. are three possible procedures that can be used.
4.1.2.1. RequestNever 5.1.2.1. RequestNever
Never make a request. This is useful if the downstream LSR uses the Never make a request. This is useful if the downstream LSR uses the
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 unsolicited downstream This procedure would be used by an LSR when unsolicited downstream
label distribution and Liberal Label Retention Mode are being used. label distribution and Liberal Label Retention Mode are being used.
4.1.2.2. RequestWhenNeeded 5.1.2.2. RequestWhenNeeded
Make a request whenever the L3 next hop to the address prefix Make a request whenever the L3 next hop to the address prefix
changes, or when a new address prefix is learned, and one doesn't changes, or when a new address prefix is learned, and one doesn't
already have a label binding from that next hop for the given address already have a label binding from that next hop for the given address
prefix. 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 5.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 5.1.2.2). If
Ru is not capable of being an LSP ingress, it may issue a request Ru is not capable of being an LSP ingress, it may issue a request
only when it receives a request from upstream. only when it receives a request from upstream.
If Rd receives such a request from Ru, for an address prefix for 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 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 is 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 5.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, because it has no next hop it cannot provide a binding at this time, because it has no next hop
for X, then the NotAvailable procedure determines how Ru responds. for X, then the NotAvailable procedure determines how Ru responds.
There are two possible procedures governing Ru's behavior: There are two possible procedures governing Ru's behavior:
4.1.3.1. RequestRetry 5.1.3.1. RequestRetry
Ru should issue the request again at a later time. That is, the 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 5.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 unsolicited downstream label PushConditional procedure, i.e., if unsolicited downstream label
distribution is used. distribution is used.
Note that if Rd replies that it cannot provide a binding to Ru, 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 because of some error condition, rather than because Rd has no next
hop, the behavior of Ru will be governed by the error recovery hop, the behavior of Ru will be governed by the error recovery
conditions of the label distribution protocol, rather than by the conditions of the label distribution protocol, rather than by the
NotAvailable procedure. NotAvailable procedure.
4.1.4. Upstream LSR: Release Procedure 5.1.4. Upstream LSR: Release Procedure
Suppose that Rd is an LSR which has bound a label to address prefix 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 Ru 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 5.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 5.1.4.2. NoReleaseOnChange
Ru should maintain the binding, so that it can use it again Ru should maintain the binding, so that it can use it again
immediately if Rd later becomes Ru's L3 next hop for X. This immediately if Rd later becomes Ru's L3 next hop for X. This
procedure would be used to implement Liberal Label Retention Mode. procedure would be used to implement Liberal Label Retention Mode.
4.1.5. Upstream LSR: labelUse Procedure 5.1.5. Upstream LSR: labelUse Procedure
Suppose Ru is an LSR which has received label binding L for address Suppose Ru is an LSR which has received label binding L for address
prefix X from LSR Rd, and Ru is upstream of Rd with respect to X, and prefix X from LSR Rd, and Ru is upstream of Rd with respect to X, and
in fact Rd is Ru's L3 next hop for X. in fact Rd is Ru's L3 next hop for X.
Ru will make use of the binding if Rd is Ru's L3 next hop for X. If, 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 two procedures which Ru may use: There are two procedures which Ru may use:
4.1.5.1. UseImmediate 5.1.5.1. UseImmediate
Ru may put the binding into use immediately. At any time when Ru has 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 loop also be Ru's LSP next hop for X. This procedure is used when loop
detection is not in use. detection is not in use.
4.1.5.2. UseIfLoopNotDetected 5.1.5.2. UseIfLoopNotDetected
This procedure is the same as UseImmediate, unless Ru has detected a This procedure is the same as UseImmediate, unless Ru has detected a
loop in the LSP. If a loop has been detected, Ru will discontinue loop in the LSP. If a loop has been detected, Ru will discontinue
the use of label L for forwarding packets to Rd. the use of label L for forwarding packets to Rd.
This procedure is used when loop detection is in use. This procedure is used when loop detection 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 5.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 required that the unbinding of L from X be distributed by Rd to It is required that the unbinding of L from X be distributed by Rd to
a LSR Ru before Rd distributes to Ru any new binding of L to any a LSR Ru before Rd distributes to Ru any new binding of L to any
other address prefix Y, where X != Y. If Ru were to learn of the new other address prefix Y, where X != Y. If Ru were to learn of the new
skipping to change at page 57, line 11 skipping to change at page 57, line 11
As long as the relevant label distribution adjacency remains in As long as the relevant label distribution adjacency remains in
place, label bindings that are withdrawn must always be withdrawn place, label bindings that are withdrawn must always be withdrawn
explicitly. If a second label is bound to an address prefix, the explicitly. If a second label is bound to an address prefix, the
result is not to implicitly withdraw the first label, but to bind result is not to implicitly withdraw the first label, but to bind
both labels; this is needed to support multi-path routing. If a both labels; this is needed to support multi-path routing. If a
second address prefix is bound to a label, the result is not to second address prefix is bound to a label, the result is not to
implicitly withdraw the binding of that label to the first address implicitly withdraw the binding of that label to the first address
prefix, but to use that label for both address prefixes. prefix, but to use that label for both address prefixes.
4.2. MPLS Schemes: Supported Combinations of Procedures 5.2. MPLS Schemes: Supported Combinations of Procedures
Consider two LSRs, Ru and Rd, which are label distribution peers with Consider two LSRs, Ru and Rd, which are label distribution peers with
respect to some set of address prefixes, where Ru is the upstream respect to some set of address prefixes, where Ru is the upstream
peer and Rd is the downstream peer. peer and Rd is the downstream peer.
The MPLS scheme which governs the interaction of Ru and Rd can be The MPLS scheme which governs the interaction of Ru and Rd can be
described as a quintuple of procedures: <Distribution Procedure, described as a quintuple of procedures: <Distribution Procedure,
Request Procedure, NotAvailable Procedure, Release Procedure, Request Procedure, NotAvailable Procedure, Release Procedure,
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. Schemes for LSRs that Support Label Merging 5.2.1. Schemes for LSRs that Support Label Merging
If Ru and Rd are label distribution peers, and both support label If Ru and Rd are label distribution peers, and both support label
merging, one of the following schemes must be used: merging, one of the following schemes must be used:
1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, 1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
UseImmediate> UseImmediate>
This is unsolicited downstream label distribution with This is unsolicited downstream label distribution with
independent control, liberal label retention mode, and no loop independent control, liberal label retention mode, and no loop
detection. detection.
skipping to change at page 58, line 39 skipping to change at page 58, line 39
independent control and conservative label retention mode, independent control and conservative label retention mode,
without loop detection. without loop detection.
7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, 7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
UseIfLoopNotDetected> UseIfLoopNotDetected>
This is downstream-on-demand label distribution with This is downstream-on-demand label distribution with
independent control and conservative label retention mode, with independent control and conservative label retention mode, with
loop detection. loop detection.
4.2.2. Schemes for LSRs that do not Support Label Merging 5.2.2. Schemes for LSRs that do not Support Label Merging
Suppose that R1, R2, R3, and R4 are ATM switches which do not support 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>.
skipping to change at page 59, line 34 skipping to change at page 59, line 34
independent control and conservative label retention mode, independent control and conservative label retention mode,
without loop detection. without loop detection.
3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, 3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange,
UseIfLoopNotDetected> UseIfLoopNotDetected>
This is downstream-on-demand label distribution with This is downstream-on-demand label distribution with
independent control and conservative label retention mode, with independent control and conservative label retention mode, with
loop detection. loop detection.
4.2.3. Interoperability Considerations 5.2.3. Interoperability Considerations
It is easy to see that certain quintuples do NOT yield viable MPLS 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
bindings to upstream LSR Ru only upon request from Ru, but Ru bindings to upstream LSR Ru only upon request from Ru, but Ru
never makes any such requests. Obviously, these schemes are not never makes any such requests. Obviously, these schemes are not
skipping to change at page 61, line 5 skipping to change at page 61, line 5
RequestWhenNeeded/ReleaseOnChange (conservative) , or to use RequestWhenNeeded/ReleaseOnChange (conservative) , or to use
RequestNever/NoReleaseOnChange (liberal). However, the choice RequestNever/NoReleaseOnChange (liberal). However, the choice
of "push" vs. "pull" and "conditional" vs. "unconditional" of "push" vs. "pull" and "conditional" vs. "unconditional"
belongs to Rd. If Ru chooses liberal label retention mode, Rd belongs to Rd. If Ru chooses liberal label retention mode, Rd
can choose either PushUnconditional or PushConditional. If Ru can choose either PushUnconditional or PushConditional. If Ru
chooses conservative label retention mode, Rd can choose chooses conservative label retention mode, Rd can choose
PushConditional, PulledConditional, or PulledUnconditional. PushConditional, PulledConditional, or PulledUnconditional.
These choices together determine the MPLS scheme in use. These choices together determine the MPLS scheme in use.
5. Security Considerations 6. Security Considerations
Some routers may implement security procedures which depend on the Some routers may implement security procedures which depend on the
network layer header being in a fixed place relative to the data link network layer header being in a fixed place relative to the data link
layer header. The MPLS generic encapsulation inserts a shim between layer header. The MPLS generic encapsulation inserts a shim between
the data link layer header and the network layer header. This may the data link layer header and the network layer header. This may
cause such any such security procedures to fail. cause any such security procedures to fail.
An MPLS label has its meaning by virtue of an agreement between the 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 LSR that puts the label in the label stack (the "label writer") , and
the LSR that interprets that label (the "label reader"). If labeled the LSR that interprets that label (the "label reader"). If labeled
packets are accepted from untrusted sources, or if a particular packets are accepted from untrusted sources, or if a particular
incoming label is accepted from an LSR to which that label has not incoming label is accepted from an LSR to which that label has not
been distributed, then packets may be routed in an illegitimate been distributed, then packets may be routed in an illegitimate
manner. manner.
6. Intellectual Property 7. Intellectual Property
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
7. Authors' Addresses 8. 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-372-8117 +1-781-372-8117
E-mail: rcallon@ironbridgenetworks.com E-mail: rcallon@ironbridgenetworks.com
8. References 9. References
[MPLS-ATM] "MPLS using LDP and ATM VC Switching", Davie, Doolan, [MPLS-ATM] "MPLS using LDP and ATM VC Switching", Davie, Doolan,
Lawrence, McGloghrie, Rekhter, Rosen, Swallow, work in progress, Lawrence, McGloghrie, Rekhter, Rosen, Swallow, work in progress,
April 1999. April 1999.
[MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, [MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen,
work in progress, February 1999. work in progress, February 1999.
[MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, [MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi,
editor, work in progress, March 1999. editor, work in progress, March 1999.
 End of changes. 

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