RFC relevance of distribute

As per Relevance of the word distribute, we have this rfc below:

Network Working Group E.
Request for Comments: 3031 Cisco Systems, Inc
Category: Standards Track A.
Force10 Networks, Inc
R.
Juniper Networks, Inc
January 2001

Multiprotocol Label Switching

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2001). All Rights Reserved

This document specifies the architecture for Multiprotocol
Switching (MPLS).

Table of

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

Rosen, et al. Standards Track [Page 1]

RFC 3031 MPLS Architecture January 2001

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

Rosen, et al. Standards Track [Page 2]

RFC 3031 MPLS Architecture January 2001

4.4 MPLS and Multi-Path Routing ........................ 44
4.5 LSP Trees as Multipoint-to-Point Entities .......... 44
4.6 LSP Tunneling between BGP Border Routers ........... 45
4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 47
4.8 MPLS and Multicast ................................. 47
5 Label Distribution Procedures (Hop-by-Hop) ......... 47
5.1 The Procedures for Advertising and Using labels .... 48
5.1.1 Downstream LSR: Distribution Procedure ............. 48
5.1.1.1 PushUnconditional .................................. 49
5.1.1.2 PushConditional .................................... 49
5.1.1.3 PulledUnconditional ................................ 49
5.1.1.4 PulledConditional .................................. 50
5.1.2 Upstream LSR: Request Procedure .................... 51
5.1.2.1 RequestNever ....................................... 51
5.1.2.2 RequestWhenNeeded .................................. 51
5.1.2.3 RequestOnRequest ................................... 51
5.1.3 Upstream LSR: NotAvailable Procedure ............... 52
5.1.3.1 RequestRetry ....................................... 52
5.1.3.2 RequestNoRetry ..................................... 52
5.1.4 Upstream LSR: Release Procedure .................... 52
5.1.4.1 ReleaseOnChange .................................... 52
5.1.4.2 NoReleaseOnChange .................................. 53
5.1.5 Upstream LSR: labelUse Procedure ................... 53
5.1.5.1 UseImmediate ....................................... 53
5.1.5.2 UseIfLoopNotDetected ............................... 53
5.1.6 Downstream LSR: Withdraw Procedure ................. 53
5.2 MPLS Schemes: Supported Combinations of Procedures . 54
5.2.1 Schemes for LSRs that Support Label Merging ........ 55
5.2.2 Schemes for LSRs that do not Support Label Merging . 56
5.2.3 Interoperability Considerations .................... 57
6 Security Considerations ............................ 58
7 Intellectual Property .............................. 58
8 Authors' Addresses ................................. 59
9 References ......................................... 59
10 Full Copyright Statement ........................... 61

1.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.

2. Introduction to

This document specifies the architecture for Multiprotocol
Switching (MPLS).

Note that the use of MPLS for multicast is left for further study

Rosen, et al. Standards Track [Page 3]

RFC 3031 MPLS Architecture January 2001

2.1.

As a packet of a connectionless network layer protocol travels
one router to the next, each router makes an independent
decision for that packet. That is, each router analyzes the packet'
header, and each router runs a network layer routing algorithm.
router independently chooses a next hop for the packet, based on
analysis of the packet's header and the results of running
routing algorithm

Packet headers contain considerably more information than is
simply to choose the next hop. Choosing the next hop can
be thought of as the composition of two functions. The
function partitions the entire set of possible packets into a set
"Forwarding Equivalence Classes (FECs)". The second maps each FEC
a next hop. Insofar as the forwarding decision is concerned
different packets which get mapped into the same FEC
indistinguishable. All packets which belong to a particular FEC
which travel from a particular node will follow the same path (or
certain kinds of multi-path routing are in use, they will all
one of a set of paths associated with the FEC).

In conventional IP forwarding, a particular router will
consider two packets to be in the same FEC if there is some
prefix X in that router's routing tables such that X is the "
match" for each packet's destination address. As the
traverses the network, each hop in turn reexamines the packet
assigns it to a FEC

In MPLS, the assignment of a particular packet to a particular FEC
done just once, as the packet enters the network. The FEC to
the packet is assigned is encoded as a short fixed length value
as a "label". When a packet is forwarded to its next hop, the
is sent along with it; that is, the packets are "labeled" before
are forwarded

At subsequent hops, there is no further analysis of the packet'
network layer header. Rather, the label is used as an index into
table which specifies the next hop, and a new label. The old
is replaced with the new label, and the packet is forwarded to
next hop

In the MPLS forwarding paradigm, once a packet is assigned to a FEC
no further header analysis is done by subsequent routers;
forwarding is driven by the labels. This has a number of
over conventional network layer forwarding

Rosen, et al. Standards Track [Page 4]

RFC 3031 MPLS Architecture January 2001

- MPLS forwarding can be done by switches which are capable
doing label lookup and replacement, but are either not
of analyzing the network layer headers, or are not capable
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,
information it has about the packet, even if that
cannot be gleaned from the network layer header. For example
packets arriving on different ports may be assigned
different FECs. Conventional forwarding, on the other hand
can only consider information which travels with the packet
the packet header

- A packet that enters the network at a particular router can
labeled differently than the same packet entering the
at a different router, and as a result forwarding
that depend on the ingress router can be easily made.
cannot be done with conventional forwarding, since the
of a packet's ingress router does not travel with the packet

