idnits 2.17.1 draft-ietf-mpls-tp-use-cases-and-design-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 1, 2013) is 4012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-tictoc-1588overmpls-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT L. Fang, Ed. 3 Intended Status: Informational Cisco 4 Expires: November 1, 2013 N. Bitar 5 Verizon 6 R. Zhang 7 Alcatel Lucent 8 M. Daikoku 9 KDDI 10 P. Pan 11 Infinera 13 May 1, 2013 15 MPLS-TP Applicability; Use Cases and Design 16 draft-ietf-mpls-tp-use-cases-and-design-08.txt 18 Abstract 20 This document provides the applicability of Multiprotocol Label 21 Switching Transport Profile (MPLS-TP) with use case studies and 22 network design considerations. The use cases include Metro Ethernet 23 access and aggregation transport, Mobile backhaul, and packet optical 24 transport. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. MPLS-TP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1. Metro Access and Aggregation . . . . . . . . . . . . . . . 6 69 2.2. Packet Optical Transport . . . . . . . . . . . . . . . . . 7 70 2.3. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . 7 71 2.3.1. 2G and 3G Mobile Backhaul . . . . . . . . . . . . . . . 8 72 2.3.2. 4G/LTE Mobile Backhaul . . . . . . . . . . . . . . . . 8 73 3. Network Design Considerations . . . . . . . . . . . . . . . . . 9 74 3.1. The role of MPLS-TP . . . . . . . . . . . . . . . . . . . . 9 75 3.2. Provisioning mode . . . . . . . . . . . . . . . . . . . . . 9 76 3.3. Standards compliance . . . . . . . . . . . . . . . . . . . 10 77 3.4. End-to-end MPLS OAM consistency . . . . . . . . . . . . . . 10 78 3.5. PW Design considerations in MPLS-TP networks . . . . . . . 11 79 3.6. Proactive and on-demand MPLS-TP OAM tools . . . . . . . . . 11 80 3.7. MPLS-TP and IP/MPLS Interworking considerations . . . . . . 12 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 This document provides applicability, use case studies and network 93 design considerations for the Multiprotocol Label Switching Transport 94 Profile (MPLS-TP). 96 1.1. Terminology 98 Term Definition 99 ------ ------------------------------------------------------- 100 2G 2nd generation wireless telephone technology 101 3G 3rd generation of mobile telecommunications technology 102 4G 4th Generation Mobile network 103 ADSL Asymmetric Digital Subscriber Line 104 AIS Alarm Indication Signal 105 ASNGW Access Service Network Gateway 106 ATM Asynchronous Transfer Mode 107 BFD Bidirectional Forwarding Detection 108 BTS Base Transceiver Station 109 CC-CV Continuity Check and Connectivity Verification 110 CDMA Code Division Multiple Access 111 E-LINE Ethernet point-to-point connectivity 112 E-LAN Ethernet LAN, provides multipoint connectivity 113 eNB Evolved Node B 114 EPC Evolved Packet Core 115 E-VLAN Ethernet Virtual Private LAN 116 EVDO Evolution-Data Optimized 117 G-ACh Generic Associated Channel 118 GAL G-ACh Label 119 GMPLS Generalized Multi-Protocol Label Switching 120 GSM Global System for Mobile Communications 121 HSPA High Speed Packet Access 122 IPTV Internet Protocol television 123 L2VPN Layer 2 Virtual Private Network 124 L3VPN Layer 3 Virtual Private Network 125 LAN Local Access Network 126 LDI Link Down Indication 127 LDP Label Distribution Protocol 128 LSP Label Switched Path 129 LTE Long Term Evolution 130 MEP Maintenance Entity Group End Point 131 MIP Maintenance Entity Group Intermediate Point 132 MPLS MultiProtocol Label Switching 133 MPLS-TP MultiProtocol Label Switching Transport Profile 134 MS-PW Multi-Segment Pseudowire 135 NMS Network Management System 136 OAM Operations, Administration, and Maintenance 137 OPEX Operating Expenses 138 PE Provider-Edge device 139 PDN GW Packet Data Network Gateway 140 PW Pseudowire 141 RAN Radio Access Network 142 RDI Remote Defect Indication 143 S1 LTE Standardized interface between eNB and EPC 144 SDH Synchronous Digital Hierarchy 145 SGW Serving Gateway 146 SLA Service Level Agreement 147 SONET Synchronous Optical Network 148 S-PE PW Switching Provider Edge 149 SP Service Provider 150 SRLG Shared Risk Link Groups 151 SS-PW Single-Segment Pseudowire 152 TDM Time Division Multiplexing 153 TFS Time and Frequency Synchronization 154 tLDP Targeted Label Distribution Protocol 155 VPN Virtual Private Network 156 UMTS Universal Mobile Telecommunications System 157 X2 LTE Standardized interface between eNBs for handover 159 1.2. Background 161 Traditional transport technologies include SONET/SDH, TDM, and ATM. 162 There is a transition away from these transport technologies to new 163 packet transport technologies. In addition to the increasing demand 164 for bandwidth, packet transport technologies offer the following key 165 advantages: 167 Bandwidth efficiency: Traditional transport technologies support 168 fixed Bandwidth, no packet statistical multiplexing, the bandwidth is 169 reserved in the transport network regardless it is used by the client 170 or not. In contrast, packet technologies support statistical 171 multiplexing. This is the most important motivation for the 172 transition from traditional transport technologies to packet 173 transport technologies. The proliferation of new distributed 174 applications which communicate with servers over the network in a 175 bursty fashion has been driving the adoption of packet transport 176 techniques, since packet multiplexing of traffic from bursty sources 177 provides more efficient use of bandwidth than traditional circuit- 178 based TDM technologies. 180 Flexible data rate connections: The granularity of data rate 181 connections of traditional transport technologies is limited to the 182 rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12, etc.). 183 Packet technologies support flexible data rate connections. The 184 support of finer data rate granularity is particularly important for 185 today's wireline and wireless services and applications. 187 QoS support: While traditional transport technology, such as TDM, has 188 very limited QoS support, packet transport can provide proper QoS 189 treatment for IPTV, Voice and Video over IP applications. 191 The root cause for transport moving to packet transport is the shift 192 of application from TDM to packet. For example, Voice TDM to VoIP; 193 Video to Video over IP; TDM access lines to Ethernet; TDM VPNs to IP 194 VPNs and Ethernet VPNs. In addition, network convergence and 195 technology refreshes demand for common and a flexible infrastructure 196 that provides multiple services. 198 As part of MPLS family, MPLS-TP complements existing IP/MPLS 199 technologies; it closes the gaps in the traditional access and 200 aggregation transport to enable end-to-end packet technology 201 solutions in a cost efficient, reliable, and interoperable manner. 202 After several years of industry debate on which packet technology to 203 use, MPLS-TP has emerged as the next generation transport technology 204 of choice for many Service Providers worldwide. 206 The Unified MPLS strategy - using MPLS from core to aggregation and 207 access (e.g. IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation 208 and access) appear to be very attractive to many SPs. It streamlines 209 the operation, reduces the overall complexity, and improves end-to- 210 end convergence. It leverages the MPLS experience, and enhances the 211 ability to support revenue generating services. 213 MPLS-TP is a subset of MPLS functions that meet the packet transport 214 requirements defined in [RFC5654]. This subset includes: MPLS data 215 forwarding, pseudo-wire encapsulation for circuit emulation, and 216 dynamic control plane using GMPLS control for LSP and tLDP for 217 pseudo-wire (PW). MPLS-TP also extends previous MPLS OAM functions, 218 such as BFD extension for proactive Connectivity Check and 219 Connectivity Verification (CC-CV) [RFC6428], and Remote Defect 220 Indication (RDI) [RFC6428], LSP Ping Extension for on-demand CC-CV 221 [RFC6426]. New tools have been defined for alarm suppression with 222 Alarm Indication Signal (AIS) [RFC6427], and switch-over triggering 223 with Link Defect Indication (LDI) [RFC6427]. Note that since the MPLS 224 OAM feature extensions defined through the process of MPLS-TP 225 development are part of the MPLS family, the applicability is general 226 to MPLS, and not limited to MPLS-TP. 228 The requirements of MPLS-TP are provided in MPLS-TP Requirements [RFC 229 5654], and the architectural framework is defined in MPLS-TP 230 Framework [RFC5921]. This document's intent is to provide the use 231 case studies and design considerations from a practical point of view 232 based on Service Providers deployments plan as well as actual 233 deployments. 235 The most common use cases for MPLS-TP include Metro access and 236 aggregation, Mobile Backhaul, and Packet Optical Transport. MPLS-TP 237 data plane architecture, path protection mechanisms, and OAM 238 functionality are used to support these deployment scenarios. 240 The design considerations discussed in this document include: the 241 role of MPLS-TP in the network; provisioning options; standards 242 compliance; end-to-end forwarding and OAM consistency; compatibility 243 with existing IP/MPLS networks; and optimization vs. simplicity 244 design trade-offs. 246 2. MPLS-TP Use Cases 248 2.1. Metro Access and Aggregation 250 The use of MPLS-TP for Metro access and aggregation transport is the 251 most common deployment scenario observed in the field. 253 Some operators are building green-field access and aggregation 254 transport infrastructure, while others are upgrading/replacing their 255 existing transport infrastructure with new packet technologies. The 256 existing legacy access and aggregation networks are usually based on 257 TDM or ATM technologies. Some operators are replacing these networks 258 with MPLS-TP technologies, since legacy ATM/TDM aggregation and 259 access are becoming inadequate to support the rapid business growth 260 and too expensive to maintain. In addition, in many cases the legacy 261 devices are facing End of Sale and End of Life issues. As operators 262 must move forward with the next generation packet technology, the 263 adoption of MPLS-TP in access and aggregation becomes a natural 264 choice. The statistical multiplexing in MPLS-TP helps to achieve 265 higher efficiency compared with the time division scheme in the 266 legacy technologies. MPLS-TP OAM tools and protection mechanisms help 267 to maintain high reliability of transport networks and achieve fast 268 recovery. 270 As most Service Providers' core networks are MPLS enabled, extending 271 the MPLS technology to the aggregation and access transport networks 272 with a Unified MPLS strategy is very attractive to many Service 273 Providers. Unified MPLS strategy in this document means having end- 274 to-end MPLS technologies through core, aggregation, and access. It 275 reduces OPEX by streamlining operation and leveraging the operational 276 experience already gained with MPLS technologies; it also improves 277 network efficiency and reduces end-to-end convergence time. 279 The requirements from the SPs for ATM/TDM aggregation replacement 280 often include: i) maintaining the previous operational model, which 281 means providing a similar user experience in NMS, ii) supporting the 282 existing access network, (e.g., Ethernet, ADSL, ATM, TDM, etc.), and 283 connections with the core networks, and iii) supporting the same 284 operational capabilities and services (L3VPN, L2VPN, E-LINE/E-LAN/E- 285 VLAN, Dedicated Line, etc.). MPLS-TP can meet these requirements and 286 in general the requirements defined in [RFC5654] to support a smooth 287 transition. 289 2.2. Packet Optical Transport 291 Many SP's transport networks consist of both packet and optical 292 portions. The transport operators are typically sensitive to network 293 deployment cost and operational simplicity. MPLS-TP supports both 294 static provisioning through NMS and dynamic provisioning via the 295 GMPLS control plane. As such, it is viewed as a natural fit in some 296 of the transport networks, where the operators can utilize the MPLS- 297 TP LSP's (including the ones statically provisioned) to manage user 298 traffic as "circuits" in both packet and optical networks, and when 299 they are ready, move to dynamic control plane for greater efficiency. 301 Among other attributes, bandwidth management, protection/recovery and 302 OAM are critical in Packet/Optical transport networks. In the context 303 of MPLS-TP, each LSP is expected to be associated with a fixed amount 304 of bandwidth in terms of bits-per-second and/or time-slots. OAM is to 305 be performed on each individual LSP. For some of the performance 306 monitoring (PM) functions, the OAM mechanisms need to be able to 307 transmit and process OAM packets at very high frequency. An overview 308 of MPLS-TP OAM toolset is found in [RFC6669]. 310 Protection [RFC6372] is another important element in transport 311 networks. Typically, ring and linear protection can be readily 312 applied in metro networks. However, as long-haul networks are 313 sensitive to bandwidth cost and tend to have mesh-like topology, 314 shared mesh protection is becoming increasingly important. 316 In some cases, SPs plan to deploy MPLS-TP from their long haul 317 optical packet transport all the way to the aggregation and access in 318 their networks. 320 2.3. Mobile Backhaul 322 Wireless communication is one of the fastest growing areas in 323 communication worldwide. In some regions, the tremendous mobile 324 growth is fueled by the lack of existing land-line and cable 325 infrastructure. In other regions, the introduction of smart phones is 326 quickly driving mobile data traffic to become the primary mobile 327 bandwidth consumer (some SPs have already observed more than 85% of 328 total mobile traffic are data traffic). MPLS-TP is viewed as a 329 suitable technology for Mobile backhaul. 331 2.3.1. 2G and 3G Mobile Backhaul 333 MPLS-TP is commonly viewed as a very good fit for 2G/3G mobile 334 backhaul. 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) Mobile Backhaul 335 Networks are still currently dominating the mobile infrastructure. 337 The connectivity for 2G/3G networks is point to point (P2P). The 338 logical connections are hub-and-spoke. Networks are physically 339 constructed using a star or ring topology. In the Radio Access 340 Network (RAN), each mobile Base Transceiver Station (BTS/Node B) is 341 communicating with a Radio Controller (BSC/RNC). These connections 342 are often statically set up. 344 Hierarchical or centralized architectures are often used for pre- 345 aggregation and aggregation layers. Each aggregation network inter- 346 connects with multiple access networks. For example, a single 347 aggregation ring could aggregate traffic for 10 access rings with a 348 total of 100 base stations. 350 The technology used today is largely ATM based. Mobile providers are 351 replacing the ATM RAN infrastructure with newer packet technologies. 352 IP RAN networks with IP/MPLS technologies are deployed today by many 353 SPs with great success. MPLS-TP is another suitable choice for Mobile 354 RAN. The P2P connections from base station to Radio Controller can be 355 set statically to mimic the operation of today's RAN environments; 356 in-band OAM and deterministic path protection can support fast 357 failure detection and switch-over to satisfy the SLA agreements. 358 Bidirectional LSPs may help to simplify the provisioning process. The 359 deterministic nature of MPLS-TP LSP set up can also support packet 360 based synchronization to maintain predictable performance regarding 361 packet delay and jitters. The traffic engineered and co-routed 362 bidirectional properties of an MPLS-TP LSP are of benefit in 363 transporting packet based Time and Frequency Synchronization (TFS) 364 protocols such as [1588overmpls]. However, the choice between an 365 external, physical layer or packet based TFS method is network 366 dependent and thus is out of scope of this document. 368 2.3.2. 4G/LTE Mobile Backhaul 370 One key difference between LTE and 2G/3G mobile networks is that the 371 logical connection in LTE is a mesh, while in 2G/3G is a P2P star. In 372 LTE, the base stations eNB/BTS communicate with multiple Network 373 controllers (PDN GW/SGW or ASNGW), and the radio elements communicate 374 with one another for signal exchange and traffic offload to wireless 375 or wireline infrastructures. 377 IP/MPLS has a great advantage in any-to-any connectivity 378 environments. Thus, the use of mature IP or L3VPN technologies is 379 particularly common in the design of SP's LTE deployment plans. 381 The extended OAM functions defined in MPLS-TP, such as in-band OAM 382 and path protection mechanisms bring additional advantages to support 383 SLAs. The dynamic control-plane with GMPLS signaling is especially 384 suited for the mesh environment, to support dynamic topology changes 385 and network optimization. 387 Some operators are using the same model as in 2G and 3G Mobile 388 Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static 389 provisioning (through NMS) in aggregation and access. The reasoning 390 is as follows: the X2 traffic load in LTE networks currently may be a 391 very small percentage of the total traffic. For example, one large 392 mobile operator observed that X2 traffic was less than one percent of 393 the total S1 traffic. Therefore, optimizing the X2 traffic may not be 394 the design objective in this case. The X2 traffic can be carried 395 through the same static tunnels together with the S1 traffic in the 396 aggregation and access networks, and further forwarded across the 397 IP/MPLS core. In addition, mesh protection may be more efficient with 398 regard to bandwidth utilization, but linear protection and ring 399 protection are often considered simpler by some operators from the 400 point of view of operation maintenance and trouble shooting, and so 401 are widely deployed. In general, using MPLS-TP with static 402 provisioning for LTE backhaul is a viable option. The design 403 objective of using this approach is to keep the operation simple and 404 use a common model for mobile backhaul, especially during the 405 transition period. 407 The TFS considerations stated in Section 3.3.1 apply to the 4G/LTE 408 Mobile Backhaul case as well. 410 3. Network Design Considerations 412 3.1. The role of MPLS-TP 414 The role of MPLS-TP is to provide a solution to help evolve 415 traditional transport towards packet. It is designed to support the 416 transport characteristics/behavior described in [RFC5654]. The 417 primary use of MPLS-TP is largely to replace legacy transport 418 technologies, such as SONET/SDH. MPLS-TP is not designed to replace 419 the service support capabilities of IP/MPLS, such as L2VPN, L3VPN, 420 IPTV, Mobile RAN, etc. 422 3.2. Provisioning mode 424 MPLS-TP supports two provisioning modes: i) a mandatory static 425 provisioning mode, which must be supported without dependency on 426 dynamic routing or signaling; and ii) an optional distributed dynamic 427 control plane, which is used to enable dynamic service provisioning. 429 The decision on which mode to use is largely dependent on the 430 operational feasibility and the stage of network transition. 431 Operators who are accustomed to the transport-centric operational 432 model (e.g., NMS configuration without control plane) typically 433 prefer the static provisioning mode. This is the most common choice 434 in current deployments. The dynamic provisioning mode can be more 435 powerful but it is more suited to operators who are familiar with the 436 operation and maintenance of IP/MPLS technologies or are ready to 437 step up through training and planned transition. 439 There may be also cases where operators choose to use the combination 440 of both modes. This is appropriate when parts of the network are 441 provisioned in a static fashion and other parts are controlled by 442 dynamic signaling. This combination may also be used to transition 443 from static provisioning to dynamic control plane. 445 3.3. Standards compliance 447 It is generally recognized by SPs that standards compliance is 448 important for lowering cost, accelerating product maturity, achieving 449 multi-vendor interoperability, and meeting the expectations of their 450 enterprise customers. 452 MPLS-TP is a joint work between IETF and ITU-T. In April 2008, IETF 453 and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as 454 joint work [RFC5317]. The transport requirements are provided by ITU- 455 T, the protocols are developed in IETF. 457 3.4. End-to-end MPLS OAM consistency 459 End-to-end MPLS OAM consistency is highly desirable in order to 460 enable Service Providers to deploy an end-to-end MPLS solution. As 461 MPLS-TP adds OAM function to the MPLS toolkit, it cannot be expected 462 that a full-function end-to-end LSP with MPLS-TP OAM can be achieved 463 when the LSP traverses a legacy MPLS/IP core. Although it may be 464 possible to select a subset of MPLS-TP OAM that can be gatewayed to 465 the legacy MPLS/IP OAM, a better solution is achieved by tunneling 466 the MPLS-TP LSP over the legacy MPLS/IP network. In that mode of 467 operation, legacy OAM may be run on the tunnel in the core, and the 468 tunnel end-points may report issues in as much detail as possible to 469 the MIPs in the MPLS-TP LSP. Note that over time it is expected that 470 routers in the MPLS/IP core will be upgraded to fully support MPLS-TP 471 features: once this has occurred, it will be possible to run end-to- 472 end MPLS-TP LSPs seamlessly across the core. 474 3.5. PW Design considerations in MPLS-TP networks 476 In general, PWs in MPLS-TP work the same as in IP/MPLS networks. Both 477 Single-Segment PW (SS-PW) and Multi-Segment PW (MS-PW) are supported. 478 For dynamic control plane, Targeted LDP (tLDP) is used. In static 479 provisioning mode, PW status is a new PW OAM feature for failure 480 notification. In addition, both directions of a PW must be bound to 481 the same transport bidirectional LSP. 483 In the common network topology involving multi-tier rings, the design 484 choice is between using SS-PW or MS-PW. This is not a discussion 485 unique to MPLS-TP, as it applies to PW design in general, but it is 486 relevant here, since MPLS-TP is more sensitive to the operational 487 complexities, as noted by operators. If MS-PW is used, Switched PE 488 (S-PE) must be deployed to connect the rings. The advantage of this 489 choice is that it provides domain isolation, which in turn 490 facilitates trouble shooting and allows for faster PW failure 491 recovery. On the other hand, the disadvantage of using S-PE is that 492 it adds more complexity. Using SS-PW is simpler, since it does not 493 require S-PEs, but less efficient because the paths across primary 494 and secondary rings are longer. If operational simplicity is a higher 495 priority, some SPs choose the latter. 497 Another design trade-off is whether to use PW protection in addition 498 to LSP protection or rely solely on LSP protection. When the MPLS-TP 499 LSPs are protected, if the working LSP fails, the protect LSP assures 500 that the connectivity is maintained and the PW is not impacted. 501 However, in the case of simultaneous failure of both working and 502 protect LSPs, the attached PW would fail. By adding PW protection, 503 and attaching the protect PW to a diverse LSP not in the same Shared 504 Risk Link Group (SRLG), the PW is protected even when the primary PW 505 fails. Clearly, using PW protection adds considerably more 506 complexity and resource usage, and thus operators often may choose 507 not to use it, and consider protection against single point of 508 failure as sufficient. 510 3.6. Proactive and on-demand MPLS-TP OAM tools 512 MPLS-TP provide both proactive and on-demand OAM Tools. As a 513 proactive OAM fault management tool, BFD Connectivity Check (CC) can 514 be sent at regular intervals for Connectivity Check; three missed CC 515 messages (or a configurable number) can trigger the failure 516 protection switch-over. BFD sessions are configured for both working 517 and protecting LSPs. 519 A design decision is choosing the value of the BFD CC interval. The 520 shorter the interval, the faster the detection time is, but also the 521 higher the resource utilization is. The proper value depends on the 522 application and the service needs. 524 As an on-demand OAM fault management mechanism, for example when 525 there is a fiber cut, Link Down Indication (LDI) message [RFC6427] 526 can be generated from the failure point and propagated to the 527 Maintenance Entity Group End Points (MEPs) to trigger immediate 528 switch-over from working to protect path. An Alarm Indication Signal 529 (AIS) can be propagated from the Maintenance Entity Group 530 Intermediate Point (MIP) to the MEPs for alarm suppression. 532 In general, both proactive and on-demand OAM tools should be enabled 533 to guarantee short switch-over times. 535 3.7. MPLS-TP and IP/MPLS Interworking considerations 537 Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and 538 IP/MPLS Interworking is inevitable if not a reality. However, 539 Interworking discussion is out of the scope of this document; it is 540 for further study. 542 4. Security Considerations 544 Under the use case of Metro access and aggregation, in the scenario 545 where some of the access equipment is placed in facilities not owned 546 by the SP, the static provisioning mode of MPLS-TP is often preferred 547 over the control plane option because it eliminates the possibility 548 of a control plane attack which may potentially impact the whole 549 network. This scenario falls into the Security Reference Model 2 as 550 described in [RFC6941]. 552 Similar location issues apply to the mobile use cases, since 553 equipment is often placed in remote and outdoor environment, which 554 can increase the risk of un-authorized access to the equipment. 556 In general, NMS access can be a common point of attack in all MPLS-TP 557 use cases, and attacks to GAL or G-ACh are unique security treats to 558 MPLS-TP. The MPLS-TP security considerations are discussed in MPLS-TP 559 Security Framework [RFC6941]. General security considerations for 560 MPLS and GMPLS networks are addressed in Security Framework for MPLS 561 and GMPLS Networks [RFC5920]. 563 5. IANA Considerations 565 This document contains no new IANA considerations. 567 6. Acknowledgements 569 The authors wish to thank Adrian Farrel for his review as Routing 570 Area Director, Adrian's detailed comments and suggestions were of 571 great help for improving the quality of this document, and thank Loa 572 Andersson and Adrian Farrel for their continued support and guidance. 573 The authors would also like to thank Weiqiang Cheng for his helpful 574 input on LTE Mobile backhaul based on his knowledge and experience in 575 real world deployment, thank Stewart Bryant for his text contribution 576 on timing, thank Russ Housley for his improvement suggestions, thank 577 Andrew Malis for his support and use case discussion, thank Pablo 578 Frank, Lucy Yong, Huub van Helvoort, Tom Petch, Curtis Villamizar, 579 and Paul Doolan for their comments and suggestions, thank Joseph Yee 580 and Miguel Garcia for their APPSDIR and Gen-ART reviews and comments 581 respectively. 583 7. References 585 7.1. Normative References 587 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 588 Sprecher, N., and S. Ueno, "Requirements of an MPLS 589 Transport Profile", RFC 5654, September 2009. 591 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 592 Networks", RFC 5920, July 2010. 594 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 595 L., and L. Berger, "A Framework for MPLS in Transport 596 Networks", RFC 5921, July 2010. 598 [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS 599 On-Demand Connectivity Verification and Route Tracing", 600 RFC 6426, November 2011. 602 [RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., 603 Boutros, S., and D. Ward, "MPLS Fault Management 604 Operations, Administration, and Maintenance (OAM)", 605 RFC 6427, November 2011. 607 [RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed., 608 "Proactive Connectivity Verification, Continuity Check, 609 and Remote Defect Indication for the MPLS Transport 610 Profile", RFC 6428, November 2011. 612 7.2. Informative References 614 [RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working 615 Team (JWT) Report on MPLS Architectural Considerations for 616 a Transport Profile", RFC 5317, February 2009. 618 [RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport 619 Profile (MPLS-TP) Survivability Framework", RFC 6372, 620 September 2011. 622 [RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, 623 Administration, and Maintenance (OAM) Toolset for MPLS- 624 Based Transport Networks", RFC 6669, July 2012. 626 [RFC6941] Fang, L. Ed., Niven-Jenkins, B., Ed., Mansfield, 627 S., Ed., and R. Graveman, Ed., "MPLS-TP Security 628 Framework," RFC 6941, April 2013. 630 [1588overmpls], Davari, S., Oren, A., Bhatia, M., Roberts, P., and 631 L. Montini, "Transporting Timing messages over MPLS 632 Networks," draft-ietf-tictoc-1588overmpls-04.txt, February 633 2013. 635 Authors' Addresses 637 Luyuan Fang 638 Cisco Systems, Inc. 639 111 Wood Ave. South 640 Iselin, NJ 08830 641 United States 642 Email: lufang@cisco.com 644 Nabil Bitar 645 Verizon 646 40 Sylvan Road 647 Waltham, MA 02145 648 United States 649 Email: nabil.bitar@verizon.com 651 Raymond Zhang 652 Alcatel-Lucent 653 701 Middlefield Road 654 Mountain View, CA 94043 655 United States 656 Email: raymond.zhang@alcatel-lucent.com 658 Masahiro Daikoku 659 KDDI corporation 660 3-11-11.Iidabashi, Chiyodaku, Tokyo 661 Japan 662 Email: ms-daikoku@kddi.com 664 Ping Pan 665 Infinera 666 United States 667 Email: ppan@infinera.com 669 Contributors' Addresses 671 Kam Lee Yap 672 XO Communications 673 13865 Sunrise Valley Drive, 674 Herndon, VA 20171 675 United States 676 Email: klyap@xo.com 678 Dan Frost 679 Cisco Systems, Inc. 680 United Kingdom 681 Email:danfrost@cisco.com 683 Henry Yu 684 TW Telecom 685 10475 Park Meadow Dr. 686 Littleton, CO 80124 687 United States 688 Email: henry.yu@twtelecom.com 690 Jian Ping Zhang 691 China Telecom, Shanghai 692 Room 3402, 211 Shi Ji Da Dao 693 Pu Dong District, Shanghai 694 China 695 Email: zhangjp@shtel.com.cn 697 Lei Wang 698 Lime Networks 699 Strandveien 30, 1366 Lysaker 700 Norway 701 Email: lei.wang@limenetworks.no 703 Mach(Guoyi) Chen 704 Huawei Technologies Co., Ltd. 705 No. 3 Xinxi Road 706 Shangdi Information Industry Base 707 Hai-Dian District, Beijing 100085 708 China 709 Email: mach@huawei.com 711 Nurit Sprecher 712 Nokia Siemens Networks 713 3 Hanagar St. Neve Ne'eman B 714 Hod Hasharon, 45241 715 Israel 716 Email: nurit.sprecher@nsn.com