idnits 2.17.1 draft-ietf-pals-mpls-tp-dual-homing-protection-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 15, 2015) is 3298 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. 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 17, 2015 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 April 15, 2015 16 Dual-Homing Protection for MPLS and MPLS-TP Pseudowires 17 draft-ietf-pals-mpls-tp-dual-homing-protection-00 19 Abstract 21 This document describes a framework and several scenarios for 22 pseudowire (PW) dual-homing local protection. A Dual-Node 23 Interconncetion (DNI) PW is provisioned between the dual-homing 24 Provider Edge (PE) nodes for carrying traffic when failure accurs 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 October 17, 2015. 54 Copyright Notice 56 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . 8 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 PW between the edge nodes. Such mechanism does not protect the 90 failure of the Attachement Circuit (AC) or the Provider Edge (PE) 91 node. [RFC6718] and [RFC6870] describe the framework and mechanism 92 for PW redundancy to provide protection for AC or PE node failure. 93 The PW redundancy mechanism is based on the signaling of Label 94 Distribution Protocol (LDP), which is applicable to PWs with a 95 dynamic control plane. [I-D.ietf-pwe3-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 PSN network. To meet the above requirement, 111 a fast dual-homing PW local protection mechanism is needed to protect 112 the failures in AC, the PE node and the PSN network. 114 This document describes a framework and several scenarios for 115 pseudowire (PW) dual-homing local protection. A Dual-Node 116 Interconncetion (DNI) PW is provisioned between the dual-homing 117 Provider Edge (PE) nodes for carrying traffic when failure accurs in 118 the AC or PW side. In order for the dual-homing PE nodes to 119 determine the forwarding state of AC, PW and DNI PW, necessary state 120 exchange and coordination between the dual-homing PEs is needed. The 121 mechanism defined in this document is complementary to the existing 122 protection mechanisms. The neccessary protocol extensions will be 123 described in a seperate document. 125 The proposed mechanism has been deployed in several mobile backhaul 126 networks which use static MPLS-TP PWs for the backhauling of mobile 127 traffic. 129 2. Reference Models of Dual-homing Local Protection 131 This section shows the reference architecture of the PE for dual- 132 homing PW local protection and the usage of the architecture in 133 different scenarios. 135 2.1. PE Architecture 137 Figure 1 shows the PE architecture for dual-homing local protection. 138 This is based on the architecture in Figure 4a of [RFC3985]. In 139 addition to the AC and the service PW, a DNI PW is provisioned to 140 connect the forwarders of the dual-homing PEs. It can be used to 141 forward traffic between the dual-homing PEs when failure accurs in 142 the AC or service PW side. As [RFC3985] specifies: "any required 143 switching functionality is the responsibility of a forwarder 144 function", in this case, the forwarder is responsible for switching 145 the payloads between three entities: the AC, the service PW and the 146 DNI PW. The specific behavior of forwarder is determined according 147 to the forwarding state machine defined in this document. 149 +----------------------------------------+ 150 | Dual-homing PE Device | 151 Single +----------------------------------------+ 152 AC | | | Service PW 153 <------>o Forwarder + Service X<===========> 154 | | PW | 155 +--------+--------+ | 156 | DNI PW | | 157 +--------X--------+----------------------+ 158 ^ 159 | DNI PW 160 | 161 V 162 +--------X-------------------------------+ 163 | Peer Dual-homing PE Device | 164 +----------------------------------------+ 166 Figure 1: PE Architecture for Dual-homing Protection 168 2.2. Dual-Homing Local Protection Reference Scenarios 170 2.2.1. One-Side Dual-Homing Protection 172 Figure 2 illustrates the network scenario of dual-homing PW local 173 protection where one of the CEs is dual-homed to two PE nodes. CE1 174 is dual-homed to PE1 and PE2, while CE2 is single-homed to PE3. DNI- 175 PW is established between the dual-homing PEs, which is used to 176 bridge traffic when a failure occurs in the PSN network or in the AC 177 side. A control mechanism enables the PEs and CE to determine which 178 AC should be used to carry traffic between CE1 and the PSN network. 179 These mechanisms/protocols are beyond the scope of this document. 180 The working and protection PWs can be determined either by 181 configuration or by existing signaling mechanisms. 183 This scenario can protect the node failure of PE1 or PE2, or the 184 failure of one of the ACs between CE1 and the dual-homing PEs. In 185 addition, dual-homing PW protection can protect the failure occured 186 in the PSN network which impacts the working PW, thus it can be an 187 alternative to PSN tunnel protection mechanisms. This topology can 188 be used in mobile backhauling application scenarios. For example, 189 the NodeB serves as CE2 while the RNC serves as CE1. PE3 works as an 190 access side MPLS device while PE1 and PE2 works as core side MPLS 191 devices. 193 |<--------------- Emulated Service --------------->| 194 | | 195 | |<------- Pseudo Wire ------>| | 196 | | | | 197 | | |<-- PSN Tunnels-->| | | 198 | V V V V | 199 V AC1 +----+ +----+ V 200 +-----+ | | PE1| | | +-----+ 201 | |----------|........PW1.(working).......| | | 202 | | | | | | | | 203 | | +-+--+ | | AC3 | | 204 | | | | | | | | 205 | CE1 | DNI PW | |PE3 |----------| CE2 | 206 | | | | | | | 207 | | +-+--+ | | | | 208 | | | | | | | | 209 | |----------|......PW2.(protection)......| | | 210 +-----+ | | PE2| | | +-----+ 211 AC2 +----+ +----+ 212 Figure 2. One-side dual-homing PW protection 214 Consider in normal state AC1 from CE1 to PE1 is initially active and 215 AC2 from CE1 to PE2 is initially standby, PW1 is the working PW and 216 PW2 is the protection PW. 218 When a failure occurs in AC1, then the state of AC2 changes to active 219 based on some AC redundancy mechanism. In order to keep the 220 switchover local and continue using PW1 to forward traffic, the 221 forwarder on PE2 needs to connect AC2 to the DNI PW, and the 222 forwarder on PE1 needs to connect the DNI PW to the PW1. In this way 223 the failure in the AC1 do not impact the forwarding of the service 224 PWs across the network. After the switchover, traffic will go 225 through the path: CE1-(AC2)-PE2-(DNI-PW)-PE1-(PW1)-PE3-(AC3)-CE2. 227 When a failure in the PSN network affects the working PW (PW1), 228 according to PW protection mechanisms, traffic is switched onto the 229 protection PW (PW2), while the state of AC1 remains active. Then the 230 forwarder on PE1 needs to connect AC1 to the DNI PW, and the 231 forwarder on PE2 needs to connect the DNI PW to PW2. In this way the 232 failure in the PSN network do not impact the state of the ACs. After 233 the switchover, traffic will go through the path: CE1-(AC1)-PE1-(DNI- 234 PW)-PE2-(PW2)-PE3-(AC3)-CE2. 236 In both AC and PW failure cases, the dual-homing PW protection needs 237 to coordinate the PEs to set the forwarding state between the AC, 238 service PW and DNI PW properly. 240 2.2.2. Two-side Dual-Homing Protection 242 Figure 3 illustrates the network scenario of dual-homing PW 243 protection where the CEs in both sides are dual-homed. CE1 is dual- 244 homed to PE1 and PE2, and CE2 is dual-homed to PE3 and PE4. A dual- 245 homing control mechanism enables the PEs and CEs to determine which 246 AC should be used to carry traffic between CE and the PSN network. 247 The DNI-PWs are provisioned between the dual-homing PEs on both side. 248 One service PW is established between PE1 and PE3, another service PW 249 is established between PE2 and PE4. The role of working and 250 protection PW can be determined either by configuration or via 251 existing signaling mechansims. 253 This scenario can protect the node failure of one of the dual-homing 254 PEs, or the failure of one of the ACs between the CEs and their dual- 255 homing PEs. Meanwhile, dual-homing PW protection can protect the 256 failure occured in the PSN network which impacts one of the PWs, thus 257 it can be an alternative to PSN tunnel protection mechanisms. This 258 scenario is mainly used for services provisioning for important 259 business customers. In this case, CE1 and CE2 can be regarded as 260 service access points. 262 |<---------------- Emulated Service -------------->| 263 | | 264 | |<-------- Pseudowire ------>| | 265 | | | | 266 | | |<-- PSN Tunnels-->| | | 267 | V V V V | 268 V AC1 +----+ +----+ AC3 V 269 +-----+ | | ...|...PW1.(working)..|... | | +-----+ 270 | |----------| PE1| | PE3|----------| | 271 | | +----+ +----+ | | 272 | | | | | | 273 | CE1 | DNI PW1 | | DNI PW2 | CE2 | 274 | | | | | | 275 | | +----+ +----+ | | 276 | | | | | | | | 277 | |----------| PE2| | PE4|--------- | | 278 +-----+ | | ...|.PW2.(protection).|... | | +-----+ 279 AC2 +----+ +----+ AC4 281 Figure 3. Two-side dual-homing PW protection 283 Consider in normal state AC1 from CE1 to PE1 is initially active and 284 AC2 from CE1 to PE2 is initially standby, AC3 from CE2 to PE3 is 285 initially active and AC4 from CE2 to PE4 is initially standby, PW1 is 286 the working PW and PW2 is the protection PW. 288 When a failure occurs in AC1, the state of AC2 changes to active 289 based on some AC redundancy mechanism. In order to keep the 290 switchover local and continue using PW1 to forward traffic, the 291 forwarder on PE2 needs to connect AC2 to the DNI PW, and the 292 forwarder on PE1 needs to connect the DNI PW with PW1. In this way 293 failures in the AC side do not impact the forwarding of the service 294 PWs across the network. After the switchover, traffic will go 295 through the path: CE1-(AC2)-PE2-(DNI-PW1)-PE1-(PW1)-PE3-(AC3)-CE2. 297 When a failure occurs in the working PW (PW1), according to the PW 298 protection mechanism, traffic is switched onto the protection PW 299 "PW2". In order to keep the state of AC1 and AC3 unchanged, the 300 forwarder on PE1 needs to connect AC1 to the DNI-PW1, and the 301 forwarder on PE2 needs to connect the DNI-PW1 to PW2. On the other 302 side, the forwarder of PE3 needs to connect AC3 to the DNI-PW2, and 303 the forwarder on PE4 needs to connect PW2 to the DNI-PW2. In this 304 way, the state of the ACs will not be impacted by the failure in the 305 PSN network. After the switchover, traffic will go through the path: 306 CE1-(AC1)-PE1-(DNI-PW1)-PE2-(PW2)-PE4-(DNI-PW2)-PE3-(AC3)-CE2. 308 In both AC and PW failure cases, the dual-homing PW protection needs 309 to coordinate the PEs to set the forwarding state between the AC, 310 service PW and the DNI PW properly. 312 3. Generic Dual-homing PW Protection Mechanism 314 As shown in the above scenarios, with the described Dual-Homing PW 315 Protection, the failures in the AC side do not impact the forwarding 316 behavior of the PWs in the PSN network, and vice-versa. This is 317 achieved by properly setting the forwarding state between the 318 following entities: 320 o AC 322 o Service PWs 324 o DNI PW 326 The forwarding behavior of the dual-homing PE nodes are determined by 327 the forwarding state machine as shown in table 1: 329 +-----------+---------+--------+---------------------+ 330 |Service PW | AC | DNI PW | Forwarding Behavior | 331 +-----------+---------+--------+---------------------+ 332 | Active | Active | Up |Service PW <-> AC | 333 +-----------+---------+--------+---------------------+ 334 | Active | Standby | Up |Service PW <-> DNI PW| 335 +-----------+---------+--------+---------------------+ 336 | Standby | Active | Up | DNI PW <-> AC | 337 +-----------+---------+--------+---------------------+ 338 | Standby | Standby | Up | Drop all packets | 339 +-----------+---------+--------+---------------------+ 340 Table 1. Dual-homing PE Forwarding State Machine 342 In order for the dual-homing PEs to coordinate the traffic forwarding 343 during the failures, synchronization of the status information of the 344 involved entities and coordination of switchover between the dual- 345 homing PEs are needed. For PWs with a dynamic control plane, such 346 information sychronization and coordination can be achieved with a 347 dynamic protocol, such as [RFC7275], possibly with some extensions. 348 For PWs which are manually configured without a control plane, a new 349 mechanism is needed to exchange the status information and coordinate 350 switchover between the dual-homing PEs. This is described in a 351 separate document. 353 4. IANA Considerations 355 This document does not require any IANA action. 357 5. Security Considerations 359 The mechanism defined in this document do not affect the security 360 model as defined in [RFC3985]. 362 6. References 364 6.1. Normative References 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, March 1997. 369 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 370 Edge (PWE3) Architecture", RFC 3985, March 2005. 372 6.2. Informative References 374 [I-D.ietf-pwe3-endpoint-fast-protection] 375 Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, "PW 376 Endpoint Fast Failure Protection", draft-ietf-pwe3- 377 endpoint-fast-protection-02 (work in progress), January 378 2015. 380 [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- 381 TP) Survivability Framework", RFC 6372, September 2011. 383 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 384 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 385 Protection", RFC 6378, October 2011. 387 [RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire 388 Redundancy", RFC 6718, August 2012. 390 [RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential 391 Forwarding Status Bit", RFC 6870, February 2013. 393 [RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., 394 Matsushima, S., and T. Nadeau, "Inter-Chassis 395 Communication Protocol for Layer 2 Virtual Private Network 396 (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, June 397 2014. 399 Authors' Addresses 401 Weiqiang Cheng 402 China Mobile 403 No.32 Xuanwumen West Street 404 Beijing 100053 405 China 407 Email: chengweiqiang@chinamobile.com 409 Lei Wang 410 China Mobile 411 No.32 Xuanwumen West Street 412 Beijing 100053 413 China 415 Email: Wangleiyj@chinamobile.com 416 Han Li 417 China Mobile 418 No.32 Xuanwumen West Street 419 Beijing 100053 420 China 422 Email: Lihan@chinamobile.com 424 Kai Liu 425 Huawei Technologies 426 Huawei Base, Bantian, Longgang District 427 Shenzhen 518129 428 China 430 Email: alex.liukai@huawei.com 432 Shahram Davari 433 Broadcom Corporation 434 3151 Zanker Road 435 San Jose 95134-1933 436 United States 438 Email: davari@broadcom.com 440 Jie Dong 441 Huawei Technologies 442 Huawei Campus, No. 156 Beiqing Rd. 443 Beijing 100095 444 China 446 Email: jie.dong@huawei.com 448 Alessandro D'Alessandro 449 Telecom Italia 450 via Reiss Romoli, 274 451 Torino 10148 452 Italy 454 Email: alessandro.dalessandro@telecomitalia.it