RFC relevance of switching

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

Network Working Group B.
Request for Comments: 3035 J.
Category: Standards Track K.
E.
G.
Cisco Systems, Inc
Y.
Juniper
P.
Ennovate Networks, Inc
January 2001

MPLS using LDP and ATM VC

Status of this

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

Copyright

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

The Multiprotocol Label Switching (MPLS) Architecture [1] discusses
way in which Asynchronous Transfer Mode (ATM) switches may be used
Label Switching Routers. The ATM switches run network layer
algorithms (such as Open Shortest Path First (OSPF),
System to Intermediate System (IS-IS), etc.), and their
forwarding is based on the results of these routing algorithms.
ATM-specific routing or addressing is needed. ATM switches used
this way are known as ATM-LSRs (Label Switching Routers).

This document extends and clarifies the relevant portions of [1]
[2] by specifying in more detail the procedures which to be used
distributing labels to or from ATM-LSRs, when those labels
Forwarding Equivalence Classes (FECs, see [1]) for which the
are determined on a hop-by-hop basis by network layer
algorithms

This document also specifies the MPLS encapsulation to be used
sending labeled packets to or from ATM-LSRs, and in that respect is
companion document to [3].

Davie Standards Track [Page 1]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

Table of

1 Introduction ........................................... 2
2 Specification of Requirements .......................... 3
3 Definitions ............................................ 3
4 Special Characteristics of ATM Switches ................ 4
5 Label Switching Control Component for ATM .............. 5
6 Hybrid Switches (Ships in the Night) ................... 5
7 Use of VPI/VCIs ....................................... 5
7.1 Direct Connections ..................................... 6
7.2 Connections via an ATM VP .............................. 7
7.3 Connections via an ATM SVC ............................. 7
8 Label Distribution and Maintenance Procedures .......... 7
8.1 Edge LSR Behavior ...................................... 8
8.2 Conventional ATM Switches (non-VC-merge) ............... 9
8.3 VC-merge-capable ATM Switches .......................... 11
9 Encapsulation .......................................... 12
10 TTL Manipulation ....................................... 13
11 Optional Loop Detection: Distributing Path Vectors ..... 15
11.1 When to Send Path Vectors Downstream ................... 15
11.2 When to Send Path Vectors Upstream ..................... 16
12 Security Considerations ................................ 17
13 Intellectual Property Considerations ................... 17
14 References ............................................. 18
15 Acknowledgments ........................................ 18
16 Authors' Addresses ..................................... 18
17 Full Copyright Statement ............................... 20

1.

The MPLS Architecture [1] discusses the way in which ATM switches
be used as Label Switching Routers. The ATM switches run
layer routing algorithms (such as OSPF, IS-IS, etc.), and their
forwarding is based on the results of these routing algorithms.
ATM-specific routing or addressing is needed. ATM switches used
this way are known as ATM-LSRs

This document extends and clarifies the relevant portions of [1]
[2] by specifying in more detail the procedures which are to be
for distributing labels to or from ATM-LSRs, when those
represent Forwarding Equivalence Classes (FECs, see [1]) for
the routes are determined on a hop-by-hop basis by network
routing algorithms. The label distribution technique described
is referred to in [1] as "downstream-on-demand". This
distribution technique MUST be used by ATM-LSRs that are not
of "VC merge" (defined in section 3), and is OPTIONAL for ATM-
that are capable of VC merge

Davie Standards Track [Page 2]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

This document does NOT specify the label distribution techniques
be used in the following cases

- the routes are explicitly chosen before label
begins, instead of being chosen on a hop-by-hop basis as
distribution proceeds

- the routes are intended to diverge in any way from the
chosen by the conventional hop-by-hop routing at any time

- the labels represent FECs that consist of multicast packets

- the LSRs use "VP merge".

Further statements made in this document about ATM-LSR
distribution do not necessarily apply in these cases

This document also specifies the MPLS encapsulation to be used
sending labeled packets to or from ATM-LSRs, and in that respect is
companion document to [3]. The specified encapsulation is to be
for multicast or explicitly routed labeled packets as well

This document uses terminology from [1].

2. Specification of

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

3.

A Label Switching Router (LSR) is a device which implements the
switching control and forwarding components described in [1].

