Internet Draft Internet-Draft T. Theimer Expires April 2000 J. Klink Siemens October 1999 Requirements for OAM Functionality in MPLS <draft-theimer-mpls-oam-requ-00.txt> 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. Abstract This draft discusses the motivation for MPLS OAM functionality and possible requirements for OAM in MPLS networks. Examples of OAM functions include support for fault management, continuity checks, loopbacks, performance monitoring and protection switching. Such capabilities may be useful in many applications of MPLS networks, but a detailed set of requirements is currently not available. Further discussion and input is solicited, in particular from network operators and service providers. 1. Introduction OAM (Operation, Administration and Maintenance) functionality is important in public networks for ease of network operation, for verifying network performance and to reduce network operating costs. OAM functionality is especially relevant for networks in which Quality of Service is an important issue. OAM functions have therefore been defined e.g. for SONET/SDH and also for ATM networks. MPLS, as one of the key technologies for scalable next-generation networks providing QoS and supporting a diverse range of network services, will most likely require some basic OAM functionality as well. [Page 1] Internet-Draft OAM Requirements for MPLS October 1999 MPLS OAM functionality is not seen as a substitute for physical layer (e.g. SONET/SDH) OAM functionality. However, MPLS layer OAM functions may nevertheless be desirable in addition to physical layer OAM: They will be required whenever OAM functionality is needed that permits differentiation per individual LSP. For example: - monitoring of connectivity, availability or performance of an individual LSP - MPLS protection switching for an individual LSP This draft intends to initiate a discussion on requirements for OAM functionality in MPLS, with the ultimate goal to identify a set of basic OAM functions and the protocol extensions needed for an interoperable implementation of these functions. Note that we do not intend to simply adopt the OAM functions and procedures previously defined for other technologies (in particular ATM), as this would probably lead to very complex and expensive implementations. It is therefore very important to carefully define the OAM requirements for MPLS, focusing primarily on those issues where market demand is already beginning to appear. 2. Motivation and Requirements for OAM Functionality in MPLS OAM functionality may be useful in MPLS for the following reasons (this list is clearly not exhaustive, and requires further work to describe each requirement in more detail): 2.1. It allows the Operator to verify whether Quality of Service guarantees committed in SLAs (Service Level Agreements) are in fact being met by the label switched path (LSP). Associated requirements: - in-service verification of LSP availability (whether an LSP is _up_ or _down_) and error performance (counting of lost frames) - in-service verification of delay and delay variation - in-service verification of connection throughput guarantees. 2.2. It allows the Operator to improve network reliability. Associated requirements: - LSP failure detection and automatic rerouting - MPLS protection switching 2.3. It allows the Operator to reduce network operating costs. Long term statistics show that the costs of operating a public network are higher than the initial installation costs. Theimer & Klink Expires April 2000 [Page 2] Internet-Draft OAM Requirements for MPLS October 1999 Associated requirements: - tools for fast and efficient fault detection and fault localization (related to individual LSPs) - tools for efficient network setup and configuration. 2.5. It allows the Operator to improve traffic flow/distribution through the network. Traffic engineering requirements have already been addressed in [3], and work is currently in progress in the IETF. 2.6. It gives support for improved accounting/billing procedures. Associated requirements: - measurement of throughput per connection for throughput based billing - detection of violations to an SLA traffic contract that can be given consideration for billing. 3. Examples of MPLS OAM Functionality Some examples of MPLS OAM functionality that may be used to address the above requirements are listed below: 3.1. Fault Management/Continuity Check OAM functionality could be defined to provide alarm information in cases where an MPLS path is _down_ or interrupted. This information could be propagated downstream along the MPLS path. Such functionality is particularly important when LSPs are manually configured in each node rather than established through a signalling protocol. Protocols such as LDP already provide similar functionality for the control plane path, covering severe errors such as total node or link failures. However, some error scenarios cannot be detected through these control plane mechanisms, and would also require inband monitoring capabilities within an LSP. One key application for such a function would be the in-service verification of MPLS path availability (continual monitoring whether the path is _up_ or _down_), enabling an Operator to verify whether Service Level Agreements with high availability guarantees are being met. Another possible application is as a trigger for MPLS protection switching. 3.2. Loopbacks OAM loopback packets could be defined, that would be looped back to the source of the loopback request at different nodes within an LSP Theimer & Klink Expires April 2000 [Page 3] Internet-Draft OAM Requirements for MPLS October 1999 (similar to a _ping_ function). This could be used to enable verification of correct connectivity/configuration of the LSP prior to its being taken into service. It could also be used to localise faults along an LSP. 3.3. Performance Monitoring OAM functionality could be defined to continually monitor the performance of an MPLS path, e.g. with respect to lost packets. Possible applications for this function include: - triggering of an alarm if a performance threshold is exceeded - performance statistics per individual LSP - triggering of MPLS protection switching if a _signal degrade_ situation is detected. 3.4. MPLS Protection Switching Work on MPLS protection switching has already been started, e.g. [1] and [2]. MPLS OAM functionality may be defined to support MPLS protection switching. Basic functionality that will probably need to be supported for this is: - Detection of failure situations (_hard_ or _soft_ failures) and propagation of this information to the MPLS protection domain source/sink. OAM functions for Fault Management/Continuity Check and Performance Monitoring (see above) could be used to achieve this. - Communication between protection domain source and sink in order to coordinate protection switching operations. 4. Areas for Standardisation Depending on the detailed list of OAM requirements and their relevance, extensions to existing protocols and/or some new protocols may have to be defined to support OAM functions in MPLS. Examples include extensions to TE-RSVP [4] and CR-LDP [5] to enable and control OAM capabilities for selected LSPs, and to forward error notification messages. In some cases it may also be required to introduce an OAM indicator in the MPLS header. This OAM indicator would enable a simple differentiation between user packets and OAM packets in equipment supporting MPLS. Further discussion is required to clarify the need for such an OAM indicator and to identify a suitable encoding. Theimer & Klink Expires April 2000 [Page 4] Internet-Draft OAM Requirements for MPLS October 1999 5. References [1] K. Owens, C. Huang: Protection/Restoration of MPLS Networks. Work in progress <draft-makam-mpls-protection-00.txt>, June 1999. [2] D. Haskin, R. Krishnan: A Method for Setting an Alternative Label Switched Paths to Handle Fast Reroute. Work in Progress <draft-haskin-mpls-fast-reroute-01.txt>, June 1999. [3] D. Awduche, et al: _Requirements for Traffic Engineering Over MPLS. RFC 2702, September 1999. [4] D.O. Awduche, et al: Extensions to RSVP for LSP Tunnels. Work in progress <draft-ietf-mpls-rsvp-lsp-tunnel-04.txt>, September 1999. [5] B. Jamoussi, et al: Constraint-Based LSP Setup using LDP. Work in progress <draft-ietf-mpls-cr-ldp-03.txt>, October 1999. 6. Authors' Addresses Thomas Theimer Siemens AG Hofmannstr. 51 81359 Munich, Germany Email: Thomas.Theimer@icn.siemens.de Joachim Klink Siemens AG Hofmannstr. 51 81359 Munich, Germany Email: Joachim.Klink@icn.siemens.de Theimer & Klink Expires April 2000 [Page 5]