Network Working Group Luyuan Fang Internet Draft Dan Frost Intended status: Informational Cisco Systems Expires: September 07, 2011 Raymond Zhang BT Nabil Bitar Verizon Lei Wang Telenor Masahiro Daikoku KDDI March 7, 2011 MPLS-TP OAM Toolset draft-fang-mpls-tp-oam-toolset-00.txt Abstract This document provides an overview of MPLS-TP OAM tools, including MPLS-TP OAM functions, generic mechanisms for supporting MPLS-TP OAM; MPLS-TP Fault management tools; and Performance Management tools defined in IETF, OAM toolset utilization, and IANA assigned code point under G-Ach discussion. The protocol definitions for each individual MPLS-TP OAM tool are specified in separate RFCs (or Working Group documents while this document is work in progress) which this document references. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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. This Internet-Draft will expire on September 07, 2011. [Page 1] MPLS-TP OAM-Toolset March 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.. Table of Contents 1. Introduction .................................................. 3 2. Terminology ................................................... 3 3. Brief Overview of MPLS-TP OAM Requirements .................... 6 3.1. Architectural Requirements ................................. 6 3.2. Functional Requirements .................................... 6 4. MPLS-TP OAM Mechanisms and Toolset Summary .................... 8 4.1. In-band OAM Mechanisms ..................................... 8 4.2. Fault Management Toolset ................................... 8 4.3. Performance Monitoring Toolset ............................. 9 5. OAM Toolset Functionalities and Utilization .................. 10 5.1. Connectivity Verifications ................................ 10 5.2. Route Tracing ............................................. 10 5.3. Diagnostic Tests .......................................... 11 5.4. Lock Instruct ............................................. 11 5.5. Lock Reporting ............................................ 11 5.6. Alarm Reporting ........................................... 11 5.7. Remote Defect ............................................. 11 5.8. Client Failure ............................................ 11 5.9. Packet Loss Measurement ................................... 11 5.10. Packet Delay Measurement .................................. 11 6. IANA assigned code points under G-Ach ........................ 11 7. Security Considerations ...................................... 12 8. IANA Considerations .......................................... 12 9. Normative References ......................................... 13 10. Informative References ...................................... 13 11. Author's Addresses .......................................... 14 [Page 2] MPLS-TP OAM-Toolset March 2011 Requirements Language Although this document 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 [RFC 2119]. 1. Introduction The Operations, Administration, and Maintenance (OAM) Requirements for Transport Profile of Multiprotocol Label Switching (MPLS-TP) networks are defined in RFC 5860 [RFC 5860]. MPLS-TP OAM mechanisms and multiple OAM tools have been developed based on MPLS-TP OAM requirements. This document provides an overview of MPLS-TP OAM tools, including MPLS-TP OAM functions, generic mechanisms for supporting MPLS-TP OAM; MPLS-TP Fault management tools; and Performance Management tools, OAM toolset utilization, and IANA assigned code point under G-Ach consideration. The protocol definitions for each individual MPLS-TP OAM tool are defined in separate RFCs (or Working Group documents while this document is work in progress) this document references. 2. Terminology This document uses MPLS-TP OAM specific terminology. Term Definition ---------------------------------------------------- AC Attachment Circuit AIS Alarm indication signal APS Automatic Protection Switching ATM Asynchronous Transfer Mode [Page 3] MPLS-TP OAM-Toolset March 2011 BFD Bidirectional Forwarding Detection CC Continuity Check CE Customer-Edge device CM Configuration Management CoS Class of Service CV Connectivity Verification FM Fault Management GAL Generic Alert Label G-ACH Generic Associated Channel GMPLS Generalized Multi-Protocol Label Switching LDI Link Down Indication LDP Label Distribution Protocol LER Label Edge Router LKR Lock Report L-LSP Label-Only-Inferred-PSC LSP LM Loss Measurement LMEG LSP ME Group LSP Label Switched PathLSR Label Switching Router LSME LSP SPME ME LSMEG LSP SPME ME Group ME Maintenance Entity MEG Maintenance Entity Group MEP Maintenance Entity Group End Point MIP Maintenance Entity Group Intermediate Point [Page 4] MPLS-TP OAM-Toolset March 2011 MPLS MultiProtocol Label Switching NMS Network Management System NTP Network Time Protocol OAM Operations, Administration, and Management PE Provider Edge PHB Per-hop Behavior PM Performance Monitoring PME PW Maintenance Entity PMEG PW ME Group PSC PHB Scheduling Class PSME PW SPME ME PSMEG PW SPME ME Group PW Pseudowire QoS Quality of Service RDI Remote Defect Indication SDH Synchronous Digital Hierarchy SLA Service Level Agreement SME Section Maintenance Entity SMEG Section ME Group SONET Synchronous Optical Network SPME Sub-path Maintenance Element S-PE Switching Provider Edge SRLG Shared Risk Link Group TC Traffic Class [Page 5] MPLS-TP OAM-Toolset March 2011 T-PE Terminating Provider Edge 3. Brief Overview of MPLS-TP OAM Requirements This following Architectural and Functional Requirements are defined by RFC 5860. They are captured here for easy reading before discussing the toolset. 3.1. Architectural Requirements The MPLS OAM Supports point-to-point bidirectional PWs, point-to- point co-routed bidirectional LSPs, point-to-point bidirectional Sections, point-to-point associated bidirectional LSPs, point-to- point unidirectional LSPs, and point-to-multipoint LSPs, support LSPs and PWs in single domain and across domains. The protocol solution(s) SHOULD be independent of the underlying tunneling or point-to-point technology or transmission media. The protocol solution(s) SHOULD be independent of the service a PW may emulate. The protocol solution(s) SHOULD be independent of the underlying tunneling or point-to-point technology or transmission media. The protocol solution(s) SHOULD be independent of the service a PW may emulate. In-band OAM MUST be implemented. OAM packets for a specific PW, LSP, or Section MUST follow the exact same data path as user traffic of the same. The solutions MUST operate OAM functions with or without relying on IP capabilities. It is REQUIRED that OAM interoperability is achieved between distinct domains with different operational models, e.g. with IP or without IP support in the data plane. And OAM functions MUST be configurable even in the absence of a control plane. 3.2. Functional Requirements In general, MPLS-TP OAM tools MUST provide functions to detect, diagnose, localize, and notify the faults when occur. The mechanism [Page 6] MPLS-TP OAM-Toolset March 2011 for correction actions trigged by fault detection SHOULD be provided. The following are the fault detection functional requirements - Continuity Checks: a function to enable an End Point to monitor the liveness of a PW, LSP, or Section. - Connectivity Verifications: a function to enable an End Point to determine whether or not it is connected to specific End Point(s) by means of the expected PW, LSP, or Section. - Route Tracing: the functionality to enable an End Point to discover the Intermediate (if any) and End Point(s) along a PW, LSP, or Section. - Diagnostic Tests: a function to enable conducting diagnostic tests on a PW, LSP, or Section. For example, a loop-back function. - Lock Instruct: the functionality to enable an End Point of a PW, LSP, or Section to instruct its associated End Point(s) to lock the PW, LSP, or Section. - Lock Reporting: a function to enable an Intermediate Point of a PW or LSP to report, to an End Point of that same PW or LSP, a lock condition indirectly affecting that PW or LSP. - Alarm Reporting: the functionality to enable an Intermediate Point of a PW or LSP to report, to an End Point of that same PW or LSP, a fault or defect condition indirectly affecting that PW or LSP. - Remote Defect Indication: a function to enable an End Point to report, to its associated End Point, a fault or defect condition that it detects on a PW, LSP, or Section for which they are the End Points. - Client Failure Indication: a function to enable the propagation, from edge to edge of an MPLS-TP network, of information pertaining to a client fault condition detected at an End Point of a PW or LSP, if the client layer OAM does not provide alarm notification. - Packet Loss Measurement: a function to enable the quantification of packet loss ratio over a PW, LSP, or Section. - Packet Loss Measurement: a function to enable the quantification of the one-way, and the two-way, delay ratio over a PW, LSP, or Section. [Page 7] MPLS-TP OAM-Toolset March 2011 4. MPLS-TP OAM Mechanisms and Toolset Summary The following subsections provide the summary of MPLS-TP OAM Fault Management and Performance Management toolset, with indication of the corresponding IETF RFCs (or Internet drafts while this document is work in progress) to support the MPLS OAM functionalities defined in RFC 5860. 4.1. In-band OAM Mechanisms To meet the In-band OAM requirements for MPLS-TP, Generic Associated Channel is created [RFC 5586]. It generalizes the applicability of the Pseudowire (PW) Associated Channel Header (ACH) to enable a control chancel associated to MPLS Label Switching Paths in addition to PW. The Generic Associated Label (GAL) is defined by assigning one of the reserved MPLS label values to the G-Ach, to allow the identification of the Associated Channel Header in the label stack. The creation of G-Ach and GAL provided the necessary mechanisms for building in-band OAM MPLS-TP toolset. RFC 5586 [RFC 5586] An-In-Band Data Communication Network for the MPLS Transport Profile describes how the G-Ach may be used to for Management Communication and Signaling Communication. 4.2. Fault Management Toolset The following tables provide the summary of MPLS-TP OAM Fault Management toolset functions, protocol definitions, and the IETF RFCs or Internet drafts. The following table provide the Performance Monitoring Functions, protocol definitions, and corresponding RFCs or Internet Drafts. (Editor's note: only RFCs are referenced in the final version of the document). [Page 8] MPLS-TP OAM-Toolset March 2011 +----------------------------------------------------------------+ | Proactive Fault Management OAM Toolset | |----------------------------------------------------------------| |OAM Functions |Protocols Definitions | RFCs / IDs | |------------------|------------------------|--------------------| |Continuity Check |Bidirectional Forwarding| draft-ietf-mpls-tp | |(CV) & Continuity |Detection (BFD) | -cc-cv-rdi [cc-cv] | |Verification(CV) | | | |------------------|------------------------|--------------------| |Remote Defect |Bidirectional Forwarding| draft-ietf-mpls-tp | |Indication (RDI) |Detection (BFD) | -cc-cv-rdi | |------------------|------------------------|--------------------| |Alarm Indication |AIS message under G-Ach | draft-ietf-mpls-tp | |Signal (AIS) | | -fault | |------------------|------------------------|--------------------| |Link Down |Flag in AIS message | draft-ietf-mpls-tp | ||Indication (LDI) | | -fault [fault] | |------------------|------------------------|--------------------| |Lock Report (LKR) |LKR message under G-Ach | draft-ietf-mpls-tp | | | | -fault | +----------------------------------------------------------------+ Table 1. Proactive Fault Management OAM Toolset +----------------------------------------------------------------+ | On Demand Fault Management OAM Toolset | |----------------------------------------------------------------| |OAM Functions |Protocols Definitions | RFCs / IDs | |------------------|------------------------|--------------------| |Continuity |LSP Ping and BFD | draft-ietf-mpls-tp | |Verification(CV) | | -cc-cv-rdi | |------------------|------------------------|--------------------| |Loopback |1) In-band Loopback | draft-ietf-mpls-tp | |(LBM/LBR) | in G-Ach | -li-lb [li-lb] | | |2) LSP Ping | | |------------------|------------------------|--------------------| |Lock Instruct | In-band lock message | draft-ietf-mpls-tp | |(LI) | in G-Ach | -li-lb | +----------------------------------------------------------------+ Table 2. On Demand Fault Management OAM Toolset 4.3. Performance Monitoring Toolset [Page 9] MPLS-TP OAM-Toolset March 2011 The following table provide the Performance Monitoring Fuctions, protocol definitions, and corresponding RFCs or Internet Drafts. +----------------------------------------------------------------+ | Performance Monitoring OAM Toolset | |----------------------------------------------------------------| |OAM Functions |Protocols Definitions | RFCs / IDs | |------------------|------------------------|--------------------| |Packet loss |LM & DM query messages | draft-ietf-mpls-tp | |measurement (LM) | | -loss-delay [lo-de]| |------------------|------------------------| | |Packet delay (DM) |LM & DM query messages | draft-ietf-mpls-tp | |(LBM/LBR) | | -loss-delay | |measurement | | -profile [lo-de-p] | |------------------|------------------------| | |Throughput |Supported by LM | | |measurement | | | |------------------|------------------------| | |Delay Variation |Supported by DM | | |measurement | | | +----------------------------------------------------------------+ Table 3. Performance Monitoring OAM Toolset 5. OAM Toolset Functionalities and Utilization (to be filled) 5.1. Connectivity Verifications 5.2. Route Tracing [Page 10] MPLS-TP OAM-Toolset March 2011 5.3. Diagnostic Tests 5.4. Lock Instruct 5.5. Lock Reporting 5.6. Alarm Reporting 5.7. Remote Defect 5.8. Client Failure 5.9. Packet Loss Measurement 5.10. Packet Delay Measurement 6. IANA assigned code points under G-Ach OAM toolset/functions defined under G-Ach MUST use IANA assigned code points, using Experimental Code Point under G-Ach is inappropriate and it can lead to interoperability problems and potential Code Point collision in production network. RFC 5586 "MPLS Generic Associated Channel" stated the following in IANA consideration section: A requirement has emerged (see [RFC 5860]) to allow for optimizations or extensions to OAM and other control protocols running in an associated channel to be experimented without resorting to the IETF standards process, by supporting experimental code points. This would prevent code points used for such functions from being used from the range allocated through the IETF standards and thus protects an installed base of equipment from potential inadvertent overloading of code points. In order to support this requirement, IANA has changed the code point allocation scheme for the PW Associated Channel Type be changed as follows: 0 - 32751: IETF Review 32760 - 32767: Experimental Code points in the experimental range MUST be used according to the guidelines of RFC 3692 [RFC 3692]. Functions using experimental G- Ach code points MUST be disabled by default. The guidelines on the usage of experimental numbers are defined in IETF RFC 3692. As indicated by RFC 3692: The experimental numbers are useful when experimenting new protocols or extending existing [Page 11] MPLS-TP OAM-Toolset March 2011 protocols in order to test and experiment the new functions, as part of implementation. RFC 3692 reserves a range of numbers for experimentation when the need of such experimentation has been identified. However, the experimental numbers "are reserved for generic testing purposes, and other implementations may use the same numbers for different experimental uses." "Experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments." "Shipping a product with a specific value pre-enabled would be inappropriate and can lead to interoperability problems when the chosen value collides with a different usage, as it someday surely will." Further more, "it would be inappropriate for a group of vendors, a consortia, or another Standards Development Organization to agree among themselves to use a particular value for a specific purpose and then agree to deploy devices using those values." Experimental numbers are not guaranteed to be unique by definition. There is the risk of code point collision when using Experimental Code Point in production networks. Similar statements can also be found in RFC4929 "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures". As described in [RFC 4775], "non- standard extensions, including experimental values, are not to be portrayed as industrial standards whether by an individual vendor, an industry forum, or a standards body." 7. Security Considerations The document provides overview on MPLS-TP OAM requirements, functions, protocol definitions, and solution considerations. The actual protocols for the OAM toolset are defined in separate documents and referenced by this document. The general security considerations are provided in MPLS-TP Security Framework. [tp-sec-fr] 8. IANA Considerations This document contains no new IANA considerations. [Page 12] MPLS-TP OAM-Toolset March 2011 9. Normative References [RFC 5586], M. Bocci, M. Vigoureux, S. Bryant, "MPLS Generic Associated Channel",RFC 5586, June 2009. [RFC 5654], Niven-Jenkins, B., et al, "MPLS-TP Requirements", RFC 5654, September 2009. [RFC 5718], D. Beller, and A. Farrel, "An In-Band Data Communication Network For the MPLS Transport Profile", RFC 5718, Jan 2010. [RFC 5860], M. Vigoureux, D. Ward, M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010. 10. Informative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers Considered Useful", RFC 3692, Jan. 2004. [RFC 4775] S. Bradner, "Procedures for Protocol Extensions and Variations", RFC 4775, Dec. 2006. [RFC 5920] L. Fang, et al, Security Framework for MPLS and GMPLS Networks, July 2010. [MPLS-TP NM REQ] Hing-Kam Lam, Scott Mansfield, Eric Gray, MPLS TP Network Management Requirements, draft-ietf-mpls-tp-nm-req-06.txt, October 2009. [cc-cv] D. Allan, G. Swallow, J. Drake, Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile, draft-ietf-mpls-tp-cc-cv-rdi-03, Feb. 2011. [fault] G. Swallow, A. Fulignoli, M. Vigoureux, MPLS Fault Management OAM, draft-ietf-mpls-tp-fault-01, March 2011. [li-lb] S. Boutros, S. Sivabalan, et,al., MPLS Transport Profile Lock Instruct and Loopback Functions draft-ietf-mpls-tp-li-lb- 01.txt, March 2011. [lo-de] D. Frost, S. Bryant, Packet Loss and Delay Measurement for the MPLS Transport Profile, June 2010. [Page 13] MPLS-TP OAM-Toolset March 2011 [lo-de-p] D. Frost, S. Bryant, A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks, draft-frost-mpls-tp-loss- delay-profile-00, Dec. 2010. [tp-sec-fr] L. Fang, Niven-Jenkins, S. Mansfield, et. Al. MPLS-TP Security Framework, draft-ietf-mpls-tp-security-framework-00, Feb. 2011. 11. Author's Addresses Luyuan Fang Cisco Systems 111 Wood Avenue South Iselin, NJ 08830 USA Email: lufang@cisco.com Dan Frost Cisco Systems Email: danfrost@cisco.com Raymond Zhang British Telecom BT Center 81 Newgate Street London, EC1A 7AJ United Kingdom Email: raymond.zhang@bt.com Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 USA Email: nabil.bitar@verizon.com Lei Wang Telenor Telenor Norway Office Snaroyveien 1331 Fornedbu Email: Lei.wang@telenor.com Masahiro DAIKOKU KDDI corporation 3-11-11.Iidabashi, Chiyodaku, Tokyo Japan Email: ms-daikoku@kddi.com [Page 14] MPLS-TP OAM-Toolset March 2011 [Page 15]