WDIFF

draft-ietf-mpls-arch-00.txt --> draft-ietf-mpls-arch-01.txt

Network Working Group Eric C. Rosen
Internet Draft Cisco Systems, Inc.
Expiration Date: February September 1998
Arun Viswanathan
IBM Corp.
Lucent Technologies

Ross Callon
Ascend Communications,
IronBridge Networks, Inc.

August 1997

A Proposed

March 1998

Multiprotocol Label Switching Architecture for MPLS

draft-ietf-mpls-arch-00.txt

draft-ietf-mpls-arch-01.txt

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

To learn view the current status entire list of any Internet-Draft, current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ds.internic.net ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).

Abstract

This internet draft contains a draft protocol specifies the architecture for multiprotocol
label switching (MPLS). The proposed architecture is based on other label
switching approaches [2-11] as well as on the MPLS Framework document
[1].

Rosen, Viswanathan & Callon [Page 1]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997 draft-ietf-mpls-arch-01.txt March 1998

Table of Contents

1 Introduction to MPLS ............................... 3 4
1.1 Overview ........................................... 3 4
1.2 Terminology ........................................ 5 6
1.3 Acronyms and Abbreviations ......................... 9
1.4 Acknowledgments .................................... 10
2 Outline of Approach ................................ 10 11
2.1 Labels ............................................. 10 11
2.2 Upstream and Downstream LSRs ....................... 11 12
2.3 Labeled Packet ..................................... 11 12
2.4 Label Assignment and Distribution; Attributes ...... 11 12
2.5 Label Distribution Protocol (LDP) .................. 12 13
2.6 The Label Stack .................................... 12 13
2.7 The Next Hop Label Forwarding Entry (NHLFE) ........ 13 14
2.8 Incoming Label Map (ILM) ........................... 13 14
2.9 Stream-to-NHLFE Map (STN) .......................... 13 15
2.10 Label Swapping ..................................... 14 15
2.11 Scope and Uniqueness of Labels ..................... 15
2.12 Label Switched Path (LSP), LSP Ingress, LSP Egress . 14
2.12 16
2.13 Penultimate Hop Popping ............................ 18
2.14 LSP Next Hop ....................................... 16
2.13 19
2.15 Route Selection .................................... 17
2.14 20
2.16 Time-to-Live (TTL) ................................. 18
2.15 21
2.17 Loop Control ....................................... 19
2.15.1 22
2.17.1 Loop Prevention .................................... 20
2.15.2 23
2.17.2 Interworking of Loop Control Options ............... 22
2.16 25
2.18 Merging and Non-Merging LSRs ....................... 23
2.16.1 26
2.18.1 Stream Merge ....................................... 24
2.16.2 27
2.18.2 Non-merging LSRs ................................... 24
2.16.3 27
2.18.3 Labels for Merging and Non-Merging LSRs ............ 25
2.16.4 28
2.18.4 Merge over ATM ..................................... 26
2.16.4.1 29
2.18.4.1 Methods of Eliminating Cell Interleave ............. 26
2.16.4.2 29
2.18.4.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 26
2.17 29
2.19 LSP Control: Egress versus Local ................... 27
2.18 30
2.20 Granularity ........................................ 29
2.19 32
2.21 Tunnels and Hierarchy .............................. 30
2.19.1 33
2.21.1 Hop-by-Hop Routed Tunnel ........................... 30
2.19.2 33
2.21.2 Explicitly Routed Tunnel ........................... 30
2.19.3 33
2.21.3 LSP Tunnels ........................................ 30
2.19.4 33
2.21.4 Hierarchy: LSP Tunnels within LSPs ................. 31
2.19.5 34
2.21.5 LDP Peering and Hierarchy .......................... 31
2.20 34
2.22 LDP Transport ...................................... 33
2.21 36
2.23 Label Encodings .................................... 33
2.21.1 36
2.23.1 MPLS-specific Hardware and/or Software ............. 33
2.21.2 36
2.23.2 ATM Switches as LSRs ............................... 34
2.21.3 Interoperability among Encoding Techniques ......... 35
2.22 Multicast .......................................... 36 37

Rosen, Viswanathan & Callon [Page 2]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997 draft-ietf-mpls-arch-01.txt March 1998

2.23.3 Interoperability among Encoding Techniques ......... 38
2.24 Multicast .......................................... 39
3 Some Applications of MPLS .......................... 36 39
3.1 MPLS and Hop by Hop Routed Traffic ................. 36 39
3.1.1 Labels for Address Prefixes ........................ 36 39
3.1.2 Distributing Labels for Address Prefixes ........... 36 39
3.1.2.1 LDP Peers for a Particular Address Prefix .......... 36 39
3.1.2.2 Distributing Labels ................................ 37 40
3.1.3 Using the Hop by Hop path as the LSP ............... 38 41
3.1.4 LSP Egress and LSP Proxy Egress .................... 38 41
3.1.5 The POP Label ...................................... 39 42
3.1.6 Option: Egress-Targeted Label Assignment ........... 40 43
3.2 MPLS and Explicitly Routed LSPs .................... 41 44
3.2.1 Explicitly Routed LSP Tunnels: Traffic Engineering . 42 44
3.3 Label Stacks and Implicit Peering .................. 42 45
3.4 MPLS and Multi-Path Routing ........................ 43 46
3.5 LSPs may be LSP Trees as Multipoint-to-Point Entities ........... 44 .......... 46
3.6 LSP Tunneling between BGP Border Routers ........... 44 47
3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 46 49
3.8 MPLS and Multicast ................................. 46 49
4 LDP Procedures for Hop-by-Hop Routed Traffic ....... 50
4.1 The Procedures for Advertising and Using labels .... 50
4.1.1 Downstream LSR: Distribution Procedure ............. 50
4.1.1.1 PushUnconditional .................................. 51
4.1.1.2 PushConditional .................................... 51
4.1.1.3 PulledUnconditional ................................ 52
4.1.1.4 PulledConditional .................................. 52
4.1.2 Upstream LSR: Request Procedure .................... 53
4.1.2.1 RequestNever ....................................... 53
4.1.2.2 RequestWhenNeeded .................................. 53
4.1.2.3 RequestOnRequest ................................... 53
4.1.3 Upstream LSR: NotAvailable Procedure ............... 54
4.1.3.1 RequestRetry ....................................... 54
4.1.3.2 RequestNoRetry ..................................... 47
5 Security Considerations ............................ 47
6 Authors' Addresses ................................. 47
7 References ......................................... 47
Appendix A Why Egress Control is Better ....................... 48
Appendix B Why Local Control is Better ........................ 54
4.1.4 Upstream LSR: Release Procedure .................... 54
4.1.4.1 ReleaseOnChange .................................... 54
4.1.4.2 NoReleaseOnChange .................................. 54
4.1.5 Upstream LSR: labelUse Procedure ................... 55
4.1.5.1 UseImmediate ....................................... 55
4.1.5.2 UseIfLoopFree ...................................... 55
4.1.5.3 UseIfLoopNotDetected ............................... 55
4.1.6 Downstream LSR: Withdraw Procedure ................. 56

1. Introduction to
4.2 MPLS

1.1. Overview

In connectionless network layer protocols, as a packet Schemes: Supported Combinations of Procedures . 56
4.2.1 TTL-capable LSP Segments ........................... 57
4.2.2 Using ATM Switches as LSRs ......................... 57
4.2.2.1 Without Multipoint-to-point Capability ............. 58
4.2.2.2 With Multipoint-To-Point Capability ................ 58
4.2.3 Interoperability Considerations .................... 59

Rosen, Viswanathan & Callon [Page 3]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

4.2.4 How to do Loop Prevention .......................... 60
4.2.5 How to do Loop Detection ........................... 60
4.2.6 Security Considerations ............................ 60
5 Authors' Addresses ................................. 60
6 References ......................................... 61

1. Introduction to MPLS

1.1. Overview

In connectionless network layer protocols, as a packet travels from
one router hop to the next, an independent forwarding decision is
made at each hop. Each router analyzes the packet header, and runs a network layer routing
algorithm. As a packet travels through the network, each router
analyzes the packet header. The choice of next hop for a packet is chosen
based on the header analysis and the result 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 packet forwarding space set of possible packets into "forwarding
equivalence classes a set of
"Forwarding Equivalence Classes (FECs)". The second maps these FECs each FEC to
a next hop. Multiple network layer headers Insofar as the forwarding decision is concerned,
different packets which get mapped into the same FEC are indistinguishable, as far as the forwarding decision is
concerned. The set of
indistinguishable. All packets belonging which belong to the same FEC, traveling a particular FEC and
which travel from a common node, particular node will follow the same path and be forwarded in the

Rosen, Viswanathan & Callon [Page 3]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

same manner (for example, by being placed in path. Such
a common queue) towards
the destination. This set of packets following the same path,
belonging to the same FEC (and therefore being forwarded in a common
manner) may be referred to as called a "stream".

In conventional IP forwarding, multiple packets are a particular router will typically assigned
consider two packets to be in the same
Stream by a particular router stream 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 stream.

In MPLS, the mapping from assignment of a particular packet headers to a particular stream
is performed done just once, as the packet enters the network. The stream to
which the packet is assigned is encoded with 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".

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

Rosen, Viswanathan & Callon [Page 4]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

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. This
eliminates the need If assignment to perform a longest match computation stream is based on a "longest match",
this eliminates the need to perform a longest match computation for
each packet at each hop; the computation can be performed just once.

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", in order to apply different
discard thresholds or scheduling disciplines to different packets. In
MPLS, this can also
MPLS allows the precedence or class of service to be inferred from
the label, so that no further header analysis is needed. needed; in some
cases MPLS provides a way to explicitly encode a class of service in
the "label header".

The fact that a packet is assigned to a Stream stream just once, rather than
at every hop, allows the use of sophisticated forwarding paradigms.
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 point ("policy routing") can be easily made. In fact,
the policy used to assign a packet to a Stream stream need not have only the
network layer header as input; it may use arbitrary information about
the packet, and/or arbitrary policy information as input. Since this
decouples forwarding from routing, it allows one to use MPLS to
support a large variety of routing policies that are difficult or
impossible to support with just conventional network layer
forwarding.

Similarly, MPLS facilitates the use of explicit routing, without
requiring that each IP packet carry the explicit route. Explicit
routes may be useful to support policy routing and traffic
engineering.

Rosen, Viswanathan & Callon [Page 4]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

MPLS makes use of a routing approach whereby the normal mode of
operation is that L3 routing (e.g., existing IP routing protocols
and/or new IP routing protocols) is used by all nodes to determine
the routed path.

MPLS stands for "Multiprotocol" Label Switching, multiprotocol
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.

A general discussion of issues related to MPLS is presented in "A

Rosen, Viswanathan & Callon [Page 5]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

Framework for Multiprotocol Label Switching" [1].

1.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.

aggregate stream synonym of "stream"

DLCI a label used in Frame Relay networks to
identify frame relay circuits

flow a single instance of an application to
application flow of data (as in the RSVP
and IFMP use of the term "flow")

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

frame merge stream merge, 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 stream, usually of local
significance.

Rosen, Viswanathan & Callon [Page 5]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

label information base the database of information containing
label bindings

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 streams of data to be
forwarded.

Rosen, Viswanathan & Callon [Page 6]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

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

label switched path the path created by the concatenation of
one or more label switched hops, allowing
a packet to be forwarded by swapping
labels from an MPLS node to another MPLS
node.

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 and closed

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

label stack an ordered set of labels

Rosen, Viswanathan & Callon [Page 6]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

loop survival a method of dealing with loops in which
data may be transmitted over a loop, but
means are employed to limit the amount of
network resources which may be consumed
by the looping data

label switched path The path through one or more LSRs at one
level of the hierarchy followed by a
stream.

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

Rosen, Viswanathan & Callon [Page 7]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

merge point the node at which multiple streams and
switched paths are combined into a single
stream sent over a single path.

Mlabel abbreviation for MPLS label

MPLS core standards the standards which describe the core
MPLS technology

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 placed in a short MPLS shim
header used to identify streams

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

Rosen, Viswanathan & Callon [Page 7]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997
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

Rosen, Viswanathan & Callon [Page 8]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

stream an aggregate of one or more flows,
treated as one aggregate for the purpose
of forwarding in L2 and/or L3 nodes
(e.g., may be described using a single
label). In many cases a stream may be the
aggregate of a very large number of
flows. Synonymous with "aggregate
stream".

stream merge the merging of several smaller streams
into a larger stream, such that for some
or all of the path the larger stream can
be referred to using a single label.

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 stream merge when it is specifically
applied to VCs, specifically so as to
allow multiple VCs to merge into one
single VC

VP merge stream merge when it is applied to VPs,
specifically so as to allow multiple VPs
to merge into one single VP. In this case
the VCIs need to be unique. This allows
cells from different sources to be
distinguished via the VCI.

VPI/VCI a label used in ATM networks to identify
circuits

Rosen, Viswanathan & Callon [Page 8]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

1.3. Acronyms and Abbreviations

ATM Asynchronous Transfer Mode

BGP Border Gateway Protocol

DLCI Data Link Circuit Identifier

FEC Forwarding Equivalence Class

STN Stream stream to NHLFE Map

Rosen, Viswanathan & Callon [Page 9]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

IGP Interior Gateway Protocol

ILM Incoming Label Map

IP Internet Protocol

LIB Label Information Base

LDP Label Distribution Protocol

L2 Layer 2

L3 Layer 3

LSP Label Switched Path

LSR Label Switching Router

MPLS MultiProtocol Label Switching

MPT Multipoint to Point Tree

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

Rosen, Viswanathan & Callon [Page 9]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

VPI Virtual Path Identifier

1.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.

Rosen, Viswanathan & Callon [Page 10]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

2. Outline of Approach

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

2.1. Labels

A label is a short short, fixed length length, locally significant identifier
which is used to identify a stream. The label is based on the stream
or
forwarding equivalence class Forwarding Equivalence Class that a packet is assigned to. The
label does not directly encode the network layer address, and is based address. The choice
of label depends on the network layer address only to the extent that
the forwarding
equivalence class is based Forwarding Equivalence Class depends on the that address.

If Ru and Rd are neighboring LSRs, and Ru transmits a packet to Rd, they may
agree to use label L to represent Stream stream S for packets which are sent
from Ru to Rd. That is, they can agree to a "mapping" between label
L and Stream stream S for packets moving from Ru to Rd. As a result of such
an agreement, L becomes Ru's "outgoing label" corresponding to Stream stream
S for such packets; L becomes Rd's "incoming label" corresponding to Stream
stream S for such packets.

Note that L does not necessarily correspond to Stream stream S for any
packets other than those which are being sent from Ru to Rd. Also, L
is not an inherently meaningful value and does not have any network-
wide value; the particular value assigned to L gets its meaning
solely from the agreement between Ru and Rd.

Sometimes it may be difficult or even impossible for Rd to tell that tell, of
an arriving packet carrying label L, that the label L comes from was placed in
the packet by Ru, rather than from 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 mapping from label to FEC is
one-to-one. That is, in such cases, Rd must not agree with Ru1 to
use L for one purpose, while also agreeing with some other LSR Ru2 to
use L for a different purpose.

Rosen, Viswanathan & Callon [Page 10] 11]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

The scope of labels could be unique per interface, or unique per MPLS
node, or unique in a network. If labels are unique within a network,
no label swapping needs to be performed in the MPLS nodes in that
domain. The packets are just label forwarded and not label swapped.
The possible use of labels with network-wide scope is FFS. draft-ietf-mpls-arch-01.txt March 1998

2.2. Upstream and Downstream LSRs

Suppose Ru and Rd have agreed to map label L to Stream stream S, for packets
sent from Ru to Rd. Then with respect to this mapping, Ru is the
"upstream LSR", and Rd is the "downstream LSR".

The notion of upstream and downstream relate to agreements between
nodes of the label values to be assigned for packets belonging to a
particular Stream stream that might be traveling from an upstream node to a
downstream node. This is independent of whether the routing protocol
actually will cause any packets to be transmitted in that particular
direction. Thus, Rd is the downstream LSR for a particular mapping
for label L if it recognizes L-labeled packets from Ru as being in
Stream
stream S. This may be true even if routing does not actually forward
packets for Stream stream S between nodes Rd and Ru, or if routing has made
Ru downstream of Rd along the path which is actually used for packets
in Stream stream S.

2.3. Labeled Packet

A "labeled packet" is a packet into which a label has been encoded.
The encoding can be done by means of an encapsulation which exists
specifically for this purpose, or by placing the label in an
available location in either of the data link or network layer
headers. Of course, the encoding technique must be agreed to by the
entity which encodes the label and the entity which decodes the
label.

2.4. Label Assignment and Distribution; Attributes

For unicast traffic in the MPLS architecture, the decision to bind a
particular label L to a particular Stream stream S is made by the LSR which
is downstream with respect to that mapping. The downstream LSR then
informs the upstream LSR of the mapping. Thus labels are
"downstream-assigned", and are "distributed upstream".

A particular mapping of label L to Stream stream S, distributed by Rd to Ru,
may have associated "attributes". If Ru, acting as a downstream LSR,
also distributes a mapping of a label to Stream stream S, then under certain

Rosen, Viswanathan & Callon [Page 11]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997
conditions, it may be required to also distribute the corresponding
attribute that it received from Rd.

Rosen, Viswanathan & Callon [Page 12]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

2.5. Label Distribution Protocol (LDP)

A Label Distribution Protocol (LDP) is a set of procedures by which
one LSR informs another of the label/Stream mappings it has made.
Two LSRs which use an LDP to exchange label/Stream mapping
information are known as "LDP Peers" with respect to the mapping
information they exchange; we will speak of there being an "LDP
Adjacency" between them.

(N.B.: two LSRs may be LDP Peers with respect to some set of
mappings, but not with respect to some other set of mappings.)

The LDP also encompasses any negotiations in which two LDP Peers need
to engage in order to learn of each other's MPLS capabilities.

2.6. 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".

IN MPLS, EVERY FORWARDING DECISION IS BASED EXCLUSIVELY ON THE LABEL
AT THE TOP OF THE STACK.

Although, as we shall see, MPLS supports a particular LSR, hierarchy, the decision as to how to forward processing
of a labeled packet is completely independent of the level of
hierarchy. The processing is always based exclusively on the label at the top label, without
regard for the possibility that some number of other labels may have
been "above it" in the
stack. 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 (sections 2.19.3 2.21.3 and
2.19.4).
2.21.4).

Rosen, Viswanathan & Callon [Page 12] 13]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997 draft-ietf-mpls-arch-01.txt March 1998

2.7. 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 data link encapsulation to use when transmitting the packet

3. the way to encode the label stack when transmitting the packet

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

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.

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 examine label,
and operate then "forward" the resulting packet to itself. It would then
make another forwarding decision, based on what remains after the encapsulated packet.
label stacked is popped. This may still be a
lower level label, 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".

2.8. Incoming Label Map (ILM)

The "Incoming Label Map" (ILM) is a mapping from incoming labels to
NHLFEs. It is used when forwarding packets that arrive as labeled
packets.

Rosen, Viswanathan & Callon [Page 14]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

2.9. Stream-to-NHLFE Map (STN)

The "Stream-to-NHLFE" (STN) is a mapping from stream to NHLFEs. It is
used when forwarding packets that arrive unlabeled, but which are to
be labeled before being forwarded.

Rosen, Viswanathan & Callon [Page 13]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

2.10. 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 Stream. stream. It then uses the FTN STN
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

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.

2.11. Scope and Uniqueness of Labels

A given LSR Rd may map label L1 to note stream S, and distribute that when
mapping to LDP peer Ru1. Rd may also map label swapping is in use, the next
hop L2 to stream S, and
distribute that mapping to LDP peer Ru2. Whether or not L1 == L2 is always taken from
not determined by the NHLFE; architecture; this may in some cases be
different from what the next hop would be if MPLS were not in use.

2.11. 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 LSRs,

<R1, ..., Rn>

with the following properties:

1. R1, the "LSP Ingress", 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 local matter.

A given LSR Rd may map label stack of depth m when received
by Ri;

3. At no time during P's transit from R1 L to R[n-1] does its stream S1, and distribute that
mapping to LDP peer Ru1. Rd may also map label
stack ever have a depth of less than m;

4. For all i, 1<i<n: Ri transmits P L to R[i+1] by means of MPLS,
i.e., by using stream S2, and
distribute that mapping to LDP 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 S1 == S2. 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 (the
level m label) as an index into an ILM; if the following conditions hold:

Rosen, Viswanathan & Callon [Page 14] 15]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

5. For all i, 1<i<n: if draft-ietf-mpls-arch-01.txt March 1998

- Ru1 and Ru2 are the only LDP peers to which Rd distributed a system S receives
mapping of label value L, and forwards P after P
is transmitted by Ri but before P is received by R[i+1] (e.g.,
Ri

- Ru1 and R[i+1] might be Ru2 are each directly connected to Rd via a switched data link
subnetwork, and S might be one of the data link switches), then
S's forwarding decision is 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. When
these conditions do not based on hold, the level m label, or
on the network layer header. This may labels must be because:

a) unique over the decision LSR
which has assigned them.

If a particular LSR Rd is not based on the attached to a particular LSR Ru over two
point-to-point interfaces, then Rd may distribute to Rd a mapping of
label stack or the
network layer header at all;

b) the decision is based on L to stream S1, as well as a mapping of label stack on L to stream S2,
S1 != S2, if and only if each mapping is valid only for packets which
additional labels have been pushed (i.e., on
Ru sends to Rd over a level m+k
label, where k>0). particular one of the interfaces. In all other words, we can speak
cases, Rd MUST NOT distribute to Ru mappings of the level m same label value
to two different streams.

This prohibition holds even if the mappings 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.

2.12. Label Switched Path (LSP), LSP Ingress, LSP Egress

A "Label Switched Path (LSP) of level m" for Packet a particular packet P as the is
a sequence of LSRs:

1. which begins routers,

<R1, ..., Rn>

with the following properties:

1. R1, the "LSP Ingress", is an LSR (an "LSP Ingress") that which 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 onto P's
label stack, resulting in a forwarding decision is
made by label Switching on stack of depth m;

2. For all i, 1<i<n, P has a level m-k label, where k>0, or label stack of depth m when a forwarding decision is made received
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 Ri;

