Network Working Group T. Nadeau INTERNET-DRAFT BT Intended Status: Informational T. Otani Created: October 22, 2007 KDDI R&D Labs Expires: April 22, 2008 D. Brungard at&t A. Farrel Old Dog Consulting OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks draft-ietf-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/ietf/1id-abstracts.txt 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 (OAM) for Generalized Multi-Protocol Label Switching (GMPLS) networks, as well as for applications of GMPLS. T. Nadeau, et al. [Page 1] draft-ietf-ccamp-gmpls-oam-requirements October 2007 Table of Contents 1. Introduction .................................................. 3 2. Terminology ................................................... 3 2.1 Conventions Used in this Document ............................ 3 2.2 Key Terms .................................................... 3 2.3 Acronyms ..................................................... 3 3. Motivations ................................................... 4 4. General Requirements .......................................... 4 4.1 GMPLS Control Plane and Communications Channel ............... 7 4.2 Interaction Between the Management and Control Planes ........ 7 4.2.1 Signaling .................................................. 7 4.2.2 Routing .................................................... 7 4.2.3 Link Management ............................................ 9 4.3 Interaction Between the GMPLS Control Plane and Data Plane ... 9 4.4 Detection of Label Switch Path Defects ....................... 9 4.5 Diagnosis of a Broken Label Switch Path ..................... 10 4.6 Path Characterization ....................................... 4.7 Service Level Agreement Measurement ......................... 4.8 Frequency of OAM Execution .................................. 4.9 Alarm Suppression, Aggregation, and Layer Coordination ...... 4.10 Support for OAM Interworking for Fault Notification ........ 4.11 Error Detection and Recovery ............................... 4.12 Standard Management Interfaces ............................. 4.13 Detection of Denial of Service Attacks .................... 4.14 Per-LSP Accounting Requirements ............................ 5. Security Consideration ....................................... 6. IANA Considerations .......................................... 7. References ................................................... 7.1 Normative References ........................................ 7.2 Informative References ...................................... 8. Acknowledgments .............................................. 9. Author's Address ............................................. 10. Intellectual Property Statement ............................. 11. Copyright Statement ......................................... T. Nadeau, et al. [Page 2] draft-ietf-ccamp-gmpls-oam-requirements October 2007 1. Introduction This document describes requirements for control plane operations and management (OAM) for Generalized Multi-Protocol Label Switching (GMPLS) networks. It also describes OAM requirements associated with the interaction between the GMPLS Control Plane and Data Plane OAM. The OAM requirements specified in this document apply to GMPLS networks as well as to applications of GMPLS functions such as dynamic bandwidth broker applications. [RFC3945] describes how GMPLS extends Multi-Protocol Label Switching (MPLS) to support a variety of data plane technologies. The requirements set out in this document apply to all forms of GMPLS LSPs. Note that the requirements for OAM for GMPLS networks are built on the foundation requirements for OAM for MPLS networks [RFC4377], as well as the existing OAM techniques available in non-packet networks that may be controlled by GMPLS. These existing requirements are not repeated in this document except to illustrate new requirements. 2. Terminology 2.1 Conventions Used in this Document Although this is not a protocol specification, 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 [RFC2119] for clarity of presentation of requirements. 2.2 Key Terms Definitions of key terms for MPLS OAM and GMPLS are found in [RFC3945] and [RFC4377], and the reader is assumed to be familiar with those definitions which are not repeated here. The reader may also find it helpful to be familiar with at least the terminology sections of the SONET/SDH and OTN architectures [G.709] and [G.784]. T. Nadeau, et al. [Page 3] draft-ietf-ccamp-gmpls-oam-requirements October 2007 2.3 Acronyms GMPLS: Generalized Multi-Protocol Label Switching CE: Customer Edge DoS: Denial of Service ECMP: Equal Cost Multipath LDP: Label Distribution Protocol LSP: Label Switched 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 Requests For Comment. Early MPLS OAM documents developed specific solutions to individual issues or to problems encountered in MPLS deployments. Coordination of the full OAM requirements for MPLS was achieved in [RFC4377] and [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 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 requirements documents exist for GMPLS networks which provide a comprehensive set of OAM requirements which take into consideration both the GMPLS control plane protocols and the underlying data planes. Since GMPLS networks pose some unique configurations and problems for OAM not covered by existing requirements or solutions documents, this document sets out the requirements that need to be satisfied to fill this gap. T. Nadeau, et al. [Page 4] draft-ietf-ccamp-gmpls-oam-requirements October 2007 4. General Requirements The general requirements described in this section are inspired by those described for point-to-point MPLS in [RFC4377], and where the GMPLS network is a packet network it is expected that the solutions will be identical or very similar. The subsections below do not repeat material from [RFC4377], but simply give references to that document. However, where the requirements for GMPLS OAM differ from or are more extensive than those expressed in [RFC4377], additional text is supplied. Moreover, these requirements should be commonly applied to not only a single domain network but also an inter-domain network [RFC4726]. 4.1 GMPLS Control Plane and Communications Channel The GMPLS control plane SHOULD provide a health check function between GMPLS control entities. The control plane MUST provide a health check on the connectivity of the control channel, and this SHOULD be configurable for both on- demand operation and continual monitoring. This requirement applies both to in-band and out-of-band control channel support. If multiple control channels exist between two LSRs, the health check SHOULD be supported for each control channel. These functions MUST be independent of the underlying technology of the control plane or data plane. 4.2 Interaction Between the Management and Control Planes 4.2.1 Signaling It MUST be possible to monitor and manage the information about an LSP (including session name, attributes, source/destination pair, and route) created by the GMPLS control plane. Such management SHOULD be provided through MIB modules. It SHOULD be possible to monitor and distinguish the LSPs traversing any TE link in the network. In the event of any data plane event that affects any TE link, it MUST be possible for the management plane to correlate the data plane faults to the individual control plane LSPs. The control plane MUST allow the management plane administrative privileges, e.g., changing the operational status of an LSP for pre- planned maintenance and recovery-related operations. To support a pre-planned maintenance activity or during a control plane failure, it SHOULD be possible for selected LSPs to be manually switched from T. Nadeau, et al. [Page 5] draft-ietf-ccamp-gmpls-oam-requirements October 2007 their primary route to their secondary route though the management plane. The management plane SHOULD have the ability to change the recovery type of active LSPs (for example, from unprotected to 1+1 protected, or from full LSP rerouting to pre-planned LSP rerouting) without disrupting traffic on the LSPs. It SHOULD also be possible for the management plane to change other properties of LSPs without impacting data plane operations. These properties include, but are not limited to: - LSP recovery type - recovery priorities - reversion support - TBD List to be completed The management plane SHOULD provide a mechanism to force the switch- over to a different route or to a rcovery LSP. 4.2.2 Routing It MUST be possible to manage and monitor the GMPLS routing information exchanged in the control plane and to manage and monitor the process by which the informaiton is exchanged. Such management SHOULD be provided through MIB modules. Management SHOULD have access to at least the following GMPLS properties of TE links: - bandwidth - switching type - source/destination address pair Mechanisms SHOULD be provided in the management plane to verify the consistency of the connectivity information distributed by routing mechanisms in the control plane with the physical connectivity in the data plane. 4.2.3 Link Management The management plane MUST be able to monitor and manage the status of TE links, and status changes of TE links MUST be notified to the management plane. This SHOULD be provided through MIB modules. Link verification mechanisms using the data plane and the control plane should be supported interactively without configuring each plane independently. T. Nadeau, et al. [Page 6] draft-ietf-ccamp-gmpls-oam-requirements October 2007 4.3 Interaction Between the GMPLS Control Plane and Data Plane The GMPLS control plane supports operational separation from the data plane. Various applications (e.g., ASON Call support [RFC4974], and GMPLS recovery mechanisms [RFC4872], [RFC4873]) require the control plane to be aware of the data plane operational status. The operational state of the data plane SHOULD be automatically reported to the control plane. On the other hand, the operational state of the GMPLS control plane MUST NOT impact the operaitonal state of the data plane. 4.4 Detection of Label Switch Path Defects GMPLS decouples the data plane and the control plane. If the route of an LSP is traced in the control plane, the route information SHOULD include information about the data plane resources utilized by the LSP so that an operator can check the validity of the data plane by examining the data plane state directly. Mechanisms MAY be provided to automate this correlation functionality. 4.5 Diagnosis of a Broken Label Switch Path LMP [RFC4204] and LMP-WDM [RFC4209] are defined for use in GMPLS networks manage TE links. The functions provided include fault detection and fault isolation. The management plane SHOULD be able to access this informaiton to make correlations between broken data links and the implied status of both the TE links that the data links support and the LSPs that traverse the data links. Additionally, LSPs may be used as data links to support TE links [RFC4206]. In this case, the management plane SHOULD be able to access LSP status information to make correlations between failed LSPs and the TE links that the LSPs support. 4.6 Path Characterization Path characterization function is the ability to indicate the detail of created LSPs. The control plane MUST provide mechanisms to gather path characterization information. The informaiton collected by the control plane MUST be accessible to the management plane, and this access SHOULD be through a MIB module. T. Nadeau, et al. [Page 7] draft-ietf-ccamp-gmpls-oam-requirements October 2007 4.7 Service Level Agreement Measurement Existing data planes already provide various mechanisms to measure the level of service being provided. These mechanisms are technology- specific and include bit interleaved parity (BIP)-8 in SONET/SDH overhead, and error counts in forward error correction (FEC) function on OTN interfaces. These mechanisms operate distinct from the control plane. Mechanisms MUST be provided in the management to control the use of these mechanisms and to gather the recorded information. It MUST be possible to correlate the infromation gathered to the LSPs and the services that the LSPs support. Mechanisms MAY be provided thrugh the control plane to control the use of these mechanisms and to distribute the information recorded. 4.8 Frequency of OAM Execution This requirement is the same as for the MPLS OAM requirements. See [RFC4377] section 4.5. 4.9 Alarm Suppression, Aggregation, and Layer Coordination Alarm suppression function is required for in order to support link maintenance. The GMPLS control plane MUST provide the ability to control whether data plane components on the path of an LSP do or do not generate alarms in the case of data plane faults. To avoid a stream of alarms, alarm aggregation may be implemented by LSRs and this may be achieved by determining the main cause and by prioritizing the alarms. This function MAY be managed through the control plane for data plane components on the path of an LSP. Considering multi-layer GMPLS networks, such as a TDM switch capable network over a lambda switch capable network, the generated alarms MAY be correlated between layers by using the linkage information between control planes of different layers. 4.10 Support for OAM Interworking for Fault Notification MPLS OAM and GMPLS OAM SHOULD be interwork to support the operation of an MPLS-TE network over a GMPLS network [MPLS/GMPLS]. The operator SHOULD be able to control OAM function separately in each network, but SHOULD be able to coordinate the OAM funciton. For example, in the case of a data link failure in the GMPLS network, the it SHOULD be possible to configure the GMPLS OAM to apply priorities to the following actions: T. Nadeau, et al. [Page 8] draft-ietf-ccamp-gmpls-oam-requirements October 2007 - report the data link failure to the management plane of the GMPLS network - report the data link failure to the management plane of the MPLS network - trigger recovery operations within the GMPLS network - trigger recovery operations within the MPLS network 4.11 Error Detection and Recovery Error detection and recovery SHOULD be applicable not only to a single domain network, but also an inter-domain network. Those operations SHOULD be automated through the control plane and the data plane. 4.12 Standard Management Interfaces Common interfaces for the control and the management of the GMPLS network are desired to facilitate wide deployment GMPLS networks. Some GMPLS MIB modules have been standardized in [RFC4631], [RFC4802], and [RFC4803] building on [RFC3811], [RFC3812], and [RFC3813]. [RFC4220] provides a MIB module for managing and monitoring TE links. Since only those MIB modules do not cover all the OAM requirements set out in this document, additional MIB modules SHOULD be developed such as [TED-MIB]. 4.13 Detection of Denial of Service Attacks This requirement is the same as for the MPLS OAM requirements. See [RFC4377] section 4.10. 4.14 Per-LSP Accounting Requirements A GMPLS LSP may support MPLS LSPs hierarchically. By pointing out the GMPLS LSP, those MPLS LSPs over it SHOULD be managed and accounted. 5. Security Considerations This document introduces no new security issues beyond those detailed in the MPLS OAM requirements. See [RFC4377] section 5. 6. IANA Considerations This informational document makes no requests for IANA action. T. Nadeau, et al. [Page 9] draft-ietf-ccamp-gmpls-oam-requirements October 2007 7. References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching Architecture", RFC 3945, October, 2004. [RFC4377] T. Nadeau, et al., "OAM Requirements for MPLS Network" RFC 4377, February 2006. 7.2 Informative References [RFC3609] Bonica, R., Kompella, K., and Meyer, D., "Tracing Requirements for Generic Tunnels", RFC 3609, September 2003. [RFC3811] Nadeau, T., and Cucchiara, J., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3812] Srinivasan, C., Viswanathan, A., and Nadeau, T., "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. [RFC3813] Srinivasan, C., Viswanathan, A., and Nadeau, T., "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. [RFC4204] J. P. Lang, "Link Management Protocol(LMP)", RFC4204, October 2005. [RFC4206] Kompella, K. and Rekhter, Y., "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC4209] A. Fredette, "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", RFC4209, October 2005. [RFC4220] Dubuc, M., Nadeau, T., and Lang, J., "Traffic Engineering Link Management Information Base", RFC 4220, November 2005. T. Nadeau, et al. [Page 10] draft-ietf-ccamp-gmpls-oam-requirements October 2007 [RFC4631] M. Dubuc, et al, "Link Management Protocol (LMP) Management Information Base (MIB)", RFC4631, September 2006. [RFC4726] A. Farrel, et al, "A Framework for Inter-Domain MPLS Traffic Engineering", RFC4726, November 2006. [RFC4802] T. Nadeau, et al, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC4802, February 2007. [RFC4803] T. Nadeau, et al, "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC4803, Feb., 2007. [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] L. Berger, "GMPLS Based Segment Recovery", RFC 4873, May 2007. [RFC4974] Papadimitriou, D. and Farrel, A., "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007. [G.709] "Interfaces for the optical transport network (OTN)", ITU-T G.709, February 2001. [G.784] "Synchronous Digital Hierarchy (SDH) management", ITU-T G.784, June 1999. [MPLS/GMPLS] K. Kumaki, "Interworking Requirements to Support operation of MPLS-TE over GMPLS networks", draft-ietf- ccamp-mpls-gmpls-interwork-reqts, work in progress. [TED-MIB] Miyazawa, M., Otani, T., Nadeaud, T., and Kumaki, K., "Traffic Engineering Database Management Information Base in support of GMPLS", draft-ietf-ccamp-gmpls-ted- mib, work in progress. 8. Acknowledgments The authors wish to acknowledge and thank Masanori Miyazawa, Don O'Connor, and Tom Petch for their valuable comments on this document. T. Nadeau, et al. [Page 11] draft-ietf-ccamp-gmpls-oam-requirements October 2007 9. Author's Address Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama, 356-8502. Japan Phone: +81-49-278-7357 Email: otani@kddilabs.jp Thomas D. Nadeau British Telecom BT Centre 81 Newgate Street EC1A 7AJ London Email: tom.nadeau@bt.com Deborah Brungard (AT&T) Rm. D1-3C22-200 S. Laurel Ave. Middletown, NJ 07748, USA Email: dbrungard@att.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk 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. T. Nadeau, et al. [Page 12] draft-ietf-ccamp-gmpls-oam-requirements October 2007 11. Copyright Statement Copyright (C) The IETF Trust (2007). 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. T. Nadeau, et al. [Page 13]