- The considerations that determine how a packet is assigned to
FEC can become ever more and more complicated, without
impact at all on the routers that merely forward
packets

- Sometimes it is desirable to force a packet to follow
particular route which is explicitly chosen at or before
time the packet enters the network, rather than being chosen
the normal dynamic routing algorithm as the packet
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
along with it ("source routing"). In MPLS, a label can be
to represent the route, so that the identity of the
route need not be carried with the packet

Some routers analyze a packet's network layer header not merely
choose the packet's next hop, but also to determine a packet'
"precedence" or "class of service". They may then apply
discard thresholds or scheduling disciplines to different packets
MPLS allows (but does not require) the precedence or class of
to be fully or partially inferred from the label. In this case,
may say that the label represents the combination of a FEC and
precedence or class of service

Rosen, et al. Standards Track [Page 5]

RFC 3031 MPLS Architecture January 2001

MPLS stands for "Multiprotocol" Label Switching,
because its techniques are applicable to ANY network layer protocol
In this document, however, we focus on the use of IP as the
layer protocol

A router which supports MPLS is known as a "Label Switching Router",
or LSR

2.2.

This section gives a general conceptual overview of the terms used
this document. Some of these terms are more precisely defined
later sections of the document

DLCI a label used in Frame Relay networks
identify frame relay

forwarding equivalence class a group of IP packets which
forwarded in the same manner (e.g.,
over the same path, with the
forwarding treatment

frame merge label merging, when it is applied
operation over frame based media,
that the potential problem of
interleave is not an issue

label a short fixed length
contiguous identifier which is used
identify a FEC, usually of
significance

label merging the replacement of multiple
labels for a particular FEC with
single outgoing

label swap the basic forwarding
consisting of looking up an
label to determine the outgoing label
encapsulation, port, and other
handling information

label swapping a forwarding paradigm
streamlined forwarding of data by
labels to identify classes of
packets which are
indistinguishably when forwarding

Rosen, et al. Standards Track [Page 6]

RFC 3031 MPLS Architecture January 2001

label switched hop the hop between two MPLS nodes, on
forwarding is done using labels

label switched path The path through one or more LSRs at
level of the hierarchy followed by
packets in a particular FEC

label switching router an MPLS node which is capable
forwarding native L3

layer 2 the protocol layer under layer 3 (
therefore offers the services used
layer 3). Forwarding, when done by
swapping of short fixed length labels
occurs at layer 2 regardless of
the label being examined is an
VPI/VCI, a frame relay DLCI, or an
label

layer 3 the protocol layer at which IP and
associated routing protocols
link layer synonymous with layer 2

loop detection a method of dealing with loops in
loops are allowed to be set up, and
may be transmitted over the loop,
the loop is later

loop prevention a method of dealing with loops in
data is never transmitted over a

label stack an ordered set of

merge point a node at which label merging is

MPLS domain a contiguous set of nodes which
MPLS routing and forwarding and
are also in one Routing
Administrative

MPLS edge node an MPLS node that connects an
domain with a node which is outside
the domain, either because it does
run MPLS, and/or because it is in
different domain. Note that if an
has a neighboring host which is
running MPLS, that that LSR is an
edge node

Rosen, et al. Standards Track [Page 7]

RFC 3031 MPLS Architecture January 2001

MPLS egress node an MPLS edge node in its role
handling traffic as it leaves an

MPLS ingress node an MPLS edge node in its role
handling traffic as it enters an

MPLS label a label which is carried in a
header, and which represents
packet's

MPLS node a node which is running MPLS. An
node will be aware of MPLS
protocols, will operate one or more L
routing protocols, and will be
of forwarding packets based on labels
An MPLS node may optionally be
capable of forwarding native L3 packets

MultiProtocol Label Switching an IETF working group and
effort associated with the

network layer synonymous with layer 3

stack synonymous with label

switched path synonymous with label switched

virtual circuit a circuit used by a connection-
layer 2 technology such as ATM or
Relay, requiring the maintenance
state information in layer 2 switches

VC merge label merging where the MPLS label
carried in the ATM VCI field (
combined VPI/VCI field), so as to
multiple VCs to merge into one single

VP merge label merging where the MPLS label
carried din the ATM VPI field, so as
allow multiple VPs to be merged into
single VP. In this case two cells
have the same VCI value only if
originated from the same node.
allows cells from different sources
be distinguished via the VCI

Rosen, et al. Standards Track [Page 8]

RFC 3031 MPLS Architecture January 2001

VPI/VCI a label used in ATM networks to

2.3. Acronyms and

ATM Asynchronous Transfer
BGP Border Gateway
DLCI Data Link Circuit
FEC Forwarding Equivalence
FTN FEC to NHLFE
IGP Interior Gateway
ILM Incoming Label
IP Internet
LDP Label Distribution
L2 Layer 2 L3 Layer 3
LSP Label Switched
LSR Label Switching
MPLS MultiProtocol Label
NHLFE Next Hop Label Forwarding
SVC Switched Virtual
SVP Switched Virtual
TTL Time-To-
VC Virtual
VCI Virtual Circuit
VP Virtual
VPI Virtual Path

2.4.

The ideas and text in this document have been collected from a
of sources and comments received. We would like to thank
Boivie, Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan
and George Swallow for their inputs and ideas

3. MPLS

In this section, we introduce some of the basic concepts of MPLS
describe the general approach to be used

3.1.

A label is a short, fixed length, locally significant
which is used to identify a FEC. The label which is put on
particular packet represents the Forwarding Equivalence Class
which that packet is assigned

Rosen, et al. Standards Track [Page 9]

RFC 3031 MPLS Architecture January 2001

Most commonly, a packet is assigned to a FEC based (completely
partially) on its network layer destination address. However,
label is never an encoding of that address

If Ru and Rd are LSRs, they may agree that when Ru transmits a
to Rd, Ru will label with packet with label value L if and only
the packet is a member of a particular FEC F. That is, they
agree to a "binding" between label L and FEC F for packets
from Ru to Rd. As a result of such an agreement, L becomes Ru'
"outgoing label" representing FEC F, and L becomes Rd's "
label" representing FEC F

Note that L does not necessarily represent FEC F for any
other than those which are being sent from Ru to Rd. L is
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
imply either that the packet originated at Ru or that its
is Rd. Rather, we mean to include packets which are "
packets" at one or both of the LSRs

Sometimes it may be difficult or even impossible for Rd to tell,
an arriving packet carrying label L, that the label L was placed
the packet by Ru, rather than by some other LSR. (This
typically be the case when Ru and Rd are not direct neighbors.)
such cases, Rd must make sure that the binding from label to FEC
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
FEC F2, UNLESS Rd can always tell, when it receives a packet
incoming label L, whether the label was put on the packet by Ru1
whether it was put on by Ru2.

It is the responsibility of each LSR to ensure that it can
interpret its incoming labels

3.2. Upstream and Downstream

Suppose Ru and Rd have agreed to bind label L to FEC F, for
sent from Ru to Rd. Then with respect to this binding, Ru is
"upstream LSR", and Rd is the "downstream LSR".

To say that one node is upstream and one is downstream with
to a given binding means only that a particular label represents
particular FEC in packets travelling from the upstream node to
downstream node. This is NOT meant to imply that packets in that
would actually be routed from the upstream node to the
node

Rosen, et al. Standards Track [Page 10]

RFC 3031 MPLS Architecture January 2001

3.3. Labeled

A "labeled packet" is a packet into which a label has been encoded
In some cases, the label resides in an encapsulation header
exists specifically for this purpose. In other cases, the label
reside in an existing data link or network layer header, as long
there is a field which is available for that purpose. The
encoding technique to be used must be agreed to by both the
which encodes the label and the entity which decodes the label

3.4. Label Assignment and

In the MPLS architecture, the decision to bind a particular label
to a particular FEC F is made by the LSR which is DOWNSTREAM
respect to that binding. The downstream LSR then informs
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
fall into a certain numeric range, then it merely needs to
that it only binds labels that are in that range

3.5. Attributes of a Label

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
conditions, it may be required to also distribute the
attribute that it received from Rd

3.6. Label Distribution

A label distribution protocol is a set of procedures by which one
informs another of the label/FEC bindings it has made. Two
which use a label distribution protocol to exchange label/FEC
information are known as "label distribution peers" with respect
the binding information they exchange. If two LSRs are
distribution peers, we will speak of there being a "
distribution adjacency" between them

(N.B.: two LSRs may be label distribution peers with respect to
set of bindings, but not with respect to some other set of bindings.)

The label distribution protocol also encompasses any negotiations
which two label distribution peers need to engage in order to
of each other's MPLS capabilities

Rosen, et al. Standards Track [Page 11]

RFC 3031 MPLS Architecture January 2001

THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE
DISTRIBUTION PROTOCOL. In fact, a number of different
distribution protocols are being standardized. Existing
have been extended so that label distribution can be piggybacked
them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). New
have also been defined for the explicit purpose of
labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].

