Network Working Group M.Bocci Internet Draft M.Vigoureux M.Lasserre L.Levrau I.Busi Alcatel-Lucent D.Ward S.Bryant Cisco Intended status: Proposed Standard June 20, 2008 Expires: December 2008 MPLS Generic Associated Channel draft-bocci-pwe3-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 Bocci et al Expires December 20, 2008 [Page 1] Internet-Draft Generic Associated Channel Header June 2008 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 20, 2008. Copyright Notice 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................................................3 1.1. Objectives.............................................3 1.2. Scope..................................................3 1.3. 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 Disclaimer of Validity.........................................8 Bocci et al Expires December 20, 2008 [Page 2] Internet-Draft Generic Associated Channel Header June 2008 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] or LSP- Ping [7]. However, a requirement has been indicated to extend these toolsets, in particular where MPLS networks are used for 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. 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.2. 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. Bocci et al Expires December 20, 2008 [Page 3] Internet-Draft Generic Associated Channel Header June 2008 This draft does not deprecate existing MPLS and PW OAM mechanisms. 1.3. 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. 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 20, 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 congestion 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 20, 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 and George Swallow. 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 20, 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-oam-requirements-mpls- transport-00.txt,April 2008 [7] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006 Author's Addresses Matthew Bocci Alcatel-Lucent Voyager Place, Maidenhead, Berks, UK Phone: +44 1633 413600 Email: matthew.bocci@alcatel-lucent.co.uk Marc Lasserre Alcatel-Lucent Email: mlaserre@alcatel-lucent.com Martin Vigoureux Alcatel-Lucent Email: martin.vigoureux@alcatel-lucent.fr Lieven Levrau Alcatel-Lucent Email: llevrau@alcatel-lucent.com David Ward Cisco 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 Email: dward@cisco.com Bocci et al Expires December 20, 2008 [Page 7] Internet-Draft Generic Associated Channel Header June 2008 Stewart Bryant Cisco stbryant@cisco.com 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. 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. Disclaimer of Validity 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. 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. Bocci et al Expires December 20, 2008 [Page 8] Internet-Draft Generic Associated Channel Header June 2008 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bocci et al Expires December 20, 2008 [Page 9]