Request for Comments: 3031 Cisco Systems, Inc.
Category: Standards Track A. Viswanathan
Force10 Networks, Inc.
R. Callon
Juniper Networks, Inc.
January 2001
Multiprotocol Label Switching Architecture
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document specifies the architecture for Multiprotocol Label
Switching (MPLS).
Table of Contents
1 Specification ...................................... 3
2 Introduction to MPLS ............................... 3
2.1 Overview ........................................... 4
2.2 Terminology ........................................ 6
2.3 Acronyms and Abbreviations ......................... 9
2.4 Acknowledgments .................................... 9
3 MPLS Basics ........................................ 9
3.1 Labels ............................................. 9
3.2 Upstream and Downstream LSRs ....................... 10
3.3 Labeled Packet ..................................... 11
3.4 Label Assignment and Distribution .................. 11
3.5 Attributes of a Label Binding ...................... 11
3.6 Label Distribution Protocols ....................... 11
3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12
3.8 Label Retention Mode ............................... 12
3.9 The Label Stack .................................... 13
3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 13
3.11 Incoming Label Map (ILM) ........................... 14
3.12 FEC-to-NHLFE Map (FTN) ............................. 14
3.13 Label Swapping ..................................... 15
3.14 Scope and Uniqueness of Labels ..................... 15
3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 16
3.16 Penultimate Hop Popping ............................ 18
3.17 LSP Next Hop ....................................... 20
3.18 Invalid Incoming Labels ............................ 20
3.19 LSP Control: Ordered versus Independent ............ 20
3.20 Aggregation ........................................ 21
3.21 Route Selection .................................... 23
3.22 Lack of Outgoing Label ............................. 24
3.23 Time-to-Live (TTL) ................................. 24
3.24 Loop Control ....................................... 25
3.25 Label Encodings .................................... 26
3.25.1 MPLS-specific Hardware and/or Software ............. 26
3.25.2 ATM Switches as LSRs ............................... 26
3.25.3 Interoperability among Encoding Techniques ......... 28
3.26 Label Merging ...................................... 28
3.26.1 Non-merging LSRs ................................... 29
3.26.2 Labels for Merging and Non-Merging LSRs ............ 30
3.26.3 Merge over ATM ..................................... 31
3.26.3.1 Methods of Eliminating Cell Interleave ............. 31
3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 31
3.27 Tunnels and Hierarchy .............................. 32
3.27.1 Hop-by-Hop Routed Tunnel ........................... 32
3.27.2 Explicitly Routed Tunnel ........................... 33
3.27.3 LSP Tunnels ........................................ 33
3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 33
3.27.5 Label Distribution Peering and Hierarchy ........... 34
3.28 Label Distribution Protocol Transport .............. 35
3.29 Why More than one Label Distribution Protocol? ..... 36
3.29.1 BGP and LDP ........................................ 36
3.29.2 Labels for RSVP Flowspecs .......................... 36
3.29.3 Labels for Explicitly Routed LSPs .................. 36
3.30 Multicast .......................................... 37
4 Some Applications of MPLS .......................... 37
4.1 MPLS and Hop by Hop Routed Traffic ................. 37
4.1.1 Labels for Address Prefixes ........................ 37
4.1.2 Distributing Labels for Address Prefixes ........... 37
4.1.2.1 Label Distribution Peers for an Address Prefix ..... 37
4.1.2.2 Distributing Labels ................................ 38
4.1.3 Using the Hop by Hop path as the LSP ............... 39
4.1.4 LSP Egress and LSP Proxy Egress .................... 39
4.1.5 The Implicit NULL Label ............................ 40
4.1.6 Option: Egress-Targeted Label Assignment ........... 40
4.2 MPLS and Explicitly Routed LSPs .................... 42
4.2.1 Explicitly Routed LSP Tunnels ...................... 42
4.3 Label Stacks and Implicit Peering .................. 43
4.4 MPLS and Multi-Path Routing ........................ 44
4.5 LSP Trees as Multipoint-to-Point Entities .......... 44
4.6 LSP Tunneling between BGP Border Routers ........... 45
4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 47
4.8 MPLS and Multicast ................................. 47
5 Label Distribution Procedures (Hop-by-Hop) ......... 47
5.1 The Procedures for Advertising and Using labels .... 48
5.1.1 Downstream LSR: Distribution Procedure ............. 48
5.1.1.1 PushUnconditional .................................. 49
5.1.1.2 PushConditional .................................... 49
5.1.1.3 PulledUnconditional ................................ 49
5.1.1.4 PulledConditional .................................. 50
5.1.2 Upstream LSR: Request Procedure .................... 51
5.1.2.1 RequestNever ....................................... 51
5.1.2.2 RequestWhenNeeded .................................. 51
5.1.2.3 RequestOnRequest ................................... 51
5.1.3 Upstream LSR: NotAvailable Procedure ............... 52
5.1.3.1 RequestRetry ....................................... 52
5.1.3.2 RequestNoRetry ..................................... 52
5.1.4 Upstream LSR: Release Procedure .................... 52
5.1.4.1 ReleaseOnChange .................................... 52
5.1.4.2 NoReleaseOnChange .................................. 53
5.1.5 Upstream LSR: labelUse Procedure ................... 53
5.1.5.1 UseImmediate ....................................... 53
5.1.5.2 UseIfLoopNotDetected ............................... 53
5.1.6 Downstream LSR: Withdraw Procedure ................. 53
5.2 MPLS Schemes: Supported Combinations of Procedures . 54
5.2.1 Schemes for LSRs that Support Label Merging ........ 55
5.2.2 Schemes for LSRs that do not Support Label Merging . 56
5.2.3 Interoperability Considerations .................... 57
6 Security Considerations ............................ 58
7 Intellectual Property .............................. 58
8 Authors' Addresses ................................. 59
9 References ......................................... 59
10 Full Copyright Statement ........................... 61
1. Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
2. Introduction to MPLS
This document specifies the architecture for Multiprotocol Label
Switching (MPLS).
Note that the use of MPLS for multicast is left for further study.
2.1. Overview
As a packet of a connectionless network layer protocol travels from
one router to the next, each router makes an independent forwarding
decision for that packet. That is, each router analyzes the packet's
header, and each router runs a network layer routing algorithm. Each
router independently chooses a next hop for the packet, based on its
analysis of the packet's header and the results of running the
routing algorithm.
Packet headers contain considerably more information than is needed
simply to choose the next hop. Choosing the next hop can therefore
be thought of as the composition of two functions. The first
function partitions the entire set of possible packets into a set of
"Forwarding Equivalence Classes (FECs)". The second maps each FEC to
a next hop. Insofar as the forwarding decision is concerned,
different packets which get mapped into the same FEC are
indistinguishable. All packets which belong to a particular FEC and
which travel from a particular node will follow the same path (or if
certain kinds of multi-path routing are in use, they will all follow
one of a set of paths associated with the FEC).
In conventional IP forwarding, a particular router will typically
consider two packets to be in the same FEC if there is some address
prefix X in that router's routing tables such that X is the "longest
match" for each packet's destination address. As the packet
traverses the network, each hop in turn reexamines the packet and
assigns it to a FEC.
In MPLS, the assignment of a particular packet to a particular FEC is
done just once, as the packet enters the network. The FEC to which
the packet is assigned is encoded as a short fixed length value known
as a "label". When a packet is forwarded to its next hop, the label
is sent along with it; that is, the packets are "labeled" before they
are forwarded.
At subsequent hops, there is no further analysis of the packet's
network layer header. Rather, the label is used as an index into a
table which specifies the next hop, and a new label. The old label
is replaced with the new label, and the packet is forwarded to its
next hop.
In the MPLS forwarding paradigm, once a packet is assigned to a FEC,
no further header analysis is done by subsequent routers; all
forwarding is driven by the labels. This has a number of advantages
over conventional network layer forwarding.
- MPLS forwarding can be done by switches which are capable of
doing label lookup and replacement, but are either not capable
of analyzing the network layer headers, or are not capable of
analyzing the network layer headers at adequate speed.
- Since a packet is assigned to a FEC when it enters the network,
the ingress router may use, in determining the assignment, any
information it has about the packet, even if that information
cannot be gleaned from the network layer header. For example,
packets arriving on different ports may be assigned to
different FECs. Conventional forwarding, on the other hand,
can only consider information which travels with the packet in
the packet header.
- A packet that enters the network at a particular router can be
labeled differently than the same packet entering the network
at a different router, and as a result forwarding decisions
that depend on the ingress router can be easily made. This
cannot be done with conventional forwarding, since the identity
of a packet's ingress router does not travel with the packet.
- The considerations that determine how a packet is assigned to a
FEC can become ever more and more complicated, without any
impact at all on the routers that merely forward labeled
packets.
- Sometimes it is desirable to force a packet to follow a
particular route which is explicitly chosen at or before the
time the packet enters the network, rather than being chosen by
the normal dynamic routing algorithm as the packet travels
through the network. This may be done as a matter of policy,
or to support traffic engineering. In conventional forwarding,
this requires the packet to carry an encoding of its route
along with it ("source routing"). In MPLS, a label can be used
to represent the route, so that the identity of the explicit
route need not be carried with the packet.
Some routers analyze a packet's network layer header not merely to
choose the packet's next hop, but also to determine a packet's
"precedence" or "class of service". They may then apply different
discard thresholds or scheduling disciplines to different packets.
MPLS allows (but does not require) the precedence or class of service
to be fully or partially inferred from the label. In this case, one
may say that the label represents the combination of a FEC and a
precedence or class of service.
MPLS stands for "Multiprotocol" Label Switching, multiprotocol
because its techniques are applicable to ANY network layer protocol.
In this document, however, we focus on the use of IP as the network
layer protocol.
A router which supports MPLS is known as a "Label Switching Router",
or LSR.
2.2. Terminology
This section gives a general conceptual overview of the terms used in
this document. Some of these terms are more precisely defined in
later sections of the document.
DLCI a label used in Frame Relay networks to
identify frame relay circuits
forwarding equivalence class a group of IP packets which are
forwarded in the same manner (e.g.,
over the same path, with the same
forwarding treatment)
frame merge label merging, when it is applied to
operation over frame based media, so
that the potential problem of cell
interleave is not an issue.
label a short fixed length physically
contiguous identifier which is used to
identify a FEC, usually of local
significance.
label merging the replacement of multiple incoming
labels for a particular FEC with a
single outgoing label
label swap the basic forwarding operation
consisting of looking up an incoming
label to determine the outgoing label,
encapsulation, port, and other data
handling information.
label swapping a forwarding paradigm allowing
streamlined forwarding of data by using
labels to identify classes of data
packets which are treated
indistinguishably when forwarding.
label switched hop the hop between two MPLS nodes, on which
forwarding is done using labels.
label switched path The path through one or more LSRs at one
level of the hierarchy followed by a
packets in a particular FEC.
label switching router an MPLS node which is capable of
forwarding native L3 packets
layer 2 the protocol layer under layer 3 (which
therefore offers the services used by
layer 3). Forwarding, when done by the
swapping of short fixed length labels,
occurs at layer 2 regardless of whether
the label being examined is an ATM
VPI/VCI, a frame relay DLCI, or an MPLS
label.
layer 3 the protocol layer at which IP and its
associated routing protocols operate
link layer synonymous with layer 2
loop detection a method of dealing with loops in which
loops are allowed to be set up, and data
may be transmitted over the loop, but
the loop is later detected
loop prevention a method of dealing with loops in which
data is never transmitted over a loop
label stack an ordered set of labels
merge point a node at which label merging is done
MPLS domain a contiguous set of nodes which operate
MPLS routing and forwarding and which
are also in one Routing or
Administrative Domain
MPLS edge node an MPLS node that connects an MPLS
domain with a node which is outside of
the domain, either because it does not
run MPLS, and/or because it is in a
different domain. Note that if an LSR
has a neighboring host which is not
running MPLS, that that LSR is an MPLS
edge node.
MPLS egress node an MPLS edge node in its role in
handling traffic as it leaves an MPLS
domain
MPLS ingress node an MPLS edge node in its role in
handling traffic as it enters an MPLS
domain
MPLS label a label which is carried in a packet
header, and which represents the
packet's FEC
MPLS node a node which is running MPLS. An MPLS
node will be aware of MPLS control
protocols, will operate one or more L3
routing protocols, and will be capable
of forwarding packets based on labels.
An MPLS node may optionally be also
capable of forwarding native L3 packets.
MultiProtocol Label Switching an IETF working group and the
effort associated with the working
group
network layer synonymous with layer 3
stack synonymous with label stack
switched path synonymous with label switched path
virtual circuit a circuit used by a connection-oriented
layer 2 technology such as ATM or Frame
Relay, requiring the maintenance of
state information in layer 2 switches.
VC merge label merging where the MPLS label is
carried in the ATM VCI field (or
combined VPI/VCI field), so as to allow
multiple VCs to merge into one single VC
VP merge label merging where the MPLS label is
carried din the ATM VPI field, so as to
allow multiple VPs to be merged into one
single VP. In this case two cells would
have the same VCI value only if they
originated from the same node. This
allows cells from different sources to
be distinguished via the VCI.
VPI/VCI a label used in ATM networks to identify
circuits
2.3. Acronyms and Abbreviations
ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol
DLCI Data Link Circuit Identifier
FEC Forwarding Equivalence Class
FTN FEC to NHLFE Map
IGP Interior Gateway Protocol
ILM Incoming Label Map
IP Internet Protocol
LDP Label Distribution Protocol
L2 Layer 2 L3 Layer 3
LSP Label Switched Path
LSR Label Switching Router
MPLS MultiProtocol Label Switching
NHLFE Next Hop Label Forwarding Entry
SVC Switched Virtual Circuit
SVP Switched Virtual Path
TTL Time-To-Live
VC Virtual Circuit
VCI Virtual Circuit Identifier
VP Virtual Path
VPI Virtual Path Identifier
2.4. Acknowledgments
The ideas and text in this document have been collected from a number
of sources and comments received. We would like to thank Rick
Boivie, Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan,
and George Swallow for their inputs and ideas.
3. MPLS Basics
In this section, we introduce some of the basic concepts of MPLS and
describe the general approach to be used.
3.1. Labels
A label is a short, fixed length, locally significant identifier
which is used to identify a FEC. The label which is put on a
particular packet represents the Forwarding Equivalence Class to
which that packet is assigned.
Most commonly, a packet is assigned to a FEC based (completely or
partially) on its network layer destination address. However, the
label is never an encoding of that address.
If Ru and Rd are LSRs, they may agree that when Ru transmits a packet
to Rd, Ru will label with packet with label value L if and only if
the packet is a member of a particular FEC F. That is, they can
agree to a "binding" between label L and FEC F for packets moving
from Ru to Rd. As a result of such an agreement, L becomes Ru's
"outgoing label" representing FEC F, and L becomes Rd's "incoming
label" representing FEC F.
Note that L does not necessarily represent FEC F for any packets
other than those which are being sent from Ru to Rd. L is an
arbitrary value whose binding to F is local to Ru and Rd.
When we speak above of packets "being sent" from Ru to Rd, we do not
imply either that the packet originated at Ru or that its destination
is Rd. Rather, we mean to include packets which are "transit
packets" at one or both of the LSRs.
Sometimes it may be difficult or even impossible for Rd to tell, of
an arriving packet carrying label L, that the label L was placed in
the packet by Ru, rather than by some other LSR. (This will
typically be the case when Ru and Rd are not direct neighbors.) In
such cases, Rd must make sure that the binding from label to FEC is
one-to-one. That is, Rd MUST NOT agree with Ru1 to bind L to FEC F1,
while also agreeing with some other LSR Ru2 to bind L to a different
FEC F2, UNLESS Rd can always tell, when it receives a packet with
incoming label L, whether the label was put on the packet by Ru1 or
whether it was put on by Ru2.
It is the responsibility of each LSR to ensure that it can uniquely
interpret its incoming labels.
3.2. Upstream and Downstream LSRs
Suppose Ru and Rd have agreed to bind label L to FEC F, for packets
sent from Ru to Rd. Then with respect to this binding, Ru is the
"upstream LSR", and Rd is the "downstream LSR".
To say that one node is upstream and one is downstream with respect
to a given binding means only that a particular label represents a
particular FEC in packets travelling from the upstream node to the
downstream node. This is NOT meant to imply that packets in that FEC
would actually be routed from the upstream node to the downstream
node.
3.3. Labeled Packet
A "labeled packet" is a packet into which a label has been encoded.
In some cases, the label resides in an encapsulation header which
exists specifically for this purpose. In other cases, the label may
reside in an existing data link or network layer header, as long as
there is a field which is available for that purpose. The particular
encoding technique to be used must be agreed to by both the entity
which encodes the label and the entity which decodes the label.
3.4. Label Assignment and Distribution
In the MPLS architecture, the decision to bind a particular label L
to a particular FEC F is made by the LSR which is DOWNSTREAM with
respect to that binding. The downstream LSR then informs the
upstream LSR of the binding. Thus labels are "downstream-assigned",
and label bindings are distributed in the "downstream to upstream"
direction.
If an LSR has been designed so that it can only look up labels that
fall into a certain numeric range, then it merely needs to ensure
that it only binds labels that are in that range.
3.5. Attributes of a Label Binding
A particular binding of label L to FEC F, distributed by Rd to Ru,
may have associated "attributes". If Ru, acting as a downstream LSR,
also distributes a binding of a label to FEC F, then under certain
conditions, it may be required to also distribute the corresponding
attribute that it received from Rd.
3.6. Label Distribution Protocols
A label distribution protocol is a set of procedures by which one LSR
informs another of the label/FEC bindings it has made. Two LSRs
which use a label distribution protocol to exchange label/FEC binding
information are known as "label distribution peers" with respect to
the binding information they exchange. If two LSRs are label
distribution peers, we will speak of there being a "label
distribution adjacency" between them.
(N.B.: two LSRs may be label distribution peers with respect to some
set of bindings, but not with respect to some other set of bindings.)
The label distribution protocol also encompasses any negotiations in
which two label distribution peers need to engage in order to learn
of each other's MPLS capabilities.
THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL
DISTRIBUTION PROTOCOL. In fact, a number of different label
distribution protocols are being standardized. Existing protocols
have been extended so that label distribution can be piggybacked on
them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). New protocols
have also been defined for the explicit purpose of distributing
labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].
In this document, we try to use the acronym "LDP" to refer
specifically to the protocol defined in [MPLS-LDP]; when speaking of
label distribution protocols in general, we try to avoid the acronym.
3.7. Unsolicited Downstream vs. Downstream-on-Demand
The MPLS architecture allows an LSR to explicitly request, from its
next hop for a particular FEC, a label binding for that FEC. This is
known as "downstream-on-demand" label distribution.
The MPLS architecture also allows an LSR to distribute bindings to
LSRs that have not explicitly requested them. This is known as
"unsolicited downstream" label distribution.
It is expected that some MPLS implementations will provide only
downstream-on-demand label distribution, and some will provide only
unsolicited downstream label distribution, and some will provide
both. Which is provided may depend on the characteristics of the
interfaces which are supported by a particular implementation.
However, both of these label distribution techniques may be used in
the same network at the same time. On any given label distribution
adjacency, the upstream LSR and the downstream LSR must agree on
which technique is to be used.
3.8. Label Retention Mode
An LSR Ru may receive (or have received) a label binding for a
particular FEC from an LSR Rd, even though Rd is not Ru's next hop
(or is no longer Ru's next hop) for that FEC.
Ru then has the choice of whether to keep track of such bindings, or
whether to discard such bindings. If Ru keeps track of such
bindings, then it may immediately begin using the binding again if Rd
eventually becomes its next hop for the FEC in question. If Ru
discards such bindings, then if Rd later becomes the next hop, the
binding will have to be reacquired.
If an LSR supports "Liberal Label Retention Mode", it maintains the
bindings between a label and a FEC which are received from LSRs which
are not its next hop for that FEC. If an LSR supports "Conservative
Label Retention Mode", it discards such bindings.
Liberal label retention mode allows for quicker adaptation to routing
changes, but conservative label retention mode though requires an LSR
to maintain many fewer labels.
3.9. The Label Stack
So far, we have spoken as if a labeled packet carries only a single
label. As we shall see, it is useful to have a more general model in
which a labeled packet carries a number of labels, organized as a
last-in, first-out stack. We refer to this as a "label stack".
Although, as we shall see, MPLS supports a hierarchy, the processing
of a labeled packet is completely independent of the level of
hierarchy. The processing is always based on the top label, without
regard for the possibility that some number of other labels may have
been "above it" in the past, or that some number of other labels may
be below it at present.
An unlabeled packet can be thought of as a packet whose label stack
is empty (i.e., whose label stack has depth 0).
If a packet's label stack is of depth m, we refer to the label at the
bottom of the stack as the level 1 label, to the label above it (if
such exists) as the level 2 label, and to the label at the top of the
stack as the level m label.
The utility of the label stack will become clear when we introduce
the notion of LSP Tunnel and the MPLS Hierarchy (section 3.27).
3.10. The Next Hop Label Forwarding Entry (NHLFE)
The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
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 one
of the following operations:
a) replace the label at the top of the label stack with a
specified new label
b) pop the label stack
c) replace the label at the top of the label stack with a
specified new label, and then push one or more specified new
labels onto the label stack.
It may also contain:
d) the data link encapsulation to use when transmitting the packet
e) the way to encode the label stack when transmitting the packet
f) any other information needed in order to properly dispose of
the packet.
Note that at a given LSR, the packet's "next hop" might be that LSR
itself. In this case, the LSR would need to pop the top level label,
and then "forward" the resulting packet to itself. It would then
make another forwarding decision, based on what remains after the
label stacked is popped. This may still be a labeled packet, or it
may be the native IP packet.
This implies that in some cases the LSR may need to operate on the IP
header in order to forward the packet.
If the packet's "next hop" is the current LSR, then the label stack
operation MUST be to "pop the stack".
3.11. Incoming Label Map (ILM)
The "Incoming Label Map" (ILM) maps each incoming label to a set of
NHLFEs. It is used when forwarding packets that arrive as labeled
packets.
If the ILM maps a particular label to a set of NHLFEs that contains
more than one element, exactly one element of the set must be chosen
before the packet is forwarded. The procedures for choosing an
element from the set are beyond the scope of this document. Having
the ILM map a label to a set containing more than one NHLFE may be
useful if, e.g., it is desired to do load balancing over multiple
equal-cost paths.
3.12. FEC-to-NHLFE Map (FTN)
The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is
used when forwarding packets that arrive unlabeled, but which are to
be labeled before being forwarded.
If the FTN maps a particular label to a set of NHLFEs that contains
more than one element, exactly one element of the set must be chosen
before the packet is forwarded. The procedures for choosing an
element from the set are beyond the scope of this document. Having
the FTN map a label to a set containing more than one NHLFE may be
useful if, e.g., it is desired to do load balancing over multiple
equal-cost paths.
3.13. Label Swapping
Label swapping is the use of the following procedures to forward a
packet.
In order to forward a labeled packet, a LSR examines the label at the
top of the label stack. It uses the ILM to map this label to an
NHLFE. Using the information in the NHLFE, it determines where to
forward the packet, and performs an operation on the packet's label
stack. It then encodes the new label stack into the packet, and
forwards the result.
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
map this to an NHLFE. Using the information in the NHLFE, it
determines where to forward the packet, and performs an operation on
the packet's label stack. (Popping the label stack would, of course,
be illegal in this case.) It then encodes the new label stack into
the packet, and forwards the result.
IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT
HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE
DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE.
3.14. Scope and Uniqueness of Labels
A given LSR Rd may bind label L1 to FEC F, and distribute that
binding to label distribution peer Ru1. Rd may also bind label L2 to
FEC F, and distribute that binding to label distribution peer Ru2.
Whether or not L1 == L2 is not determined by the architecture; this
is a local matter.
A given LSR Rd may bind label L to FEC F1, and distribute that
binding to label distribution peer Ru1. Rd may also bind label L to
FEC F2, and distribute that binding to label distribution peer Ru2.
IF (AND ONLY IF) RD CAN TELL, WHEN IT RECEIVES A PACKET WHOSE TOP
LABEL IS L, WHETHER THE LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN
THE ARCHITECTURE DOES NOT REQUIRE THAT F1 == F2. In such cases, we
may say that Rd is using a different "label space" for the labels it
distributes to Ru1 than for the labels it distributes to Ru2.
In general, Rd can only tell whether it was Ru1 or Ru2 that put the
particular label value L at the top of the label stack if the
following conditions hold:
- Ru1 and Ru2 are the only label distribution peers to which Rd
distributed a binding of label value L, and
- Ru1 and Ru2 are each directly connected to Rd via a point-to-
point interface.
When these conditions hold, an LSR may use labels that have "per
interface" scope, i.e., which are only unique per interface. We may
say that the LSR is using a "per-interface label space". When these
conditions do not hold, the labels must be unique over the LSR which
has assigned them, and we may say that the LSR is using a "per-
platform label space."
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
label L to FEC F1, as well as a binding of label L to FEC F2, F1 !=
F2, if and only if each binding is valid only for packets which Ru
sends to Rd over a particular one of the interfaces. In all other
cases, Rd MUST NOT distribute to Ru bindings of the same label value
to two different FECs.
This prohibition holds even if the bindings are regarded as being at
different "levels of hierarchy". In MPLS, there is no notion of
having a different label space for different levels of the hierarchy;
when interpreting a label, the level of the label is irrelevant.
The question arises as to whether it is possible for an LSR to use
multiple per-platform label spaces, or to use multiple per-interface
label spaces for the same interface. This is not prohibited by the
architecture. However, in such cases the LSR must have some means,
not specified by the architecture, of determining, for a particular
incoming label, which label space that label belongs to. For
example, [MPLS-SHIM] specifies that a different label space is used
for unicast packets than for multicast packets, and uses a data link
layer codepoint to distinguish the two label spaces.
3.15. Label Switched Path (LSP), LSP Ingress, LSP Egress
A "Label Switched Path (LSP) of level m" for a particular packet P is
a sequence of routers,
<R1, ..., Rn>
with the following properties:
1. R1, the "LSP Ingress", is an LSR which pushes a label onto P's
label stack, resulting in a label stack of depth m;
2. For all i, 1<i<n, P has a label stack of depth m when received
by LSR Ri;
3. At no time during P's transit from R1 to R[n-1] does its label
stack ever have a depth of less than m;
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
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
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
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
on the network layer header. This may be because:
a) the decision is not based on the label stack or the network
layer header at all;
b) the decision is based on a label stack on which additional
labels have been pushed (i.e., on a level m+k label, where
k>0).
In other words, we can speak of the level m LSP for Packet P as the
sequence of routers:
1. which begins with an LSR (an "LSP Ingress") that pushes on a
level m label,
2. all of whose intermediate LSRs make their forwarding decision
by label Switching on a level m label,
3. which ends (at an "LSP Egress") when a forwarding decision is
made by label Switching on a level m-k label, where k>0, or
when a forwarding decision is made by "ordinary", non-MPLS
forwarding procedures.
A consequence (or perhaps a presupposition) of this is that whenever
an LSR pushes a label onto an already labeled packet, it needs to
make sure that the new label corresponds to a FEC whose LSP Egress is
the LSR that assigned the label which is now second in the stack.
We will call a sequence of LSRs the "LSP for a particular FEC F" if
it is an LSP of level m for a particular packet P when P's level m
label is a label corresponding to FEC F.
Consider the set of nodes which may be LSP ingress nodes for FEC F.
Then there is an LSP for FEC F which begins with each of those nodes.
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
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
"LSP tree" for a particular FEC F.
3.16. Penultimate Hop Popping
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]
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
Egress.
From an architectural perspective, this is perfectly appropriate.
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
any function, and need no longer be carried.
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,
it first looks up the top label, and determines as a result of that
lookup that it is indeed the LSP egress. Then it must pop the stack,
and examine what remains of the packet. If there is another label on
the stack, the egress will look this up and forward the packet based
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
no other label on the stack, then the packet is forwarded according
to its network layer destination address. Note that this would
require the egress to do TWO lookups, either two label lookups or a
label lookup followed by an address lookup.
If, on the other hand, penultimate hop popping is used, then when the
penultimate hop looks up the label, it determines:
- that it is the penultimate hop, and
- who the next hop is.
The penultimate node then pops the stack, and forwards the packet
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
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
decision. Or, if the packet was only carrying a single label, the
LSP egress will simply see the network layer packet, which is just
what it needs to see in order to make its forwarding decision.
This technique allows the egress to do a single lookup, and also
requires only a single lookup by the penultimate node.
The creation of the forwarding "fastpath" in a label switching
product may be greatly aided if it is known that only a single lookup
is ever required:
- the code may be simplified if it can assume that only a single
lookup is ever needed
- the code can be based on a "time budget" that assumes that only
a single lookup is ever needed.
In fact, when penultimate hop popping is done, the LSP Egress need
not even be an LSR.
However, some hardware switching engines may not be able to pop the
label stack, so this cannot be universally required. There may also
be some situations in which penultimate hop popping is not desirable.
Therefore the penultimate node pops the label stack only if this is
specifically requested by the egress node, OR if the next node in the
LSP does not support MPLS. (If the next node in the LSP does support
MPLS, but does not make such a request, the penultimate node has no
way of knowing that it in fact is the penultimate node.)
An LSR which is capable of popping the label stack at all MUST do
penultimate hop popping when so requested by its downstream label
distribution peer.
Initial label distribution protocol negotiations MUST allow each LSR
to determine whether its neighboring LSRS are capable of popping the
label stack. A LSR MUST NOT request a label distribution peer to pop
the label stack unless it is capable of doing so.
It may be asked whether the egress node can always interpret the top
label of a received packet properly if penultimate hop popping is
used. As long as the uniqueness and scoping rules of section 3.14
are obeyed, it is always possible to interpret the top label of a
received packet unambiguously.
3.17. LSP Next Hop
The LSP Next Hop for a particular labeled packet in a particular LSR
is the LSR which is the next hop, as selected by the NHLFE entry used
for forwarding that packet.
The LSP Next Hop for a particular FEC is the next hop as selected by
the NHLFE entry indexed by a label which corresponds to that FEC.
Note that the LSP Next Hop may differ from the next hop which would
be chosen by the network layer routing algorithm. We will use the
term "L3 next hop" when we refer to the latter.
3.18. Invalid Incoming Labels
What should an LSR do if it receives a labeled packet with a
particular incoming label, but has no binding for that label? It is
tempting to think that the labels can just be removed, and the packet
forwarded as an unlabeled IP packet. However, in some cases, doing
so could cause a loop. If the upstream LSR thinks the label is bound
to an explicit route, and the downstream LSR doesn't think the label
is bound to anything, and if the hop by hop routing of the unlabeled
IP packet brings the packet back to the upstream LSR, then a loop is
formed.
It is also possible that the label was intended to represent a route
which cannot be inferred from the IP header.
Therefore, when a labeled packet is received with an invalid incoming
label, it MUST be discarded, UNLESS it is determined by some means
(not within the scope of the current document) that forwarding it
unlabeled cannot cause any harm.
3.19. LSP Control: Ordered versus Independent
Some FECs correspond to address prefixes which are distributed via a
dynamic routing algorithm. The setup of the LSPs for these FECs can
be done in one of two ways: Independent LSP Control or Ordered LSP
Control.
In Independent LSP Control, each LSR, upon noting that it recognizes
a particular FEC, makes an independent decision to bind a label to
that FEC and to distribute that binding to its label distribution
peers. This corresponds to the way that conventional IP datagram
routing works; each node makes an independent decision as to how to
treat each packet, and relies on the routing algorithm to converge
rapidly so as to ensure that each datagram is correctly delivered.
In Ordered LSP Control, an LSR only binds a label to a particular FEC
if it is the egress LSR for that FEC, or if it has already received a
label binding for that FEC from its next hop for that FEC.
If one wants to ensure that traffic in a particular FEC follows a
path with some specified set of properties (e.g., that the traffic
does not traverse any node twice, that a specified amount of
resources are available to the traffic, that the traffic follows an
explicitly specified path, etc.) ordered control must be used. With
independent control, some LSRs may begin label switching a traffic in
the FEC before the LSP is completely set up, and thus some traffic in
the FEC may follow a path which does not have the specified set of
properties. Ordered control also needs to be used if the recognition
of the FEC is a consequence of the setting up of the corresponding
LSP.
Ordered LSP setup may be initiated either by the ingress or the
egress.
Ordered control and independent control are fully interoperable.
However, unless all LSRs in an LSP are using ordered control, the
overall effect on network behavior is largely that of independent
control, since one cannot be sure that an LSP is not used until it is
fully set up.
This architecture allows the choice between independent control and
ordered control to be a local matter. Since the two methods
interwork, a given LSR need support only one or the other. Generally
speaking, the choice of independent versus ordered control does not
appear to have any effect on the label distribution mechanisms which
need to be defined.
3.20. Aggregation
One way of partitioning traffic into FECs is to create a separate FEC
for each address prefix which appears in the routing table. However,
within a particular MPLS domain, this may result in a set of FECs
such that all traffic in all those FECs follows the same route. For
example, a set of distinct address prefixes might all have the same
egress node, and label swapping might be used only to get the the
traffic to the egress node. In this case, within the MPLS domain,
the union of those FECs is itself a FEC. This creates a choice:
should a distinct label be bound to each component FEC, or should a
single label be bound to the union, and that label applied to all
traffic in the union?
The procedure of binding a single label to a union of FECs which is
itself a FEC (within some domain), and of applying that label to all
traffic in the union, is known as "aggregation". The MPLS
architecture allows aggregation. Aggregation may reduce the number
of labels which are needed to handle a particular set of packets, and
may also reduce the amount of label distribution control traffic
needed.
Given a set of FECs which are "aggregatable" into a single FEC, it is
possible to (a) aggregate them into a single FEC, (b) aggregate them
into a set of FECs, or (c) not aggregate them at all. Thus we can
speak of the "granularity" of aggregation, with (a) being the
"coarsest granularity", and (c) being the "finest granularity".
When order control is used, each LSR should adopt, for a given set of
FECs, the granularity used by its next hop for those FECs.
When independent control is used, it is possible that there will be
two adjacent LSRs, Ru and Rd, which aggregate some set of FECs
differently.
If Ru has finer granularity than Rd, this does not cause a problem.
Ru distributes more labels for that set of FECs than Rd does. This
means that when Ru needs to forward labeled packets in those FECs to
Rd, it may need to map n labels into m labels, where n > m. As an
option, Ru may withdraw the set of n labels that it has distributed,
and then distribute a set of m labels, corresponding to Rd's level of
granularity. This is not necessary to ensure correct operation, but
it does result in a reduction of the number of labels distributed by
Ru, and Ru is not gaining any particular advantage by distributing
the larger number of labels. The decision whether to do this or not
is a local matter.
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),
it has two choices:
- It may adopt Rd's finer level of granularity. This would
require it to withdraw the m labels it has distributed, and
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 can determine that this will produce the same routing.
For example, suppose that Ru applies a single label to all
traffic that needs to pass through a certain egress LSR,
whereas Rd binds a number of different labels to such traffic,
depending on the individual destination addresses of the
packets. If Ru knows the address of the egress router, and if
Rd has bound a label to the FEC which is identified by that
address, then Ru can simply apply that label.
In any event, every LSR needs to know (by configuration) what
granularity to use for labels that it assigns. Where ordered control
is used, this requires each node to know the granularity only for
FECs which leave the MPLS network at that node. For independent
control, best results may be obtained by ensuring that all LSRs are
consistently configured to know the granularity for each FEC.
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
prefix in the forwarding table", or "one label per egress node").
3.21. Route Selection
Route selection refers to the method used for selecting the LSP for a
particular FEC. The proposed MPLS protocol architecture supports two
options for Route Selection: (1) hop by hop routing, and (2) explicit
routing.
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