3. At no time during P's transit from R1 to a FEC whose LSP Egress is
the LSR that assigned the R[n-1] does its label which is now second in the stack.

Note that according to these definitions, if <R1, ..., Rn> is
stack ever have a level
m LSP for packet P, depth of less than m;

4. For all i, 1<i<n: Ri transmits P may be transmitted from R[n-1] to Rn with a
label stack R[i+1] by means of depth m-1. That is, MPLS,
i.e., by using the label stack may be popped at the penultimate LSR top of the LSP, rather than at the LSP Egress. This
is appropriate, since the level m label has served its function of
getting the packet to Rn, and Rn's forwarding decision cannot be made
until the stack (the
level m label label) as an index into an ILM;

Rosen, Viswanathan & Callon [Page 16]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

5. For all i, 1<i<n: if a system S receives and forwards P after P
is popped. If the label stack transmitted by Ri but before P is not popped received by R[n-1], then Rn must do two label lookups; this is an overhead
which is best avoided. However, some hardware switching engines may
not R[i+1] (e.g.,
Ri and R[i+1] might be able to pop the label stack.

The penultimate node pops connected via a switched data link
subnetwork, and S might be one of the label stack only if this data link switches), then
S's forwarding decision is
specifically requested by the egress node. Having the penultimate
node pop the label stack has an implication not based on the assignment of
labels: For any one node Rn, operating at level m in label, or
on the MPLS

Rosen, Viswanathan & Callon [Page 15]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

hierarchy, there network layer header. This may be some LSPs which terminate at that node (i.e.,
for which Rn is because:

a) the egress node) and some other LSPs which continue
beyond that node (i.e., for which Rn decision is an intermediate node). If the
penultimate node R[n-1] pops not based on the label stack for those LSPs which terminate
at Rn, then node R[n] will receive some packets for which or the top of
network layer header at all;

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

In other egress
nodes), and some packets for which the top words, we can speak of the stack is a level
m-1 label (i.e., packets for which Rn is the egress). This implies
that in order m LSP for node R[n-1] to pop Packet P as the stack, node Rn must assign
labels such
sequence of routers:

1. which begins with an LSR (an "LSP Ingress") that pushes on a
level m and level m-1 labels are distinguishable
(i.e., use unique values across multiple levels label,

2. all of the MPLS
hierarchy).

Note that if whose intermediate LSRs make their forwarding decision
by label Switching on a level m = 1, the LSP Egress may receive label,

3. which ends (at an unlabeled packet,
and in fact need not even be capable of supporting MPLS. In this
case, assuming that we are using globally meaningful IP addresses,
the confusion of labels at multiple levels is not possible. However,
it "LSP Egress") when a forwarding decision is possible that the
made by label may still be 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 value for the egress
node. One example this is that the label may be used to assign the packet
to whenever
an LSR pushes a particular Forwarding Equivalence Class (for example, label onto an already labeled packet, it needs to
identify the packet as a high priority packet). Another example is
make sure that the new label may assign the packet corresponds to a particular virtual private
network (for example, the virtual private network may make use of
local IP addresses, and FEC whose LSP Egress is
the label may be necessary to disambiguate LSR that assigned the addresses). Therefore even when there is only a single label
value the stack which is nonetheless popped only when requested by now second in the
egress node. stack.

We will call a sequence of LSRs the "LSP for a particular Stream stream S"
if it is an LSP of level m for a particular packet P when P's level m
label is a label corresponding to Stream stream S.

2.12. LSP Next Hop

The

Consider the set of nodes which may be LSP Next Hop ingress nodes for a particular labeled packet in a particular LSR stream
S. Then there is the LSR an LSP for stream S which is the next hop, as selected by begins with each of those
nodes. If a number of those LSPs have the NHLFE entry used
for forwarding that packet.

The same LSP Next Hop for egress, then one
can consider the set of such LSPs to be a particular Stream tree, whose root is the next hop as selected
by LSP
egress. (Since data travels along this tree towards the NHLFE entry indexed by root, this
may be called a label which corresponds to that
Stream. multipoint-to-point tree.) We can thus speak of the
"LSP tree" for a particular stream S.

Rosen, Viswanathan & Callon [Page 16] 17]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997 draft-ietf-mpls-arch-01.txt March 1998

2.13. Route Selection

Route selection refers Penultimate Hop Popping

Note that according to the method used for selecting the LSP for definitions of section 2.11, if <R1, ...,
Rn> is a
particular stream. The proposed MPLS protocol architecture supports
two options level m LSP for Route Selection: (1) Hop by hop routing, and (2)
Explicit routing.

Hop by hop routing allows each node packet P, P may be transmitted from R[n-1]
to independently choose Rn with a label stack of depth m-1. That is, the next
hop for label stack may
be popped at the path for a stream. This is penultimate LSR of the normal mode today with
existing datagram IP networks. A hop by hop routed LSP refers to an
LSP whose route is selected using hop by hop routing.

An explicitly routed LSP is an LSP where, LSP, rather than at a given LSR, the LSP
next hop is not chosen by each local node, but rather
Egress.

From an architectural perspective, this is chosen by a
single node (usually the ingress or egress node of the LSP). perfectly appropriate.
The
sequence purpose of LSRs followed by an explicit routing LSP may be chosen by
configuration, or by a protocol selected by a single node (for
example, the egress node may make use of level m label is to get the topological information
learned from a link state database in order packet to compute Rn. Once
R[n-1] has decided to send the entire
path for packet to Rn, the tree ending at that egress node). Explicit routing may label no longer has
any function, and need no longer be useful for carried.

There is also a number of purposes such as allowing policy routing
and/or facilitating traffic engineering. With MPLS the explicit
route needs practical advantage to be specified at the time that Labels are assigned, but
the explicit route doing penultimate hop popping.
If one does not have to be specified with each IP packet.
This implies do this, then when the LSP egress receives a packet,
it first looks up the top label, and determines as a result of that explicit routing with MPLS
lookup that it is relatively efficient
(when compared with indeed the efficiency LSP egress. Then it must pop the stack,
and examine what remains of explicit routing 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 pure
datagrams).

For any one the packet's level m
LSP (at any one is also an intermediate node for its level of hierarchy), m-1 LSP.) If there are two
possible options: (i) The entire LSP may be hop by hop routed from
ingress is
no other label on the stack, then the packet is forwarded according
to egress; (ii) The entire LSP may be explicit routed from
ingress its network layer destination address. Note that this would
require the egress to egress. Intermediate cases do not make sense: In general,
an LSP will be explicit routed specifically because there is TWO lookups, either two label lookups or a good
reason to use
label lookup followed by an alternative to address lookup.

If, on the other hand, penultimate hop by popping is used, then when the
penultimate hop routed path. This
implies that if some of looks up the nodes along label, it determines:

- that it is the path follow an explicit
route but some of penultimate hop, and

- who the nodes make use of hop by next hop routing, is.

The penultimate node then
inconsistent routing will result pops the stack, and loops (or severely inefficient
paths) may form.

For this reason, it is important that if an explicit route is
specified for an LSP, then forward the packet
based on the information gained by looking up the label that route must was at
the top of the stack. When the LSP egress receives the packet, the
label at the top of the stack will be followed. Note that the label which it
is relatively simple needs to *follow* an explicit route which is specified
look up in order to make its own forwarding decision. Or, if the
packet was only carrying a LDP setup. We therefore propose that single label, the LDP specification
require that all MPLS nodes implement LSP egress will simply
see the ability to follow an
explicit route if this is specified.

It network layer packet, which is not necessary for a node just what it needs to be able to create an explicit
route. However, see in
order to ensure interoperability 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 necessary known that only a single lookup is
every required:

Rosen, Viswanathan & Callon [Page 17] 18]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

to ensure that either (i) Every node knows how to use hop by hop
routing; or (ii) Every node knows how to create and follow an
explicit route. We propose that due to draft-ietf-mpls-arch-01.txt March 1998

- the common use of hop by hop
routing in networks today, code may be simplified if it can assume that only a single
lookup is reasonable to make hop by hop
routing ever needed

- the default code can be based on a "time budget" that all nodes assumes that only a
single lookup is ever needed.

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

However, some hardware switching engines may not be able to use.

2.14. Time-to-Live (TTL)

In conventional IP forwarding, each packet carries a "Time To Live"
(TTL) value pop the
label stack, so this cannot be universally required. There may also
be some situations in its header. Whenever a packet passes through a
router, its TTL gets decremented which penultimate hop popping is not desirable.
Therefore the penultimate node pops the label stack only if this is
specifically requested by 1; the egress node, or if the TTL reaches 0 before next node in the packet has reached its destination,
LSP does not support MPLS. (If the packet gets discarded.

This provides some level of protection against forwarding loops that
may exist due to misconfigurations, or due to failure or slow
convergence of next node in the routing algorithm. TTL is sometimes used for other
functions as well, LSP does support
MPLS, but does not make such as multicast scoping, and supporting the
"traceroute" command. This implies that there are two TTL-related
issues that MPLS needs to deal with: (i) TTL as a way to suppress
loops; (ii) TTL as a way to accomplish other functions, such as
limiting request, the scope penultimate node has no
way of a packet.

When a packet travels along an LSP, it should emerge with the same
TTL value knowing that it would have had if it had traversed in fact is the same
sequence penultimate node.)

An LSR which is capable of routers without having been label switched. If popping the
packet travels along a hierarchy label stack at all MUST do
penultimate hop popping when so requested by its downstream LDP peer.

Initial LDP negotiations must allow each LSR to determine whether its
neighboring LSRS are capable of LSPs, popping the total number of LSR-
hops traversed should be reflected in its TTL value when it emerges
from label stack. A LSR will
not request an LDP peer to pop the hierarchy of LSPs.

The way that TTL label stack unless it is handled capable
of doing so.

It may vary depending upon be asked whether the MPLS egress node can always interpret the top
label values are carried in an MPLS-specific "shim" header, or of a received packet properly if penultimate hop popping is
used. As long as the
MPLS labels uniqueness and scoping rules of section 2.11
are carried in an L2 header such as an ATM header or a
frame relay header.

If obeyed, it is always possible to interpret the top label values are encoded in of a "shim" that sits between the
data link and network layer headers, then this shim should have
received packet unambiguously.

2.14. LSP Next Hop

The LSP Next Hop for a TTL
field that particular labeled packet in a particular LSR
is initially loaded from the network layer header TTL
field, is decremented at each LSR-hop, and LSR which is copied into the network
layer header TTL field when next hop, as selected by the packet emerges from its LSP.

If NHLFE entry used
for forwarding that packet.

The LSP Next Hop for a particular stream is the next hop as selected
by the NHLFE entry indexed by a label values are encoded in an L2 header (e.g., which corresponds to that
stream.

Note that the VPI/VCI
field in ATM's AAL5 header), and LSP Next Hop may differ from the labeled packets are forwarded next hop which would
be chosen by
an L2 switch (e.g., an ATM switch). This implies that unless the data
link network layer itself has a TTL field (unlike ATM), it routing algorithm. We will not be
possible use the
term "L3 next hop" when we refer to decrement a packet's TTL at each LSR-hop. An LSP segment
which consists of a sequence of LSRs that cannot decrement a packet's
TTL will be called a "non-TTL LSP segment". the latter.

Rosen, Viswanathan & Callon [Page 18] 19]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

When a packet emerges from a non-TTL draft-ietf-mpls-arch-01.txt March 1998

2.15. Route Selection

Route selection refers to the method used for selecting the LSP segment, it should however
be given for a TTL that reflects the number of LSR-hops it traversed. In
the unicast case, this can be achieved
particular stream. The proposed MPLS protocol architecture supports
two options for Route Selection: (1) Hop by propagating a meaningful
LSP length hop routing, and (2)
Explicit routing.

Hop by hop routing allows each node to ingress nodes, enabling independently choose the ingress to decrement next
hop for the
TTL value before forwarding packets into path for a non-TTL stream. This is the normal mode today with
existing datagram IP networks. A hop by hop routed LSP segment.

Sometimes it can be determined, upon ingress refers to a non-TTL an
LSP
segment, that whose route is selected using hop by hop routing.

An explicitly routed LSP is an LSP where, at a particular packet's TTL will expire before the packet
reaches given LSR, the egress of that non-TTL LSP segment. In this case, the LSR
at
next hop is not chosen by each local node, but rather is chosen by a
single node (usually the ingress to or egress node of the non-TTL LSP). The
sequence of LSRs followed by an explicitly routed LSP segment must not label switch the
packet. This means that special procedures must may be developed to
support traceroute functionality, for example, traceroute packets chosen
by configuration, or may be forwarded using conventional hop selected dynamically by hop forwarding.

2.15. Loop Control

On a non-TTL LSP segment, by definition, TTL cannot be used to
protect against forwarding loops. The importance of loop control single node
(for example, the egress node may
depend on make use of the particular hardware being used topological
information learned from a link state database in order to provide the LSR
functions along compute
the non-TTL LSP segment.

Suppose, entire path for instance, the tree ending at that ATM switching hardware is being used to
provide egress node). Explicit
routing may be useful for a number of purposes such as allowing
policy routing and/or facilitating traffic engineering. With MPLS switching functions, with the label being carried in the
VPI/VCI field. Since ATM switching hardware cannot decrement TTL,
there is no protection against loops. If
the ATM hardware is capable
of providing fair access explicit route needs to be specified at the buffer pool for incoming cells
carrying different VPI/VCI values, this looping may time that labels are
assigned, but the explicit route does not have any
deleterious effect on other traffic. If the ATM hardware cannot
provide fair buffer access of this sort, however, then even transient
loops may cause severe degradation of the LSR's total performance.

Even if fair buffer access can to be provided, it specified with
each IP packet. This implies that explicit routing with MPLS is still worthwhile to
have some means
relatively efficient (when compared with the efficiency of detecting loops that last "longer than possible".
In addition, even where TTL and/or per-VC fair queuing provides a
means explicit
routing for surviving loops, it still pure datagrams).

For any one LSP (at any one level of hierarchy), there are two
possible options: (i) The entire LSP may be desirable where practical hop by hop routed from
ingress to avoid setting up LSPs which loop. egress; (ii) The MPLS architecture will therefore provide a technique for ensuring
that looping entire LSP segments can may be detected, and a technique for
ensuring that looping LSP segments are never created.

Rosen, Viswanathan & Callon [Page 19]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

2.15.1. Loop Prevention

LSR's maintain for each of their LSP's an LSR id list. This list is a
list of all the LSR's downstream explicit routed from this LSR on a given LSP. The
LSR id list is used
ingress to prevent the formation of switched path loops.
The LSR ID list egress. Intermediate cases do not make sense: In general,
an LSP will be explicit routed specifically because there is propagated upstream from a node good
reason to its neighbor
nodes. The LSR ID list is used use an alternative to prevent loops as follows:

When a node, R, detects a change in the next hop for a given stream,
it asks its new next by hop for a label and the associated LSR ID list
for routed path. This
implies that stream.

The new next hop responds with a label for if some of the stream and nodes along the path follow an
associated LSR id list.

R looks in explicit
route but some of the LSR id list. If R determines nodes make use of hop by hop routing, then
inconsistent routing will result and loops (or severely inefficient
paths) may form.

For this reason, it is important that it, R, if an explicit route is in the
list
specified for an LSP, then we have a that route loop. In this case, we do nothing and the
old LSP will continue to must be used until the route protocols break the
loop. The means by which the old LSP followed. Note that it
is replaced by a new LSP after
the relatively simple to *follow* an explicit route protocols breathe loop is described below.

If R which is not specified
in the LSR id list, R will start a "diffusion"
computation [12]. The purpose of the diffusion computation is to
prune LDP setup. We therefore propose that the tree upstream of R so LDP specification
require that we remove all LSR's from MPLS nodes implement the
tree that would be on a looping path if R were to switch over ability to the
new LSP. After those LSR's are removed from the tree, it follow an
explicit route if this is safe specified.

It is not necessary for
R a node to replace the old LSP with the new LSP (and the old LSP can be
released).

The diffusion computation works as follows:

R adds its LSR id to the list and sends a query message able to each of
its "upstream" neighbors (i.e. create an explicit
route. However, in order to each of its neighbors that ensure interoperability it is not
the new "downstream" next hop).

A node S necessary

Rosen, Viswanathan & Callon [Page 20]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

to ensure that receives such a query will process the query as
follows:

- If node R is not either (i) Every node S's next knows how to use hop for the given stream, by hop
routing; or (ii) Every node S
will respond knows how to node R will create and follow an "OK" message meaning
explicit route. We propose that as far
as node S is concerned it is safe for node R to switch over due to the new LSP.

- If node R is node S's next common use of hop for the stream, node S will check
to see if it, node S, is by hop
routing in the LSR id list that it received from
node R. If networks today, it is, we have a route loop and S will respond with a
"LOOP" message. R will unsplice the connection is reasonable to S pruning S
from the tree. The mechanism make hop by which S will get a new LSP for

Rosen, Viswanathan & Callon [Page 20]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

the stream after the route protocols break the loop is described
below.

- If node S is not in hop
routing the LSR id list, S will add its LSR id default that all nodes need to the
LSR id list and send a new query message further upstream. The
diffusion computation will continue be able to propagate upstream along use.

2.16. Time-to-Live (TTL)

In conventional IP forwarding, each of the paths in the tree upstream of S until either packet carries a loop
is detected, "Time To Live"
(TTL) value in which case the node is pruned as described above
or we get to a point where its header. Whenever a node gets packet passes through a response ("OK" or
"LOOP") from each of
router, its neighbors perhaps because none of those
neighbors considers TTL gets decremented by 1; if the node in question to be its downstream
next hop. Once a node TTL reaches 0 before
the packet has received a response from each of its
upstream neighbors, it returns an "OK" message to reached its downstream
neighbor. When destination, the original node, node R, packet gets a response from
each discarded.

This provides some level of its neighbors, it is safe protection against forwarding loops that
may exist due to replace the old LSP with misconfigurations, or due to failure or slow
convergence of the
new one because all routing algorithm. TTL is sometimes used for other
functions as well, such as multicast scoping, and supporting the paths
"traceroute" command. This implies that would loop have been pruned
from the tree.

There there are a couple of details to discuss:

- First, we need to do something about nodes two TTL-related
issues that for one reason or
another do not produce a timely response in response MPLS needs to deal with: (i) TTL as a query
message. If a node Y does not respond way to suppress
loops; (ii) TTL as a query from node X
because of a failure of some kind, X will not be able to respond
to its downstream neighbors (if any) or switch over way to a new LSP
if X is, like R above, the node that has detected the route
change. This problem is handled by timing out accomplish other functions, such as
limiting the query message.
If a node doesn't receive scope of a response within packet.

When a "reasonable" period
of time, packet travels along an LSP, it "unsplices" its VC to should emerge with the upstream neighbor same
TTL value that is
not responding and proceeds as it would have had if it had received traversed the
"LOOP" message.

- We also need to be concerned about multiple concurrent routing
updates. What happens, for example, when a node M receives a
request for an LSP from an upstream neighbor, N, same
sequence of routers without having been label switched. If the
packet travels along a hierarchy of LSPs, the total number of LSR-
hops traversed should be reflected in its TTL value when M it emerges
from the hierarchy of LSPs.

The way that TTL is handled may vary depending upon whether the MPLS
label values are carried in an MPLS-specific "shim" header, or if the
middle of
MPLS labels are carried in an L2 header such as an ATM header or a diffusion computation i.e., it has sent
frame relay header.

If the label values are encoded in a query
upstream but hasn't received all "shim" that sits between the responses. Since
data link and network layer headers, then this shim should have a
downstream node, node R TTL
field that is about to change initially loaded from one LSP to
another, M needs to pass to N an LSR id list corresponding to the
union of the old and new LSP's if it network layer header TTL
field, is to avoid loops both
before decremented at each LSR-hop, and after the transition. This is easily accomplished
since M already has the LSR id list for copied into the old LSP and it gets network
layer header TTL field when the LSR id list for packet emerges from its LSP.