In this document, we try to use the acronym "LDP" to
specifically to the protocol defined in [MPLS-LDP]; when speaking
label distribution protocols in general, we try to avoid the acronym

3.7. Unsolicited Downstream vs. Downstream-on-

The MPLS architecture allows an LSR to explicitly request, from
next hop for a particular FEC, a label binding for that FEC. This
known as "downstream-on-demand" label distribution

The MPLS architecture also allows an LSR to distribute bindings
LSRs that have not explicitly requested them. This is known
"unsolicited downstream" label distribution

It is expected that some MPLS implementations will provide
downstream-on-demand label distribution, and some will provide
unsolicited downstream label distribution, and some will
both. Which is provided may depend on the characteristics of
interfaces which are supported by a particular implementation
However, both of these label distribution techniques may be used
the same network at the same time. On any given label
adjacency, the upstream LSR and the downstream LSR must agree
which technique is to be used

3.8. Label Retention

An LSR Ru may receive (or have received) a label binding for
particular FEC from an LSR Rd, even though Rd is not Ru's next
(or is no longer Ru's next hop) for that FEC

Ru then has the choice of whether to keep track of such bindings,
whether to discard such bindings. If Ru keeps track of
bindings, then it may immediately begin using the binding again if
eventually becomes its next hop for the FEC in question. If
discards such bindings, then if Rd later becomes the next hop,
binding will have to be reacquired

Rosen, et al. Standards Track [Page 12]

RFC 3031 MPLS Architecture January 2001

If an LSR supports "Liberal Label Retention Mode", it maintains
bindings between a label and a FEC which are received from LSRs
are not its next hop for that FEC. If an LSR supports "
Label Retention Mode", it discards such bindings

Liberal label retention mode allows for quicker adaptation to
changes, but conservative label retention mode though requires an
to maintain many fewer labels

3.9. The Label

So far, we have spoken as if a labeled packet carries only a
label. As we shall see, it is useful to have a more general model
which a labeled packet carries a number of labels, organized as
last-in, first-out stack. We refer to this as a "label stack".

Although, as we shall see, MPLS supports a hierarchy, the
of a labeled packet is completely independent of the level
hierarchy. The processing is always based on the top label,
regard for the possibility that some number of other labels may
been "above it" in the past, or that some number of other labels
be below it at present

An unlabeled packet can be thought of as a packet whose label
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
bottom of the stack as the level 1 label, to the label above it (
such exists) as the level 2 label, and to the label at the top of
stack as the level m label

The utility of the label stack will become clear when we
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
a labeled packet. It contains the following information

1. the packet's next

2. the operation to perform on the packet's label stack; this is
of the following operations

a) replace the label at the top of the label stack with
specified new

