Network Working Group Luyuan Fang Internet Draft Dan Frost Intended status: Informational Cisco Systems Expires: September 14, 2011 Nabil Bitar Verizon Raymond Zhang BT Lei Wang Telenor Kam Lee Yap XO Communications Michael Fargano Qwest John Drake Juniper Thomas Nadeau March 14, 2011 MPLS-TP OAM Toolset draft-fang-mpls-tp-oam-toolset-01.txt Abstract This document provides an overview of the MPLS-TP OAM toolset, which consists of MPLS-TP fault management and performance monitoring. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of the generic mechanisms created in the MPLS data plane to support in-band OAM. The importance of using IANA assigned code point under G-Ach when supporting MPLS-TP OAM is also discussed. The protocol definitions for each individual MPLS-TP OAM tool are specified in separate RFCs or Working Group documents which are referenced by this document. 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 [Page 1] MPLS-TP OAM-Toolset March 2011 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 14, 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 ....................7 4.1. In-band OAM Mechanisms .....................................8 4.2. Fault Management Toolset ...................................8 4.3. Performance Monitoring Toolset ............................10 5. OAM Toolset Utilization and Protocol Definitions .............10 5.1. Connectivity Check and Connectivity Verification ..........10 5.2 Diagnostic Tests and Lock Instruct. .......................11 5.3. Lock Reporting ............................................11 5.4. Alarm Reporting and Link down Indication ..................12 5.5. Remote Defect Indication ..................................12 5.6. Packet Loss and Delay Measurement .........................13 6. IANA assigned code points under G-Ach ........................14 7. Security Considerations ......................................15 8. IANA Considerations ..........................................15 [Page 2] MPLS-TP OAM-Toolset March 2011 9. Normative References .........................................15 10. Informative References .....................................16 11. Authors' Addresses..........................................17 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 the MPLS-TP OAM toolset, which consists of MPLS-TP fault management and performance monitoring. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of the generic mechanisms created in the MPLS data plane to support in-band OAM. The importance of using IANA assigned code point under G-Ach when supporting MPLS-TP OAM is also discussed. 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 are referenced by this document. 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) referenced by this document. 2. Terminology This document uses MPLS-TP OAM specific terminology. Term Definition ---------------------------------------------------- AC Attachment Circuit AIS Alarm indication signal [Page 3] MPLS-TP OAM-Toolset March 2011 APS Automatic Protection Switching ATM Asynchronous Transfer Mode 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 LM Loss Measurement LMEG LSP ME Group LOC Loss of Continuity LSP Label Switched Path LSR Label Switching Router LSME LSP SPME ME LSMEG LSP SPME ME Group ME Maintenance Entity [Page 4] MPLS-TP OAM-Toolset March 2011 MEG Maintenance Entity Group MEP Maintenance Entity Group End Point MIP Maintenance Entity Group Intermediate Point MPLS MultiProtocol Label Switching NMS Network Management System NTP Network Time Protocol OAM Operations, Administration, and Management PE Provider Edge PM Performance Monitoring PME PW Maintenance Entity PMEG PW ME Group 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-TP 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. In addition, MPLS-TP OAM supports these LSPs and PWs when they span single domain or multiple 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. 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 support OAM functions with or without relying on IP capabilities. It is REQUIRED that OAM interoperability be 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 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. [Page 6] MPLS-TP OAM-Toolset March 2011 - 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, and more generically to trace the route of 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 Delay Measurement: a function to enable the quantification of the one-way, and if appropriate, the two-way, delay ratio of a PW, LSP, or Section. 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 [Page 7] MPLS-TP OAM-Toolset March 2011 is work in progress) to support the MPLS-TP OAM functions 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 MPLS Label Switching Paths (LSPs), and Sections. The Generic Associated Label (GAL) [RFC 5586] is defined by assigning one of the reserved MPLS label values to the G-Ach, GAL identifies the presence of the Associated Channel Header following the label stack. The creation of G-Ach and GAL provided the necessary mechanisms for building in-band OAM MPLS-TP toolset. RFC 5718 [RFC 5718] An-In-Band Data Communication Network for the MPLS Transport Profile describes how the G-Ach may be used for Management and Signaling Communication. 4.2. Fault Management Toolset The following tables provide the summary of MPLS-TP OAM toolset. Table 1 provides the summary of MPLS-TP OAM Fault Management toolset functions, associated tool/protocol, and the corresponding IETF RFCs or Internet drafts where they are defined. Table 2 provides the Performance Monitoring Functions, associated tool/protocol definitions, and the corresponding IETF RFCs or Internet Drafts where they are defined. The following table provide the Performance Monitoring Functions, protocol definitions, and corresponding RFCs or Internet Drafts. (Editor's note: only RFCs will be referenced in the final version of the document). [Page 8] MPLS-TP OAM-Toolset March 2011 +----------------------------------------------------------------+ | Proactive Fault Management OAM Toolset | |----------------------------------------------------------------| |OAM Functions |OAM Tools/Protocols | 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 [cc-cv] | |------------------|------------------------|--------------------| |Alarm Indication |AIS message under G-Ach | draft-ietf-mpls-tp | |Signal (AIS) | | -fault [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 [fault] | +----------------------------------------------------------------+ Table 1. Proactive Fault Management OAM Toolset +----------------------------------------------------------------+ | On Demand Fault Management OAM Toolset | |----------------------------------------------------------------| |OAM Functions |OAM Tools/Protocols | RFCs / IDs | |------------------|------------------------|--------------------| |Continuity |LSP Ping and BFD | draft-ietf-mpls-tp | |Verification(CV) | | -cc-cv-rdi [cc-cv] | |------------------|------------------------|--------------------| |Diagnostic: |1) In-band Loopback | draft-ietf-mpls-tp | |Loopback, Lock | and Lock Instruct | -li-lb [li-lb] | |and LSP Ping |2) LSP Ping | | |------------------|------------------------|--------------------| |Lock Instruct | In-band lock message | draft-ietf-mpls-tp | |(LI) | in G-Ach | -li-lb [li-lb] | +----------------------------------------------------------------+ Table 2. On Demand Fault Management OAM Toolset [Page 9] MPLS-TP OAM-Toolset March 2011 4.3. Performance Monitoring Toolset Table 3 provides 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 | |measurement | | -loss-delay | |------------------|------------------------|-profile [tp-lo-de] | |Throughput |derived from Loss | | |measurement |measurement | | |------------------|------------------------| | |Delay Variation |Supported from Delay | | |measurement |measurement | | +----------------------------------------------------------------+ Table 3. Performance Monitoring OAM Toolset 5. OAM Toolset Utilization and Protocol Definitions 5.1. Connectivity Check and Connectivity Verification Continuity Check (CC) and Proactive Connectivity Verification (CV) functions are used to detect loss of continuity (LOC), and unintended connectivity between two MEPs. Loss of connectivity, mis-merging, mis-connectivity, or unexpected Maintenance Entity Group End Points (MEPs) can be detected using the CC/CV tools. The CC/CV tools are used to support MPLS-TP fault management, performance management, and protection switching. Bidirectional Forwarding Detection (BFD) and LSP Ping are defined to support the CC/CV functions [cc-cv]. BFD control packets are sent by the source MEP to sink MEP. The sink MEP monitors the arrival of the BFD control packets and detects the defect. The interval of BFD control packet can be configured. For example: [Page 10] MPLS-TP OAM-Toolset March 2011 - 3.3ms is the default interval for protection switching. - 100ms is the default interval for performance monitoring. - 1s is the default interval for fault management. 5.2. Diagnostic Tests and Lock Instruct The OAM functions to support diagnostic tests are required in the transport environment. The Loopback mode is defined for management purpose in [li-lb]. The mechanism is provided to Lock and unlock traffic (e.g. data and control traffic) or specific OAM traffic at a specific LSR on the path of the MPLS-TP LSP to allow loop back it to the source by [li- lb]. These diagnostic functions apply to associated bidirectional MPLS- TP LSPs, including MPLS-TP LSPs, bi-directional RSVP-TE tunnels (which is relevant for MPLS-TP dynamic control plane option with GMPLS), and single segment and multi-segment pseudowires. The Lock operation instruction is carried in an MPLS Loopback request message sent from a MEP to a trail-end MEP of the LSP to request that the LSP be taken out of service. In response, the Lock operation reply is carried in a Loopback response message sent from the trail-end MEP back to the originating MEP to report the result. The loopback operations include [li-lb]: - Lock: take an LSP out of service for maintenance. - Unlock: Restore a previously locked LSP to service. - Set_Full_Loopback and Set_OAM_Loopback - Unset_Full_Loopback and Set_OAM_Loopback Operators can use the loopback mode to test the connectivity or performance (loss, delay, delay variation, and throughput) of given LSP upto a specific node on the path of the LSP. 5.3. Lock Reporting The Lock Report (LKR) function is used to communicate to the client (sub-) layer MEPs the administrative locking of a server (sub-) layer MEP, and consequential interruption of data traffic forwarding in the client (sub-) layer [fault]. When operator is taking the LSP out of service for maintenance other operational reason, using the LKR function can help to [Page 11] MPLS-TP OAM-Toolset March 2011 distinguish the condition as administrative locking from defect condition. The Lock Report function would also serve the purpose of alarm suppression in the MPLS-TP network above the level of the Lock is occurred. The receipt of an LKR message MAY be treated as the equivalent of loss of continuity at the client layer [fault]. 5.4. Alarm Reporting and Link down Indication Alarm Indication Signal (AIS) message serves the purpose of alarm suppression upon the failure detection in the server (-sub) layer. When the Link Down Indication (RDI) is set, the AIS message MAY be used to trigger recovery mechanisms [fault]. When a server MEP detects the failure, it asserts Loss of Continuity (LOC) or signal fail which sets the flag up to generate OAM packet with AIS message. The AIS message is forwarded to downstream sink MEP in the client layer. This would enable the client layer to suppress the generation of secondary alarms. A Link Down Indication (LDI) flag is defined in the AIS message. The LDI flag is set in the AIS message in response to detecting a fatal failure in the server layer. Receipt of an AIS message with this flag set MAY be interpreted by a MEP as an indication of signal fail at the client layer. [fault] Fault OAM messages are generated by intermediate nodes where an LSP is switched, and propagated to the end points (MEPs). From practical point of view, when both proactive CC functions and LDI are used, one may consider to run the proactive CC functions at a slower rate (e.g. longer BFD hello intervals), and reply on LDI to trigger fast protection switch over upon failure detection in a given LSP. 5.5. Remote Defect Indication Remote Defect Indication (RDI) function enables an End Point to report to the other End Point that a fault or defect condition is detected on the PW, LSP, or Section they are the End Points. The RDI OAM function is supported by the use of Bidirectional Forwarding Detection (BFD) Control Packets [cc-cv]. RDI is only used for bidirectional connections and is associated with proactive CC/CV activation. [Page 12] MPLS-TP OAM-Toolset March 2011 When an end point (MEP) detects a signal failure condition, it sets the flag up by setting the diagnostic field of the BFD control packet to a particular value to indicate the failure condition on the associated PW, LSP, or Section, and transmitting the BFD control packet with the failure flag up to the other end point (its peer MEP). RDI function can be used to facilitate the protection switching by synchronizing the two end points when unidirectional failure occurs and is detected by one end. 5.6. Packet Loss and Delay Measurement Packet loss and delay measurement toolset enables operators to measure the quality of the packet transmission over a PW, LSP, or Section. The protocol for MPLS-TP loss and delay measurement functions is defined in [lo-de] as profiled in [tp-lo-de]. These documents specify how to measure Packet Loss, Packet Delay, Packet Delay Variation, and Throughput. The loss and delay protocols have the following characteristics and capabilities: - Support measurement of packet loss, delay and throughput over Label Switched Paths (LSPs), pseudowires, and MPLS sections (links). - The same LM and DM protocols can be used for both continuous/proactive and selective/on-demand measurement. - The LM and DM protocols use a simple query/response model for bidirectional measurement that allows a single node - the querier - to measure the loss or delay in both directions. - The LM and DM protocols use query messages for unidirectional loss and delay measurement. The measurement can either be carried out at the downstream node(s) or at the querier if an out-of-band return path is available. - The LM and DM protocols do not require that the transmit and receive interfaces be the same when performing bidirectional measurement. [Page 13] MPLS-TP OAM-Toolset March 2011 - The LM protocol supports both 32-bit and 64-bit counters although for simplicity only 32-bit packet counters are currently included in the MPLS-TP profile. - The LM protocol supports measurement in terms of both packet counts and octet counts although for simplicity only packet counters are currently included in the MPLS-TP profile. - The LM protocol can be used to measure channel throughput as well as packet loss. - The DM protocol supports varying the measurement message size in order to measure delays associated with different packet sizes. 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 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 protocols in order to test and experiment with the new functions, as part of implementation. RFC 3692 reserves a range of numbers for [Page 14] MPLS-TP OAM-Toolset March 2011 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 of MPLS-TP OAM requirements, functions, protocol, 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 Security Framework for MPLS and GMPLS Networks [RFC 5920], and MPLS-TP Security Framework [tp-sec-fr]. 8. IANA Considerations This document contains no new IANA considerations. 9. Normative References [Page 15] MPLS-TP OAM-Toolset March 2011 [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. [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. [loopback] S. Boutros, S. Sivabalan, G. Swallow, R. Aggarwal, M. Vigoureux, Operating MPLS Transport Profile LSP in Loopback Mode, draft-boutros-mpls-tp-loopback-03.txt, March 2011. [lo-de] D. Frost, S. Bryant, Packet Loss and Delay Measurement for the MPLS Networks, draft-ietf-mpls-loss-delay-01, Feb. 2011. [tp-lo-de] D. Frost, S. Bryant, A Packet Loss and Delay Measurement Profile for MPLS-based Transport Networks, draft-frost-mpls-tp-loss- delay-profile-02, Feb. 2011. 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. [Page 16] MPLS-TP OAM-Toolset March 2011 [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. [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. Authors' 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 Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 USA Email: nabil.bitar@verizon.com Raymond Zhang British Telecom BT Center 81 Newgate Street London, EC1A 7AJ United Kingdom Email: raymond.zhang@bt.com Lei Wang Telenor Telenor Norway Office Snaroyveien 1331 Fornedbu Email: Lei.wang@telenor.com Kam Lee Yap [Page 17] MPLS-TP OAM-Toolset March 2011 XO Communications 13865 Sunrise Valley Drive, Herndon, VA 20171 Email: klyap@xo.com Michael Fargano Qwest 5325 Zuni St, 224 Denver CO 80221-1499 Email: Michael.Fargano@qwest.com John Drake Juniper Email: jdrake@juniper.net Thomas Nadeau Email: tnadeau@lucidvision.com [Page 18]