If the new LSP label values are encoded in an L2 header (e.g., the query message. After R
makes VPI/VCI
field in ATM's AAL5 header), and the labeled packets are forwarded by
an L2 switch from (e.g., an ATM switch). This implies that unless the old LSP to the new one, R sends a new
establish message upstream with the LSR id list of (just) the new
LSP. At this point, the nodes upstream of R know that R data
link layer itself has
switched over a TTL field (unlike ATM), it will not be
possible to the new decrement a packet's TTL at each LSR-hop. An LSP and segment
which consists of a sequence of LSRs that they can return the id list
for (just) the new cannot decrement a packet's
TTL will be called a "non-TTL LSP in response to any new requests for LSP's. segment".

Rosen, Viswanathan & Callon [Page 21]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

They can also grow the tree to include additional nodes that
would not have been valid for the combined LSR id list.

- We also need to discuss how draft-ietf-mpls-arch-01.txt March 1998

When a node that doesn't have an LSP for packet emerges from a non-TTL LSP segment, it should however
be given stream at a TTL that reflects the end number of a diffusion computation (because LSR-hops it
would have been on a looping LSP) gets one after the routing
protocols break traversed. In
the loop. If node L has been pruned from unicast case, this can be achieved by propagating a meaningful
LSP length to ingress nodes, enabling the
tree and its local route protocol processing entity breaks ingress to decrement the
loop by changing L's next hop, L will request
TTL value before forwarding packets into a new non-TTL LSP from its
new downstream neighbor which segment.

Sometimes it can be determined, upon ingress to a non-TTL LSP
segment, that a particular packet's TTL will use once it executes expire before the
diffusion computation as described above. If the loop is broken
by a route change at another point in packet
reaches the loop, i.e. at a point
"downstream" egress of L, L will get a new LSP as the new that non-TTL LSP tree grows
upstream from the point of segment. In this case, the route change as discussed in LSR
at the
previous paragraph.

- Note that when a node is pruned from ingress to the tree, non-TTL LSP segment must not label switch the switched path
upstream of that node remains "connected".
packet. This is important
since it allows the switched path to get "reconnected" means that special procedures must be developed to
support traceroute functionality, for example, traceroute packets may
be forwarded using conventional hop by hop forwarding.

2.17. Loop Control

On a
downstream switched path after a route change with a minimal
amount non-TTL LSP segment, by definition, TTL cannot be used to
protect against forwarding loops. The importance of unsplicing and resplicing once loop control may
depend on the appropriate
diffusion computation(s) have taken place.

The LSR Id list can also be particular hardware being used to provide a "loop detection"
capability. To use it in this manner, an LSR which sees that it is
already in the LSR Id list for a particular stream will immediately
unsplice itself from
functions along the switched path non-TTL LSP segment.

Suppose, for instance, that stream, and will NOT
pass ATM switching hardware is being used to
provide MPLS switching functions, with the LSR Id list further upstream. The LSR can rejoin a switched
path for label being carried in the stream when it changes its next hop
VPI/VCI field. Since ATM switching hardware cannot decrement TTL,
there is no protection against loops. If the ATM hardware is capable
of providing fair access to the buffer pool for that stream, or
when incoming cells
carrying different VPI/VCI values, this looping may not have any
deleterious effect on other traffic. If the ATM hardware cannot
provide fair buffer access of this sort, however, then even transient
loops may cause severe degradation of the LSR's total performance.

Even if fair buffer access can be provided, it receives is still worthwhile to
have some means of detecting loops that last "longer than possible".
In addition, even where TTL and/or per-VC fair queuing provides a new LSR Id list from its current next hop, in
which
means for surviving loops, it is not contained. The diffusion computation would still may be
omitted.

2.15.2. Interworking of Loop Control Options desirable where practical
to avoid setting up LSPs which loop.

The MPLS protocol architecture allows some nodes to will therefore provide a technique for ensuring
that looping LSP segments can be using loop
prevention, while some other nodes detected, and a technique for
ensuring that looping LSP segments are not (i.e., the choice of
whether or not to use loop prevention may never created.

All LSRs will be required to support a local decision). When
this mix is used, it is not possible common technique for a loop to form which
includes only nodes which do
detection. Support for the loop prevention. However, prevention technique is optional,
though it is possible
for loops recommended in ATM-LSRs that have no other way to form which contain a combination
protect themselves against the effects of some nodes which do
loop prevention, and some nodes which do not.

There are at least four identified cases in which it makes sense to
combine nodes which do looping data packets. Use
of the loop prevention with nodes which do not: (i)
For transition, in intermediate states while transitioning from all
non-loop-prevention to all loop prevention, or vice versa; (ii) For technique, when supported, is optional.

Rosen, Viswanathan & Callon [Page 22]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

interoperability, where one vendor implements draft-ietf-mpls-arch-01.txt March 1998

2.17.1. Loop Prevention

NOTE: The loop prevention but
another vendor does not; (iii) Where there technique described here is a mixed ATM and
datagram media network, being
reconsidered, and where loop prevention is desired over the
ATM portions may be changed.

LSR's maintain for each of the network but not over the datagram portions; (iv)
where some their LSP's an LSR id list. This list is a
list of all the ATM switches can do fair access to the buffer pool LSR's downstream from this LSR on a per-VC basis, and some cannot, and loop prevention given LSP. The
LSR id list is desired
over used to prevent the ATM portions formation of the network which cannot.

Note that interworking is straightforward. If an switched path loops.
The LSR ID list is not doing
loop prevention, and it receives propagated upstream from a downstream node to its neighbor
nodes. The LSR ID list is used to prevent loops as follows:

When a label
mapping which contains loop prevention information, it (a) accepts node, R, detects a change in the next hop for a given stream,
it asks its new next hop for a label mapping, (b) does NOT pass the loop prevention information
upstream, and (c) informs the downstream neighbor that the path is
loop-free.

Similarly, if associated LSR ID list
for that stream.

The new next hop responds with a label for the stream and an
associated LSR id list.

R which is doing loop prevention receives from a
downstream looks in the LSR id list. If R determines that it, R, is in the
list then we have a label mapping route loop. In this case, we do nothing and the
old LSP will continue to be used until the route protocols break the
loop. The means by which does not contain any loop
prevention information, then R passes the label mapping upstream with old LSP is replaced by a new LSP after
the route protocols breathe loop prevention information included as if is described below.

If R were the egress for is not in the
specified stream.

Optionally, LSR id list, R will start a node "diffusion"
computation [12]. The purpose of the diffusion computation is permitted to implement
prune the ability tree upstream of either
doing or not doing loop prevention as options, and is permitted R so that we remove all LSR's from the
tree that would be on a looping path if R were to
choose which switch over to use for any one particular LSP based on the
information obtained from downstream nodes. When the label mapping
arrives
new LSP. After those LSR's are removed from downstream, then the node may choose whether tree, it is safe for
R to use loop
prevention so replace the old LSP with the new LSP (and the old LSP can be
released).

The diffusion computation works as follows:

R adds its LSR id to continue to use the same approach as was used in
the information passed to it. Note that regardless of whether loop
prevention is used the egress nodes (for any particular LSP) always
initiates exchange of label mapping information without waiting for
other nodes to act.

2.16. Merging list and Non-Merging LSRs

Merge allows multiple upstream LSPs to be merged into a single
downstream LSP. When implemented by multiple nodes, this results in
the traffic going to sends a particular egress nodes, based on one
particular Stream, query message to follow a multipoint each of
its "upstream" neighbors (i.e. to point tree (MPT), with
the MPT rooted at each of its neighbors that is not
the egress new "downstream" next hop).

A node and associated with the Stream.
This can have S that receives such a significant effect on reducing query will process the number of labels
that need to be maintained by any one particular node. query as
follows:

- If merge was node R is not used at all it would be necessary node S's next hop for each the given stream, node S
will respond to
provide the upstream neighbors with a label for each Stream node R will an "OK" message meaning that as far
as node S is concerned it is safe for each
upstream node which may be forwarding traffic R to switch over the link. This
implies that the number of labels needed might not in general be
known a priori. However, the use of merge allows a single label to be
the new LSP.

Rosen, Viswanathan & Callon [Page 23]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

used per Stream, therefore allowing label assignment to be done in a
common way without regard for the number of upstream nodes which will
be using draft-ietf-mpls-arch-01.txt March 1998

- If node R is node S's next hop for the downstream LSP.

The proposed MPLS protocol architecture supports LSP merge, while
allowing nodes which do not support LSP merge. This leads stream, node S will check
to the
issue of ensuring correct interoperation between nodes which
implement merge and those which do not. The issue see if it, node S, is somewhat
different in the case of datagram media versus the case of ATM. The
different media types will therefore be discussed separately.

2.16.1. Stream Merge

Let us say that an LSR is capable of Stream Merge if id list that it can receive
two packets received from different incoming interfaces, and/or with different
labels,
node R. If it is, we have a route loop and send both packets out the same outgoing interface S will respond with a
"LOOP" message. R will unsplice the same label. This in effect takes two incoming streams and merges
them into one. Once connection to S pruning S
from the packets are transmitted, tree. The mechanism by which S will get a new LSP for
the information that
they arrived from different interfaces and/or with different incoming
labels stream after the route protocols break the loop is lost.

Let us say that an LSR described
below.

- If node S is not capable of Stream Merge if, for any two
packets which arrive from different interfaces, or with different
labels, in the packets must either be transmitted out different
interfaces, or must have different labels.

An LSR which is capable of Stream Merge (a "Merging LSR") needs to
maintain only one outgoing label for each FEC. AN id list, S will add its LSR which is not
capable of Stream Merge (a "Non-merging LSR") may need id to maintain as
many as N outgoing labels per FEC, where N is the number of LSRs in the network. Hence by supporting Stream Merge, an
LSR can reduce its
number of outgoing labels by id list and send a factor of O(N). Since new query message further upstream. The
diffusion computation will continue to propagate upstream along
each label of the paths in
use requires the dedication of some amount tree upstream of resources, this can be S until either a significant savings.

2.16.2. Non-merging LSRs

The MPLS forwarding procedures loop
is very similar to detected, in which case the forwarding
procedures used by such technologies node is pruned as ATM and Frame Relay. That is, described above
or we get to a unit of data arrives, point where a label (VPI/VCI node gets a response ("OK" or DLCI) is looked up
"LOOP") from each of its neighbors perhaps because none of those
neighbors considers the node in question to be its downstream
next hop. Once a
"cross-connect table", on the basis node has received a response from each of that lookup its
upstream neighbors, it returns an output port is
chosen, and "OK" message to its downstream
neighbor. When the label value is rewritten. In fact, original node, node R, gets a response from
each of its neighbors, it is possible safe to
use such technologies for MPLS forwarding; LDP can be used as replace the
"signalling protocol" for setting up old LSP with the cross-connect tables.

Unfortunately, these technologies do not necessarily support the

Rosen, Viswanathan & Callon [Page 24]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

Stream Merge capability. In ATM, if
new one attempts to perform Stream
Merge, the result may be because all the interleaving of cells from various
packets. If cells paths that would loop have been pruned
from different packets get interleaved, it is
impossible to reassemble the packets. Some Frame Relay switches use
cell switching on their backplanes. These switches may also be
incapable of supporting Stream Merge, for the same reason -- cells tree.

There are a couple of
different packets may get interleaved, and there is then no way to
reassemble the packets.

We propose to support two solutions details to this problem. discuss:

- First, MPLS will
contain procedures which allow the use of non-merging LSRs. Second,
MPLS will support procedures which allow certain ATM switches to
function as merging LSRs.

Since MPLS supports both merging and non-merging LSRs, MPLS also
contains procedures we need to ensure correct interoperation between them.

2.16.3. Labels do something about nodes that for Merging and Non-Merging LSRs

An upstream LSR which supports Stream Merge needs to be sent only one
label per FEC. An upstream neighbor which reason or
another do not produce a timely response in response to a query
message. If a node Y does not support Stream
Merge needs respond to be sent multiple labels per FEC. However, there is no
way a query from node X
because of knowing a priori how many labels it needs. This will depend on
how many LSRs are upstream failure of it with respect some kind, X will not be able to respond
to its downstream neighbors (if any) or switch over to the FEC in question.

In the MPLS architecture, if a particular upstream neighbor does not
support Stream Merge, it is not sent any labels for a particular FEC
unless it explicitly asks for a label for new LSP
if X is, like R above, the node that FEC. The upstream
neighbor may make multiple such requests, and has detected the route
change. This problem is given handled by timing out the query message.
If a new label
each time. When node doesn't receive a downstream neighbor receives such response within a request from
upstream, and "reasonable" period
of time, it "unsplices" its VC to the downstream upstream neighbor does that is
not itself support Stream
Merge, then responding and proceeds as it must in turn ask its downstream neighbor for another
label for would if it had received the FEC in question.

It is possible that there may be some nodes which support merge, but
have a limited number of upstream streams which may
"LOOP" message.

- We also need to be merged into a
single downstream streams. Suppose concerned about multiple concurrent routing
updates. What happens, for example that due to some
hardware limitation example, when a node M receives a
request for an LSP from an upstream neighbor, N, when M is capable in the
middle of merging four upstream LSPs
into a single downstream LSP. Suppose however, that this particular
node diffusion computation i.e., it has six sent a query
upstream LSPs arriving at it for but hasn't received all the responses. Since a particular Stream. In
this case, this node may merge these into two
downstream LSPs
(corresponding to two labels that need node, node R is about to be obtained change from one LSP to
another, M needs to pass to N an LSR id list corresponding to the
downstream neighbor). In this case, the normal operation
union of the LDP
implies that the downstream neighbor will supply this node with a
single label for old and new LSP's if it is to avoid loops both
before and after the Stream. transition. This node can then ask its downstream
neighbor for one additional label is easily accomplished
since M already has the LSR id list for the Stream, implying that old LSP and it gets
the
node will thereby obtain LSR id list for the required two labels. new LSP in the query message. After R

Rosen, Viswanathan & Callon [Page 25] 24]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

The interaction between explicit routing and merge is FFS.

2.16.4. Merge over ATM

2.16.4.1. Methods of Eliminating Cell Interleave

There are several methods that can be used to eliminate draft-ietf-mpls-arch-01.txt March 1998

makes the cell
interleaving problem in ATM, thereby allowing ATM switches to support
stream merge: :

1. VP merge

When VP merge is used, multiple virtual paths are merged into a
virtual path, but packets switch from different sources are
distinguished by using different VCs within the VP.

2. VC merge

When VC merge is used, switches are required old LSP to buffer cells
from one packet until the entire packet is received (this may
be determined by looking for new one, R sends a new
establish message upstream with the AAL5 end LSR id list of frame indicator).

VP merge has (just) the advantage new
LSP. At this point, the nodes upstream of R know that it is compatible with a higher
percentage of existing ATM switch implementations. This makes it more
likely R has
switched over to the new LSP and that VP merge they can be used return the id list
for (just) the new LSP in existing networks. Unlike VC
merge, VP merge does not incur response to any delays at the merge points and new requests for LSP's.
They can also does not impose any buffer requirements. However, it has grow the
disadvantage tree to include additional nodes that it requires coordination of
would not have been valid for the VCI space within
each VP. There are combined LSR id list.

- We also need to discuss how a number of ways that this can be accomplished.
Selection of one or more methods is FFS.

This tradeoff between compatibility with existing equipment versus
protocol complexity and scalability implies node that it is desirable doesn't have an LSP for a
given stream at the MPLS protocol to support both VP merge and VC merge. In order to
do so each ATM switch participating in MPLS needs to know whether its
immediate ATM neighbors perform VP merge, VC merge, or no merge.

2.16.4.2. Interoperation: VC Merge, VP Merge, and Non-Merge

The interoperation of the various forms of merging over ATM is most
easily described by first describing the interoperation of VC merge
with non-merge.

In the case where VC merge and non-merge nodes are interconnected the
forwarding end of cells is based in all cases a diffusion computation (because it
would have been on a VC (i.e., looping LSP) gets one after the
concatenation of routing
protocols break the VPI loop. If node L has been pruned from the
tree and VCI). For each node, if an upstream

Rosen, Viswanathan & Callon [Page 26]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

neighbor is doing VC merge then that upstream neighbor requires only
a single VPI/VCI for a particular Stream (this is analogous to its local route protocol processing entity breaks the
requirement for
loop by changing L's next hop, L will request a single label in new LSP from its
new downstream neighbor which it will use once it executes the case of operation over frame
media).
diffusion computation as described above. If the upstream neighbor loop is not doing merge, then broken
by a route change at another point in the
neighbor will require loop, i.e. at a single VPI/VCI per Stream for itself, plus
enough VPI/VCIs to pass to its upstream neighbors. The number
required point
"downstream" of L, L will be determined by allowing get a new LSP as the new LSP tree grows
upstream nodes to request
additional VPI/VCIs from their downstream neighbors (this is again
analogous to the method used with frame merge).

A similar method is possible to support nodes which perform VP merge.
In this case the VP merge node, rather than requesting a single
VPI/VCI or a number point of VPI/VCIs from its downstream neighbor, instead
may request a single VP (identified by a VPI) but several VCIs within the VP. Furthermore, suppose route change as discussed in the
previous paragraph.

- Note that when a non-merge node is downstream pruned from two different VP merge nodes. This the tree, the switched path
upstream of that node may need to request one
VPI/VCI (for traffic originating from itself) plus two VPs (one for
each upstream node), each associated with a specified set of VCIs (as
requested from the upstream node).

In order to support all of VP merge, VC merge, and non-merge, it remains "connected". This is
therefore necessary important
since it allows the switched path to allow upstream nodes get "reconnected" to request a combination
of zero or more VC identifiers (consisting of
downstream switched path after a VPI/VCI), plus zero
or more VPs (identified by VPIs) each containing route change with a specified number minimal
amount of VCs (identified by unsplicing and resplicing once the appropriate
diffusion computation(s) have taken place.

The LSR Id list can also be used to provide a set of VCIs "loop detection"
capability. To use it in this manner, an LSR which are significant within sees that it is
already in the LSR Id list for a
VP). VP merge nodes would therefore request one VP, with particular stream will immediately
unsplice itself from the switched path for that stream, and will NOT
pass the LSR Id list further upstream. The LSR can rejoin a contained
VCI switched
path for the stream when it changes its next hop for traffic that stream, or
when it originates (if appropriate) plus receives a VCI for
each VC requested new LSR Id list from above (regardless its current next hop, in
which it is not contained. The diffusion computation would be
omitted.

2.17.2. Interworking of whether or Loop Control Options

The MPLS protocol architecture allows some nodes to be using loop
prevention, while some other nodes are not (i.e., the VC is
part choice of a containing VP). VC merge node would request only a single
VPI/VCI (since they can merge all upstream traffic into a single VC).
Non-merge nodes would pass on any requests that they get from above,
plus request a VPI/VCI for traffic that they originate (if
appropriate).

2.17. LSP Control: Egress versus Local

There is a choice to be made regarding
whether the initial setup of
LSPs will be initiated by the egress node, or locally by each
individual node. not to use loop prevention may be a local decision). When LSP control
this mix is done locally, then each node may at any time pass
label bindings to its neighbors used, it is not possible for each FEC recognized by that node.
In the normal case that the neighboring nodes recognize the same
FECs, then a loop to form which
includes only nodes may map incoming labels which do loop prevention. However, it is possible
for loops to outgoing labels as part form which contain a combination of the normal label swapping forwarding method.

When LSP control is done by the egress, then initially only the some nodes which do
loop prevention, and some nodes which do not.

Rosen, Viswanathan & Callon [Page 27] 25]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

egress node passes label bindings to its neighbors corresponding draft-ietf-mpls-arch-01.txt March 1998

There are at least four identified cases in which it makes sense to
any FECs
combine nodes which leave the MPLS network at that egress node. Other do loop prevention with nodes wait until they get a label which do not: (i)
For transition, in intermediate states while transitioning from downstream for a particular
FEC before passing a corresponding label for the same FEC to upstream
nodes.

With local control, since each LSR is (at least initially)
independently assigning labels all
non-loop-prevention to FECs, it is possible that different
LSRs may make inconsistent decisions. all loop prevention, or vice versa; (ii) For example, an upstream LSR
may make a coarse decision (map multiple IP address prefixes to a
single label) while its downstream neighbor makes a finer grain
decision (map each individual IP address prefix to
interoperability, where one vendor implements loop prevention but
another vendor does not; (iii) Where there is a separate label).
With downstream label assignment this can be corrected by having LSRs
withdraw labels that it has assigned which are inconsistent with
downstream labels, mixed ATM and replace them with new consistent label
assignments.

Even with egress control it
datagram media network, and where loop prevention is possible that desired over the choice
ATM portions of egress
node may change, or the egress may (based on a change in
configuration) change its mind in terms network but not over the datagram portions; (iv)
where some of the granularity which is ATM switches can do fair access to be used. This implies the same mechanism will be necessary to
allow changes in granularity to bubble up to upstream nodes. The
choice buffer pool
on a per-VC basis, and some cannot, and loop prevention is desired
over the ATM portions of egress or local control may therefore effect the frequency
with network which this mechanism cannot.

Note that interworking is straightforward. If an LSR is used, but will not effect the need for doing
loop prevention, and it receives from a downstream LSR a
mechanism to achieve consistency of label granularity. Generally
speaking,
mapping which contains loop prevention information, it (a) accepts
the choice of local versus egress control label mapping, (b) does not appear
to have any effect on NOT pass the LDP mechanisms which need to be defined.

Egress control loop prevention information
upstream, and local control can interwork in a very
straightforward manner (although some of (c) informs the advantages ascribed to
egress control may be lost, see appendices A and B). With either
approach, (assuming downstream label assignment) neighbor that the egress node will
initially assign labels for particular FECs and will pass these
labels to its neighbors. With either approach these path is
loop-free.

Similarly, if an LSR R which is doing loop prevention receives from a
downstream LSR a label assignments
will bubble upstream, with mapping which does not contain any loop
prevention information, then R passes the label mapping upstream nodes choosing labels that
are consistent with
loop prevention information included as if R were the labels that they receive from downstream. The
difference between egress for the two approaches
specified stream.

Optionally, a node is therefore primarily an issue permitted to implement the ability of what each node does prior either
doing or not doing loop prevention as options, and is permitted to obtaining a label assignment
choose which to use for a any one particular FEC LSP based on the
information obtained from downstream nodes: Does it wait, or does it assign
a preliminary nodes. When the label under mapping
arrives from downstream, then the expectation that it will (probably) be
correct?

Regardless of which method is used (local control or egress control)
each node needs may choose whether to know (possibly by configuration) what granularity use loop
prevention so as to continue to use for labels the same approach as was used in
the information passed to it. Note that it assigns. Where egress control regardless of whether loop
prevention is used, this
requires each node to know used the granularity only egress nodes (for any particular LSP) always
initiates exchange of label mapping information without waiting for streams which
leave the MPLS network at that node. For local control,
other nodes to act.

2.18. Merging and Non-Merging LSRs

Merge allows multiple upstream LSPs to be merged into a single
downstream LSP. When implemented by multiple nodes, this results in order
the traffic going to
avoid a particular egress nodes, based on one
particular stream, to follow a multipoint to point tree (MPT), with
the MPT rooted at the egress node and associated with the stream.
This can have a significant effect on reducing the number of labels
that need to withdraw inconsistent labels, be maintained by any one particular node.

If merge was not used at all it would be necessary for each node in the to

Rosen, Viswanathan & Callon [Page 28] 26]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

network would need to be configured consistently to know draft-ietf-mpls-arch-01.txt March 1998