b) pop the label

Rosen, et al. Standards Track [Page 13]

RFC 3031 MPLS Architecture January 2001

c) replace the label at the top of the label stack with
specified new label, and then push one or more specified
labels onto the label stack

It may also contain

d) the data link encapsulation to use when transmitting the

e) the way to encode the label stack when transmitting the

f) any other information needed in order to properly dispose
the packet

Note that at a given LSR, the packet's "next hop" might be that
itself. In this case, the LSR would need to pop the top level label
and then "forward" the resulting packet to itself. It would
make another forwarding decision, based on what remains after
label stacked is popped. This may still be a labeled packet, or
may be the native IP packet

This implies that in some cases the LSR may need to operate on the
header in order to forward the packet

If the packet's "next hop" is the current LSR, then the label
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
NHLFEs. It is used when forwarding packets that arrive as
packets

If the ILM maps a particular label to a set of NHLFEs that
more than one element, exactly one element of the set must be
before the packet is forwarded. The procedures for choosing
element from the set are beyond the scope of this document.
the ILM map a label to a set containing more than one NHLFE may
useful if, e.g., it is desired to do load balancing over
equal-cost paths

3.12. FEC-to-NHLFE Map (FTN

The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It
used when forwarding packets that arrive unlabeled, but which are
be labeled before being forwarded

Rosen, et al. Standards Track [Page 14]

RFC 3031 MPLS Architecture January 2001

If the FTN maps a particular label to a set of NHLFEs that
more than one element, exactly one element of the set must be
before the packet is forwarded. The procedures for choosing
element from the set are beyond the scope of this document.
the FTN map a label to a set containing more than one NHLFE may
useful if, e.g., it is desired to do load balancing over
equal-cost paths

3.13. Label

Label swapping is the use of the following procedures to forward
packet

In order to forward a labeled packet, a LSR examines the label at
top of the label stack. It uses the ILM to map this label to
NHLFE. Using the information in the NHLFE, it determines where
forward the packet, and performs an operation on the packet's
stack. It then encodes the new label stack into the packet,
forwards the result

In order to forward an unlabeled packet, a LSR analyzes the
layer header, to determine the packet's FEC. It then uses the FTN
map this to an NHLFE. Using the information in the NHLFE,
determines where to forward the packet, and performs an operation
the packet's label stack. (Popping the label stack would, of course
be illegal in this case.) It then encodes the new label stack
the packet, and forwards the result

IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE
HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES
DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE

3.14. Scope and Uniqueness of

A given LSR Rd may bind label L1 to FEC F, and distribute
binding to label distribution peer Ru1. Rd may also bind label L2
FEC F, and distribute that binding to label distribution peer Ru2.
Whether or not L1 == L2 is not determined by the architecture;
is a local matter

A given LSR Rd may bind label L to FEC F1, and distribute
binding to label distribution peer Ru1. Rd may also bind label L
FEC F2, and distribute that binding to label distribution peer Ru2.
IF (AND ONLY IF) RD CAN TELL, WHEN IT RECEIVES A PACKET WHOSE
LABEL IS L, WHETHER THE LABEL WAS PUT THERE BY RU1 OR BY RU2,
THE ARCHITECTURE DOES NOT REQUIRE THAT F1 == F2. In such cases,
may say that Rd is using a different "label space" for the labels
distributes to Ru1 than for the labels it distributes to Ru2.

Rosen, et al. Standards Track [Page 15]

RFC 3031 MPLS Architecture January 2001

In general, Rd can only tell whether it was Ru1 or Ru2 that put
particular label value L at the top of the label stack if
following conditions hold

- Ru1 and Ru2 are the only label distribution peers to which
distributed a binding of label value L,

- 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 "
interface" scope, i.e., which are only unique per interface. We
say that the LSR is using a "per-interface label space". When
conditions do not hold, the labels must be unique over the LSR
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
point-to-point interfaces, then Rd may distribute to Ru a binding
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
sends to Rd over a particular one of the interfaces. In all
cases, Rd MUST NOT distribute to Ru bindings of the same label
to two different FECs

This prohibition holds even if the bindings are regarded as being
different "levels of hierarchy". In MPLS, there is no notion
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
multiple per-platform label spaces, or to use multiple per-
label spaces for the same interface. This is not prohibited by
architecture. However, in such cases the LSR must have some means
not specified by the architecture, of determining, for a
incoming label, which label space that label belongs to.
example, [MPLS-SHIM] specifies that a different label space is
for unicast packets than for multicast packets, and uses a data
layer codepoint to distinguish the two label spaces

