Network Working Group Thomas D. Nadeau Internet Draft Monique Morrow Expires: April 2003 George Swallow Cisco Systems, Inc. October 2002 IP-based Tool Requirements for MPLS Networks draft-nadeau-ip-basedtool-requirements-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. 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 memo describes requirements for operations and management (OAM) based on IP-based tools for Multi-Protocol Label Switching (MPLS) [RFC3031] networks. As customers gain deployment experience with MPLS, managing these networks and services becomes pivotal to the service provider business. Minimal requirements include the ability to detect a break in the LSP data path and trace the source of the failure. Therefore, maintaining core integrity is key in identifying requirements for MPLS OAM. The document scope is IP-based tool requirement capture for fault detection, diagnostics, and statistic reporting and security management. 1. Introduction Nadeau et al. Expires April 2003 [Page 1] Internet Draft IP-based Tools Requirements October 28, 2002 This document identifies a set of OAM requirements gathered from network operators in various workshops by the authors of this document. No specific mechanisms are proposed to address these requirements at this time. Comments should be made directly to the MPLS mailing list at mpls@uu.net. This memo does not, in its draft form, specify a standard for the Internet community. 2. Terminology This document uses terminology from the MPLS architecture document [MPLSArch], CCAMP Architecture [CCAMPArch] and various MPLS-related MIBs such as the MPLS-TC-MIB [TCMIB], MPLS-LSR-MIB [LSRMIB], MPLS-TE-MIB [TEMIB], MPLS-LDP-MIB [LDPMIB], MPLS-FTN-MIB [FTNMIB], and the MPLS-LINK-BUNDLING- MIB [LBMIB]. Defect: Any error condition that prevents an LSR from functioning correctly. For example, loss of an IGP path will most likely also result in an LSP not being able to deliver traffic to its destination. Another example is the breakage of a TE tunnel. These may be due to physical circuit failures or failure of switching nodes to operate as expected. 3. Requirements We have compiled requirements from a diverse group of network operators that have much experience running MPLS networks. The following are requirements for MPLS Label Switching Router OAM functions that have been identified directly from operators deploying MPLS. a) Detection and diagnosis of broken Label Switch Path (LSP) that does not require manual hop-by-hop troubleshooting across the data path, specifically an LSP path-tracing tool. b) LSP tunnel trace capability [TUNTRACE] from both head-end Label Switch Router (LSR) and mid-point LSR. c) Automation of LSP path tracing for LSPs originating on a Provider Edge (PE) and ability to raise alarms when failures are detected. Nadeau et al. Expires April 2003 [Page 2] Internet Draft IP-based Tools Requirements October 28, 2002 d) Lightweight IP-layer ping function to validate customer edge (CE) to CE connectivity in order to demonstrate true end-to-end connectivity for the customer [LSPPING]. This mechanism should allow for configuration of automatic path tracing as described in b upon discovery of a ping failure. Other automatic actions may be necessary as well. e) VPN integrity by providing a mechanism to detect LSP mis- merging. f) Service Level Agreement (SLA) support by providing a mechanism to measure LSP latency. g) Error Detection and Recovery. A mechanism needed to detect an error, recover from it and alert the network operator prior to the customer informing the network operator of the error condition. It is however, sometimes a requirement that the customer be notified of the defect condition at the same time that the network operator is made aware of the defect. Depending on the device's capabilities, the device may be programmed to take automatic corrective actions as a result of detection of defect conditions. These actions may be user or operator-specified, or may simply be inherent to the underlying transport technology (i.e.: MPLS Fast-Reroute). h) Ability to detect failures on any parallel paths of LSPs which loadshare traffic across parallel paths. (LSRs may split traffic using, for example, hashing of fields within the packet header. It is important that to detect failures on all operational paths as failure of any branch may lead to loss of traffic.) i) Ability to perform OAM functions both point-to-point LSPs (such as those created by RSVP-TE) and multipoint to point LSPs (such as those created by LDP DU). j) Operator configurable OAM and frequency of OAM execution. k) Data plane OAM packets must follow the same path as for customer, however under certain conditions, for example, when there is load-balancing in the LSP, the OAM ping and customer data packets may take different paths. l) The OAM function can be extended for Service Level Agreement (SLA) measurement and limited to latency. m) OAM packet statistics that measure quantity (i.e.: number of packets) and quality (i.e.: latency measure) of OAM packets generated and received at each end of the tested LSP. n) Ability to suppress unnecessary alarms. For example, if an Nadeau et al. Expires April 2003 [Page 3] Internet Draft IP-based Tools Requirements October 28, 2002 underlying LSP that carries many VCs is not operational, it is unnecessary for the LSR to generate one alarm for every VC within the affected LSP. The operator Elemental Management System (EMS) can instead determine the affected VCs and VPNs by correlating the single LSP alarm with the LSRĘs configuration. Another example is the failure of an LSP at the bottom of the label stack may result in the failure of many other LSPs. OAM functions should suppress alarms on nested LSPs in this case. o) Allow for the integration of standard MPLS-related MIBs [LSRMIB][TEMIB][LBMIB][FTNMIB] for fault and statistics management. p) Allow for detection of Denial of Service attacks via an OAM filtering mechanism as part of security management. q) An LSR supporting OAM functions for pseudo-wire functions that join one or more networking technologies over MPLS must be able to translate an MPLS defect into the native technology's error condition. For example, errors occurring over the MPLS LSP must translate into native ATM OAM cells at the edges of the pseudo-wire. r) Separation of Data and Control Plane OAM. The inherent separation of control and data planes in MPLS lends itself to being sometimes implemented independently within an MPLS LSR. For example, in a multi-slot LSR, one slot may run a control process responsible for running MPLS control protocols such as LDP and RSVP, and then programming line cards residing in other slots to forward traffic accordingly. In doing so, the switch separates out the data plane from the control plane in such as way that it is possible for the line card to be mis- programmed whilst the control card is unaware. This leads to a potential for the line card to black hole data plane traffic. This is one example of why it is important for LSRs to possess functions that allow an operator to detect data plane liveliness. Data Plane liveliness MUST use the exact same path as data. 4. Security Considerations Detection and recovery from LSP mis-merging is a clear security consideration and is identified as a requirement for MPLS OAM. 5. Acknowledgments Nadeau et al. Expires April 2003 [Page 4] Internet Draft IP-based Tools Requirements October 28, 2002 The authors wish to acknowledge and thank the following individuals for their valuable comments to this document: Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr. Ikejiri, NTT Communications and Mr.Kumaki of KDDI. 6. References [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, G., Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", Internet Draft , March 2002. [TUNTRACE] Bonica, R., Kompella, K., Meyer, D., "Tracing Requirements for Generic Tunnels", Internet Draft , November 2001. [GTTP] Bonica, R., Kompella, K., Meyer, D., "Generic Tunnel Tracing Protocol (GTTP) Specification", Internet Draft , July 2001. [LSRMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Label Switch Router Management Information Base Using SMIv2", Internet Draft , January 2001. [TEMIB] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Traffic Engineering Management Information Base Using SMIv2", Internet Draft , August 2001. [FTNMIB] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base", Internet Draft , August 2001. [LBMIB] Dubuc, M., Dharanikota, S., Nadeau, T., J. Lang, "Link Bundling Management Information Base Using SMIv2", Internet Draft , September 2001. [PWE3FRAME] Pate, P., Xiao, X., White., C., Kompella., K., Malis, A., Johnson, T., and T. Nadeau, Nadeau et al. Expires April 2003 [Page 5] Internet Draft IP-based Tools Requirements October 28, 2002 "Framework for Pseudo Wire Emulation Edge-to- Edge (PWE3)", Internet Draft , September, 2001. [PPVPNFW] Callon, R., Suzuki, M., Gleeson, B., Malis, A., Muthukrishnan, K., Rosen, E., Sargor, C., and J. Yu, "A Framework for Provider Provisioned Virtual Private Networks", Internet Draft , July 2001. [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC2233] McCloghrie, K. and F. Kastenholtz, "The Interface Group MIB Using SMIv2", RFC 2233, November 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. Nadeau et al. Expires April 2003 [Page 6] Internet Draft IP-based Tools Requirements October 28, 2002 [ITU-T] Draft Recommendation Y.17fw (MPLS Management Framework) 7. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 300 Apollo Drive Chelmsford, MA 01824 Phone: +1-978-244-3051 Email: tnadeau@cisco.com Monique Jeanne Morrow Cisco Systems, Inc. Glatt-Com, 2nd Floor CH-8301 Switzerland Voice: +41 (0)1 878-9412 EMail: mmorrow@cisco.com George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Voice: +1 978 244 8143 Email: swallow@cisco.com 8. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Nadeau et al. Expires April 2003 [Page 7] Internet Draft IP-based Tools Requirements October 28, 2002 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 April 2003 [Page 8]