provide the
granularity upstream neighbors with a label for each stream. However, in many cases this stream for each
upstream node which may be done
by using forwarding traffic over the link. This
implies that the number of labels needed might not in general be
known a single level priori. However, the use of granularity which applies to all streams
(such as "one merge allows a single label to be
used per IP prefix in the forwarding table"). The
choice between local control versus egress control could similarly stream, therefore allowing label assignment to be
left as done in a configuration option.

Future versions
common way without regard for the number of upstream nodes which will
be using the downstream LSP.

The proposed MPLS protocol architecture will need supports LSP merge, while
allowing nodes which do not support LSP merge. This leads to choose the
issue of ensuring correct interoperation between
three options: (i) Requiring local control; (ii) Requiring egress
control; or (iii) Allowing a choice nodes which
implement merge and those which do not. The issue is somewhat
different in the case of local control or egress
control. Arguments for local datagram media versus egress control are contained in
appendices A and B.

2.18. Granularity

When forwarding by label swapping, a stream the case of ATM. The
different media types will therefore be discussed separately.

2.18.1. Stream Merge

Let us say that an LSR is capable of Stream Merge if it can receive
two packets following a
stream arriving from upstream may be mapped different incoming interfaces, and/or with different
labels, and send both packets out the same outgoing interface with
the same label. This in effect takes two incoming streams and merges
them into one. Once the packets are transmitted, the information that
they arrived from different interfaces and/or with different incoming
labels is lost.

Let us say that an equal LSR is not capable of Stream Merge if, for any two
packets which arrive from different interfaces, or coarser
grain stream. However, a coarse grain stream (for example, containing with different
labels, the packets destined for a short IP address prefix covering many subnets)
cannot must either be mapped directly into a finer grain stream (for example,
containing packets destined for a longer IP address prefix covering a
single subnet). This implies that there transmitted out different
interfaces, or must have different labels.

An LSR which is capable of Stream Merge (a "Merging LSR") needs to be some mechanism
maintain only one outgoing label for ensuring consistency between each FEC. AN LSR which is not
capable of Stream Merge (a "Non-merging LSR") may need to maintain as
many as N outgoing labels per FEC, where N is the granularity number of LSPs LSRs in an MPLS
network.

The method used for ensuring compatibility of granularity may depend
upon
the method used for LSP control.

When LSP control is local, it is possible that a node may pass a
coarse grain label to network. Hence by supporting Stream Merge, an LSR can reduce its upstream neighbor(s), and subsequently
receive
number of outgoing labels by a finer grain factor of O(N). Since each label from its downstream neighbor. In this
case in
use requires the node has two options: (i) It may forward dedication of some amount of resources, this can be
a significant savings.

2.18.2. Non-merging LSRs

The MPLS forwarding procedures is very similar to the corresponding
packets using normal IP datagram forwarding (i.e.,
procedures used by examination such technologies as ATM and Frame Relay. That is,
a unit of data arrives, a label (VPI/VCI or DLCI) is looked up in a
"cross-connect table", on the IP header); (ii) It may withdraw basis of that lookup an output port is
chosen, and the label mappings that value is rewritten. In fact, it has
passed is possible to its upstream neighbors, and replace these with finer grain
label mappings.

When LSP control is egress based, the label setup originates from the
egress node and passes upstream. It is therefore straightforward with
this approach to maintain equally-grained mappings along the route.

Rosen, Viswanathan & Callon [Page 29] 27]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

2.19. Tunnels and Hierarchy

Sometimes a router Ru takes explicit action to cause a particular
packet to draft-ietf-mpls-arch-01.txt March 1998

use such technologies for MPLS forwarding; LDP can be delivered to another router Rd, even though Ru and Rd
are not consecutive routers on used as the Hop-by-hop path
"signalling protocol" for that packet,
and Rd is setting up the cross-connect tables.

Unfortunately, these technologies do not necessarily support the packet's ultimate destination. For example, this
Stream Merge capability. In ATM, if one attempts to perform Stream
Merge, the result may be done by encapsulating the packet inside a network layer packet
whose destination address is the address interleaving of Rd itself. This creates a
"tunnel" cells from Ru to Rd. We refer to any packet so handled as a
"Tunneled Packet".

2.19.1. Hop-by-Hop Routed Tunnel various
packets. If a Tunneled Packet follows the Hop-by-hop path cells from Ru to Rd, we
say that different packets get interleaved, it is in an "Hop-by-Hop Routed Tunnel" whose "transmit
endpoint" is Ru
impossible to reassemble the packets. Some Frame Relay switches use
cell switching on their backplanes. These switches may also be
incapable of supporting Stream Merge, for the same reason -- cells of
different packets may get interleaved, and whose "receive endpoint" there is Rd.

2.19.2. Explicitly Routed Tunnel

If a Tunneled Packet travels from Ru then no way to Rd over a path other than
reassemble the
Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel"
whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd.
For example, we might send a packet through an Explicitly Routed
Tunnel by encapsulating it in a packet packets.

We propose to support two solutions to this problem. First, MPLS will
contain procedures which is source routed.

2.19.3. LSP Tunnels

It is possible allow the use of non-merging LSRs. Second,
MPLS will support procedures which allow certain ATM switches to implement a tunnel
function as a LSP, merging LSRs.

Since MPLS supports both merging and use label
switching rather than network layer encapsulation non-merging LSRs, MPLS also
contains procedures to cause the packet ensure correct interoperation between them.

2.18.3. Labels for Merging and Non-Merging LSRs

An upstream LSR which supports Stream Merge needs to travel through the tunnel. The tunnel would be a LSP <R1, ...,
Rn>, where R1 is the transmit endpoint of the tunnel, and Rn sent only one
label per FEC. An upstream neighbor which does not support Stream
Merge needs to be sent multiple labels per FEC. However, there is the
receive endpoint no
way of the tunnel. This is called knowing a "LSP Tunnel".

The set of packets which priori how many labels it needs. This will depend on
how many LSRs are upstream of it with respect to be sent though the LSP tunnel becomes
a Stream, and each LSR FEC in question.

In the tunnel must assign MPLS architecture, if a label to that particular upstream neighbor does not
support Stream (i.e., must assign Merge, it is not sent any labels for a label to the tunnel). The criteria particular FEC
unless it explicitly asks for
assigning a particular packet to an LSP tunnel label for that FEC. The upstream
neighbor may make multiple such requests, and is given a local matter at
the tunnel's transmit endpoint. To put new label
each time. When a packet into an LSP tunnel,
the transmit endpoint pushes downstream neighbor receives such a label for the tunnel onto the label
stack request from
upstream, and sends the labeled packet to the next hop in the tunnel.

If it is downstream neighbor does not necessary itself support Stream
Merge, then it must in turn ask its downstream neighbor for another
label for the tunnel's receive endpoint to FEC in question.

It is possible that there may be able
to determine some nodes which support merge, but
have a limited number of upstream streams which packets it receives through the tunnel, as
discussed earlier, the label stack may be popped merged into a
single downstream streams. Suppose for example that due to some
hardware limitation a node is capable of merging four upstream LSPs
into a single downstream LSP. Suppose however, that this particular
node has six upstream LSPs arriving at it for a particular stream. In
this case, this node may merge these into two downstream LSPs
(corresponding to two labels that need to be obtained from the penultimate
LSR in
downstream neighbor). In this case, the tunnel. normal operation of the LDP

Rosen, Viswanathan & Callon [Page 30] 28]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

A "Hop-by-Hop Routed LSP Tunnel" is a Tunnel draft-ietf-mpls-arch-01.txt March 1998

implies that is implemented as
an hop-by-hop routed LSP between the transmit endpoint and the
receive endpoint.

An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an
Explicitly Routed LSP.

2.19.4. Hierarchy: LSP Tunnels within LSPs

Consider downstream neighbor will supply this node with a LSP <R1, R2, R3, R4>. Let us suppose that R1 receives
unlabeled packet P, and pushes on its
single label stack for the stream. This node can then ask its downstream
neighbor for one additional label to cause
it to follow this path, and that this is in fact for the Hop-by-hop path.
However, let us further suppose stream, implying that R2 the
node will thereby obtain the required two labels.

The interaction between explicit routing and R3 merge is FFS.

2.18.4. Merge over ATM

2.18.4.1. Methods of Eliminating Cell Interleave

There are not directly
connected, several methods that can be used to eliminate the cell
interleaving problem in ATM, thereby allowing ATM switches to support
stream merge: :

1. VP merge

When VP merge is used, multiple virtual paths are merged into a
virtual path, but packets from different sources are "neighbors"
distinguished by virtue of being the endpoints of an
LSP tunnel. So using different VCs within the actual sequence of LSRs traversed by P is <R1, R2,
R21, R22, R23, R3, R4>. VP.

2. VC merge

When P travels from R1 VC merge is used, switches are required to R2, it will have a label stack of depth 1.
R2, switching on buffer cells
from one packet until the label, determines that P must enter entire packet is received (this may
be determined by looking for the tunnel.
R2 first replaces AAL5 end of frame indicator).

VP merge has the Incoming label with a label advantage that is meaningful
to R3. Then it pushes on a new label. This level 2 label has a value
which is meaningful to R21. Switching is done on the level 2 label by
R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel,
pops the label stack before forwarding the packet to R3. When R3 sees
packet P, P has only compatible with a level 1 label, having now exited the tunnel.
Since R3 is the penultimate hop in P's level 1 LSP, higher
percentage of existing ATM switch implementations. This makes it pops more
likely that VP merge can be used in existing networks. Unlike VC
merge, VP merge does not incur any delays at the label
stack, merge points and R4 receives P unlabeled.

The label stack mechanism allows LSP tunneling to nest to
also does not impose any depth.

2.19.5. LDP Peering and Hierarchy

Suppose that packet P travels along a Level 1 LSP <R1, R2, R3, R4>,
and when going from R2 to R3 travels along a Level 2 LSP <R2, R21,
R22, R3>. From the perspective of the Level 2 LSP, R2's LDP peer is
R21. From buffer requirements. However, it has the perspective
disadvantage that it requires coordination of the Level 1 LSP, R2's LDP peers are R1
and R3. One can have LDP peers at VCI space within
each layer VP. There are a number of hierarchy. We will
see in sections 3.6 and 3.7 some ways to make use of this hierarchy.
Note that in this example, R2 and R21 must can be IGP neighbors, but R2
and R3 need not be.

When two LSRs are IGP neighbors, we will refer to them as "Local LDP
Peers". When two LSRs may be LDP peers, but are not IGP neighbors,
we will refer to them as "Remote LDP Peers". In accomplished.
Selection of one or more methods is FFS.

This tradeoff between compatibility with existing equipment versus
protocol complexity and scalability implies that it is desirable for
the above example,
R2 MPLS protocol to support both VP merge and R21 are local LDP peers, but R2 VC merge. In order to
do so each ATM switch participating in MPLS needs to know whether its
immediate ATM neighbors perform VP merge, VC merge, or no merge.

2.18.4.2. Interoperation: VC Merge, VP Merge, and R3 are remote LDP peers. Non-Merge

The interoperation of the various forms of merging over ATM is most
easily described by first describing the interoperation of VC merge

Rosen, Viswanathan & Callon [Page 31] 29]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

The MPLS architecture supports two ways to distribute labels at
different layers of the hierarchy: Explicit Peering and Implicit
Peering.

One performs label Distribution with one's Local LDP Peers by opening
LDP connections to them. One can perform label Distribution draft-ietf-mpls-arch-01.txt March 1998

with
one's Remote LDP Peers in one of two ways:

1. Explicit Peering non-merge.

In explicit peering, one sets up LDP connections between Remote
LDP Peers, exactly as one would do for Local LDP Peers. This
technique is most useful when the number case where VC merge and non-merge nodes are interconnected the
forwarding of Remote LDP Peers cells is
small, or based in all cases on a VC (i.e., the number of higher level label mappings is large,
or the Remote LDP Peers are in distinct routing areas or
domains. Of course, one needs to know which labels to
distribute to which peers; this is addressed in section 3.1.2.

Examples
concatenation of the use of explicit peering is found in sections
3.2.1 VPI and 3.6.

2. Implicit Peering

In Implicit Peering, one does not have LDP connections to one's
remote LDP peers, but VCI). For each node, if an upstream
neighbor is doing VC merge then that upstream neighbor requires only
a single VPI/VCI for a particular stream (this is analogous to one's local LDP peers. To
distribute higher level labels to ones remote LDP peers, one
encodes the higher level labels as an attribute
requirement for a single label in the case of operation over frame
media). If the lower
level labels, and distributes upstream neighbor is not doing merge, then the lower level label, along with
this attribute,
neighbor will require a single VPI/VCI per stream for itself, plus
enough VPI/VCIs to the local LDP peers. pass to its upstream neighbors. The local LDP peers
then propagate number
required will be determined by allowing the information upstream nodes to request
additional VPI/VCIs from their peers. This process
continues till the information reaches remote LDP peers. Note
that downstream neighbors (this is again
analogous to the intermediary nodes may also be remote LDP peers.

This technique method used with frame merge).

A similar method is most useful when possible to support nodes which perform VP merge.
In this case the VP merge node, rather than requesting a single
VPI/VCI or a number of Remote LDP
Peers is large. Implicit peering does not require VPI/VCIs from its downstream neighbor, instead
may request a n-square
peering mesh to distribute labels to the remote LDP peers
because the information is piggybacked through the local LDP
peering. However, implicit peering requires single VP (identified by a VPI) but several VCIs within
the intermediate
nodes to store information VP. Furthermore, suppose that they might not be directly
interested in.

An example of the use of implicit peering is found in section
3.3.

Rosen, Viswanathan & Callon [Page 32]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

2.20. LDP Transport

LDP is used between nodes in an MPLS network to establish and
maintain the label mappings. In order for LDP to operate correctly,
LDP information needs to be transmitted reliably, and the LDP
messages pertaining to a particular FEC need to be transmitted in
sequence. non-merge node is downstream
from two different VP merge nodes. This node may potentially be accomplished either by using an
existing reliable transport protocol such as TCP, or by specifying
reliability mechanisms as part of LDP need to request one
VPI/VCI (for example, the reliability
mechanisms which are defined in IDRP could potentially be "borrowed"
for use with LSP). The precise means traffic originating from itself) plus two VPs (one for accomplishing transport
reliability
each upstream node), each associated with LSP are for further study, but will be a specified by
the MPLS Protocol Architecture before set of VCIs (as
requested from the architecture may be
considered complete.

2.21. Label Encodings upstream node).

In order to transmit a label stack along with the packet whose label
stack it is, support all of VP merge, VC merge, and non-merge, it is
therefore necessary to define allow upstream nodes to request a concrete encoding combination
of the
label stack. The architecture supports several different encoding
techniques; the choice zero or more VC identifiers (consisting of encoding technique depends on the
particular kind a VPI/VCI), plus zero
or more VPs (identified by VPIs) each containing a specified number
of device being used to forward labeled packets.

2.21.1. MPLS-specific Hardware and/or Software

If one is using MPLS-specific hardware and/or software to forward
labeled packets, the most obvious way to encode the label stack is to
define VCs (identified by a new protocol to be used as set of VCIs which are significant within a "shim" between the data link
layer and network layer headers. This shim
VP). VP merge nodes would really be just an
encapsulation therefore request one VP, with a contained
VCI for traffic that it originates (if appropriate) plus a VCI for
each VC requested from above (regardless of whether or not the network layer packet; it VC is
part of a containing VP). VC merge node would be "protocol-
independent" such that it could be used to encapsulate request only a single
VPI/VCI (since they can merge all upstream traffic into a single VC).
Non-merge nodes would pass on any network
layer. Hence we will refer requests that they get from above,
plus request a VPI/VCI for traffic that they originate (if
appropriate).

2.19. LSP Control: Egress versus Local

There is a choice to it as be made regarding whether the "generic MPLS
encapsulation".

The generic MPLS encapsulation would in turn initial setup of
LSPs will be encapsulated in a
data link layer protocol.

The generic MPLS encapsulation should contain the following fields:

1. initiated by the egress node, or locally by each
individual node.

When LSP control is done locally, then each node may at any time pass
label stack,

2. a Time-to-Live (TTL) field bindings to its neighbors for each FEC recognized by that node.

Rosen, Viswanathan & Callon [Page 33] 30]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

3. a Class of Service (CoS) field

The TTL field permits MPLS to provide a TTL function similar to what
is provided by IP.

The CoS field permits LSRs to apply various scheduling packet
disciplines to labeled packets, without requiring separate labels for
separate disciplines.

This section is not intended to rule out draft-ietf-mpls-arch-01.txt March 1998

In the use of alternative
mechanisms in network environments where such alternatives may be
appropriate.

2.21.2. ATM Switches as LSRs

It will be noted normal case that MPLS forwarding procedures are similar to those
of legacy "label swapping" switches such as ATM switches. ATM
switches use the input port and neighboring nodes recognize the same
FECs, then nodes may map incoming VPI/VCI value as the
index into a "cross-connect" table, from which they obtain an output
port and an labels to outgoing VPI/VCI value. Therefore if one or more labels
can be encoded directly into as part
of the fields which are accessed normal label swapping forwarding method.

When LSP control is done by these
legacy switches, the egress, then initially only the legacy switches can, with suitable software
upgrades, be used as LSRs. We will refer
egress node passes label bindings to such devices as "ATM-
LSRs".

There are three obvious ways its neighbors corresponding to encode labels in the ATM cell header
(presuming
any FECs which leave the use of AAL5):

1. SVC Encoding

Use the VPI/VCI field to encode the label which is MPLS network at the top
of the that egress node. Other
nodes wait until they get a label stack. This technique can be used in any network. from downstream for a particular
FEC before passing a corresponding label for the same FEC to upstream
nodes.

With this encoding technique, local control, since each LSP LSR is realized as (at least initially)
independently assigning labels to FECs, it is possible that different
LSRs may make inconsistent decisions. For example, an ATM
SVC, and the LDP becomes the ATM "signaling" protocol. With
this encoding technique, the ATM-LSRs cannot perform "push" or
"pop" operations on the label stack.

2. SVP Encoding

Use the VPI field upstream LSR
may make a coarse decision (map multiple IP address prefixes to encode the a
single label) while its downstream neighbor makes a finer grain
decision (map each individual IP address prefix to a separate label).
With downstream label assignment this can be corrected by having LSRs
withdraw labels that it has assigned which are inconsistent with
downstream labels, and replace them with new consistent label
assignments.

Even with egress control it is at possible that the top choice of egress
node may change, or the label stack, and the VCI field to encode the second label egress may (based on a change in
configuration) change its mind in terms of the stack, if one granularity which is present.
to be used. This technique some advantages
over implies the previous one, same mechanism will be necessary to
allow changes in that it permits the use of ATM "VP-
switching". That is, granularity to bubble up to upstream nodes. The
choice of egress or local control may therefore effect the LSPs are realized as ATM SVPs, frequency
with
LDP serving as the ATM signaling protocol.

However, this technique cannot always be used. If the network

Rosen, Viswanathan & Callon [Page 34]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

includes an ATM Virtual Path through a non-MPLS ATM network,
then the VPI field is not necessarily available for use by
MPLS.

When which this encoding technique mechanism is used, but will not effect the ATM-LSR at the egress need for a
mechanism to achieve consistency of label granularity. Generally
speaking, the VP effectively choice of local versus egress control does a "pop" operation.

3. SVP Multipoint Encoding

Use the VPI field not appear
to encode have any effect on the label LDP mechanisms which is at need to be defined.

Egress control and local control can interwork in a very
straightforward manner (although when both methods exist in the top of
network, the label stack, use part overall behavior of the VCI field to encode the second network is largely that of local
control). With either approach, (assuming downstream label on
assignment) the stack, if one is present, egress node will initially assign labels for
particular FECs and use will pass these labels to its neighbors. With
either approach these label assignments will bubble upstream, with
the remainder of upstream nodes choosing labels that are consistent with the VCI field to identify
labels that they receive from downstream. The difference between the LSP ingress. If this technique
two approaches is used, conventional ATM VP-switching capabilities can be used therefore primarily an issue of what each node does
prior to provide multipoint-to-point VPs. Cells obtaining a label assignment for a particular FEC from different
packets
downstream nodes: Does it wait, or does it assign a preliminary label
under the expectation that it will then carry different VCI values, so multipoint-
to-point VPs can (probably) be provided without any cell interleaving
problems.

This technique depends on the existence correct?

Regardless of a capability for
assigning small unique values to which method is used (local control or egress control)

Rosen, Viswanathan & Callon [Page 31]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

each ATM switch.

If there are more node needs to know (possibly by configuration) what granularity
to use for labels on that it assigns. Where egress control is used, this
requires each node to know the stack than can be encoded granularity only for streams which
leave the MPLS network at that node. For local control, in order to
avoid the ATM
header, need to withdraw inconsistent labels, each node in the ATM encodings must
network would need to be combined with configured consistently to know the generic
encapsulation. This does presuppose that it
granularity for each stream. However, in many cases this may be possible done
by using a single level of granularity which applies to tell,
when reassembling all streams
(such as "one label per IP prefix in the ATM cells into packets, whether forwarding table").

This architecture allows the generic
encapsulation is also present.

2.21.3. Interoperability among Encoding Techniques

If <R1, R2, R3> is a segment of choice between local control and egress
control to be a LSP, it is possible that R1 will
use one encoding of local matter. Since the label stack when transmitting packet P to R2,
but R2 will use two methods interwork, a different encoding when transmitting
given LSR need support only one or the other.

2.20. Granularity

When forwarding by label swapping, a packet P stream of packets following a
stream arriving from upstream may be mapped into an equal or coarser
grain stream. However, a coarse grain stream (for example, containing
packets destined for a short IP address prefix covering many subnets)
cannot be mapped directly into a finer grain stream (for example,
containing packets destined for a longer IP address prefix covering a
single subnet). This implies that there needs to
R3. In general, be some mechanism
for ensuring consistency between the MPLS architecture supports granularity of LSPs with different
label stack encodings in an MPLS
network.

The method used on different hops. Therefore, when we
discuss the procedures for processing a labeled packet, we speak in
abstract terms ensuring compatibility of operating on granularity may depend
upon the packet's label stack. method used for LSP control.

When a
labeled packet LSP control is received, the LSR must decode local, it is possible that a node may pass a
coarse grain label to determine its upstream neighbor(s), and subsequently
receive a finer grain label from its downstream neighbor. In this
case the
current value node has two options: (i) It may forward the corresponding
packets using normal IP datagram forwarding (i.e., by examination of
the label stack, then must operate on IP header); (ii) It may withdraw the label
stack mappings that it has
passed to determine the new value of the stack, its upstream neighbors, and then encode the
new value appropriately before transmitting replace these with finer grain
label mappings.

When LSP control is egress based, the labeled packet to its
next hop.

Unfortunately, ATM switches have no capability for translating label setup originates from
one encoding technique to another. The MPLS architecture therefore
requires that whenever it the
egress node and passes upstream. It is possible for two ATM switches therefore straightforward with
this approach to be
successive LSRs maintain equally-grained mappings along a level m LSP for some packet, that those two the route.

Rosen, Viswanathan & Callon [Page 35] 32]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

ATM switches use the same encoding technique.

Naturally there will be MPLS networks which contain a combination of
ATM switches operating as LSRs, draft-ietf-mpls-arch-01.txt March 1998

