Network Working Group M.Bocci, (Ed.) Internet Draft Alcatel-Lucent D.Ward, (Ed.) Cisco Intended status: Proposed Standard June 26, 2008 Expires: December 2008 MPLS Generic Associated Channel draft-bocci-pwe3-mpls-tp-ge-ach-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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 This Internet-Draft will expire on December 26, 2008. Copyright Notice Bocci et al Expires December 26, 2008 [Page 1] Internet-Draft Generic Associated Channel Header June 2008 Copyright (C) The IETF Trust (2008). Abstract This draft describes a generic associated channel header (GE-ACH) that provides a control channel associated with an MPLS LSP, pseudowire or MPLS section. The VCCV ACH defined for PWs in RFC 5085 is generalized to allow a larger set of control channel and OAM functions to be used to meet the requirements of packet transport and other applications of MPLS. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Introduction................................................2 1.1. Contributing Authors....................................3 1.2. Objectives.............................................3 1.3. Scope..................................................3 1.4. Terminology............................................4 2. Generic Associated Channel...................................4 2.1. Generic Associated Channel Header.......................4 3. Congestion Considerations....................................5 4. Security Considerations......................................5 5. IANA Considerations.........................................5 6. Acknowledgments.............................................6 7. References..................................................6 7.1. Normative References....................................6 7.2. Informative References..................................7 Author's Addresses.............................................7 Intellectual Property Statement.................................8 1. Introduction There is a need for Operations and Maintenance (OAM) mechanisms that can be used for edge-to-edge (i.e. between originating and terminating LSRs or T-PEs) and segment fault detection (e.g. between any two LSRs or S-PEs along the path of an LSP or PW), diagnostics, maintenance and other functions for a Pseudowire and an LSP. Some of these functions can be supported using tools such as VCCV [3], BFD [8], or LSP-Ping [7]. However, a requirement has been indicated to extend these toolsets, in particular where MPLS networks are used for Bocci et al Expires December 26, 2008 [Page 2] Internet-Draft Generic Associated Channel Header June 2008 packet transport services and network operations [6]. These include performance monitoring, automatic protection switching, and support for management and signaling communication channels. These tools must be applicable to, and function in essentially the same manner (from an operational point of view) on both MPLS PWs and MPLS LSPs. They must also operate in-band on the PW or LSP such that they do not depend on PSN routing, user data traffic or ultimately on control plane functions. Virtual Circuit Connectivity Verification (VCCV) can use an associated channel to provide a control channel between a PW's ingress and egress points over which OAM and other control messages can be exchanged. In this draft, we propose a generic associated channel header (GE-ACH) to enable the same control channel mechanism be used for MPLS Sections, LSPs and PWs. The associated channel header (ACH) specified in RFC 4385 [2] is used with additional code points to support additional MPLS OAM functions. 1.1. Contributing Authors The editors gratefully acknowledge the following additional contributors: Stewart Bryant, Italo Busi, Marc Lasserre, Lieven Levrau, and Martin Vigoureux. 1.2. Objectives This draft proposes a mechanism to provide for the OAM needs of transport applications. It creates a generic OAM identification mechanism that may be applied to all MPLS LSPs, while maintaining compatibility with the PW associated channel header (ACH) [2]. It also normalizes the use of the ACH for PWs in a transport context. 1.3. Scope This draft defines the encapsulation header for LSP, MPLS Section and PW associated channel messages. It does not define how associated channel capabilities are signaled or negotiated between LSRs or PEs, the operation of various OAM functions, or the messages transmitted on the associated channel. This draft does not deprecate existing MPLS and PW OAM mechanisms. Bocci et al Expires December 26, 2008 [Page 3] Internet-Draft Generic Associated Channel Header June 2008 1.4. Terminology ACH: Associated Channel Header MPLS Section: A Section is a network segment between two LSRs that are immediately adjacent. 2. Generic Associated Channel VCCV [3] defines three control channel types that may be used to multiplex OAM messages onto a PW. CC type 1, uses an associated channel header and is referred to as "In-band VCCV", CC type 2 which uses the router alert label to indicate VCCV packets and is referred to as "Out of Band VCCV", and CC type 3 that uses the TTL to force the packet to be processed by the destination routers control plane (known as "MPLS PW Label with TTL == 1"). This draft proposes that in transport applications only the type 1 (associated channel header) mechanism is used for LSP OAM and for PW OAM. In transport applications a static or traffic engineered LSP is normally used, thus the data and the OAM will follow the same path. This does not preclude the use of the GE-ACH mechanism described in this draft for other applications of MPLS. Note that VCCV also includes mechanisms for negotiating the control channel and connectivity verification (i.e. OAM tool) types between PEs. These mechanisms need to be extended when a generic associated channel is used for MPLS LSP OAM. This will most likely require extensions to label distribution protocols and is outside the scope of this document. This section defines a generic associated channel header (GE-ACH) that identifies packets on the associated channel. 2.1. Generic Associated Channel Header The format of the GE-ACH for LSP, Section and PW associated channel traffic is shown in Figure 1: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Generic Associated Channel Header Bocci et al Expires December 26, 2008 [Page 4] Internet-Draft Generic Associated Channel Header June 2008 The first nibble is set to 0001b to indicate a channel associated with a PW or LSP. The Version and Reserved fields are set to 0, as specified in RFC 4385 [2]. Values for the channel type used for VCCV are specified in RFC 4446 [4]. This draft specifies the following additional channel types: 0xXX - for OAM functions 0xYY - for APS functions 0xKK - for Management Communications Channel (MCC) functions 0xZZ - for Signaling Communications Channel (SCC) functions The functionality of these channel types will be defined elsewhere. 3. Congestion Considerations The congestion considerations detailed in RFC 5085 [1] apply. Further generic associated channel-specific congestion considerations will be detailed in a future revision of this draft. 4. Security Considerations The security considerations detailed in RFC 5085 [1] apply. Further generic associated channel-specific security considerations will be detailed in a future revision of this draft. 5. IANA Considerations This draft requests that code points for the following GE-ACH channel types be allocated from the IANA PW Associated Channel Type registry [4]: 0xXX - for OAM functions 0xYY - for APS functions 0xKK - for Management Communications Channel (MCC) functions 0xZZ - for Signaling Communications Channel (SCC) functions Bocci et al Expires December 26, 2008 [Page 5] Internet-Draft Generic Associated Channel Header June 2008 The PW Associated Channel Type registry is currently allocated based on the IETF consensus process, described in [5]. This allocation process was chosen based on the consensus reached in the PWE3 working group that pseudowire associated channel mechanisms should be reviewed by the IETF and only those that are consistent with the PWE3 architecture and requirements should be allocated a code point. However, a requirement has emerged to allow for vendor-specific optimizations or extensions to OAM and other control protocols running in an associated channel, by supporting vendor specific code points [6]. This would prevent code points used for such functions from being allocated through the IETF standards process in future. Vendor specific code point space thus protects an installed base of equipment from potential inadvertent overloading of code points. Each draft specifying ACH protocols must provide a solution for supporting vendor-specific types, in accordance with [6], in addition to those allocated by IETF consensus. The details of these solutions are outside the scope of this draft. 6. Acknowledgments The authors gratefully acknowledge the input of Lou Berger, George Swallow and Rahul Aggarwal. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] S. Bryant et al., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006 [3] Nadeau, T. & Pignataro, S., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007 [4] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", RFC 4446, April 2006 [5] Narten, T., Alvestrand, H., " Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998 Bocci et al Expires December 26, 2008 [Page 6] Internet-Draft Generic Associated Channel Header June 2008 7.2. Informative References [6] M. Vigoureux et al., "Requirements for OAM in MPLS Transport Networks", draft-vigoureux-mpls-tp-oam-requirements-00.txt, June 2008 [7] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006 [8] R. Aggarwal et al, "BFD for MPLS LSPs", draft-ietf-bfd-mpls- 07.txt, June 2008 Author's Addresses Matthew Bocci, (Ed.) Alcatel-Lucent Voyager Place, Maidenhead, Berks, UK Phone: +44 1633 413600 Email: matthew.bocci@alcatel-lucent.co.uk David Ward, (Ed.) Cisco 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 Email: dward@cisco.com Stewart Bryant Cisco 250, Longwater, Green Park, Reading, RG2 6GB, United Kingdom. Email: stbryant@cisco.com Bocci et al Expires December 26, 2008 [Page 7] Internet-Draft Generic Associated Channel Header June 2008 Italo Busi, Alcatel-Lucent VIA TRENTO 30, 20059 VIMERCATE ITALY Email: italo.busi@alcatel-lucent.it Marc Lasserre Alcatel-Lucent 16 Avenue Descartes, 92352 LE PLESSIS ROBINSON CEDE, France Email: mlaserre@alcatel-lucent.com Lieven Levrau Alcatel-Lucent 7-9, Avenue Morane, Saulnier BP 57 78141, VELIZY, France Email: llevrau@alcatel-lucent.com Martin Vigoureux Alcatel-Lucent Centre De Villarceaux, France Email: martin.vigoureux@alcatel-lucent.fr Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Bocci et al Expires December 26, 2008 [Page 8] Internet-Draft Generic Associated Channel Header June 2008 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bocci et al Expires December 26, 2008 [Page 9]