A label switching controlled ATM (LC-ATM) interface is an
interface controlled by the label switching control component.
a packet traversing such an interface is received, it is treated as
labeled packet. The packet's top label is inferred either from
contents of the VCI field or the combined contents of the VPI and
fields. Any two LDP peers which are connected via an LC-
interface will use LDP negotiations to determine which of these
is applicable to that interface

An ATM-LSR is a LSR with a number of LC-ATM interfaces which
cells between these interfaces, using labels carried in the VCI
VPI/VCI field, without reassembling the cells into frames
forwarding

Davie Standards Track [Page 3]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

A frame-based LSR is a LSR which forwards complete frames between
interfaces. Note that such a LSR may have zero, one or more LC-
interfaces

Sometimes a single box may behave as an ATM-LSR with respect
certain pairs of interfaces, but may behave as a frame-based LSR
respect to other pairs. For example, an ATM switch with an
interface may function as an ATM-LSR when forwarding cells
its LC-ATM interfaces, but may function as a frame-based LSR
forwarding frames from its ethernet to one of its LC-ATM interfaces
In such cases, one can consider the two functions (ATM-LSR
frame-based LSR) as being coresident in a single box

It is intended that an LC-ATM interface be used to connect two ATM
LSRs, or to connect an ATM-LSR to a frame-based LSR. The use of
LC-ATM interface to connect two frame-based LSRs is not considered
this document

An ATM-LSR domain is a set of ATM-LSRs which are
interconnected by LC-ATM interfaces

The Edge Set of an ATM-LSR domain is the set of frame-based
which are connected to members of the domain by LC-ATM interfaces.
frame-based LSR which is a member of an Edge Set of an ATM-LSR
may be called an Edge LSR

VC-merge is the process by which a switch receives cells on
incoming VCIs and transmits them on a single outgoing VCI
causing the cells of different AAL5 PDUs to become interleaved

4. Special Characteristics of ATM

While the MPLS architecture permits considerable flexibility in
implementation, an ATM-LSR is constrained by the capabilities of
(possibly pre-existing) hardware and the restrictions on such
as cell format imposed by ATM standards. Because of
constraints, some special procedures are required for ATM-LSRs

Some of the key features of ATM switches that affect their
as LSRs are

- the label swapping function is performed on fields (the
and/or VPI) in the cell header; this dictates the size
placement of the label(s) in a packet

- multipoint-to-point and multipoint-to-multipoint VCs
generally not supported. This means that most switches
support 'VC-merge' as defined above

Davie Standards Track [Page 4]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

- there is generally no capability to perform a 'TTL-decrement
function as is performed on IP headers in routers

This document describes ways of applying label switching to
switches which work within these constraints

5. Label Switching Control Component for

To support label switching an ATM switch MUST implement the
component of label switching. This consists primarily of
allocation, distribution, and maintenance procedures. Label
information is communicated by several mechanisms, notably the
Distribution Protocol (LDP) [2]. This document imposes
requirements on the LDP

This document considers only the case where the label
control component uses information learned directly from
layer routing protocols. It is presupposed that the
participates as a peer in these protocols (e.g., OSPF, IS-IS).

In some cases, LSRs make use of other protocols (e.g., RSVP, PIM
BGP) to distribute label bindings. In these cases, an ATM-LSR
need to participate in these protocols. However, these are
explicitly considered in this document

Support of label switching on an ATM switch does NOT require
switch to support the ATM control component defined by the ITU
ATM Forum (e.g., UNI, PNNI). An ATM-LSR may OPTIONALLY respond
OAM cells