2.21. Tunnels and other LSRs which operate using an
MPLS shim header. In such networks there may Hierarchy

Sometimes a router Ru takes explicit action to cause a particular
packet to be some LSRs which have
ATM interfaces as well as "MPLS Shim" interfaces. This is one example
of an LSR with different label stack encodings on different hops.
Such an LSR may swap off an ATM encoded label stack on an incoming
interface delivered to another router Rd, even though Ru and replace it with an MPLS shim header encoded label stack Rd
are not consecutive routers on the outgoing interface.

2.22. Multicast

This section is Hop-by-hop path for further study

3. Some Applications of MPLS

3.1. MPLS that packet,
and Hop by Hop Routed Traffic

One use of MPLS Rd is to simplify not the process of forwarding packets
using hop packet's ultimate destination. For example, this
may be done by hop routing.

3.1.1. Labels for Address Prefixes

In general, router R determines encapsulating the next hop for packet P by finding
the inside a network layer packet
whose destination address prefix X in its routing table which is the longest match
for P's destination address. That is, address of Rd itself. This creates a
"tunnel" from Ru to Rd. We refer to any packet so handled as a
"Tunneled Packet".

2.21.1. Hop-by-Hop Routed Tunnel

If a Tunneled Packet follows the packets Hop-by-hop path from Ru to Rd, we
say that it is in an "Hop-by-Hop Routed Tunnel" whose "transmit
endpoint" is Ru and whose "receive endpoint" is Rd.

2.21.2. Explicitly Routed Tunnel

If a given Stream
are just those packets which match Tunneled Packet travels from Ru to Rd over a given address prefix path other than the
Hop-by-hop path, we say that it is in R's
routing table. In this case, an "Explicitly Routed Tunnel"
whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd.
For example, we might send a Stream can be identified with packet through an
address prefix.

If Explicitly Routed
Tunnel by encapsulating it in a packet P must traverse which is source routed.

2.21.3. LSP Tunnels

It is possible to implement a sequence of routers, tunnel as a LSP, and at each router
in use label
switching rather than network layer encapsulation to cause the sequence P matches packet
to travel through the same address prefix, MPLS simplifies tunnel. The tunnel would be a LSP <R1, ...,
Rn>, where R1 is the forwarding process by enabling all routers but transmit endpoint of the first to avoid
executing tunnel, and Rn is the best match algorithm; they need only look up
receive endpoint of the label.

3.1.2. Distributing Labels for Address Prefixes

3.1.2.1. LDP Peers for tunnel. This is called a Particular Address Prefix

LSRs R1 and R2 "LSP Tunnel".

The set of packets which are considered to be LDP Peers for address prefix X if
and only if one of sent though the following conditions holds:

Rosen, Viswanathan & Callon [Page 36]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

1. R1's route to X is a route which it learned about via a
particular instance of LSP tunnel becomes
a particular IGP, stream, and R2 is a neighbor
of R1 each LSR in the tunnel must assign a label to that instance of that IGP

2. R1's route
stream (i.e., must assign a label to X is the tunnel). The criteria for
assigning a route which it learned about by some
instance of routing algorithm A1, and that route is
redistributed into particular packet to an instance of routing algorithm A2, and R2 LSP tunnel is a neighbor of R1 in that instance of A2

3. R1 is local matter at
the receive endpoint of tunnel's transmit endpoint. To put a packet into an LSP Tunnel that is within
another LSP, and R2 is a tunnel,
the transmit endpoint of that tunnel, and
R1 and R2 are participants in pushes a common instance of an IGP, and
are in label for the same IGP area (if tunnel onto the IGP in question has areas), label
stack and R1's route sends the labeled packet to X was learned via that IGP instance, or the next hop in the tunnel.

If it is
redistributed by R1 into that IGP instance

4. R1's route to X is a route not necessary for the tunnel's receive endpoint to be able
to determine which packets it learned about via BGP, and
R2 receives through the tunnel, as
discussed earlier, the label stack may be popped at the penultimate
LSR in the tunnel.

Rosen, Viswanathan & Callon [Page 33]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

A "Hop-by-Hop Routed LSP Tunnel" is a BGP peer of R1

In general, these rules ensure Tunnel that if is implemented as
an hop-by-hop routed LSP between the route to transmit endpoint and the
receive endpoint.

An "Explicitly Routed LSP Tunnel" is a particular
address prefix LSP Tunnel that is distributed via also an IGP, the LDP peers for
Explicitly Routed LSP.

2.21.4. Hierarchy: LSP Tunnels within LSPs

Consider a LSP <R1, R2, R3, R4>. Let us suppose that
address prefix are the IGP neighbors. If R1 receives
unlabeled packet P, and pushes on its label stack the route label to a particular
address prefix cause
it to follow this path, and that this is distributed via BGP, in fact the LDP peers for Hop-by-hop path.
However, let us further suppose that address
prefix R2 and R3 are the BGP peers. In other cases not directly
connected, but are "neighbors" by virtue of LSP tunneling, being the
tunnel endpoints are LDP peers.

3.1.2.2. Distributing Labels

In order to use MPLS for the forwarding of normally routed traffic,
each LSR MUST:

1. bind one or more labels to each address prefix that appears in
its routing table;

2. for each such address prefix X, use an LDP to distribute
LSP tunnel. So the
mapping of a label to X to each actual sequence of its LDP Peers for X.

There is also one circumstance in which an LSR must distribute a
label mapping for an address prefix, even if it LSRs traversed by P is not the LSR which
bound that label to that address prefix:

3. If <R1, R2,
R21, R22, R23, R3, R4>.

When P travels from R1 uses BGP to distribute R2, it will have a route to X, naming some other
LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has
assigned label L to X, then R1 must distribute stack of depth 1.
R2, switching on the mapping
between T and X to any BGP peer to which it distributes that
route.

Rosen, Viswanathan & Callon [Page 37]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

These rules ensure label, determines that labels corresponding to address prefixes
which correspond to BGP routes are distributed to IGP neighbors if
and only if the BGP routes are distributed into the IGP. Otherwise, P must enter the labels bound to BGP routes are distributed only to tunnel.
R2 first replaces the other BGP
speakers.

These rules are intended to indicate which Incoming label mappings must be
distributed by with a given LSR label that is meaningful
to R3. Then it pushes on a new label. This level 2 label has a value
which other LSRs, NOT is meaningful to indicate R21. Switching is done on the
conditions under level 2 label by
R21, R22, R23. R23, which the distribution is to be made. That is
discussed the penultimate hop in section 2.17.

3.1.3. Using the Hop by Hop path as R2-R3 tunnel,
pops the LSP

If label stack before forwarding the hop-by-hop path that packet P needs to follow is <R1, ...,
Rn>, then <R1, ..., Rn> can be an LSP as long as:

1. there is R3. When R3 sees
packet P, P has only a single address prefix X, such that, for all i,
1<=i<n, X level 1 label, having now exited the tunnel.
Since R3 is the longest match penultimate hop in Ri's routing table for P's
destination address;

2. for all i, 1<i<n, Ri has assigned a level 1 LSP, it pops the label to X
stack, and distributed
that R4 receives P unlabeled.

The label stack mechanism allows LSP tunneling to R[i-1].

Note nest to any depth.

2.21.5. LDP Peering and Hierarchy

Suppose that packet P travels along a packet's Level 1 LSP can extend only until it encounters a router
whose forwarding tables have <R1, R2, R3, R4>,
and when going from R2 to R3 travels along a longer best match address prefix for Level 2 LSP <R2, R21,
R22, R3>. From the packet's destination address. At that point, perspective of the LSP must end and Level 2 LSP, R2's LDP peer is
R21. From the best match algorithm must be performed again.

Suppose, for example, that packet P, with destination address
10.2.153.178 needs to go from perspective of the Level 1 LSP, R2's LDP peers are R1 to R2 to
and R3. Suppose also One can have LDP peers at each layer of hierarchy. We will
see in sections 3.6 and 3.7 some ways to make use of this hierarchy.
Note that in this example, R2
advertises address prefix 10.2/16 to R1, and R21 must be IGP neighbors, but advertises 10.2.153/22,
10.2.154/22, R2
and 10.2/16 to R3. That is, R2 is advertising an
"aggregated route" R3 need not be.

When two LSRs are IGP neighbors, we will refer to R1. In this situation, packet P can them as "Local LDP
Peers". When two LSRs may be label
Switched until it reaches R2, LDP peers, but since R2 has performed route
aggregation, it must execute the best match algorithm are not IGP neighbors,
we will refer to find P's
Stream.

3.1.4. LSP Egress them as "Remote LDP Peers". In the above example,
R2 and LSP Proxy Egress

An LSR R is considered to be an "LSP Egress" LSR for address prefix X
if R21 are local LDP peers, but R2 and only if one of the following conditions holds:

1. R1 has an address Y, such that X is the address prefix in R1's
routing table which is the longest match for Y, or R3 are remote LDP peers.

Rosen, Viswanathan & Callon [Page 38] 34]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

2. R contains draft-ietf-mpls-arch-01.txt March 1998

The MPLS architecture supports two ways to distribute labels at
different layers of the hierarchy: Explicit Peering and Implicit
Peering.

One performs label Distribution with one's Local LDP Peers by opening
LDP connections to them. One can perform label Distribution with
one's Remote LDP Peers in its routing tables one or more address prefixes Y
such that X is a proper initial substring of Y, but R's "LSP
previous hops" for X two ways:

1. Explicit Peering

In explicit peering, one sets up LDP connections between Remote
LDP Peers, exactly as one would do not contain any such address prefixes
Y; that is, R2 is a "deaggregation point" for address prefix X.

An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address
prefix X if and only if:

1. R1's next hop for X Local LDP Peers. This
technique is R2 R1 and R2 are not most useful when the number of Remote LDP Peers with
respect to X (perhaps because R2 does not support MPLS), is
small, or

2. R1 has been configured to act as an LSP Proxy Egress for X

The definition the number of LSP allows for higher level label mappings is large,
or the LSP Egress Remote LDP Peers are in distinct routing areas or
domains. Of course, one needs to be a node know which
does not support MPLS; in labels to
distribute to which peers; this case the penultimate node in the LSP is addressed in section 3.1.2.

Examples of the Proxy Egress.

3.1.5. The POP Label

The POP label use of explicit peering is a label with special semantics which an LSR can bind
to an address prefix. If LSR Ru, by consulting its ILM, sees that
labeled packet P must be forwarded next found in sections
3.2.1 and 3.6.

2. Implicit Peering

In Implicit Peering, one does not have LDP connections to Rd, one's
remote LDP peers, but that Rd has
distributed a mapping of the POP label only to one's local LDP peers. To
distribute higher level labels to ones remote LDP peers, one
encodes the corresponding address
prefix, then instead higher level labels as an attribute of replacing the value of lower
level labels, and distributes the label on top of lower level label, along with
this attribute, to the label stack, Ru pops the label stack, and local LDP peers. The local LDP peers
then forwards the
resulting packet to Rd.

LSR Rd distributes a mapping between the POP label and an address
prefix X to LSR Ru if and only if:

1. propagate the rules of Section 3.1.2 indicate that Rd distributes information to Ru a
label mapping for X, and

2. when their peers. This process
continues till the information reaches remote LDP connection between Ru and Rd was opened, Ru
indicated peers. Note
that it could support the POP label, and

3. Rd is an LSP Egress (not proxy egress) for X.

This causes the penultimate LSR on a LSP to pop the label stack. intermediary nodes may also be remote LDP peers.

This technique is quite appropriate; if most useful when the LSP Egress number of Remote LDP
Peers is an MPLS Egress for X, then
if the penultimate LSR large. Implicit peering does not pop the label stack, the LSP Egress
will need require a n-square
peering mesh to look up the label, pop the label stack, and then look up
the next label (or look up the L3 address, if no more distribute labels are
present). By having the penultimate LSR pop to the label stack, remote LDP peers
because the LSP
Egress information is saved piggybacked through the work of having local LDP
peering. However, implicit peering requires the intermediate
nodes to look up two labels store information that they might not be directly
interested in.

An example of the use of implicit peering is found in order to
make its forwarding decision. section
3.3.

Rosen, Viswanathan & Callon [Page 39] 35]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

However, if the penultimate LSR draft-ietf-mpls-arch-01.txt March 1998

2.22. LDP Transport

LDP is used between nodes in an ATM switch, it may not have the
capability MPLS network to pop establish and
maintain the label stack. Hence a POP label mapping may be
distributed only mappings. In order for LDP to LSRs which can support that function.

If operate correctly,
LDP information needs to be transmitted reliably, and the penultimate LSR LDP
messages pertaining to a particular FEC need to be transmitted in an LSP for address prefix X
sequence. Flow control is an LSP Proxy
Egress, it acts just also required, as if the LSP Egress had distributed is the POP
label for X.

3.1.6. Option: Egress-Targeted Label Assignment

There are situations capability to
carry multiple LDP messages in which an LSP Ingress, Ri, knows that packets
of several different Streams must all follow the same LSP,
terminating at, say, LSP Egress Re. In this case, proper routing can a single datagram.

These goals will be achieved met by using TCP as the underlying transport for
LDP.

(The use of multicast techniques to distribute label mappings is
FFS.)

2.23. Label Encodings

In order to transmit a single label can be used for all such Streams; stack along with the packet whose label
stack it is, it is not necessary to have define a distinct label for each Stream. If
(and only if) concrete encoding of the following conditions hold:

1.
label stack. The architecture supports several different encoding
techniques; the address choice of LSR Re is itself in the routing table as a "host
route", and

2. there is some way for Ri to determine that Re is encoding technique depends on the LSP egress
for all packets in a
particular set kind of Streams

Then Ri may bind a single label device being used to all FECS in the set. This is
known as "Egress-Targeted Label Assignment."

How can LSR Ri determine that an LSR Re is the LSP Egress for all
packets in a particular Stream? There are a couple of possible ways:

- forward labeled packets.

2.23.1. MPLS-specific Hardware and/or Software

If the network one is running a link state routing algorithm, and all
nodes in the area support MPLS, then the routing algorithm
provides Ri with enough information using MPLS-specific hardware and/or software to determine the routers
through which packets in that Stream must leave forward
labeled packets, the routing
domain or area.

- It is possible to use LDP to pass information about which address
prefixes are "attached" most obvious way to which egress LSRs. This method has
the advantage of not depending on encode the presence of link state
routing.

If egress-targeted label assignment stack is used, the number of labels
that need to
define a new protocol to be supported throughout used as a "shim" between the data link
layer and network may be greatly
reduced. layer headers. This may shim would really be significant if one is using legacy switching
hardware to do MPLS, and the switching hardware can support only a
limited number just an
encapsulation of labels.

One possible approach the network layer packet; it would be "protocol-
independent" such that it could be used to configure the encapsulate any network
layer. Hence we will refer to use

Rosen, Viswanathan & Callon [Page 40]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

egress-targeted label assignment by default, but to configure
particular LSRs to NOT use egress-targeted label assignment for one
or more of it as the address prefixes for which it is an LSP egress. We
impose "generic MPLS
encapsulation".

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

The generic MPLS encapsulation should contain the following rule:

- If fields:

1. the label stack,

2. a particular LSR is NOT an LSP Egress for some set Time-to-Live (TTL) field

Rosen, Viswanathan & Callon [Page 36]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

3. a Class of address
prefixes, then it should assign labels Service (CoS) field

The TTL field permits MPLS to the address prefixes in
the same way as provide a TTL function similar to what
is done provided by its LSP next hop IP.

The CoS field permits LSRs to apply various scheduling packet
disciplines to labeled packets, without requiring separate labels for
separate disciplines.

2.23.2. ATM Switches as LSRs

It will be noted that MPLS forwarding procedures are similar to those address
prefixes. That is, suppose Rd is Ru's LSP next hop for address
prefixes X1 and X2. If Rd assigns
of legacy "label swapping" switches such as ATM switches. ATM
switches use the same label to X1 input port and X2,
Ru should the incoming VPI/VCI value as well. If Rd assigns different labels to X1 the
index into a "cross-connect" table, from which they obtain an output
port and X2,
then Ru should as well.

For example, suppose an outgoing VPI/VCI value. Therefore if one wants to make egress-targeted label
assignment the default, but to assign distinct or more labels to those
address prefixes for
can be encoded directly into the fields which there are multiple possible LSP egresses
(i.e., for those address prefixes which are multi-homed.) One can
configure all LSRs to use egress-targeted label assignment, and accessed by these
legacy switches, then
configure a handful of LSRs to assign distinct labels to those
address prefixes which are multi-homed. For a particular multi-homed
address prefix X, one would only need the legacy switches can, with suitable software
upgrades, be used as LSRs. We will refer to configure this in LSRs which such devices as "ATM-
LSRs".

There are either LSP Egresses or LSP Proxy Egresses for X.

It is important three obvious ways to note that if Ru and Rd are adjacent LSRs in an LSP
for X1 and X2, forwarding will still be done correctly if Ru assigns
distinct encode labels to X1 and X2 while Rd assigns just one label to in the
both ATM cell header
(presuming the use of them. This just means that R1 will map different incoming
labels to AAL5):

1. SVC Encoding

Use the same outgoing label, an ordinary occurrence.

Similarly, if Rd assigns distinct labels to X1 and X2, but Ru assigns VPI/VCI field to them both encode the label corresponding to which is at the address top
of their the label stack. This technique can be used in any network.
With this encoding technique, each LSP
Egress is realized as an ATM
SVC, and the LDP becomes the ATM "signaling" protocol. With
this encoding technique, the ATM-LSRs cannot perform "push" or Proxy Egress, forwarding will still be done correctly. Ru
will just map
"pop" operations on the incoming label stack.

2. SVP Encoding

Use the VPI field to encode the label which Rd has assigned
to is at the address top of that LSP Egress.

3.2. MPLS
the label stack, and Explicitly Routed LSPs

There are a number of reasons why it may be desirable to use explicit
routing instead of hop by hop routing. For example, this allows
routes the VCI field to be based encode the second label
on administrative policies, and allows the routes stack, if one is present. This technique some advantages
over the previous one, in that LSPs take to be carefully designed to allow traffic engineering
(i.e., to allow intentional management of it permits the loading use of ATM "VP-
switching". That is, the
bandwidth through LSPs are realized as ATM SVPs, with
LDP serving as the nodes and links in ATM signaling protocol.

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

Rosen, Viswanathan & Callon [Page 41] 37]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

3.2.1. Explicitly Routed LSP Tunnels: Traffic Engineering

In some situations, draft-ietf-mpls-arch-01.txt March 1998

When this encoding technique is used, the network administrators may desire to forward
certain classes ATM-LSR at the egress
of traffic along certain pre-specified paths, where
these paths differ from the Hop-by-hop path that VP effectively does a "pop" operation.

3. SVP Multipoint Encoding

Use the traffic would
ordinarily follow. This is known as Traffic Engineering.

MPLS allows this VPI field to be easily done by means of Explicitly Routed LSP
Tunnels. All that encode the label which is needed is:

1. A means at the top of selecting
the packets that are label stack, use part of the VCI field to be sent into encode the
Explicitly Routed LSP Tunnel;

2. A means second
label on the stack, if one is present, and use the remainder of setting up
the Explicitly Routed VCI field to identify the LSP Tunnel;

3. A means ingress. If this technique
is used, conventional ATM VP-switching capabilities can be used
to provide multipoint-to-point VPs. Cells from different
packets will then carry different VCI values, so multipoint-
to-point VPs can be provided without any cell interleaving
problems.

This technique depends on the existence of ensuring a capability for
assigning small unique values to each ATM switch.

If there are more labels on the stack than can be encoded in the ATM
header, the ATM encodings must be combined with the generic
encapsulation. This does presuppose that packets sent it be possible to tell,
when reassembling the ATM cells into packets, whether the Tunnel generic
encapsulation is also present.

2.23.3. Interoperability among Encoding Techniques

If <R1, R2, R3> is a segment of a LSP, it is possible that R1 will not
loop from
use one encoding of the receive endpoint back label stack when transmitting packet P to R2,
but R2 will use a different encoding when transmitting a packet P to
R3. In general, the transmit endpoint.

If MPLS architecture supports LSPs with different
label stack encodings used on different hops. Therefore, when we
discuss the transmit endpoint procedures for processing a labeled packet, we speak in
abstract terms of operating on the tunnel wishes to put packet's label stack. When a
labeled packet
into is received, the tunnel, it LSR must first replace decode it to determine the label
current value at the top of the stack with a label value that was distributed to it by the
tunnel's receive endpoint. Then it stack, then must push operate on the label which
corresponds
stack to determine the tunnel itself, as distributed to it by new value of the next
hop along stack, and then encode the tunnel. To allow this,
new value appropriately before transmitting the tunnel endpoints should be
explicit LDP peers. The label mappings they need labeled packet to exchange are of its
next hop.

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

3.3. Label Stacks and Implicit Peering

Suppose same encoding technique.

Naturally there will be MPLS networks which contain a particular LSR Re combination of
ATM switches operating as LSRs, and other LSRs which operate using an

Rosen, Viswanathan & Callon [Page 38]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

MPLS shim header. In such networks there may be some LSRs which have
ATM interfaces as well as "MPLS Shim" interfaces. This is one example
of an LSP proxy egress for 10 address
prefixes, LSR with different label stack encodings on different hops.
Such an LSR may swap off an ATM encoded label stack on an incoming
interface and replace it reaches each address prefix through a distinct
interface.

One could assign a single label to all 10 address prefixes. Then Re
is with an LSP egress for all 10 address prefixes. MPLS shim header encoded label stack
on the outgoing interface.

2.24. Multicast

This ensures that
packets section is for all 10 address prefixes get delivered to Re. However, Re
would then have further study

3. Some Applications of MPLS

3.1. MPLS and Hop by Hop Routed Traffic

One use of MPLS is to look up simplify the network layer address process of each such forwarding packets
using hop by hop routing.

3.1.1. Labels for Address Prefixes

In general, router R determines the next hop for packet P by finding
the address prefix X in order to choose its routing table which is the proper interface to send longest match
for P's destination address. That is, the packets in a given stream
are just those packets which match a given address prefix in R's
routing table. In this case, a stream can be identified with an
address prefix.

If packet on.

