draft-ietf-mpls-atm-02.txt   draft-ietf-mpls-atm-03.txt 
Network Working Group Bruce Davie Network Working Group Bruce Davie
Internet Draft Jeremy Lawrence Internet Draft Jeremy Lawrence
Expiration Date: October 1999 Keith McCloghrie Expiration Date: November 2000 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.
April 1999 May 2000
MPLS using LDP and ATM VC Switching MPLS using LDP and ATM VC Switching
draft-ietf-mpls-atm-02.txt draft-ietf-mpls-atm-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
This document extends and clarifies the relevant portions of [1] and This document extends and clarifies the relevant portions of [1] and
skipping to change at page 2, line 24 skipping to change at page 3, line 11
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]. companion document to [3].
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 .............. 6
6 Hybrid Switches (Ships in the Night) ................... 6 6 Hybrid Switches (Ships in the Night) ................... 7
7 Use of VPI/VCIs ....................................... 6 7 Use of VPI/VCIs ....................................... 7
7.1 Direct Connections ..................................... 7 7.1 Direct Connections ..................................... 8
7.2 Connections via an ATM VP .............................. 7 7.2 Connections via an ATM VP .............................. 8
7.3 Connections via an ATM SVC ............................. 8 7.3 Connections via an ATM SVC ............................. 9
8 Label Distribution and Maintenance Procedures .......... 8 8 Label Distribution and Maintenance Procedures .......... 9
8.1 Edge LSR Behavior ...................................... 8 8.1 Edge LSR Behavior ...................................... 9
8.2 Conventional ATM Switches (non-VC-merge) ............... 9 8.2 Conventional ATM Switches (non-VC-merge) ............... 10
8.3 VC-merge-capable ATM Switches .......................... 12 8.3 VC-merge-capable ATM Switches .......................... 13
9 Encapsulation .......................................... 13 9 Encapsulation .......................................... 14
10 TTL Manipulation ....................................... 14 10 TTL Manipulation ....................................... 15
11 Optional Loop Detection: Distributing Path Vectors ..... 15 11 Optional Loop Detection: Distributing Path Vectors ..... 16
11.1 When to Send Path Vectors Downstream ................... 15 11.1 When to Send Path Vectors Downstream ................... 16
11.2 When to Send Path Vectors Upstream ..................... 16 11.2 When to Send Path Vectors Upstream ..................... 17
12 Security Considerations ................................ 17 12 Security Considerations ................................ 18
13 Intellectual Property Considerations ................... 17 13 Intellectual Property Considerations ................... 18
14 References ............................................. 18 14 References ............................................. 19
15 Acknowledgments ........................................ 18 15 Acknowledgments ........................................ 19
16 Authors' Addresses ..................................... 18 16 Authors' Addresses ..................................... 20
17 Full Copyright Statement ............................... 21
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 4, line 26 skipping to change at page 5, line 8
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
contents of the VCI field or the combined contents of the VPI and VCI contents of the VCI field or the combined contents of the VPI and VCI
fields. Any two LDP peers which are connected via an LC-ATM fields. Any two LDP peers which are connected via an LC-ATM
interface will use LDP negotiations to determine which of these cases interface will use LDP negotiations to determine which of these cases
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, without reassembling the cells into frames before
forwarding.
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.
Sometimes a single box may behave as an ATM-LSR with respect to Sometimes a single box may behave as an ATM-LSR with respect to
certain pairs of interfaces, but may behave as a frame-based LSR with 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 respect to other pairs. For example, an ATM switch with an ethernet
interface may function as an ATM-LSR when forwarding cells between interface may function as an ATM-LSR when forwarding cells between
its LC-ATM interfaces, but may function as a frame-based LSR when its LC-ATM interfaces, but may function as a frame-based LSR when
skipping to change at page 6, line 38 skipping to change at page 7, line 28
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. "Virtual Path", in the VCI field.
Labeled packets MUST be transmitted using the null encapsulation, as Labeled packets MUST be transmitted using the null encapsulation, as
defined in Section 5.1 of RFC 1483 [5]. defined in Section 6.1 of RFC 2684 [5].
In addition, if two LDP peers are connected via an LC-ATM interface, In addition, if two LDP peers are connected via an LC-ATM interface,
a non-MPLS connection, capable of carrying unlabelled IP packets, a non-MPLS connection, capable of carrying unlabelled IP packets,
MUST be available. This non-MPLS connection is used to carry LDP 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 packets between the two peers, and MAY also be used (but is not
required to be used) for other unlabeled packets (such as OSPF required to be used) for other unlabeled packets (such as OSPF
packets, etc.). The LLC/SNAP encapsulation of RFC 1483 [5] MUST be packets, etc.). The LLC/SNAP encapsulation of RFC 2684 [5] MUST be
used on the non-MPLS connection. 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 NOT be in
0-32 range. These may use either the null encapsulation, as defined the 0-32 range. These may use either the null encapsulation, as
in Section 5.1 of RFC 1483 [5], or the LLC/SNAP encapsulation, as defined in Section 6.1 of RFC 2684 [5], or the LLC/SNAP
defined in Section 4.1 of RFC 1483 [5]. encapsulation, as defined in Section 5.1 of RFC 2684 [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 7, line 41 skipping to change at page 8, line 38
7.2. Connections via an ATM VP 7.2. Connections via an ATM VP
Sometimes it can be useful to treat two LSRs as adjacent (in some Sometimes it can 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 an ATM Virtual Path. In this them is made through an ATM "cloud" via an ATM Virtual Path. In this
case, the VPI field is not available to MPLS, and the label MUST be case, the VPI field is not available to MPLS, and the label MUST be
encoded entirely within the VCI field. encoded entirely within the VCI field.
In this case, the default VCI value of the non-MPLS connection In this case, the default VCI value of the non-MPLS connection
between the LSRs is 32. The VPI is set to whatever is required to between the LSRs is 32. Other values can be configured, as long as
make use of the Virtual Path. both parties are aware of the configured value. The VPI is set to
whatever is required to make use of the Virtual Path.
A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST
NOT be used as the encoding of a label. NOT be used as the encoding of a label.
With the exception of these reserved values, the VPI/VCI values used With the exception of these reserved values, the VPI/VCI values used
in the two directions of the link MAY be treated as independent in the two directions of the link MAY be treated as independent
spaces. spaces.
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
skipping to change at page 13, line 30 skipping to change at page 14, line 26
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 Labeled packets MUST be transmitted using the null encapsulation of
Section 5.1 of RFC 1483 [5]. Section 6.1 of RFC 2684 [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,
skipping to change at page 17, line 44 skipping to change at page 18, line 44
12. Security Considerations 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.
13. Intellectual Property Considerations 13. Intellectual Property Considerations
Cisco Systems may seek patent or other intellectual property The IETF has been notified of intellectual property rights claimed in
protection for some or all of the technologies disclosed in this regard to some or all of the specification contained in this
document. If any standards arising from this document are or become document. For more information consult the online list of claimed
protected by one or more patents assigned to Cisco Systems, Cisco rights.
intends to disclose those patents and license them under openly
specified and non-discriminatory terms, for no fee. The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
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, April 1999. Switching Architecture", Work in Progress, August 1999.
[2] Andersson L., Doolan P., Feldman N., Fredette A., Thomas R., [2] Andersson L., Doolan P., Feldman N., Fredette A., Thomas R., "LDP
"Label Distribution Protocol", Work in Progress, April 1999. Specification", Work in Progress, October 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,
April 1999. September 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, April 1999. over ATM link", Work in Progress, July 1999.
[5] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation [5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM
Layer 5", RFC 1483, July 1993 Adaptation Layer 5", RFC 2684, September 1999
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.
16. Authors' Addresses 16. Authors' Addresses
Bruce Davie Bruce Davie
skipping to change at line 857 skipping to change at page 21, line 17
Chelmsford, MA, 01824 Chelmsford, MA, 01824
E-mail: erosen@cisco.com E-mail: erosen@cisco.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA, 01824 Chelmsford, MA, 01824
E-mail: swallow@cisco.com E-mail: swallow@cisco.com
17. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
 End of changes. 

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