IETF Internet Draft Thomas D. Nadeau Proposed status: Informational Cisco Systems, Inc Expires: May 2007 Tomohiro Otani KDDI R&D Labs Deborah Brungard at&t Adrian Farrel Old Dog Consulting March 2007 OAM Requirements for GMPLS Networks draft-nadeau-ccamp-gmpls-oam-requirements-01.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 for Generalized Multi-Protocol Label Switching networks, as well as for applications of Generalized Multi-Protocol Label Switching. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................3 2. Terminology.....................................................3 2.1 Conventions used in this document..............................3 T. Nadeau, et al. 1 Internet Drafts March 2007 2.2 Terminology....................................................3 2.3 Acronyms.......................................................3 3. Motivations.....................................................4 4. General Requirements............................................4 5. Security consideration..........................................7 6. References......................................................7 6.1 Normative References...........................................7 6.2 Informative References.........................................7 7. Acknowledgment..................................................9 8. Author’s Address................................................9 9. Intellectual Property Statement.................................9 10. Copyright Statement...........................................10 T. Nadeau, et al. 2 Internet Drafts March 2007 1. Introduction This document describes requirements for data plane operations and management (OAM) for Generalized Multi-Protocol Label Switching (GMPLS) networks. This draft specifies OAM requirements for GMPLS networks, as well as for applications of GMPLS functions such as dynamic bandwidth broker applications. These requirements 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 Terminology Definitions of key terms for MPLS OAM and GMPLS are found in [RFC3945, RFC4377] and the reader is assumed to be familiar with those definitions which are not repeated here. The reader may be also familiar with at least the terminology section of the SONET/SDH and OTN architecture [G. 709, G.774]. 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 T. Nadeau, et al. 3 Internet Drafts March 2007 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. Early MPLS OAM documents developed specific solutions to individual issues or problems in deployment. Coordination of the full OAM requirements for MPLS was later achieved by [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 SONET/SDH/TDM 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. 4. General Requirements The general requirements described in this section are based on those described for point-to-point MPLS in [RFC4377]. 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. If the GMPLS control communications channel is out-of-band, the control plane SHOULD provide a health check (on-demand and continuous) on the connectivity of the control channel. This requirement is not limited to out-of-fiber control channels, but applies to both 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. T. Nadeau, et al. 4 Internet Drafts March 2007 4.2 Interaction between a management plane and a control plane 4.2.1 Signaling The information about an LSP (including session name, attributes, source/destination pair, and route) created by the control plane MUST be managed (or monitored) by the GMPLS management plane. For a TE link, LSPs associated with the TE link SHALL be individually monitored regarding their control plane operational status and notified to the management plane. The control plane SHALL 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 their primary route to their secondary route though the management plane. The change of recovery type of LSPs is required, for example, from unprotected to 1+1 protected LSP, or from full LSP rerouting to pre- planned LSP rerouting. Other capabilities include changing a recovery type of LSPs [RFC4426, Segment], recovery priorities (without impacting data plane operations), disabling/enabling reversion, forced switching to a different route and so forth. 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 TE information, especially bandwidth, GMPLS TE attributes, and the source/destination pair. This information is typically distributed by GMPLS TE extensions to the routing protocols and SHOULD be retrieved through MIBs. The Management plane SHALL provide the capability to verify routing consistency in the control plane with the data plane. 4.2.3 Link management Current status or status change of TE links MUST be notified to the management plane (for example, by SNMP notification). Link verification mechanisms using the data plane in SONET/SDH, OTN or DWDM and the control plane should be supported interactively without configuring each plane independently. 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, GMPLS recovery T. Nadeau, et al. 5 Internet Drafts March 2007 mechanisms) require the control plane to be aware of the data plane operational status. The operational state of one plane should be automatically reflected to that of another plane. 4.4 Detection of Label Switch Path Defects GMPLS introduces such a concept that the data plane and the control plane are decoupled. If the route of a LSP is traced in the control plane, the route information should include the linkage information of the utilized data plane. And then operators may check the validity of the data plane. The management plane may usually automate the correlation functionality between the data plane and the control plane. 4.5 Diagnosis of a Broken Label Switch Path In GMPLS networks, LMP [RFC 4204] and LMP-WDM [RFC 4209] are additionally defined to manage TE links including fault detection and fault isolation. Depending on the condition of the data plane, the status of TE links is usually reflected. The management plane will contain the TE links which are composed of a LSP and should indicate which TE link is failed or not. 4.6 Path characterization Path characterization function is the ability to indicate the detail of created LSPs. The additional information for GMPLS OAM should include GMPLS attributes of LSPs. 4.7 Service Level Agreement Measurement Various mechanisms in the data plane are available to measure the service level such as bit interleaved parity (BIP)-8 in SONET/SDH overhear, error counts in forward error correction (FEC) function in OTN interfaces, underneath of the control plane. Such information should be managed so as to linkage to the identical LSP. 4.8 Frequency of OAM Execution This is the same as MPLS OAM requirements. 4.9 Alarm Suppression, Aggregation and Layer Coordination Alarm suppression function is required for the link maintenance. The control plane must support to set the data plane not to generate alarms and invoke the recovery operation, for example, pulling the cable from the system. To avoid the stream of alarms, alarm aggregation may be implemented. Alarms of the main cause are prioritized and generated. 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 T. Nadeau, et al. 6 Internet Drafts March 2007 between control planes of different layers. For the operational convenience, 4.10 Support for OAM Interworking for Fault Notification MPLS OAM and GMPLS OAM should be effectively interworking, in MPLS- TE/GMPLS networks [MPLS/GMPLS]. The operator should configure the priority of the operation in each network. For example, in the case of a link failure, the GMPLS network will not notify the failure to the MPLS network in order to complete the recovery operation without affecting the MPLS network, otherwise the alarm should be transferred to the MPLS network by appropriately translating it. 4.11 Error Detection and Recovery Error detection and recovery should be applicable to not only a single domain network, but also an inter-domain network. Those operations should be automated by the control plane and the data plane. 4.12 Standard Management Interfaces For the purpose of widely deploying GMPLS networks, common interfaces for the control and the management of the GMPLS network are desired. Some GMPLS MIBs have been standardized [RFC4631, RFC4802, RFC4803]. Since only those MIBs cannot cover all OAM requirements here, additional MIBs should be developed [TED-MIB] as the deployment is going on. 4.13 Detection of Denial of Service Attacks This is the same as MPLS OAM requirements. 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 consideration This document introduces no new security issues beyond those detailed in the MPLS OAM requirements. 6. References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2 Informative References T. Nadeau, et al. 7 Internet Drafts March 2007 [RFC4377] T. Nadeau, et al., "OAM Requirements for MPLS Network" RFC4377, Feb. 2006. [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching Architecture", RFC3945, October, 2004. [G.709] "Interfaces for the optical transport network (OTN) ", ITU-T G.709, Feb., 2001. [G.784] " Synchronous Digital Hierarchy (SDH) management", ITU-T G.784, June, 1999. [RFC4726] A. Farrel, et al, "A framework for inter-domain MPLS traffic engineering", RFC4726, Nov., 2006. [RFC4426] J. Lang, "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC4426, March 2006. [Segment] L. Berger, "GMPLS Based Segment Recovery", draft- ietf-ccamp-gmpls-segment-recovery-03.txt, Oct. 2006. [MPLS/GMPLS] K. Kumaki, "Interworking Requirements to Support operation of MPLS-TE over GMPLS networks", draft- ietf-ccamp-mpls-gmpls-interwork-reqts-00.txt, Dec., 2006. [RFC4204] J. P. Lang, "Link Management Protocol(LMP)", RFC4204, Oct. 2005. [RFC4209] A. Fredette, "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", RFC4209, Oct., 2005. [RFC4631] M. Dubuc, et al, "Link Management Protocol (LMP) Management Information Base (MIB)", RFC4631, Sept., 2006. [RFC4802] T. Nadeau, et al, "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC4802, Feb., 2007. [RFC4803] T. Nadeau, et al, "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC4803, Feb., 2007. [TED-MIB] M. Miyazawa, "Traffic Engineering Database Management Information Base in support of GMPLS", draft-ietf- ccamp-gmpls-ted-mib-00.txt, Nov., 2006. [RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing an IANA Considerations Section in RFCs" BCP 26, RFC 2434, October 1998. T. Nadeau, et al. 8 Internet Drafts March 2007 7. Acknowledgment The authors wish to acknowledge and thank Masanori Miyazawa for his valuable comments to this document. 8. Author's Address Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Phone: +81-49-278-7357 Saitama, 356-8502. Japan Email: otani@kddilabs.jp Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Road Phone: +1-978-936-1470 Boxboro, MA 01719 Email: tnadeau@cisco.com300 Deborah Brungard (AT&T) Rm. D1-3C22-200 S. Laurel Ave. Phone: +1-732-420-1573 Middletown, NJ 07748, USA Email: dbrungard@att.com Adrian Farrel Old Dog Consulting Phone: (0) 1978 860944 Email: adrian@olddog.co.uk 9. 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. 9 Internet Drafts March 2007 10. 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. 10