idnits 2.17.1 draft-fang-mpls-tp-oam-considerations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4673 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-bhh-mpls-tp-oam-y1731-06 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-cc-cv-rdi-05 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-tp-loss-delay-profile-03 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-on-demand-cv-05 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Fang Li (Ed) 2 Internet Draft CATR,China 3 Intended status: Informational Han Li (Ed) 4 China Mobile 5 Alessando D'Alessandro(Ed) 6 Telecom Italia 7 Ruiquan Jing (Ed) 8 China Telecom 9 Guangquan Wang(Ed) 10 China Unicom 11 Juan Pedro Fernandez-Palacios Gi(Ed) 12 Telefonica I+D 14 Expires: January 2012 July 11, 2011 16 Operator Considerations on MPLS-TP OAM Mechanisms 17 draft-fang-mpls-tp-oam-considerations-02 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 48 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 49 2011 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Abstract 65 Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is 66 based on a profile of the MPLS and pseudo wire (PW) procedures as 67 specified in the MPLS Traffic Engineering (MPLS-TE), pseudo wire (PW) 68 and multi-segment PW (MS-PW) architectures complemented with 69 additional Operations, Administration and Maintenance (OAM) 70 procedures for fault, performance and protection-switching management 71 for packet transport applications that do not rely on the presence of 72 a control plane. 74 This document is intended to explain the criticality of progressing 75 the essential suite of MPLS-TP OAM solution elements in order to meet 76 the urgent and increasing requirements for metro packet transport 77 networks. It describes examples of key packet transport network 78 applications for several operators, reviews associated MPLS-TP 79 service provider requirements, and analyzes MPLS-TP OAM solution 80 approaches that have been submitted to the IETF. Based upon this, it 81 is recommended that the solution elements described in draft-bhh- 82 mpls-tp-oam-y1731 [6] be included within the MPLS-TP toolkit for 83 supporting MPLS-TP OAM Functions, and that the draft be progressed as 84 a Standards Track RFC. 86 Table of Contents 88 1. Introduction.................................................3 89 1.1. Contributing Authors....................................4 90 2. Conventions used in this document............................4 91 2.1. Terminology.............................................4 92 3. PTN network Applications.....................................4 93 3.1. Summary of MPLS-TP based PTN Applications...............4 94 3.2. China Mobile............................................5 95 3.3. China Telecom...........................................6 96 3.4. China Unicom............................................6 97 3.5. Telecom Italia..........................................7 99 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 100 2011 101 3.6. Telefonica I+D..........................................7 102 4. Requirement of MPLS-TP OAM function toolset..................7 103 5. OAM solutions................................................8 104 5.1. draft-bhh solution approach.............................8 105 5.2. Extension of IP/MPLS OAM tools approach.................9 106 5.3. Development of new OAM tools approach..................10 107 6. Interoperability of draft-bhh implementations...............10 108 7. Considerations..............................................12 109 8. Proposal....................................................13 110 9. Security Considerations.....................................13 111 10. IANA Considerations........................................13 112 11. Acknowledgments............................................13 113 12. References.................................................14 114 12.1. Normative References..................................14 115 12.2. Informative References................................14 117 1. Introduction 119 This document is intended to explain the criticality of progressing 120 the essential suite of MPLS-TP OAM solution elements in order to meet 121 the urgent and increasing requirements for metro packet transport 122 networks (e.g. mobile backhauling). It describes examples of key 123 packet transport network applications for several operators, reviews 124 associated MPLS-TP network operators' requirements (which is defined 125 in RFC5654 [1]), and analyzes MPLS-TP OAM solution approaches that 126 have been submitted to the IETF. Based upon this, it is recommended 127 that the solution elements described in draft-bhh-mpls-tp-oam-y1731 128 [6] be included within the MPLS-TP toolkit for supporting MPLS-TP OAM 129 Functions, and that the draft be progressed as a Standards Track RFC. 131 This solution satisfies essential MPLS-TP OAM requirements as defined 132 in RFC5860 [3], and has been tested, validated and deployed by 133 several operators. While draft-bhh-mpls-tp-oam-y1731 [6] documents 134 these solution elements within a single document, the solution 135 approach allows operators to select the particular OAM functions they 136 wish to use. Thus, it can complement other solution elements, as it 137 does not deprecate existing MPLS and PW OAM mechanisms or preclude 138 definition/utilization of other MPLS-TP OAM tools. 140 The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates 141 Y.1731 [4] OAM PDUs within MPLS-TP packets in compliance with RFC 142 5586 [2] and the draft-ietf-mpls-tp-oam-framework [5]. This approach 143 leverages ITU-T Y.1731 [4] PDUs and procedures (state machines) and 144 IETF RFC 5586 mechanisms to provide a set of MPLS-TP OAM mechanisms 145 that satisfy RFC5860 requirements and fit within the MPLS-TP OAM 146 framework as described in draft-ietf-mpls-tp-oam-framework [5]. This 147 offers an excellent example of what could be considered a cooperative 148 product of IETF and ITU-T, which builds upon the experience of both 150 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 151 2011 152 standards development organizations, to provide a robust and timely 153 solution. 155 1.1. Contributing Authors 157 Haiyi Zhang, Lei Wang, Yusen Yang, Pei Zhang, Andrea Di Giglio 159 2. Conventions used in this document 161 2.1. Terminology 163 AIS Alarm Indication Signal 165 CC Continuity Check 167 CFI Client Failure Indication 169 CV Connectivity Verification 171 DM Packet Delay Measurement 173 LB Loopback 175 LM Packet Loss Measurement 177 MPLS-TP MPLS Transport Profile 179 OAM Operation, Administration and Management 181 PTN Packet Transport Network 183 RDI Remote Defect Indication 185 TCM Tandem Connection Monitoring 187 3. PTN network Applications 189 3.1. Summary of MPLS-TP based PTN Applications 191 Current requirements of operators for supporting MPLS-TP based PTN 192 applications are mainly driven by mobile backhauling and L2 VPN 193 services for business customers. 195 In typical network deployments, IP-based and transport-based 196 environments are separated. IP backbone and metro core networks are 197 based on IP/MPLS routers, while metro aggregation and access networks 198 are based on PTN equipments. Of these, for several operators, the 200 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 201 2011 202 most urgent MPLS-TP application scenarios are for the PTN-based metro 203 networks, which are separated in the existing networks from the core 204 IP/MPLS networks. However, in the future, deployments of MPLS-TP 205 within backbone/core networks are not precluded. 207 The following section provides some examples of PTN applications in 208 many operators' metro networks, to illustrate the urgent market 209 requirement for MPLS-TP to be standardized in a reasonable way as 210 soon as possible. 212 Although the functionality of MPLS-TP OAM is more important than the 213 message format of OAM, when operators began to widely deploy MPLS-TP 214 technology, the network interworking between each vendor becomes a 215 key concern. Usually, there are at least two vendor's equipments in 216 one metro network. In order to provide end-to-end reliable services 217 (such as L2 VPN) supporting OAM and protection, the requirement for 218 standardized OAM PDU formats and procedures is urgent. 220 Hundreds of thousands of MPLS-TP based PTN boxes are being deployed 221 in countries such as Korea, China, Japan, India, Italy, etc. More and 222 more operators have started/are planning to test all the available 223 draft about MPLS-TP OAM to explore how far the proposed solutions 224 (from standard bodies and fora) and already available vendor 225 solutions can satisfy operators' requirements for superior protection, 226 fault and performance management in the MPLS-TP space. Many operators 227 are actively monitoring and contributing to the MPLS-TP 228 standardization process with the aim to get shortly a comprehensive 229 implementation of latest drafts as required from the market trend. 230 While it would be desirable to converge to a single solution in the 231 end, the viability of all protocol proposals on the table should be 232 explored at this point. 234 3.2. China Mobile 236 China Mobile had deployed 38315 PTN nodes in 138 metro networks in 237 2009 and has deployed more than 110,000 PTN nodes in 28 of 31 238 provinces's metro network till September 2010. And more than 130,000 239 PTN boxes will be deployed in 2011. PTN deployment speeds up in 2011 240 with the roll out of 3G base stations. 242 According to the PTN OAM specifications in CCSA PTN standards and 243 China Mobile PTN equipment requirements, the main PTN vendors have 244 already finished the new OAM software version development based on 245 draft-bhh-mpls-tp-oam-y1731 and passed the experimental upgrade test 246 from ITU-T G.8114 to draft-bhh-mpls-tp-oam-y1731 in lab from May to 247 July 2010. 249 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 250 2011 251 In Aug. 2010, China Mobile has successfully carried out a large scale 252 field trial whose objective was to upgrade the PTN OAM protocols 253 based on ITU-T G.8114 to draft-bhh-mpls-tp-oam-y1731 [6]. The main 254 PTN vendors have participated in this upgrading field trial. The 255 trial results show that PTN OAM smoothly upgrading from ITU-T G.8114 256 to draft-bhh-mpls-tp-oam-y1731 is already a mature approach. Such 257 field trial has involved 422 PTN nodes in 3 cities. Since then, such 258 network has been running with OAM functionalities based on draft-bhh- 259 mpls-tp-oam-y1731 without any problem. 261 In July 2011, CMCC has successfully migrated 10,000 nodes from G.8114 262 PTN OAM to draft-bhh-mpls-tp-oam-y1731 PTN OAM and has deployed 263 additional 160,000 new nodes running just draft-bhh-mpls-tp-oam-y1731 264 PTN OAM. PTN box deployed in 2011 will support draft-bhh only, by the 265 end of this year, all 330,000 PTN equipments in CMCC will run draft- 266 bhh only. 268 In a typical China Mobile metro network, there are several thousands 269 PTN nodes to provide wireless backhauling, broadband (PON-OLT) 270 backhauling, 10M/100M/GE private line services. 272 3.3. China Telecom 274 China Telecom has evaluated the application of PTN technologies for 275 more than two years and concluded that Mobile backhaul and Ethernet 276 Line service will be the main service drivers to deploy PTN. China 277 Telecom regarded PTN technology to be mainly based on MPLS-TP. 278 Further more it is necessary to build a PTN network that satisfies 279 the rapidly growing mobile service (currently growing on the order of 280 millions of customers per month) in wireless network. 282 China Telecom has selected PTN as one of the mobile backhaul 283 solutions for its CDMA 2000 EV-DO networks. For example, a PTN 284 network with 2200 nodes has been built in Chongqing, Sichuan. Two 285 commercial trial PTN networks have been built in Jiangsu and Hubei 286 province. 288 3.4. China Unicom 290 China Unicom regards PTN technology as key for multi-service 291 transport platforms. Currently, MSTP is still the preferred transport 292 technology for China Unicom. However, from the long-term point of 293 view, PTN technology will be important for transport platforms. So 294 since 2009, China Unicom has been organizing a large scale PTN 295 testing activities to evaluate the maturity and feasibility of PTN 296 networks. 298 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 299 2011 300 In 2010, China Unicom has deployed PTN technology in some field trail 301 networks. In 2011, China Unicom has started to build PTN commercial 302 trail networks in more than 10 cities. 304 3.5. Telecom Italia 306 Telecom Italia investigated PTN technologies and has been testing 307 several vendors' PTN equipment. Telecom Italia has recently 308 finalized a tender for acquiring PTN equipment and is going to deploy 309 them in the second half of 2011 in its metro aggregation networks. TI 310 is therefore interested in a fast definition of MPLS-TP 311 specifications in order to guarantee the interworking between 312 different implementations, particularly in respect to OAM and 313 protection mechanisms. 315 3.6. Telefonica I+D 317 Telefonica I+D, as R&D branch of Telefonica Group, is investigating 318 end to end PTN based network architectures based on the deployment of 319 PTN technologies in both metro aggregation and core networks. Main 320 drivers for end to end PTN networks are: 322 1. Automated end to end service provisioning (e.g L2 VPNS between 323 different metro networks) 325 2. Automated network failure detection and restoration by end to end 326 OAM mechanisms 328 MPLS-TP is one of the PTN technologies under analysis. According to 329 it, Telefonica I+D is interested in the definition of MPLS-TP 330 specifications enabling OAM multi-vendor compatibility in end to end 331 MPLS-TP networks. 333 4. Requirement of MPLS-TP OAM function toolset 335 From operator's view, the following OAM toolset and functionality are 336 essential for MPLS-TP deployment for PTN applications: 338 1. Pro-active Continuity Check and Connectivity Verification: to 339 support protection switching and misconnection detection; 341 2. Alarm and Lock reporting: to suppress pro-active CC/CV alarm 342 storms; 344 3. Remote Defect Indication: to support bi-direction performance 345 monitoring and single-ended fault management of bi-directional 346 connections; 348 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 349 2011 350 4. Pro-active and on-demand packet Loss/Delay Measurement: to be able 351 to compare the PM on the same path provide by ETH OAM and MPLS-TP 352 OAM. E.g. LM/DM should have the same behavior and results in both 353 Ethernet and MPLS-TP; 355 5. Client Failure Indication(CFI): to support services where alarm 356 propagation capabilities are not available/supported by the client 357 traffic (e.g., EPL services connecting two CEs not supporting 358 Ethernet OAM); 360 6. On-demand CV and diagnostic test: to allow service providers to 361 localize fault (at least the Loop-back tool) and check the out-of- 362 service test before service commissioning; 364 7. Tandem Connection Monitoring(TCM): for any transport path (e.g., 365 LSPs and PWs) to support inter-domain monitoring; 367 Note: the OAM tools of Route Tracing to support on-demand CV in 368 connection-oriented PTN network is not needed, for the transport path 369 can be get in the PTN NMS trail management function. 371 5. OAM solutions 373 The operator's preference for a particular OAM solution depends on 374 the application domain and their network evolution strategy. 376 o For the PTN application domain described in this draft, the 377 priority is maximal synergy with transport-oriented operations and 378 managerial practices. The solution based upon draft-bhh-mpls-tp- 379 oam-y1731 [6] is consistent with this desired optimization. 381 o For some other operators who are evolving from an IP/MPLS 382 environment, leveraging on IP-oriented mechanisms such as BFD and 383 LSP-Ping is preferable (where possible to do so). 385 Both operator viewpoints are valid and standards should be capable of 386 providing interoperable solutions to meet the entire operator 387 community needs. 389 Different approaches have been submitted to the IETF standardization 390 process and are summarized in the next sections. 392 5.1. draft-bhh solution approach 394 The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates 395 Y.1731 [4] OAM PDUs within MPLS-TP OAM packets in compliance with RFC 396 5586 [2] and draft-ietf-mpls-tp-oam-framework [5]. This approach 397 leverages ITU-T Y.1731 [4] PDUs and procedures (state machines) and 399 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 400 2011 401 IETF RFC 5586 [2] mechanisms to provide the essential set of OAM 402 mechanisms that meet the MPLS-TP OAM requirements as defined in RFC 403 5860 [3]. 405 ITU-T Recommendation Y.1731 [4] specifies: 407 o OAM PDUs and procedures that meet the transport networks 408 requirements for OAM 410 o Encapsulation mechanisms to carry these OAM PDUs within Ethernet 411 frames to provide Ethernet OAM capabilities in Ethernet networks 413 The first release of ITU-T Rec. Y.1731 [4] was approved in May 2006. 414 This Recommendation meets the operator's OAM requirements for 415 supporting end-to-end Ethernet services, which represents the most 416 popular and increasing market for operators and services providers. 418 Although Y.1731 [4] is focused on Ethernet service OAM, the 419 definition of OAM PDUs and procedures are technology independent and 420 can also be used for other packet technologies (e.g., MPLS-TP) 421 provided that the technology specific encapsulation is defined. 423 The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates 424 Y.1731 [4] OAM PDUs within MPLS-TP packets in compliance with RFC 425 5586 [2] and draft-ietf-mpls-tp-oam-framework [5] (i.e., the OAM PDUs 426 are carried over the G-ACH [2]). 428 While draft-bhh-mpls-tp-oam-y1731 [6] documents these solution 429 elements within a single document, the solution approach allows 430 operators to select the particular OAM functions they wish to use. 431 Thus, it can complement other solution elements, as it does not 432 deprecate existing MPLS and PW OAM mechanisms or preclude 433 definition/utilization of other MPLS-TP OAM tools. 435 5.2. Extension of IP/MPLS OAM tools approach 437 Another solution approach is to extend IP/MPLS OAM tools to meet the 438 MPLS-TP OAM requirements as defined in RFC 5860 [3]. 440 Some work in this direction is ongoing in draft-ietf-mpls-tp-cc-cv- 441 rdi [7] and draft-ietf-mpls-tp-on-demand-cv [9]. This approach is 442 currently limited to support only the pro-active CC, CV, RDI and 443 on-demand CV and tracerouting functions as defined in RFC 5860 [3]. 445 So far a lot of technical difficulties have been encountered in 446 meeting some important transport requirements and behaviours, while 447 maintaining backward compatibility with existing BFD and LSP Ping 448 implementations. Those technical difficulties have not been resolved 450 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 451 2011 452 even during MPLS WG Last Call and the solution drafts that have been 453 moved toward IESG Processing still do not meet the transport 454 networks' needs for several service providers. 456 5.3. Development of new OAM tools approach 458 For other OAM functions described in RFC 5860 [3] and not covered by 459 the extensions of existing IP/MPLS OAM tools (mentioned in section 460 5.2), new tools would need to be developed. 462 A series of separated drafts have been submitted with different 463 maturity levels and there are some overlaps and inconsistencies that 464 need to be resolved. These drafts appear to re-use some Y.1731 [4] 465 information elements (e.g., draft-ietf-mpls-tp-loss-delay-profile 466 [8]). 468 6. Interoperability of draft-bhh implementations 470 As discussed earlier, interoperability testing of multi-vendor 471 implementations continues to be conducted by various operators. 473 Public interoperability events have also been conducted, as described 474 below. 476 In Sep. 2009 CEWC, EANTC conducted an MPLS-TP interoperability test 477 and reported: 479 "Different solutions have been proposed in individual author drafts 480 such as draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi [10] and 481 draft-bhh-mpls-tp-oam-y1731 [6], however the working group has not 482 yet accepted these documents as IETF working group drafts. The 483 purpose of EANTC's effort is to evaluate the current status of the 484 industry and to examine progress made since their last test in 485 February. The two OAM proposals tested have received substantial 486 vendor and service provider backing, so EANTC were able to stage 487 multi-vendor interoperability tests. The Alcatel-Lucent 1850 TSS-160, 488 Alcatel-Lucent 1850 TSS-320, and Huawei PTN 3900 successfully tested 489 an interoperable OAM solution based on the draft-bhh-mpls-tp-oam- 490 y1731 [6] which proposes modifications to Ethernet OAM tools as 491 defined in ITU-T Y.1731 [4] for use with MPLS-TP OAM. The enhanced 492 BFD protocol was used to check the continuity (liveliness) of the 493 MPLS-TP LSP established between the Ericsson devices. Both OAM 494 solutions were verified for the use of GAL and G-ACh." 496 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 497 2011 498 The EANTC whitepaper can be getting at: 500 http://www.eantc.com/fileadmin/eantc/downloads/events/2007- 501 2010/CEWC09/EANTC-CEWC2009-WhitePaper-v1_2.pdf (P.16~17). 503 In Feb. 2010 MPLS &Ethernet WC, EANTC conducted another MPLS-TP 504 interoperability test and reported: 506 "EANTC tested the MPLS-TP OAM approach supported by Alcatel-Lucent, 507 Huawei, and ZTE based on Y.1731 [4]. The Alcatel-Lucent 1850 TSS- 508 320, Huawei PTN 3900, and ZTE ZXCTN 6100 all successfully tested 509 interoperability for their MPLS-TP OAM implementations, based on ITU- 510 T Y.1731 which defines a protocol for Ethernet OAM. EANTC tested 511 this by first verifying that the protocol was used by all vendors to 512 establish connectivity on the respective MPLS-TP transport path, and 513 their ability to switch over to a backup transport path upon loss of 514 such connectivity. Between those devices was a LAN segment, to make 515 sure that the trigger was the loss of CCM frames (not the LOS)." 517 The EANTC whitepaper can be getting at: 519 http://www.eantc.com/fileadmin/eantc/downloads/events/2007- 520 2010/MPLSEWC2010/EANTC-MPLSEWC2010-WhitePaper.pdf (P.13~14). 522 In Sep. 2010 CEWC, EANTC conducted an MPLS-TP 1:1 LSP protection 523 interoperability test and reported: 525 "Most recently, one of the author drafts for a Bidirectional 526 Forwarding Detection (BFD) based OAM titled 'Proactive Connection 527 Verification, Continuity Check and Remote Defect Indication for MPLS 528 Transport Profile' has been accepted by the IETF MPLS working group. 529 In parallel, a series of vendors registered to the interop event 530 ready to test their OAM solutions based on ITU-T Recommendation 531 Y.1731[6]". 533 "In order to perform this test several multi-vendors pairs were 534 built... The observed failover times ranged between 13 to 28 ms for 535 link failure. The OAM tools from these vendors was based on draft- 536 bhh-mpls-tp-oam-y1731 and the linear protection was tested according 537 to draft-zulr-mpls-tp-linear-protection-switching-01." 539 The EANTC whitepaper can be downloaded at: 541 http://www.eantc.de/fileadmin/eantc/downloads/events/2007- 542 2010/CEWC2010/EANTC-CEWC2010-WhitePaper-v1_1.pdf (P.17~18) 544 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 545 2011 546 7. Considerations 548 For PTN-based metro aggregation and access networks, the OAM 549 mechanisms defined in draft-bhh-mpls-tp-oam-y1731 [6] fully satisfy 550 all the essential MPLS-TP OAM requirements. 552 The operators who have contributed to this draft fully support global 553 standards, and have relied upon the work of ITU-T and IETF. For this 554 reason, full support was given to the JWT agreement reached between 555 ITU-T and IETF, whose goal was to define the required MPLS-TP 556 standard solutions by October 2009. However, after waiting for over 557 two years, the essential solutions are still not available, and based 558 on the ongoing technical discussions there is great concern that a 559 solution will not be available in time for the planned deployments. 560 MPLS-TP based PTN significant deployment has started in this year. 561 There is urgency for standard MPLS-TP solutions this year to support 562 PTN applications, which are based on mature, multi-vendor 563 interoperable and tested mechanisms and procedures. 565 The maturity of OAM mechanisms is a key concern for operators. The 566 OAM toolset defined in Y.1731 [4] has emerged as a high benchmark for 567 OAM capabilities for support of managed end-to-end Ethernet services. 568 Using the approach in draft-bhh-mpls-tp-oam-y1731 [6], which is based 569 on proven ITU-T Y.1731 [4] OAM mechanisms and procedures, can help 570 the industry in providing MPLS-TP technology in time to meet market 571 needs. Also, for those operators who will have their PTN network 572 managed and maintained by their transport staff, this approach offers 573 the most expedient way to deploy MPLS-TP technology, as the 574 mechanisms defined in draft-bhh-mpls-tp-oam-y1731 [6] are very 575 similar to those of transport OAM. 577 Operator's OAM preference depends on the application domains, network 578 evolution strategy, etc. The roadmap for OAM toolset standardization 579 based on re-use of IP tools and development of new tools does not 580 meet the market needs of some operators like China Mobile, Telecom 581 Italia, China Telecom and China Unicom, and therefore, for the sake 582 of satisfying market needs, the solution described in draft-bhh-mpls- 583 tp-oam-y1731 [6], which leverages existing ITU-T and IETF standards, 584 should be taken into account. 586 In June 2010, during the ITU-T SG15 meeting, some members asked ITU-T 587 to liaise IETF the request to provide roadmap for MPLS-TP OAM toolset 588 and related internet drafts by sending a liaison to IETF. However, 589 roadmap was not clarified by IETF during the IETF 78 and in the 590 response liaison. 592 Moreover no action was taken about the proposal to get draft-bhh- 593 mpls-tp-oam-y1731 [6] included within the MPLS-TP toolkit although 595 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 596 2011 597 the discussion during the MPLS-TP sessions had been heavily focused 598 on MPLS-TP OAM and many operators and vendors expressed a clear 599 support for draft-bhh-mpls-tp-oam-y1731[6]. 601 Currently, the schedule for completion of MPLS-TP OAM toolsets and 602 related drafts/RFCs in IETF is not clear so negatively affecting the 603 MPLS-TP standardization process in both IETF and ITU-T and the 604 telecommunication industry as a whole. 606 As discussed earlier, this proposal allows operators to select the 607 particular OAM functions they wish to use, and can complement other 608 MPLS-TP OAM solution elements currently under definition in the IETF. 610 8. Proposal 612 This Informational Internet-Draft is aimed at moving forward the 613 progress of an essential MPLS-TP OAM solution set to meet the urgent 614 and increasing requirements of PTN applications for the metro packet 615 transport network. Therefore, it is recommended that the solution 616 elements described in draft-bhh-mpls-tp-oam-y1731 [6] be included 617 within the MPLS-TP toolkit for supporting MPLS-TP OAM Functions, and 618 that the draft be progressed as a Standards Track RFC. 620 9. Security Considerations 622 There are not any security considerations in this draft. 624 10. IANA Considerations 626 No new IANA considerations. 628 11. Acknowledgments 630 The authors would like to thank the good cooperation between IETF and 631 ITU-T and thanks all IETF experts and ITU-T experts work on MPLS-TP 632 technology to push MPLS-TP standard rapidly. 634 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 635 2011 636 12. References 638 12.1. Normative References 640 [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., Ueno, 641 S., "MPLS-TP Requirements", RFC 5654, September 2009 643 [2] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., 644 "MPLS Generic Associated Channel", RFC 5586, June 2009 646 [3] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 647 MPLS Transport Networks", RFC 5860, May, 2010 649 [4] ITU-T Recommendation Y.1731 (02/2008), " OAM functions and 650 mechanisms for Ethernet based networks ", Feb,2008 652 [5] I. Busi, B. Niven-Jenkins, D. Allan," MPLS-TP OAM 653 Framework",draft-ietf-mpls-tp-oam-framework-11 (work in 654 progress) 656 [6] I. Busi, H. van Helvoort, J.He "MPLS-TP OAM based on Y.1731", 657 draft-bhh-mpls-tp-oam-y1731-06 (work in progress) 659 12.2. Informative References 661 [7] Dave Allan, George Swallow, John Drake, "Proactive Connection 662 Verification, Continuity Check and Remote Defect indication for 663 MPLS Transport Profile" draft-ietf-mpls-tp-cc-cv-rdi-05 (work 664 in progress) 666 [8] Dan Frost, Stewart Bryant, "Packet Loss and Delay Measurement 667 for the MPLS Transport Profile" draft-ietf-mpls-tp-loss-delay- 668 profile-03 (work in progress) 670 [9] N. Bahadur, R. Aggarwal, S. Boutros, E. Gray, "LSP-Ping 671 extensions for MPLS-TP" draft-ietf-mpls-tp-on-demand-cv-05 672 (work in progress) 674 [10] A. Fulignoli , S. Boutros , M.Vigoureux ," MPLS-TP BFD for 675 Proactive CC-CV and RDI ",draft-fulignoli-mpls-tp-bfd-cv- 676 proactive-and-rdi-01 (expired and merged into draft-ietf-mpls- 677 tp-cc-cv-rdi; work in progress) 679 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 680 2011 681 Authors' Addresses 683 Fang Li (Editor) 684 China Academy of Telecommunication Research, P.R.China 686 Email: lifang@catr.cn 688 Han Li (Editor) 689 China Moblie 691 Email: lihan@chinamobile.com 693 Alessando D'Alessandro (Editor) 694 Telecom Italia 696 Email: alessandro.dalessandro@telecomitalia.it 698 Guangquan WANG (Editor) 699 China Unicom 701 Email: wanggq@dimpt.com 703 Ruiquan Jing (Editor) 704 China telecom 706 Email: jingrq@ctbri.com.cn 708 Juan Pedro Fernandez-Palacios Gi 709 Telefonica I+D 711 Email: jpfpg@tid.es 713 Contributing Authors' Addresses 715 Haiyi Zhang 716 China Academy of Telecommunication Research, P.R.China 718 Email: zhanghaiyi@catr.cn 720 Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July 721 2011 722 Lei Wang 723 China Mobile 725 Email: wangleiyj@chinamobile.com 727 Pei zhang 728 China Unicom 730 Email: hq-zhangp@chinaunicom.cn 732 Yusen Yang 733 China Telecom 735 Email: yangys@chinatelecom.com.cn 737 Andrea Di Giglio 738 Telecom Italia 740 Email: andrea.digiglio@telecomitalia.it