3.15. Label Switched Path (LSP), LSP Ingress, LSP

A "Label Switched Path (LSP) of level m" for a particular packet P
a sequence of routers

with the following properties

Rosen, et al. Standards Track [Page 16]

RFC 3031 MPLS Architecture January 2001

1. R1, the "LSP Ingress", is an LSR which pushes a label onto P'
label stack, resulting in a label stack of depth m

2. For all i, 1 by LSR Ri

3. At no time during P's transit from R1 to R[n-1] does its
stack ever have a depth of less than m

4. For all i, 1 i.e., by using the label at the top of the label stack (
level m label) as an index into an ILM

5. For all i, 1receives and forwards P after
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
subnetwork, and S might be one of the data link switches),
S's forwarding decision is not based on the level m label,
on the network layer header. This may be because

a) the decision is not based on the label stack or the
layer header at all

b) the decision is based on a label stack on which
labels have been pushed (i.e., on a level m+k label,
k>0).

In other words, we can speak of the level m LSP for Packet P as
sequence of routers

1. which begins with an LSR (an "LSP Ingress") that pushes on
level m label

2. all of whose intermediate LSRs make their forwarding
by label Switching on a level m label

3. which ends (at an "LSP Egress") when a forwarding decision
made by label Switching on a level m-k label, where k>0,
when a forwarding decision is made by "ordinary", non-
forwarding procedures

A consequence (or perhaps a presupposition) of this is that
an LSR pushes a label onto an already labeled packet, it needs
make sure that the new label corresponds to a FEC whose LSP Egress
the LSR that assigned the label which is now second in the stack

Rosen, et al. Standards Track [Page 17]

RFC 3031 MPLS Architecture January 2001

We will call a sequence of LSRs the "LSP for a particular FEC F"
it is an LSP of level m for a particular packet P when P's level
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
consider the set of such LSPs to be a tree, whose root is the
egress. (Since data travels along this tree towards the root,
may be called a multipoint-to-point tree.) We can thus speak of
"LSP tree" for a particular FEC F

3.16. Penultimate Hop

Note that according to the definitions of section 3.15, if 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
be popped at the penultimate LSR of the LSP, rather than at the
Egress

From an architectural perspective, this is perfectly appropriate
The purpose of the level m label is to get the packet to Rn.
R[n-1] has decided to send the packet to Rn, the label no longer
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
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
the stack, the egress will look this up and forward the packet
on this lookup. (In this case, the egress for the packet's level
LSP is also an intermediate node for its level m-1 LSP.) If there
no other label on the stack, then the packet is forwarded
to its network layer destination address. Note that this
require the egress to do TWO lookups, either two label lookups or
label lookup followed by an address lookup

If, on the other hand, penultimate hop popping is used, then when
penultimate hop looks up the label, it determines

- that it is the penultimate hop,

- who the next hop is

The penultimate node then pops the stack, and forwards the
based on the information gained by looking up the label that
previously at the top of the stack. When the LSP egress receives

Rosen, et al. Standards Track [Page 18]

RFC 3031 MPLS Architecture January 2001

packet, the label which is now at the top of the stack will be
label which it needs to look up in order to make its own
decision. Or, if the packet was only carrying a single label,
LSP egress will simply see the network layer packet, which is
what it needs to see in order to make its forwarding decision

This technique allows the egress to do a single lookup, and
requires only a single lookup by the penultimate node

The creation of the forwarding "fastpath" in a label
product may be greatly aided if it is known that only a single
is ever required

- the code may be simplified if it can assume that only a
lookup is ever

- the code can be based on a "time budget" that assumes that
a single lookup is ever needed

In fact, when penultimate hop popping is done, the LSP Egress
not even be an LSR

However, some hardware switching engines may not be able to pop
label stack, so this cannot be universally required. There may
be some situations in which penultimate hop popping is not desirable
Therefore the penultimate node pops the label stack only if this
specifically requested by the egress node, OR if the next node in
LSP does not support MPLS. (If the next node in the LSP does
MPLS, but does not make such a request, the penultimate node has
way of knowing that it in fact is the penultimate node.)

An LSR which is capable of popping the label stack at all MUST
penultimate hop popping when so requested by its downstream
distribution peer

Initial label distribution protocol negotiations MUST allow each
to determine whether its neighboring LSRS are capable of popping
label stack. A LSR MUST NOT request a label distribution peer to
the label stack unless it is capable of doing so

It may be asked whether the egress node can always interpret the
label of a received packet properly if penultimate hop popping
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
received packet unambiguously

Rosen, et al. Standards Track [Page 19]

RFC 3031 MPLS Architecture January 2001

3.17. LSP Next

The LSP Next Hop for a particular labeled packet in a particular
is the LSR which is the next hop, as selected by the NHLFE entry
for forwarding that packet

The LSP Next Hop for a particular FEC is the next hop as selected
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
be chosen by the network layer routing algorithm. We will use
term "L3 next hop" when we refer to the latter

3.18. Invalid Incoming

