draft-ietf-mpls-atm-01.txt   draft-ietf-mpls-atm-02.txt 
Network Working Group Bruce Davie Network Working Group Bruce Davie
Internet Draft Jeremy Lawrence Internet Draft Jeremy Lawrence
Expiration Date: May 1999 Keith McCloghrie Expiration Date: October 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.
November 1998 April 1999
MPLS using ATM VC Switching MPLS using LDP and ATM VC Switching
draft-ietf-mpls-atm-01.txt draft-ietf-mpls-atm-02.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 and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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 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
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt.
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific The list of Internet-Draft Shadow Directories can be accessed at
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
Abstract Abstract
The MPLS Architecture [1] discusses a way in which ATM switches may The MPLS Architecture [1] discusses a 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 4, line 9 skipping to change at page 4, line 9
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
for multicast or explicitly routed labeled packets as well. for multicast or explicitly routed labeled packets as well.
This document uses terminology from [1]. This document uses terminology from [1].
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119.
3. Definitions 3. Definitions
A Label Switching Router (LSR) is a device which implements the label A Label Switching Router (LSR) is a device which implements the label
switching control and forwarding components described in [1]. switching control and forwarding components described in [1].
A label switching controlled ATM (LC-ATM) interface is an ATM A label switching controlled ATM (LC-ATM) interface is an ATM
interface controlled by the label switching control component. When a interface controlled by the label switching control component. When a
packet traversing such an interface is received, it is treated as a packet traversing such an interface is received, it is treated as a
labeled packet. The packet's top label is inferred either from the labeled packet. The packet's top label is inferred either from the
skipping to change at page 6, line 35 skipping to change at page 6, line 35
consistent between the two control components, such as the portions consistent between the two control components, such as the portions
of the VPI/VCI space which are available to each component. of the VPI/VCI space which are available to each component.
7. Use of VPI/VCIs 7. Use of VPI/VCIs
Label switching is accomplished by associating labels with Forwarding Label switching is accomplished by associating labels with Forwarding
Equivalence Classes, and using the label value to forward packets, Equivalence Classes, and using the label value to forward packets,
including determining the value of any replacement label. See [1] including determining the value of any replacement label. See [1]
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.
connected via an LC-ATM interface, a non-MPLS connection, capable of
carrying unlabelled IP packets, MUST be available. This non-MPLS Labeled packets MUST be transmitted using the null encapsulation, as
connection is used to carry LDP packets between the two peers, and defined in Section 5.1 of RFC 1483 [5].
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 In addition, if two LDP peers are connected via an LC-ATM interface,
RFC 1483 [5] MUST be used on the non-MPLS connection. a non-MPLS connection, capable of carrying unlabelled IP packets,
MUST be available. This non-MPLS 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 packets (such as OSPF
packets, etc.). The LLC/SNAP encapsulation of RFC 1483 [5] MUST be
used on the non-MPLS connection.
It SHOULD be possible to configure an LC-ATM interface with It SHOULD be possible to configure an LC-ATM interface with
additional VPI/VCIs that are used to carry control information or additional VPI/VCIs that are used to carry control information or
non-labelled packets. In that case, the VCI values MUST be in the non-labelled packets. In that case, the VCI values MUST be in the
0-32 range. These may use either the null encapsulation, as defined 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 in Section 5.1 of RFC 1483 [5], or the LLC/SNAP encapsulation, as
defined in Section 4.1 of RFC 1483 [5]. defined in Section 4.1 of RFC 1483 [5].
7.1. Direct Connections 7.1. Direct Connections
skipping to change at page 8, line 10 skipping to change at page 8, line 15
The allowable ranges of VPI/VCIs are communicated through LDP. If The allowable ranges of VPI/VCIs are communicated through LDP. If
more than one VPI is used for label switching, the allowable range of more than one VPI is used for label switching, the allowable range of
VCIs may be different for each VPI, and each range is communicated VCIs may be different for each VPI, and each range is communicated
through LDP. through LDP.
7.3. Connections via an ATM SVC 7.3. Connections via an ATM SVC
Sometimes it may be useful to treat two LSRs as adjacent (in some Sometimes it may be useful to treat two LSRs as adjacent (in some
LSP) across an LC-ATM interface, even though the connection between LSP) across an LC-ATM interface, even though the connection between
them is made through an ATM "cloud" via a set of ATM Switched Virtual them is made through an ATM "cloud" via a set of ATM Switched Virtual
Circuits. In this case, the procedures described in [4] MUST be used Circuits.
to assign a VCID to each such VC, and LDP is used to bind a VCID to a
FEC. The top label of a received packet is then inferred (via a
one-to-one mapping) from the virtual circuit on which the packet
arrived.
In this case, there is no default VPI or VCI value for the non-MPLS The current document does not specify the procedure for handling this
connection. case. Such procedures can be found in [4]. The procedures described
in [4] allow a VCID to be assigned to each such VC, and specify how
LDP can be used used to bind a VCID to a FEC. The top label of a
received packet would then be inferred (via a one-to-one mapping)
from the virtual circuit on which the packet arrived. There would
not be a default VPI or VCI value for the non-MPLS connection.
8. Label Distribution and Maintenance Procedures 8. Label Distribution and Maintenance Procedures
This document discusses the use of "downstream-on-demand" label This document discusses the use of "downstream-on-demand" label
distribution (see [1]) by ATM-LSRs. These label distribution distribution (see [1]) by ATM-LSRs. These label distribution
procedures MUST be used by ATM-LSRs that do not support VC-merge, and procedures MUST be used by ATM-LSRs that do not support VC-merge, and
MAY also be used by ATM-LSRs that do support VC-merge. The MAY also be used by ATM-LSRs that do support VC-merge. The
procedures differ somewhat in the two cases, however. We therefore procedures differ somewhat in the two cases, however. We therefore
describe the two scenarios in turn. We begin by describing the describe the two scenarios in turn. We begin by describing the
behavior of members of the Edge Set of an ATM-LSR domain; these "Edge behavior of members of the Edge Set of an ATM-LSR domain; these "Edge
LSRs" are not themselves ATM-LSRs, and their behavior is the same LSRs" are not themselves ATM-LSRs, and their behavior is the same
whether the domain contains VC-merge capable LSRs or not. whether the domain contains VC-merge capable LSRs or not.
8.1. Edge LSR Behavior 8.1. Edge LSR Behavior
Consider a member of the Edge Set of an ATM-LSR domain. Assume that, 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 the as a result of its routing calculations, it selects an ATM-LSR as the
next hop of a certain FEC, and that the next hop is reachable via a next hop of a certain FEC, and that the next hop is reachable via a
LC-ATM interface. The Edge LSR uses LDP to request a label binding LC-ATM interface. The Edge LSR uses LDP to request a label binding
for that FEC from the next hop. The hop count field in the request for that FEC from the next hop. The hop count field in the request
is set to 1. Once the Edge LSR receives the label binding is set to 1 (but see the next paragraph). Once the Edge LSR receives
information, it may use MPLS forwarding procedures to transmit the label binding information, it may use MPLS forwarding procedures
packets in the specified FEC, using the specified label as an to transmit packets in the specified FEC, using the specified label
outgoing label. (Or using the VPI/VCI that corresponds to the as an outgoing label. (Or using the VPI/VCI that corresponds to the
specified VCID as the outgoing label, if VCIDs are being used.) specified VCID as the outgoing label, if the VCID technique of [4] is
being used.)
Note: if the Edge LSR's previous hop is using downstream-on-demand
label distribution to request a label from the Edge LSR for a
particular FEC, and if the Edge LSR is not merging the LSP from that
previous hop with any other LSP, and if the request from the previous
hop has a hop count of h, then the hop count in the request issued by
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, which The binding received by the edge LSR may contain a hop count, which
represents the number of hops a packet will take to cross the ATM-LSR represents the number of hops a packet will take to cross the ATM-LSR
domain when using this label. If there is a hop count associated with domain when using this label. If there is a hop count associated with
the binding, the ATM-LSR SHOULD adjust a data packet's TTL by this the binding, the ATM-LSR SHOULD adjust a data packet's TTL by this
amount before transmitting the packet. In any event, it MUST adjust amount before transmitting the packet. In any event, it MUST adjust
a data packet's TTL by at least one before transmitting it. The a data packet's TTL by at least one before transmitting it. The
procedures for doing so (in the case of IP packets) are specified in procedures for doing so (in the case of IP packets) are specified in
section 10. The procedures for encapsulating the packets are section 10. The procedures for encapsulating the packets are
specified in section 9. specified in section 9.
skipping to change at page 13, line 21 skipping to change at page 13, line 29
for this route must be withdrawn from all upstream neighbors to whom for this route must be withdrawn from all upstream neighbors to whom
a binding was previously provided. This ensures that any loops caused a binding was previously provided. This ensures that any loops caused
by routing transients will be detected and broken. by routing transients will be detected 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.
Labeled packets MUST be transmitted using the null encapsulation of
Section 5.1 of RFC 1483 [5].
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
MUST also contain a "shim header" [3]. MUST also contain a "shim header" [3].
If the packet has a label stack with n entries, it MUST carry a shim If the packet has a label stack with n entries, it MUST carry a shim
with n entries. The actual value of the top label is encoded in the with n entries. The actual value of the top label is encoded in the
VPI/VCI field. The label value of the top entry in the shim (which VPI/VCI field. The label value of the top entry in the shim (which
is just a "placeholder" entry) MUST be set to 0 upon transmission, is just a "placeholder" entry) MUST be set to 0 upon transmission,
and MUST be ignored upon reception. The packet's outgoing TTL, and and MUST be ignored upon reception. The packet's outgoing TTL, and
skipping to change at page 18, line 8 skipping to change at page 18, line 8
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.
14. 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, April 1999.
[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, April 1999.
[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. April 1999.
[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, April 1999.
[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
15. 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. We thank Alex Conta for his comments. Littlewood and Dan Tappan. We thank Alex Conta for his comments.
skipping to change at page 19, line 6 skipping to change at page 19, line 6
E-mail: bsd@cisco.com E-mail: bsd@cisco.com
Paul Doolan Paul Doolan
Ennovate Networks Inc. Ennovate Networks Inc.
330 Codman Hill Rd 330 Codman Hill Rd
Boxborough, MA 01719 Boxborough, MA 01719
E-mail: pdoolan@ennovatenetworks.com E-mail: pdoolan@ennovatenetworks.com
Jeremy Lawrence Jeremy Lawrence
Cisco Systems, Inc. Cisco Systems, Inc.
1400 Parkmoor Ave. 99 Walker St.
San Jose, CA, 95126 North Sydney, NSW, Australia
E-mail: jlawrenc@cisco.com E-mail: jlawrenc@cisco.com
Keith McCloghrie Keith McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA, 95134 San Jose, CA, 95134
E-mail: kzm@cisco.com E-mail: kzm@cisco.com
 End of changes. 

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