idnits 2.17.1 draft-muley-pwe3-redundancy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.3 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 460. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (September 22, 2006) is 6397 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (ref. '2') (Obsoleted by RFC 8077) == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-02 -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 3036 (ref. '5') (Obsoleted by RFC 5036) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Praveen Muley 2 Internet Draft Mustapha Aissaoui 3 Expires: March 2007 Matthew Bocci 4 Alcatel 6 Jonathan Newton 7 Cable & Wireless 9 September 22, 2006 11 Pseudowire (PW) Redundancy 12 draft-muley-pwe3-redundancy-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that 17 any applicable patent or other IPR claims of which he or she is 18 aware have been or will be disclosed, and any of which he or she 19 becomes aware will be disclosed, in accordance with Section 6 of 20 BCP 79. 22 This document may only be posted in an Internet-Draft. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on March 22, 2007. 42 Abstract 44 This document describes a few scenarios where PW redundancy is 45 needed. A set of redundant PWs is configured between PE nodes in SS- 46 PW applications, or between T-PE nodes in MS-PW applications. In 47 order for the PE/T-PE nodes to indicate the preferred PW path to 48 forward to one another, a new status bit is needed to indicate the 49 preferential forwarding status of active or standby for each PW in 50 the redundancy set. This draft specifies a new PW status bit for this 51 purpose. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC-2119 [1]. 59 Table of Contents 61 1. Terminology.................................................2 62 2. Introduction................................................3 63 3. Multi-homing Single SS-PW redundancy applications............4 64 3.1. One Multi-homed CE with Single SS-PW redundancy..........4 65 3.2. Multiple Multi-homed CEs with single SS-PW redundancy....5 66 4. Multi-homing MS-PW redundancy applications...................6 67 4.1. Multi-homed CE with MS-PW redundancy....................6 68 4.2. Single Homed CE with MS-PW redundancy...................7 69 5. Design considerations........................................8 70 6. Security Considerations......................................9 71 7. IANA Considerations.........................................9 72 7.1. Status Code for PW Preferential Forwarding Status........9 73 8. Acknowledgments.............................................9 74 9. References..................................................9 75 Author's Addresses............................................10 76 Intellectual Property Statement................................10 77 Disclaimer of Validity........................................11 78 Copyright Statement...........................................11 79 Acknowledgment................................................11 81 1. Terminology 83 o PW Terminating Provider Edge (T-PE). A PE where the customer- 84 facing attachment circuits (ACs) are bound to a PW forwarder. A 85 Terminating PE is present in the first and last segments of a MS- 86 PW. This incorporates the functionality of a PE as defined in 87 RFC3985 [4]. 89 o Single-Segment Pseudo Wire (SS-PW). A PW setup directly between 90 two T-PE devices. Each PW in one direction of a SS-PW traverses 91 one PSN tunnel that connects the two T-PEs. 93 o Multi-Segment Pseudo Wire (MS-PW). A static or dynamically 94 configured set of two or more contiguous PW segments that behave 95 and function as a single point-to-point PW. Each end of a MS-PW by 96 definition MUST terminate on a T-PE. 98 o PW Segment. A part of a single-segment or multi-segment PW, which 99 is set up between two PE devices, T-PEs and/or S-PEs. 101 o PW Switching Provider Edge (S-PE). A PE capable of switching the 102 control and data planes of the preceding and succeeding PW 103 segments in a MS-PW. The S-PE terminates the PSN tunnels of the 104 preceding and succeeding segments of the MS-PW. 106 o PW switching point for a MS-PW. A PW Switching Point is never the 107 S-PE and the T-PE for the same MS-PW. A PW switching point runs 108 necessary protocols to setup and manage PW segments with other PW 109 switching points and terminating PEs 111 o Active PW. A PW whose preferential status is set to Active and 112 Operational status is UP. 114 o Standby PW. A PW whose preferential status is set to Standby. 116 2. Introduction 118 In single-segment PW (SS-PW) applications, protection for the PW is 119 provided by the PSN layer. This may be an RSVP LSP with a FRR backup 120 and/or an end-to-end backup LSP. There are however applications where 121 the backup PW terminates on a different target PE node. PSN 122 protection mechanisms cannot protect against failure of the target PE 123 node or the failure of the remote AC. 125 In multi-segment PW (MS-PW) applications, a primary and multiple 126 secondary PWs in standby mode are configured in the network. The 127 paths of these PWs are diverse and are switched at different S-PE 128 nodes. In these applications, PW redundancy is important for the 129 service resilience. 131 This document describes these applications and specifies a new PW 132 status bit to indicate the preferential forwarding status of the PW 133 for the purpose of notifying the remote T-PE of the active/standby 134 state of each PW in the redundancy set. This status bit is different 135 from the operational status bits already defined in the PWE3 control 136 protocol [2]. The PW with both local and remote operational UP status 137 and local and remote preferential active status is selected to 138 forward traffic. 140 3. Multi-homing Single SS-PW redundancy applications 142 3.1. One Multi-homed CE with single SS-PW redundancy 144 The following figure illustrates an application of single segment 145 pseudo-wire redundancy. 147 |<-------------- Emulated Service ---------------->| 148 | | 149 | |<------- Pseudo Wire ------>| | 150 | | | | 151 | | |<-- PSN Tunnels-->| | | 152 | V V V V | 153 V AC +----+ +----+ AC V 154 +-----+ | | PE1|==================| | | +-----+ 155 | |----------|....|...PW1.(active)...|....|----------| | 156 | | | |==================| | | CE2 | 157 | CE1 | +----+ |PE2 | | | 158 | | +----+ | | +-----+ 159 | | | |==================| | 160 | |----------|....|...PW2.(standby)..| | 161 +-----+ | | PE3|==================| | 162 AC +----+ +----+ 164 Figure 1 Multi-homed CE with single SS-PW redundancy 166 In Figure 1, CE1 is dual homed to PE1 and to PE3 by attachment 167 circuits. The method for dual-homing of CE1 to PE1 and PE3 nodes and 168 the used protocols are outside the scope of this document. PE2 has an 169 attachment circuit from CE2. Two pseudo-wires pw1 and pw2 are 170 established, one connects PE1 to PE2 and the other one connects PE3 171 to PE2. On PE2, PW1 has a higher priority than PW2 by local 172 configuration. 174 In normal operation, PE1 and PE3 will advertise "Active" and 175 "Standby" preferential forwarding status (apart from operational 176 status) respectively to PE2. This status reflects the forwarding 177 state of the two AC's to CE1. PE2 advertises preferential status of 178 "Active" on both PW1 and PW2. As both the local and remote 179 operational and administrative status for PW1 are UP and Active, 180 traffic is forwarded over PW1 in both directions. 182 On failure of AC to PE1, PE1 sends a PW status notification to PE2 183 indicating that the AC operational status changed to DOWN. It will 184 also set the forwarding status of PW1 to "standby". PE3 AC will 185 change preferential status to active and this status is also 186 communicated to PE2 using the newly proposed forwarding status bit in 187 the PW status TLV notification message. The changing of preferential 188 status on PE3 due to failure of AC at PE1 is achieved by various 189 methods depending of the used dual-homing protocol and is outside the 190 scope of this draft. On receipt of the status notifications, PE2 191 switches the path to the standby pseudo-wire PW2 as the newly changed 192 status turns PW2 as Active PW. Note in this example, the receipt of 193 the operational status of the AC on the CE1-PE1 link is normally 194 sufficient to have PE2 switch the path to PW2. However, the operator 195 may want to trigger the switchover of the path of the PW for 196 administrative reasons, i.e., maintenance, and thus the proposed PW 197 forwarding active/standby bit is required to notify PE2 to trigger 198 the switchover. 200 3.2. Multiple Multi-homed CEs with single SS-PW redundancy 202 |<-------------- Emulated Service ---------------->| 203 | | 204 | |<------- Pseudo Wire ------>| | 205 | | | | 206 | | |<-- PSN Tunnels-->| | | 207 | V V V V | 208 V AC +----+ +----+ AC V 209 +-----+ | |....|.......PW1........|....| | +-----+ 210 | |----------| PE1|...... .........| PE3|----------| | 211 | CE1 | +----+ \ / PW3 +----+ | CE2 | 212 | | +----+ X +----+ | | 213 | | | |....../ \..PW4....| | | | 214 | |----------| PE2| | PE4|--------- | | 215 +-----+ | |....|.....PW2..........|....| | +-----+ 216 AC +----+ +----+ AC 218 Figure 2 Multiple Multi-homed CEs with single SS-PW redundancy 220 In the figure illustrated above the both CEs CE1 and CE2 are dual- 221 homed with PEs, PE1, PE2 and PE3, PE4 respectively. The method for 222 dual-homing and the used protocols are outside the scope of this 223 document. Note that the PSN tunnels are not shown in this figure for 224 clarity. However, it can be assumed that each of the PWs shown is 225 encapsulated in a separate PSN tunnel. 227 PE1 advertises the preferential status "active" and operational 228 status "UP" for pseudo-wires PW1 and PW4 connected to PE3 and PE4. 229 This status reflects the forwarding state of the AC attached to PE1. 230 PE2 advertise preferential status "standby" where as operational 231 status "UP" for pseudo-wires PW2 and PW3 to PE3 and PE4. PE3 232 advertises preferential status "standby" where as operational status 233 "UP" for pseudo-wires PW1 and PW3 to PE1 and PE2. PE4 advertise the 234 preferential status "active" and operational status "UP" for pseudo- 235 wires PW2 and PW4 to PE2 and PE1 respectively. Thus by matching the 236 local and remote preferential status "active" and operational status 237 "Up" of pseudo-wire the active pseudo-wire is selected. In this case 238 it is the PW4 that will be selected. On failure of AC between the CE1 239 and PE1 the preferential status on PE2 is changed. Different 240 mechanisms/protocols can be used to achieve this and these are beyond 241 the scope of this document. PE2 then announces the newly changed 242 preferential status "active" to PE3 and PE4. PE1 will advertise a PW 243 status notification message indicating that the AC between CE1 and 244 PE1 is operationally down. PE2 and PE4 checks the local and remote 245 preferential status "active" and operational status "Up" and selects 246 PW2 as the new active pseudo-wire to send traffic. 248 In this application, because each dual-homing algorithm running on 249 the two node sets, i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects 250 the active AC independently, there is a need to signal the active 251 status of the AC such that the PE nodes can select a common active PW 252 path for end-to-end forwarding between CE1 and CE2. 254 4. Multi-homing MS-PW redundancy applications 256 4.1. Multi-homed CE with MS-PW redundancy 258 The following figure illustrates an application of multi-segment 259 pseudo-wire redundancy. 261 Native |<-----------Pseudo Wire----------->| Native 262 Service | | Service 263 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 264 | V V V V V V | 265 | +-----+ +-----+ +-----+ 266 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 267 | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | 268 | | | |=========| |=========| | | | 269 | CE1| +-----+ +-----+ +-----+ | | 270 | | |.| +-----+ +-----+ | CE2| 271 | | |.|===========| |=========| | | | 272 | | |.....PW2-Seg1......|.PW2-Seg2......|-------| | 273 +----+ |=============|S-PE2|=========|T-PE4| | +----+ 274 +-----+ +-----+ AC 276 Figure 3 Multi-homed CE with MS-PW redundancy 278 In Figure 3, the PEs that provide PWE3 to CE1 and CE2 are 279 Terminating-PE1 (T-PE1) and Terminating-PE2 (T-PE2) respectively. A 280 PSN tunnel extends from T-PE1 to switching-PE1 (S-PE1) across PSN1, 281 and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PW1 282 and PW2 are used to connect the attachment circuits (ACs) between T- 283 PE1 and T-PE2. Each PW segment on the tunnel across PSN1 is switched 284 to a PW segment in the tunnel across PSN2 at S-PE1 to complete the 285 multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore 286 the PW switching point. PW1 has two segments and is active pseudo- 287 wire while PW2 has two segments and is a standby pseudo-wire. This 288 application requires support for MS-PW with segments of the same type 289 as described in [3]. The operation in this case is the same as in the 290 case of SS-PW. The only difference is that the S-PW nodes need to 291 relay the PW status notification containing both the operational and 292 forwarding status to the T-PE nodes. 294 4.2. Single Homed CE with MS-PW redundancy 296 This is the main application of interest and the network setup is 297 shown in Figure 3 299 Native |<------------Pseudo Wire------------>| Native 300 Service | | Service 301 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 302 | V V V V V V | 303 | +-----+ +-----+ +-----+ | 304 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 305 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 306 | CE1| | |=========| |=========| | | CE2| 307 | | +-----+ +-----+ +-----+ | | 308 +----+ |.||.| |.||.| +----+ 309 |.||.| +-----+ |.||.| 310 |.||.|=========| |========== .||.| 311 |.||...PW2-Seg1......|.PW2-Seg2...||.| 312 |.| ===========|S-PE2|============ |.| 313 |.| +-----+ |.| 314 |.|============+-----+============= .| 315 |.....PW3-Seg1.| | PW3-Seg2......| 316 ==============|S-PE3|=============== 317 | | 318 +-----+ 320 Figure 4 Single homed CE with multi-segment pseudo-wire redundancy 322 In Figure 4, CE1 is connected to PE1 in provider Edge 1 and CE2 to 323 PE2 in provider edge 2 respectively. There are three segmented PWs. A 324 primary PW, PW1, is switched at S-PE1. A standby PW, PW2, which is 325 switched at S-PE2 and has a priority of 1. Finally, another standby 326 PW, PW3, is switched at S-PE3 and has a priority of 2. This means T- 327 PE1 and T-PE2 will select PW1 over PW2, and PW2 over PW3 if all of 328 them are in the UP state. Moreover, a T-PE node will revert back to 329 the primary PW, PW1, whenever it comes back up. 331 The intent of this application is to have T-PE1 and T-PE2 synchronize 332 the transmit and receive paths of the PW over the network. In other 333 words, both T-PE nodes will transmit over the PW segment which is 334 switched by the same S-PE. This is desirable for ease of operation 335 and troubleshooting. 337 Since there is no multi-homing running on the AC, the T-PE nodes 338 would advertise 'Active" for the forwarding status. However, this 339 does not guarantee that the paths of the PW are synchronized because 340 for example of mismatch of the configuration of the PW priority in 341 each T-PE. Thus, there is a need to devise an augmented mechanism to 342 achieve the desirable synchronization of the PW paths and to add the 343 ability to have a T-PE instruct the remote T-PE to perform a 344 coordinated switchover to a common Active path. 346 The solution required for this specific scenario is left for further 347 study. 349 5. Design considerations 351 While using the pseudo-wire redundancy application, the T-LDP peers 352 MUST negotiate the usage of PW status TLV. The status code defined 353 below carries the active/standby preferential forwarding status of 354 the pseudo-wire. The pseudo-wire is only considered active pseudo- 355 wire only when both the local PW status and the remote PW status 356 indicate preferential status "active" and operational status as Up. 357 Any other status combination keeps the pseudo-wire in standby mode. 358 The pseudo-wires are given different preference level. In case of 359 network failure, the PE/T-PE will first switch to the standby PW with 360 a higher preference. Although the configuration of the pseudo-wire 361 preference is matter of local policy matter and is outside the scope 362 of this, it is desirable to have the preferences configured on both 363 end points be similar. In mis-configuration, a method to force the 364 synchronization of the PW paths is required is for further study. 365 While in standby status, a pseudo-wire can still receive packets in 366 order to avoid black holing of the in-flight packets during 367 switchover. 369 6. Security Considerations 371 This document specifies the LDP extensions that are needed for 372 protecting pseudo-wires. It will have the same security properties as 373 in LDP [5] and the PW control protocol [2]. 375 7. IANA Considerations 377 We have defined the following codes for the pseudo-wire redundancy 378 application. 380 7.1. Status Code for PW Preferential Forwarding Status 382 The T-PE nodes need to indicate to each other the preferential 383 forwarding status of active/inactive of the pseudo-wire. 385 0x00000020 When the bit is set it represents "PW forwarding 386 standby". 388 When the bit is cleared, it represents "PW forwarding 389 "active". 391 8. Acknowledgments 393 The authors would like to thank Vach Kompella, Kendall Harvey, 394 Tiberiu Grigoriu, Neil Hart, Kajal Saha, and Philippe Niger for their 395 valuable comments and suggestions. 397 9. References 399 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 400 Levels", BCP 14, RFC 2119, March 1997. 402 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 403 LDP", RFC 4447, April 2006. 405 [3] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3- 406 segmented-pw-02.txt, March 2006. 408 [4] Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge (PWE3) 409 Architecture", March 2005 411 [5] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 412 Thomas, "LDP Specification", RFC 3036, January 2001 414 Author's Addresses 416 Praveen Muley 417 Alcatel 418 701 E. Middlefiled Road 419 Mountain View, CA, USA 420 Email: Praveen.muley@alcatel.com 422 Mustapha Aissaoui 423 Alcatel 424 600 March Rd 425 Kanata, ON, Canada K2K 2E6 426 Email: mustapha.aissaoui@alcatel.com 428 Matthew Bocci 429 Alcatel 430 Voyager Place, Shoppenhangers Rd 431 Maidenhead, Berks, UK SL6 2PJ 432 Email: matthew.bocci@alcatel.co.uk 434 Jonathan Newton 435 Cable & Wireless 436 Email: Jonathan.Newton@cwmsg.cwplc.com 438 Intellectual Property Statement 440 The IETF takes no position regarding the validity or scope of any 441 Intellectual Property Rights or other rights that might be claimed to 442 pertain to the implementation or use of the technology described in 443 this document or the extent to which any license under such rights 444 might or might not be available; nor does it represent that it has 445 made any independent effort to identify any such rights. Information 446 on the procedures with respect to rights in RFC documents can be 447 found in BCP 78 and BCP 79. 449 Copies of IPR disclosures made to the IETF Secretariat and any 450 assurances of licenses to be made available, or the result of an 451 attempt made to obtain a general license or permission for the use of 452 such proprietary rights by implementers or users of this 453 specification can be obtained from the IETF on-line IPR repository at 454 http://www.ietf.org/ipr. 456 The IETF invites any interested party to bring to its attention any 457 copyrights, patents or patent applications, or other proprietary 458 rights that may cover technology that may be required to implement 459 this standard. Please address the information to the IETF at 460 ietf-ipr@ietf.org. 462 Disclaimer of Validity 464 This document and the information contained herein are provided on an 465 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 466 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 467 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 468 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 469 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 470 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 472 Copyright Statement 474 Copyright (C) The Internet Society (2006). 476 This document is subject to the rights, licenses and restrictions 477 contained in BCP 78, and except as set forth therein, the authors 478 retain all their rights. 480 Acknowledgment 482 Funding for the RFC Editor function is currently provided by the 483 Internet Society.