--- 1/draft-ietf-mpls-atm-02.txt 2006-02-05 00:37:15.000000000 +0100 +++ 2/draft-ietf-mpls-atm-03.txt 2006-02-05 00:37:15.000000000 +0100 @@ -1,26 +1,26 @@ Network Working Group Bruce Davie Internet Draft Jeremy Lawrence -Expiration Date: October 1999 Keith McCloghrie +Expiration Date: November 2000 Keith McCloghrie Yakov Rekhter Eric Rosen George Swallow Cisco Systems, Inc. Paul Doolan Ennovate Networks, Inc. - April 1999 + May 2000 MPLS using LDP and ATM VC Switching - draft-ietf-mpls-atm-02.txt + draft-ietf-mpls-atm-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. @@ -29,20 +29,24 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + Abstract The MPLS Architecture [1] discusses a way in which ATM switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs. This document extends and clarifies the relevant portions of [1] and @@ -55,40 +59,41 @@ 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 companion document to [3]. Contents 1 Introduction ........................................... 3 2 Specification of Requirements .......................... 4 3 Definitions ............................................ 4 4 Special Characteristics of ATM Switches ................ 5 - 5 Label Switching Control Component for ATM .............. 5 - 6 Hybrid Switches (Ships in the Night) ................... 6 - 7 Use of VPI/VCIs ....................................... 6 - 7.1 Direct Connections ..................................... 7 - 7.2 Connections via an ATM VP .............................. 7 - 7.3 Connections via an ATM SVC ............................. 8 - 8 Label Distribution and Maintenance Procedures .......... 8 - 8.1 Edge LSR Behavior ...................................... 8 - 8.2 Conventional ATM Switches (non-VC-merge) ............... 9 - 8.3 VC-merge-capable ATM Switches .......................... 12 - 9 Encapsulation .......................................... 13 - 10 TTL Manipulation ....................................... 14 - 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 + 5 Label Switching Control Component for ATM .............. 6 + 6 Hybrid Switches (Ships in the Night) ................... 7 + 7 Use of VPI/VCIs ....................................... 7 + 7.1 Direct Connections ..................................... 8 + 7.2 Connections via an ATM VP .............................. 8 + 7.3 Connections via an ATM SVC ............................. 9 + 8 Label Distribution and Maintenance Procedures .......... 9 + 8.1 Edge LSR Behavior ...................................... 9 + 8.2 Conventional ATM Switches (non-VC-merge) ............... 10 + 8.3 VC-merge-capable ATM Switches .......................... 13 + 9 Encapsulation .......................................... 14 + 10 TTL Manipulation ....................................... 15 + 11 Optional Loop Detection: Distributing Path Vectors ..... 16 + 11.1 When to Send Path Vectors Downstream ................... 16 + 11.2 When to Send Path Vectors Upstream ..................... 17 + 12 Security Considerations ................................ 18 + 13 Intellectual Property Considerations ................... 18 + 14 References ............................................. 19 + 15 Acknowledgments ........................................ 19 + 16 Authors' Addresses ..................................... 20 + 17 Full Copyright Statement ............................... 21 1. Introduction The MPLS Architecture [1] discusses the way in which ATM switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs. @@ -141,22 +146,23 @@ A label switching controlled ATM (LC-ATM) interface is an ATM interface controlled by the label switching control component. When 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 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 interface will use LDP negotiations to determine which of these cases is applicable to that interface. 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 - VPI/VCI field. + cells between these interfaces, using labels carried in the VCI or + VPI/VCI field, without reassembling the cells into frames before + forwarding. 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. 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 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 @@ -246,36 +252,36 @@ 7. Use of VPI/VCIs Label switching is accomplished by associating labels with Forwarding Equivalence Classes, and using the label value to forward packets, including determining the value of any replacement label. See [1] 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 "Virtual Path", in the VCI field. 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, 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 + packets, etc.). The LLC/SNAP encapsulation of RFC 2684 [5] MUST be used on the non-MPLS connection. It SHOULD be possible to configure an LC-ATM interface with additional VPI/VCIs that are used to carry control information or - 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 - in Section 5.1 of RFC 1483 [5], or the LLC/SNAP encapsulation, as - defined in Section 4.1 of RFC 1483 [5]. + non-labelled packets. In that case, the VCI values MUST NOT be in + the 0-32 range. These may use either the null encapsulation, as + defined in Section 6.1 of RFC 2684 [5], or the LLC/SNAP + encapsulation, as defined in Section 5.1 of RFC 2684 [5]. 7.1. Direct Connections We say that two LSRs are "directly connected" over an LC-ATM 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. When two LSRs are directly connected via an LC-ATM interface, they jointly control the allocation of VPIs/VCIs on the interface connecting them. They may agree to use the VPI/VCI field to encode a @@ -296,22 +302,23 @@ 7.2. Connections via an ATM VP Sometimes it can be useful to treat two LSRs as adjacent (in some 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 case, the VPI field is not available to MPLS, and the label MUST be encoded entirely within the VCI field. 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 - make use of the Virtual Path. + between the LSRs is 32. Other values can be configured, as long as + 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 NOT be used as the encoding of a label. With the exception of these reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces. The allowable ranges of VPI/VCIs are communicated through LDP. If more than one VPI is used for label switching, the allowable range of @@ -566,21 +574,21 @@ a binding was previously provided. This ensures that any loops caused by routing transients will be detected and broken. 9. Encapsulation The procedures described in this section affect only the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves do not modify the encapsulation in any way. 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 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 MUST also contain a "shim header" [3]. 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 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, @@ -767,44 +774,62 @@ 12. Security Considerations The use of the procedures and encapsulations specified in this document does not have any security impact other than that which may generally be present in the use of any MPLS procedures or encapsulations. 13. Intellectual Property Considerations - Cisco Systems may seek patent or other intellectual property - protection for some or all of the technologies disclosed in this - document. If any standards arising from this document are or become - protected by one or more patents assigned to Cisco Systems, Cisco - intends to disclose those patents and license them under openly - specified and non-discriminatory terms, for no fee. + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + 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 [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., - "Label Distribution Protocol", Work in Progress, April 1999. + [2] Andersson L., Doolan P., Feldman N., Fredette A., Thomas R., "LDP + Specification", Work in Progress, October 1999. [3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., 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 - over ATM link", Work in Progress, April 1999. + over ATM link", Work in Progress, July 1999. - [5] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation - Layer 5", RFC 1483, July 1993 + [5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM + Adaptation Layer 5", RFC 2684, September 1999 15. Acknowledgments Significant contributions to this work have been made by Anthony Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan Littlewood and Dan Tappan. We thank Alex Conta for his comments. 16. Authors' Addresses Bruce Davie @@ -847,10 +872,31 @@ Chelmsford, MA, 01824 E-mail: erosen@cisco.com George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 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.