What should an LSR do if it receives a labeled packet with
particular incoming label, but has no binding for that label? It
tempting to think that the labels can just be removed, and the
forwarded as an unlabeled IP packet. However, in some cases,
so could cause a loop. If the upstream LSR thinks the label is
to an explicit route, and the downstream LSR doesn't think the
is bound to anything, and if the hop by hop routing of the
IP packet brings the packet back to the upstream LSR, then a loop
formed

It is also possible that the label was intended to represent a
which cannot be inferred from the IP header

Therefore, when a labeled packet is received with an invalid
label, it MUST be discarded, UNLESS it is determined by some
(not within the scope of the current document) that forwarding
unlabeled cannot cause any harm

3.19. LSP Control: Ordered versus

Some FECs correspond to address prefixes which are distributed via
dynamic routing algorithm. The setup of the LSPs for these FECs
be done in one of two ways: Independent LSP Control or Ordered
Control

In Independent LSP Control, each LSR, upon noting that it
a particular FEC, makes an independent decision to bind a label
that FEC and to distribute that binding to its label
peers. This corresponds to the way that conventional IP
routing works; each node makes an independent decision as to how
treat each packet, and relies on the routing algorithm to
rapidly so as to ensure that each datagram is correctly delivered

Rosen, et al. Standards Track [Page 20]

RFC 3031 MPLS Architecture January 2001

In Ordered LSP Control, an LSR only binds a label to a particular
if it is the egress LSR for that FEC, or if it has already received
label binding for that FEC from its next hop for that FEC

If one wants to ensure that traffic in a particular FEC follows
path with some specified set of properties (e.g., that the
does not traverse any node twice, that a specified amount
resources are available to the traffic, that the traffic follows
explicitly specified path, etc.) ordered control must be used.
independent control, some LSRs may begin label switching a traffic
the FEC before the LSP is completely set up, and thus some traffic
the FEC may follow a path which does not have the specified set
properties. Ordered control also needs to be used if the
of the FEC is a consequence of the setting up of the
LSP

Ordered LSP setup may be initiated either by the ingress or
egress

Ordered control and independent control are fully interoperable
However, unless all LSRs in an LSP are using ordered control,
overall effect on network behavior is largely that of
control, since one cannot be sure that an LSP is not used until it
fully set up

This architecture allows the choice between independent control
ordered control to be a local matter. Since the two
interwork, a given LSR need support only one or the other.
speaking, the choice of independent versus ordered control does
appear to have any effect on the label distribution mechanisms
need to be defined

3.20.

One way of partitioning traffic into FECs is to create a separate
for each address prefix which appears in the routing table. However
within a particular MPLS domain, this may result in a set of
such that all traffic in all those FECs follows the same route.
example, a set of distinct address prefixes might all have the
egress node, and label swapping might be used only to get 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
single label be bound to the union, and that label applied to
traffic in the union

The procedure of binding a single label to a union of FECs which
itself a FEC (within some domain), and of applying that label to

Rosen, et al. Standards Track [Page 21]

RFC 3031 MPLS Architecture January 2001

traffic in the union, is known as "aggregation". The
architecture allows aggregation. Aggregation may reduce the
of labels which are needed to handle a particular set of packets,
may also reduce the amount of label distribution control
needed

Given a set of FECs which are "aggregatable" into a single FEC, it
possible to (a) aggregate them into a single FEC, (b) aggregate
into a set of FECs, or (c) not aggregate them at all. Thus we
speak of the "granularity" of aggregation, with (a) being
"coarsest granularity", and (c) being the "finest granularity".

When order control is used, each LSR should adopt, for a given set
FECs, the granularity used by its next hop for those FECs

When independent control is used, it is possible that there will
two adjacent LSRs, Ru and Rd, which aggregate some set of
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.
means that when Ru needs to forward labeled packets in those FECs
Rd, it may need to map n labels into m labels, where n > m. As
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
granularity. This is not necessary to ensure correct operation,
it does result in a reduction of the number of labels distributed
Ru, and Ru is not gaining any particular advantage by
the larger number of labels. The decision whether to do this or
is a local matter