Alternatively, one could assign P must traverse a distinct label to sequence of routers, and at each interface.
Then Re is an LSP proxy egress for router
in the 10 sequence P matches the same address prefixes. This
eliminates prefix, MPLS simplifies
the need for Re forwarding process by enabling all routers but the first to avoid
executing the best match algorithm; they need only look up the network layer addresses in
order label.

3.1.2. Distributing Labels for Address Prefixes

3.1.2.1. LDP Peers for a Particular Address Prefix

LSRs R1 and R2 are considered to forward be LDP Peers for address prefix X if
and only if one of the packets. However, following conditions holds:

1. R1's route to X is a route which it can result in the use learned about via a
particular instance of a
large number particular IGP, and R2 is a neighbor
of labels.

An alternative would be to bind all 10 address prefixes to the same
level 1 label (which is also bound to the address R1 in that instance of the LSR itself), that IGP

Rosen, Viswanathan & Callon [Page 42] 39]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

and then to bind each address prefix draft-ietf-mpls-arch-01.txt March 1998

2. R1's route to X is a distinct level 2 label. The
level 2 label would be treated as route which it learned about by some
instance of routing algorithm A1, and that route is
redistributed into an attribute instance of routing algorithm A2, and R2
is a neighbor of R1 in that instance of A2

3. R1 is the level 1 label
mapping, which we call the "Stack Attribute". We impose the
following rules:

- When LSR Ru initially labels receive endpoint of an untagged packet, if the longest
match for the packet's destination address is X, and R's LSP next
hop for X Tunnel that is Rd, within
another LSP, and Rd has distributed to R1 R2 is a mapping transmit endpoint of label
L1 X, along with that tunnel, and
R1 and R2 are participants in a stack attribute common instance of L2, then

1. Ru must push L2 an IGP, and then L1 onto
are in the packet's label stack,
and then forward same IGP area (if the packet IGP in question has areas),
and R1's route to Rd;

2. When Ru distributes label mappings for X was learned via that IGP instance, or is
redistributed by R1 into that IGP instance

4. R1's route to its LDP peers,
it must include L2 as the stack attribute.

3. Whenever the stack attribute changes (possibly as X is a result
of route which it learned about via BGP, and
R2 is a change in Ru's LSP next hop for X), Ru must distribute
the new stack attribute.

Note BGP peer of R1

In general, these rules ensure that although if the label value bound route to X may be different at
each hop along a particular
address prefix is distributed via an IGP, the LSP, LDP peers for that
address prefix are the stack attribute value is passed
unchanged, and is set by IGP neighbors. If the LSP proxy egress.

Thus route to a particular
address prefix is distributed via BGP, the LSP proxy egress LDP peers for X becomes an "implicit peer" with each that address
prefix are the BGP peers. In other LSR in cases of LSP tunneling, the routing area or domain.
tunnel endpoints are LDP peers.

3.1.2.2. Distributing Labels

In this case, explicit
peering would be too unwieldy, because order to use MPLS for the number forwarding of peers would
become too large.

3.4. MPLS and Multi-Path Routing

If an normally routed traffic,
each LSR supports multiple routes for a particular Stream, then it
may assign multiple MUST:

1. bind one or more labels to the Stream, one each address prefix that appears in
its routing table;

2. for each route. Thus such address prefix X, use an LDP to distribute the reception
mapping of a second label mapping from a particular neighbor to X to each of its LDP Peers for X.

There is also one circumstance in which an LSR must distribute a particular
label mapping for an address prefix should be taken as meaning prefix, even if it is not the LSR which
bound that
either label can be used to represent that address prefix. prefix:

3. If multiple label mappings for R1 uses BGP to distribute a particular route to X, naming some other
LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has
assigned label L to X, then R1 must distribute the mapping
between T and X to any BGP peer to which it distributes that
route.

These rules ensure that labels corresponding to address prefix prefixes
which correspond to BGP routes are
specified, they may have distinct attributes. distributed to IGP neighbors if
and only if the BGP routes are distributed into the IGP. Otherwise,
the labels bound to BGP routes are distributed only to the other BGP

Rosen, Viswanathan & Callon [Page 43] 40]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

3.5. LSPs may draft-ietf-mpls-arch-01.txt March 1998

speakers.

These rules are intended to indicate which label mappings must be Multipoint-to-Point Entities

Consider
distributed by a given LSR to which other LSRs, NOT to indicate the case of packets P1 and P2, each of
conditions under which has a
destination address whose longest match, throughout a particular
routing domain, the distribution is address prefix X. Suppose that to be made. That is
discussed in section 2.19.

3.1.3. Using the Hop-by-hop Hop by Hop path for P1 is <R1, R2, R3>, and as the Hop-by-hop LSP

If the hop-by-hop path for P2 is <R4,
R2, R3>. Let's suppose that R3 binds label L3 to X, and distributes
this mapping to R2. R2 binds label L2 packet P needs to follow is <R1, ...,
Rn>, then <R1, ..., Rn> can be an LSP as long as:

1. there is a single address prefix X, and distributes this
mapping such that, for all i,
1<=i<n, X is the longest match in Ri's routing table for P's
destination address;

2. for all i, 1<i<n, Ri has assigned a label to both R1 X and R4. When R2 receives packet P1, its incoming distributed
that label will to R[i-1].

Note that a packet's LSP can extend only until it encounters a router
whose forwarding tables have a longer best match address prefix for
the packet's destination address. At that point, the LSP must end and
the best match algorithm must be L2. R2 will overwrite L2 performed again.

Suppose, for example, that packet P, with L3, and send P1 destination address
10.2.153.178 needs to go from R1 to R3.
When R2 receives packet P2, its incoming label will also be L2. R2
again overwrites L2 with L3, and send P2 on to R3.

Note then Suppose also that when P1 R2
advertises address prefix 10.2/16 to R1, but R3 advertises
10.2.153/22, 10.2.154/22, and P2 are traveling from 10.2/16 to R2. That is, R2 is
advertising an "aggregated route" to R3, they carry R1. In this situation, packet P
can be label Switched until it reaches R2, but since R2 has performed
route aggregation, it must execute the same label, best match algorithm to find
P's stream.

3.1.4. LSP Egress and as far as MPLS LSP Proxy Egress

An LSR R is concerned, they cannot considered to be
distinguished. Thus instead of talking about two distinct LSPs, <R1,
R2, R3> an "LSP Egress" LSR for address prefix X
if and <R4, R2, R3>, we might talk only if one of the following conditions holds:

1. R1 has an address Y, such that X is the address prefix in R1's
routing table which is the longest match for Y, or

2. R contains in its routing tables one or more address prefixes Y
such that X is a single "Multipoint-to-
Point LSP", which we might denote as <{R1, R4}, R2, R3>.

This creates a difficulty when we attempt to use conventional ATM
switches as LSRs. Since conventional ATM switches proper initial substring of Y, but R's "LSP
previous hops" for X do not support
multipoint-to-point connections, there must be procedures to ensure contain any such address prefixes
Y; that each LSP is, R2 is realized as a point-to-point VC. However, "deaggregation point" for address prefix X.

Rosen, Viswanathan & Callon [Page 41]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address
prefix X if ATM
switches which do support multipoint-to-point VCs and only if:

1. R1's next hop for X is R2 R1 and R2 are in use, then
the LSPs can be most efficiently realized not LDP Peers with
respect to X (perhaps because R2 does not support MPLS), or

2. R1 has been configured to act as multipoint-to-point VCs.
Alternatively, if an LSP Proxy Egress for X

The definition of LSP allows for the SVP Multipoint Encoding (section 2.21) can LSP Egress to be
used, a node which
does not support MPLS; in this case the penultimate node in the LSPs can be realized as multipoint-to-point SVPs.

3.6. LSP Tunneling between BGP Border Routers

Consider
is the case of an Autonomous System, A, which carries transit
traffic between other Autonomous Systems. Autonomous System A will
have a number of BGP Border Routers, and Proxy Egress.

3.1.5. The POP Label

The POP label is a mesh of BGP connections
among them, over label with special semantics which BGP routes are distributed. In many such
cases, it is desirable to avoid distributing the BGP routes an LSR can bind
to
routers which are not BGP Border Routers. an address prefix. If this can be avoided,
the "route distribution load" on those routers is significantly
reduced. However, there LSR Ru, by consulting its ILM, sees that
labeled packet P must be some means of ensuring forwarded next to Rd, but that Rd has
distributed a mapping of the
transit traffic will be delivered from Border Router POP label to Border Router
by the interior routers.

This can easily be done by means corresponding address
prefix, then instead of LSP Tunnels. Suppose that BGP
routes are distributed only to BGP Border Routers, and not to replacing the
interior routers that lie along value of the Hop-by-hop path from Border
Router to Border Router. LSP Tunnels can label on top of
the label stack, Ru pops the label stack, and then be used as follows:

Rosen, Viswanathan & Callon [Page 44]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

1. Each BGP Border Router distributes, to every other BGP Border
Router in forwards the same Autonomous System,
resulting packet to Rd.

LSR Rd distributes a mapping between the POP label for each and an address
prefix X to LSR Ru if and only if:

1. the rules of Section 3.1.2 indicate that it Rd distributes to that router via BGP.

2. The IGP Ru a
label mapping for X, and

2. when the Autonomous System maintains a host route for
each BGP Border Router. Each interior router distributes its
labels for these host routes to each of its IGP neighbors. LDP connection between Ru and Rd was opened, Ru
indicated that it could support the POP label, and

3. Suppose that:

a) BGP Border Router B1 receives an unlabeled packet P,

b) address prefix X in B1's routing table Rd is the longest
match an LSP Egress (not proxy egress) for X.

This causes the destination address of P,

c) the route to X is penultimate LSR on a BGP route,

d) LSP to pop the BGP Next Hop for X is B2,

e) B2 has bound label L1 to X, and has distributed this
mapping to B1,

f) stack. This
is quite appropriate; if the IGP next hop LSP Egress is an MPLS Egress for X, then
if the address of B2 is I1,

g) penultimate LSR does not pop the address of B2 is in B1's and I1's IGP routing tables
as a host route, and

h) I1 has bound label L2 to stack, the address of B2, and
distributed this mapping to B1.

Then before sending packet P LSP Egress
will need to I1, B1 must create a label
stack for P, then push on look up the label, pop the label L1, stack, and then push on label L2.

4. Suppose that BGP Border Router B1 receives a labeled Packet P,
where look up
the next label on (or look up the top of L3 address, if no more labels are
present). By having the penultimate LSR pop the label stack corresponds to an
address prefix, X, to which stack, the route LSP
Egress is a BGP route, and that
conditions 3b, 3c, 3d, and 3e all hold. Then before sending
packet P to I1, B1 must replace the label at the top of saved the
label stack with L1, and then push on label L2.

With these procedures, a given packet P follows a level 1 LSP all of
whose members are BGP Border Routers, and between each pair work of BGP
Border Routers having to look up two labels in order to
make its forwarding decision.

However, if the level 1 LSP, penultimate LSR is an ATM switch, it follows a level 2 LSP.

These procedures effectively create a Hop-by-Hop Routed LSP Tunnel
between may not have the BGP Border Routers.

Since
capability to pop the BGP border routers are exchanging label mappings stack. Hence a POP label mapping may be
distributed only to LSRs which can support that function.

If the penultimate LSR in an LSP for address prefix X is an LSP Proxy

Rosen, Viswanathan & Callon [Page 45] 42]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

address prefixes that are not even known to the IGP routing, draft-ietf-mpls-arch-01.txt March 1998

Egress, it acts just as if the BGP
routers should become explicit LDP peers with each other.

3.7. Other Uses of Hop-by-Hop Routed LSP Tunnels

The use of Hop-by-Hop Routed LSP Tunnels is not restricted to tunnels
between BGP Next Hops. Any situation Egress had distributed the POP
label for X.

3.1.6. Option: Egress-Targeted Label Assignment

There are situations in which one might otherwise
have used an encapsulation tunnel is one in which it is appropriate
to use a Hop-by-Hop Routed LSP Tunnel. Instead Ingress, Ri, knows that packets
of encapsulating several different streams must all follow the
packet with same LSP,
terminating at, say, LSP Egress Re. In this case, proper routing can
be achieved by using a new header whose destination address single label can be used for all such streams;
it is not necessary to have a distinct label for each stream. If
(and only if) the following conditions hold:

1. the address of LSR Re is itself in the tunnel's receive endpoint, the label corresponding routing table as a "host
route", and

2. there is some way for Ri to the address
prefix which determine that Re is the longest match LSP egress
for the address all packets in a particular set of streams

Then Ri may bind a single label to all FECS in the tunnel's
receive endpoint set. This is pushed on the packet's label stack. The packet
which
known as "Egress-Targeted Label Assignment."

How can LSR Ri determine that an LSR Re is sent into the tunnel may or may not already be labeled.

If the transmit endpoint LSP Egress for all
packets in a particular stream? There are a couple of possible ways:

- If the tunnel wishes to put network is running a labeled packet
into the tunnel, it must first replace the label value at link state routing algorithm, and all
nodes in the top of area support MPLS, then the stack routing algorithm
provides Ri with a label value that was distributed enough information to it by determine the
tunnel's receive endpoint. Then it routers
through which packets in that stream must push on leave the label which
corresponds routing
domain or area.

- It is possible to the tunnel itself, as distributed to it by the next
hop along the tunnel. To allow this, the tunnel endpoints should be
explicit use LDP peers. The label mappings they need to exchange pass information about which address
prefixes are of
no interest "attached" to the LSRs along the tunnel.

3.8. MPLS and Multicast

Multicast routing proceeds by constructing multicast trees. The tree
along which a particular multicast packet must get forwarded depends
in general egress LSRs. This method has
the advantage of not depending on the packet's source address and its destination
address. Whenever a particular LSR is a node in a particular
multicast tree, it binds a presence of link state
routing.

If egress-targeted label to that tree. It then distributes assignment is used, the number of labels
that mapping need to its parent on the multicast tree. (If be supported throughout the node in
question network may be greatly
reduced. This may be significant if one is on a LAN, using legacy switching
hardware to do MPLS, and has siblings on that LAN, it must also
distribute the mapping switching hardware can support only a
limited number of labels.

One possible approach would be to its siblings. This allows configure the parent network to use a single
egress-targeted label value when multicasting assignment by default, but to all children on the
LAN.)

When a multicast labeled packet arrives, the NHLFE corresponding configure
particular LSRs to
the NOT use egress-targeted label indicates the set of output interfaces assignment for that packet, as
well as the outgoing label. If one
or more of the same label encoding technique address prefixes for which it is
used on all the outgoing interfaces, the very same packet can be sent
to all an LSP egress. We
impose the children. following rule:

Rosen, Viswanathan & Callon [Page 46] 43]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

4. LDP Procedures

This section draft-ietf-mpls-arch-01.txt March 1998

- If a particular LSR is FFS.

5. Security Considerations

Security considerations are not discussed NOT an LSP Egress for some set of address
prefixes, then it should assign labels to the address prefixes in this version
the same way as is done by its LSP next hop for those address
prefixes. That is, suppose Rd is Ru's LSP next hop for address
prefixes X1 and X2. If Rd assigns the same label to X1 and X2,
Ru should as well. If Rd assigns different labels to X1 and X2,
then Ru should as well.

For example, suppose one wants to make egress-targeted label
assignment the default, but to assign distinct labels to those
address prefixes for which there are multiple possible LSP egresses
(i.e., for those address prefixes which are multi-homed.) One can
configure all LSRs to use egress-targeted label assignment, and then
configure a handful of LSRs to assign distinct labels to those
address prefixes which are multi-homed. For a particular multi-homed
address prefix X, one would only need to configure this
draft.

6. Authors' Addresses

Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: erosen@cisco.com

Arun Viswanathan
IBM Corp.
17 Skyline Drive
Hawthorne NY 10532
914-784-3273
E-mail: arunv@vnet.ibm.com

Ross Callon
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
508-952-7412
E-mail: rcallon@casc.com

7. References

[1] "A Framework in LSRs which
are either LSP Egresses or LSP Proxy Egresses for Multiprotocol Label Switching", R.Callon,
P.Doolan, N.Feldman, A.Fredette, G.Swallow, X.

It is important to note that if Ru and A.Viswanathan, work Rd are adjacent LSRs in progress, Internet Draft <draft-ietf-mpls-framework-01.txt>, July
1997.

[2] "ARIS: Aggregate Route-Based IP Switching", A. Viswanathan, N.
Feldman, R. Boivie, R. Woundy, work an LSP
for X1 and X2, forwarding will still be done correctly if Ru assigns
distinct labels to X1 and X2 while Rd assigns just one label to the
both of them. This just means that R1 will map different incoming
labels to the same outgoing label, an ordinary occurrence.

Similarly, if Rd assigns distinct labels to X1 and X2, but Ru assigns
to them both the label corresponding to the address of their LSP
Egress or Proxy Egress, forwarding will still be done correctly. Ru
will just map the incoming label to the label which Rd has assigned
to the address of that LSP Egress.

3.2. MPLS and Explicitly Routed LSPs

There are a number of reasons why it may be desirable to use explicit
routing instead of hop by hop routing. For example, this allows
routes to be based on administrative policies, and allows the routes
that LSPs take to be carefully designed to allow traffic engineering
(i.e., to allow intentional management of the loading of the
bandwidth through the nodes and links in progress, the network).

3.2.1. Explicitly Routed LSP Tunnels: Traffic Engineering

In some situations, the network administrators may desire to forward
certain classes of traffic along certain pre-specified paths, where
these paths differ from the Hop-by-hop path that the traffic would
ordinarily follow. This is known as Traffic Engineering.

Rosen, Viswanathan & Callon [Page 44]

Internet Draft
<draft-viswanathan-aris-overview-00.txt>, draft-ietf-mpls-arch-01.txt March 1997.

[3] "ARIS Specification", N. Feldman, A. Viswanathan, work in
progress, Internet Draft <draft-feldman-aris-spec-00.txt>, March
1997.

Rosen, Viswanathan & Callon [Page 47]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

[4] "ARIS Support for LAN Media Switching", S. Blake, A. Ghanwani, W.
Pace, V. Srinivasan, work in progress, Internet Draft <draft-blake-
aris-lan-00.txt>, March 1997.

[5] "Tag Switching Architecture - Overview", Rekhter, Davie, Katz,
Rosen, Swallow, Farinacci, work in progress, Internet Draft <draft-
rekhter-tagswitch-arch-00.txt>, January, 1997.

[6] "Tag distribution Protocol", Doolan, Davie, Katz, Rekhter, Rosen,
work in progress, Internet Draft <draft-doolan-tdp-spec-01.txt>, May,
1997.

[7] "Use of Tag Switching with ATM", Davie, Doolan, Lawrence,
McGloghrie, Rekhter, Rosen, Swallow, work in progress, Internet Draft
<draft-davie-tag-switching-atm-01.txt>, January, 1997.

[8] "Label Switching: Label Stack Encodings", Rosen, Rekhter, Tappan,
Farinacci, Fedorkow, Li, work in progress, Internet Draft <draft-
rosen-tag-stack-02.txt>, June, 1997.

[9] "Partitioning Tag Space among Multicast Routers on a Common
Subnet", Farinacci, work in progress, internet draft <draft-
farinacci-multicast-tag-part-00.txt>, December, 1996.

[10] "Multicast Tag Binding and Distribution using PIM", Farinacci,
Rekhter, work in progress, internet draft <draft-farinacci-
multicast-tagsw-00.txt>, December, 1996.

[11] "Toshiba's Router Architecture Extensions for ATM: Overview",
Katsube, Nagami, Esaki, RFC 2098, February, 1997.

[12] "Loop-Free Routing Using Diffusing Computations", J.J. Garcia-
Luna-Aceves, IEEE/ACM Transactions on Networking, Vol. 1, No. 1,
February 1993.

Appendix A Why Egress Control is Better

This section is written 1998

MPLS allows this to be easily done by Arun Viswanathan.

It is demonstrated here why egress control means of Explicitly Routed LSP
Tunnels. All that is a necessary and
sufficient mechanism for needed is:

1. A means of selecting the LDP, and therefore is packets that are to be sent into the optimal method
for
Explicitly Routed LSP Tunnel;

2. A means of setting up LSPs.

The necessary condition is established by citing counter examples
that can be achieved *only* by egress control. It's also established
why these typical scenarios are vital requirements for a
multiprotocol LDP. The sufficiency part is established by proving

Rosen, Viswanathan & Callon [Page 48]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997 the Explicitly Routed LSP Tunnel;

3. A means of ensuring that egress control subsumes packets sent into the local control.

Then finally, some discussions are made to mitigate concerns
expressed against Tunnel will not having local control. It is shown that local
control has clearly undesirable properties which may lead
loop from the receive endpoint back to severe
scalability and robustness problems. It is also shown that in having
both egress control and local control simultaneously in a network
leads the transmit endpoint.

If the transmit endpoint of the tunnel wishes to interoperability problems and how local control abrogates put a labeled packet
into the tunnel, it must first replace the label value at the essential benefits top of egress control.

A complete and self-contained case is presented here that clearly
establishes
the stack with a label value that egress control is was distributed to it by the preponderant mechanism for
LDP, and
tunnel's receive endpoint. Then it suffices must push on the label which
corresponds to support egress control alone as the
distribution paradigm.

A.1 Definition of an Egress

A node is identified tunnel itself, as an "egress" for a Stream, if:

1) it's at a routing boundary for that Stream,
2) distributed to it by the next
hop for that Stream is non-MPLS,
3) along the Stream is directly attached or tunnel. To allow this, the node itself.

Nodes that satisfy conditions 1 or 2 for Streams, will by default
start behaving as tunnel endpoints should be
explicit LDP peers. The label mappings they need to exchange are of
no interest to the LSRs along the tunnel.

3.3. Label Stacks and Implicit Peering

Suppose a particular LSR Re is an LSP proxy egress for those streams. Note that conditions 1 10 address
prefixes, and 2 can be learned dynamically. For condition 3, nodes will not by
default act as it reaches each address prefix through a distinct
interface.

One could assign a single label to all 10 address prefixes. Then Re
is an LSP egress for themselves or directly attached
networks. If this condition is made the default, the LSPs setup by
egress control will create LSPs all 10 address prefixes. This ensures that are identical
packets for all 10 address prefixes get delivered to Re. However, Re
would then have to look up the LSPs
created by local control.

