draft-ietf-mpls-arch-07.txt   rfc3031.txt 
Network Working Group Eric C. Rosen Network Working Group E. Rosen
Internet Draft Cisco Systems, Inc. Request for Comments: 3031 Cisco Systems, Inc.
Expiration Date: January 2001 Category: Standards Track A. Viswanathan
Arun Viswanathan
Force10 Networks, Inc. Force10 Networks, Inc.
R. Callon
Ross Callon
Juniper Networks, Inc. Juniper Networks, Inc.
January 2001
July 2000
Multiprotocol Label Switching Architecture Multiprotocol Label Switching Architecture
draft-ietf-mpls-arch-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This internet draft specifies the architecture for Multiprotocol This document specifies the architecture for Multiprotocol Label
Label Switching (MPLS). Switching (MPLS).
Table of Contents Table of Contents
1 Specification ...................................... 4 1 Specification ...................................... 3
2 Introduction to MPLS ............................... 4 2 Introduction to MPLS ............................... 3
2.1 Overview ........................................... 4 2.1 Overview ........................................... 4
2.2 Terminology ........................................ 6 2.2 Terminology ........................................ 6
2.3 Acronyms and Abbreviations ......................... 9 2.3 Acronyms and Abbreviations ......................... 9
2.4 Acknowledgments .................................... 10 2.4 Acknowledgments .................................... 9
3 MPLS Basics ........................................ 10 3 MPLS Basics ........................................ 9
3.1 Labels ............................................. 10 3.1 Labels ............................................. 9
3.2 Upstream and Downstream LSRs ....................... 11 3.2 Upstream and Downstream LSRs ....................... 10
3.3 Labeled Packet ..................................... 11 3.3 Labeled Packet ..................................... 11
3.4 Label Assignment and Distribution .................. 12 3.4 Label Assignment and Distribution .................. 11
3.5 Attributes of a Label Binding ...................... 12 3.5 Attributes of a Label Binding ...................... 11
3.6 Label Distribution Protocols ....................... 12 3.6 Label Distribution Protocols ....................... 11
3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 13 3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12
3.8 Label Retention Mode ............................... 13 3.8 Label Retention Mode ............................... 12
3.9 The Label Stack .................................... 14 3.9 The Label Stack .................................... 13
3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 14 3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 13
3.11 Incoming Label Map (ILM) ........................... 15 3.11 Incoming Label Map (ILM) ........................... 14
3.12 FEC-to-NHLFE Map (FTN) ............................. 15 3.12 FEC-to-NHLFE Map (FTN) ............................. 14
3.13 Label Swapping ..................................... 16 3.13 Label Swapping ..................................... 15
3.14 Scope and Uniqueness of Labels ..................... 16 3.14 Scope and Uniqueness of Labels ..................... 15
3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 17 3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 16
3.16 Penultimate Hop Popping ............................ 19 3.16 Penultimate Hop Popping ............................ 18
3.17 LSP Next Hop ....................................... 21 3.17 LSP Next Hop ....................................... 20
3.18 Invalid Incoming Labels ............................ 21 3.18 Invalid Incoming Labels ............................ 20
3.19 LSP Control: Ordered versus Independent ............ 21 3.19 LSP Control: Ordered versus Independent ............ 20
3.20 Aggregation ........................................ 22 3.20 Aggregation ........................................ 21
3.21 Route Selection .................................... 24 3.21 Route Selection .................................... 23
3.22 Lack of Outgoing Label ............................. 25 3.22 Lack of Outgoing Label ............................. 24
3.23 Time-to-Live (TTL) ................................. 25 3.23 Time-to-Live (TTL) ................................. 24
3.24 Loop Control ....................................... 26 3.24 Loop Control ....................................... 25
3.25 Label Encodings .................................... 27 3.25 Label Encodings .................................... 26
3.25.1 MPLS-specific Hardware and/or Software ............. 27 3.25.1 MPLS-specific Hardware and/or Software ............. 26
3.25.2 ATM Switches as LSRs ............................... 27 3.25.2 ATM Switches as LSRs ............................... 26
3.25.3 Interoperability among Encoding Techniques ......... 29 3.25.3 Interoperability among Encoding Techniques ......... 28
3.26 Label Merging ...................................... 30 3.26 Label Merging ...................................... 28
3.26.1 Non-merging LSRs ................................... 31 3.26.1 Non-merging LSRs ................................... 29
3.26.2 Labels for Merging and Non-Merging LSRs ............ 31 3.26.2 Labels for Merging and Non-Merging LSRs ............ 30
3.26.3 Merge over ATM ..................................... 32 3.26.3 Merge over ATM ..................................... 31
3.26.3.1 Methods of Eliminating Cell Interleave ............. 32 3.26.3.1 Methods of Eliminating Cell Interleave ............. 31
3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 33 3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 31
3.27 Tunnels and Hierarchy .............................. 34 3.27 Tunnels and Hierarchy .............................. 32
3.27.1 Hop-by-Hop Routed Tunnel ........................... 34 3.27.1 Hop-by-Hop Routed Tunnel ........................... 32
3.27.2 Explicitly Routed Tunnel ........................... 34 3.27.2 Explicitly Routed Tunnel ........................... 33
3.27.3 LSP Tunnels ........................................ 34 3.27.3 LSP Tunnels ........................................ 33
3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 35 3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 33
3.27.5 Label Distribution Peering and Hierarchy ........... 35 3.27.5 Label Distribution Peering and Hierarchy ........... 34
3.28 Label Distribution Protocol Transport .............. 37 3.28 Label Distribution Protocol Transport .............. 35
3.29 Why More than one Label Distribution Protocol? ..... 37 3.29 Why More than one Label Distribution Protocol? ..... 36
3.29.1 BGP and LDP ........................................ 37 3.29.1 BGP and LDP ........................................ 36
3.29.2 Labels for RSVP Flowspecs .......................... 37 3.29.2 Labels for RSVP Flowspecs .......................... 36
3.29.3 Labels for Explicitly Routed LSPs .................. 38 3.29.3 Labels for Explicitly Routed LSPs .................. 36
3.30 Multicast .......................................... 38 3.30 Multicast .......................................... 37
4 Some Applications of MPLS .......................... 38 4 Some Applications of MPLS .......................... 37
4.1 MPLS and Hop by Hop Routed Traffic ................. 38 4.1 MPLS and Hop by Hop Routed Traffic ................. 37
4.1.1 Labels for Address Prefixes ........................ 38 4.1.1 Labels for Address Prefixes ........................ 37
4.1.2 Distributing Labels for Address Prefixes ........... 39 4.1.2 Distributing Labels for Address Prefixes ........... 37
4.1.2.1 Label Distribution Peers for an Address Prefix ..... 39 4.1.2.1 Label Distribution Peers for an Address Prefix ..... 37
4.1.2.2 Distributing Labels ................................ 39 4.1.2.2 Distributing Labels ................................ 38
4.1.3 Using the Hop by Hop path as the LSP ............... 40 4.1.3 Using the Hop by Hop path as the LSP ............... 39
4.1.4 LSP Egress and LSP Proxy Egress .................... 41 4.1.4 LSP Egress and LSP Proxy Egress .................... 39
4.1.5 The Implicit NULL Label ............................ 41 4.1.5 The Implicit NULL Label ............................ 40
4.1.6 Option: Egress-Targeted Label Assignment ........... 42 4.1.6 Option: Egress-Targeted Label Assignment ........... 40
4.2 MPLS and Explicitly Routed LSPs .................... 44 4.2 MPLS and Explicitly Routed LSPs .................... 42
4.2.1 Explicitly Routed LSP Tunnels ...................... 44 4.2.1 Explicitly Routed LSP Tunnels ...................... 42
4.3 Label Stacks and Implicit Peering .................. 45 4.3 Label Stacks and Implicit Peering .................. 43
4.4 MPLS and Multi-Path Routing ........................ 46 4.4 MPLS and Multi-Path Routing ........................ 44
4.5 LSP Trees as Multipoint-to-Point Entities .......... 46 4.5 LSP Trees as Multipoint-to-Point Entities .......... 44
4.6 LSP Tunneling between BGP Border Routers ........... 47 4.6 LSP Tunneling between BGP Border Routers ........... 45
4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 49 4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 47
4.8 MPLS and Multicast ................................. 49 4.8 MPLS and Multicast ................................. 47
5 Label Distribution Procedures (Hop-by-Hop) ......... 50 5 Label Distribution Procedures (Hop-by-Hop) ......... 47
5.1 The Procedures for Advertising and Using labels .... 50 5.1 The Procedures for Advertising and Using labels .... 48
5.1.1 Downstream LSR: Distribution Procedure ............. 50 5.1.1 Downstream LSR: Distribution Procedure ............. 48
5.1.1.1 PushUnconditional .................................. 51 5.1.1.1 PushUnconditional .................................. 49
5.1.1.2 PushConditional .................................... 51 5.1.1.2 PushConditional .................................... 49
5.1.1.3 PulledUnconditional ................................ 52 5.1.1.3 PulledUnconditional ................................ 49
5.1.1.4 PulledConditional .................................. 52 5.1.1.4 PulledConditional .................................. 50
5.1.2 Upstream LSR: Request Procedure .................... 53 5.1.2 Upstream LSR: Request Procedure .................... 51
5.1.2.1 RequestNever ....................................... 53 5.1.2.1 RequestNever ....................................... 51
5.1.2.2 RequestWhenNeeded .................................. 53 5.1.2.2 RequestWhenNeeded .................................. 51
5.1.2.3 RequestOnRequest ................................... 54 5.1.2.3 RequestOnRequest ................................... 51
5.1.3 Upstream LSR: NotAvailable Procedure ............... 54 5.1.3 Upstream LSR: NotAvailable Procedure ............... 52
5.1.3.1 RequestRetry ....................................... 54 5.1.3.1 RequestRetry ....................................... 52
5.1.3.2 RequestNoRetry ..................................... 54 5.1.3.2 RequestNoRetry ..................................... 52
5.1.4 Upstream LSR: Release Procedure .................... 55 5.1.4 Upstream LSR: Release Procedure .................... 52
5.1.4.1 ReleaseOnChange .................................... 55 5.1.4.1 ReleaseOnChange .................................... 52
5.1.4.2 NoReleaseOnChange .................................. 55 5.1.4.2 NoReleaseOnChange .................................. 53
5.1.5 Upstream LSR: labelUse Procedure ................... 55 5.1.5 Upstream LSR: labelUse Procedure ................... 53
5.1.5.1 UseImmediate ....................................... 56 5.1.5.1 UseImmediate ....................................... 53
5.1.5.2 UseIfLoopNotDetected ............................... 56 5.1.5.2 UseIfLoopNotDetected ............................... 53
5.1.6 Downstream LSR: Withdraw Procedure ................. 56 5.1.6 Downstream LSR: Withdraw Procedure ................. 53
5.2 MPLS Schemes: Supported Combinations of Procedures . 57 5.2 MPLS Schemes: Supported Combinations of Procedures . 54
5.2.1 Schemes for LSRs that Support Label Merging ........ 57 5.2.1 Schemes for LSRs that Support Label Merging ........ 55
5.2.2 Schemes for LSRs that do not Support Label Merging . 58 5.2.2 Schemes for LSRs that do not Support Label Merging . 56
5.2.3 Interoperability Considerations .................... 59 5.2.3 Interoperability Considerations .................... 57
6 Security Considerations ............................ 61 6 Security Considerations ............................ 58
7 Intellectual Property .............................. 61 7 Intellectual Property .............................. 58
8 Authors' Addresses ................................. 61 8 Authors' Addresses ................................. 59
9 References ......................................... 62 9 References ......................................... 59
10 Full Copyright Statement ........................... 61
1. Specification 1. Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. Introduction to MPLS 2. Introduction to MPLS
This internet draft specifies the architecture for Multiprotocol This document specifies the architecture for Multiprotocol Label
Label Switching (MPLS). Switching (MPLS).
Note that the use of MPLS for multicast is left for further study. Note that the use of MPLS for multicast is left for further study.
2.1. Overview 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
simply to choose the next hop. Choosing the next hop can therefore be simply to choose the next hop. Choosing the next hop can therefore
thought of as the composition of two functions. The first function be thought of as the composition of two functions. The first
partitions the entire set of possible packets into a set of function partitions the entire set of possible packets into a set of
"Forwarding Equivalence Classes (FECs)". The second maps each FEC to "Forwarding Equivalence Classes (FECs)". The second maps each FEC to
a next hop. Insofar as the forwarding decision is concerned, a next hop. Insofar as the forwarding decision is concerned,
different packets which get mapped into the same FEC are different packets which get mapped into the same FEC are
indistinguishable. All packets which belong to a particular FEC and indistinguishable. All packets which belong to a particular FEC and
which travel from a particular node will follow the same path (or if which travel from a particular node will follow the same path (or if
certain kinds of multi-path routing are in use, they will all follow certain kinds of multi-path routing are in use, they will all follow
one of a set of paths associated with the FEC). one of a set of paths associated with the FEC).
In conventional IP forwarding, a particular router will typically In conventional IP forwarding, a particular router will typically
consider two packets to be in the same FEC if there is some address consider two packets to be in the same FEC if there is some address
prefix X in that router's routing tables such that X is the "longest prefix X in that router's routing tables such that X is the "longest
match" for each packet's destination address. As the packet traverses match" for each packet's destination address. As the packet
the network, each hop in turn reexamines the packet and assigns it to traverses the network, each hop in turn reexamines the packet and
a FEC. assigns it to a FEC.
In MPLS, the assignment of a particular packet to a particular FEC is In MPLS, the assignment of a particular packet to a particular FEC is
done just once, as the packet enters the network. The FEC to which done just once, as the packet enters the network. The FEC to which
the packet is assigned is encoded as a short fixed length value known the packet is assigned is encoded as a short fixed length value known
as a "label". When a packet is forwarded to its next hop, the label as a "label". When a packet is forwarded to its next hop, the label
is sent along with it; that is, the packets are "labeled" before they is sent along with it; that is, the packets are "labeled" before they
are forwarded. are forwarded.
At subsequent hops, there is no further analysis of the packet's At subsequent hops, there is no further analysis of the packet's
network layer header. Rather, the label is used as an index into a network layer header. Rather, the label is used as an index into a
table which specifies the next hop, and a new label. The old label table which specifies the next hop, and a new label. The old label
is replaced with the new label, and the packet is forwarded to its is replaced with the new label, and the packet is forwarded to its
next hop. next hop.
In the MPLS forwarding paradigm, once a packet is assigned to a FEC, In the MPLS forwarding paradigm, once a packet is assigned to a FEC,
no further header analysis is done by subsequent routers; all no further header analysis is done by subsequent routers; all
forwarding is driven by the labels. This has a number of advantages forwarding is driven by the labels. This has a number of advantages
over conventional network layer forwarding. over conventional network layer forwarding.
- MPLS forwarding can be done by switches which are capable of - MPLS forwarding can be done by switches which are capable of
doing label lookup and replacement, but are either not capable of doing label lookup and replacement, but are either not capable
analyzing the network layer headers, or are not capable of of analyzing the network layer headers, or are not capable of
analyzing the network layer headers at adequate speed. analyzing the network layer headers at adequate speed.
- Since a packet is assigned to a FEC when it enters the network, - Since a packet is assigned to a FEC when it enters the network,
the ingress router may use, in determining the assignment, any the ingress router may use, in determining the assignment, any
information it has about the packet, even if that information information it has about the packet, even if that information
cannot be gleaned from the network layer header. For example, cannot be gleaned from the network layer header. For example,
packets arriving on different ports may be assigned to different packets arriving on different ports may be assigned to
FECs. Conventional forwarding, on the other hand, can only different FECs. Conventional forwarding, on the other hand,
consider information which travels with the packet in the packet can only consider information which travels with the packet in
header. the packet header.
- A packet that enters the network at a particular router can be - A packet that enters the network at a particular router can be
labeled differently than the same packet entering the network at labeled differently than the same packet entering the network
a different router, and as a result forwarding decisions that at a different router, and as a result forwarding decisions
depend on the ingress router can be easily made. This cannot be that depend on the ingress router can be easily made. This
done with conventional forwarding, since the identity of a cannot be done with conventional forwarding, since the identity
packet's ingress router does not travel with the packet. of a packet's ingress router does not travel with the packet.
- The considerations that determine how a packet is assigned to a - The considerations that determine how a packet is assigned to a
FEC can become ever more and more complicated, without any impact FEC can become ever more and more complicated, without any
at all on the routers that merely forward labeled packets. impact at all on the routers that merely forward labeled
packets.
- Sometimes it is desirable to force a packet to follow a - Sometimes it is desirable to force a packet to follow a
particular route which is explicitly chosen at or before the time particular route which is explicitly chosen at or before the
the packet enters the network, rather than being chosen by the time the packet enters the network, rather than being chosen by
normal dynamic routing algorithm as the packet travels through the normal dynamic routing algorithm as the packet travels
the network. This may be done as a matter of policy, or to through the network. This may be done as a matter of policy,
support traffic engineering. In conventional forwarding, this or to support traffic engineering. In conventional forwarding,
requires the packet to carry an encoding of its route along with this requires the packet to carry an encoding of its route
it ("source routing"). In MPLS, a label can be used to represent along with it ("source routing"). In MPLS, a label can be used
the route, so that the identity of the explicit route need not be to represent the route, so that the identity of the explicit
carried with the packet. route need not be carried with the packet.
Some routers analyze a packet's network layer header not merely to Some routers analyze a packet's network layer header not merely to
choose the packet's next hop, but also to determine a packet's choose the packet's next hop, but also to determine a packet's
"precedence" or "class of service". They may then apply different "precedence" or "class of service". They may then apply different
discard thresholds or scheduling disciplines to different packets. discard thresholds or scheduling disciplines to different packets.
MPLS allows (but does not require) the precedence or class of service MPLS allows (but does not require) the precedence or class of service
to be fully or partially inferred from the label. In this case, one to be fully or partially inferred from the label. In this case, one
may say that the label represents the combination of a FEC and a may say that the label represents the combination of a FEC and a
precedence or class of service. precedence or class of service.
skipping to change at page 6, line 40 skipping to change at page 6, line 16
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.
2.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
the potential problem of cell interleave that the potential problem of cell
is not an issue. interleave is not an issue.
label a short fixed length physically label a short fixed length physically
contiguous identifier which is used to contiguous identifier which is used to
identify a FEC, usually of local identify a FEC, usually of local
significance. significance.
label merging the replacement of multiple incoming label merging the replacement of multiple incoming
labels for a particular FEC with a single labels for a particular FEC with a
outgoing label single outgoing label
label swap the basic forwarding operation consisting label swap the basic forwarding operation
of looking up an incoming label to consisting of looking up an incoming
determine the outgoing label, label to determine the outgoing label,
encapsulation, port, and other data encapsulation, port, and other data
handling information. handling information.
label swapping a forwarding paradigm allowing label swapping a forwarding paradigm allowing
streamlined forwarding of data by using streamlined forwarding of data by using
labels to identify classes of data labels to identify classes of data
packets which are treated packets which are treated
indistinguishably when forwarding. indistinguishably when forwarding.
label switched hop the hop between two MPLS nodes, on which label switched hop the hop between two MPLS nodes, on which
forwarding is done using labels. forwarding is done using labels.
label switched path The path through one or more LSRs at one label switched path The path through one or more LSRs at one
level of the hierarchy followed by a level of the hierarchy followed by a
packets in a particular FEC. packets in a particular FEC.
label switching router an MPLS node which is capable of label switching router an MPLS node which is capable of
forwarding native L3 packets forwarding native L3 packets
layer 2 the protocol layer under layer 3 (which layer 2 the protocol layer under layer 3 (which
therefore offers the services used by therefore offers the services used by
layer 3). Forwarding, when done by the layer 3). Forwarding, when done by the
swapping of short fixed length labels, swapping of short fixed length labels,
occurs at layer 2 regardless of whether occurs at layer 2 regardless of whether
the label being examined is an ATM the label being examined is an ATM
VPI/VCI, a frame relay DLCI, or an MPLS VPI/VCI, a frame relay DLCI, or an MPLS
label. label.
layer 3 the protocol layer at which IP and its layer 3 the protocol layer at which IP and its
associated routing protocols operate link associated routing protocols operate
layer synonymous with layer 2 link layer synonymous with layer 2
loop detection a method of dealing with loops in which loop detection a method of dealing with loops in which
loops are allowed to be set up, and data loops are allowed to be set up, and data
may be transmitted over the loop, but the may be transmitted over the loop, but
loop is later detected the loop is later detected
loop prevention a method of dealing with loops in which loop prevention a method of dealing with loops in which
data is never transmitted over a loop data is never transmitted over a loop
label stack an ordered set of labels label stack an ordered set of labels
merge point a node at which label merging is done merge point a node at which label merging is done
MPLS domain a contiguous set of nodes which operate MPLS domain a contiguous set of nodes which operate
MPLS routing and forwarding and which are MPLS routing and forwarding and which
also in one Routing or Administrative are also in one Routing or
Domain Administrative Domain
MPLS edge node an MPLS node that connects an MPLS domain MPLS edge node an MPLS node that connects an MPLS
with a node which is outside of the domain with a node which is outside of
domain, either because it does not run the domain, either because it does not
MPLS, and/or because it is in a different run MPLS, and/or because it is in a
domain. Note that if an LSR has a different domain. Note that if an LSR
neighboring host which is not running has a neighboring host which is not
MPLS, that that LSR is an MPLS edge node. running MPLS, that that LSR is an MPLS
edge node.
MPLS egress node an MPLS edge node in its role in handling MPLS egress node an MPLS edge node in its role in
traffic as it leaves an MPLS domain handling traffic as it leaves an MPLS
domain
MPLS ingress node an MPLS edge node in its role in handling MPLS ingress node an MPLS edge node in its role in
traffic as it enters an MPLS domain handling traffic as it enters an MPLS
domain
MPLS label a label which is carried in a packet MPLS label a label which is carried in a packet
header, and which represents the packet's header, and which represents the
FEC packet's FEC
MPLS node a node which is running MPLS. An MPLS MPLS node a node which is running MPLS. An MPLS
node will be aware of MPLS control node will be aware of MPLS control
protocols, will operate one or more L3 protocols, will operate one or more L3
routing protocols, and will be capable of routing protocols, and will be capable
forwarding packets based on labels. An of forwarding packets based on labels.
MPLS node may optionally be also capable An MPLS node may optionally be also
of forwarding native L3 packets. capable of forwarding native L3 packets.
MultiProtocol Label Switching an IETF working group and the effort MultiProtocol Label Switching an IETF working group and the
associated with the working group effort associated with the working
group
network layer synonymous with layer 3 network layer synonymous with layer 3
stack synonymous with label stack stack synonymous with label stack
switched path synonymous with label switched path switched path synonymous with label switched path
virtual circuit a circuit used by a connection-oriented virtual circuit a circuit used by a connection-oriented
layer 2 technology such as ATM or Frame layer 2 technology such as ATM or Frame
Relay, requiring the maintenance of state Relay, requiring the maintenance of
information in layer 2 switches. state information in layer 2 switches.
VC merge label merging where the MPLS label is VC merge label merging where the MPLS label is
carried in the ATM VCI field (or combined carried in the ATM VCI field (or
VPI/VCI field), so as to allow multiple combined VPI/VCI field), so as to allow
VCs to merge into one single VC multiple VCs to merge into one single VC
VP merge label merging where the MPLS label is VP merge label merging where the MPLS label is
carried din the ATM VPI field, so as to carried din the ATM VPI field, so as to
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
distinguished via the VCI. be 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
2.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
skipping to change at page 10, line 15 skipping to change at page 9, line 35
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
2.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
Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan, and Boivie, Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan,
George Swallow for their inputs and ideas. and George Swallow for their inputs and ideas.
3. 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.
3.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.
If Ru and Rd are LSRs, they may agree that when Ru transmits a packet If Ru and Rd are LSRs, they may agree that when Ru transmits a packet
to Rd, Ru will label with packet with label value L if and only if to Rd, Ru will label with packet with label value L if and only if
the packet is a member of a particular FEC F. That is, they can the packet is a member of a particular FEC F. That is, they can
skipping to change at page 14, line 8 skipping to change at page 13, line 17
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.
3.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
been "above it" in the past, or that some number of other labels may been "above it" in the past, or that some number of other labels may
be below it at present. be below it at present.
skipping to change at page 14, line 33 skipping to change at page 13, line 42
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 3.27). the notion of LSP Tunnel and the MPLS Hierarchy (section 3.27).
3.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
2. the operation to perform on the packet's label stack; this is 1. the packet's next hop
one of the following operations:
a) replace the label at the top of the label stack with a 2. the operation to perform on the packet's label stack; this is one
specified new label of the following operations:
b) pop the label stack a) replace the label at the top of the label stack with a
specified new label
c) replace the label at the top of the label stack with a b) pop the label stack
specified new label, and then push one or more specified c) replace the label at the top of the label stack with a
new labels onto the label stack. specified new label, and then push one or more specified new
labels onto the label stack.
It may also contain: It may also contain:
d) the data link encapsulation to use when transmitting the packet d) the data link encapsulation to use when transmitting the packet
e) the way to encode the label stack when transmitting the packet e) the way to encode the label stack when transmitting the packet
f) any other information needed in order to properly dispose of f) any other information needed in order to properly dispose of
the packet. the packet.
skipping to change at page 15, line 28 skipping to change at page 14, line 33
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".
3.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.
3.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
when forwarding packets that arrive unlabeled, but which are to be used when forwarding packets that arrive unlabeled, but which are to
labeled before being forwarded. be 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.
3.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.
In order to forward an unlabeled packet, a LSR analyzes the network In order to forward an unlabeled packet, a LSR analyzes the network
layer header, to determine the packet's FEC. It then uses the FTN to layer header, to determine the packet's FEC. It then uses the FTN to
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.
3.14. Scope and Uniqueness of Labels 3.14. Scope and Uniqueness of Labels
skipping to change at page 17, line 5 skipping to change at page 16, line 9
IF (AND ONLY IF) RD CAN TELL, WHEN IT RECEIVES A PACKET WHOSE TOP IF (AND ONLY IF) RD CAN TELL, WHEN IT RECEIVES A PACKET WHOSE TOP
LABEL IS L, WHETHER THE LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN LABEL IS L, WHETHER THE LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN
THE ARCHITECTURE DOES NOT REQUIRE THAT F1 == F2. In such cases, we THE ARCHITECTURE DOES NOT REQUIRE THAT F1 == F2. In such cases, we
may say that Rd is using a different "label space" for the labels it may say that Rd is using a different "label space" for the labels it
distributes to Ru1 than for the labels it distributes to Ru2. distributes to Ru1 than for the labels it distributes to Ru2.
In general, Rd can only tell whether it was Ru1 or Ru2 that put the In general, Rd can only tell whether it was Ru1 or Ru2 that put the
particular label value L at the top of the label stack if the particular label value L at the top of the label stack if the
following conditions hold: following conditions hold:
- Ru1 and Ru2 are the only label distribution peers to which Rd - Ru1 and Ru2 are the only label distribution peers to which Rd
distributed a binding of label value L, and distributed a binding of label value L, and
- Ru1 and Ru2 are each directly connected to Rd via a point-to- - Ru1 and Ru2 are each directly connected to Rd via a point-to-
point interface. point interface.
When these conditions hold, an LSR may use labels that have "per When these conditions hold, an LSR may use labels that have "per
interface" scope, i.e., which are only unique per interface. We may interface" scope, i.e., which are only unique per interface. We may
say that the LSR is using a "per-interface label space". When these say that the LSR is using a "per-interface label space". When these
conditions do not hold, the labels must be unique over the LSR which conditions do not hold, the labels must be unique over the LSR which
has assigned them, and we may say that the LSR is using a "per- has assigned them, and we may say that the LSR is using a "per-
platform label space." platform label space."
If a particular LSR Rd is attached to a particular LSR Ru over two If a particular LSR Rd is attached to a particular LSR Ru over two
point-to-point interfaces, then Rd may distribute to Ru a binding of point-to-point interfaces, then Rd may distribute to Ru a binding of
skipping to change at page 18, line 23 skipping to change at page 17, line 23
4. For all i, 1<i<n: Ri transmits P to R[i+1] by means of MPLS, 4. For all i, 1<i<n: Ri transmits P to R[i+1] by means of MPLS,
i.e., by using the label at the top of the label stack (the i.e., by using the label at the top of the label stack (the
level m label) as an index into an ILM; level m label) as an index into an ILM;
5. For all i, 1<i<n: if a system S receives and forwards P after P 5. For all i, 1<i<n: if a system S receives and forwards P after P
is transmitted by Ri but before P is received by R[i+1] (e.g., is transmitted by Ri but before P is received by R[i+1] (e.g.,
Ri and R[i+1] might be connected via a switched data link Ri and R[i+1] might be connected via a switched data link
subnetwork, and S might be one of the data link switches), then subnetwork, and S might be one of the data link switches), then
S's forwarding decision is not based on the level m label, or S's forwarding decision is not based on the level m label, or
on the network layer header. This may be because: on the network layer header. This may be because:
a) the decision is not based on the label stack or the a) the decision is not based on the label stack or the network
network layer header at all; layer header at all;
b) the decision is based on a label stack on which b) the decision is based on a label stack on which additional
additional labels have been pushed (i.e., on a level m+k labels have been pushed (i.e., on a level m+k label, where
label, where k>0). k>0).
In other words, we can speak of the level m LSP for Packet P as the In other words, we can speak of the level m LSP for Packet P as the
sequence of routers: sequence of routers:
1. which begins with an LSR (an "LSP Ingress") that pushes on a 1. which begins with an LSR (an "LSP Ingress") that pushes on a
level m label, level m label,
2. all of whose intermediate LSRs make their forwarding decision 2. all of whose intermediate LSRs make their forwarding decision
by label Switching on a level m label, by label Switching on a level m label,
skipping to change at page 19, line 18 skipping to change at page 18, line 21
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.
3.16. Penultimate Hop Popping 3.16. Penultimate Hop Popping
Note that according to the definitions of section 3.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.
There is also a practical advantage to doing penultimate hop popping. There is also a practical advantage to doing penultimate hop popping.
If one does not do this, then when the LSP egress receives a packet, If one does not do this, then when the LSP egress receives a packet,
skipping to change at page 19, line 43 skipping to change at page 18, line 46
on this lookup. (In this case, the egress for the packet's level m on this lookup. (In this case, the egress for the packet's level m
LSP is also an intermediate node for its level m-1 LSP.) If there is LSP is also an intermediate node for its level m-1 LSP.) If there is
no other label on the stack, then the packet is forwarded according no other label on the stack, then the packet is forwarded according
to its network layer destination address. Note that this would to its network layer destination address. Note that this would
require the egress to do TWO lookups, either two label lookups or a require the egress to do TWO lookups, either two label lookups or a
label lookup followed by an address lookup. label lookup followed by an address lookup.
If, on the other hand, penultimate hop popping is used, then when the If, on the other hand, penultimate hop popping is used, then when the
penultimate hop looks up the label, it determines: penultimate hop looks up the label, it determines:
- that it is the penultimate hop, and - that it is the penultimate hop, and
- who the next hop is. - who the next hop is.
The penultimate node then pops the stack, and forwards the packet The penultimate node then pops the stack, and forwards the packet
based on the information gained by looking up the label that was based on the information gained by looking up the label that was
previously at the top of the stack. When the LSP egress receives the previously at the top of the stack. When the LSP egress receives the
packet, the label which is now at the top of the stack will be the packet, the label which is now at the top of the stack will be the
label which it needs to look up in order to make its own forwarding label which it needs to look up in order to make its own forwarding
decision. Or, if the packet was only carrying a single label, the decision. Or, if the packet was only carrying a single label, the
LSP egress will simply see the network layer packet, which is just LSP egress will simply see the network layer packet, which is just
what it needs to see in order to make its forwarding decision. what it needs to see in order to make its forwarding decision.
This technique allows the egress to do a single lookup, and also This technique allows the egress to do a single lookup, and also
requires only a single lookup by the penultimate node. requires only a single lookup by the penultimate node.
The creation of the forwarding "fastpath" in a label switching The creation of the forwarding "fastpath" in a label switching
product may be greatly aided if it is known that only a single lookup product may be greatly aided if it is known that only a single lookup
is ever required: is ever required:
- the code may be simplified if it can assume that only a single - the code may be simplified if it can assume that only a single
lookup is ever needed lookup is ever needed
- the code can be based on a "time budget" that assumes that only a - the code can be based on a "time budget" that assumes that only
single lookup is ever needed. a single lookup is ever needed.
In fact, when penultimate hop popping is done, the LSP Egress need In fact, when penultimate hop popping is done, the LSP Egress need
not even be an LSR. not even be an LSR.
However, some hardware switching engines may not be able to pop the However, some hardware switching engines may not be able to pop the
label stack, so this cannot be universally required. There may also label stack, so this cannot be universally required. There may also
be some situations in which penultimate hop popping is not desirable. be some situations in which penultimate hop popping is not desirable.
Therefore the penultimate node pops the label stack only if this is Therefore the penultimate node pops the label stack only if this is
specifically requested by the egress node, OR if the next node in the specifically requested by the egress node, OR if the next node in the
LSP does not support MPLS. (If the next node in the LSP does support LSP does not support MPLS. (If the next node in the LSP does support
skipping to change at page 22, line 47 skipping to change at page 21, line 46
3.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
single label be bound to the union, and that label applied to all single label be bound to the union, and that label applied to all
traffic in the union? traffic in the union?
The procedure of binding a single label to a union of FECs which is The procedure of binding a single label to a union of FECs which is
itself a FEC (within some domain), and of applying that label to all itself a FEC (within some domain), and of applying that label to all
traffic in the union, is known as "aggregation". The MPLS traffic in the union, is known as "aggregation". The MPLS
architecture allows aggregation. Aggregation may reduce the number architecture allows aggregation. Aggregation may reduce the number
of labels which are needed to handle a particular set of packets, and of labels which are needed to handle a particular set of packets, and
may also reduce the amount of label distribution control traffic may also reduce the amount of label distribution control traffic
needed. needed.
Given a set of FECs which are "aggregatable" into a single FEC, it is Given a set of FECs which are "aggregatable" into a single FEC, it is
possible to (a) aggregate them into a single FEC, (b) aggregate them possible to (a) aggregate them into a single FEC, (b) aggregate them
skipping to change at page 23, line 41 skipping to change at page 22, line 39
granularity. This is not necessary to ensure correct operation, but granularity. This is not necessary to ensure correct operation, but
it does result in a reduction of the number of labels distributed by it does result in a reduction of the number of labels distributed by
Ru, and Ru is not gaining any particular advantage by distributing Ru, and Ru is not gaining any particular advantage by distributing
the larger number of labels. The decision whether to do this or not the larger number of labels. The decision whether to do this or not
is a local matter. is a local matter.
If Ru has coarser granularity than Rd (i.e., Rd has distributed n If Ru has coarser granularity than Rd (i.e., Rd has distributed n
labels for the set of FECs, while Ru has distributed m, where n > m), labels for the set of FECs, while Ru has distributed m, where n > m),
it has two choices: it has two choices:
- It may adopt Rd's finer level of granularity. This would require - It may adopt Rd's finer level of granularity. This would
it to withdraw the m labels it has distributed, and distribute n require it to withdraw the m labels it has distributed, and
labels. This is the preferred option. distribute n labels. This is the preferred option.
- It may simply map its m labels into a subset of Rd's n labels, if - It may simply map its m labels into a subset of Rd's n labels,
it can determine that this will produce the same routing. For if it can determine that this will produce the same routing.
example, suppose that Ru applies a single label to all traffic For example, suppose that Ru applies a single label to all
that needs to pass through a certain egress LSR, whereas Rd binds traffic that needs to pass through a certain egress LSR,
a number of different labels to such traffic, depending on the whereas Rd binds a number of different labels to such traffic,
individual destination addresses of the packets. If Ru knows the depending on the individual destination addresses of the
address of the egress router, and if Rd has bound a label to the packets. If Ru knows the address of the egress router, and if
FEC which is identified by that address, then Ru can simply apply Rd has bound a label to the FEC which is identified by that
that label. address, then Ru can simply apply that label.
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").
3.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
using hop by hop routing. selected using hop by hop routing.
In an explicitly routed LSP, each LSR does not independently choose In an explicitly routed LSP, each LSR does not independently choose
the next hop; rather, a single LSR, generally the LSP ingress or the the next hop; rather, a single LSR, generally the LSP ingress or the
LSP egress, specifies several (or all) of the LSRs in the LSP. If a LSP egress, specifies several (or all) of the LSRs in the LSP. If a
single LSR specifies the entire LSP, the LSP is "strictly" explicitly single LSR specifies the entire LSP, the LSP is "strictly" explicitly
routed. If a single LSR specifies only some of the LSP, the LSP is routed. If a single LSR specifies only some of the LSP, the LSP is
"loosely" explicitly routed. "loosely" explicitly routed.
The sequence of LSRs followed by an explicitly routed LSP may be The sequence of LSRs followed by an explicitly routed LSP may be
chosen by configuration, or may be selected dynamically by a single chosen by configuration, or may be selected dynamically by a single
skipping to change at page 25, line 18 skipping to change at page 24, line 18
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
procedure: procedure:
- 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
enable this particular LSR to forward it correctly. to 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.
3.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
functions as well, such as multicast scoping, and supporting the other functions as well, such as multicast scoping, and supporting
"traceroute" command. This implies that there are two TTL-related the "traceroute" command. This implies that there are two TTL-
issues that MPLS needs to deal with: (i) TTL as a way to suppress related issues that MPLS needs to deal with: (i) TTL as a way to
loops; (ii) TTL as a way to accomplish other functions, such as suppress loops; (ii) TTL as a way to accomplish other functions, such
limiting the scope of a packet. as limiting the scope of a packet.
When a packet travels along an LSP, it SHOULD emerge with the same When a packet travels along an LSP, it SHOULD emerge with the same
TTL value that it would have had if it had traversed the same TTL value that it would have had if it had traversed the same
sequence of routers without having been label switched. If the sequence of routers without having been label switched. If the
packet travels along a hierarchy of LSPs, the total number of LSR- packet travels along a hierarchy of LSPs, the total number of LSR-
hops traversed SHOULD be reflected in its TTL value when it emerges hops traversed SHOULD be reflected in its TTL value when it emerges
from the hierarchy of LSPs. from the hierarchy of LSPs.
The way that TTL is handled may vary depending upon whether the MPLS The way that TTL is handled may vary depending upon whether the MPLS
label values are carried in an MPLS-specific "shim" header [MPLS- label values are carried in an MPLS-specific "shim" header [MPLS-
skipping to change at page 26, line 19 skipping to change at page 25, line 21
data link and network layer headers, then this shim MUST have a TTL data link and network layer headers, then this shim MUST have a TTL
field that SHOULD be initially loaded from the network layer header field that SHOULD be initially loaded from the network layer header
TTL field, SHOULD be decremented at each LSR-hop, and SHOULD be TTL field, SHOULD be decremented at each LSR-hop, and SHOULD be
copied into the network layer header TTL field when the packet copied into the network layer header TTL field when the packet
emerges from its LSP. emerges from its LSP.
If the label values are encoded in a data link layer header (e.g., If the label values are encoded in a data link layer header (e.g.,
the VPI/VCI field in ATM's AAL5 header), and the labeled packets are the VPI/VCI field in ATM's AAL5 header), and the labeled packets are
forwarded by an L2 switch (e.g., an ATM switch), and the data link forwarded by an L2 switch (e.g., an ATM switch), and the data link
layer (like ATM) does not itself have a TTL field, then it will not layer (like ATM) does not itself have a TTL field, then it will not
be possible to decrement a packet's TTL at each LSR-hop. An LSP be possible to decrement a packet's TTL at each LSR-hop. An LSP
segment which consists of a sequence of LSRs that cannot decrement a segment which consists of a sequence of LSRs that cannot decrement a
packet's TTL will be called a "non-TTL LSP segment". packet's TTL will be called a "non-TTL LSP segment".
When a packet emerges from a non-TTL LSP segment, it SHOULD however When a packet emerges from a non-TTL LSP segment, it SHOULD however
be given a TTL that reflects the number of LSR-hops it traversed. In be given a TTL that reflects the number of LSR-hops it traversed. In
the unicast case, this can be achieved by propagating a meaningful the unicast case, this can be achieved by propagating a meaningful
LSP length to ingress nodes, enabling the ingress to decrement the LSP length to ingress nodes, enabling the ingress to decrement the
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
at the ingress to the non-TTL LSP segment must not label switch the LSR at the ingress to the non-TTL LSP segment must not label switch
packet. This means that special procedures must be developed to the 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.
3.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
of providing fair access to the buffer pool for incoming cells of providing fair access to the buffer pool for incoming cells
carrying different VPI/VCI values, this looping may not have any carrying different VPI/VCI values, this looping may not have any
deleterious effect on other traffic. If the ATM hardware cannot deleterious effect on other traffic. If the ATM hardware cannot
provide fair buffer access of this sort, however, then even transient provide fair buffer access of this sort, however, then even transient
loops may cause severe degradation of the LSR's total performance. loops may cause severe degradation of the LSR's total performance.
Even if fair buffer access can be provided, it is still worthwhile to Even if fair buffer access can be provided, it is still worthwhile to
have some means of detecting loops that last "longer than possible". have some means of detecting loops that last "longer than possible".
In addition, even where TTL and/or per-VC fair queuing provides a In addition, even where TTL and/or per-VC fair queuing provides a
means for surviving loops, it still may be desirable where practical means for surviving loops, it still may be desirable where practical
to avoid setting up LSPs which loop. 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
skipping to change at page 27, line 44 skipping to change at page 26, line 44
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].
3.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".
There are three obvious ways to encode labels in the ATM cell header There are three obvious ways to encode labels in the ATM cell header
(presuming the use of AAL5): (presuming the use of AAL5):
skipping to change at page 28, line 25 skipping to change at page 27, line 22
With this encoding technique, each LSP is realized as an ATM With this encoding technique, each LSP is realized as an ATM
SVC, and the label distribution protocol becomes the ATM SVC, and the label distribution protocol becomes the ATM
"signaling" protocol. With this encoding technique, the ATM- "signaling" protocol. With this encoding technique, the ATM-
LSRs cannot perform "push" or "pop" operations on the label LSRs cannot perform "push" or "pop" operations on the label
stack. stack.
2. SVP Encoding 2. SVP 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, and the VCI field to encode the second label the label stack, and the VCI field to encode the second label
on the stack, if one is present. This technique some advantages on the stack, if one is present. This technique some
over the previous one, in that it permits the use of ATM "VP- advantages over the previous one, in that it permits the use of
switching". That is, the LSPs are realized as ATM SVPs, with ATM "VP-switching". That is, the LSPs are realized as ATM
the label distribution protocol serving as the ATM signaling SVPs, with the label distribution protocol serving as the ATM
protocol. signaling protocol.
However, this technique cannot always be used. If the network However, this technique cannot always be used. If the network
includes an ATM Virtual Path through a non-MPLS ATM network, includes an ATM Virtual Path through a non-MPLS ATM network,
then the VPI field is not necessarily available for use by then the VPI field is not necessarily available for use by
MPLS. MPLS.
When this encoding technique is used, the ATM-LSR at the egress When this encoding technique is used, the ATM-LSR at the egress
of the VP effectively does a "pop" operation. of the VP effectively does a "pop" operation.
3. SVP Multipoint Encoding 3. SVP Multipoint Encoding
skipping to change at page 29, line 24 skipping to change at page 28, line 20
encapsulation. encapsulation.
3.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
stack to determine the new value of the stack, and then encode the stack to determine the new value of the stack, and then encode the
new value appropriately before transmitting the labeled packet to its new value appropriately before transmitting the labeled packet to its
next hop. next hop.
Unfortunately, ATM switches have no capability for translating from Unfortunately, ATM switches have no capability for translating from
one encoding technique to another. The MPLS architecture therefore one encoding technique to another. The MPLS architecture therefore
requires that whenever it is possible for two ATM switches to be requires that whenever it is possible for two ATM switches to be
successive LSRs along a level m LSP for some packet, that those two successive LSRs along a level m LSP for some packet, that those two
ATM switches use the same encoding technique. ATM switches use the same encoding technique.
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
of an LSR with different label stack encodings on different hops. example of an LSR with different label stack encodings on different
Such an LSR may swap off an ATM encoded label stack on an incoming hops. Such an LSR may swap off an ATM encoded label stack on an
interface and replace it with an MPLS shim header encoded label stack incoming interface and replace it with an MPLS shim header encoded
on the outgoing interface. label stack on the outgoing interface.
3.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
two packets from different incoming interfaces, and/or with different two packets from different incoming interfaces, and/or with different
labels, and send both packets out the same outgoing interface with labels, and send both packets out the same outgoing interface with
the same label. Once the packets are transmitted, the information the same label. Once the packets are transmitted, the information
that they arrived from different interfaces and/or with different that they arrived from different interfaces and/or with different
incoming labels is lost. incoming labels is lost.
Let us say that an LSR is not capable of label merging if, for any Let us say that an LSR is not capable of label merging if, for any
two packets which arrive from different interfaces, or with different two packets which arrive from different interfaces, or with different
labels, the packets must either be transmitted out different labels, the packets must either be transmitted out different
interfaces, or must have different labels. ATM-LSRs using the SVC or interfaces, or must have different labels. ATM-LSRs using the SVC or
SVP Encodings cannot perform label merging. This is discussed in SVP Encodings cannot perform label merging. This is discussed in
more detail in the next section. more detail in the next section.
skipping to change at page 30, line 47 skipping to change at page 29, line 37
particular LSR needs is never be larger than the number of label particular LSR needs is never be larger than the number of label
distribution adjacencies. Without label merging, the number of distribution adjacencies. Without label merging, the number of
incoming labels per FEC that a particular LSR needs is as large as incoming labels per FEC that a particular LSR needs is as large as
the number of upstream nodes which forward traffic in the FEC to the the number of upstream nodes which forward traffic in the FEC to the
LSR in question. In fact, it is difficult for an LSR to even LSR in question. In fact, it is difficult for an LSR to even
determine how many such incoming labels it must support for a determine how many such incoming labels it must support for a
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.
3.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
a unit of data arrives, a label (VPI/VCI or DLCI) is looked up in a is, a unit of data arrives, a label (VPI/VCI or DLCI) is looked up in
"cross-connect table", on the basis of that lookup an output port is a "cross-connect table", on the basis of that lookup an output port
chosen, and the label value is rewritten. In fact, it is possible to is chosen, and the label value is rewritten. In fact, it is possible
use such technologies for MPLS forwarding; a label distribution to 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.
Unfortunately, these technologies do not necessarily support the Unfortunately, these technologies do not necessarily support the
label merging capability. In ATM, if one attempts to perform label label merging capability. In ATM, if one attempts to perform label
merging, the result may be the interleaving of cells from various merging, the result may be the interleaving of cells from various
packets. If cells from different packets get interleaved, it is packets. If cells from different packets get interleaved, it is
impossible to reassemble the packets. Some Frame Relay switches use impossible to reassemble the packets. Some Frame Relay switches use
cell switching on their backplanes. These switches may also be cell switching on their backplanes. These switches may also be
incapable of supporting label merging, for the same reason -- cells incapable of supporting label merging, for the same reason -- cells
of different packets may get interleaved, and there is then no way to of different packets may get interleaved, and there is then no way to
reassemble the packets. reassemble the packets.
We propose to support two solutions to this problem. First, MPLS will We propose to support two solutions to this problem. First, MPLS
contain procedures which allow the use of non-merging LSRs. Second, will contain procedures which allow the use of non-merging LSRs.
MPLS will support procedures which allow certain ATM switches to Second, MPLS will support procedures which allow certain ATM switches
function as merging LSRs. to 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.
3.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
on how many LSRs are upstream of it with respect to the FEC in depend 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
unless it explicitly asks for a label for that FEC. The upstream unless it explicitly asks for a label for that FEC. The upstream
neighbor may make multiple such requests, and is given a new label neighbor may make multiple such requests, and is given a new label
each time. When a downstream neighbor receives such a request from each time. When a downstream neighbor receives such a request from
upstream, and the downstream neighbor does not itself support label upstream, and the downstream neighbor does not itself support label
merging, then it must in turn ask its downstream neighbor for another merging, then it must in turn ask its downstream neighbor for another
label for the FEC in question. label for the FEC in question.
It is possible that there may be some nodes which support label It is possible that there may be some nodes which support label
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.
3.26.3. Merge over ATM 3.26.3. Merge over ATM
3.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
skipping to change at page 32, line 37 skipping to change at page 31, line 26
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.
2. VC merge 2. VC merge
When VC merge is used, switches are required to buffer cells When VC merge is used, switches are required to buffer cells
from one packet until the entire packet is received (this may from one packet until the entire packet is received (this may
be determined by looking for the AAL5 end of frame indicator). be determined by looking for the AAL5 end of frame indicator).
VP merge has the advantage that it is compatible with a higher VP merge has the advantage that it is compatible with a higher
percentage of existing ATM switch implementations. This makes it more percentage of existing ATM switch implementations. This makes it
likely that VP merge can be used in existing networks. Unlike VC more likely that VP merge can be used in existing networks. Unlike
merge, VP merge does not incur any delays at the merge points and VC merge, VP merge does not incur any delays at the merge points and
also does not impose any buffer requirements. However, it has the also does not impose any buffer requirements. However, it has the
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.
3.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
requirement for a single label in the case of operation over frame requirement for a single label in the case of operation over frame
media). If the upstream neighbor is not doing merge, then the media). If the upstream neighbor is not doing merge, then the
neighbor will require a single VPI/VCI per stream for itself, plus neighbor will require a single VPI/VCI per stream for itself, plus
enough VPI/VCIs to pass to its upstream neighbors. The number enough VPI/VCIs to pass to its upstream neighbors. The number
required will be determined by allowing the upstream nodes to request required will be determined by allowing the upstream nodes to request
additional VPI/VCIs from their downstream neighbors (this is again additional VPI/VCIs from their downstream neighbors (this is again
analogous to the method used with frame merge). analogous to the method used with frame merge).
A similar method is possible to support nodes which perform VP merge. A similar method is possible to support nodes which perform VP merge.
In this case the VP merge node, rather than requesting a single In this case the VP merge node, rather than requesting a single
VPI/VCI or a number of VPI/VCIs from its downstream neighbor, instead VPI/VCI or a number of VPI/VCIs from its downstream neighbor, instead
may request a single VP (identified by a VPI) but several VCIs within may request a single VP (identified by a VPI) but several VCIs within
the VP. Furthermore, suppose that a non-merge node is downstream the VP. Furthermore, suppose that a non-merge node is downstream
from two different VP merge nodes. This node may need to request one from two different VP merge nodes. This node may need to request one
VPI/VCI (for traffic originating from itself) plus two VPs (one for VPI/VCI (for traffic originating from itself) plus two VPs (one for
each upstream node), each associated with a specified set of VCIs (as each upstream node), each associated with a specified set of VCIs (as
requested from the upstream node). requested from the upstream node).
In order to support all of VP merge, VC merge, and non-merge, it is In order to support all of VP merge, VC merge, and non-merge, it is
therefore necessary to allow upstream nodes to request a combination therefore necessary to allow upstream nodes to request a combination
of zero or more VC identifiers (consisting of a VPI/VCI), plus zero of zero or more VC identifiers (consisting of a VPI/VCI), plus zero
or more VPs (identified by VPIs) each containing a specified number or more VPs (identified by VPIs) each containing a specified number
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).
3.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
"tunnel" from Ru to Rd. We refer to any packet so handled as a a "tunnel" from Ru to Rd. We refer to any packet so handled as a
"Tunneled Packet". "Tunneled Packet".
3.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.
3.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.
3.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
assigning a particular packet to an LSP tunnel is a local matter at assigning a particular packet to an LSP tunnel is a local matter at
the tunnel's transmit endpoint. To put a packet into an LSP tunnel, the tunnel's transmit endpoint. To put a packet into an LSP tunnel,
the transmit endpoint pushes a label for the tunnel onto the label the transmit endpoint pushes a label for the tunnel onto the label
stack and sends the labeled packet to the next hop in the tunnel. stack and sends the labeled packet to the next hop in the tunnel.
If it is not necessary for the tunnel's receive endpoint to be able If it is not necessary for the tunnel's receive endpoint to be able
skipping to change at page 35, line 14 skipping to change at page 33, line 43
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.
3.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,
R21, R22, R23, R3, R4>. R2, 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.
R2, switching on the label, determines that P must enter the tunnel. R2, switching on the label, determines that P must enter the tunnel.
R2 first replaces the Incoming label with a label that is meaningful R2 first replaces the Incoming label with a label that is meaningful
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
which is meaningful to R21. Switching is done on the level 2 label by value which is meaningful to R21. Switching is done on the level 2
R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel, label by R21, R22, R23. R23, which is the penultimate hop in the
pops the label stack before forwarding the packet to R3. When R3 sees R2-R3 tunnel, pops the label stack before forwarding the packet to
packet P, P has only a level 1 label, having now exited the tunnel. R3. When R3 sees packet P, P has only a level 1 label, having now
Since R3 is the penultimate hop in P's level 1 LSP, it pops the label exited the tunnel. Since R3 is the penultimate hop in P's level 1
stack, and R4 receives P unlabeled. LSP, it pops the label 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.
3.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 4.6 and 4.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 39 skipping to change at page 35, line 20
4.2.1 and 4.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
then propagate the information to their local label then propagate the information to their local label
distribution peers. This process continues till the information distribution peers. This process continues till the
reaches the remote peer. information reaches the remote peer.
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
4.3. 4.3.
3.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].
3.29. Why More than one Label Distribution Protocol? 3.29. Why More than one Label Distribution Protocol?
skipping to change at page 38, line 16 skipping to change at page 36, line 45
3.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
and label distribution. routing 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].
3.30. Multicast 3.30. Multicast
This section is for further study This section is for further study
4. Some Applications of MPLS 4. Some Applications of MPLS
skipping to change at page 38, line 47 skipping to change at page 37, line 28
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.
4.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.
4.1.2. Distributing Labels for Address Prefixes 4.1.2. Distributing Labels for Address Prefixes
4.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
skipping to change at page 40, line 45 skipping to change at page 39, line 19
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
the best match algorithm must be performed again. and 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/23, 10.2.154/23, 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.
skipping to change at page 42, line 13 skipping to change at page 40, line 30
prefix X to LSR Ru if and only if: prefix X to LSR Ru if and only if:
1. the rules of Section 4.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.
is quite appropriate; if the LSP Egress is an MPLS Egress for X, then This is quite appropriate; if the LSP Egress is an MPLS Egress for X,
if the penultimate LSR does not pop the label stack, the LSP Egress then if the penultimate LSR does not pop the label stack, the LSP
will need to look up the label, pop the label stack, and then look up Egress will need to look up the label, pop the label stack, and then
the next label (or look up the L3 address, if no more labels are look up the next label (or look up the L3 address, if no more labels
present). By having the penultimate LSR pop the label stack, the LSP are present). By having the penultimate LSR pop the label stack, the
Egress is saved the work of having to look up two labels in order to LSP Egress is saved the work of having to look up two labels in order
make its forwarding decision. to 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.
4.1.6. Option: Egress-Targeted Label Assignment 4.1.6. Option: Egress-Targeted Label Assignment
skipping to change at page 43, line 5 skipping to change at page 41, line 20
2. there is some way for Ri to determine that Re is the LSP egress 2. there is some way for Ri to determine that Re is the LSP egress
for all packets in a particular set of FECs for all packets in a particular set of FECs
Then Ri may bind a single label to all FECS in the set. This is Then Ri may bind a single label to all FECS in the set. This is
known as "Egress-Targeted Label Assignment." known as "Egress-Targeted Label Assignment."
How can LSR Ri determine that an LSR Re is the LSP Egress for all How can LSR Ri determine that an LSR Re is the LSP Egress for all
packets in a particular FEC? There are a number of possible ways: packets in a particular FEC? There are a number of possible ways:
- If the network is running a link state routing algorithm, and all - If the network is running a link state routing algorithm, and
nodes in the area support MPLS, then the routing algorithm all nodes in the area support MPLS, then the routing algorithm
provides Ri with enough information to determine the routers provides Ri with enough information to determine the routers
through which packets in that FEC must leave the routing domain through which packets in that FEC must leave the routing domain
or area. or area.
- If the network is running BGP, Ri may be able to determine that - If the network is running BGP, Ri may be able to determine that
the packets in a particular FEC must leave the network via some the packets in a particular FEC must leave the network via some
particular router which is the "BGP Next Hop" for that FEC. particular router which is the "BGP Next Hop" for that FEC.
- It is possible to use the label distribution protocol to pass - It is possible to use the label distribution protocol to pass
information about which address prefixes are "attached" to which information about which address prefixes are "attached" to
egress LSRs. This method has the advantage of not depending on which egress LSRs. This method has the advantage of not
the presence of link state routing. depending on the presence of link state routing.
If egress-targeted label assignment is used, the number of labels If egress-targeted label assignment is used, the number of labels
that need to be supported throughout the network may be greatly that need to be supported throughout the network may be greatly
reduced. This may be significant if one is using legacy switching reduced. This may be significant if one is using legacy switching
hardware to do MPLS, and the switching hardware can support only a hardware to do MPLS, and the switching hardware can support only a
limited number of labels. limited number of labels.
One possible approach would be to configure the network to use One possible approach would be to configure the network to use
egress-targeted label assignment by default, but to configure egress-targeted label assignment by default, but to configure
particular LSRs to NOT use egress-targeted label assignment for one particular LSRs to NOT use egress-targeted label assignment for one
or more of the address prefixes for which it is an LSP egress. We or more of the address prefixes for which it is an LSP egress. We
impose the following rule: impose the following rule:
- If a particular LSR is NOT an LSP Egress for some set of address - If a particular LSR is NOT an LSP Egress for some set of
prefixes, then it should assign labels to the address prefixes in address prefixes, then it should assign labels to the address
the same way as is done by its LSP next hop for those address prefixes in the same way as is done by its LSP next hop for
prefixes. That is, suppose Rd is Ru's LSP next hop for address those address prefixes. That is, suppose Rd is Ru's LSP next
prefixes X1 and X2. If Rd assigns the same label to X1 and X2, hop for address prefixes X1 and X2. If Rd assigns the same
Ru should as well. If Rd assigns different labels to X1 and X2, label to X1 and X2, Ru should as well. If Rd assigns different
then Ru should as well. labels to X1 and X2, then Ru should as well.
For example, suppose one wants to make egress-targeted label For example, suppose one wants to make egress-targeted label
assignment the default, but to assign distinct labels to those assignment the default, but to assign distinct labels to those
address prefixes for which there are multiple possible LSP egresses address prefixes for which there are multiple possible LSP egresses
(i.e., for those address prefixes which are multi-homed.) One can (i.e., for those address prefixes which are multi-homed.) One can
configure all LSRs to use egress-targeted label assignment, and then configure all LSRs to use egress-targeted label assignment, and then
configure a handful of LSRs to assign distinct labels to those configure a handful of LSRs to assign distinct labels to those
address prefixes which are multi-homed. For a particular multi-homed address prefixes which are multi-homed. For a particular multi-homed
address prefix X, one would only need to configure this in LSRs which address prefix X, one would only need to configure this in LSRs which
are either LSP Egresses or LSP Proxy Egresses for X. are either LSP Egresses or LSP Proxy Egresses for X.
skipping to change at page 44, line 16 skipping to change at page 42, line 33
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.
4.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].
4.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
or in support of traffic engineering. The explicit route may be a 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
Tunnels. All that is needed is: Tunnels. All that is needed is:
1. A means of selecting the packets that are to be sent into the 1. A means of selecting the packets that are to be sent into the
Explicitly Routed LSP Tunnel; Explicitly Routed LSP Tunnel;
2. A means of setting up the Explicitly Routed LSP Tunnel; 2. A means of setting up the Explicitly Routed LSP Tunnel;
3. A means of ensuring that packets sent into the Tunnel will not 3. A means of ensuring that packets sent into the Tunnel will not
loop from the receive endpoint back to the transmit endpoint. loop from the receive endpoint back to the transmit endpoint.
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.
4.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
skipping to change at page 45, line 25 skipping to change at page 43, line 42
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.
Alternatively, one could assign a distinct label to each interface. Alternatively, one could assign a distinct label to each interface.
Then Re is an LSP proxy egress for the 10 address prefixes. This Then Re is an LSP proxy egress for the 10 address prefixes. This
eliminates the need for Re to look up the network layer addresses in eliminates the need for Re to look up the network layer addresses in
order to forward the packets. However, it can result in the use of a order to forward the packets. However, it can result in the use of a
large number of labels. large number of labels.
An alternative would be to bind all 10 address prefixes to the same An alternative would be to bind all 10 address prefixes to the same
level 1 label (which is also bound to the address of the LSR itself), level 1 label (which is also bound to the address of the LSR itself),
and then to bind each address prefix to a distinct level 2 label. The and then to bind each address prefix to a distinct level 2 label.
level 2 label would be treated as an attribute of the level 1 label The level 2 label would be treated as an attribute of the level 1
binding, which we call the "Stack Attribute". We impose the label binding, which we call the "Stack Attribute". We impose the
following rules: following rules:
- When LSR Ru initially labels a hitherto unlabeled packet, if the - When LSR Ru initially labels a hitherto unlabeled packet, if
longest match for the packet's destination address is X, and Ru's the longest match for the packet's destination address is X,
LSP next hop for X is Rd, and Rd has distributed to Ru a binding and Ru's LSP next hop for X is Rd, and Rd has distributed to Ru
of label L1 to X, along with a stack attribute of L2, then a binding of label L1 to X, along with a stack attribute of L2,
then
1. Ru must push L2 and then L1 onto the packet's label stack, 1. Ru must push L2 and then L1 onto the packet's label stack,
and then forward the packet to Rd; and then forward the packet to Rd;
2. When Ru distributes label bindings for X to its label 2. When Ru distributes label bindings for X to its label
distribution peers, it must include L2 as the stack distribution peers, it must include L2 as the stack
attribute. attribute.
3. Whenever the stack attribute changes (possibly as a result 3. Whenever the stack attribute changes (possibly as a result
of a change in Ru's LSP next hop for X), Ru must distribute of a change in Ru's LSP next hop for X), Ru must distribute
the new stack attribute. the new stack attribute.
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.
skipping to change at page 46, line 23 skipping to change at page 44, line 41
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.
4.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
again overwrites L2 with L3, and send P2 on to R3. again overwrites L2 with L3, and send P2 on to R3.
Note then that when P1 and P2 are traveling from R2 to R3, they carry Note then that when P1 and P2 are traveling from R2 to R3, they carry
the same label, and as far as MPLS is concerned, they cannot be the same label, and as far as MPLS is concerned, they cannot be
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
skipping to change at page 47, line 8 skipping to change at page 45, line 19
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 3.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.
4.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
by the interior routers. by the interior routers.
This can easily be done by means of LSP Tunnels. Suppose that BGP This can easily be done by means of LSP Tunnels. Suppose that BGP
routes are distributed only to BGP Border Routers, and not to the routes are distributed only to BGP Border Routers, and not to the
interior routers that lie along the Hop-by-hop path from Border interior routers that lie along the Hop-by-hop path from Border
Router to Border Router. LSP Tunnels can then be used as follows: Router to Border Router. LSP Tunnels can then be used as follows:
1. Each BGP Border Router distributes, to every other BGP Border 1. Each BGP Border Router distributes, to every other BGP Border
Router in the same Autonomous System, a label for each address Router in the same Autonomous System, a label for each address
prefix that it distributes to that router via BGP. prefix that it distributes to that router via BGP.
2. The IGP for the Autonomous System maintains a host route for 2. The IGP for the Autonomous System maintains a host route for
each BGP Border Router. Each interior router distributes its each BGP Border Router. Each interior router distributes its
labels for these host routes to each of its IGP neighbors. labels for these host routes to each of its IGP neighbors.
3. Suppose that: 3. Suppose that:
a) BGP Border Router B1 receives an unlabeled packet P, a) BGP Border Router B1 receives an unlabeled packet P,
b) address prefix X in B1's routing table is the longest
match for the destination address of P,
c) the route to X is a BGP route, b) address prefix X in B1's routing table is the longest match
for the destination address of P,
d) the BGP Next Hop for X is B2, c) the route to X is a BGP route,
e) B2 has bound label L1 to X, and has distributed this d) the BGP Next Hop for X is B2,
binding to B1, e) B2 has bound label L1 to X, and has distributed this binding
to B1,
f) the IGP next hop for the address of B2 is I1, f) the IGP next hop for the address of B2 is I1,
g) the address of B2 is in B1's and I1's IGP routing tables g) the address of B2 is in B1's and I1's IGP routing tables as
as a host route, and a host route, and
h) I1 has bound label L2 to the address of B2, and h) I1 has bound label L2 to the address of B2, and distributed
distributed this binding to B1. this binding to B1.
Then before sending packet P to I1, B1 must create a label Then before sending packet P to I1, B1 must create a label
stack for P, then push on label L1, and then push on label L2. stack for P, then push on label L1, and then push on label L2.
4. Suppose that BGP Border Router B1 receives a labeled Packet P, 4. Suppose that BGP Border Router B1 receives a labeled Packet P,
where the label on the top of the label stack corresponds to an where the label on the top of the label stack corresponds to an
address prefix, X, to which the route is a BGP route, and that address prefix, X, to which the route is a BGP route, and that
conditions 3b, 3c, 3d, and 3e all hold. Then before sending conditions 3b, 3c, 3d, and 3e all hold. Then before sending
packet P to I1, B1 must replace the label at the top of the packet P to I1, B1 must replace the label at the top of the
label stack with L1, and then push on label L2. label stack with L1, and then push on label L2.
With these procedures, a given packet P follows a level 1 LSP all of With these procedures, a given packet P follows a level 1 LSP all of
whose members are BGP Border Routers, and between each pair of BGP whose members are BGP Border Routers, and between each pair of BGP
Border Routers in the level 1 LSP, it follows a level 2 LSP. Border Routers in the level 1 LSP, it follows a level 2 LSP.
These procedures effectively create a Hop-by-Hop Routed LSP Tunnel These procedures effectively create a Hop-by-Hop Routed LSP Tunnel
between the BGP Border Routers. between the BGP Border Routers.
skipping to change at page 48, line 38 skipping to change at page 46, line 45
other. other.
It is sometimes possible to create Hop-by-Hop Routed LSP Tunnels It is sometimes possible to create Hop-by-Hop Routed LSP Tunnels
between two BGP Border Routers, even if they are not in the same between two BGP Border Routers, even if they are not in the same
Autonomous System. Suppose, for example, that B1 and B2 are in AS 1. Autonomous System. Suppose, for example, that B1 and B2 are in AS 1.
Suppose that B3 is an EBGP neighbor of B2, and is in AS2. Finally, Suppose that B3 is an EBGP neighbor of B2, and is in AS2. Finally,
suppose that B2 and B3 are on some network which is common to both suppose that B2 and B3 are on some network which is common to both
Autonomous Systems (a "Demilitarized Zone"). In this case, an LSP Autonomous Systems (a "Demilitarized Zone"). In this case, an LSP
tunnel can be set up directly between B1 and B3 as follows: tunnel can be set up directly between B1 and B3 as follows:
- 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
the BGP next hop for each such route is B3. If B3 has assigned that the BGP next hop for each such route is B3. If B3 has
labels to address prefixes, B2 passes these labels along, assigned labels to address prefixes, B2 passes these labels
unchanged, to B1. along, unchanged, to B1.
- The IGP of AS1 has a host route for B3. - The IGP of AS1 has a host route for B3.
4.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.
4.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.
5. 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.
5.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.
The upstream LSR must perform: The upstream LSR must perform:
- The Request Procedure, and - The Request Procedure, and
- 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 5.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.
5.1.1. Downstream LSR: Distribution Procedure 5.1.1. Downstream LSR: Distribution Procedure
skipping to change at page 56, line 33 skipping to change at page 54, line 7
5.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
binding of L to Y before it learned of the unbinding of L from X, and binding of L to Y before it learned of the unbinding of L from X, and
if packets matching both X and Y were forwarded by Ru to Rd, then for if packets matching both X and Y were forwarded by Ru to Rd, then for
a period of time, Ru would label both packets matching X and packets a period of time, Ru would label both packets matching X and packets
matching Y with label L. matching Y with label L.
The distribution and withdrawal of label bindings is done via a label The distribution and withdrawal of label bindings is done via a label
distribution protocol. All label distribution protocols require that distribution protocol. All label distribution protocols require that
a label distribution adjacency be established between two label a label distribution adjacency be established between two label
distribution peers (except implicit peers). If LSR R1 has a label distribution peers (except implicit peers). If LSR R1 has a label
distribution adjacency to LSR R2, and has received label bindings distribution adjacency to LSR R2, and has received label bindings
skipping to change at page 59, line 39 skipping to change at page 57, line 17
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.
5.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
viable, since they will not result in the proper distribution of not viable, since they will not result in the proper
label bindings. distribution of label bindings.
- <*, RequestNever, *, *, ReleaseOnChange> - <*, RequestNever, *, *, ReleaseOnChange>
In these MPLS schemes, Rd releases bindings when it isn't using In these MPLS schemes, Rd releases bindings when it isn't using
them, but it never asks for them again, even if it later has a them, but it never asks for them again, even if it later has a
need for them. These schemes thus do not ensure that label need for them. These schemes thus do not ensure that label
bindings get properly distributed. bindings get properly distributed.
In this section, we specify rules to prevent a pair of label In this section, we specify rules to prevent a pair of label
distribution peers from adopting procedures which lead to infeasible distribution peers from adopting procedures which lead to infeasible
MPLS Schemes. These rules require either the exchange of information MPLS Schemes. These rules require either the exchange of information
between label distribution peers during the initialization of the between label distribution peers during the initialization of the
label distribution adjacency, or apriori knowledge of the information label distribution adjacency, or a priori knowledge of the
(obtained through a means outside the scope of this document). information (obtained through a means outside the scope of this
document).
1. Each must state whether it supports label merging. 1. Each must state whether it supports label merging.
2. If Rd does not support label merging, Rd must choose either the 2. If Rd does not support label merging, Rd must choose either the
PulledUnconditional procedure or the PulledConditional PulledUnconditional procedure or the PulledConditional
procedure. If Rd chooses PulledConditional, Ru is forced to procedure. If Rd chooses PulledConditional, Ru is forced to
use the RequestRetry procedure. use the RequestRetry procedure.
That is, if the downstream LSR does not support label merging, That is, if the downstream LSR does not support label merging,
its preferences take priority when the MPLS scheme is chosen. its preferences take priority when the MPLS scheme is chosen.
skipping to change at page 61, line 14 skipping to change at page 58, line 35
6. 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 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.
7. 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.
8. 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
Arun Viswanathan EMail: erosen@cisco.com
Force10 Networks, Inc.
1440 McCarthy Blvd. Arun Viswanathan
Milpitas, CA 95035-7438 Force10 Networks, Inc.
E-mail: arun@force10networks.com 1440 McCarthy Blvd.
Ross Callon Milpitas, CA 95035-7438
Juniper Networks, Inc.
1194 North Mathilda Avenue EMail: arun@force10networks.com
Sunnyvale, CA 94089 USA
E-mail: rcallon@juniper.net Ross Callon
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
EMail: rcallon@juniper.net
9. References 9. References
[MPLS-ATM] "MPLS using LDP and ATM VC Switching", Davie, Doolan, [MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter,
Lawrence, McGloghrie, Rekhter, Rosen, Swallow, work in progress, June Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS
2000. using LDP and ATM VC Switching", RFC 3035,
January 2001.
[MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, [MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter,
work in progress, January 2000. Rosen, Work in Progress.
[MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, [MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi,
editor, work in progress, July 2000. Editor, Work in Progress.
[MPLS-FRMRLY] "Use of Label Switching on Frame Relay Networks", [MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, "Use of Label
Conta, Doolan, Malis, work in progress, June 2000. Switching on Frame Relay Networks Specification",
RFC 3034, January 2001.
[MPLS-LDP], "LDP Specification", Andersson, Doolan, Feldman, [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette,
Fredette, Thomas, work in progress, June 2000. A. and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[MPLS-RSVP-TUNNELS], "Extensions to RSVP for LSP Tunnels", Awduche, [MPLS-RSVP-TUNNELS] "Extensions to RSVP for LSP Tunnels", Awduche,
Berger, Gan, Li, Swallow, Srinvasan, work in progress, February 2000. Berger, Gan, Li, Swallow, Srinvasan, Work in
Progress.
[MPLS-SHIM] "MPLS Label Stack Encodings", Rosen, Rekhter, Tappan, [MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G.,
Farinacci, Fedorkow, Li, Conta, work in progress, July 2000. Farinacci, D. and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[MPLS-TRFENG] RFC 2702, "Requirements for Traffic Engineering Over [MPLS-TRFENG] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M.
MPLS", Awduche, Malcolm, Agogbua, O'Dell, McManus, September 1999. and J. McManus, "Requirements for Traffic
Engineering Over MPLS", RFC 2702, September 1999.
10. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 192 change blocks. 
565 lines changed or deleted 566 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/