6. Hybrid Switches (Ships in the Night

The existence of the label switching control component on an
switch does not preclude the ability to support the ATM
component defined by the ITU and ATM Forum on the same switch and
same interfaces. The two control components, label switching and
ITU/ATM Forum defined, would operate independently

Definition of how such a device operates is beyond the scope of
document. However, only a small amount of information needs to
consistent between the two control components, such as the
of the VPI/VCI space which are available to each component

7. Use of VPI/

Label switching is accomplished by associating labels with
Equivalence Classes, and using the label value to forward packets
including determining the value of any replacement label. See [1]

Davie Standards Track [Page 5]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

for further details. In an ATM-LSR, the label is carried in
VPI/VCI field, or, when two ATM-LSRs are connected via an
"Virtual Path", in the VCI field

Labeled packets MUST be transmitted using the null encapsulation,
defined in Section 6.1 of RFC 2684 [5].

In addition, if two LDP peers are connected via an LC-ATM interface
a non-MPLS connection, capable of carrying unlabelled IP packets
MUST be available. This non-MPLS connection is used to carry
packets between the two peers, and MAY also be used (but is
required to be used) for other unlabeled packets (such as
packets, etc.). The LLC/SNAP encapsulation of RFC 2684 [5] MUST
used on the non-MPLS connection

It SHOULD be possible to configure an LC-ATM interface
additional VPI/VCIs that are used to carry control information
non-labelled packets. In that case, the VCI values MUST NOT be
the 0-32 range. These may use either the null encapsulation,
defined in Section 6.1 of RFC 2684 [5], or the LLC/
encapsulation, as defined in Section 5.1 of RFC 2684 [5].

7.1. Direct

We say that two LSRs are "directly connected" over an LC-
interface if all cells transmitted out that interface by one LSR
reach the other, and there are no ATM switches between the two LSRs

When two LSRs are directly connected via an LC-ATM interface,
jointly control the allocation of VPIs/VCIs on the
connecting them. They may agree to use the VPI/VCI field to encode
single label

The default VPI/VCI value for the non-MPLS connection is VPI 0,
32. Other values can be configured, as long as both parties
aware of the configured value

A VPI/VCI value whose VCI part is in the range 0-32 inclusive
NOT be used as the encoding of a label

With the exception of these reserved values, the VPI/VCI values
in the two directions of the link MAY be treated as
spaces

The allowable ranges of VCIs are communicated through LDP

Davie Standards Track [Page 6]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

7.2. Connections via an ATM

Sometimes it can be useful to treat two LSRs as adjacent (in
LSP) across an LC-ATM interface, even though the connection
them is made through an ATM "cloud" via an ATM Virtual Path. In
case, the VPI field is not available to MPLS, and the label MUST
encoded entirely within the VCI field

In this case, the default VCI value of the non-MPLS
between the LSRs is 32. Other values can be configured, as long
both parties are aware of the configured value. The VPI is set
whatever is required to make use of the Virtual Path

A VPI/VCI value whose VCI part is in the range 0-32 inclusive
NOT be used as the encoding of a label

With the exception of these reserved values, the VPI/VCI values
in the two directions of the link MAY be treated as
spaces

The allowable ranges of VPI/VCIs are communicated through LDP.
more than one VPI is used for label switching, the allowable range
VCIs may be different for each VPI, and each range is
through LDP

7.3. Connections via an ATM

Sometimes it may be useful to treat two LSRs as adjacent (in
LSP) across an LC-ATM interface, even though the connection
them is made through an ATM "cloud" via a set of ATM Switched
Circuits

The current document does not specify the procedure for handling
case. Such procedures can be found in [4]. The procedures
in [4] allow a VCID to be assigned to each such VC, and specify
LDP can be used used to bind a VCID to a FEC. The top label of
received packet would then be inferred (via a one-to-one mapping
from the virtual circuit on which the packet arrived. There
not be a default VPI or VCI value for the non-MPLS connection

8. Label Distribution and Maintenance

This document discusses the use of "downstream-on-demand"
distribution (see [1]) by ATM-LSRs. These label
procedures MUST be used by ATM-LSRs that do not support VC-merge,
MAY also be used by ATM-LSRs that do support VC-merge.
procedures differ somewhat in the two cases, however. We
describe the two scenarios in turn. We begin by describing

Davie Standards Track [Page 7]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

behavior of members of the Edge Set of an ATM-LSR domain; these "
LSRs" are not themselves ATM-LSRs, and their behavior is the
whether the domain contains VC-merge capable LSRs or not

8.1. Edge LSR

Consider a member of the Edge Set of an ATM-LSR domain. Assume that
as a result of its routing calculations, it selects an ATM-LSR as
next hop of a certain FEC, and that the next hop is reachable via
LC-ATM interface. The Edge LSR uses LDP to request a label
for that FEC from the next hop. The hop count field in the
is set to 1 (but see the next paragraph). Once the Edge LSR
the label binding information, it may use MPLS forwarding
to transmit packets in the specified FEC, using the specified
as an outgoing label. (Or using the VPI/VCI that corresponds to
specified VCID as the outgoing label, if the VCID technique of [4]
being used.)

Note: if the Edge LSR's previous hop is using downstream-on-
label distribution to request a label from the Edge LSR for
particular FEC, and if the Edge LSR is not merging the LSP from
previous hop with any other LSP, and if the request from the
hop has a hop count of h, then the hop count in the request issued
the Edge LSR should not be set to 1, but rather to h+1.

The binding received by the edge LSR may contain a hop count,
represents the number of hops a packet will take to cross the ATM-
domain when using this label. If there is a hop count
with the binding, the ATM-LSR SHOULD adjust a data packet's TTL
this amount before transmitting the packet. In any event, it
adjust a data packet's TTL by at least one before transmitting it
The procedures for doing so (in the case of IP packets) are
in section 10. The procedures for encapsulating the packets
specified in section 9.

When a member of the Edge Set of the ATM-LSR domain receives a
binding request from an ATM-LSR, it allocates a label, and
(via LDP) a binding containing the allocated label back to the
that originated the request. It sets the hop count in the binding
1.

When a routing calculation causes an Edge LSR to change the next
for a particular FEC, and the former next hop was in the ATM-
domain, the Edge LSR SHOULD notify the former next hop (via LDP)
the label binding associated with the FEC is no longer needed

Davie Standards Track [Page 8]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

8.2. Conventional ATM Switches (non-VC-merge

When an ATM-LSR receives (via LDP) a label binding request for
certain FEC from a peer connected to the ATM-LSR over a LC-
interface, the ATM-LSR takes the following actions

- it allocates a label

- it requests (via LDP) a label binding from the next hop
that FEC

- it returns (via LDP) a binding containing the
incoming label back to the peer that originated the request

For purposes of this procedure, we define a maximum hop count
MAXHOP. MAXHOP has a default value of 255, but may be configured
a different value

The hop count field in the request that the ATM-LSR sends (to
next hop LSR) MUST be set to one more than the hop count field in
request that it received from the upstream LSR. If the resulting
count exceeds MAXHOP, the request MUST NOT be sent to the next hop
and the ATM-LSR MUST notify the upstream neighbor that its
request cannot be satisfied

Otherwise, once the ATM-LSR receives the binding from the next hop
it begins using that label

The ATM-LSR MAY choose to wait for the request to be satisfied
downstream before returning the binding upstream. This is a form
"ordered control" (as defined in [1] and [2]), in
"ingress-initiated ordered control". In this case, as long as
ATM-LSR receives from downstream a hop count which is greater than 0
and less than MAXHOP, it MUST increment the hop count it
from downstream and MUST include the result in the binding it
upstream. However, if the hop count exceeds MAXHOP, a label
MUST NOT be passed upstream. Rather, the upstream LDP peer MUST
informed that the requested label binding cannot be satisfied.
the hop count received from downstream is 0, the hop count
upstream should also be 0; this indicates that the actual hop
is unknown

Alternatively, the ATM-LSR MAY return the binding upstream
waiting for a binding from downstream ("independent" control,
defined in [1] and [2]). In this case, it specifies a hop count of 0
in the binding, indicating that the true hop count is unknown.
correct value for hop count will be returned later, as
below

Davie Standards Track [Page 9]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

Note that an ATM-LSR, or a member of the edge set of an ATM-
domain, may receive multiple binding requests for the same FEC
the same ATM-LSR. It MUST generate a new binding for each
(assuming adequate resources to do so), and retain any
binding(s). For each request received, an ATM-LSR MUST also
a new binding request toward the next hop for the FEC

When a routing calculation causes an ATM-LSR to change the next
for a FEC, the ATM-LSR MUST notify the former next hop (via LDP)
the label binding associated with the FEC is no longer needed

When a LSR receives a notification that a particular label binding
no longer needed, the LSR MAY deallocate the label associated
the binding, and destroy the binding. In the case where an ATM-
receives such notification and destroys the binding, it MUST
the next hop for the FEC that the label binding is no longer needed
If a LSR does not destroy the binding, it may re-use the binding
if it receives a request for the same FEC with the same hop count
the request that originally caused the binding to be created

When a route changes, the label bindings are re-established from
point where the route diverges from the previous route.
upstream of that point are (with one exception, noted below
oblivious to the change

Whenever a LSR changes its next hop for a particular FEC, if the
next hop is reachable via an LC-ATM interface, then for each
that it has bound to that FEC, and distributed upstream, it
request a new label binding from the new next hop

When an ATM-LSR receives a label binding for a particular FEC from
downstream neighbor, it may already have provided a
label binding for this FEC to an upstream neighbor, either because
is using independent control, or because the new binding
downstream is the result of a routing change. In this case,
the hop count is 0, it MUST extract the hop count from the
binding and increment it by one. If the new hop count is
from that which was previously conveyed to the upstream
(including the case where the upstream neighbor was given the
'unknown') the ATM-LSR MUST notify the upstream neighbor of
change. Each ATM-LSR in turn MUST increment the hop count and
it upstream until it reaches the ingress Edge LSR. If at any
the value of the hop count equals MAXHOP, the ATM-LSR SHOULD
the binding from the upstream neighbor. A hop count of 0 MUST
passed upstream unchanged

Davie Standards Track [Page 10]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

Whenever an ATM-LSR originates a label binding request to its
hop LSR as a result of receiving a label binding request from
(upstream) LSR, and the request to the next hop LSR is not satisfied
the ATM-LSR SHOULD destroy the binding created in response to
received request, and notify the requester (via LDP).

If an ATM-LSR receives a binding request containing a hop count
exceeds MAXHOP, it MUST not establish a binding, and it MUST
an error to the requester

When a LSR determines that it has lost its LDP session with
LSR, the following actions are taken. Any binding
learned via this connection MUST be discarded. For any
bindings that were created as a result of receiving label
requests from the peer, the LSR MAY destroy these bindings (
deallocate labels associated with these binding).

An ATM-LSR SHOULD use 'split-horizon' when it satisfies
requests from its neighbors. That is, if it receives a request for
binding to a particular FEC and the LSR making that request is
according to this ATM-LSR, the next hop for that FEC, it should
return a binding for that route

It is expected that non-merging ATM-LSRs would generally
"conservative label retention mode" [1].

8.3. VC-merge-capable ATM

Relatively minor changes are needed to accommodate ATM-LSRs
support VC-merge. The primary difference is that a VC-merge-
ATM-LSR needs only one outgoing label per FEC, even if
requests for label bindings to that FEC are received from
neighbors

When a VC-merge-capable ATM-LSR receives a binding request from
upstream LSR for a certain FEC, and it does not already have
outgoing label binding for that FEC (or an outstanding request
such a label binding), it MUST issue a bind request to its next
just as it would do if it were not merge-capable. If, however,
already has an outgoing label binding for that FEC, it does not
to issue a downstream binding request. Instead, it may
allocate an incoming label, and return that label in a binding to
upstream requester. When packets with that label as top label
received from the requester, the top label value will be
with the existing outgoing label value that corresponds to the
FEC

Davie Standards Track [Page 11]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

If the ATM-LSR does not have an outgoing label binding for the FEC
but does have an outstanding request for one, it need not
another request

When sending a label binding upstream, the hop count associated
the corresponding binding from downstream MUST be incremented by 1,
and the result transmitted upstream as the hop count associated
the new binding. However, there are two exceptions: a hop count of 0
MUST be passed upstream unchanged, and if the hop count is already
MAXHOP, the ATM-LSR MUST NOT pass a binding upstream, but
MUST send an error upstream

Note that, just like conventional ATM-LSRs and members of the
set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue
new binding every time it receives a request from upstream,
there may be switches upstream which do not support VC-merge
However, it only needs to issue a corresponding binding
downstream if it does not already have a label binding for
appropriate route

When a change in the routing table of a VC-merge-capable ATM-
causes it to select a new next hop for one of its FECs, it
optionally release the binding for that route from the former
hop. If it doesn't already have a corresponding binding for the
next hop, it must request one. (The choice between conservative
liberal label retention mode [1] is an implementation option.)

If a new binding is obtained, which contains a hop count that
from that which was received in the old binding, then the ATM-
must take the new hop count, increment it by one, and notify
upstream neighbors who have label bindings for this FEC of the
value. Just as with conventional ATM-LSRs, this enables the new
count to propagate back towards the ingress of the ATM-LSR domain
If at any point the hop count exceeds MAXHOP, then the label
for this route must be withdrawn from all upstream neighbors to
a binding was previously provided. This ensures that any
caused by routing transients will be detected and broken

9.

The procedures described in this section affect only the Edge LSRs
the ATM-LSR domain. The ATM-LSRs themselves do not modify
encapsulation in any way

Labeled packets MUST be transmitted using the null encapsulation
Section 6.1 of RFC 2684 [5].

Davie Standards Track [Page 12]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

Except in certain circumstances specified below, when a
packet is transmitted on an LC-ATM interface, where the VPI/VCI (
VCID) is interpreted as the top label in the label stack, the
MUST also contain a "shim header" [3].

If the packet has a label stack with n entries, it MUST carry a
with n entries. The actual value of the top label is encoded in
VPI/VCI field. The label value of the top entry in the shim (
is just a "placeholder" entry) MUST be set to 0 upon transmission
and MUST be ignored upon reception. The packet's outgoing TTL,
its CoS, are carried in the TTL and CoS fields respectively of
top stack entry in the shim

Note that if a packet has a label stack with only one entry,
requires it to have a single-entry shim (4 bytes), even though
actual label value is encoded into the VPI/VCI field. This is
to ensure that the packet always has a shim. Otherwise, there
be no way to determine whether it had one or not, i.e., no way
determine whether there are additional label stack entries

The only ways to eliminate this extra overhead are

- through apriori knowledge that packets have only a single
(e.g., perhaps the network only supports one level of label

- by using two VCs per FEC, one for those packets which have
a single label, and one for those packets which have more
one

The second technique would require that there be some way
signalling via LDP that the VC is carrying only packets with a
label, and is not carrying a shim. When supporting VC merge,
would also have to take care not to merge a VC on which the shim
not used into a VC on which it is used, or vice versa

While either of these techniques is permitted, it is doubtful
they have any practical utility. Note that if the shim header is
present, the outgoing TTL is carried in the TTL field of the
layer header

10. TTL

The procedures described in this section affect only the Edge LSRs
the ATM-LSR domain. The ATM-LSRs themselves do not modify the TTL
any way

Davie Standards Track [Page 13]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

The details of the TTL adjustment procedure are as follows. If
packet was received by the Edge LSR as an unlabeled packet,
"incoming TTL" comes from the IP header. (Procedures for
network layer protocols are for further study.) If a packet
received by the Edge LSR as a labeled packet, using the
specified in [3], the "incoming TTL" comes from the entry at the
of the label stack

If a hop count has been associated with the label binding that
used when the packet is forwarded, the "outgoing TTL" is set to
larger of (a) 0 or (b) the difference between the incoming TTL
the hop count. If a hop count has not been associated with the
binding that is used when the packet is forwarded, the "outgoing TTL
is set to the larger of (a) 0 or (b) one less than the incoming TTL

If this causes the outgoing TTL to become zero, the packet MUST
be transmitted as a labeled packet using the specified label.
packet can be treated in one of two ways

- it may be treated as having expired; this may cause an
message to be transmitted

- the packet may be forwarded, as an unlabeled packet, with a
that is 1 less than the incoming TTL; such forwarding
need to be done over a non-MPLS connection

Of course, if the incoming TTL is 1, only the first of these
options is applicable

If the packet is forwarded as a labeled packet, the outgoing TTL
carried as specified in section 9.

When an Edge LSR receives a labeled packet over an LC-ATM interface
it obtains the incoming TTL from the top label stack entry of
generic encapsulation, or, if that encapsulation is not present,
the IP header

If the packet's next hop is an ATM-LSR, the outgoing TTL is
using the procedures described in this section. Otherwise
outgoing TTL is formed using the procedures described in [3].

The procedures in this section are intended to apply only to
packets

Davie Standards Track [Page 14]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

11. Optional Loop Detection: Distributing Path

Every ATM-LSR MUST implement, as a configurable option, the
procedure for detecting forwarding loops. We refer to this as
LDPV (Loop Detection via Path Vectors) procedure. This
does not prevent the formation of forwarding loops, but does
that any such loops are detected. If this option is not enabled
loops are detected by the hop count mechanism previously described
If this option is enabled, loops will be detected more quickly,
at a higher cost in overhead

11.1. When to Send Path Vectors

Suppose an LSR R sends a request for a label binding, for
particular LSP, to its next hop. Then if R does not support VC
merging, and R is configured to use the LDPV procedure

- If R is sending the request because it is an ingress node
that LSP, or because it has acquired a new next hop, then
MUST include a path vector object with the request, and
path vector object MUST contain only R's own address

- If R is sending the request as a result of having received
request from an upstream LSR, then

* if the received request has a path vector object, R MUST
its own address to the received path vector object, and
pass the resulting path vector object to its next hop
with the label binding request

* if the received request does not have a path vector object
R MUST include a path vector object with the request
sends, and the path vector object MUST contain only R's
address

An LSR which supports VC-merge SHOULD NOT include a path
object in the requests that it sends to its next hop

If an LSR receives a label binding request whose path vector
contains the address of the node itself, the LSR concludes that
label binding requests have traveled in a loop. The LSR MUST act
it would in the case where the hop count exceeds MAXHOP (see
8.2).

This procedure detects the case where the request messages
though a sequence of non-merging ATM-LSRs

Davie Standards Track [Page 15]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

11.2. When to Send Path Vectors

As specified in section 8, there are circumstances in which an LSR
must inform its upstream neighbors, via a label binding
message, of a change in hop count for a particular LSP. If
following conditions all hold

- R is configured for the LDPV procedure

- R supports VC-merge

- R is not the egress for that LSP,

- R is not informing its neighbors of a decrease in the
count

then R MUST include a path vector object in the response message

If the change in hop count is a result of R's having been informed
its next hop, S, of a change in hop count, and the message from S
R included a path vector object, then if the above conditions hold,
MUST add itself to this object and pass the result upstream
Otherwise, if the above conditions hold, R MUST create a new
with only its own address

If R is configured for the LDPV procedure, and R supports VC merge
then it MAY include a path vector object in any label
response message that it sends upstream. In particular, at any
that R receives a label binding response from its next hop, if
response contains a path vector, R MAY (if configured for the
procedure) send a response to its upstream neighbors, containing
path vector object formed by adding its own address to the
path vector

If R does not support VC merge, it SHOULD NOT send a path
object upstream

If an LSR receives a message from its next hop, with a path
object containing its own address, then LSR MUST act as it would
it received a message with a hop count equal to MAXHOP

LSRs which are configured for the LDPV procedure SHOULD NOT store
path vector once the corresponding path vector object has
transmitted

Davie Standards Track [Page 16]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

Note that if the ATM-LSR domain consists entirely of non-
ATM-LSRs, path vectors need not ever be sent upstream, since
loops will be detected by means of the path vectors
downstream

By not sending path vectors unless the hop count increases,
avoids sending them in many situations when there is no loop.
cost is that in some situations in which there is a loop, the time
detect the loop may be lengthened

12. Security

The encapsulation and procedures specified in this document do
interfere in any way with the application of authentication and/
encryption to network layer packets (such as the application of
to IP datagrams).

The procedures described in this document do not protect against
alteration (either accidental or malicious) of MPLS labels.
alteration could cause misforwarding

The procedures described in this document do not enable a
LSR to authenticate the transmitting LSR

A discussion of the security considerations applicable to the
distribution mechanism can be found in [2].

13. Intellectual Property

The IETF has been notified of intellectual property rights claimed
regard to some or all of the specification contained in
document. For more information consult the online list of
rights

The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementors or users of this specification
be obtained from the IETF Secretariat

Davie Standards Track [Page 17]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director

14.

[1] Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol
Switching Architecture", RFC 3031, January 2001.

[2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas
"LDP Specification", RFC 3036, January 2001.

[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G.,
Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
January 2001.

[4] Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID
over ATM Link for LDP", RFC 3038, January 2001.

[5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over
Adaptation Layer 5", RFC 2684, September 1999.

15.

Significant contributions to this work have been made by
Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin,
Littlewood and Dan Tappan. We thank Alex Conta for his comments

16. Authors'

Bruce
Cisco Systems, Inc
250 Apollo
Chelmsford, MA, 01824

EMail: bsd@cisco.

Paul
Ennovate Networks Inc
60 Codman Hill
Boxborough, MA 01719

EMail: pdoolan@ennovatenetworks.

Davie Standards Track [Page 18]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

Jeremy
Cisco Systems, Inc
99 Walker St
North Sydney, NSW,

EMail: jlawrenc@cisco.

Keith
Cisco Systems, Inc
170 Tasman
San Jose, CA, 95134

EMail: kzm@cisco.

Yakov
Juniper
1194 N. Mathilda
Sunnyvale, CA 94089

EMail: yakov@juniper.

Eric
Cisco Systems, Inc
250 Apollo
Chelmsford, MA, 01824

EMail: erosen@cisco.

George
Cisco Systems, Inc
250 Apollo
Chelmsford, MA, 01824

EMail: swallow@cisco.

Davie Standards Track [Page 19]

RFC 3035 MPLS using LDP and ATM VC Switching January 2001

17. Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Davie Standards Track [Page 20]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX