draft-ietf-mpls-atm-00.txt   draft-ietf-mpls-atm-01.txt 
Network Working Group Bruce Davie Network Working Group Bruce Davie
Internet Draft Jeremy Lawrence Internet Draft Jeremy Lawrence
Expiration Date: March 1999 Keith McCloghrie Expiration Date: May 1999 Keith McCloghrie
Yakov Rekhter Yakov Rekhter
Eric Rosen Eric Rosen
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
Paul Doolan Paul Doolan
Ennovate Networks, Inc. Ennovate Networks, Inc.
September 1998 November 1998
Use of Label Switching With ATM MPLS using ATM VC Switching
draft-ietf-mpls-atm-00.txt draft-ietf-mpls-atm-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Contents Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 3
2 Specification of Requirements .......................... 4 2 Specification of Requirements .......................... 4
3 Definitions ............................................ 4 3 Definitions ............................................ 4
4 Special Characteristics of ATM Switches ................ 5 4 Special Characteristics of ATM Switches ................ 5
5 Label Switching Control Component for ATM .............. 5 5 Label Switching Control Component for ATM .............. 5
6 Hybrid Switches (Ships in the Night) ................... 6 6 Hybrid Switches (Ships in the Night) ................... 6
7 Use of VPI/VCIs ....................................... 6 7 Use of VPI/VCIs ....................................... 6
7.1 Direct Connections ..................................... 6 7.1 Direct Connections ..................................... 7
7.2 Connections via an ATM VP .............................. 7 7.2 Connections via an ATM VP .............................. 7
7.3 Connections via an ATM SVC ............................. 8 7.3 Connections via an ATM SVC ............................. 8
8 Label Distribution and Maintenance Procedures .......... 8 8 Label Distribution and Maintenance Procedures .......... 8
8.1 Edge LSR Behavior ...................................... 8 8.1 Edge LSR Behavior ...................................... 8
8.2 Conventional ATM Switches (non-VC-merge) ............... 9 8.2 Conventional ATM Switches (non-VC-merge) ............... 9
8.3 VC-merge-capable ATM Switches .......................... 11 8.3 VC-merge-capable ATM Switches .......................... 12
9 Encapsulation .......................................... 13 9 Encapsulation .......................................... 13
10 TTL Manipulation ....................................... 14 10 TTL Manipulation ....................................... 14
11 Security Considerations ................................ 15 11 Optional Loop Detection: Distributing Path Vectors ..... 15
12 Intellectual Property Considerations ................... 15 11.1 When to Send Path Vectors Downstream ................... 15
13 References ............................................. 15 11.2 When to Send Path Vectors Upstream ..................... 16
14 Acknowledgments ........................................ 16 12 Security Considerations ................................ 17
15 Authors' Addresses ..................................... 16 13 Intellectual Property Considerations ................... 17
14 References ............................................. 18
15 Acknowledgments ........................................ 18
16 Authors' Addresses ..................................... 18
1. Introduction 1. Introduction
The MPLS Architecture [1] discusses the way in which ATM switches may The MPLS Architecture [1] discusses the way in which ATM switches may
be used as Label Switching Routers. The ATM switches run network be used as Label Switching Routers. The ATM switches run network
layer routing algorithms (such as OSPF, IS-IS, etc.), and their data layer routing algorithms (such as OSPF, IS-IS, etc.), and their data
forwarding is based on the results of these routing algorithms. No forwarding is based on the results of these routing algorithms. No
ATM-specific routing or addressing is needed. ATM switches used in ATM-specific routing or addressing is needed. ATM switches used in
this way are known as ATM-LSRs. this way are known as ATM-LSRs.
skipping to change at page 3, line 32 skipping to change at page 3, line 32
of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs
that are capable of VC merge. that are capable of VC merge.
This document does NOT specify the label distribution techniques to This document does NOT specify the label distribution techniques to
be used in the following cases: be used in the following cases:
- the routes are explicitly chosen before label distribution - the routes are explicitly chosen before label distribution
begins, instead of being chosen on a hop-by-hop basis as label begins, instead of being chosen on a hop-by-hop basis as label
distribution proceeds, distribution proceeds,
- the routes are intended to diverge in any way from the routes
chosen by the conventional hop-by-hop routing at any time,
- the labels represent FECs that consist of multicast packets, - the labels represent FECs that consist of multicast packets,
- the LSRs use "VP merge". - the LSRs use "VP merge".
Further statements made in this document about ATM-LSR label Further statements made in this document about ATM-LSR label
distribution do not necessarily apply in these cases. distribution do not necessarily apply in these cases.
This document also specifies the MPLS encapsulation to be used when This document also specifies the MPLS encapsulation to be used when
sending labeled packets to or from ATM-LSRs, and in that respect is a sending labeled packets to or from ATM-LSRs, and in that respect is a
companion document to [3]. The specified encapsulation is to be used companion document to [3]. The specified encapsulation is to be used
skipping to change at page 4, line 33 skipping to change at page 4, line 33
is applicable to that interface. is applicable to that interface.
An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards
cells between these interfaces using labels carried in the VCI or cells between these interfaces using labels carried in the VCI or
VPI/VCI field. VPI/VCI field.
A frame-based LSR is a LSR which forwards complete frames between its A frame-based LSR is a LSR which forwards complete frames between its
interfaces. Note that such a LSR may have zero, one or more LC-ATM interfaces. Note that such a LSR may have zero, one or more LC-ATM
interfaces. interfaces.
In general, an LC-ATM interface will be used either to connect two Sometimes a single box may behave as an ATM-LSR with respect to
ATM-LSRs, or to connect an ATM-LSR to a frame-based LSR. certain pairs of interfaces, but may behave as a frame-based LSR with
respect to other pairs. For example, an ATM switch with an ethernet
interface may function as an ATM-LSR when forwarding cells between
its LC-ATM interfaces, but may function as a frame-based LSR when
forwarding frames from its ethernet to one of its LC-ATM interfaces.
In such cases, one can consider the two functions (ATM-LSR and
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 an
LC-ATM interface to connect two frame-based LSRs is not considered in
this document.
An ATM-LSR domain is a set of ATM-LSRs which are mutually An ATM-LSR domain is a set of ATM-LSRs which are mutually
interconnected by LC-ATM interfaces. interconnected by LC-ATM interfaces.
The Edge Set of an ATM-LSR domain is the set of frame-based LSRs The Edge Set of an ATM-LSR domain is the set of frame-based LSRs
which are connected to members of the domain by LC-ATM interfaces. A which are connected to members of the domain by LC-ATM interfaces. A
frame-based LSR which is a member of an Edge Set of an ATM-LSR domain frame-based LSR which is a member of an Edge Set of an ATM-LSR domain
may be called an Edge LSR. may be called an Edge LSR.
VC-merge is the process by which a switch receives cells on several VC-merge is the process by which a switch receives cells on several
skipping to change at page 5, line 22 skipping to change at page 5, line 28
Some of the key features of ATM switches that affect their behavior Some of the key features of ATM switches that affect their behavior
as LSRs are: as LSRs are:
- the label swapping function is performed on fields (the VCI - the label swapping function is performed on fields (the VCI
and/or VPI) in the cell header; this dictates the size and and/or VPI) in the cell header; this dictates the size and
placement of the label(s) in a packet. placement of the label(s) in a packet.
- multipoint-to-point and multipoint-to-multipoint VCs are - multipoint-to-point and multipoint-to-multipoint VCs are
generally not supported. This means that most switches cannot generally not supported. This means that most switches cannot
support `VC-merge' as defined above. support 'VC-merge' as defined above.
- there is generally no capability to perform a `TTL-decrement' - there is generally no capability to perform a 'TTL-decrement'
function as is performed on IP headers in routers. function as is performed on IP headers in routers.
This document describes ways of applying label switching to ATM This document describes ways of applying label switching to ATM
switches which work within these constraints. switches which work within these constraints.
5. Label Switching Control Component for ATM 5. Label Switching Control Component for ATM
To support label switching an ATM switch MUST implement the control To support label switching an ATM switch MUST implement the control
component of label switching. This consists primarily of label component of label switching. This consists primarily of label
allocation, distribution, and maintenance procedures. Label binding allocation, distribution, and maintenance procedures. Label binding
skipping to change at page 6, line 34 skipping to change at page 6, line 43
for further details. In an ATM-LSR, the label is carried in the for further details. In an ATM-LSR, the label is carried in the
VPI/VCI field, or, when two ATM-LSRs are connected via an ATM VPI/VCI field, or, when two ATM-LSRs are connected via an ATM
"Virtual Path", in the VCI field. In addition, if two LDP peers are "Virtual Path", in the VCI field. In addition, if two LDP peers are
connected via an LC-ATM interface, a non-MPLS connection, capable of connected via an LC-ATM interface, a non-MPLS connection, capable of
carrying unlabelled IP packets, MUST be available. This non-MPLS carrying unlabelled IP packets, MUST be available. This non-MPLS
connection is used to carry LDP packets between the two peers, and connection is used to carry LDP packets between the two peers, and
MAY also be used (but is not required to be used) for other unlabeled MAY also be used (but is not required to be used) for other unlabeled
packets (such as OSPF packets, etc.). The LLC/SNAP encapsulation of packets (such as OSPF packets, etc.). The LLC/SNAP encapsulation of
RFC 1483 [5] MUST be used on the non-MPLS connection. RFC 1483 [5] MUST be used on the non-MPLS connection.
LDP MAY be used to advertise additional VPI/VCIs to carry control It SHOULD be possible to configure an LC-ATM interface with
information or non-labelled packets. These may use either the null additional VPI/VCIs that are used to carry control information or
encapsulation, as defined in Section 5.1 of RFC 1483 [5], or the non-labelled packets. In that case, the VCI values MUST be in the
LLC/SNAP encapsulation, as defined in Section 4.1 of RFC 1483 [5]. 0-32 range. These may use either the null encapsulation, as defined
in Section 5.1 of RFC 1483 [5], or the LLC/SNAP encapsulation, as
defined in Section 4.1 of RFC 1483 [5].
7.1. Direct Connections 7.1. Direct Connections
We say that two LSRs are "directly connected" over an LC-ATM We say that two LSRs are "directly connected" over an LC-ATM
interface if all cells transmitted out that interface by one LSR will interface if all cells transmitted out that interface by one LSR will
reach the other, and there are no ATM switches between the two LSRs. reach the other, and there are no ATM switches between the two LSRs.
When two LSRs are directly connected via an LC-ATM interface, they When two LSRs are directly connected via an LC-ATM interface, they
jointly control the allocation of VPIs/VCIs on the interface jointly control the allocation of VPIs/VCIs on the interface
connecting them. They may agree to use the VPI/VCI field to encode a connecting them. They may agree to use the VPI/VCI field to encode a
skipping to change at page 9, line 32 skipping to change at page 9, line 32
interface, the ATM-LSR takes the following actions: interface, the ATM-LSR takes the following actions:
- it allocates a label, - it allocates a label,
- it requests (via LDP) a label binding from the next hop for that - it requests (via LDP) a label binding from the next hop for that
FEC; FEC;
- it returns (via LDP) a binding containing the allocated incoming - it returns (via LDP) a binding containing the allocated incoming
label back to the peer that originated the request. label back to the peer that originated the request.
For purposes of this procedure, we define a maximum hop count value
MAXHOP. MAXHOP has a default value of 255, but may be configured to
a different value.
The hop count field in the request that the ATM-LSR sends (to the The hop count field in the request that the ATM-LSR sends (to the
next hop LSR) MUST be set to one more than the hop count field in the next hop LSR) MUST be set to one more than the hop count field in the
request that it received from the upstream LSR. If the resulting hop request that it received from the upstream LSR. If the resulting hop
count exceeds a configured maximum value, the request MUST NOT be count exceeds MAXHOP, the request MUST NOT be sent to the next hop,
sent to the next hop, and the ATM-LSR MUST notify the upstream and the ATM-LSR MUST notify the upstream neighbor that its binding
neighbor that its binding request cannot be satisfied. request cannot be satisfied.
Otherwise, once the ATM-LSR receives the binding from the next hop, Otherwise, once the ATM-LSR receives the binding from the next hop,
it begins using that label. it begins using that label.
The ATM-LSR MAY choose to wait for the request to be satisfied from The ATM-LSR MAY choose to wait for the request to be satisfied from
downstream before returning the binding upstream. This is a form of downstream before returning the binding upstream. This is a form of
"ordered control" (as defined in [1] and [2]), in particular "ordered control" (as defined in [1] and [2]), in particular
"ingress-initiated ordered control". In this case, as long as the "ingress-initiated ordered control". In this case, as long as the
ATM-LSR receives from downstream a hop count which is greater than 0 ATM-LSR receives from downstream a hop count which is greater than 0
and less than a configured maximum value, it MUST increment the hop and less than MAXHOP, it MUST increment the hop count it receives
count it receives from downstream and MUST include the result in the from downstream and MUST include the result in the binding it returns
binding it returns upstream. However, if the hop count exceeds a upstream. However, if the hop count exceeds MAXHOP, a label binding
configured maximum value, a label binding MUST NOT be passed MUST NOT be passed upstream. Rather, the upstream LDP peer MUST be
upstream. Rather, the upstream LDP peer MUST be informed that the informed that the requested label binding cannot be satisfied. If
requested label binding cannot be satisfied. If the hop count the hop count received from downstream is 0, the hop count passed
received from downstream is 0, the hop count passed upstream should upstream should also be 0; this indicates that the actual hop count
also be 0; this indicates that the actual hop count is unknown. is unknown.
Alternatively, the ATM-LSR MAY return the binding upstream without Alternatively, the ATM-LSR MAY return the binding upstream without
waiting for a binding from downstream ("independent" control, as waiting for a binding from downstream ("independent" control, as
defined in [1] and [2]). In this case, it specifies a hop count of 0 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. The in the binding, indicating that the true hop count is unknown. The
correct value for hop count will be returned later, as described correct value for hop count will be returned later, as described
below. below.
Note that an ATM-LSR, or a member of the edge set of an ATM-LSR Note that an ATM-LSR, or a member of the edge set of an ATM-LSR
domain, may receive multiple binding requests for the same FEC from domain, may receive multiple binding requests for the same FEC from
skipping to change at page 11, line 7 skipping to change at page 11, line 11
When an ATM-LSR receives a label binding for a particular FEC from a When an ATM-LSR receives a label binding for a particular FEC from a
downstream neighbor, it may already have provided a corresponding downstream neighbor, it may already have provided a corresponding
label binding for this FEC to an upstream neighbor, either because it label binding for this FEC to an upstream neighbor, either because it
is using independent control, or because the new binding from is using independent control, or because the new binding from
downstream is the result of a routing change. In this case, unless downstream is the result of a routing change. In this case, unless
the hop count is 0, it MUST extract the hop count from the new the hop count is 0, it MUST extract the hop count from the new
binding and increment it by one. If the new hop count is different binding and increment it by one. If the new hop count is different
from that which was previously conveyed to the upstream neighbor from that which was previously conveyed to the upstream neighbor
(including the case where the upstream neighbor was given the value (including the case where the upstream neighbor was given the value
`unknown') the ATM-LSR MUST notify the upstream neighbor of the 'unknown') the ATM-LSR MUST notify the upstream neighbor of the
change. Each ATM-LSR in turn MUST increment the hop count and pass it change. Each ATM-LSR in turn MUST increment the hop count and pass it
upstream until it reaches the ingress Edge LSR. If at any point the upstream until it reaches the ingress Edge LSR. If at any point the
value of the hop count equals a configured maximum hop count value, value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw the
the ATM-LSR SHOULD withdraw the binding from the upstream neighbor. binding from the upstream neighbor. A hop count of 0 MUST be passed
A hop count of 0 MUST be passed upstream unchanged. upstream unchanged.
Whenever an ATM-LSR originates a label binding request to its next Whenever an ATM-LSR originates a label binding request to its next
hop LSR as a result of receiving a label binding request from another hop LSR as a result of receiving a label binding request from another
(upstream) LSR, and the request to the next hop LSR is not satisfied, (upstream) LSR, and the request to the next hop LSR is not satisfied,
the ATM-LSR SHOULD destroy the binding created in response to the the ATM-LSR SHOULD destroy the binding created in response to the
received request, and notify the requester (via LDP). received request, and notify the requester (via LDP).
If an ATM-LSR receives a binding request containing a hop count that If an ATM-LSR receives a binding request containing a hop count that
exceeds a configurable maximum, it MUST not establish a binding, and exceeds MAXHOP, it MUST not establish a binding, and it MUST return
it MUST return an error to the requester. an error to the requester.
When a LSR determines that it has lost its LDP session with another When a LSR determines that it has lost its LDP session with another
LSR, the following actions are taken. Any binding information LSR, the following actions are taken. Any binding information
learned via this connection MUST be discarded. For any label learned via this connection MUST be discarded. For any label
bindings that were created as a result of receiving label binding bindings that were created as a result of receiving label binding
requests from the peer, the LSR MAY destroy these bindings (and requests from the peer, the LSR MAY destroy these bindings (and
deallocate labels associated with these binding). deallocate labels associated with these binding).
An ATM-LSR SHOULD use `split-horizon' when it satisfies binding An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding
requests from its neighbors. That is, if it receives a request for a requests from its neighbors. That is, if it receives a request for a
binding to a particular FEC and the LSR making that request is, 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 not according to this ATM-LSR, the next hop for that FEC, it should not
return a binding for that route. return a binding for that route.
Non-merging ATM-LSRs MUST use "conservative label retention mode" It is expected that non-merging ATM-LSRs would generally use
[1]. "conservative label retention mode" [1].
8.3. VC-merge-capable ATM Switches 8.3. VC-merge-capable ATM Switches
Relatively minor changes are needed to accommodate ATM-LSRs which Relatively minor changes are needed to accommodate ATM-LSRs which
support VC-merge. The primary difference is that a VC-merge-capable support VC-merge. The primary difference is that a VC-merge-capable
ATM-LSR needs only one outgoing label per FEC, even if multiple ATM-LSR needs only one outgoing label per FEC, even if multiple
requests for label bindings to that FEC are received from upstream requests for label bindings to that FEC are received from upstream
neighbors. neighbors.
When a VC-merge-capable ATM-LSR receives a binding request from an When a VC-merge-capable ATM-LSR receives a binding request from an
skipping to change at page 12, line 24 skipping to change at page 12, line 35
If the ATM-LSR does not have an outgoing label binding for the FEC, 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 issue but does have an outstanding request for one, it need not issue
another request. another request.
When sending a label binding upstream, the hop count associated with When sending a label binding upstream, the hop count associated with
the corresponding binding from downstream MUST be incremented by 1, the corresponding binding from downstream MUST be incremented by 1,
and the result transmitted upstream as the hop count associated with and the result transmitted upstream as the hop count associated with
the new binding. However, there are two exceptions: a hop count of 0 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 at MUST be passed upstream unchanged, and if the hop count is already at
the configured maximum value, the ATM-LSR MUST NOT pass a binding MAXHOP, the ATM-LSR MUST NOT pass a binding upstream, but instead
upstream, but instead MUST send an error upstream. MUST send an error upstream.
Note that, just like conventional ATM-LSRs and members of the edge Note that, just like conventional ATM-LSRs and members of the edge
set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a
new binding every time it receives a request from upstream, since new binding every time it receives a request from upstream, since
there may be switches upstream which do not support VC-merge. there may be switches upstream which do not support VC-merge.
However, it only needs to issue a corresponding binding request However, it only needs to issue a corresponding binding request
downstream if it does not already have a label binding for the downstream if it does not already have a label binding for the
appropriate route. appropriate route.
When a change in the routing table of a VC-merge-capable ATM-LSR When a change in the routing table of a VC-merge-capable ATM-LSR
skipping to change at page 12, line 41 skipping to change at page 13, line 4
However, it only needs to issue a corresponding binding request However, it only needs to issue a corresponding binding request
downstream if it does not already have a label binding for the downstream if it does not already have a label binding for the
appropriate route. appropriate route.
When a change in the routing table of a VC-merge-capable ATM-LSR When a change in the routing table of a VC-merge-capable ATM-LSR
causes it to select a new next hop for one of its FECs, it MAY causes it to select a new next hop for one of its FECs, it MAY
optionally release the binding for that route from the former next optionally release the binding for that route from the former next
hop. If it doesn't already have a corresponding binding for the new hop. If it doesn't already have a corresponding binding for the new
next hop, it must request one. (The choice between conservative and next hop, it must request one. (The choice between conservative and
liberal label retention mode [1] is an implementation option.) liberal label retention mode [1] is an implementation option.)
If a new binding is obtained, which contains a hop count that differs If a new binding is obtained, which contains a hop count that differs
from that which was received in the old binding, then the ATM-LSR from that which was received in the old binding, then the ATM-LSR
must take the new hop count, increment it by one, and notify any must take the new hop count, increment it by one, and notify any
upstream neighbors who have label bindings for this FEC of the new upstream neighbors who have label bindings for this FEC of the new
value. Just as with conventional ATM-LSRs, this enables the new hop value. Just as with conventional ATM-LSRs, this enables the new hop
count to propagate back towards the ingress of the ATM-LSR domain. If count to propagate back towards the ingress of the ATM-LSR domain. If
at any point the hop count exceeds the configurable maximum value, at any point the hop count exceeds MAXHOP, then the label bindings
then the label bindings for this route must be withdrawn from all for this route must be withdrawn from all upstream neighbors to whom
upstream neighbors to whom a binding was previously provided. This a binding was previously provided. This ensures that any loops caused
ensures that any loops caused by routing transients will be detected by routing transients will be detected and broken.
and broken.
9. Encapsulation 9. Encapsulation
The procedures described in this section affect only the Edge LSRs of The procedures described in this section affect only the Edge LSRs of
the ATM-LSR domain. The ATM-LSRs themselves do not modify the the ATM-LSR domain. The ATM-LSRs themselves do not modify the
encapsulation in any way. encapsulation in any way.
Except in certain circumstances specified below, when a labeled Except in certain circumstances specified below, when a labeled
packet is transmitted on an LC-ATM interface, where the VPI/VCI (or packet is transmitted on an LC-ATM interface, where the VPI/VCI (or
VCID) is interpreted as the top label in the label stack, the packet VCID) is interpreted as the top label in the label stack, the packet
skipping to change at page 13, line 40 skipping to change at page 14, line 4
determine whether there are additional label stack entries. determine whether there are additional label stack entries.
The only ways to eliminate this extra overhead are: The only ways to eliminate this extra overhead are:
- through apriori knowledge that packets have only a single label - through apriori knowledge that packets have only a single label
(e.g., perhaps the network only supports one level of label) (e.g., perhaps the network only supports one level of label)
- by using two VCs per FEC, one for those packets which have only a - by using two VCs per FEC, one for those packets which have only a
single label, and one for those packets which have more than one single label, and one for those packets which have more than one
label label
The second technique would require that there be some way of
signalling via LDP that the VC is carrying only packets with a single
label, and is not carrying a shim. When supporting VC merge, one
would also have to take care not to merge a VC on which the shim is
not used into a VC on which it is used, or vice versa.
While either of these techniques is permitted, it is doubtful that While either of these techniques is permitted, it is doubtful that
they have any practical utility. Note that if the shim header is not they have any practical utility. Note that if the shim header is not
present, the outgoing TTL is carried in the TTL field of the network present, the outgoing TTL is carried in the TTL field of the network
layer header. layer header.
10. TTL Manipulation 10. TTL Manipulation
The procedures described in this section affect only the Edge LSRs of The procedures described in this section affect only the Edge LSRs of
the ATM-LSR domain. The ATM-LSRs themselves do not modify the TTL in the ATM-LSR domain. The ATM-LSRs themselves do not modify the TTL in
skipping to change at page 15, line 6 skipping to change at page 15, line 18
generic encapsulation, or, if that encapsulation is not present, from generic encapsulation, or, if that encapsulation is not present, from
the IP header. the IP header.
If the packet's next hop is an ATM-LSR, the outgoing TTL is formed If the packet's next hop is an ATM-LSR, the outgoing TTL is formed
using the procedures described in this section. Otherwise the using the procedures described in this section. Otherwise the
outgoing TTL is formed using the procedures described in [3]. outgoing TTL is formed using the procedures described in [3].
The procedures in this section are intended to apply only to unicast The procedures in this section are intended to apply only to unicast
packets. packets.
11. Security Considerations 11. Optional Loop Detection: Distributing Path Vectors
Every ATM-LSR MUST implement, as a configurable option, the following
procedure for detecting forwarding loops. We refer to this as the
LDPV (Loop Detection via Path Vectors) procedure. This procedure
does not prevent the formation of forwarding loops, but does ensure
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, but
at a higher cost in overhead.
11.1. When to Send Path Vectors Downstream
Suppose an LSR R sends a request for a label binding, for a
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 for
that LSP, or because it has acquired a new next hop, then R MUST
include a path vector object with the request, and the path
vector object MUST contain only R's own address.
- If R is sending the request as a result of having received a
request from an upstream LSR, then:
* if the received request has a path vector object, R MUST add
its own address to the received path vector object, and MUST
pass the resulting path vector object to its next hop along
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 it sends,
and the path vector object MUST contain only R's own address.
An LSR which supports VC-merge SHOULD NOT include a path vector
object in the requests that it sends to its next hop.
If an LSR receives a label binding request whose path vector object
contains the address of the node itself, the LSR concludes that the
label binding requests have traveled in a loop. The LSR MUST act as
it would in the case where the hop count exceeds MAXHOP (see section
8.2).
This procedure detects the case where the request messages loop
though a sequence of non-merging ATM-LSRs.
11.2. When to Send Path Vectors Upstream
As specified in section 8, there are circumstances in which an LSR R
must inform its upstream neighbors, via a label binding response
message, of a change in hop count for a particular LSP. If the
following conditions all hold:
- R is configured for the LDPV procedure,
- R supports VC-merge,
- R is not the egress for that LSP, and
- R is not informing its neighbors of a decrease in the hop 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 by
its next hop, S, of a change in hop count, and the message from S to
R included a path vector object, then if the above conditions hold, R
MUST add itself to this object and pass the result upstream.
Otherwise, if the above conditions hold, R MUST create a new object
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 binding
response message that it sends upstream. In particular, at any time
that R receives a label binding response from its next hop, if that
response contains a path vector, R MAY (if configured for the LDPV
procedure) send a response to its upstream neighbors, containing the
path vector object formed by adding its own address to the received
path vector.
If R does not support VC merge, it SHOULD NOT send a path vector
object upstream.
If an LSR receives a message from its next hop, with a path vector
object containing its own address, then LSR MUST act as it would if
it received a message with a hop count equal to MAXHOP.
LSRs which are configured for the LDPV procedure SHOULD NOT store a
path vector once the corresponding path vector object has been
transmitted.
Note that if the ATM-LSR domain consists entirely of non-merging
ATM-LSRs, path vectors need not ever be sent upstream, since any
loops will be detected by means of the path vectors traveling
downstream.
By not sending path vectors unless the hop count increases, one
avoids sending them in many situations when there is no loop. The
cost is that in some situations in which there is a loop, the time to
detect the loop may be lengthened.
12. Security Considerations
The use of the procedures and encapsulations specified in this The use of the procedures and encapsulations specified in this
document does not have any security impact other than that which may document does not have any security impact other than that which may
generally be present in the use of any MPLS procedures or generally be present in the use of any MPLS procedures or
encapsulations. encapsulations.
12. Intellectual Property Considerations 13. Intellectual Property Considerations
Cisco Systems may seek patent or other intellectual property Cisco Systems may seek patent or other intellectual property
protection for some or all of the technologies disclosed in this protection for some or all of the technologies disclosed in this
document. If any standards arising from this document are or become document. If any standards arising from this document are or become
protected by one or more patents assigned to Cisco Systems, Cisco protected by one or more patents assigned to Cisco Systems, Cisco
intends to disclose those patents and license them under openly intends to disclose those patents and license them under openly
specified and non-discriminatory terms, for no fee. specified and non-discriminatory terms, for no fee.
13. References 14. References
[1] Rosen E., Viswanathan, A., Callon R., "Multi-Protocol Label [1] Rosen E., Viswanathan, A., Callon R., "Multi-Protocol Label
Switching Architecture", Work in Progress, July 1998 Switching Architecture", Work in Progress, July 1998
[2] Andersson L., Doolan P., Feldman N., Fredette A., Thomas R., [2] Andersson L., Doolan P., Feldman N., Fredette A., Thomas R.,
"Label Distribution Protocol", Work in Progress, August 1998. "Label Distribution Protocol", Work in Progress, August 1998.
[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., [3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G.,
Li, T., Conta, A., "MPLS Label Stack Encoding", Work in Progress, Li, T., Conta, A., "MPLS Label Stack Encoding", Work in Progress,
September 1998. September 1998.
[4] Nagami, K., Demizu N., Esaki H., Doolan P., "VCID Notification [4] Nagami, K., Demizu N., Esaki H., Doolan P., "VCID Notification
over ATM link", Work in Progress, August 1998. over ATM link", Work in Progress, August 1998.
[5] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation [5] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993 Layer 5", RFC 1483, July 1993
14. Acknowledgments 15. Acknowledgments
Significant contributions to this work have been made by Anthony Significant contributions to this work have been made by Anthony
Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan
Littlewood and Dan Tappan. Littlewood and Dan Tappan. We thank Alex Conta for his comments.
15. Authors' Addresses 16. Authors' Addresses
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA, 01824 Chelmsford, MA, 01824
E-mail: bsd@cisco.com E-mail: bsd@cisco.com
Paul Doolan Paul Doolan
Ennovate Networks Inc. Ennovate Networks Inc.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/