A.2 Overview network layer address of Egress Control

When each such
packet in order to choose the proper interface to send the packet on.

Alternatively, one could assign a node distinct label to each interface.
Then Re is an egress for a Stream, it originates a LSP setup
message proxy egress for that particular Stream. The setup message is sent to all
MPLS neighbors, except the next hop neighbor. Each of these messages
to 10 address prefixes. This
eliminates the neighbors carry an appropriate label for that Stream. When a
node in a MPLS domain receives a setup message from a neighbor need for a
particular Stream, it checks if that neighbor is Re to look up the next hop for network layer addresses in
order to forward the
given Stream. If so, packets. However, it propagates can result in the message use of a
large number of labels.

An alternative would be to bind all its MPLS
neighbors, except the next hop from which 10 address prefixes to the message arrived. If
not, same
level 1 label (which is also bound to the node may keep address of the label provided in the setup message for
future use or negatively acknowledge the node that sent the message LSR itself),
and then to release bind each address prefix to a distinct level 2 label. The
level 2 label would be treated as an attribute of the level 1 label assignment. But it must not forward
mapping, which we call the setup
message from "Stack Attribute". We impose the incorrect next hop to any of its neighbors. This
flooding scheme is similar in mechanism to Reverse Path Multicast.

When a next hop for a Stream changes due to change in network
following rules:

Rosen, Viswanathan & Callon [Page 49] 45]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

topology, or a new node joins draft-ietf-mpls-arch-01.txt March 1998

- When LSR Ru initially labels an untagged packet, if the topology, longest
match for the node packet's destination address is locally
appended X, and R's LSP next
hop for X is Rd, and Rd has distributed to the existing LSP, without requiring egress intervention.
The node may either request the label R1 a mapping from the new next hop,
or use the previously stored (but unused) of label from that next hop.
In the former case, the new next hop immediately responds
L1 X, along with a stack attribute of L2, then

1. Ru must push L2 and then L1 onto the packet's label mapping stack,
and then forward the packet to Rd;

2. When Ru distributes label mappings for that Stream if it has X to its own downstream mapping
for that Stream.

A.3 Why Egress Control is Necessary

There are some important situations LDP peers,
it must include L2 as the stack attribute.

3. Whenever the stack attribute changes (possibly as a result
of a change in which egress control is
necessary:

- Shutting off an Ru's LSP

If for some reason a network administrator requires to "shut off"
a LSP setup for a particular Stream, s/he can configure the
egress node for that Stream next hop for X), Ru must distribute
the desired result. new stack attribute.

Note that although the requirement label value bound to shut off an LSP X may be different at
each hop along the LSP, the stack attribute value is a very fundamental one. If
a destination has network layer reachability but no MPLS layer
reachability (because of a problem in MPLS layer), shutting off
an passed
unchanged, and is set by the LSP provides proxy egress.

Thus the only means to reach that destination. This
mode of operation can be used by LSRs in a network that aren't a
sink LSP proxy egress for large amounts of data. These LSRs usually require X becomes an
occasional telnet or network management traffic. It's important
to provide the capability that such nodes "implicit peer" with each
other LSR in a network can the routing area or domain. In this case, explicit
peering would be
accessed through hop-by-hop connectivity avoiding too unwieldy, because the number of peers would
become too large.

3.4. MPLS layer
optimization. The reachability is more important than
optimization in instances like this. The MPLS architecture MUST
provide this capability.

Note that this is only possible in local control when each node
in and Multi-Path Routing

If an entire network is configured to shut off a LSP setup LSR supports multiple routes for a particular Stream. Such is neither desirable nor scalable.

- Egress Aggregation

In some networks, due to the absence of routing summarization,
aggregation may not be possible through routing information.
However, with Egress control, stream, then it is possible
may assign multiple labels to aggregate *all*
Streams that exit the network through stream, one for each route. Thus
the reception of a common egress node with second label mapping from a
single LSP. This is achieved easily because the egress simply particular neighbor
for a particular address prefix should be taken as meaning that
either label can use the same be used to represent that address prefix.

If multiple label mappings for all Streams.

Such a particular address prefix are
specified, they may have distinct attributes.

3.5. LSP Trees as Multipoint-to-Point Entities

Consider the case of packets P1 and P2, each of which has a
destination address whose longest match, throughout a particular
routing domain, is simply not possible with address prefix X. Suppose that the Local control; Hop-by-hop
path for P1 is <R1, R2, R3>, and the Hop-by-hop path for P2 is <R4,
R2, R3>. Let's suppose that R3 binds label L3 to X, and distributes
this mapping to R2. R2 binds label L2 to X, and distributes this
mapping to both R1 and R4. When R2 receives packet P1, its incoming
label will be L2. R2 will overwrite L2 with local
knowledge LSRs cannot map several Streams L3, and send P1 to a single R3.
When R2 receives packet P2, its incoming label
because it is unknown if Streams will diverge at some subsequent
downstream node. also be L2. R2

Rosen, Viswanathan & Callon [Page 50] 46]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

The egress aggregation works for both distance vector protocols draft-ietf-mpls-arch-01.txt March 1998

again overwrites L2 with L3, and link state protocols; it is protocol independent. send P2 on to R3.

Note then that when using VP switching in conjunction with some distance vector
protocols it becomes very essential that such aggregation be
possible, as there are many vendor switches that don't have VC
merging capability, P1 and have limited VP switching capability.
The egress control provides such vendors with a level-playing
field to compete with MPLS products. Moreover, this capability
can be very useful in enterprise networks; where several legacy
LANs at a site can be aggregated P2 are traveling from R2 to R3, they carry
the egress LSR at that site.
Furthermore, this approach can drastically reduce signalling same label, and
LSP state maintenance overheads in the entire network.

- Loop Prevention

The loop-prevention mechanism only works from the egress node for
multipoint-to-point as far as MPLS is concerned, they cannot be
distinguished. Thus instead of talking about two distinct LSPs, since the loop prevention mechanism
requires the list <R1,
R2, R3> and <R4, R2, R3>, we might talk of LSR nodes through a single "Multipoint-to-
Point LSP Tree", which the setup message
has already traversed in order we might denote as <{R1, R4}, R2, R3>.

This creates a difficulty when we attempt to identify and prevent LSP loops.

A loop prevention scheme is use conventional ATM
switches as LSRs. Since conventional ATM switches do not possible through local control.

- De-aggregation

Egress control provides the capability support
multipoint-to-point connections, there must be procedures to de-aggregate one or
more Streams from an aggregated Stream. For example, if a
network ensure
that each LSP is aggregating all CIDRs of an EBGP node into a single
LSP, with egress control, realized as a specific CIDR from this bundle point-to-point VC. However, if ATM
switches which do support multipoint-to-point VCs are in use, then
the LSPs can be
given its own dedicated LSP. This enables one to apply special
policies to specific CIDRs when required.

In most efficiently realized as multipoint-to-point VCs.
Alternatively, if the local control this SVP Multipoint Encoding (section 2.23) can be achieved only by configuring
every node in the network with specific de-aggregation
information and
used, the associated policy. This approach LSPs can lead
severe scalability problems.

- Unique Labels

As is known, when using VP merging, all ingresses must be realized as multipoint-to-point SVPs.

3.6. LSP Tunneling between BGP Border Routers

Consider the case of an Autonomous System, A, which carries transit
traffic between other Autonomous Systems. Autonomous System A will
have
unique VCI values to prevent cell interleaving. With egress
control, a number of BGP Border Routers, and a mesh of BGP connections
among them, over which BGP routes are distributed. In many such
cases, it is possible to distribute unique VCI values desirable to avoid distributing the
ingress nodes, avoiding the need BGP routes to configure each ingress node.
The egress node can pick a unique VCI for each ingress node.
Another benefit of egress control is that each egress
routers which are not BGP Border Routers. If this can be
configured with a unique label value in the case of egress
aggregation (as described above). Since avoided,
the label value "route distribution load" on those routers is
unique, the same label value can significantly
reduced. However, there must be used on all the segments some means of a
LSP. This enables one to identify anywhere in a network each LSP

Rosen, Viswanathan & Callon [Page 51]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997 ensuring that is associated with a certain egress node, thus easing
network debugging.

This again, is not possible in the local control because of the
lack of a single coordinating node.

A.4 Examples that work better through egress control

Local control needs to propagate attributes that come
transit traffic will be delivered from the
downstream node Border Router to all upstream nodes. Border Router
by the interior routers.

This behavior itself can easily be
LIKENED done by means of LSP Tunnels. Suppose that BGP
routes are distributed only to BGP Border Routers, and not to the egress control. Nevertheless,
interior routers that lie along the local control Hop-by-hop path from Border
Router to Border Router. LSP Tunnels can
achieve these only then be used as follows:

1. Each BGP Border Router distributes, to every other BGP Border
Router in the same Autonomous System, a severely inefficient manner. Since label for each node
only knows of local information, address
prefix that it creates and distributes an LSP
with incorrect attributes. As each node learns of new downstream
attributes, a correction is made as the attributes are propagated
upstream again. This can lead to that router via BGP.

2. The IGP for the Autonomous System maintains a worst case of O(n-squared) setup
messages host route for
each BGP Border Router. Each interior router distributes its
labels for these host routes to create a single LSP, where n is the number each of nodes its IGP neighbors.

3. Suppose that:

Rosen, Viswanathan & Callon [Page 47]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

a) BGP Border Router B1 receives an unlabeled packet P,

b) address prefix X in a
LSP.

In B1's routing table is the egress control, longest
match for the attribute distribution destination address of P,

c) the route to X is achieved during
initial LSP setup, with a single message from BGP route,

d) the egress BGP Next Hop for X is B2,

e) B2 has bound label L1 to
ingresses.

- TTL/Traceroute

The ingress requires a proper LSP hop-count value X, and has distributed this
mapping to decrement
TTL in packets that use a particular LSP, B1,

f) the IGP next hop for the address of B2 is I1,

g) the address of B2 is in environments such B1's and I1's IGP routing tables
as
ATM which do not have a TTL equivalent. This simulates the TTL
decrement which exists in an IP network, host route, and also enables scoping
utilities, such as traceroute,

h) I1 has bound label L2 to work as they do today in IP
networks. In egress control, the LSP hop-count is known at the
ingress as a by-product address of the LSP setup message, since an LSP
setup message traverses from egress B2, and
distributed this mapping to B1.

Then before sending packet P to ingress, I1, B1 must create a label
stack for P, then push on label L1, and increments
the hop-count at each node along the path.

- MTU

When the MTU at then push on label L2.

4. Suppose that BGP Border Router B1 receives a labeled Packet P,
where the egress node is smaller than label on the MTU at some top of the ingress nodes, packets originated at those ingress nodes
will be dropped when they reach the egress node. Hosts not using
MTU discovery have no means label stack corresponds to recover from this. However,
similar an
address prefix, X, to which the hop-count, the minimum LSP MTU can be propagated route is a BGP route, and that
conditions 3b, 3c, 3d, and 3e all hold. Then before sending
packet P to I1, B1 must replace the ingresses via egress control LSP setup messages, enabling label at the ingress to do fragmentation when required.

Rosen, Viswanathan & Callon [Page 52]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

- Implicit Peering

Implicit peering is top of the mechanism through which higher level
label stack labels are communicated to the ingress nodes. These with L1, and then push on label
values L2.

With these procedures, a given packet P follows a level 1 LSP all of
whose members are piggybacked BGP Border Routers, and between each pair of BGP
Border Routers in the LSP setup messages. This works
best with egress control; when the egress creates the setup
message, level 1 LSP, it can piggyback the stack labels at the same time.

- ToS/COS Based LSPs

When certain LSPs require higher or lower precedence or priority
through follows a network, level 2 LSP.

These procedures effectively create a Hop-by-Hop Routed LSP Tunnel
between the single egress node BGP Border Routers.

Since the BGP border routers are exchanging label mappings for
address prefixes that LSP can be
configured with the required priority and this can be
communicated in are not even known to the egress control LSP setup message. In IGP routing, the
local control, BGP
routers should become explicit LDP peers with each and every node in the network must be
configured per other.

Rosen, Viswanathan & Callon [Page 48]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

3.7. Other Uses of Hop-by-Hop Routed LSP to achieve the same result. Tunnels

The local control initially distributes labels to its neighbors
willy-nilly, and then waits for attributes to come through egress
control. Thus, local control use of Hop-by-Hop Routed LSP Tunnels is completely dependent on egress
control not restricted to provide complete functional operation tunnels
between BGP Next Hops. Any situation in which one might otherwise
have used an encapsulation tunnel is one in which it is appropriate
to LSPs. Otherwise,
local control requires that attributes be configured through use a Hop-by-Hop Routed LSP Tunnel. Instead of encapsulating the
entire network for each Stream. This
packet with a new header whose destination address is the most compelling argument
that local control is *not sufficient*; or conversely, egress control address of
the tunnel's receive endpoint, the label corresponding to the address
prefix which is necessary. This demonstrates egress control subsumes the local
control. Moreover, distribution longest match for the address of labels without associated
attributes may not be appropriate and may lead to undesired results.

A.5 Egress Control the tunnel's
receive endpoint is Sufficient pushed on the packet's label stack. The argument for sufficiency is proved by demonstrating that required
LSPs can be created with egress control, and this packet
which is sent into the tunnel may or may not already be labeled.

If the case transmit endpoint of the tunnel wishes to put a labeled packet
into the tunnel, it must first replace the label value at the top of
the stack with local control.

The egress control can create an LSP for every route entry made a label value that was distributed to it by the routing protocols:

1. A route can be learned from another routing domain, in which
case
tunnel's receive endpoint. Then it must push on the LSR at label which
corresponds to the routing domain will act tunnel itself, as an egress for distributed to it by the route and originate an LSP setup for that route.

2. A route can be a locally attached network or next
hop along the LSR itself may
be a host route. In this case, tunnel. To allow this, the LSR tunnel endpoints should be
explicit LDP peers. The label mappings they need to exchange are of
no interest to the LSRs along the tunnel.

3.8. MPLS and Multicast

Multicast routing proceeds by constructing multicast trees. The tree
along which such a route
is attached originates an LSP setup message.

Rosen, Viswanathan & Callon [Page 53]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

3. An particular multicast packet must get forwarded depends
in general on the packet's source address and its destination
address. Whenever a particular LSR with is a non-MPLS next-hop behaves as an egress for all
those route whose next-hop is the non-MPLS neighbor.

These three above methods can create an LSP for each route entry in a
network. Moreover, policy specific LSPs, as described previously,
can *only* be achieved with egress control. Thus, egress control is
necessary and sufficient for creating LSPs. QED.

A.6 Discussions

A.6.1 Is Local control faster than Egress control?

During topology changes, such as links going down, coming up, change
in link cost, etc, there is no difference in setup latency between
Egress Control and Local control. This is due to the fact that the node (Ru) which undergoes a change in next-hop for a Stream
immediately requests particular
multicast tree, it binds a label assignment from the new next hop node
(Rd). The new next hop node to that tree. It then immediately supplies the label distributes
that mapping for the requested Stream. As explained in the Egress Control
Method section, to its parent on the node Ru may already have stored label assignments
from multicast tree. (If the node Rd, in which case node Ru can immediately splice itself
to
question is on a LAN, and has siblings on that LAN, it must also
distribute the multipoint-to-point tree. Hence, new nodes are spliced into
existing LSPs locally. In mapping to its siblings. This allows the scenario where a network initially
learns of parent to
use a new route, although single label value when multicasting to all children on the Local control may setup LSPs
faster than
LAN.)

When a multicast labeled packet arrives, the Egress control, this difference in latency has no
perceived advantage. Since routing itself may take several seconds NHLFE corresponding to propagate and converge on
the new route information, label indicates the potential
latency set of egress control is small output interfaces for that packet, as
well as compared to the routing
protocol propagation time, and outgoing label. If the initial setup time at route
propagation time same label encoding technique is unimportant since these are long lived LSPs.

Moreover, the hurried distribution of labels in local control may not
carry much meaning because:

4. The associated attributes are not applied or propagated to the
ingress.

5. While the ingress may believe it has an LSP, in reality the
packets may be blackholed in the middle of
used on all the network if outgoing interfaces, the
full LSP is not established.

6. Policy based LSPs, which very same packet can only be achieved via egress
control as described above, may undo an un-used label
assignment established by local control.

A.6.2 Scalability and Robustness

It has been alleged that the egress control does not have sent
to all the children.

Rosen, Viswanathan & Callon [Page 54] 49]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

scalability draft-ietf-mpls-arch-01.txt March 1998

4. LDP Procedures for Hop-by-Hop Routed Traffic

4.1. The Procedures for Advertising and robustness properties required by distributed
processing. However, the egress uses a root distribution paradigm
commonly Using labels

In this section, we consider only label mappings that are used by many other standard routing protocols. For example, for
traffic to be label switched along its hop-by-hop routed path. In
these cases, the label in question will correspond to an address
prefix in the case of OSPF, LSAs routing table.

There are flooded through a domain originating at number of different procedures that may be used to
distribute label mappings. One such procedure is executed by the "egress", where
downstream LSR, and the difference being that others by the flooding in upstream LSR.

The downstream LSR must perform:

- The Distribution Procedure, and

- the
case of OSPF is contained through a sequence number Withdrawal Procedure.

The upstream LSR must perform:

- The Request Procedure, and in

- the Egress
control it is contained by NotAvailable Procedure, and

- the next hop validation. In Release Procedure, and

- the case labelUse Procedure.

The MPLS architecture supports several variants of
PIM (and some other multicast protocols), each procedure.

However, the distribution mechanism
is in fact exactly similar. Even MPLS architecture does not support all possible
combinations of all possible variants. The set of supported
combinations will be described in BGP with route reflection,
updates originate at section 4.2, where the root and traverse
interoperability between different combinations will also be
discussed.

4.1.1. Downstream LSR: Distribution Procedure

The Distribution Procedure is used by a tree structure to reach
the peers, as opposed downstream LSR to determine
when it should distribute a n-square mesh. label mapping for a particular address
prefix to its LDP peers. The commonality is the
distribution paradigm, in which the architecture supports four different
distribution originates at the
root of a tree and traverses the branches till it reaches all the
leaves. None of the above mentioned protocols have scalability or
robustness problems because procedures.

Irrespective of the distribution paradigm.

The ONLY concern expressed against to counter Egress control is particular procedure that is used, if the setup message does not propagate upstream from a certain node,
then the sub-tree label
mapping for a particular address prefix has been distributed by a
downstream LSR Rd to an upstream LSR Ru, and if at any time the

Rosen, Viswanathan & Callon [Page 50]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

attributes (as defined above) of that node will not be added into mapping change, then Rd must
inform Ru of the
LSP. It's new attributes.

If an LSR is maintaining multiple routes to a reasonable concern, but further analysis shows that it's
not particular address
prefix, it is a realistic problem. The impact of this problem compared local matter as to whether that LSR maps multiple
labels to the
impact address prefix (one per route), and hence distributes
multiple mappings.

4.1.1.1. PushUnconditional

Let Rd be an LSR. Suppose that:

1. X is an address prefix in Rd's routing table

2. Ru is an LDP Peer of Rd with respect to X

Whenever these conditions hold, Rd must map a similar problem in local control are exactly the same
when LSRs employed in a MPLS domain have little or no forwarding
capabilities (for example, ATM LSRs), since in both cases, packets
are blackholed. In fact, in the egress control the packets for
afflicted LSPs will be dropped right at the ingress, while with local
control the packets will be dropped at the point of breakage, causing
packets label to unnecessarily traverse part way through the network. When
reasonable forwarding capability exists in the MPLS domain, with the
egress control the packets may be forwarded hop-by-hop till the point
where X and
distribute that mapping to Ru. It is the LSP setup ended. Whereas in case responsibility of local control, the
packets will label switched till the point Rd to
keep track of breakage and hop-by-hop
forwarded till the LSP segment resumes. Since egress control mappings which it has
advantages when there is no forwarding capability, distributed to Ru, and local control
is to
make sure that Ru always has advantages when there these mappings.

4.1.1.2. PushConditional

Let Rd be an LSR. Suppose that:

1. X is forwarding capability, there an address prefix in Rd's routing table

2. Ru is an
equal tradeoff between them, and thus, neither LDP Peer of Rd with respect to X

3. Rd is superior either an LSP Egress or
inferior in this regard. This latter case an LSP Proxy Egress for X, or
Rd's L3 next hop for X is simply a loss in
optimization, since the network has reasonable forwarding
capabilities. Hence the robustness issue Rn, where Rn is not distinct from Ru, and
Rn has bound a problem in either
types of networks. As mentioned before, the local control is
dependent on egress control for distributing attributes. The
attribute distribution could then also face the same problem of
stalled propagation, which would lead label to erroneous LSP setup. So,
the local control can also be seen X and distributed that mapping to Rd.

Then as afflicted with this problem, if
it exists.

Moreover, if stalled propagation were truly soon as these conditions all hold, Rd should map a problem, there are
other schemes in MPLS label to X
and distribute that would face mapping to Ru.

Whereas PushUnconditional causes the same issue. For example, distribution of label mappings
for all address prefixes in the routing table, PushConditional causes
the distribution of label mappings only for those address prefixes
for which one has received label mappings from one's LSP next hop, or
for which one does not have an MPLS-capable L3 next hop.

Rosen, Viswanathan & Callon [Page 55] 51]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

the draft-ietf-mpls-arch-01.txt March 1998

4.1.1.3. PulledUnconditional

Let Rd be an LSR. Suppose that:

1. X is an address prefix in Rd's routing table

2. Ru is a label distribution through PIM, Explicit Route setup, and RSVP
would also not work, and therefore should be withdrawn :-).

Note that exhaustion peer of Rd with respect to X

3. Ru has explicitly requested that Rd map a label space cannot stall the propagation of
messages to X and
distribute the upstream nodes. Appropriate indications can be given mapping to the upstream nodes in the setup message that no label allocation
was made because of exhaustion of Ru

Then Rd should map a label space, so that correct action
can be taken at the upstream nodes, to X and yet the LSP setup would
continue.

A.6.3 Conclusion

