MPLS Working Group Fang Li (Ed) Internet Draft CATR,China Intended status: Informational Han Li (Ed) China Mobile Alessando D'Alessandro(Ed) Telecom Italia Ruiquan Jing (Ed) China Telecom Guangquan Wang(Ed) China Unicom Juan Pedro Fernandez-Palacios Gi(Ed) Telefonica I+D Expires: January 2012 July 11, 2011 Operator Considerations on MPLS-TP OAM Mechanisms draft-fang-mpls-tp-oam-considerations-02 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), 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 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Fang et al. Expires January 11, 2012 [Page 1] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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. Abstract Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is based on a profile of the MPLS and pseudo wire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), pseudo wire (PW) and multi-segment PW (MS-PW) architectures complemented with additional Operations, Administration and Maintenance (OAM) procedures for fault, performance and protection-switching management for packet transport applications that do not rely on the presence of a control plane. This document is intended to explain the criticality of progressing the essential suite of MPLS-TP OAM solution elements in order to meet the urgent and increasing requirements for metro packet transport networks. It describes examples of key packet transport network applications for several operators, reviews associated MPLS-TP service provider requirements, and analyzes MPLS-TP OAM solution approaches that have been submitted to the IETF. Based upon this, it is recommended that the solution elements described in draft-bhh- mpls-tp-oam-y1731 [6] be included within the MPLS-TP toolkit for supporting MPLS-TP OAM Functions, and that the draft be progressed as a Standards Track RFC. Table of Contents 1. Introduction.................................................3 1.1. Contributing Authors....................................4 2. Conventions used in this document............................4 2.1. Terminology.............................................4 3. PTN network Applications.....................................4 3.1. Summary of MPLS-TP based PTN Applications...............4 3.2. China Mobile............................................5 3.3. China Telecom...........................................6 3.4. China Unicom............................................6 3.5. Telecom Italia..........................................7 Fang et al. Expires January 11, 2012 [Page 2] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 3.6. Telefonica I+D..........................................7 4. Requirement of MPLS-TP OAM function toolset..................7 5. OAM solutions................................................8 5.1. draft-bhh solution approach.............................8 5.2. Extension of IP/MPLS OAM tools approach.................9 5.3. Development of new OAM tools approach..................10 6. Interoperability of draft-bhh implementations...............10 7. Considerations..............................................12 8. Proposal....................................................13 9. Security Considerations.....................................13 10. IANA Considerations........................................13 11. Acknowledgments............................................13 12. References.................................................14 12.1. Normative References..................................14 12.2. Informative References................................14 1. Introduction This document is intended to explain the criticality of progressing the essential suite of MPLS-TP OAM solution elements in order to meet the urgent and increasing requirements for metro packet transport networks (e.g. mobile backhauling). It describes examples of key packet transport network applications for several operators, reviews associated MPLS-TP network operators' requirements (which is defined in RFC5654 [1]), and analyzes MPLS-TP OAM solution approaches that have been submitted to the IETF. Based upon this, it is recommended that the solution elements described in draft-bhh-mpls-tp-oam-y1731 [6] be included within the MPLS-TP toolkit for supporting MPLS-TP OAM Functions, and that the draft be progressed as a Standards Track RFC. This solution satisfies essential MPLS-TP OAM requirements as defined in RFC5860 [3], and has been tested, validated and deployed by several operators. While draft-bhh-mpls-tp-oam-y1731 [6] documents these solution elements within a single document, the solution approach allows operators to select the particular OAM functions they wish to use. Thus, it can complement other solution elements, as it does not deprecate existing MPLS and PW OAM mechanisms or preclude definition/utilization of other MPLS-TP OAM tools. The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates Y.1731 [4] OAM PDUs within MPLS-TP packets in compliance with RFC 5586 [2] and the draft-ietf-mpls-tp-oam-framework [5]. This approach leverages ITU-T Y.1731 [4] PDUs and procedures (state machines) and IETF RFC 5586 mechanisms to provide a set of MPLS-TP OAM mechanisms that satisfy RFC5860 requirements and fit within the MPLS-TP OAM framework as described in draft-ietf-mpls-tp-oam-framework [5]. This offers an excellent example of what could be considered a cooperative product of IETF and ITU-T, which builds upon the experience of both Fang et al. Expires January 11, 2012 [Page 3] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 standards development organizations, to provide a robust and timely solution. 1.1. Contributing Authors Haiyi Zhang, Lei Wang, Yusen Yang, Pei Zhang, Andrea Di Giglio 2. Conventions used in this document 2.1. Terminology AIS Alarm Indication Signal CC Continuity Check CFI Client Failure Indication CV Connectivity Verification DM Packet Delay Measurement LB Loopback LM Packet Loss Measurement MPLS-TP MPLS Transport Profile OAM Operation, Administration and Management PTN Packet Transport Network RDI Remote Defect Indication TCM Tandem Connection Monitoring 3. PTN network Applications 3.1. Summary of MPLS-TP based PTN Applications Current requirements of operators for supporting MPLS-TP based PTN applications are mainly driven by mobile backhauling and L2 VPN services for business customers. In typical network deployments, IP-based and transport-based environments are separated. IP backbone and metro core networks are based on IP/MPLS routers, while metro aggregation and access networks are based on PTN equipments. Of these, for several operators, the Fang et al. Expires January 11, 2012 [Page 4] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 most urgent MPLS-TP application scenarios are for the PTN-based metro networks, which are separated in the existing networks from the core IP/MPLS networks. However, in the future, deployments of MPLS-TP within backbone/core networks are not precluded. The following section provides some examples of PTN applications in many operators' metro networks, to illustrate the urgent market requirement for MPLS-TP to be standardized in a reasonable way as soon as possible. Although the functionality of MPLS-TP OAM is more important than the message format of OAM, when operators began to widely deploy MPLS-TP technology, the network interworking between each vendor becomes a key concern. Usually, there are at least two vendor's equipments in one metro network. In order to provide end-to-end reliable services (such as L2 VPN) supporting OAM and protection, the requirement for standardized OAM PDU formats and procedures is urgent. Hundreds of thousands of MPLS-TP based PTN boxes are being deployed in countries such as Korea, China, Japan, India, Italy, etc. More and more operators have started/are planning to test all the available draft about MPLS-TP OAM to explore how far the proposed solutions (from standard bodies and fora) and already available vendor solutions can satisfy operators' requirements for superior protection, fault and performance management in the MPLS-TP space. Many operators are actively monitoring and contributing to the MPLS-TP standardization process with the aim to get shortly a comprehensive implementation of latest drafts as required from the market trend. While it would be desirable to converge to a single solution in the end, the viability of all protocol proposals on the table should be explored at this point. 3.2. China Mobile China Mobile had deployed 38315 PTN nodes in 138 metro networks in 2009 and has deployed more than 110,000 PTN nodes in 28 of 31 provinces's metro network till September 2010. And more than 130,000 PTN boxes will be deployed in 2011. PTN deployment speeds up in 2011 with the roll out of 3G base stations. According to the PTN OAM specifications in CCSA PTN standards and China Mobile PTN equipment requirements, the main PTN vendors have already finished the new OAM software version development based on draft-bhh-mpls-tp-oam-y1731 and passed the experimental upgrade test from ITU-T G.8114 to draft-bhh-mpls-tp-oam-y1731 in lab from May to July 2010. Fang et al. Expires January 11, 2012 [Page 5] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 In Aug. 2010, China Mobile has successfully carried out a large scale field trial whose objective was to upgrade the PTN OAM protocols based on ITU-T G.8114 to draft-bhh-mpls-tp-oam-y1731 [6]. The main PTN vendors have participated in this upgrading field trial. The trial results show that PTN OAM smoothly upgrading from ITU-T G.8114 to draft-bhh-mpls-tp-oam-y1731 is already a mature approach. Such field trial has involved 422 PTN nodes in 3 cities. Since then, such network has been running with OAM functionalities based on draft-bhh- mpls-tp-oam-y1731 without any problem. In July 2011, CMCC has successfully migrated 10,000 nodes from G.8114 PTN OAM to draft-bhh-mpls-tp-oam-y1731 PTN OAM and has deployed additional 160,000 new nodes running just draft-bhh-mpls-tp-oam-y1731 PTN OAM. PTN box deployed in 2011 will support draft-bhh only, by the end of this year, all 330,000 PTN equipments in CMCC will run draft- bhh only. In a typical China Mobile metro network, there are several thousands PTN nodes to provide wireless backhauling, broadband (PON-OLT) backhauling, 10M/100M/GE private line services. 3.3. China Telecom China Telecom has evaluated the application of PTN technologies for more than two years and concluded that Mobile backhaul and Ethernet Line service will be the main service drivers to deploy PTN. China Telecom regarded PTN technology to be mainly based on MPLS-TP. Further more it is necessary to build a PTN network that satisfies the rapidly growing mobile service (currently growing on the order of millions of customers per month) in wireless network. China Telecom has selected PTN as one of the mobile backhaul solutions for its CDMA 2000 EV-DO networks. For example, a PTN network with 2200 nodes has been built in Chongqing, Sichuan. Two commercial trial PTN networks have been built in Jiangsu and Hubei province. 3.4. China Unicom China Unicom regards PTN technology as key for multi-service transport platforms. Currently, MSTP is still the preferred transport technology for China Unicom. However, from the long-term point of view, PTN technology will be important for transport platforms. So since 2009, China Unicom has been organizing a large scale PTN testing activities to evaluate the maturity and feasibility of PTN networks. Fang et al. Expires January 11, 2012 [Page 6] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 In 2010, China Unicom has deployed PTN technology in some field trail networks. In 2011, China Unicom has started to build PTN commercial trail networks in more than 10 cities. 3.5. Telecom Italia Telecom Italia investigated PTN technologies and has been testing several vendors' PTN equipment. Telecom Italia has recently finalized a tender for acquiring PTN equipment and is going to deploy them in the second half of 2011 in its metro aggregation networks. TI is therefore interested in a fast definition of MPLS-TP specifications in order to guarantee the interworking between different implementations, particularly in respect to OAM and protection mechanisms. 3.6. Telefonica I+D Telefonica I+D, as R&D branch of Telefonica Group, is investigating end to end PTN based network architectures based on the deployment of PTN technologies in both metro aggregation and core networks. Main drivers for end to end PTN networks are: 1. Automated end to end service provisioning (e.g L2 VPNS between different metro networks) 2. Automated network failure detection and restoration by end to end OAM mechanisms MPLS-TP is one of the PTN technologies under analysis. According to it, Telefonica I+D is interested in the definition of MPLS-TP specifications enabling OAM multi-vendor compatibility in end to end MPLS-TP networks. 4. Requirement of MPLS-TP OAM function toolset From operator's view, the following OAM toolset and functionality are essential for MPLS-TP deployment for PTN applications: 1. Pro-active Continuity Check and Connectivity Verification: to support protection switching and misconnection detection; 2. Alarm and Lock reporting: to suppress pro-active CC/CV alarm storms; 3. Remote Defect Indication: to support bi-direction performance monitoring and single-ended fault management of bi-directional connections; Fang et al. Expires January 11, 2012 [Page 7] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 4. Pro-active and on-demand packet Loss/Delay Measurement: to be able to compare the PM on the same path provide by ETH OAM and MPLS-TP OAM. E.g. LM/DM should have the same behavior and results in both Ethernet and MPLS-TP; 5. Client Failure Indication(CFI): to support services where alarm propagation capabilities are not available/supported by the client traffic (e.g., EPL services connecting two CEs not supporting Ethernet OAM); 6. On-demand CV and diagnostic test: to allow service providers to localize fault (at least the Loop-back tool) and check the out-of- service test before service commissioning; 7. Tandem Connection Monitoring(TCM): for any transport path (e.g., LSPs and PWs) to support inter-domain monitoring; Note: the OAM tools of Route Tracing to support on-demand CV in connection-oriented PTN network is not needed, for the transport path can be get in the PTN NMS trail management function. 5. OAM solutions The operator's preference for a particular OAM solution depends on the application domain and their network evolution strategy. o For the PTN application domain described in this draft, the priority is maximal synergy with transport-oriented operations and managerial practices. The solution based upon draft-bhh-mpls-tp- oam-y1731 [6] is consistent with this desired optimization. o For some other operators who are evolving from an IP/MPLS environment, leveraging on IP-oriented mechanisms such as BFD and LSP-Ping is preferable (where possible to do so). Both operator viewpoints are valid and standards should be capable of providing interoperable solutions to meet the entire operator community needs. Different approaches have been submitted to the IETF standardization process and are summarized in the next sections. 5.1. draft-bhh solution approach The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates Y.1731 [4] OAM PDUs within MPLS-TP OAM packets in compliance with RFC 5586 [2] and draft-ietf-mpls-tp-oam-framework [5]. This approach leverages ITU-T Y.1731 [4] PDUs and procedures (state machines) and Fang et al. Expires January 11, 2012 [Page 8] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 IETF RFC 5586 [2] mechanisms to provide the essential set of OAM mechanisms that meet the MPLS-TP OAM requirements as defined in RFC 5860 [3]. ITU-T Recommendation Y.1731 [4] specifies: o OAM PDUs and procedures that meet the transport networks requirements for OAM o Encapsulation mechanisms to carry these OAM PDUs within Ethernet frames to provide Ethernet OAM capabilities in Ethernet networks The first release of ITU-T Rec. Y.1731 [4] was approved in May 2006. This Recommendation meets the operator's OAM requirements for supporting end-to-end Ethernet services, which represents the most popular and increasing market for operators and services providers. Although Y.1731 [4] is focused on Ethernet service OAM, the definition of OAM PDUs and procedures are technology independent and can also be used for other packet technologies (e.g., MPLS-TP) provided that the technology specific encapsulation is defined. The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates Y.1731 [4] OAM PDUs within MPLS-TP packets in compliance with RFC 5586 [2] and draft-ietf-mpls-tp-oam-framework [5] (i.e., the OAM PDUs are carried over the G-ACH [2]). While draft-bhh-mpls-tp-oam-y1731 [6] documents these solution elements within a single document, the solution approach allows operators to select the particular OAM functions they wish to use. Thus, it can complement other solution elements, as it does not deprecate existing MPLS and PW OAM mechanisms or preclude definition/utilization of other MPLS-TP OAM tools. 5.2. Extension of IP/MPLS OAM tools approach Another solution approach is to extend IP/MPLS OAM tools to meet the MPLS-TP OAM requirements as defined in RFC 5860 [3]. Some work in this direction is ongoing in draft-ietf-mpls-tp-cc-cv- rdi [7] and draft-ietf-mpls-tp-on-demand-cv [9]. This approach is currently limited to support only the pro-active CC, CV, RDI and on-demand CV and tracerouting functions as defined in RFC 5860 [3]. So far a lot of technical difficulties have been encountered in meeting some important transport requirements and behaviours, while maintaining backward compatibility with existing BFD and LSP Ping implementations. Those technical difficulties have not been resolved Fang et al. Expires January 11, 2012 [Page 9] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 even during MPLS WG Last Call and the solution drafts that have been moved toward IESG Processing still do not meet the transport networks' needs for several service providers. 5.3. Development of new OAM tools approach For other OAM functions described in RFC 5860 [3] and not covered by the extensions of existing IP/MPLS OAM tools (mentioned in section 5.2), new tools would need to be developed. A series of separated drafts have been submitted with different maturity levels and there are some overlaps and inconsistencies that need to be resolved. These drafts appear to re-use some Y.1731 [4] information elements (e.g., draft-ietf-mpls-tp-loss-delay-profile [8]). 6. Interoperability of draft-bhh implementations As discussed earlier, interoperability testing of multi-vendor implementations continues to be conducted by various operators. Public interoperability events have also been conducted, as described below. In Sep. 2009 CEWC, EANTC conducted an MPLS-TP interoperability test and reported: "Different solutions have been proposed in individual author drafts such as draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi [10] and draft-bhh-mpls-tp-oam-y1731 [6], however the working group has not yet accepted these documents as IETF working group drafts. The purpose of EANTC's effort is to evaluate the current status of the industry and to examine progress made since their last test in February. The two OAM proposals tested have received substantial vendor and service provider backing, so EANTC were able to stage multi-vendor interoperability tests. The Alcatel-Lucent 1850 TSS-160, Alcatel-Lucent 1850 TSS-320, and Huawei PTN 3900 successfully tested an interoperable OAM solution based on the draft-bhh-mpls-tp-oam- y1731 [6] which proposes modifications to Ethernet OAM tools as defined in ITU-T Y.1731 [4] for use with MPLS-TP OAM. The enhanced BFD protocol was used to check the continuity (liveliness) of the MPLS-TP LSP established between the Ericsson devices. Both OAM solutions were verified for the use of GAL and G-ACh." Fang et al. Expires January 11, 2012 [Page 10] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 The EANTC whitepaper can be getting at: http://www.eantc.com/fileadmin/eantc/downloads/events/2007- 2010/CEWC09/EANTC-CEWC2009-WhitePaper-v1_2.pdf (P.16~17). In Feb. 2010 MPLS &Ethernet WC, EANTC conducted another MPLS-TP interoperability test and reported: "EANTC tested the MPLS-TP OAM approach supported by Alcatel-Lucent, Huawei, and ZTE based on Y.1731 [4]. The Alcatel-Lucent 1850 TSS- 320, Huawei PTN 3900, and ZTE ZXCTN 6100 all successfully tested interoperability for their MPLS-TP OAM implementations, based on ITU- T Y.1731 which defines a protocol for Ethernet OAM. EANTC tested this by first verifying that the protocol was used by all vendors to establish connectivity on the respective MPLS-TP transport path, and their ability to switch over to a backup transport path upon loss of such connectivity. Between those devices was a LAN segment, to make sure that the trigger was the loss of CCM frames (not the LOS)." The EANTC whitepaper can be getting at: http://www.eantc.com/fileadmin/eantc/downloads/events/2007- 2010/MPLSEWC2010/EANTC-MPLSEWC2010-WhitePaper.pdf (P.13~14). In Sep. 2010 CEWC, EANTC conducted an MPLS-TP 1:1 LSP protection interoperability test and reported: "Most recently, one of the author drafts for a Bidirectional Forwarding Detection (BFD) based OAM titled 'Proactive Connection Verification, Continuity Check and Remote Defect Indication for MPLS Transport Profile' has been accepted by the IETF MPLS working group. In parallel, a series of vendors registered to the interop event ready to test their OAM solutions based on ITU-T Recommendation Y.1731[6]". "In order to perform this test several multi-vendors pairs were built... The observed failover times ranged between 13 to 28 ms for link failure. The OAM tools from these vendors was based on draft- bhh-mpls-tp-oam-y1731 and the linear protection was tested according to draft-zulr-mpls-tp-linear-protection-switching-01." The EANTC whitepaper can be downloaded at: http://www.eantc.de/fileadmin/eantc/downloads/events/2007- 2010/CEWC2010/EANTC-CEWC2010-WhitePaper-v1_1.pdf (P.17~18) Fang et al. Expires January 11, 2012 [Page 11] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 7. Considerations For PTN-based metro aggregation and access networks, the OAM mechanisms defined in draft-bhh-mpls-tp-oam-y1731 [6] fully satisfy all the essential MPLS-TP OAM requirements. The operators who have contributed to this draft fully support global standards, and have relied upon the work of ITU-T and IETF. For this reason, full support was given to the JWT agreement reached between ITU-T and IETF, whose goal was to define the required MPLS-TP standard solutions by October 2009. However, after waiting for over two years, the essential solutions are still not available, and based on the ongoing technical discussions there is great concern that a solution will not be available in time for the planned deployments. MPLS-TP based PTN significant deployment has started in this year. There is urgency for standard MPLS-TP solutions this year to support PTN applications, which are based on mature, multi-vendor interoperable and tested mechanisms and procedures. The maturity of OAM mechanisms is a key concern for operators. The OAM toolset defined in Y.1731 [4] has emerged as a high benchmark for OAM capabilities for support of managed end-to-end Ethernet services. Using the approach in draft-bhh-mpls-tp-oam-y1731 [6], which is based on proven ITU-T Y.1731 [4] OAM mechanisms and procedures, can help the industry in providing MPLS-TP technology in time to meet market needs. Also, for those operators who will have their PTN network managed and maintained by their transport staff, this approach offers the most expedient way to deploy MPLS-TP technology, as the mechanisms defined in draft-bhh-mpls-tp-oam-y1731 [6] are very similar to those of transport OAM. Operator's OAM preference depends on the application domains, network evolution strategy, etc. The roadmap for OAM toolset standardization based on re-use of IP tools and development of new tools does not meet the market needs of some operators like China Mobile, Telecom Italia, China Telecom and China Unicom, and therefore, for the sake of satisfying market needs, the solution described in draft-bhh-mpls- tp-oam-y1731 [6], which leverages existing ITU-T and IETF standards, should be taken into account. In June 2010, during the ITU-T SG15 meeting, some members asked ITU-T to liaise IETF the request to provide roadmap for MPLS-TP OAM toolset and related internet drafts by sending a liaison to IETF. However, roadmap was not clarified by IETF during the IETF 78 and in the response liaison. Moreover no action was taken about the proposal to get draft-bhh- mpls-tp-oam-y1731 [6] included within the MPLS-TP toolkit although Fang et al. Expires January 11, 2012 [Page 12] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 the discussion during the MPLS-TP sessions had been heavily focused on MPLS-TP OAM and many operators and vendors expressed a clear support for draft-bhh-mpls-tp-oam-y1731[6]. Currently, the schedule for completion of MPLS-TP OAM toolsets and related drafts/RFCs in IETF is not clear so negatively affecting the MPLS-TP standardization process in both IETF and ITU-T and the telecommunication industry as a whole. As discussed earlier, this proposal allows operators to select the particular OAM functions they wish to use, and can complement other MPLS-TP OAM solution elements currently under definition in the IETF. 8. Proposal This Informational Internet-Draft is aimed at moving forward the progress of an essential MPLS-TP OAM solution set to meet the urgent and increasing requirements of PTN applications for the metro packet transport network. Therefore, it is recommended that the solution elements described in draft-bhh-mpls-tp-oam-y1731 [6] be included within the MPLS-TP toolkit for supporting MPLS-TP OAM Functions, and that the draft be progressed as a Standards Track RFC. 9. Security Considerations There are not any security considerations in this draft. 10. IANA Considerations No new IANA considerations. 11. Acknowledgments The authors would like to thank the good cooperation between IETF and ITU-T and thanks all IETF experts and ITU-T experts work on MPLS-TP technology to push MPLS-TP standard rapidly. Fang et al. Expires January 11, 2012 [Page 13] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 12. References 12.1. Normative References [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., Ueno, S., "MPLS-TP Requirements", RFC 5654, September 2009 [2] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., "MPLS Generic Associated Channel", RFC 5586, June 2009 [3] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", RFC 5860, May, 2010 [4] ITU-T Recommendation Y.1731 (02/2008), " OAM functions and mechanisms for Ethernet based networks ", Feb,2008 [5] I. Busi, B. Niven-Jenkins, D. Allan," MPLS-TP OAM Framework",draft-ietf-mpls-tp-oam-framework-11 (work in progress) [6] I. Busi, H. van Helvoort, J.He "MPLS-TP OAM based on Y.1731", draft-bhh-mpls-tp-oam-y1731-06 (work in progress) 12.2. Informative References [7] Dave Allan, George Swallow, John Drake, "Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile" draft-ietf-mpls-tp-cc-cv-rdi-05 (work in progress) [8] Dan Frost, Stewart Bryant, "Packet Loss and Delay Measurement for the MPLS Transport Profile" draft-ietf-mpls-tp-loss-delay- profile-03 (work in progress) [9] N. Bahadur, R. Aggarwal, S. Boutros, E. Gray, "LSP-Ping extensions for MPLS-TP" draft-ietf-mpls-tp-on-demand-cv-05 (work in progress) [10] A. Fulignoli , S. Boutros , M.Vigoureux ," MPLS-TP BFD for Proactive CC-CV and RDI ",draft-fulignoli-mpls-tp-bfd-cv- proactive-and-rdi-01 (expired and merged into draft-ietf-mpls- tp-cc-cv-rdi; work in progress) Fang et al. Expires January 11, 2012 [Page 14] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 Authors' Addresses Fang Li (Editor) China Academy of Telecommunication Research, P.R.China Email: lifang@catr.cn Han Li (Editor) China Moblie Email: lihan@chinamobile.com Alessando D'Alessandro (Editor) Telecom Italia Email: alessandro.dalessandro@telecomitalia.it Guangquan WANG (Editor) China Unicom Email: wanggq@dimpt.com Ruiquan Jing (Editor) China telecom Email: jingrq@ctbri.com.cn Juan Pedro Fernandez-Palacios Gi Telefonica I+D Email: jpfpg@tid.es Contributing Authors' Addresses Haiyi Zhang China Academy of Telecommunication Research, P.R.China Email: zhanghaiyi@catr.cn Fang et al. Expires January 11, 2012 [Page 15] Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 2011 Lei Wang China Mobile Email: wangleiyj@chinamobile.com Pei zhang China Unicom Email: hq-zhangp@chinaunicom.cn Yusen Yang China Telecom Email: yangys@chinatelecom.com.cn Andrea Di Giglio Telecom Italia Email: andrea.digiglio@telecomitalia.it Fang et al. Expires January 11, 2012 [Page 16]