idnits 2.17.00 (12 Aug 2021) /tmp/idnits44523/draft-ietf-mpls-tp-use-cases-and-design-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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 == Line 621 has weird spacing: '...otected when ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 20, 2011) is 3805 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC 2119' is defined on line 894, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Fang, Ed. 3 Internet Draft Cisco Systems 4 Intended status: Informational N. Bitar 5 Expires: June 20, 2012 Verizon 6 R. Zhang 7 Alcatel Lucent 8 M. DAIKOKU 9 KDDI 10 P. Pan 11 Infinera 13 December 20, 2011 15 MPLS-TP Applicability; Use Cases and Design 16 draft-ietf-mpls-tp-use-cases-and-design-01.txt 18 Abstract 20 This document provides applicability, use case studies and network 21 design considerations for Multiprotocol Label Switching Transport 22 profile (MPLS-TP). 24 In the recent years, MPLS-TP has emerged as the technology of choice 25 for the new generation of packet transport. Many service providers 26 (SPs) are working to replace the legacy transport technologies, e.g. 27 SONET/SDH, TDM, and ATM technologies, with MPLS-TP for packet 28 transport, in order to achieve higher efficiency, lower operational 29 cost, while maintaining transport characteristics. 31 The use cases for MPLS-TP include Metro Ethernet access and 32 aggregation, Mobile backhaul, and packet optical transport. The 33 design considerations discussed in this documents ranging from 34 operational experience; standards compliance; technology maturity; 35 end-to-end forwarding and OAM consistency; compatibility with 36 IP/MPLS networks; multi-vendor interoperability; and optimization 37 vs. simplicity design trade off discussion. The general design 38 principle is to provide reliable, manageable, and scalable transport 39 solutions. 41 Status of this Memo 43 This Internet-Draft is submitted to IETF in full conformance with 44 the provisions of BCP 78 and BCP 79. 46 MPLS-TP Use Case and Design Considerations 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six 53 months and may be updated, replaced, or obsoleted by other documents 54 at any time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress. 57 This Internet-Draft will expire on June 18, 2012. 59 Copyright Notice 61 Copyright (c) 2011 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with 69 respect to this document. Code Components extracted from this 70 document must include Simplified BSD License text as described in 71 Section 4.e of the Trust Legal Provisions and are provided without 72 warranty as described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction ...................................................3 77 3 78 1.1. Background and Motivation ...................................3 79 3 80 1.2. Co-authors and contributors .................................3 81 5 82 2. Terminologies ..................................................5 83 5 84 3. Overview of MPLS-TP base functions .............................6 85 6 86 3.1. MPLS-TP development principles ..............................6 87 6 88 3.2. Data Plane ..................................................7 89 7 90 3.3. Control Plane ...............................................7 91 7 92 3.4. OAM .........................................................7 93 7 94 3.5. Survivability ...............................................8 95 8 96 4. MPLS-TP Use Case Studies .......................................8 97 8 98 8 100 MPLS-TP Use Case and Design Considerations 102 4.2. Packet Optical Transport ....................................9 103 9 104 4.3. Mobile Backhaul ............................................10 105 10 106 5. Network Design Considerations .................................11 107 11 108 5.1. IP/MPLS vs. MPLS-TP ........................................11 109 11 110 5.2. Standards compliance .......................................11 111 12 112 5.3. End-to-end MPLS OAM consistency ............................12 113 13 114 5.4. PW Design considerations in MPLS-TP networks ...............13 115 13 116 5.5. Proactive and event driven MPLS-TP OAM tools ...............13 117 14 118 5.6. MPLS-TP and IP/MPLS Interworking considerations ............14 119 14 120 5.7. Delay and delay variation ..................................14 121 14 122 5.8. More on MPLS-TP Deployment Considerations ..................17 123 17 124 6. Security Considerations .......................................19 125 19 126 7. IANA Considerations ...........................................19 127 19 128 8. Normative References ..........................................19 129 19 130 9. Informative References ........................................19 131 19 132 10. Author's Addresses...........................................20 133 20 135 Requirements Language 137 Although this document is not a protocol specification, the key 138 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 140 this document are to be interpreted as described in RFC 2119 [RFC 141 2119]. 143 1. Introduction 145 1.1. Background and Motivation 147 This document provides case studies and network design 148 considerations for Multiprotocol Label Switching Transport Profile 149 (MPLS-TP). 151 In recent years, the urgency for moving from traditional transport 152 technologies, such as SONET/SDH, TDM/ATM, to new packet technologies 154 data services, such as IPTV and IP Video for content downloading, 155 streaming, and sharing; rapid growth of mobile services, especially 156 smart phone applications; the continued growth of business VPNs and 157 residential broadband. The end of live for many legacy TDM devices 158 and the continuing network convergence effort are also key 159 contributing factors for transport moving toward packet 160 MPLS-TP Use Case and Design Considerations 161 technologies. After several years of heated debate on which packet 162 technology to use, MPLS-TP has emerged as the next generation 163 transport technology of choice for many service providers 164 worldwide. 166 MPLS-TP is based on MPLS technologies. MPLS-TP re-use a subset of 167 MPLS base functions, such as MPLS data forwarding, Pseudo-wire 168 encapsulation for circuit emulation, and GMPLS for LSP, tLDP for PW, 169 as dynamic control plane options; MPLS-TP extended current MPLS OAM 170 functions, such as BFD extension for Connectivity for proactive 171 Connectivity Check (CC) and Connectivity Verification (CV), and 172 Remote Defect Indication (RDI), LSP Ping Extension for on demand 173 Connectivity Check (CC) and Connectivity Verification (CV), fault 174 allocation, and remote integrity check. New tools are being defined 175 for alarm suppression with Alarm Indication Signal (AIS), and 176 trigger of switch over with Link Defect Indication (LDI). 178 The goal is to take advantage of the maturity of MPLS technology, 179 re-use the existing component when possible and extend the existing 180 protocols or create new procedures/protocols when needed to fully 181 satisfy the transport requirements. 183 The general requirements of MPLS-TP are provided in MPLS-TP 184 Requirements [RFC 5654], and the architectural framework are defined 185 in MPLS-TP Framework [RFC 5921]. This document intent to provide the 186 use case studies and design considerations from practical point of 187 view based on Service Providers deployments plans and field 188 implementations. 190 The most common use cases for MPLS-TP include Metro access and 191 aggregation, Mobile Backhaul, and Packet Optical Transport. MPLS-TP 192 data plane architecture, path protection mechanisms, and OAM 193 functionalities are used to support these deployment scenarios. 194 As part of MPLS family, MPLS-TP complements today's IP/MPLS 195 technologies; it closes the gaps in the traditional access and 196 aggregation transport to enable end-to-end packet technology 197 solutions in a cost efficient, reliable, and interoperable manner. 199 The unified MPLS strategy, using MPLS from core to aggregation and 200 access (e.g. IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation 201 and access) appear to be very attractive to many SPs. It streamlines 202 the operation, many help to reduce the overall complexity and 203 improve end-to-end convergence. It leverages the MPLS experience, 204 and enhances the ability to support revenue generating services. 206 The design considerations discussed in this document are generic. 207 While many design criteria are commonly apply to most of SPs, each 208 individual SP may place the importance of one aspect over another 209 MPLS-TP Use Case and Design Considerations 210 depending on the existing operational environment, what type of 211 applications need to be supported, the design objectives, the cost 212 constrain, and the network evolution plans. 214 1.2. Co-authors and contributors 216 Luyuan Fang, Cisco Systems 217 Nabil Bitar, Verizon 218 Raymond Zhang, Alcatel Lucent 219 Masahiro DAIKOKU, KDDI 220 Ping Pan, Infinera 221 Mach(Guoyi) Chen, Huawei Technologies 222 Dan Frost, Cisco Systems 223 Kam Lee Yap, XO Communications 224 Henry Yu, Time W Telecom 225 Jian Ping Zhang, China Telecom, Shanghai 226 Nurit Sprecher, Nokia Siemens Networks 227 Lei Wang, Telenor 229 2. Terminologies 231 AIS Alarm Indication Signal 232 APS Automatic Protection Switching 233 ATM Asynchronous Transfer Mode 234 BFD Bidirectional Forwarding Detection 235 CC Continuity Check 236 CE Customer Edge device 237 CV Connectivity Verification 238 CM Configuration Management 239 DM Packet delay measurement 240 ECMP Equal Cost Multi-path 241 FM Fault Management 242 GAL Generic Alert Label 243 G-ACH Generic Associated Channel 244 GMPLS Generalized Multi-Protocol Label Switching 245 LB Loopback 246 LDP Label Distribution Protocol 247 LM Packet loss measurement 248 LSP Label Switched Path 249 LT Link trace 250 MEP Maintenance End Point 251 MIP Maintenance Intermediate Point 252 MP2MP Multi-Point to Multi-Point connections 253 MPLS Multi-Protocol Label Switching 254 MPLS-TP MPLS transport profile 256 MPLS-TP Use Case and Design Considerations 257 OAM Operations, Administration, and Management 258 P2P Point to Multi-Point connections 259 P2MP Point to Point connections 260 PE Provider-Edge device 261 PHP Penultimate Hop Popping 262 PM Performance Management 263 PW Pseudowire 264 RDI Remote Defect Indication 265 RSVP-TE Resource Reservation Protocol with Traffic 266 Engineering Extensions 267 SLA Service Level Agreement 268 SNMP Simple Network Management Protocol 269 SONET Synchronous Optical Network 270 S-PE Switching Provider Edge 271 SRLG Shared Risk Link Group 272 SM-PW Multi-Segment PW 273 SS-PW Signle-Segment PW 274 TDM Time Division Multiplexing 275 TE Traffic Engineering 276 tLDP target LDP 277 TTL Time-To-Live 278 T-PE Terminating Provider Edge 279 VPN Virtual Private Network 281 3. Overview of MPLS-TP base functions 283 The section provides a summary view of MPLS-TP technology, 284 especially in comparison to the base IP/MPLS technologies. For 285 complete requirements and architecture definitions, please refer to 286 [RFC 5654] and [RFC 5921]. 288 3.1. MPLS-TP development principles 290 The principles for MPLS-TP development are: meeting transport 291 requirements; maintain transport characteristics; re-using the 292 existing MPLS technologies wherever possible to avoid duplicate the 293 effort; ensuring consistency and inter-operability of MPLS-TP and 294 IP/MPLS networks; developing new tools as necessary to fully meet 295 transport requirements. 297 MPLS-TP Technologies include four major areas: Data Plane, Control 298 Plane, OAM, and Survivability. The short summary is provided below. 300 MPLS-TP Use Case and Design Considerations 301 3.2. Data Plane 303 MPLS-TP re-used MPLS and PW architecture; and MPLS forwarding 304 mechanism; 306 MPLS-TP extended the LSP support from unidirectional to both bi- 307 directional unidirectional support. 309 MPLS-TP defined PHP as optional, disallowed ECMP and MP2MP, only P2P 310 and P2MP are supported. 312 3.3. Control Plane 314 MPLS-TP allowed two control plane options: 316 Static: Using NMS for static provisioning; 317 Dynamic control plane for LSP: using GMPLS, OSPF-TE, RSVP-TE for 318 full automation; 319 Dymanic control plane for PW: using tLDP. 320 ACH concept in PW is extended to G-ACh for MPLS-TP LSP to support 321 in-band OAM. 323 Both Static and dynamic control plane options must allow control 324 plane, data plane, management plane separation. 326 3.4. OAM 328 OAM received most attention in MPLS-TP development; Many OAM 329 functions require protocol extensions or new development to meet the 330 transport requirements. 332 1) Continuity Check (CC), Continuity Verification (CV), and Remote 333 Integrity: 334 - Proactive CC and CV: Extended BFD 335 - On demand CC and CV: Extended LSP Ping 336 - Proactive Remote Integrity: Extended BFD 337 - On demand Remote Integrity: Extended LSP Ping 339 2) Fault Management: 340 - Fault Localization: Extended LSP Ping 341 - Alarm Suppression: created AIS 342 - Remote Defect Indication (RDI): Extended BFD 343 - Lock reporting: Created Lock Instruct 344 - Link defect Indication: Created LDI 345 - Static PW defect indication: Use Static PW status 346 MPLS-TP Use Case and Design Considerations 347 Performance Management: 348 - Loss Management: Create MPLS-TP loss/delay measurement 349 - Delay Measurement: Create MPLS-TP loss/delay measurement 351 MPLS-TP OAM tool set overview can be found at [OAM Tool Set]. 353 3.5. Survivability 355 - Deterministic path protection 356 - Switch over within 50ms 357 - 1:1, 1+1, 1:N protection 358 - Linear protection 359 - Ring protection 360 - Shared Mesh Protection 362 MPLS transport Profile Survivability Framework [RFC 6372] provides 363 more details on the subject. 365 4. MPLS-TP Use Case Studies 367 4.1. Metro Access and Aggregation 369 The most common deployment cases observed in the field upto today is 370 using MPLS-TP for Metro access and aggregation. Some SPs are 371 building green field access and aggregation infrastructure, while 372 others are upgrading/replacing the existing transport infrastructure 373 with new packet technologies such as MPLS-TP. 374 The access and aggregation networks today can be based on ATM, TDM, 375 MSTP, or Ethernet technologies as later development. 377 Some other SPs announced their plans for replacing their ATM or TDM 378 aggregation networks with MPLS-TP technologies, simply because their 379 ATM / TDM aggregation networks are no longer suited to support the 380 rapid bandwidth growth, and they are expensive to maintain or may 381 also be and impossible expand due to End of Sale and End of Life 382 legacy equipments. Operators have to move forward with the next 383 generation packet technology, the adoption of MPLS-TP in access and 384 aggregation becomes a natural choice. The statistical muxing in 385 MPLS-TP helps to achieve higher efficiency comparing with the time 386 division scheme in the legacy technologies. 388 The unified MPLS strategy, using MPLS from core to aggregation and 389 access (e.g. IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation 390 and access) appear to be very attractive to many SPs. It streamlines 391 the operation, many help to reduce the overall complexity and 392 MPLS-TP Use Case and Design Considerations 393 improve end-to-end convergence. It leverages the MPLS experience, 394 and enhances the ability to support revenue generating services. 396 The current requirements from the SPs for ATM/TDM aggregation 397 replacement often include maintaining the current operational model, 398 with the similar user experience in NMS, supports current access 399 network (e.g. Ethernet, ADSL, ATM, STM, etc.), support the 400 connections with the core networks, support the same operational 401 feasibility even after migrating to MPLS-TP from ATM/TDM and 402 services (OCN, IP-VPN, E-VLAN, Dedicated line, etc.). MPLS-TP 403 currently defined in IETF are meeting these requirements to support 404 a smooth transition. 406 The green field network deployment is targeting using the state of 407 art technology to build most stable, scalable, high quality, high 408 efficiency networks to last for the next many years. IP/MPLS and 409 MPLS-TP are both good choices, depending on the operational model. 411 4.2. Packet Optical Transport 413 Many SP's transport networks consist of both packet and optical 414 portions. The transport operators are typically sensitive to network 415 deployment cost and operation simplicity. MPLS-TP is therefore a 416 natural fit in some of the transport networks, where the operators 417 can utilize the MPLS-TP LSP's (including the ones statically 418 provisioned) to manage user traffic as "circuits" in both packet and 419 optical networks. 420 Among other attributes, bandwidth management, protection/recovery 421 and OAM are critical in Packet/Optical transport networks. In the 422 context of MPLS-TP, each LSP is expected to be associated with a 423 fixed amount of bandwidth in terms of bps and/or time-slots. OAM is 424 to be performed on each individual LSP. For some of performance 425 monitoring (PM) functions, the OAM mechanisms need to be able 426 transmit and process OAM packets at very high frequency, as low as 427 several msec's. 429 Protection is another important element in transport networks. 430 Typically, ring and linear protection can be readily applied in 431 metro networks. However, as long-haul networks are sensitive to 432 bandwidth cost and tend to have mesh-like topology, shared mesh 433 protection is becoming increasing important. 435 Packet optical deployment plans in some SPs cases are using MPLS-TP 436 from long haul optical packet transport all the way to the 437 aggregation and access. 439 MPLS-TP Use Case and Design Considerations 440 4.3. Mobile Backhaul 442 Wireless communication is one of the fastest growing areas in 443 communication world wide. For some regions, the tremendous rapid 444 mobile growth is fueled with lack of existing land-line and cable 445 infrastructure. For other regions, the introduction of Smart phones 446 quickly drove mobile data traffic to become the primary mobile 447 bandwidth consumer, some SPs have already seen 85% of total mobile 448 traffic are data traffic. 450 MPLS-TP has been viewed as a suitable technology for Mobile 451 backhaul. 453 4.3.1. 2G and 3G Mobile Backhaul Support 455 MPLS-TP is commonly viewed as a very good fit for 2G)/3G Mobile 456 backhaul. 458 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) Mobile Backhaul Networks are 459 dominating mobile infrastructure today. 461 The connectivity for 2G/3G networks are Point to point. The logical 462 connections are hub-and-spoke. The physical construction of the 463 networks can be star topology or ring topology. In the Radio Access 464 Network (RAN), each mobile base station (BTS/Node B) is 465 communicating with one Radio Controller (BSC/RNC) only. These 466 connections are often statically set up. 468 Hierarchical Aggregation Architecture / Centralized Architecture are 469 often used for pre-aggregation and aggregation layers. Each 470 aggregation networks inter-connects with multiple access networks. 471 For example, single aggregation ring could aggregate traffic for 10 472 access rings with total 100 base stations. 474 The technology used today is largely ATM based. Mobile providers are 475 replacing the ATM RAN infrastructure with newer packet technologies. 476 IP RAN networks with IP/MPLS technologies are deployed today by many 477 SPs with great success. MPLS-TP is another suitable choice for 478 Mobile RAN. The P2P connection from base station to Radio Controller 479 can be set statically to mimic the operation today in many RAN 480 environments, in-band OAM and deterministic path protection would 481 support the fast failure detection and switch over to satisfy the 482 SLA agreement. Bidirectional LSP may help to simplify the 483 provisioning process. The deterministic nature of MPLS-TP LSP set up 484 can also help packet based synchronization to maintain predictable 485 performance regarding packet delay and jitters. 487 MPLS-TP Use Case and Design Considerations 489 4.3.2. LTE Mobile Backhaul 491 One key difference between LTE and 2G/3G Mobile networks is that the 492 logical connection in LTE is mesh while 2G/3G is P2P star 493 connections. 495 In LTE, the base stations eNB/BTS can communicate with multiple 496 Network controllers (PSW/SGW or ASNGW), and each Radio element can 497 communicate with each other for signal exchange and traffic offload 498 to wireless or Wireline infrastructures. 500 IP/MPLS may have a great advantage in any-to-any connectivity 501 environment. The use of mature IP or L3VPN technologies is 502 particularly common in the design of SP's LTE deployment plan. 504 MPLS-TP can also bring advantages with the in-band OAM and path 505 protection mechanism. MPLS-TP dynamic control-plane with GMPLS 506 signaling may bring additional advantages in the mesh environment 507 for real time adaptivities, dynamic topology changes, and network 508 optimization. 510 Since MPLS-TP is part of the MPLS family. Many component already 511 shared by both IP/MPLS and MPLS-TP, the line can be further blurred 512 by sharing more common features. For example, it is desirable for 513 many SPs to introduce the in-band OAM developed for MPLS-TP back 514 into IP/MPLS networks as an enhanced OAM option. Today's MPLS PW can 515 also be set statically to be deterministic if preferred by the SPs 516 without going through full MPLS-TP deployment. 518 4.3.3. WiMAX Backhaul 519 WiMAX Mobile backhaul shares the similar characteristics as LTE, 520 with mesh connections rather than P2P, star logical connections. 522 5. Network Design Considerations 524 5.1. IP/MPLS vs. MPLS-TP 526 Questions one might hear: I have just built a new IP/MPLS network to 527 support multi-services, including L2/L3 VPNs, Internet service, 528 IPTV, etc. Now there is new MPLS-TP development in IETF. Do I need 529 to move onto MPLS-TP technology to state current with technologies? 530 MPLS-TP Use Case and Design Considerations 531 The answer is no. MPLS-TP is developed to meet the needs of 532 traditional transport moving towards packet. It is designed to 533 support the transport behavior coming with the long history. IP/MPLS 534 and MPLS-TP both are state of art technologies. IP/MPLS support both 535 transport (e.g. PW, RSVP-TE, etc.) and services (e.g L2/L3 VPNs, 536 IPTV, Mobile RAN, etc.), MPLS-TP provides transport only. The new 537 enhanced OAM features built in MPLS-TP should be share in both 538 flavors through future implementation. 540 Another common question: I need to evolve my ATM/TDM/SONET/SDH 541 networks into new packet technologies, but my operational force is 542 largely legacy transport, not familiar with new data technologies, 543 and I want to maintain the same operational model for the time 544 being, what should I do? The answer would be: MPLS-TP may be the 545 best choice today for the transition. 547 A few important factors need to be considered for IP/MPLS or MPLS-TP 548 include: 550 - Technology maturity (IP/MPLS is much more mature with 12 years 551 development) 552 - Operation experience (Work force experience, Union agreement, how 553 easy to transition to a new technology? how much does it cost?) 554 - Needs for Multi-service support on the same node (MPLS-TP provide 555 transport only, does not replace many functions of IP/MPLS) 556 - LTE, IPTV/Video distribution considerations (which path is the 557 most viable for reaching the end goal with minimal cost? but it also 558 meet the need of today's support) 560 5.2. Standards compliance 562 It is generally recognized by SPs that standards compliance are 563 important for driving the cost down and product maturity up, multi- 564 vendor interoperability, also important to meet the expectation of 565 the business customers of SP's. 567 MPLS-TP is a joint work between IETF and ITU-T. In April 2008, IETF 568 and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as 569 joint work [RFC 5317]. The transport requirements would be provided 570 by ITU-T, the protocols would be developed in IETF. 572 Today, majority of the core set of MPLS-TP protocol definitions are 573 published as IETF RFCs already. It is important to deploy the 574 solutions based on the standards definitions, in order to ensure the 575 compatibility between MPLS-TP and IP/MPLS networks, and the 576 interoperability among different equipment by different vendors. 578 MPLS-TP Use Case and Design Considerations 579 Note that using non-standards, e.g. experimental code point is not 580 recommended practice, it bares the risk of code-point collision, as 581 indicated by [RFC 3692]: It can lead to interoperability problems 582 when the chosen value collides with a different usage, as it someday 583 surely will. 585 5.3. End-to-end MPLS OAM consistency 587 In the case Service Providers deploy end-to-end MPLS solution with 588 the combination of dynamic IP/MPLS and static or dynamic MPLS-TP 589 cross core, service edge, and aggregation/access networks, end-to- 590 end MPLS OAM consistency becomes an essential requirements from many 591 Service Provider. The end-to-end MPLS OAM can only be achieved 592 through implementation of IETF MPLS-TP OAM definitions. 594 5.4. PW Design considerations in MPLS-TP networks 596 In general, PW works the same as in IP/MPLS network, both SS-PW and 597 MS-PW are supported. 599 For dynamic control plane, tLDP is used. For static provisioning is 600 used, PW status is a new PW OAM feature for failure notification. 602 In addition, both directions of a PW must be bound to the same 603 transport bidirectional LSP. 605 When multi-tier rings involved in the network topology, should S-PE 606 be used or not? It is a design trade-off. 608 . Pros for using S-PE 609 . Domain isolation, may facilitate trouble shooting 610 . the PW failure recovery may be quicker 611 . Cons for using S-PE 612 . Adds more complexity 613 . If the operation simplicity is the high priority, some 614 SPs choose not to use S-PE, simply forming longer path 615 across primary and secondary rings. 617 Should PW protection for the same end points be considered? It is 618 another design trade-off. 620 . Pros for using PW protection 621 . PW is protected when both working and protect LSPs 622 carrying the working PW fails as long as the protection 623 PW is following a diverse LSP path from the one 624 carrying the working PW. 626 MPLS-TP Use Case and Design Considerations 628 . Cons for using PW protection 629 . Adds more complexity, some may choose not to use if 630 protection against single point of failure is 631 sufficient. 633 5.5. Proactive and event driven MPLS-TP OAM tools 635 MPLS-TP provide both proactive tools and event drive OAM Tools. 637 E.g. in the proactive fashion, the BFD hellos can be sent every 3.3 638 ms as its lowest interval, 3 missed hellos would be trigger the 639 failure protection switch over. BFD sessions should be configured 640 for both working and protecting LSPs. 642 When Unidirectional Failure occurs, RDI will send the failure 643 notification to the opposite direction to trigger both end switch 644 over. 646 In the reactive fashion, when there is a fiber cut for example, LDI 647 message would be generated from the failure point and propagate to 648 MEP to trigger immediate switch over from working to protect path. 649 And AIS would propagate from MIP to MEP for alarm suppression. 651 Should both proactive and event driven OAM tools be used? The answer 652 is yes. 654 Should BFD timers be set as low as possible? It depends on the 655 applications. In many cases, it is not necessary. The lower the 656 times are, the faster the detection time, and also the higher 657 resource utilization. It is good to choose a balance point. 659 5.6. MPLS-TP and IP/MPLS Interworking considerations 661 Since IP/MPLS is largely deployment in most networks, MPLS-TP and 662 IP/MPLS interworking is a reality. 664 Typically, there is peer model and overlay model. 666 The inter-connection can be simply VLAN, or PW, or could be MPLS-TE. 667 A separate document is addressing the in the interworking issues, 668 please refer to the descriptions in [Interworking]. 670 5.7. Delay and delay variation 671 MPLS-TP Use Case and Design Considerations 672 Background/motivation: Telecommunication Carriers plan to replace 673 the aging TDM Services (e.g. legacy VPN services) provided by Legacy 674 TDM technologies/equipments to new VPN services provided by MPLS-TP 675 technologies/equipments with minimal cost. The Carriers cannot allow 676 any degradation of service quality, service operation Level, and 677 service availability when migrating out of Legacy TDM 678 technologies/equipments to MPLS-TP transport. The requirements from 679 the customers of these carriers are the same before and after the 680 migration. 682 5.7.1. Network Delay 684 From our recent observation, more and more Ethernet VPN customers 685 becoming very sensitive to the network delay issues, especially the 686 financial customers. Many of those customers has upgraded their 687 systems in their Data Centers, e.g., their accounting systems. Some 688 of the customers built the special tuned up networks, i.e. Fiber 689 channel networks, in their Data Centers, this tripped more strict 690 delay requirements to the carriers. 692 There are three types of network delay: 694 1. Absolute Delay Time 696 Absolute Delay Time here is the network delay within SLA contract. 697 It means the customers have already accepted the value of the 698 Absolute Delay Time as part of the contract before the Private Line 699 Service is provisioned. 701 2. Variation of Absolute Delay Time (without network configuration 702 changes). 704 The variation under discussion here is mainly induced by the 705 buffering in network elements. 707 Although there is no description of Variation of Absolute Delay Time 708 on the contract, this has no practical impact on the customers who 709 contract for the highest quality of services available. The 710 bandwidth is guaranteed for those customers' traffic. 712 3. Relative Delay Time 714 Relative Delay Time is the difference of the Absolute Delay Time 715 between using working and protect path. 717 MPLS-TP Use Case and Design Considerations 718 Ideally, Carriers would prefer the Relative Delay Time to be zero, 719 for the following technical reasons and network operation 720 feasibility concerns. 722 The following are the three technical reasons: 724 Legacy throughput issue 726 In the case that Relative Delay Time is increased between FC 727 networks or TCP networks, the effective throughput is degraded. The 728 effective throughput, though it may be recovered after revert back 729 to the original working path in revertive mode. 731 On the other hand, in that case that Relative Delay Time is 732 decreased between FC networks or TCP networks, buffering over flow 733 may occur at receiving end due to receiving large number of busty 734 packets. As a consequence, effective throughput is degraded as 735 well. Moreover, if packet reordering is occurred due to RTT 736 decrease, unnecessary packet resending is induced and effective 737 throughput is also further degraded. Therefore, management of 738 Relative Delay Time is preferred, although this is known as the 739 legacy TCP throughput issue. 741 Locating Network Acceralators at CE 743 In order to improve effective throughput between customer's FC 744 networks over Ethernet private line service, some customer put "WAN 745 Accelerator" to increase throughput value. For example, some WAN 746 Accelerators at receiving side may automatically send back "R_RDY" 747 in order to avoid decreasing a number of BBcredit at sending side, 748 and the other WAN Accelerators at sending side may have huge number 749 of initial BB credit. 751 When customer tunes up their CE by locating WAN Accelerator, for 752 example, when Relative Delay Time is changes, there is a possibility 753 that effective throughput is degraded. This is because a lot of 754 packet destruction may be occurred due to loss of synchronization, 755 when change of Relative delay time induces packet reordering. And, 756 it is difficult to re-tune up their CE network element automatically 757 when Relative Delay Time is changed, because only less than 50 ms 758 network down detected at CE. 760 Depending on the tuning up method, since Relative Delay Time affects 761 effective throughput between customer's FC networks, management of 762 Relative Delay Time is preferred. 764 c) Use of synchronized replication system 765 MPLS-TP Use Case and Design Considerations 766 Some strict customers, e.g. financial customers, implement 767 "synchronized replication system" for all data back-up and load 768 sharing. Due to synchronized replication system, next data 769 processing is conducted only after finishing the data saving to both 770 primary and replication DC storage. And some tuning function could 771 be applied at Server Network to increase throughput to the 772 replication DC and Client Network. Since Relative Delay Time affects 773 effective throughput, management of Relative Delay Time is 774 preferred. 776 The following are the network operational feasibility issues. 778 Some strict customers, e.g., financial customer, continuously 779 checked the private line connectivity and absolute delay time at 780 CEs. When the absolute delay time is changed, that is Relative 781 delay time is increased or decreased, the customer would complain. 783 From network operational point of view, carrier want to minimize the 784 number of customers complains, MPLS-TP LSP provisioning with zero 785 Relative delay time is preferred and management of Relative Delay 786 Time is preferred. 788 Obviously, when the Relative Delay Time is increased, the customer 789 would complain about the longer delay. When the Relative Delay Time 790 is decreased, the customer expects to keep the lesser Absolute Delay 791 Time condition and would complain why Carrier did not provide the 792 best solution in the first place. Therefore, MPLS-TP LSP 793 provisioning with zero Relative Delay Time is preferred and 794 management of Relative Delay Time is preferred. 796 More discussion will be added on how to manage the Relative delay 797 time. 799 5.8. More on MPLS-TP Deployment Considerations 801 5.8.1. Network Modes Selection 803 When considering deployment of MPLS-TP in the network, possibly 804 couple of questions will come into mind, for example, where should 805 the MPLS-TP be deployed? (e.g., access, aggregation or core 806 network?) Should IP/MPLS be deployed with MPLS-TP simultaneously? If 807 MPLS-TP and IP/MPLS is deployed in the same network, what is the 808 relationship between MPLS-TP and IP/MPLS (e.g., peer or overlay?) 809 and where is the demarcation between MPLS-TP domain and IP/MPLS 810 MPLS-TP Use Case and Design Considerations 811 domain? The results for these questions depend on the real 812 requirements on how MPLS-TP and IP/MPLS are used to provide 813 services. For different services, there could be different choice. 814 According to the combination of MPLS-TP and IP/MPLS, here are some 815 typical network modes: 817 Pure MPLS-TP as the transport connectivity (E2E MPLS-TP), this 818 situation more happens when the network is a totally new constructed 819 network. For example, a new constructed packet transport network for 820 Mobile Backhaul, or migration from ATM/TDM transport network to 821 packet based transport network. 823 Pure IP/MPLS as transport connectivity (E2E IP/MPLS), this is the 824 current practice for many deployed networks. 825 MPLS-TP combines with IP/MPLS as the transport connectivity (Hybrid 826 mode) 827 Peer mode, some domains adopt MPLS-TP as the transport connectivity; 828 other domains adopt IP/MPLS as the transport connectivity. MPLS-TP 829 domains and IP/MPLS domains are interconnected to provide transport 830 connectivity. Considering there are a lot of IP/MPLS deployments in 831 the field, this mode may be the normal practice in the early stage 832 of MPLS-TP deployment. 833 Overlay mode 834 b-1: MPLS-TP as client of IP/MPLS, this is for the case where MPLS- 835 TP domains are distributed and IP/MPLS do-main/network is used for 836 the connection of the distributed MPLS-TP domains. For examples, 837 there are some service providers who have no their own Backhaul 838 network, they have to rent the Backhaul network that is IP/MPLS 839 based from other service providers. 841 b-2: IP/MPLS as client of MPLS-TP, this is for the case where 842 transport network below the IP/MPLS network is a MPLS-TP based 843 network, the MPLS-TP network provides transport connectivity for the 844 IP/MPLS routers, the usage is analogous as today's ATM/TDM/SDH based 845 transport network that are used for providing connectivity for 846 IP/MPLS routers. 848 5.8.2. Provisioning Modes Select 849 ion 850 As stated in MPLS-TP requirements [RFC 5654], MPLS-TP network MUST 851 be possible to work without using Control Plane. And this does not 852 mean that MPLS-TP network has no control plane. Instead, operators 853 could deploy their MPLS-TP with static provisioning (e.g., CLI, NMS 854 etc.), dynamic control plane signaling (e.g., OSPF-TE/ISIS-TE, 855 GMPLS, LDP, RSVP-TE etc.), or combination of static and dynamic 856 provisioning (Hybrid mode). Each mode has its own pros and cons and 857 how to determine the right mode for a specific network mainly 858 MPLS-TP Use Case and Design Considerations 859 depends on the operators' preference. For the operators who are used 860 to operate traditional transport network and familiar with the 861 Transport-Centric operational model (e.g., NMS configuration without 862 control plane) may prefer static provisioning mode. The dynamic 863 provisioning mode is more suitable for the operators who are 864 familiar with the operation and maintenance of IP/MPLS network where 865 a fully dynamic control plane is used. The hybrid mode may be used 866 when parts of the network are provisioned with static way and the 867 other parts are controlled by dynamic signaling. For example, for 868 big SP, the network is operated and maintained by several different 869 departments who prefer to different modes, thus they could adopt 870 this hybrid mode to support both static and dynamic modes hence to 871 satisfy different requirements. Another example is that static 872 provisioning mode is suitable for some parts of the network and 873 dynamic provisioning mode is suitable for other parts of the 874 networks (e.g., static for access network, dynamic for metro 875 aggregate and core network). 877 6. Security Considerations 879 Reference to [RFC 5920]. More will be added. 881 7. IANA Considerations 883 This document contains no new IANA considerations. 885 8. Normative References 887 [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural 888 Considerations for a Transport Profile, Feb. 2009. 890 [RFC 5654], Niven-Jenkins, B., et al, "MPLS-TP Requirements," RFC 891 5654, September 2009. 893 9. Informative References 894 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 895 Requirement Levels", BCP 14, RFC 2119, March 1997. 897 [RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers 898 Considered Useful", RFC 3692, Jan. 2004. 900 [RFC 5921] Bocci, M., ED., Bryant, S., ED., et al., Frost, D. ED., 901 Levrau, L., Berger., L., "A Framework for MPLS in Transport," July 902 2010. 904 MPLS-TP Use Case and Design Considerations 906 [RFC 5920] Fang, L., ED., et al, "Security Framework for MPLS and 907 GMPLS Networks," July 2010. 909 [RFC 6372] Sprecher, N., Ferrel, A., MPLS transport Profile 910 Survivability Framework [RFC 6372], September 2011. 912 [OAM Tool Set] Sprecher, N., Fang, L., "An Overview of the OAM Tool 913 Set for MPLS Based Transport Networks, ", draft-ietf-mpls-to-oam- 914 analysis-06.txt, Oct. 2011, work in progress. 916 [Interworking] Martinotti, R., et al., "Interworking between MPLS-TP 917 and IP/MPLS", draft-martinotti-mpls-tp-interworking-02.txt, June 918 2011. 920 10. Author's Addresses 922 Luyuan Fang 923 Cisco Systems, Inc. 924 111 Wood Ave. South 925 Iselin, NJ 08830 926 USA 927 Email: lufang@cisco.com 929 Nabil Bitar 930 Verizon 931 40 Sylvan Road 932 Waltham, MA 02145 933 USA 934 Email: nabil.bitar@verizon.com 936 Raymond Zhang 937 British Telecom 938 BT Center 939 81 Newgate Street 940 London, EC1A 7AJ 941 United Kingdom 942 Email: raymond.zhang@bt.com 944 Masahiro DAIKOKU 945 KDDI corporation 946 3-11-11.Iidabashi, Chiyodaku, Tokyo 947 Japan 948 Email: ms-daikoku@kddi.com 949 MPLS-TP Use Case and Design Considerations 950 Kam Lee Yap 951 XO Communications 952 13865 Sunrise Valley Drive, 953 Herndon, VA 20171 954 Email: klyap@xo.com 956 Dan Frost 957 Cisco Systems, Inc. 958 Email:danfrost@cisco.com 960 Henry Yu 961 TW Telecom 962 10475 Park Meadow Dr. 963 Littleton, CO 80124 964 Email: henry.yu@twtelecom.com 966 Jian Ping Zhang China Telecom, Shanghai 967 Room 3402, 211 Shi Ji Da Dao 968 Pu Dong District, Shanghai 969 China Email: zhangjp@shtel.com.cn 971 Lei Wang 972 Telenor 973 Telenor Norway 974 Office Snaroyveien 975 1331 Fornedbu 976 Email: Lai.wang@telenor.com 978 Mach(Guoyi) Chen 979 Huawei Technologies Co., Ltd. 980 No. 3 Xinxi Road 981 Shangdi Information Industry Base 982 Hai-Dian District, Beijing 100085 983 China 984 Email: mach@huawei.com 986 Nurit Sprecher 987 Nokia Siemens Networks 988 3 Hanagar St. Neve Ne'eman B 989 Hod Hasharon, 45241 990 Israel 991 Email: nurit.sprecher@nsn.com