The attempt here distribute that mapping to Ru.
Note that if X is not to deride the local control, but since one
method subsumes the features and properties in Rd's routing table, or if Rd is not an LDP
peer of the other, Ru with respect to X, then why
support both and complicate implementation, interoperability and
maintenance? In fact RFC1925 says, "In protocol design, perfection
has been reached not when there is nothing left to add, but when
there is nothing left to take away". A usual diplomatic resolution
for such controversy is to make accommodations for both. We feel Rd must inform Ru that it's it cannot
provide a poor choice of architecture to support both. That is why
we feel strongly that mapping at this must be evaluated by the MPLS WG.

In time.

If Rd has already distributed a way, controlling the network behavior as mapping for address prefix X to which LSP are
formed, which Streams Ru,
and it receives a new request from Ru for a mapping for address
prefix X, it will map to which LSPs, a second label, and distribute the associated
attributes, can be compared new mapping
to applying policies at the edges of Ru. The first label mapping remains in effect.

4.1.1.4. PulledConditional

Let Rd be an
AS. This is precisely what the egress control provides, a rich and
varied policy control at the egress node of LSPs.

Appendix B Why Local Control LSR. Suppose that:

1. X is Better

This section an address prefix in Rd's routing table

2. Ru is written by Eric Rosen.

The remaining area of dispute between advocates a label distribution peer of "local control" Rd with respect to X

3. Ru has explicitly requested that Rd map a label to X and advocates of "egress control" is relatively small. In
particular, there is agreement on
distribute the following points:

1. If LSR R1's mapping to Ru

4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or
Rd's L3 next hop for address prefix X is LSR R2, and R2 Rn, where Rn is
in a different area or in a different routing domain than R1,
then R1 may assign distinct from Ru, and distribute
Rn has bound a label for X, even if R2 has
not done so.

This means to X and distributed that even under egress control, the border routers mapping to Rd,
or

Then as soon as these conditions all hold, Rd should map a label to X
and distribute that mapping to Ru. Note that if X is not in one autonomous system do Rd's
routing table, or if Rd is not have a label distribution peer of Ru with
respect to wait, before
distributing labels, for X, then Rd must inform Ru that it cannot provide a mapping
at this time.

However, if the only condition that fails to hold is that Rn has not
yet provided a label to Rd, then Rd must defer any downstream routers which are in
other autonomous systems. response to Ru
until such time as it has receiving a mapping from Rn.

Rosen, Viswanathan & Callon [Page 56] 52]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

2. draft-ietf-mpls-arch-01.txt March 1998

If LSR R1's next hop for address prefix X is LSR R2, but R1
receives Rd has distributed a label mapping for address prefix X from LSR R3, then R1 may
remember R3's mapping. If, to Ru, and
at some later time, R3 becomes R1's
next hop for S, then (if R1 is not using loop prevention) R1
may immediately begin using R3 as the LSP next hop for S, using
the remembered mapping from R3.

3. Attributes which are passed upstream from the egress may change
over time, as a result of reconfiguration any attribute of the egress, or of
other events. This means that even if egress control is used,
LSRs label mapping changes, then
Rd must be able redistribute the label mapping to accept attribute changes on existing LSPs;
attributes are not fixed when Ru, with the LSP is first constructed, nor new attribute.
It must do this even though Ru does a change in attributes require not issue a new LSP to be
constructed.

The dispute is centered on Request.

In section 4.2, we will discuss how to choose the situation in which particular
procedure to be used at any given time, and how to ensure
interoperability among LSRs that choose different procedures.

4.1.2. Upstream LSR: Request Procedure

The Request Procedure is used by the following
conditions hold:

- upstream LSR R1's next hop for an address
prefix X is within the same
administrative domain as R1, and

- R1's next hop for X has not distributed to R1 determine when to explicitly request that the downstream
LSR map a label for X, and

- R1 has not yet distributed to its neighbors any labels for X.

With local control, R1 is permitted to that prefix and distribute the mapping. There are
three possible procedures that can be used.

4.1.2.1. RequestNever

Never make a label for X to
its neighbors; with egress control it request. This is not.

From an implementation perspective, useful if the difference then between
egress control and local control is relatively small. Egress control
simply creates an additional state in downstream LSR uses the label distribution process,
and prohibits label distribution in that state.

From
PushConditional procedure or the perspective of network behavior, however, this difference PushUnconditional procedure, but is
not useful if the downstream LSR uses the PulledUnconditional
procedure or the the Pulledconditional procedures.

4.1.2.2. RequestWhenNeeded

Make a bit more significant:

- Egress control adds latency to request whenever the initial construction of an
LSP, because L3 next hop to the path must be set up serially, node by node address prefix
changes, and one doesn't already have a label mapping from that next
hop for the egress. With local control, all LSRs along the path may
perform their setup activities in parallel.

- Egress control adds additional interdependencies among nodes, as
there given address prefix.

4.1.2.3. RequestOnRequest

Issue a request whenever a request is something that one node cannot do until some other node
does something else first, received, in addition to
issuing a request when needed (as described in section 4.1.2.2). If
Rd receives such a request from Ru, for an address prefix for which
Rd has already distributed Ru a label, Rd shall assign a new
(distinct) label, map it cannot do until some other
node does something first, etc. to X, and distribute that mapping. (Whether
Rd can distribute this mapping to Ru immediately or not depends on
the Distribution Procedure being used.)

This procedure is problematical for a
number of reasons. useful when the LSRs are implemented on
conventional ATM switching hardware.

Rosen, Viswanathan & Callon [Page 57] 53]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

* In robust system design, one tries to avoid such
interdependencies, since they always bring along robustness draft-ietf-mpls-arch-01.txt March 1998

4.1.3. Upstream LSR: NotAvailable Procedure

If Ru and Rd are respectively upstream and scalability problems.

* In some situations, it is advantageous for a node to use
MPLS, even if some node downstream is not functioning
properly label
distribution peers for address prefix X, and hence not assigning labels as it should.

These disadvantages might be tolerable if there Rd is some significant
problem which can be solved by egress control, Ru's L3 next hop
for X, and Ru requests a mapping for X from Rd, but not by local
control. So Rd replies that
it is worth looking to see if there is such cannot provide a problem. mapping at this time, then the NotAvailable
procedure determines how Ru responds. There are two possible
procedures governing Ru's behavior:

4.1.3.1. RequestRetry

Ru should issue the request again at a number of situations in which it may be desirable later time. That is, the
requester is responsible for an
LSP Ingress node trying again later to know certain attributes of obtain the LSP, e.g., needed
mapping.

4.1.3.2. RequestNoRetry

Ru should never reissue the
number of hops in request, instead assuming that Rd will
provide the LSP. It mapping automatically when it is sometimes claimed that obtaining
such information requires available. This is
useful if Rd uses the use of egress control. However, this PushUnconditional procedure or the
PushConditional procedure.

4.1.4. Upstream LSR: Release Procedure

Suppose that Rd is not true. Any attribute of an LSP is liable to change after the
LSP exists. Procedures LSR which has bound a label to detect address prefix
X, and communicate the change must
exist. These procedures CANNOT be tied to the initial construction
of the LSP, since they must execute after the LSP has already been
constructed. The ability distributed that mapping to pass control information upstream along
a path towards an ingress node LSR Ru. If Rd does not presuppose anything about the
procedures used happen
to construct the path.

The fundamental issue separating the advocates of egress control from
the advocates of local control is really a network management issue.
To advocates of egress control, setting up an LSP be Ru's L3 next hop for a particular address prefix is analogous X, or has ceased to setting up a PVC be Ru's
L3 next hop for address prefix X, then Rd will not be using the
label. The Release Procedure determines how Ru acts in an ATM network.
When setting up a PVC, one goes to one of this case.
There are two possible procedures governing Ru's behavior:

4.1.4.1. ReleaseOnChange

Ru should release the PVC endpoints mapping, and
enters certain configuration information. Similarly, one might think inform Rd that to set up an LSP for a particular address prefix, one goes to it has done so.

4.1.4.2. NoReleaseOnChange

Ru should maintain the mapping, so that it can use it again
immediately if Rd later becomes Ru's L3 next hop for X.

Rosen, Viswanathan & Callon [Page 54]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

4.1.5. Upstream LSR: labelUse Procedure

Suppose Ru is an LSR which is the egress has received label mapping L for that address prefix,
prefix X from LSR Rd, and enters
configuration information. This allows the network administrator
complete control Ru is upstream of which address prefixes are assigned LSPs Rd with respect to X, and
which are not. And if this
in fact Rd is one's management model, egress control
does simplify the configuration issues.

On Ru's L3 next hop for X.

Ru will make use of the other hand, mapping if one's model Rd is that Ru's L3 next hop for X. If,
at the LSPs get set up
automatically by time the network, as a result mapping is received by Ru, Rd is NOT Ru's L3 next hop
for X, Ru does not make any use of the operation mapping at that time. Ru may
however start using the mapping at some later time, if Rd becomes
Ru's L3 next hop for X.

The labelUse Procedure determines just how Ru makes use of Rd's
mapping.

There are three procedures which Ru may use:

4.1.5.1. UseImmediate

Ru may put the
routing algorithm, then egress control mapping into use immediately. At any time when Ru has
a mapping for X from Rd, and Rd is of no utility at all. When
one hears Ru's L3 next hop for X, Rd will
also be Ru's LSP next hop for X.

4.1.5.2. UseIfLoopFree

Ru will use the claim mapping only if it determines that "egress control allow you to control your
network from by doing so, it
will not cause a few nodes", what forwarding loop.

If Ru has a mapping for X from Rd, and Rd is really being claimed (or becomes) Ru's L3
next hop for X, but Rd is "egress
control simplifies NOT Ru's current LSP next hop for X, Ru
does NOT immediately make Rd its LSP next hop. Rather, it initiates
a loop prevention algorithm. If, upon the job completion of manually configuring all the LSPs in
your network". Of course, if you don't intend this
algorithm, Rd is still the L3 next hop for X, Ru will make Rd the LSP
next hop for X, and use L as the outgoing label.

The loop prevention algorithm to be used is still under
consideration.

4.1.5.3. UseIfLoopNotDetected

This procedure is the same as UseImmediate, unless Ru has detected a
loop in the LSP. If a loop has been detected, Ru will discard
packets that would otherwise have been labeled with L and sent to Rd.

This will continue until the next hop for X changes, or until the

Rosen, Viswanathan & Callon [Page 55]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

loop is no longer detected.

4.1.6. Downstream LSR: Withdraw Procedure

In this case, there is only a single procedure.

When LSR Rd decides to break the mapping between label L and address
prefix X, then this unmapping must be distributed to manually configure all LSRs to
which the LSPs mapping was distributed.

It is desirable, though not required, that the unmapping of L from X
be distributed by Rd to a LSR Ru before Rd distributes to Ru any new
mapping of L to any other address prefix Y, where X != Y. If Ru
learns of the new mapping of L to Y before it learns of the unmapping
of L from X, and if packets matching both X and Y are forwarded by Ru
to Rd, then for a period of time, Ru will label both packets matching
X and packets matching Y with label L.

The distribution and withdrawal of label mappings is done via a label
distribution protocol, or LDP. LDP is a two-party protocol. If LSR R1
has received label mappings from LSR R2 via an instance of an LDP,
and that instance of that protocol is closed by either end (whether
as a result of failure or as a matter of normal operation), then all
mappings learned over that instance of the protocol must be
considered to have been withdrawn.

As long as the relevant LDP connection remains open, label mappings
that are withdrawn must always be withdrawn explicitly. If a second
label is bound to an address prefix, the result is not to implicitly
withdraw the first label, but to map both labels; this is needed to
support multi-path routing. If a second address prefix is bound to a
label, the result is not to implicitly withdraw the mapping of that
label to the first address prefix, but to use that label for both
address prefixes.

4.2. MPLS Schemes: Supported Combinations of Procedures

Consider two LSRs, Ru and Rd, which are label distribution peers with
respect to some set of address prefixes, where Ru is the upstream
peer and Rd is the downstream peer.

The MPLS scheme which governs the interaction of Ru and Rd can be
described as a quintuple of procedures: <Distribution Procedure,
Request Procedure, NotAvailable Procedure, Release Procedure,
labelUse Procedure>. (Since there is only one Withdraw Procedure, it
need not be mentioned.) A "*" appearing in one of the positions is a

Rosen, Viswanathan & Callon [Page 56]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

wild-card, meaning that any procedure in that category may be
present; an "N/A" appearing in a particular position indicates that
no procedure in that category is needed.

Only the MPLS schemes which are specified below are supported by the
MPLS Architecture. Other schemes may be added in the future, if a
need for them is shown.

4.2.1. TTL-capable LSP Segments

If Ru and Rd are MPLS peers, and both are capable of decrementing a
TTL field in the MPLS header, then the MPLS scheme in use between Ru
and Rd must be one of the following:

<PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
UseImmediate>

<PushConditional, RequestWhenNeeded, RequestNoRetry, *, *>

The former, roughly speaking, is "local control with downstream label
assignment". The latter is an egress control scheme.

4.2.2. Using ATM Switches as LSRs

The procedures for using ATM switches as LSRs depends on whether the
ATM switches can realize LSP trees as multipoint-to-point VCs or VPs.

Most ATM switches existing today do NOT have a multipoint-to-point
VC-switching capability. Their cross-connect tables could easily be
programmed to move cells from multiple incoming VCs to a single
outgoing VC, but the result would be that cells from different
packets get interleaved.

Some ATM switches do support a multipoint-to-point VC-switching
capability. These switches will queue up all the incoming cells from
an incoming VC until a packet boundary is reached. Then they will
transmit the entire sequence of cells on the outgoing VC, without
allowing cells from any other packet to be interleaved.

Many ATM switches do support a multipoint-to-point VP-switching
capability, which can be used if the Multipoint SVP label encoding is
used.

Rosen, Viswanathan & Callon [Page 57]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

4.2.2.1. Without Multipoint-to-point Capability

Suppose that R1, R2, R3, and R4 are ATM switches which do not support
multipoint-to-point capability, but are being used as LSRs. Suppose
further that the L3 hop-by-hop path for address prefix X is <R1, R2,
R3, R4>, and that packets destined for X can enter the network at any
of these LSRs. Since there is no multipoint-to-point capability, the
LSPs must be realized as point-to-point VCs, which means that there
needs to be three such VCs for address prefix X: <R1, R2, R3, R4>,
<R2, R3, R4>, and <R3, R4>.

Therefore, if R1 and R2 are MPLS peers, and either is an LSR which is
implemented using conventional ATM switching hardware (i.e., no cell
interleave suppression), the MPLS scheme in use between R1 and R2
must be one of the following:

<PulledUnconditional, RequestOnRequest, RequestRetry,
ReleaseOnChange, UseImmediate>

<PulledConditional, RequestOnRequest, RequestNoRetry,
ReleaseOnChange, *>

The use of the RequestOnRequest procedure will cause R4 to distribute
three labels for X to R3; R3 will distribute 2 labels for X to R2,
and R2 will distribute one label for X to R1.

The first of these procedures is the "optimistic downstream-on-
demand" variant of local control. The second is the "conservative
downstream-on-demand" variant of local control.

An egress control scheme which works in the absence of multipoint-
to-point capability is for further study.

4.2.2.2. With Multipoint-To-Point Capability

If R1 and R2 are MPLS peers, and either of them is an LSR which is
implemented using ATM switching hardware with cell interleave
suppression, and neither is an LSR which is implemented using ATM
switching hardware that does not have cell interleave suppression,
then the MPLS scheme in use between R1 and R2 must be one of the
following;

<PushConditional, RequestWhenNeeded, RequestNoRetry, *, *>

<PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
UseImmediate>

Rosen, Viswanathan & Callon [Page 58]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

<PulledConditional, RequestOnRequest, RequestNoRetry,
ReleaseOnChange, *>

The first of these is an egress control scheme. The second is is the
"downstream" variant of local control. The third is the
"conservative downstream-on-demand" variant of local control.

4.2.3. Interoperability Considerations

It is easy to see that certain quintuples do NOT yield viable MPLS
schemes. For example:

- <PulledUnconditional, RequestNever, *, *, *>
<PulledConditional, RequestNever, *, *, *>

In these MPLS schemes, the downstream LSR Rd distributes label
mappings to upstream LSR Ru only upon request from Ru, but Ru
never makes any such requests. Obviously, these schemes are not
viable, since they will not result in the proper distribution of
label mappings.

- <*, RequestNever, *, *, ReleaseOnChange>

In these MPLS schemes, Rd releases mappings when it isn't using
them, but it never asks for them again, even if it later has a
need for them. These schemes thus do not ensure that label
mappings get properly distributed.

In this section, we specify rules to prevent a pair of LDP peers from
adopting procedures which lead to infeasible MPLS Schemes. These
rules require the exchange of information between LDP peers during
the initialization of the LDP connection between them.

1. Each must state whether it is an ATM switch, and if so, whether
it has cell interleave suppression.

2. If Rd is an ATM switch without cell interleave suppression, it
must state whether it intends to use the PulledUnconditional
procedure or the Pulledconditional procedure. If the former,
Ru MUST use the RequestRetry procedure; if the latter, Ru MUST
use the RequestNoRetry procedure.

3. If Ru is an ATM switch without cell interleave suppression, it
must state whether it intends to use the RequestRetry or the
RequestNoRetry procedure. If Rd is an ATM switch without cell
interleave suppression, Rd is not bound by this, and in fact Ru
MUST adopt Rd's preferences. However, if Rd is NOT an ATM

Rosen, Viswanathan & Callon [Page 59]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

switch without cell interleave suppression, then if Ru chooses
RequestRetry, Rd must use PulledUnconditional, and if Ru
chooses RequestNoRetry, Rd MUST use PulledConditional.

4. If Rd is an ATM switch with cell interleave suppression, it
must specify whether it prefers to use PushConditional,
PushUnconditional, or PulledConditional. If Ru is not an ATM
switch without cell interleave suppression, it must then use
RequestWhenNeeded and RequestNoRetry, or else RequestNever and
NoReleaseOnChange, respectively.

5. If Ru is an ATM switch with cell interleave suppression, it
must specify whether it prefers to use RequestWhenNeeded and
RequestNoRetry, or else RequestNever and NoReleaseOnChange. If
Rd is NOT an ATM switch with cell interleave suppression, it
must then use either PushConditional or PushUnconditional,
respectively.

4.2.4. How to do Loop Prevention

TBD

4.2.5. How to do Loop Detection

TBD.

4.2.6. Security Considerations

Security considerations are not discussed in this version of this
draft.

5. Authors' Addresses

Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: erosen@cisco.com

Arun Viswanathan
Lucent Technologies
101 Crawford Corner Rd., #4D-537
Holmdel, NJ 07733
732-332-5163

Rosen, Viswanathan & Callon [Page 60]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

E-mail: arunv@dnrc.bell-labs.com

Ross Callon
IronBridge Networks
55 Hayden Avenue,
Lexington, MA 02173
+1-781-402-8017
E-mail: rcallon@ironbridgenetworks.com

6. References

[1] "A Framework for Multiprotocol Label Switching", R.Callon,
P.Doolan, N.Feldman, A.Fredette, G.Swallow, and A.Viswanathan, work
in progress, Internet Draft <draft-ietf-mpls-framework-02.txt>,
November 1997.

[2] "ARIS: Aggregate Route-Based IP Switching", A. Viswanathan, N.
Feldman, R. Boivie, R. Woundy, work in progress, Internet Draft
<draft-viswanathan-aris-overview-00.txt>, March 1997.

[3] "ARIS Specification", N. Feldman, A. Viswanathan, work in
progress, Internet Draft <draft-feldman-aris-spec-00.txt>, March
1997.

[4] "Tag Switching Architecture - Overview", Rekhter, Davie, Katz,
Rosen, Swallow, Farinacci, work in progress, Internet Draft <draft-
rekhter-tagswitch-arch-00.txt>, January, 1997.

[5] "Tag distribution Protocol", Doolan, Davie, Katz, Rekhter, Rosen,
work in progress, Internet Draft <draft-doolan-tdp-spec-01.txt>, May,
1997.

[6] "Use of Tag Switching with ATM", Davie, Doolan, Lawrence,
McGloghrie, Rekhter, Rosen, Swallow, work in progress, Internet Draft
<draft-davie-tag-switching-atm-01.txt>, January, 1997.

[7] "Label Switching: Label Stack Encodings", Rosen, Rekhter, Tappan,
Farinacci, Fedorkow, Li, Conta, work in progress, Internet Draft
<draft-ietf-mpls-label-encaps-01.txt>, February, 1998.

[8] "Partitioning Tag Space among Multicast Routers on a Common
Subnet", Farinacci, work in your network, this is irrelevant.

So before an egress control scheme is adopted, one should ask whether
complete manual configuration of the set of address prefixes which progress, internet draft <draft-
farinacci-multicast-tag-part-00.txt>, December, 1996.

[9] "Multicast Tag Binding and Distribution using PIM", Farinacci,
Rekhter, work in progress, internet draft <draft-farinacci-
multicast-tagsw-00.txt>, December, 1996.

Rosen, Viswanathan & Callon [Page 58] 61]

Internet Draft draft-ietf-mpls-arch-00.txt August 1997

get assigned LSPs is necessary. That is, is this capability needed
to solve a real problem?

It is sometimes claimed that egress control is needed if one wants to
conserve labels by assigning a single label to all address prefixes
which have the same egress. This is not true. If the network is
running a link state routing algorithm, each LSR already knows which
address prefixes have a common egress, and hence can assign a common
label. If the network is running a distance vector routing protocol,
information about which address prefixes have a common egress can be
made to "bubble up" from the egress, using LDP, even if local control
is used.

It is only in the case where the number of available labels is so
small that their use must be manually administered that egress
control has an advantage. It may be arguable that egress control
should be an option that can be used draft-ietf-mpls-arch-01.txt March 1998

[10] "Toshiba's Router Architecture Extensions for the special cases in which
it provides value. In most cases, there is no reason to have it at
all. ATM: Overview",
Katsube, Nagami, Esaki, RFC 2098, February, 1997.

[11] "Loop-Free Routing Using Diffusing Computations", J.J. Garcia-
Luna-Aceves, IEEE/ACM Transactions on Networking, Vol. 1, No. 1,
February 1993.

Rosen, Viswanathan & Callon [Page 59] 62]

Internet Draft draft-ietf-mpls-arch-01.txt March 1998

Rosen, Viswanathan & Callon [Page 63]

----