idnits 2.17.1 draft-ietf-pwe3-redundancy-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 3, 2012) is 4375 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6073' is defined on line 699, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Muley 3 Internet-Draft M. Aissaoui 4 Intended status: Informational M. Bocci 5 Expires: November 4, 2012 Alcatel-Lucent 6 May 3, 2012 8 Pseudowire Redundancy 9 draft-ietf-pwe3-redundancy-08 11 Abstract 13 This document describes a framework comprised of a number of 14 scenarios and associated requirements for pseudowire (PW) redundancy. 15 A set of redundant PWs is configured between provider edge (PE) nodes 16 in single -segment PW applications, or between terminating PE (T-PE) 17 nodes in multi-segment PW applications. In order for the PE/T-PE 18 nodes to indicate the preferred PW to use for forwarding PW packets 19 to one another, a new PW status is required to indicate the 20 preferential forwarding status of active or standby for each PW in 21 the redundancy set. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 4, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. PE Architecture . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. PW Redundancy Network Reference Scenarios . . . . . . . . 5 68 3.2.1. Single Multi-Homed CE . . . . . . . . . . . . . . . . 5 69 3.2.2. Multiple Multi-Homed CEs . . . . . . . . . . . . . . . 7 70 3.2.3. Single-Homed CE With MS-PW Redundancy . . . . . . . . 8 71 3.2.4. PW Redundancy Between MTU-s in H-VPLS . . . . . . . . 9 72 3.2.5. PW Redundancy Between VPLS Network Facing PEs 73 (n-PEs) . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.2.6. Redundancy in a VPLS Bridge Module Model . . . . . . . 12 75 4. Generic PW Redundancy Requirements . . . . . . . . . . . . . . 13 76 4.1. Protection Switching Requirements . . . . . . . . . . . . 13 77 4.2. Operational Requirements . . . . . . . . . . . . . . . . . 13 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 14 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 The objective of PW redundancy is to enable redundant attachment 90 circuits (ACs), provider edge nodes (PEs), and pseudowires (PWs) to 91 eliminate single points of failure in the path of an emulated 92 service. This is achieved while ensuring that only one active path 93 exists between a pair of customer edge nodes (CEs). 95 In single-segment PW (SS-PW) applications, protection for the PW is 96 provided by the packet switched network (PSN) layer. This may be a 97 resource reservation protocol with traffic engineering (RSVP-TE) 98 labeled switched path (LSP) with a fast-reroute (FRR) backup or an 99 end-to-end backup LSP. It is assumed that these mechanisms can 100 restore PSN connectivity rapidly enough to avoid triggering 101 protection by PW redundancy. PSN protection mechanisms cannot 102 protect against the failure of a PE node or the failure of the remote 103 AC. Typically, this is supported by dual-homing a customer edge (CE) 104 node to different PE nodes which provide a pseudowire emulated 105 service across the PSN. A set of PW mechanisms is therefore required 106 that enables a primary and one or more backup PWs to terminate on 107 different PE nodes. 109 In multi-segment PW (MS-PW) applications, PSN protection mechanisms 110 cannot protect against the failure of a switching PE (S-PE). A set 111 of mechanisms that support the operation of a primary and one or more 112 backup PWs via a different set of S-PEs is therefore required. The 113 paths of these PWs are diverse in the sense that they are switched at 114 different S-PE nodes. 116 In both of these applications, PW redundancy is important to maximise 117 the resiliency of the emulated service. 119 This document describes the framework for these applications and its 120 associated operational requirements. The framework utilizes a new PW 121 status, called the Preferential Forwarding Status of the PW. This is 122 separate from the operational states defined in RFC4447 [RFC4447]. 123 The mechanisms for PW redundancy are modeled on general protection 124 switching principles. 126 2. Terminology 128 o Up PW: A PW which has been configured (label mapping exchanged 129 between PEs) and is not in any of the PW defect states specified 130 in [RFC4447]. Such a PW is is available for forwarding traffic. 132 o Down PW: A PW that has either not been fully configured, or has 133 been configured and is in any one of the PW defect states 134 specified in [RFC4447]. Such a PW is not available for forwarding 135 traffic. 137 o Active PW: An UP PW used for forwarding user, OAM and control 138 plane traffic. 140 o Standby PW: An UP PW that is not used for forwarding user traffic 141 but may forward OAM and specific control plane traffic. 143 o PW Endpoint: A PE where a PW terminates on a point where native 144 service processing is performed, e.g., A single-segment PW (SS-PW) 145 PE, a multi-segment pseudowire (MS-PW) terminating PE (T-PE), or a 146 hierarchical VPLS MTU-s or PE-rs. 148 o Primary PW: The PW which a PW endpoint activates (i.e. uses for 149 forwarding) in preference to any other PW when more than one PW 150 qualifies for the active state. When the primary PW comes back up 151 after a failure and qualifies for the active state, the PW 152 endpoint always reverts to it. The designation of primary is 153 performed by local configuration for the PW at the PE and is only 154 required when revertive behaviour is used. 156 o Secondary PW: When it qualifies for the active state, a secondary 157 PW is only selected if no primary PW is configured or if the 158 configured primary PW does not qualify for active state (e.g., is 159 DOWN). By default, a PW in a redundancy PW set is considered 160 secondary. There is no revertive mechanism among secondary PWs. 162 o Revertive protection switching: Traffic will be carried by the 163 primary PW if it is UP and a wait-to-restore timer expires and the 164 primary PW is made the active PW. 166 o Non-revertive protection switching: Traffic will be carried by the 167 last PW selected as a result of previous active PW entering the 168 operationally DOWN state. 170 o Manual selection of a PW: The ability to manually select the 171 primary/secondary PWs. 173 o MTU-s: A hierarchical virtual private LAN service multi-tenant 174 unit switch, as defined in RFC4762 [RFC4762]. 176 o PE-rs: A hierarchical virtual private LAN service switch, as 177 defined in RFC4762. 179 o n-PE: A network facing provider edge node, as defined in RFC4026 180 [RFC4026]. 182 This document uses the term 'PE' to be synonymous with both PEs as 183 per RFC3985[RFC3985] and T-PEs as per RFC5659 [RFC5659]. 185 This document uses the term 'PW' to be synonymous with both PWs as 186 per RFC3985 and SS-PWs, MS-PWs, and PW segments as per RFC5659. 188 3. Reference Models 190 The following sections show the reference architecture of the PE for 191 PW redundancy and the usage of the architecture in different 192 topologies and applications. 194 3.1. PE Architecture 196 Figure 1 shows the PE architecture for PW redundancy when more than 197 one PW in a redundant set is associated with a single AC. This is 198 based on the architecture in Figure 4b of RFC3985 [RFC3985]. The 199 forwarder selects which of the redundant PWs to use based on the 200 criteria described in this document. 202 +----------------------------------------+ 203 | PE Device | 204 +----------------------------------------+ 205 Single | | Single | PW Instance 206 AC | + PW Instance X<===========> 207 | | | 208 | |----------------------| 209 <------>o | Single | PW Instance 210 | Forwarder + PW Instance X<===========> 211 | | | 212 | |----------------------| 213 | | Single | PW Instance 214 | + PW Instance X<===========> 215 | | | 216 +----------------------------------------+ 218 Figure 1: PE Architecture for PW redundancy 220 3.2. PW Redundancy Network Reference Scenarios 222 This section presents a set of reference scenarios for PW redundancy. 224 3.2.1. Single Multi-Homed CE 226 The following figure illustrates an application of single segment 227 pseudowire redundancy. This scenario is designed to protect the 228 emulated service against a failure of one of the PEs or ACs attached 229 to the multi-homed CE. Protection against failures of the PSN 230 tunnels is provided using PSN mechanisms such as MPLS fast reroute, 231 so that these failures do not impact the PW. 233 CE1 is dual-homed to PE1 and PE3. A dual homing control protocol, 234 the details of which are outside the scope of this document, selects 235 which AC CE1 should use to forward towards the PSN, and which PE (PE1 236 or PE3) should forward towards CE1. 238 |<-------------- Emulated Service ---------------->| 239 | | 240 | |<------- Pseudo Wire ------>| | 241 | | | | 242 | | |<-- PSN Tunnels-->| | | 243 | V V V V | 244 V AC +----+ +----+ AC V 245 +-----+ | | PE1|==================| | | +-----+ 246 | |----------|....|...PW1.(active)...|....|----------| | 247 | | | |==================| | | CE2 | 248 | CE1 | +----+ |PE2 | | | 249 | | +----+ | | +-----+ 250 | | | |==================| | 251 | |----------|....|...PW2.(standby)..| | 252 +-----+ | | PE3|==================| | 253 AC +----+ +----+ 255 Figure 2: PW Redundancy with One Multi-Homed CE 257 In this scenario, only one of the PWs should be used for forwarding 258 between PE1 / PE3, and PE2. PW redundancy determines which PW to 259 make active based on the forwarding state of the ACs so that only one 260 path is available from CE1 to CE2. 262 Consider the example where the AC from CE1 to PE1 is initially active 263 and the AC from CE1 to PE3 is initially standby. PW1 is made active 264 and PW2 is made standby in order to complete the path to CE2. 266 On failure of the AC between CE1 and PE1, the forwarding state of the 267 AC on PE3 transitions to Active. The preferential forwarding state 268 of PW2 therefore needs to become active, and PW1 standby, in order to 269 reestablish connectivity between CE1 and CE2. PE3 therefore uses PW2 270 to forward towards CE2, and PE2 uses PW2 instead of PW1 to forward 271 towards CE1. PW redundancy in this scenario requires that the 272 forwarding status of the ACs at PE1 and PE3 be signaled to PE2 so 273 that PE2 can choose which PW to make active. 275 Changes occurring on the dual-homed side of the network due to a 276 failure of the AC or PE are not propagated to the ACs on the other 277 side of the network. Furthermore, failures in the PSN are not 278 propagated to the attached CEs. 280 3.2.2. Multiple Multi-Homed CEs 282 This scenario, illustrated in Figure 3, is also designed to protect 283 the emulated service against failures of the ACs and failures of the 284 PEs. Both CE1 and CE2, are dual-homed to their respective PEs, PE1 285 and PE2, and PE3 and PE4. The method used by the CEs to choose which 286 AC to use to forward traffic towards the PSN is determined by a dual- 287 homing control protocol. The details of this protocol are outside 288 the scope of this document. 290 Note that the PSN tunnels are not shown in this figure for clarity. 291 However, it can be assumed that each of the PWs shown is encapsulated 292 in a separate PSN tunnel. Protection against failures of the PSN 293 tunnels is provided using PSN mechanisms such as MPLS fast reroute, 294 so that these failures do not impact the PW. 295 |<-------------- Emulated Service ---------------->| 296 | | 297 | |<------- Pseudowire ------->| | 298 | | | | 299 | | |<-- PSN Tunnels-->| | | 300 | V V V V | 301 V AC +----+ +----+ AC V 302 +-----+ | |....|.......PW1........|....| | +-----+ 303 | |----------| PE1|...... .........| PE3|----------| | 304 | CE1 | +----+ \ / PW3 +----+ | CE2 | 305 | | +----+ X +----+ | | 306 | | | |....../ \..PW4....| | | | 307 | |----------| PE2| | PE4|--------- | | 308 +-----+ | |....|.....PW2..........|....| | +-----+ 309 AC +----+ +----+ AC 311 Figure 3: Multiple Multi-Homed CEs with PW Redundancy 313 PW1 and PW4 connect PE1 to PE3 and PE4, respectively. Similarly, PW2 314 and PW3 connect PE2 to PE4 and PE3. PW1, PW2, PW3 and PW4 are all 315 UP. In order to support N:1 or 1:1 protection, only one PW MUST be 316 selected to forward traffic. This document defines an additional PW 317 state that reflects this forwarding state, which is separate from the 318 operational status of the PW. This is the 'Preferential Forwarding 319 Status'. 321 If a PW has a preferential forwarding status of 'active', it can be 322 used for forwarding traffic. The actual UP PW chosen by the combined 323 set of PEs connected to the CEs is determined by considering the 324 preferential forwarding status of each PW at each PE. The mechanisms 325 for communicating the preferential forwarding status are outside the 326 scope of this document. Only one PW is used for forwarding. 328 The following failure scenario illustrates the operation of PW 329 redundancy in Figure 3. In the initial steady state, when there are 330 no failures of the ACs, one of the PWs is chosen as the active PW, 331 and all others are chosen as standby. The dual-homing protocol 332 between CE1 and PE1/PE2 chooses to use the AC to PE2, while the 333 protocol between CE2 and PE3/PE4 chooses to use the AC to PE4. 334 Therefore the PW between PE2 and PE4 is chosen as the active PW to 335 complete the path between CE1 and CE2. 337 On failure of the AC between the dual-homed CE1 and PE2, the 338 preferential forwarding status of the PWs at PE1, PE2, PE3 and PE4 339 needs to change so as to re-establish a path from CE1 to CE2. 340 Different mechanisms can be used to achieve this and these are beyond 341 the scope of this document. After the change in status, the 342 algorithm needs to revaluate and select which PW to forward traffic 343 on. In this application, each dual-homing algorithm, i.e., {CE1, 344 PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently. 345 There is therefore a need to signal the active status of each AC such 346 that the PEs can select a common active PW for forwarding between CE1 347 and CE2. 349 Changes occurring on one side of network due to a failure of the AC 350 or PE are not propagated to the ACs on the other side of the network. 351 Furthermore, failures in the PSN are not propagated to the attached 352 CEs. Note that end-to-end native service protection switching can 353 also be used to protect the emulated service in this scenario. In 354 this case, PW3 and PW4 are not necessary. 356 If the CEs do not perform native service protection switching, they 357 may instead use load balancing across the paths between the CEs. 359 3.2.3. Single-Homed CE With MS-PW Redundancy 361 This application is shown in Figure 4. The main objective is to 362 protect the emulated service against failures of the S-PEs. 364 Native |<----------- Pseudowires ----------->| Native 365 Service | | Service 366 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 367 | V V V V V V | 368 | +-----+ +-----+ +-----+ | 369 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 370 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 371 | CE1| | |=========| |=========| | | CE2| 372 | | +-----+ +-----+ +-----+ | | 373 +----+ |.||.| |.||.| +----+ 374 |.||.| +-----+ |.||.| 375 |.||.|=========| |========== .||.| 376 |.||...PW2-Seg1......|.PW2-Seg2...||.| 377 |.| ===========|S-PE2|============ |.| 378 |.| +-----+ |.| 379 |.|============+-----+============= .| 380 |.....PW3-Seg1.| | PW3-Seg2......| 381 ==============|S-PE3|=============== 382 | | 383 +-----+ 385 Figure 4: Single-Homed CE with MS-PW Redundancy 387 CE1 is connected to PE1 and CE2 is connected to PE2. There are three 388 multi-segment PWs. PW1 is switched at S-PE1, PW2 is switched at 389 S-PE2, and PW3 is switched at S-PE3. 391 Since there is no multi-homing running on the ACs, the T-PE nodes 392 advertise 'active' for the preferential forwarding status based on a 393 priority for the PW. The priority associates a meaning of 'primary 394 PW' and 'secondary PW' to a PW. These priorities MUST be used if 395 revertive mode is used and the active PW to use for forwarding 396 determined accordingly. The priority can be derived via 397 configuration or based on the value of the PW FEC. For example, a 398 lower value of PWid FEC can be taken as a higher priority. However, 399 this does not guarantee selection of same PW by the T-PEs because of, 400 for example, a mismatch in the configuration of the PW priority at 401 each T-PE. The intent of this application is for T-PE1 and T-PE2 to 402 synchronize the transmit and receive paths of the PW over the 403 network. In other words, both T-PE nodes are required to transmit 404 over the PW segment which is switched by the same S-PE. This is 405 desirable for ease of operation and troubleshooting. 407 3.2.4. PW Redundancy Between MTU-s in H-VPLS 409 The following figure (based on the architecture shown in Figure 3 of 410 [RFC4762]) illustrates the application of PW redundancy to 411 hierarchical VPLS (H-VPLS). Note that the PSN tunnels are not shown 412 for clarity, and only one PW of a PW group is shown. Here, a multi- 413 tenant unit switch (MTU-s) is dual-homed to two PE router switches 414 (PE-rs). 416 PE1-rs 417 +--------+ 418 | VSI | 419 Active PW | -- | 420 Group..........|../ \..|. 421 CE-1 . | \ / | . 422 \ . | -- | . 423 \ . +--------+ . 424 \ MTU-s . . . PE3-rs 425 +--------+ . . . +--------+ 426 | VSI | . . H-VPlS .| VSI | 427 | -- ..|.. . Core |.. -- | 428 | / \ | . PWs | / \ | 429 | \ /..|.. . | \ / | 430 | -- | . . .|.. -- | 431 +--------+ . . . +--------+ 432 / . . . 433 / . +--------+ . 434 / . | VSI | . 435 CE-2 . | -- | . 436 ..........|../ \..|. 437 Standby PW | \ / | 438 Group | -- | 439 +--------+ 440 PE2-rs 442 Figure 5: MTU-s Dual Homing in H-VPLS Core 444 In Figure 5, the MTU-s is dual homed to PE1-rs and PE2-rs and has 445 spoke PWs to each of them. The MTU-s needs to choose only one of the 446 spoke PWs (the active PW) to forward traffic to one of the PEs, and 447 sets the other PW to standby. The MTU-s can derive the status of the 448 PWs based on local policy configuration. PE1-rs and PE2-rs are 449 connected to the H-VPLS core on the other side of network. The MTU-s 450 communicates the status of its member PWs for a set of virtual 451 switching instances (VSIs) that share a common status of active or 452 standby. Here, the MTU-s controls the selection of PWs used to 453 forward traffic. Signaling using PW grouping with a common group-id 454 in the PWid FEC Element, or a Grouping TLV in Generalized PWid FEC 455 Element as defined in [RFC4447], to PE1-rs and PE2-rs, is recommended 456 for improved scaling. 458 Whenever an MTU-s performs a switchover of the active PW group, it 459 needs to communicate this status change the PE2-rs. That is, it 460 informs PE2-rs that the status of the standby PW group has changed to 461 active. 463 In this scenario, PE devices are aware of switchovers at the MTU-s 464 and could generate MAC Withdraw messages to trigger MAC flushing 465 within the H-VPLS full-mesh. By default, MTU-s devices should still 466 trigger MAC withdraw messages as defined in [RFC4762] to prevent two 467 copies of MAC withdraws to be sent (one by the MTU-s and another one 468 by the PE-rs'). Mechanisms to disable the MAC withdraw trigger in 469 certain devices are out of the scope of this document. 471 3.2.5. PW Redundancy Between VPLS Network Facing PEs (n-PEs) 473 The following figure illustrates the use of PW redundancy for dual- 474 homed connectivity between PEs in a ring topology. As above, PSN 475 tunnels are not shown and only one PW of a PW group is shown for 476 clarity. 478 PE1 PE2 479 +--------+ +--------+ 480 | VSI | | VSI | 481 | -- | | -- | 482 ......|../ \..|.....................|../ \..|....... 483 | \ / | PW Group 1 | \ / | 484 | -- | | -- | 485 +--------+ +--------+ 486 . . 487 . . 488 VPLS Domain A . . VPLS Domain B 489 . . 490 . . 491 . . 492 +--------+ +--------+ 493 | VSI | | VSI | 494 | -- | | -- | 495 ......|../ \..|.....................|../ \..|........ 496 | \ / | PW Group 2 | \ / | 497 | -- | | -- | 498 +--------+ +--------+ 499 PE3 PE4 501 Figure 6: Redundancy in a Ring Topology 503 In Figure 6, PE1 and PE3 from VPLS domain A are connected to PE2 and 504 PE4 in VPLS domain B via PW group 1 and PW group 2. The PEs are 505 connected to each other in such a way as to form a ring topology. 506 Such scenarios may arise in inter-domain H-VPLS deployments where 507 rapid spanning tree (RSTP) or other mechanisms may be used to 508 maintain loop free connectivity of the PW groups. 510 [RFC4762] outlines multi-domain VPLS services without specifying how 511 multiple redundant border PEs per domain and per VPLS instance can be 512 supported. In the example above, PW group 1 may be blocked at PE1 by 513 RSTP and it is desirable to block the group at PE2 by exchanging the 514 PW preferential forwarding status of standby. The details of how PW 515 grouping is achieved and used is deployment specific and is outside 516 the scope of this document. 518 3.2.6. Redundancy in a VPLS Bridge Module Model 520 |<----- Provider ----->| 521 Core 522 +------+ +------+ 523 | n-PE |::::::::::::::::::::::| n-PE | 524 Provider | (P) |.......... .........| (P) | Provider 525 Access +------+ . . +------+ Access 526 Network X Network 527 (1) +------+ . . +------+ (2) 528 | n-PE |.......... .........| n-PE | 529 | (B) |......................| (B) | 530 +------+ +------+ 532 Figure 7: Bridge Module Model 534 Bridge Module Model 536 Figure 7 shows a scenario with two provider access networks. Each 537 network has two n-Pes. These n-PEs are connected via a full mesh of 538 PWs for a given VPLS instance. As shown in the figure, only one n-PE 539 in each access network serves as the primary PE (P) for that VPLS 540 instance and the other n-PE serves as the backup PE (B). In this 541 figure, each primary PE has two active PWs originating from it. 542 Therefore, when a multicast, broadcast, or unknown unicast frame 543 arrives at the primary n-PE from the access network side, the n-PE 544 replicates the frame over both PWs in the core even though it only 545 needs to send the frames over a single PW (shown with :::: in the 546 figure) to the primary n-PE on the other side. This is an 547 unnecessary replication of the customer frames that consumes core- 548 network bandwidth (half of the frames get discarded at the receiving 549 n-PE). This issue gets aggravated when there is three or more n-PEs 550 per provider, access network. For example if there are three n-PEs 551 or four n-PEs per access network, then 67% or 75% of core 552 bandwidthfor multicast, broadcast and unknown unicast are wasted, 553 respectively. 555 In this scenario, the n-PEs can communicate the active or standby 556 status of the PWs among them. This status can be derived from the 557 active or backup state of an n-PE for a given VPLS. 559 4. Generic PW Redundancy Requirements 561 4.1. Protection Switching Requirements 563 o Protection architectures such as N:1,1:1 or 1+1 are possible. 1:1 564 protection MUST be supported. The N:1 protection case is less 565 efficient in terms of the resources that must be allocated and 566 hence this SHOULD be supported. 1+1 protection MAY be used in the 567 scenarios described in the document. However, the details of its 568 usage are outside the scope of this document. 570 o Non-revertive behavior MUST be supported, while revertive behavior 571 is OPTIONAL. This avoids the need to designate one PW as primary 572 unless revertive behavior is explicitly required. 574 o Protection switchover can be initiated from a PE e.g. using a 575 manual lockout/force switchover, or it may be triggered by a 576 signal failure i.e. a defect in the PW or PSN. Manual switchover 577 may be necessary if it is required to disable one PW in a 578 redundant set. Both methods MUST be supported and signal failure 579 triggers MUST be treated with a higher priority than any local or 580 far-end manual trigger. 582 o Note that a PE MAY be able to forward packets received from a PW 583 with a standby status in order to avoid black holing of in-flight 584 packets during switchover. However, in the case of use of VPLS, 585 all VPLS application packets received from standby PWs MUST be 586 dropped, except for OAM packets. 588 4.2. Operational Requirements 590 o (T-)PEs involved in protecting a PW SHOULD automatically discover 591 and attempt to resolve inconsistencies in the configuration of 592 primary/secondary PW. 594 o (T-)PEs involved in protecting a PW SHOULD automatically discover 595 and attempt to resolve inconsistencies in the configuration of 596 revertive/non-revertive protection switching mode. 598 o (T-)PEs that do not automatically discover or resolve 599 inconsistencies in the configuration of primary/secondary, 600 revertive/non-revertive, or other parameters MUST generate an 601 alarm upon detection of an inconsistent configuration. 603 o (T-)PEs participating in PW redundancy MUST support the 604 configuration of revertive or non-revertive protection switching 605 modes if both modes are supported. 607 o (T-)PEs participating in PW redundancy SHOULD support the local 608 invocation of protection switching. 610 o (T-)PEs participating in PW redundancy SHOULD support the local 611 invocation of a lockout of protection switching. 613 5. Security Considerations 615 This document requires extensions to the Label Distribution Protocol 616 (LDP) that are needed for protecting pseudowires. These will inherit 617 at least the same security properties as LDP [RFC5036] and the PW 618 control protocol [RFC4447]. 620 6. IANA Considerations 622 This document has no actions for IANA. 624 7. Major Contributing Authors 626 The editors would like to thank Pranjal Kumar Dutta, Marc Lasserre, 627 Jonathan Newton, Hamid Ould-Brahim, Olen Stokes, Dave Mcdysan, Giles 628 Heron and Thomas Nadeau who made a major contribution to the 629 development of this document. 631 Pranjal Dutta 632 Alcatel-Lucent 633 Email: pranjal.dutta@alcatel-lucent.com 635 Marc Lasserre 636 Alcatel-Lucent 637 Email: marc.lasserre@alcatel-lucent.com 639 Jonathan Newton 640 Cable & Wireless 641 Email: Jonathan.Newton@cw.com 643 Olen Stokes 644 Extreme Networks 645 Email: ostokes@extremenetworks.com 647 Hamid Ould-Brahim 648 Nortel 649 Email: hbrahim@nortel.com 651 Dave McDysan 652 Verizon 653 Email: dave.mcdysan@verizon.com 655 Giles Heron 656 Cisco Systems 657 Email: giles.heron@gmail.com 659 Thomas Nadeau 660 Computer Associates 661 Email: tnadeau@lucidvision.com 663 8. Acknowledgements 665 The authors would like to thank Vach Kompella, Kendall Harvey, 666 Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus and Philippe 667 Niger for their valuable comments and suggestions. 669 9. References 671 9.1. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, March 1997. 676 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 677 Edge (PWE3) Architecture", RFC 3985, March 2005. 679 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 680 Private Network (VPN) Terminology", RFC 4026, March 2005. 682 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 683 Heron, "Pseudowire Setup and Maintenance Using the Label 684 Distribution Protocol (LDP)", RFC 4447, April 2006. 686 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 687 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 688 RFC 4762, January 2007. 690 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 691 Specification", RFC 5036, October 2007. 693 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 694 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 695 October 2009. 697 9.2. Informative References 699 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 700 Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. 702 Authors' Addresses 704 Praveen Muley 705 Alcatel-Lucent 707 Email: praveen.muley@alcatel-lucent.com 709 Mustapha Aissaoui 710 Alcatel-Lucent 712 Email: mustapha.aissaoui@alcatel-lucent.com 714 Matthew Bocci 715 Alcatel-Lucent 717 Email: matthew.bocci@alcatel-lucent.com