Network Working Group Thomas D. Nadeau Expires: January 2006 Cisco Systems, Inc. Tomohiro Otani KDDI R&D Laboratories, Inc. Deborah Brungard AT&T Adrian Farrel Old Dog Consulting July 2005 OAM Requirements for GMPLS Networks draft-nadeau-ccamp-gmpls-oam-requirements-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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes requirements for operations and management for Generalized Multi-Protocol Label Switching networks, as well as for applications of Generalized Multi-Protocol Label Switching. Table of Contents Nadeau et al. Expires January 31, 2006 [Page 1] Internet Draft GMPLS OAM Requirements July 4, 2005 1. Introduction............................................... 2. Terminology................................................ 2.1 Conventions................................................ 2.2 Terminology................................................ 2.3 Acronyms................................................... 3. Motivations................................................ 4. General Requirements....................................... 4.1 Detection of Label Switch Path Defects...................... 4.2 Diagnosis of a Broken Label Switch Path..................... 4.3 Path characterization....................................... 4.4 Service Level Agreement Measurement......................... 4.5 Frequency of OAM Execution.................................. 4.6 Alarm Suppression, Aggregation and Layer Coordination....... 4.7 Support for OAM Interworking for Fault Notification......... 4.8 Error Detection and Recovery................................ 4.9 Standard Management Interfaces.............................. 4.10 Detection of Denial of Service Attacks.................... 4.11 Per-LSP Accounting Requirements............................ 5. Security Considerations.................................... 6. IANA Considerations........................................ 7. References................................................. 7.1 Normative References....................................... 7.2 Informative References..................................... 8. Acknowledgements........................................... 9. Authors' Addresses......................................... 10. Intellectual Property Statement............................ 11. Full Copyright Statement.................................... 1. Introductions This document describes requirements for user and data plane operations and management (OAM) for Generalized Multi-Protocol Label Switching (GMPLS). This draft specifies OAM requirements for GMPLS, as well as for applications of GMPLS such as dynamic bandwidth broker applications, for example. These requirements apply to all forms of GMPLS LSPs. Note that the requirements for OAM for GMPLS is built on the foundation requirements for OAM for MPLS [MPLS-OAM], as well as the optical networks that GMPLS LSPs are built upon. These existing requirements are not repeated in this document except to illustrate new requirements. 2. Terminology 2.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Nadeau et al. Expires January 31, 2006 [Page 2] Internet Draft GMPLS OAM Requirements July 4, 2005 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2 Terminology Definitions of key terms for MPLS OAM are found in [MPLS-OAM] and the reader is assumed to be familiar with those definitions which are not repeated here. TBD: include references to SONET/SDH OAM here. The reader should be familiar with at least the terminology section of that document. The following additional terms are useful to understand this document. 2.3 Acronyms The following list of acronyms is a repeat of common acronyms defined in many other documents, and is provided here for convenience. GMPLS: Generalized Multi-Protocol Label Switching CE: Customer Edge DoS: Denial of service ECMP: Equal Cost Multipath LDP: Label Distribution Protocol LSP: Label Switching Path LSR: Label Switching Router OAM: Operations and Management OA&M: Operations, Administration and Maintenance. RSVP: Resource reSerVation Protocol SP: Service Provider TE: Traffic Engineering SONET: Synchronous Optical Network SDH: Synchronous Digital Hierarchy TDM: Time Division Multiplexing 3. Motivations OAM for MPLS networks has been established as a fundamental requirement both through operational experience and through its documentation in numerous Internet drafts. Many such documents developed specific solutions to individual issues or problems. Coordination of the full OAM requirements for MPLS was achieved by [MPLS-OAM] [RFC3609] in recognition of the fact that the previous piecemeal approach could lead to inconsistent and inefficient applicability of OAM techniques across the MPLS architecture, and might require significant modifications to Nadeau et al. Expires January 31, 2006 [Page 3] Internet Draft GMPLS OAM Requirements July 4, 2005 operational procedures and systems in order to provide consistent and useful OAM functionality. Similarly, operational requirements for OAM have been established for SONET/SDH/TDM networks. However, no such requirements exist for GMPLS networks which combine MPLS control plane protocols with underlying SONET/SDH/TDM data planes. However, no specific requirements exist for GMPLS networks. Since GMPLs configurations pose some unique configurations and problems for OAM not covered by existing requirements or solutions documents, this document will document the requirements that fit into this gap. 4. General Requirements The general requirements described in this section are closely similar to those described for point-to-point MPLS in [MPLS-OAM]. The subsections below do not repeat material from [MPLS-OAM], but simply give references to that document. However, where the requirements for P2MP MPLS OAM differ from or are ## I think I know where you stole this text from! more extensive than those expressed in [MPLS-OAM], additional text is supplied. 4.1 Control Plane The GMPLS control plane needs to provide a health check function. If the GMPLS control channel is out-of-band the control plane needs to provide a health check on the connectivity of the control channel. This requirement is not limited to out-of-fiber control channels, but applies to any out-of-band mechanism. If multiple control channels exist between two LSRs, the health check needs to be applied to each control channel. These functions should be independent of the underlying technology of the control plane. 4.2 Interaction between a management plane and a control plane 4.2.1 signaling The information of a LSP (including session name, attributes and source/destination pair, route (ERO/RRO)) created by the control plane must be managed (or monitored) by the GMPLS management plane. By specifying a TE link, LSPs containing the TE link should be extracted and notified to the management plane. Selected LSPs must be manually switched from the primary route to the Nadeau et al. Expires January 31, 2006 [Page 4] Internet Draft GMPLS OAM Requirements July 4, 2005 secondary route though the management plane. NOTE: TBD: describe differences in protection techniques 4.2.2 Routing Routing information exchanged by the control plane must be managed (or monitored) by GMPLS management plane. Such information should contain GMPLS OSPF-TE information, especially bandwidth, GMPLS TE attributes and a source/destination pair. Management plane must verify routing consistency in the control plane as well as the data plane. NOTE: TBD: describe differences in management requirements. 4.2.3 Link management Current status or status change of TE links must be notified to the management plane (ex. by MIB trap.) 4.3 Interaction Between The Control Plane and The Data Plane. The GMPLS control plane supports operational separation from the data plane. Various applications (e.g. ASON Call support, GMPLS recovery mechanisms) require the control plane to be aware of the data plane operational status. ED Note: To be further expanded after WG discussions. 5. Security Considerations This document introduces no new security issues as it only provides requirements. NOTE TBD: Must cover security requirements. 6. IANA Considerations This document creates no new requirements on IANA namespaces. 7. References 7.1 Normative References 7.2 Informative References [G.8080] ITU Recommendation G.8080. Nadeau et al. Expires January 31, 2006 [Page 5] Internet Draft GMPLS OAM Requirements July 4, 2005 [RFC3945] Mannie, E., et al, "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC3945, October 2004. [RFC3609] Bonica, R., Kompella, K., Meyer, D., "Tracing Requirements for Generic Tunnels", RFC3609, September 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MPLS-OAM] T. Nadeau, Allan D., et al. Allan D., "OAM Requirements for MPLS Networks", draft-ietf-mpls-oam-requirements-05.txt, December 2004 8. Acknowledgment The authors wish to acknowledge and thank the following individuals for their valuable comments to this document: 9. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719 Phone: +1-978-936-1470 Email: tnadeau@cisco.com Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Saitama, 356-8502. Japan Phone: +81-49-278-7357 Email: otani@kddilabs.jp Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 4201573 EMail: dbrungard@att.com Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 Email: adrian@olddog.co.uk Nadeau et al. Expires January 31, 2006 [Page 6] Internet Draft GMPLS OAM Requirements July 4, 2005 10. 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. 11. Full Copyright Statement Copyright (C) The Internet Society (2005). 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 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. Nadeau et al. Expires January 31, 2006 [Page 7]