If Ru has coarser granularity than Rd (i.e., Rd has distributed
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
require it to withdraw the m labels it has distributed,
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
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
packets. If Ru knows the address of the egress router, and
Rd has bound a label to the FEC which is identified by
address, then Ru can simply apply that label

Rosen, et al. Standards Track [Page 22]

RFC 3031 MPLS Architecture January 2001

In any event, every LSR needs to know (by configuration)
granularity to use for labels that it assigns. Where ordered
is used, this requires each node to know the granularity only
FECs which leave the MPLS network at that node. For
control, best results may be obtained by ensuring that all LSRs
consistently configured to know the granularity for each FEC
However, in many cases this may be done by using a single level
granularity which applies to all FECs (such as "one label per
prefix in the forwarding table", or "one label per egress node").

3.21. Route

Route selection refers to the method used for selecting the LSP for
particular FEC. The proposed MPLS protocol architecture supports
options for Route Selection: (1) hop by hop routing, and (2)
routing

Hop by hop routing allows each node to independently choose the
hop for each FEC. This is the usual mode today in existing
networks. A "hop by hop routed LSP" is an LSP whose route
selected using hop by hop routing

In an explicitly routed LSP, each LSR does not independently
the next hop; rather, a single LSR, generally the LSP ingress or
LSP egress, specifies several (or all) of the LSRs in the LSP. If
single LSR specifies the entire LSP, the LSP is "strictly"
routed. If a single LSR specifies only some of the LSP, the LSP
"loosely" explicitly routed

The sequence of LSRs followed by an explicitly routed LSP may
chosen by configuration, or may be selected dynamically by a
node (for example, the egress node may make use of the
information learned from a link state database in order to
the entire path for the tree ending at that egress node).

Explicit routing may be useful for a number of purposes, such
policy routing or traffic engineering. In MPLS, the explicit
needs to be specified at the time that labels are assigned, but
explicit route does not have to be specified with each IP packet
This makes MPLS explicit routing much more efficient than
alternative of IP source routing

The procedures for making use of explicit routes, either strict
loose, are beyond the scope of this document

Rosen, et al. Standards Track [Page 23]

RFC 3031 MPLS Architecture January 2001

3.22. Lack of Outgoing

When a labeled packet is traveling along an LSP, it may
happen that it reaches an LSR at which the ILM does not map
packet's incoming label into an NHLFE, even though the incoming
is itself valid. This can happen due to transient conditions, or
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
to forward the packet further via conventional forwarding, based
its network layer header. However, in general this is not a
procedure

- If the packet has been following an explicitly routed LSP,
could result in a loop

- The packet's network header may not contain enough
to enable this particular LSR to forward it correctly

Unless it can be determined (through some means outside the scope
this document) that neither of these situations obtains, the
safe procedure is to discard the packet

3.23. Time-to-Live (TTL

In conventional IP forwarding, each packet carries a "Time To Live
(TTL) value in its header. Whenever a packet passes through
router, its TTL gets decremented by 1; if the TTL reaches 0
the packet has reached its destination, the packet gets discarded

This provides some level of protection against forwarding loops
may exist due to misconfigurations, or due to failure or
convergence of the routing algorithm. TTL is sometimes used
other functions as well, such as multicast scoping, and
the "traceroute" command. This implies that there are two TTL
related issues that MPLS needs to deal with: (i) TTL as a way
suppress loops; (ii) TTL as a way to accomplish other functions,
as limiting the scope of a packet

When a packet travels along an LSP, it SHOULD emerge with the
TTL value that it would have had if it had traversed the
sequence of routers without having been label switched. If
packet travels along a hierarchy of LSPs, the total number of LSR
hops traversed SHOULD be reflected in its TTL value when it
from the hierarchy of LSPs

Rosen, et al. Standards Track [Page 24]

RFC 3031 MPLS Architecture January 2001

The way that TTL is handled may vary depending upon whether the
label values are carried in an MPLS-specific "shim" header [MPLS
SHIM], or if the MPLS labels are carried in an L2 header, such as
ATM header [MPLS-ATM] or a frame relay header [MPLS-FRMRLY].

If the label values are encoded in a "shim" that sits between
data link and network layer headers, then this shim MUST have a
field that SHOULD be initially loaded from the network layer
TTL field, SHOULD be decremented at each LSR-hop, and SHOULD
copied into the network layer header TTL field when the
emerges from its LSP

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
forwarded by an L2 switch (e.g., an ATM switch), and the data
layer (like ATM) does not itself have a TTL field, then it will
be possible to decrement a packet's TTL at each LSR-hop. An
segment which consists of a sequence of LSRs that cannot decrement
packet's TTL will be called a "non-TTL LSP segment".

When a packet emerges from a non-TTL LSP segment, it SHOULD
be given a TTL that reflects the number of LSR-hops it traversed.
the unicast case, this can be achieved by propagating a
LSP length to ingress nodes, enabling the ingress to decrement
TTL value before forwarding packets into a non-TTL LSP segment

Sometimes it can be determined, upon ingress to a non-TTL
segment, that a particular packet's TTL will expire before the
reaches the egress of that non-TTL LSP segment. In this case,
LSR at the ingress to the non-TTL LSP segment must not label
the packet. This means that special procedures must be developed
support traceroute functionality, for example, traceroute packets
be forwarded using conventional hop by hop forwarding

3.24. Loop

On a non-TTL LSP segment, by definition, TTL cannot be used
protect against forwarding loops. The importance of loop control
depend on the particular hardware being used to provide the
functions along the non-TTL LSP segment

Suppose, for instance, that ATM switching hardware is being used
provide MPLS switching functions, with the label being carried in
VPI/VCI field. Since ATM switching hardware cannot decrement TTL
there is no protection against loops. If the ATM hardware is
of providing fair access to the buffer pool for incoming
carrying different VPI/VCI values, this looping may not have
deleterious effect on other traffic. If the ATM hardware

Rosen, et al. Standards Track [Page 25]

RFC 3031 MPLS Architecture January 2001

provide fair buffer access of this sort, however, then even
loops may cause severe degradation of the LSR's total performance

Even if fair buffer access can be provided, it is still worthwhile
have some means of detecting loops that last "longer than possible".
In addition, even where TTL and/or per-VC fair queuing provides
means for surviving loops, it still may be desirable where
to avoid setting up LSPs which loop. All LSRs that may attach
non-TTL LSP segments will therefore be required to support a
technique for loop detection; however, use of the loop
technique is optional. The loop detection technique is specified
[MPLS-ATM] and [MPLS-LDP].

3.25. Label

In order to transmit a label stack along with the packet whose
stack it is, it is necessary to define a concrete encoding of
label stack. The architecture supports several different
techniques; the choice of encoding technique depends on
particular kind of device being used to forward labeled packets

3.25.1. MPLS-specific Hardware and/or

If one is using MPLS-specific hardware and/or software to
labeled packets, the most obvious way to encode the label stack is
define a new protocol to be used as a "shim" between the data
layer and network layer headers. This shim would really be just
encapsulation of the network layer packet; it would be "protocol
independent" such that it could be used to encapsulate any
layer. Hence we will refer to it as the "generic
encapsulation".

The generic MPLS encapsulation would in turn be encapsulated in
data link layer protocol

The MPLS generic encapsulation is specified in [MPLS-SHIM].

3.25.2. ATM Switches as

It will be noted that MPLS forwarding procedures are similar to
of legacy "label swapping" switches such as ATM switches.
switches use the input port and the incoming VPI/VCI value as
index into a "cross-connect" table, from which they obtain an
port and an outgoing VPI/VCI value. Therefore if one or more
can be encoded directly into the fields which are accessed by
legacy switches, then the legacy switches can, with suitable
upgrades, be used as LSRs. We will refer to such devices as "ATM
LSRs".

Rosen, et al. Standards Track [Page 26]

RFC 3031 MPLS Architecture January 2001

There are three obvious ways to encode labels in the ATM cell
(presuming the use of AAL5):

1. SVC

Use the VPI/VCI field to encode the label which is at the
of the label stack. This technique can be used in any network
With this encoding technique, each LSP is realized as an
SVC, and the label distribution protocol becomes the
"signaling" protocol. With this encoding technique, the ATM
LSRs cannot perform "push" or "pop" operations on the
stack

2. SVP

Use the VPI field to encode the label which is at the top
the label stack, and the VCI field to encode the second
on the stack, if one is present. This technique
advantages over the previous one, in that it permits the use
ATM "VP-switching". That is, the LSPs are realized as
SVPs, with the label distribution protocol serving as the
signaling protocol

However, this technique cannot always be used. If the
includes an ATM Virtual Path through a non-MPLS ATM network
then the VPI field is not necessarily available for use
MPLS

When this encoding technique is used, the ATM-LSR at the
of the VP effectively does a "pop" operation

3. SVP Multipoint

Use the VPI field to encode the label which is at the top
the label stack, use part of the VCI field to encode the
label on the stack, if one is present, and use the remainder
the VCI field to identify the LSP ingress. If this
is used, conventional ATM VP-switching capabilities can be
to provide multipoint-to-point VPs. Cells from
packets will then carry different VCI values. As we shall
in section 3.26, this enables us to do label merging,
running into any cell interleaving problems, on ATM
which can provide multipoint-to-point VPs, but which do
have the VC merge capability

This technique depends on the existence of a capability
assigning 16-bit VCI values to each ATM switch such that
single VCI value is assigned to two different switches. (If

Rosen, et al. Standards Track [Page 27]

RFC 3031 MPLS Architecture January 2001

adequate number of such values could be assigned to
switch, it would be possible to also treat the VCI value as
second label in the stack.)

If there are more labels on the stack than can be encoded in the
header, the ATM encodings must be combined with the
encapsulation

3.25.3. Interoperability among Encoding

If is a segment of a LSP, it is possible that R1
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
R3. In general, the MPLS architecture supports LSPs with
label stack encodings used on different hops. Therefore, when
discuss the procedures for processing a labeled packet, we speak
abstract terms of operating on the packet's label stack. When
labeled packet is received, the LSR must decode it to determine
current value of the label stack, then must operate on the
stack to determine the new value of the stack, and then encode
new value appropriately before transmitting the labeled packet to
next hop

Unfortunately, ATM switches have no capability for translating
one encoding technique to another. The MPLS architecture
requires that whenever it is possible for two ATM switches to
successive LSRs along a level m LSP for some packet, that those
ATM switches use the same encoding technique

Naturally there will be MPLS networks which contain a combination
ATM switches operating as LSRs, and other LSRs which operate using
MPLS shim header. In such networks there may be some LSRs which
ATM interfaces as well as "MPLS Shim" interfaces. This is
example of an LSR with different label stack encodings on
hops. Such an LSR may swap off an ATM encoded label stack on
incoming interface and replace it with an MPLS shim header
label stack on the outgoing interface

3.26. Label

Suppose that an LSR has bound multiple incoming labels to
particular FEC. When forwarding packets in that FEC, one would
to have a single outgoing label which is applied to all such packets
The fact that two different packets in the FEC arrived with
incoming labels is irrelevant; one would like to forward them
the same outgoing label. The capability to do so is known as "
merging".

Rosen, et al. Standards Track [Page 28]

RFC 3031 MPLS Architecture January 2001

Let us say that an LSR is capable of label merging if it can
two packets from different incoming interfaces, and/or with
labels, and send both packets out the same outgoing interface
the same label. Once the packets are transmitted, the
that they arrived from different interfaces and/or with
incoming labels is lost

Let us say that an LSR is not capable of label merging if, for
two packets which arrive from different interfaces, or with
labels, the packets must either be transmitted out
interfaces, or must have different labels. ATM-LSRs using the SVC
SVP Encodings cannot perform label merging. This is discussed
more detail in the next section

If a particular LSR cannot perform label merging, then if two
in the same FEC arrive with different incoming labels, they must
forwarded with different outgoing labels. With label merging,
number of