Neil Harrison Internet Draft Peter Willis Document: draft-harrison-mpls-oam-req-01.txt British Telecom Expires: May 2002 Shahram Davari PMC-Sierra Enrique G. Cuevas Ben Mack-Crane AT&T Tellabs Elke Franze Hiroshi Ohta Deutsche Telekom NTT Tricci So Sanford Goldfless Caspian Network Feihong Chen Lucent Mina Azad (this version's editor) David Allan Eric Davalo Nortel Networks Maple Optical Systems Wesam Alanqar Marcus Brunner Sprint NEC Europe Ltd. Chou Lan Pok Arun Punj SBC Technology Resources, Inc. Marconi Communications December 2001 Requirements for OAM in MPLS Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of 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. MPLS OAM Requirements Expires May 2002 [Page 1] Copyright Notice Copyright(C) The Internet Society (2001). All Rights Reserved. Abstract This draft provides requirements for maintenance procedures and Protocols (a.k.a. OAM) to determine the health and performance of MPLS user-plane. Motivation for MPLS user-plane maintenance tools rose from Network operators need to determine availability and performance of MPLS LSPs (Label Switched Paths). User-plane OAM tools are required to verify that LSPs have been setup and are available to deliver customer data to target destinations according to QoS (Quality of Service) guarantees given in SLAs (Service Level Agreements). 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 2. Motivation for MPLS user-plane maintenance functionality . . . . 3 3. Network Provider's Requirements . . . . . . . . . . . . . . . . . 3 4. Requirements extracted from IETF RFCs and Internet Drafts . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 MPLS OAM Requirements Expires May 2002 [Page 2] 1. Introduction This draft provides requirements for maintenance procedures and protocols (a.k.a. OAM) to determine the health and performance of MPLS user-plane. It is recognized that OAM functionality is important in public networks to facilitate and reduce cost of network operation, determine LSP availability, and measure quality of service. Standardized definition of availability performance and performance monitoring tools allow network users to verify whether network operators are providing contracted Service Layer Agreements. 2. Motivation for MPLS user-plane maintenance functionality Operators need MPLS user-plane OAM in order to: - Ensure that MPLS becomes a reliable network platform that can be operable, administered, and maintained through appropriate user-plane mechanisms - Allow development of simple, consistent and measurable availability and QoS SLAs for services such as MPLS-based VPNs - Drive down operational costs (which are the largest cost-line over the life of a network) - Protect the security/integrity of the network - Reduce defect detection time and, thus, increase reliability. 3. Network Provider's Requirements This section describes the high level requirements that have been identified and requested by a number of service providers. User-plane maintenance functionality must: 1) be made available at any level in the MPLS stack; MPLS nesting/tunneling capability (realized through label stack encoding [5]) allows LSPs to create layer networks in their own right. Therefore, It should be made possible to insert OAM packets at each nesting level. At this point, there are no requirements for maintenance functionality across nesting levels. Note: Similar requirement has been stated in draft-team-tewg-restore-hierarchy-00.txt "However, a capability should be provided for a network operator to control the operation of survivability mechanisms among different layers". MPLS OAM Requirements Expires May 2002 [Page 3] 2) automatically detect most types of user-plane defects; All the major defect conditions must be identified with in-service Measurable entry and exit criteria, and all consequent actions must be specified. At least the following MPLS user-plane defects need to be detected: a. Loss of LSP connectivity (due to a server layer failure or a failure within the MPLS layer) b. Swapped LSP trails c. LSP mismerging (of 2 or more LSP trails; including loops) d. Unintended replication (e.g. unintended multicasting). It is also important to specify how unavailable/available state Transition relate to the stopping/starting of the aggregation of available state QoS metrics. Note: similar requirement is also stated in draft-ietf-ppvpn-requirements-02.txt "6.1 Fault management Support for fault management includes: - indication of customers impacted by failure, - fault detection (incidents reports, alarms, failure visualization), - fault localization (analysis of alarms reports, diagnostics), - incident recording or logs, creation and follow through of trouble tickets), - corrective actions (traffic, routing, resource allocation)". 3) facilitate automated and timely network response to user-plane defects; If a defect occurs, it is necessary to detect, notify and localize it immediately and to take necessary actions. This is to minimize service interruption by providing the network with sufficient information to take corrective action to bypass the defect (protection switching, re-routing etc.), and to minimize the time to correct the defect and return the failed resource to the available state. It is necessary that defects be detected and notified automatically without operator intervention for this purpose. 4) provide automatic and on-demand maintenance and diagnostic functions. 5) be independent of any control-plane maintenance functionality; The control-plane must also have its own maintenance capability. This version of the requirements draft does not address control-plane OAM. Note: Similar requirement is stated in draft-ietf-ipo-carrier-requirements-00.txt "Requirement 60. The signaling network shall have its own OAM mechanisms." 6) be independent of user-plane maintenance functionality used in other client or server layer network technologies; This is critical to ensure that layer networks can evolve (or new/old layer networks be added/removed) without impacting other layer networks. MPLS OAM Requirements Expires May 2002 [Page 4] Note: Client and server layer independency is also required for MPLS based recovery. As indicated draft-ietf-mpls-recovery-frmwrk-03.txt, client layer (i.e. layer 3 and IP) functionality might not be fast enough and server layer functionality might not be sufficiently accessible to address MPLS based recovery. 7) be scalable to at least the order that LSPs are scalable; Specifically, operator actions for set up and activation of Maintenance functions should be kept to minimum in large-scale networks. 8) be backward compatible; LSRs that do not support such function must silently discard or pass Through the OAM packets without disturbing the traffic or causing Unnecessary actions. 9) be an extensible framework that will support important MPLS applications (e.g., TE, VPN, Frame Relay, ATM, Ethernet, Layer-2 Encapsulations). Note: Similar requirement is stated in draft-ietf-pwe3-requirements-01.txt "5.2. Status Monitoring Some native services have mechanisms for status monitoring. For example, ATM supports OAM for this purpose. For such services, the corresponding emulated services MUST specify how to perform status monitoring. The mechanisms NEED NOT be defined in this WG. Some status monitoring mechanisms defined in other WGs, e.g., [LSPPING] or [MPLSOAM], may be leveraged". Note: [LSPPING] is the same as [7] and [MPLSOAM] is the same as [8]. 4. Requirements extracted from IETF RFCs and Internet Drafts Numerous OAM requirements have been stated in existing IETF RFCs and Working group Internet drafts. This section provides a summary of such requirements to highlight the significance of dependency on MPLS user-plane OAM. draft-heron-ppvpn-vpsn-reqmts-00.txt "While further OAM functionality, such as the ability to trigger remote network loopbacks or to verify that frames are successfully delivered to the intended remote VPSN instance, is desirable it is to be considered out of scope for this effort. Other groups are defining such functionality, for example the LSP-ping effort [7] and the MPLS OAM effort [8], and it may be possible to leverage this work in VPSN implementations." MPLS OAM Requirements Expires May 2002 [Page 5] RFC 2702 "when a fault occurs along the path through which the traffic trunk traverses. The following basic problems need to be addressed under such circumstances: (1) fault detection, (2) failure notification, (3) recovery and service restoration. Obviously, an MPLS implementation will have to incorporate mechanisms to address these issues". draft-owens-te-network-survivability-01.txt "7.3.1 Considerations for the ATM and/or MPLS Layer As discussed, fault detection at the MPLS layer could be by Detecting TTL errors or by counting unlabeled packets or packets with unrecognized labels. An issue with TTL errors is that they could be the result of either an MPLS layer or an IP layer problem, since the MPLS header carries the IP TTL. For instance, TTL mis- matches could be due to a genuine problem with an upstream LSR or due to a router upstream of the LSR detecting the mismatches, probably the edge router that converted the IP packet into a labeled MPLS packet. Likewise, the persistent receipt of unlabeled packets or packets with unknown labels might indicate protocol problems, and necessitate a protection switch. Thus, detection of some types of errors at the MPLS layer may require a protection switch at the same layer, which is independent of lower layers." 5. Security Considerations The OAM function described in this document enhances the security of MPLS networks, by detecting mis-connections, and therefore preventing customers traffic to be exposed to other customers. The MPLS OAM functions as defined in this document do not raise any new security issue, to MPLS networks. 6. References [1] IETF, RFC-2119, "Key words for use in RFCs to Indicate Requirement Levels", Category: Best Current Practice, March 1997 [2] IETF, RFC-2026, "The Internet Standards Process -- Revision 3", Best Current Practice, October 1996 [3] IETF, RFC-2702, "Requirements for Traffic Engineering Over MPLS" , Informational, September 1999 [4] IETF, RFC3031, "Multiprotocol Label Switching Architecture", Category: Standards Track, January 2001. [5] IETF, RFC 3032, "MPLS label stack encoding", Category: Standards Track, January 2001. MPLS OAM Requirements Expires May 2002 [Page 6] [6] Marco Carugi et. al., "Service requirements for Provider Provisioned Virtual Private Networks", draft-ietf-ppvpn-requirements-02.txt, August 2001 [7] Ping Pan et. al., "Detecting Data Plane Liveliness in RSVP-TE", draft-pan-lsp-ping-01.txt, July 2001 [8] Neil Harrison et. al. "Requirements for OAM in MPLS Networks", draft-harrison-mpls-oam-req-01.txt, May 2001 [9] Wai Sum Lai st. al., "Network Hierarchy and Multilayer Survivability", draft-team-tewg-restore-hierarchy-00.txt, July 2001 [10] Yong Xue et. al., "Carrier Optical Services Requirements", draft-ietf-ipo-carrier-requirements-00.txt., expiry: January 2002 [11] XiPeng Xiao et. al., "Requirements for Pseudo-Wire Emulation Edge-to-Edge(PWE3)", draft-ietf-pwe3-requirements-01.txt, July 2001 [12] Giles Heron et. Al., "Requirements for Virtual Private Switched Networks", draft-heron-ppvpn-vpsn-reqmts-00.txt, July 2001 [13] Ken Owens et. al., "Network Survivability Considerations for Traffic Engineered IP Networks", draft-owens-te-network-survivability-01.txt, July 2001 [14] Vishal Sharma et. al., "Framework for MPLS-based Recovery", draft-ietf-mpls-recovery-frmwrk-03.txt, July 2001 7. Author's Addresses Neil Harrison British Telecom Phone: 44-1604-845933 Heath Bank Email: neil.2.Harrison@bt.com Iugby Road, Harleston South Hampton, UK Peter Willis British Telecom Phone: 44-1473-645178 BT, PP RSB10/PP3 B81 Email: peter.j.willis@bt.com Adastrial Park Martlesham, Ipswich, UK Shahram Davari PMC-Sierra 411 Legget Drive Phone: 1-613-271-4018 Kanata, ON, Canada Email: Shahram_Davari@pmc-sierra.com Ben Mack-Crane Tellabs 4951 Indiana Ave Phone: 1-630-512-7255 Lisle, IL, USA Email: ben.mack-crane@tellabs.com MPLS OAM Requirements Expires May 2002 [Page 7] Hiroshi Ohta NTT 3-9-11 Midori-cho phone: +81-422-59-3617 Musashino-Shi, Email: ohta.hiroshi@lab.ntt.co.jp Tokyo 180-8585 Japan Sanford Goldfless Lucent Technologies 200 Nickerson Road Phone: 508-786-3655 Marlborough, MA 01752 Email: sgoldfless@lucent.com Feihong Chen Lucent Technologies 200 Nickerson Road Phone: 508-786-3675 Marlborough, MA 01752 Email: fchen6@lucent.com Tricci So Caspian Network 170 Baytech Drive Phone: 408-382-5217 San Jose, CA Email: tso@caspiannetworks.com U.S.A. 94070 Elke Franze Deutsche Telekom T-Systems T-Nova, Technologiezentrum Phone: +49 6151 83 5459 D-64307 Darmstadt Email: elke.franze@t-systems.de Darmstadt, Germany Enrique G. Cuevas AT&T Room D3-2B25 Phone: +1 732 420 3252 200 S. Laurel Avenue E-mail: ecuevas@att.com Middletown, NJ 07748 USA Mina Azad Nortel Networks 3500 Carling Ave. phone: 1-613-763-2044 Ottawa, Ontario, CANADA Email: mazad@nortelnetworks.com David Allan Nortel Networks Phone: (613) 763-6362 3500 Carling Ave. Email: dallan@nortelnetworks.com Ottawa, Ontario, CANADA Eric Davalo Maple Optical Systems 3200 North First Street Phone: 408 545 3110 San Jose, CA 95134 Email: edavalo@mapleoptical.com Wesam Alanqar Sprint 9300, Metcalf Ave, Phone: +1-913-534-5623 Overland Park, KS 66212 E-mail: wesam.alanqar@mail.sprint.com MPLS OAM Requirements Expires May 2002 [Page 8] Marcus Brunner NEC Europe Ltd. Adenauerplatz 6 Phone: +49 (0)6221/ 9051129 D-69115 Heidelberg, Germany Email: brunner@ccrle.nec.de Chou Lan Pok SBC Technology Resources, Inc. 4698 Willow Road, Phone: 925-598-1229 Pleasanton, CA 94583 Email: pok@tri.sbc.com Arun Punj Marconi Communications 1000 Marconi Drive, warrandale - PA - 15086 MPLS OAM Requirements Expires May 2002 [Page 9]