idnits 2.17.1 draft-ietf-pals-mpls-tp-dual-homing-protection-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 are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 21, 2016) is 2951 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-pals-endpoint-fast-protection-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Cheng 3 Internet-Draft L. Wang 4 Intended status: Informational H. Li 5 Expires: September 22, 2016 China Mobile 6 K. Liu 7 Huawei Technologies 8 S. Davari 9 Broadcom Corporation 10 J. Dong 11 Huawei Technologies 12 A. D'Alessandro 13 Telecom Italia 14 March 21, 2016 16 Dual-Homing Protection for MPLS and MPLS-TP Pseudowires 17 draft-ietf-pals-mpls-tp-dual-homing-protection-02 19 Abstract 21 This document describes a framework and several scenarios for 22 pseudowire (PW) dual-homing local protection. A Dual-Node 23 Interconnection (DNI) PW is provisioned between the dual-homing 24 Provider Edge (PE) nodes for carrying traffic when failure occurs in 25 the Attachment Circuit (AC) or PW side. In order for the dual-homing 26 PE nodes to determine the forwarding state of AC, PW and the DNI PW, 27 necessary state exchange and coordination between the dual-homing PEs 28 are needed. The PW dual-homing local protection mechanism is 29 complementary to the existing PW protection mechanisms. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 22, 2016. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Reference Models of Dual-homing Local Protection . . . . . . 3 73 2.1. PE Architecture . . . . . . . . . . . . . . . . . . . . . 3 74 2.2. Dual-Homing Local Protection Reference Scenarios . . . . 4 75 2.2.1. One-Side Dual-Homing Protection . . . . . . . . . . . 4 76 2.2.2. Two-side Dual-Homing Protection . . . . . . . . . . . 6 77 3. Generic Dual-homing PW Protection Mechanism . . . . . . . . . 7 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 6.2. Informative References . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 [RFC6372] and [RFC6378] describe the framework and mechanism of MPLS- 88 TP Linear protection, which can provide protection for the MPLS LSP 89 or pseudowire (PW) between the edge nodes. Such mechanism does not 90 protect the failure of the Attachment Circuit (AC) or the Provider 91 Edge (PE) node. [RFC6718] and [RFC6870] describe the framework and 92 mechanism for PW redundancy to provide protection for AC or PE node 93 failure. The PW redundancy mechanism is based on the signaling of 94 Label Distribution Protocol (LDP), which is applicable to PWs with a 95 dynamic control plane. [I-D.ietf-pals-endpoint-fast-protection] 96 describes a fast local repair mechanism for PW egress endpoint 97 failures, which is based on PW redundancy, upstream label assignment 98 and context specific label switching. Such mechanism is applicable 99 to PWs with a dynamic control plane. 101 In some scenarios such as mobile backhauling, the MPLS PWs are 102 provisioned with dual-homing topology, in which at least the CE node 103 in one side is dual-homed to two PEs. If some fault occurs in the 104 primary AC, operators usually prefer to have the switchover only in 105 the dual-homing PE side and keeps the working pseudowires unchanged 106 if possible. This is to avoid massive PWs switchover in the mobile 107 backhaul network due to one AC failure in the core site, and also 108 could achieve efficient and balanced link bandwidth utilization. 109 Similarly, it is preferable to keep using the working AC when one 110 working PW fails in the Packet Switched Network (PSN) network. To 111 meet the above requirement, a fast dual-homing PW local protection 112 mechanism is needed to protect the failures in AC, the PE node and 113 the PSN network. 115 This document describes the framework and typical scenarios for 116 pseudowire (PW) dual-homing local protection. A Dual-Node 117 Interconnection (DNI) PW is provisioned between the dual-homing PE 118 nodes for carrying traffic when failure occurs in the AC or PW side. 119 In order for the dual-homing PE nodes to determine the forwarding 120 state of AC, PW and DNI PW, necessary state exchange and coordination 121 between the dual-homing PEs is needed. The mechanism defined in this 122 document is complementary to the existing protection mechanisms. The 123 necessary protocol extensions will be described in a separate 124 document. 126 The proposed mechanism has been deployed in several mobile backhaul 127 networks which use static MPLS-TP PWs for the backhauling of mobile 128 traffic. 130 2. Reference Models of Dual-homing Local Protection 132 This section shows the reference architecture of the PE for dual- 133 homing PW local protection and the usage of the architecture in 134 different scenarios. 136 2.1. PE Architecture 138 Figure 1 shows the PE architecture for dual-homing local protection. 139 This is based on the architecture in Figure 4a of [RFC3985]. In 140 addition to the AC and the service PW, a DNI PW is provisioned to 141 connect the forwarders of the dual-homing PEs. It can be used to 142 forward traffic between the dual-homing PEs when failure occurs in 143 the AC or service PW side. As [RFC3985] specifies: "any required 144 switching functionality is the responsibility of a forwarder 145 function", in this case, the forwarder is responsible for switching 146 the payloads between three entities: the AC, the service PW and the 147 DNI PW. The specific behavior of forwarder is determined according 148 to the forwarding state machine defined in this document. 150 +----------------------------------------+ 151 | Dual-homing PE Device | 152 Single +----------------------------------------+ 153 AC | | | Service PW 154 <------>o Forwarder + Service X<===========> 155 | | PW | 156 +--------+--------+ | 157 | DNI PW | | 158 +--------X--------+----------------------+ 159 ^ 160 | DNI PW 161 | 162 V 163 +--------X-------------------------------+ 164 | Peer Dual-homing PE Device | 165 +----------------------------------------+ 167 Figure 1: PE Architecture for Dual-homing Protection 169 2.2. Dual-Homing Local Protection Reference Scenarios 171 2.2.1. One-Side Dual-Homing Protection 173 Figure 2 illustrates the network scenario of dual-homing PW local 174 protection where one of the CEs is dual-homed to two PE nodes. CE1 175 is dual-homed to PE1 and PE2, while CE2 is single-homed to PE3. DNI- 176 PW is established between the dual-homing PEs, which is used to 177 bridge traffic when a failure occurs in the PSN network or in the AC 178 side. A control mechanism enables the PEs and CE to determine which 179 AC should be used to carry traffic between CE1 and the PSN network. 180 These mechanisms/protocols are beyond the scope of this document. 181 The working and protection PWs can be determined either by 182 configuration or by existing signaling mechanisms. 184 This scenario can protect the node failure of PE1 or PE2, or the 185 failure of one of the ACs between CE1 and the dual-homing PEs. In 186 addition, dual-homing PW protection can protect the failure occured 187 in the PSN network which impacts the working PW, thus it can be an 188 alternative solution of PSN tunnel protection mechanisms. This 189 topology can be used in mobile backhauling application scenarios. 190 For example, the NodeB serves as CE2 while the Radio Network 191 Controller (RNC) serves as CE1. PE3 works as an access side MPLS 192 device while PE1 and PE2 works as core side MPLS devices. 194 |<--------------- Emulated Service --------------->| 195 | | 196 | |<------- Pseudo Wire ------>| | 197 | | | | 198 | | |<-- PSN Tunnels-->| | | 199 | V V V V | 200 V AC1 +----+ +----+ V 201 +-----+ | | PE1| | | +-----+ 202 | |----------|........PW1.(working).......| | | 203 | | | | | | | | 204 | | +-+--+ | | AC3 | | 205 | | | | | | | | 206 | CE1 | DNI-PW | |PE3 |----------| CE2 | 207 | | | | | | | 208 | | +-+--+ | | | | 209 | | | | | | | | 210 | |----------|......PW2.(protection)......| | | 211 +-----+ | | PE2| | | +-----+ 212 AC2 +----+ +----+ 213 Figure 2. One-side dual-homing PW protection 215 Consider in normal state AC1 from CE1 to PE1 is initially active and 216 AC2 from CE1 to PE2 is initially standby, PW1 is the working PW and 217 PW2 is the protection PW. 219 When a failure occurs in AC1, then the state of AC2 changes to active 220 based on some AC redundancy mechanism. In order to keep the 221 switchover local and continue using PW1 for traffic forwarding, the 222 forwarder on PE2 needs to connect AC2 to the DNI PW, and the 223 forwarder on PE1 needs to connect the DNI PW to PW1. In this way the 224 failure in AC1 will not impact the forwarding of the service PWs 225 across the network. After the switchover, traffic will go through 226 the path: CE1-(AC2)-PE2-(DNI-PW)-PE1-(PW1)-PE3-(AC3)-CE2. 228 When a failure in the PSN network affects the working PW (PW1), 229 according to PW protection mechanisms, traffic is switched onto the 230 protection PW (PW2), while the state of AC1 remains active. Then the 231 forwarder on PE1 needs to connect AC1 to the DNI PW, and the 232 forwarder on PE2 needs to connect the DNI PW to PW2. In this way the 233 failure in the PSN network will not impact the state of the ACs. 234 After the switchover, traffic will go through the path: CE1-(AC1)- 235 PE1-(DNI-PW)-PE2-(PW2)-PE3-(AC3)-CE2. 237 In both AC and PW failure cases, the dual-homing PW protection needs 238 to coordinate the PEs to set the forwarding state between the AC, 239 service PW and DNI PW properly. 241 2.2.2. Two-side Dual-Homing Protection 243 Figure 3 illustrates the network scenario of dual-homing PW 244 protection where the CEs in both sides are dual-homed. CE1 is dual- 245 homed to PE1 and PE2, and CE2 is dual-homed to PE3 and PE4. A dual- 246 homing control mechanism enables the PEs and CEs to determine which 247 AC should be used to carry traffic between CE and the PSN network. 248 DNI-PWs are provisioned between the dual-homing PEs on both sides. 249 One service PW is established between PE1 and PE3, another service PW 250 is established between PE2 and PE4. The role of working and 251 protection PW can be determined either by configuration or via 252 existing signaling mechanisms. 254 This scenario can protect the node failure on one of the dual-homing 255 PEs, or the failure on one of the ACs between the CEs and their dual- 256 homing PEs. Meanwhile, dual-homing PW protection can protect the 257 failure occured in the PSN network which impacts one of the PWs, thus 258 it can be an alternative solution of PSN tunnel protection 259 mechanisms. This scenario is mainly used for services of important 260 business customers. In this case, CE1 and CE2 can be regarded as 261 service access points. 263 |<---------------- Emulated Service -------------->| 264 | | 265 | |<-------- Pseudowire ------>| | 266 | | | | 267 | | |<-- PSN Tunnels-->| | | 268 | V V V V | 269 V AC1 +----+ +----+ AC3 V 270 +-----+ | | ...|...PW1.(working)..|... | | +-----+ 271 | |----------| PE1| | PE3|----------| | 272 | | +----+ +----+ | | 273 | | | | | | 274 | CE1 | DNI-PW1 | | DNI-PW2 | CE2 | 275 | | | | | | 276 | | +----+ +----+ | | 277 | | | | | | | | 278 | |----------| PE2| | PE4|--------- | | 279 +-----+ | | ...|.PW2.(protection).|... | | +-----+ 280 AC2 +----+ +----+ AC4 282 Figure 3. Two-side dual-homing PW protection 284 Consider in normal state AC1 from CE1 to PE1 is initially active and 285 AC2 from CE1 to PE2 is initially standby, AC3 from CE2 to PE3 is 286 initially active and AC4 from CE2 to PE4 is initially standby, PW1 is 287 the working PW and PW2 is the protection PW. 289 When a failure occurs in AC1, the state of AC2 changes to active 290 based on some AC redundancy mechanism. In order to keep the 291 switchover local and continue using PW1 for traffic forwarding, the 292 forwarder on PE2 needs to connect AC2 to the DNI-PW1, and the 293 forwarder on PE1 needs to connect DNI-PW1 with PW1. In this way 294 failures in the AC side will not impact the forwarding of the service 295 PWs across the network. After the switchover, traffic will go 296 through the path: CE1-(AC2)-PE2-(DNI-PW1)-PE1-(PW1)-PE3-(AC3)-CE2. 298 When a failure occurs in the working PW (PW1), according to the PW 299 protection mechanism, traffic is switched onto the protection PW 300 "PW2". In order to keep the state of AC1 and AC3 unchanged, the 301 forwarder on PE1 needs to connect AC1 to DNI-PW1, and the forwarder 302 on PE2 needs to connect DNI-PW1 to PW2. On the other side, the 303 forwarder of PE3 needs to connect AC3 to DNI-PW2, and the forwarder 304 on PE4 needs to connect PW2 to DNI-PW2. In this way, the state of 305 the ACs will not be impacted by the failure in the PSN network. 306 After the switchover, traffic will go through the path: CE1-(AC1)- 307 PE1-(DNI-PW1)-PE2-(PW2)-PE4-(DNI-PW2)-PE3-(AC3)-CE2. 309 In case both the AC and PW failure occur, the dual-homing PW 310 protection needs to coordinate the PEs to set the forwarding state 311 between the AC, service PW and the DNI PW properly. 313 3. Generic Dual-homing PW Protection Mechanism 315 As shown in the above scenarios, with the described dual-homing PW 316 protection, failures in the AC side will not impact the forwarding 317 behavior of the PWs in the PSN network, and vice-versa. This is 318 achieved by properly setting the forwarding state between the 319 following entities: 321 o AC 323 o Service PW 325 o DNI PW 327 The forwarding behavior of the dual-homing PE nodes are determined by 328 the forwarding state machine as shown in table 1: 330 +-----------+---------+--------+---------------------+ 331 |Service PW | AC | DNI PW | Forwarding Behavior | 332 +-----------+---------+--------+---------------------+ 333 | Active | Active | Up |Service PW <-> AC | 334 +-----------+---------+--------+---------------------+ 335 | Active | Standby | Up |Service PW <-> DNI PW| 336 +-----------+---------+--------+---------------------+ 337 | Standby | Active | Up | DNI PW <-> AC | 338 +-----------+---------+--------+---------------------+ 339 | Standby | Standby | Up | Drop all packets | 340 +-----------+---------+--------+---------------------+ 341 Table 1. Dual-homing PE Forwarding State Machine 343 In order for the dual-homing PEs to coordinate the traffic forwarding 344 during the failures, synchronization of the status information of the 345 involved entities and coordination of switchover between the dual- 346 homing PEs are needed. For PWs with a dynamic control plane, such 347 information synchronization and coordination can be achieved with a 348 dynamic protocol, such as [RFC7275], possibly with some extensions. 349 For PWs which are manually configured without a control plane, a new 350 mechanism is needed to exchange the status information and coordinate 351 switchover between the dual-homing PEs. This is described in a 352 separate document. 354 4. IANA Considerations 356 This document does not require any IANA action. 358 5. Security Considerations 360 The mechanism defined in this document do not affect the security 361 model as defined in [RFC3985]. 363 6. References 365 6.1. Normative References 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, 369 DOI 10.17487/RFC2119, March 1997, 370 . 372 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 373 Edge-to-Edge (PWE3) Architecture", RFC 3985, 374 DOI 10.17487/RFC3985, March 2005, 375 . 377 6.2. Informative References 379 [I-D.ietf-pals-endpoint-fast-protection] 380 Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, "PW 381 Endpoint Fast Failure Protection", draft-ietf-pals- 382 endpoint-fast-protection-02 (work in progress), January 383 2016. 385 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 386 Profile (MPLS-TP) Survivability Framework", RFC 6372, 387 DOI 10.17487/RFC6372, September 2011, 388 . 390 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 391 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 392 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 393 October 2011, . 395 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 396 Redundancy", RFC 6718, DOI 10.17487/RFC6718, August 2012, 397 . 399 [RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire 400 Preferential Forwarding Status Bit", RFC 6870, 401 DOI 10.17487/RFC6870, February 2013, 402 . 404 [RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., 405 Matsushima, S., and T. Nadeau, "Inter-Chassis 406 Communication Protocol for Layer 2 Virtual Private Network 407 (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, 408 DOI 10.17487/RFC7275, June 2014, 409 . 411 Authors' Addresses 413 Weiqiang Cheng 414 China Mobile 415 No.32 Xuanwumen West Street 416 Beijing 100053 417 China 419 Email: chengweiqiang@chinamobile.com 420 Lei Wang 421 China Mobile 422 No.32 Xuanwumen West Street 423 Beijing 100053 424 China 426 Email: Wangleiyj@chinamobile.com 428 Han Li 429 China Mobile 430 No.32 Xuanwumen West Street 431 Beijing 100053 432 China 434 Email: Lihan@chinamobile.com 436 Kai Liu 437 Huawei Technologies 438 Huawei Base, Bantian, Longgang District 439 Shenzhen 518129 440 China 442 Email: alex.liukai@huawei.com 444 Shahram Davari 445 Broadcom Corporation 446 3151 Zanker Road 447 San Jose 95134-1933 448 United States 450 Email: davari@broadcom.com 452 Jie Dong 453 Huawei Technologies 454 Huawei Campus, No. 156 Beiqing Rd. 455 Beijing 100095 456 China 458 Email: jie.dong@huawei.com 459 Alessandro D'Alessandro 460 Telecom Italia 461 via Reiss Romoli, 274 462 Torino 10148 463 Italy 465 Email: alessandro.dalessandro@telecomitalia.it