idnits 2.17.1 draft-ietf-pals-mpls-tp-dual-homing-protection-06.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 (April 26, 2017) is 2555 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-pals-mpls-tp-dual-homing-coordination-05 Summary: 0 errors (**), 0 flaws (~~), 2 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: October 28, 2017 China Mobile 6 S. Davari 7 Broadcom Corporation 8 J. Dong 9 Huawei Technologies 10 April 26, 2017 12 Dual-Homing Protection for MPLS and MPLS-TP Pseudowires 13 draft-ietf-pals-mpls-tp-dual-homing-protection-06 15 Abstract 17 This document describes a framework and several scenarios for a 18 Pseudowire (PW) dual-homing local protection mechanism which avoids 19 unnecessary switchovers and which can be used for scenarios using a 20 control plane or not using a control plane. A Dual-Node 21 Interconnection (DNI) PW is used for carrying traffic between the 22 dual-homing Provider Edge (PE) nodes for carrying traffic when a 23 failure occurs in one of the Attachment Circuits (AC) or PWs. This 24 PW dual-homing local protection mechanism is complementary to 25 existing PW protection mechanisms. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 28, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Reference Models of Dual-homing Local Protection . . . . . . 3 63 2.1. PE Architecture . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Dual-Homing Local Protection Reference Scenarios . . . . 4 65 2.2.1. One-Side Dual-Homing Protection . . . . . . . . . . . 4 66 2.2.2. Two-side Dual-Homing Protection . . . . . . . . . . . 6 67 3. Generic Dual-homing PW Protection Mechanism . . . . . . . . . 8 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 7.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 [RFC6372] and [RFC6378] describe the framework and mechanism of MPLS- 79 TP Linear protection, which can provide protection for the MPLS LSP 80 or pseudowire (PW) between the edge nodes. This mechanism does not 81 protect the failure of the Attachment Circuit (AC) or the Provider 82 Edge (PE) node. [RFC6718] and [RFC6870] describe the framework and 83 mechanism for PW redundancy to provide protection for AC or PE node 84 failure. The PW redundancy mechanism is based on the signaling of 85 Label Distribution Protocol (LDP), which is applicable to PWs with a 86 dynamic control plane. [I-D.ietf-pals-endpoint-fast-protection] 87 describes a fast local repair mechanism for PW egress endpoint 88 failures, which is based on PW redundancy, upstream label assignment 89 and context specific label switching. The mechanism defined in 90 [I-D.ietf-pals-endpoint-fast-protection] is only applicable to PWs 91 with a dynamic control plane. 93 There is a need to support a dual-homing local protection mechanism 94 which avoids unnecessary switches of the AC or PW, and which can be 95 used regardless if a control plane is used. In some scenarios such 96 as mobile backhauling, the MPLS PWs are provisioned with dual-homing 97 topology, in which at least the CE node on one side is dual-homed to 98 two PEs. If some fault occurs in the primary AC, operators usually 99 prefer to have the switchover only on the dual-homing PE side and 100 keep the working pseudowires unchanged if possible. This is to avoid 101 massive PW switchover in the mobile backhaul network due to the AC 102 failure in the mobile core site, which may in turn lead to congestion 103 due to the migration of traffic from the paths preferred by the 104 network planners. Similarly, as multiple PWs share the physical AC 105 in the mobile core site, it is preferable to keep using the working 106 AC when one working PW fails in PSN network, which could avoid 107 unnecessary switchover for other PWs. To meet the above 108 requirements, a fast dual-homing local PW protection mechanism is 109 needed to protect against the failures of an AC, the PE node, and the 110 PSN network. 112 This document describes the framework and several typical scenarios 113 of pseudowire (PW) dual-homing local protection. A Dual-Node 114 Interconnection (DNI) PW is used between the dual-homing PE nodes for 115 carrying traffic when a failure occurs in the AC or PW side. In 116 order for the dual-homing PE nodes to determine the forwarding state 117 of AC, PW and DNI PW, necessary state exchange and coordination 118 between the dual-homing PEs is needed. The necessary mechanisms and 119 protocol extensions are defined in a companion document 120 [I-D.ietf-pals-mpls-tp-dual-homing-coordination]. 122 2. Reference Models of Dual-homing Local Protection 124 This section shows the reference architecture of the dual-homing PW 125 local protection and the usage of the architecture in different 126 scenarios. 128 2.1. PE Architecture 130 Figure 1 shows the PE architecture for dual-homing local protection. 131 This is based on the architecture in Figure 4a of [RFC3985]. In 132 addition to the AC and the service PW between the local and remote 133 PEs, a DNI PW is used to connect the forwarders of the dual-homing 134 PEs. It can be used to forward traffic between the dual-homing PEs 135 when a failure occurs in the AC or service PW side. As [RFC3985] 136 specifies: "any required switching functionality is the 137 responsibility of a forwarder function", in this case, the forwarder 138 is responsible for switching the payloads between three entities: the 139 AC, the service PW and the DNI PW. 141 +----------------------------------------+ 142 | Dual-homing PE Device | 143 +----------------------------------------+ 144 AC | | | Service PW 145 <------>o Forwarder + Service X<===========> 146 | | PW | 147 +--------+--------+ | 148 | DNI PW | | 149 +--------X--------+----------------------+ 150 ^ 151 | DNI PW 152 | 153 V 154 +--------X--------+----------------------+ 155 | DNI PW | | 156 +--------+--------+ | Service PW 157 AC | | Service X<===========> 158 <------>o Forwarder + PW | 159 | | | 160 +----------------------------------------+ 161 | Dual-homing PE Device | 162 +----------------------------------------+ 163 Figure 1: PE Architecture for Dual-homing Protection 165 2.2. Dual-Homing Local Protection Reference Scenarios 167 2.2.1. One-Side Dual-Homing Protection 169 Figure 2 illustrates the network scenario of dual-homing PW local 170 protection where only one of the CEs is dual-homed to two PE nodes. 171 CE1 is dual-homed to PE1 and PE2, while CE2 is single-homed to PE3. 172 A DNI-PW is established between the dual-homing PEs, which is used to 173 bridge traffic when a failure occurs in the PSN network or in the AC 174 side. A dual-homing control mechanism enables the PEs and CE to 175 determine which AC should be used to carry traffic between CE1 and 176 the PSN network. The necessary control mechanisms and protocol 177 extensions are defined in a companion document 178 [I-D.ietf-pals-mpls-tp-dual-homing-coordination]. 180 This scenario can protect the node failure of PE1 or PE2, or the 181 failure of one of the ACs between CE1 and the dual-homing PEs. In 182 addition, dual-homing PW protection can protect a failure occuring in 183 the PSN network which impacts the working PW, thus it can be an 184 alternative solution of PSN tunnel protection mechanisms. This 185 topology can be used in mobile backhauling application scenarios. 186 For example, CE2 might be a cell site equipment such as a NodeB, 187 whilst CE1 is the shared Radio Network Controller (RNC). PE3 188 functions as an access side MPLS device while PE1 and PE2 function as 189 core side MPLS devices. 191 |<--------------- Emulated Service --------------->| 192 | | 193 | |<------- Pseudo Wire ------>| | 194 | | | | 195 | | |<-- PSN Tunnels-->| | | 196 | V V V V | 197 V AC1 +----+ +----+ V 198 +-----+ | | PE1| | | +-----+ 199 | |----------|........PW1.(working).......| | | 200 | | | | | | | | 201 | | +-+--+ | | AC3 | | 202 | | | | | | | | 203 | CE1 | DNI-PW | |PE3 |----------| CE2 | 204 | | | | | | | 205 | | +-+--+ | | | | 206 | | | | | | | | 207 | |----------|......PW2.(protection)......| | | 208 +-----+ | | PE2| | | +-----+ 209 AC2 +----+ +----+ 210 Figure 2. One-side dual-homing PW protection 212 Consider in normal state AC1 from CE1 to PE1 is initially active and 213 AC2 from CE1 to PE2 is initially standby, PW1 is the working PW and 214 PW2 is the protection PW. 216 When a failure occurs in AC1, then the state of AC2 changes to active 217 based on the AC dual-homing control mechanism. In order to keep the 218 switchover local and continue using PW1 for traffic forwarding as 219 preferred according to traffic planning, the forwarder on PE2 needs 220 to connect AC2 to the DNI PW, and the forwarder on PE1 needs to 221 connect the DNI PW to PW1. In this way the failure in AC1 will not 222 impact the forwarding of the service PWs across the network. After 223 the switchover, traffic will go through the bidirectional path: CE1- 224 (AC2)-PE2-(DNI-PW)-PE1-(PW1)-PE3-(AC3)-CE2. 226 When a failure in the PSN network affects the working PW (PW1), 227 according to PW protection mechanisms [RFC6378], traffic is switched 228 onto the protection PW (PW2), while the state of AC1 remains active. 229 Then the forwarder on PE1 needs to connect AC1 to the DNI PW, and the 230 forwarder on PE2 needs to connect the DNI PW to PW2. In this way the 231 failure in the PSN network will not impact the state of the ACs. 232 After the switchover, traffic will go through the bidirectional path: 233 CE1-(AC1)-PE1-(DNI-PW)-PE2-(PW2)-PE3-(AC3)-CE2. 235 When a failure occurs in the working PE (PE1), it is equivalent to a 236 failure of the working AC, the working PW and the DNI PW. The state 237 of AC2 changes to active based on the AC dual-homing control 238 mechanism. And according to the PW protection mechanism, traffic is 239 switched on to the protection PW "PW2". In this case the forwarder 240 on PE2 needs to connect AC2 to PW2. After the switchover, traffic 241 will go through the bidirectional path: CE1-(AC2)-PE2-(PW2)-PE3- 242 (AC3)-CE2. 244 2.2.2. Two-side Dual-Homing Protection 246 Figure 3 illustrates the network scenario of dual-homing PW 247 protection where the CEs in both sides are dual-homed. CE1 is dual- 248 homed to PE1 and PE2, and CE2 is dual-homed to PE3 and PE4. A dual- 249 homing control mechanism enables the PEs and CEs to determine which 250 AC should be used to carry traffic between CE and the PSN network. 251 DNI-PWs are used between the dual-homing PEs on both sides. One 252 service PW is established between PE1 and PE3, another service PW is 253 established between PE2 and PE4. The role of working and protection 254 PW can be determined either by configuration or via existing 255 signaling mechanisms. 257 This scenario can protect the node failure on one of the dual-homing 258 PEs, or the failure on one of the ACs between the CEs and their dual- 259 homing PEs. Also, dual-homing PW protection can protect if the 260 failure occured in the PSN network which impacts one of the PWs, thus 261 it can be used as an alternative solution of PSN tunnel protection 262 mechanisms. Note, this scenario is mainly used for services 263 requiring high availability as it requires redundancy of the PEs and 264 network utilization. In this case, CE1 and CE2 can be regarded as 265 service access points. 267 |<---------------- Emulated Service -------------->| 268 | | 269 | |<-------- Pseudowire ------>| | 270 | | | | 271 | | |<-- PSN Tunnels-->| | | 272 | V V V V | 273 V AC1 +----+ +----+ AC3 V 274 +-----+ | | ...|...PW1.(working)..|... | | +-----+ 275 | |----------| PE1| | PE3|----------| | 276 | | +----+ +----+ | | 277 | | | | | | 278 | CE1 | DNI-PW1 | | DNI-PW2 | CE2 | 279 | | | | | | 280 | | +----+ +----+ | | 281 | | | | | | | | 282 | |----------| PE2| | PE4|--------- | | 283 +-----+ | | ...|.PW2.(protection).|... | | +-----+ 284 AC2 +----+ +----+ AC4 286 Figure 3. Two-side dual-homing PW protection 288 Consider in normal state, AC1 between CE1 and PE1 is initially active 289 and AC2 between CE1 and PE2 is initially standby, AC3 between CE2 and 290 PE3 is initially active and AC4 from CE2 to PE4 is initially standby, 291 PW1 is the working PW and PW2 is the protection PW. 293 When a failure occurs in AC1, the state of AC2 changes to active 294 based on the AC dual-homing control mechanism. In order to keep the 295 switchover local and continue using PW1 for traffic forwarding, the 296 forwarder on PE2 needs to connect AC2 to the DNI-PW1, and the 297 forwarder on PE1 needs to connect DNI-PW1 with PW1. In this way 298 failures in the AC side will not impact the forwarding of the service 299 PWs across the network. After the switchover, traffic will go 300 through the bidirectional path: CE1-(AC2)-PE2-(DNI-PW1)-PE1-(PW1)- 301 PE3-(AC3)-CE2. 303 When a failure occurs in the working PW (PW1), according to the PW 304 protection mechanism [RFC6378], traffic needs to be switched onto the 305 protection PW "PW2". In order to keep the state of AC1 and AC3 306 unchanged, the forwarder on PE1 needs to connect AC1 to DNI-PW1, and 307 the forwarder on PE2 needs to connect DNI-PW1 to PW2. On the other 308 side, the forwarder of PE3 needs to connect AC3 to DNI-PW2, and the 309 forwarder on PE4 needs to connect PW2 to DNI-PW2. In this way, the 310 state of the ACs will not be impacted by the failure in the PSN 311 network. After the switchover, traffic will go through the 312 bidirectional path: CE1-(AC1)-PE1-(DNI-PW1)-PE2-(PW2)-PE4-(DNI-PW2)- 313 PE3-(AC3)-CE2. 315 When a failure occurs in the working PE (PE1), it is equivalent to 316 the failures of the working AC, the working PW and the DNI PW. The 317 state of AC2 changes to active based on the AC dual-homing control 318 mechanism. And according to the PW protection mechanism, traffic is 319 switched on to the protection PW "PW2". In this case the forwarder 320 on PE2 needs to connect AC2 to PW2, and the forwarder on PE4 needs to 321 connect PW2 to DNI-PW2. After the switchover, traffic will go 322 through the bidirectional path: CE1-(AC2)-PE2-(PW2)-PE4-(DNI-PW2)- 323 PE3-(AC3)-CE2. 325 3. Generic Dual-homing PW Protection Mechanism 327 As shown in the above scenarios, with the described dual-homing PW 328 protection, failures in the AC side will not impact the forwarding 329 behavior of the PWs in the PSN network, and vice-versa. 331 In order for the dual-homing PEs to coordinate the traffic forwarding 332 during the failures, synchronization of the status information of the 333 involved entities and coordination of switchover between the dual- 334 homing PEs are needed. For PWs with a dynamic control plane, such 335 information synchronization and coordination can be achieved with a 336 dynamic protocol, such as [RFC7275], possibly with some extensions. 337 For PWs which are manually configured without a control plane, a new 338 mechanism is needed to exchange the status information and coordinate 339 switchover between the dual-homing PEs, e.g. over an embedded PW 340 control channel. This is described in a companion document 341 [I-D.ietf-pals-mpls-tp-dual-homing-coordination]. 343 4. IANA Considerations 345 This document does not require any IANA action. 347 5. Security Considerations 349 The scenarios defined in this document do not affect the security 350 model as defined in [RFC3985]. 352 With the proposed protection mechanism, the disruption of a dual- 353 homed AC, a component which is outside the core network, would have a 354 reduced impact on the traffic flows in the core network. This could 355 also avoid unnecessary congestion in the core network. 357 The security consideration of the DNI PW is the same as for Service 358 PWs in the data plane [RFC3985]. Security considerations for the 359 coordination/control mechanism will be addressed in the companion 360 document that defines the mechanism. 362 6. Contributors 364 The following individuals substantially contributed to the content of 365 this document: 367 Kai Liu 368 Huawei Technologies 369 Email: alex.liukai@huawei.com 371 Alessandro D'Alessandro 372 Telecom Italia 373 alessandro.dalessandro@telecomitalia.it 375 7. References 377 7.1. Normative References 379 [I-D.ietf-pals-mpls-tp-dual-homing-coordination] 380 Cheng, W., Wang, L., Li, H., Dong, J., and A. 381 D'Alessandro, "Dual-Homing Coordination for MPLS Transport 382 Profile (MPLS-TP) Pseudowires Protection", draft-ietf- 383 pals-mpls-tp-dual-homing-coordination-05 (work in 384 progress), January 2017. 386 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 387 Edge-to-Edge (PWE3) Architecture", RFC 3985, 388 DOI 10.17487/RFC3985, March 2005, 389 . 391 7.2. Informative References 393 [I-D.ietf-pals-endpoint-fast-protection] 394 Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, "PW 395 Endpoint Fast Failure Protection", draft-ietf-pals- 396 endpoint-fast-protection-05 (work in progress), January 397 2017. 399 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 400 Profile (MPLS-TP) Survivability Framework", RFC 6372, 401 DOI 10.17487/RFC6372, September 2011, 402 . 404 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 405 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 406 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 407 October 2011, . 409 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 410 Redundancy", RFC 6718, DOI 10.17487/RFC6718, August 2012, 411 . 413 [RFC6870] Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire 414 Preferential Forwarding Status Bit", RFC 6870, 415 DOI 10.17487/RFC6870, February 2013, 416 . 418 [RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., 419 Matsushima, S., and T. Nadeau, "Inter-Chassis 420 Communication Protocol for Layer 2 Virtual Private Network 421 (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, 422 DOI 10.17487/RFC7275, June 2014, 423 . 425 Authors' Addresses 427 Weiqiang Cheng 428 China Mobile 429 No.32 Xuanwumen West Street 430 Beijing 100053 431 China 433 Email: chengweiqiang@chinamobile.com 435 Lei Wang 436 China Mobile 437 No.32 Xuanwumen West Street 438 Beijing 100053 439 China 441 Email: Wangleiyj@chinamobile.com 443 Han Li 444 China Mobile 445 No.32 Xuanwumen West Street 446 Beijing 100053 447 China 449 Email: Lihan@chinamobile.com 450 Shahram Davari 451 Broadcom Corporation 452 3151 Zanker Road 453 San Jose 95134-1933 454 United States 456 Email: davari@broadcom.com 458 Jie Dong 459 Huawei Technologies 460 Huawei Campus, No. 156 Beiqing Rd. 461 Beijing 100095 462 China 464 Email: jie.dong@huawei.com