idnits 2.17.1 draft-muley-dutta-pwe3-redundancy-bit-02.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 30. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 742. 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 IETF Trust Copyright Line does not match the current year == Line 600 has weird spacing: '...t or of the '...' -- 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 (November 19, 2007) is 6002 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) == Unused Reference: '3' is defined on line 649, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 652, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (ref. '2') (Obsoleted by RFC 8077) == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-05 ** Downref: Normative reference to an Informational RFC: RFC 3985 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 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: May 2008 Matthew Bocci 4 Pranjal Kumar Dutta 5 Marc Lasserre 6 Alcatel-Lucent 8 Jonathan Newton 9 Cable & Wireless 11 Olen Stokes 12 Extreme Networks 14 Hamid Ould-Brahim 15 Nortel 17 Luca Martini 18 Cisco Systems Inc. 20 November 19, 2007 22 Preferential Forwarding Status bit definition 23 draft-muley-dutta-pwe3-redundancy-bit-02.txt 25 Status of this Memo 27 By submitting this Internet-Draft, each author represents that any 28 applicable patent or other IPR claims of which he or she is aware 29 have been or will be disclosed, and any of which he or she becomes 30 aware will be disclosed, in accordance with Section 6 of BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that other 34 groups may also distribute working documents as Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on May 19, 2008. 49 Abstract 51 This document describes a mechanism for standby status signaling of 52 redundant PWs between their termination points. A set of redundant 53 PWs is configured between PE nodes in SS-PW applications, or between 54 T-PE nodes in MS-PW applications. 56 In order for the PE/T-PE nodes to indicate the preferred PW path to 57 forward to one another, a new status bit is needed to indicate a 58 preferential forwarding status of active or standby for each PW in 59 the redundancy set. 61 In addition, a second status bit is defined to allow peer PE/T-PE 62 nodes to coordinate a switchover operation of the PW/MS-PW path. 64 Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC-2119 [1]. 70 Table of Contents 72 1. Introduction................................................3 73 2. Motivation..................................................4 74 3. Terminology.................................................5 75 4. Modes of Operation..........................................5 76 4.1. Independent Mode:.......................................5 77 4.2. Master/Slave Mode:......................................6 78 5. Signaling procedures of PW State Transition..................7 79 5.1. PW Standby notification procedures in Independent mode...8 80 5.2. PW Standby notification procedures in Master/Slave mode..8 81 5.2.1. PW State Machine...................................9 82 5.3. Coordination of PW Path Switchover.....................11 83 5.3.1. Procedures at the requesting endpoint.............12 84 5.3.2. Procedures at the receiving endpoint..............13 85 6. Applicability and Backward Compatibility....................14 86 7. Security Considerations.....................................14 87 8. IANA Considerations........................................14 88 8.1. Status Code for PW Preferential Forwarding Status.......14 89 8.2. Status Code for PW Request Switchover Status...........15 90 9. Acknowledgments............................................15 91 10. References................................................15 92 Author's Addresses............................................15 93 Full Copyright Statement.......................................16 94 Intellectual Property Statement................................17 95 Acknowledgment................................................17 97 1. Introduction 99 In single-segment PW (SS-PW) services such as VPWS and VPLS, 100 protection for the PW is provided by the PSN layer. This may be an 101 RSVP LSP with a FRR backup and/or an end-to-end backup LSP. There are 102 however applications where PSN protection is insufficient to fully 103 protect the PWE3 service and pseudowire redundancy is required. These 104 scenarios are described in [5]. 106 In a VPWS service, this is used to provide access AC redundancy to a 107 CE device which is dual-homed to target PE nodes. In a HVPLS service, 108 this is used to provide access PW redundancy to the MTU device which 109 is dual-homed to two PE-r devices. PSN protection mechanisms cannot 110 protect against failure of the target PE node or the failure of the 111 remote AC. These scenarios rely on a set of two or more pseudowires 112 to protect a given PWE3 service. Only one of these pseudowires is 113 used by the PEs to forward user traffic on at any given time. This is 114 the active PW. The other PWs in the set are considered standby and 115 are not used for forwarding unless they become active. 117 In order to support access AC or access PW redundancy, at least one 118 of the PEs on which a PW terminates must be different from that on 119 which the primary PW terminates, as described in [5]. Figure 1 120 illustrates an application of Active and Standby PWs. 122 |<-------------- Emulated Service ---------------->| 123 | | 124 | |<------- Pseudo Wire ------>| | 125 | | | | 126 | | |<-- PSN Tunnels-->| | | 127 | V V V V | 128 V AC +----+ +----+ AC V 129 +-----+ | | PE1|==================| | | +-----+ 130 | |----------|....|...PW1.(active)...|....|----------| | 131 | | | |==================| | | CE2 | 132 | CE1 | +----+ |PE2 | | | 133 | | +----+ | | +-----+ 134 | | | |==================| | 135 | |----------|....|...PW2.(standby)..| | 136 +-----+ | | PE3|==================| | 137 AC +----+ +----+ 139 Figure 1: Reference Model for PW Redundancy 141 In multi-segment PW (MS-PW) applications, multiple MS-PWs are 142 configured between a pair of T-PE nodes. The paths of these MS-PWs 143 are diverse and are switched at different S-PE nodes. Only one of 144 these MS-PWs is active at any given time. The others are put in 145 standby. In these applications, PW redundancy is important to provide 146 resilience in the event of failure of S-PE node since PSN protection 147 mechanisms cannot. 149 This document specifies a new PW status bit to indicate the 150 preferential forwarding status of the PW for the purpose of notifying 151 the remote PE of the active/standby state of each PW in the 152 redundancy set. This status bit is different from the operational 153 status bits already defined in the PWE3 control protocol [2]. In 154 addition, a second status bit is defined to allow peer PE/T-PE nodes 155 to coordinate a switchover operation of the PW/MS-PW path. 157 2. Motivation 159 The PWE3 control protocol [2] defines the following status codes to 160 indicate the operational state for an AC and a PW: 162 0x00000000 - Pseudowire forwarding (clear all failures) 164 0x00000001 - Pseudowire Not Forwarding 166 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 168 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 170 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 172 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 174 The scenarios defined in [5] allow the provisioning of a primary PW 175 and one or many secondary PWs in the same VPWS or VPLS service. 177 A PE node makes a selection of which PW to activate at any given time 178 for the purpose of forwarding user packets. This selection takes into 179 account the local operational state of the PW as well as the remote 180 operational state of the PW as indicated in the status bits of the PW 181 it received from the peer PE node. 183 In the absence of faults, all PWs are operationally UP both locally 184 and remotely and a PE node needs to select a single PW to forward 185 user packets to. This is referred to as the active PW. All other PWs 186 will be in standby and must not be used to forward user packets. 188 In order for both ends of the service to select the same PW for 189 forwarding user packets, it is proposed that a PE node communicates a 190 new status bit to indicate the forwarding state of a PW to its peer 191 PE node. 193 In addition, a second status bit is defined to allow peer PE/T-PE 194 nodes to coordinate a switchover operation of the PW/MS-PW path if 195 required by the application.. 197 3. Terminology 199 UP PW: A PW which has been configured (label mapping exchanged 200 between PEs) and is not in any of the PW defect states 201 specified in [2]. Such a PW is available for forwarding 202 traffic. 204 DOWN PW: A PW that has either not been fully configured or has been 205 and is in any of the PW defect states specified in [2]. 206 Such a PW is not available for forwarding traffic. 208 Active PW: An UP PW used for forwarding user traffic. 210 Standby PW: An UP PW that is not used for forwarding user traffic. 212 PW Endpoint: A PE where a PW terminates on an NSP e.g. A SS-PW PE, an 213 MS-PW T-PE, or a VPLS MTU or PE-r. 215 4. Modes of Operation 217 There are two modes of operation for the use of the PW preferential 218 forwarding status bits: 220 o Independent mode 222 o Master/Slave mode. 224 4.1. Independent Mode: 226 PW endpoint nodes independently select which PW they intend to make 227 active and which PWs they intend to make standby. They advertise the 228 corresponding Active/Standby forwarding state for each PW. Each PW 229 endpoint compares local and remote status and uses the PW that is 230 operationally UP at both endpoints and that shows Active states at 231 both the local and remote endpoint. 233 In steady state, a PE will always find an Active PW. However, it is 234 possible that due to a misconfiguration, such a PW is not found. The 235 behavior of a PE in this case is outside the scope of this document. 237 There may also be transient conditions where endpoints do not share a 238 common view of the active/standby state of the PWs. This could be 239 caused by propagation delay of the T-LDP status messages between 240 endpoints. In this case, the behavior of the receiving endpoint is 241 outside the scope of this document. 243 Thus, in this mode of operation, the following definition of Active 244 and Standby PW states apply: 246 o Active State 248 A PW is considered to be in Active state when the PW labels are 249 exchanged between its two endpoints in control plane, and the status 250 bits exchanged between the endpoints indicate the PW is UP and Active 251 at both endpoints. In this state user traffic can flow over the PW in 252 both directions. 254 o Standby State 256 A PW is considered to be in Standby state when the PW labels are 257 exchanged between its two endpoints in the control plane, but the 258 status bits exchanged indicate the PW is in Standby state at one or 259 both endpoints. In this state the endpoints MUST NOT forward data 260 traffic over the PW but MAY allow PW OAM packets, e.g., VCCV, to be 261 sent and received in order to test the liveliness of standby PWs. 263 4.2. Master/Slave Mode: 265 One endpoint node of the redundant set of PWs is designated the 266 Master and is responsible for selecting which PW both endpoints must 267 use to forward user traffic. 269 The Master indicates the forwarding state in the Active/Standby 270 status bit. The other endpoint node, the Slave, MUST follow the 271 decision of the Master node based on the received status bits. 273 One endpoint of the PW, the Master, actively selects which PW to 274 activate and uses it for forwarding user traffic. This status is 275 indicated to the Slave node by setting the preferential forwarding 276 status bit in the status bit TLV to Active. It does forward user 277 traffic to any other of the PW's in the redundant set to the slave 278 node and indicates this by setting the preferential forwarding status 279 bit in the status bit TLV to Standby for those PWs. The master node 280 MUST ignore any Active/Standby status bits received from the Slave 281 nodes. 283 The Slave endpoint(s) are required to act on the status bits received 284 from the Master. When the received status bit transitions from Active 285 to Standby, a Slave node MUST stop forwarding over the previously 286 active PW. When the received status bit transitions from Standby to 287 Active for a given PW, the Slave node MUST start forwarding user 288 traffic over this PW. 290 There is a single PE/T-PE Master PW endpoint node and one or many 291 PE/T-PE PW endpoint Slave nodes. The assignment of Master/Slave roles 292 to the PW endpoints is performed by local configuration. 294 In this mode of operation, the following definition of Active and 295 Standby PW states apply: 297 o Active State 299 A PW is considered to be in Active state when the PW labels are 300 exchanged between its two endpoints in control plane, and the status 301 bits exchanged between the endpoints indicate the PW is UP at both 302 endpoints, and the forwarding status sent by the Master endpoint 303 indicates Active state. In this state user traffic can flow over the 304 PW in both directions. 306 o Standby State 308 A PW is considered to be in Standby state when the PW labels are 309 exchanged between its two endpoints in the control plane, but the 310 status bits sent by the Master endpoint indicate the PW is in Standby 311 state. In this state the endpoints MUST NOT forward data traffic over 312 the PW but MAY allow PW OAM packets, e.g., VCCV, to be sent and 313 received. 315 5. Signaling procedures of PW State Transition 317 This section describes the extensions proposed and the processing 318 rules for the extensions. It defines a new "PW preferential 319 forwarding" bit in Status Code that is to be used with PW Status TLV 320 proposed in RFC 4447 [2]. The PW preferential forwarding bit when set 321 is used to signal Standby state of PW by one terminating point to the 322 other end. 324 5.1. PW Standby notification procedures in Independent mode 326 PW endpoint nodes independently select which PW they intend to use 327 for forwarding, and which PWs they do not, based on the specific 328 application. They advertise the corresponding Active/Standby 329 forwarding state for each PW. This advertisement occurs in both the 330 initial label mapping message and in a subsequent notification 331 message when the forwarding state transitions as a result of a state 332 change in the specific application. 334 Each endpoint compares the updated local and remote status and 335 effectively activates the PW which is operationally UP at both 336 endpoints and which shows both local Active and remote Active states. 338 When a PW is in active state, the endpoints can forward both user 339 packets and OAM packets. 341 When a PW is in standby state, the endpoints MUST NOT forward user 342 packets over the PW but MAY forward PW OAM packets. 344 For MS-PWs, S-PEs MUST relay the PW status notification containing 345 both the operational and preferential forwarding status bits between 346 ingress and egress PWs. 348 5.2. PW Standby notification procedures in Master/Slave mode 350 Whenever the Master PW endpoint "actively" selects or deselects a PW 351 for forwarding user traffic at its end, it explicitly notifies the 352 event to the remote Slave endpoint. The slave endpoint carries out 353 the corresponding action on receiving the PW state change 354 notification. 356 If the PW preferential forwarding bit in PW Status TLV received by 357 the slave is set, it indicates that the PW at the Master end is not 358 used for forwarding and is thus kept in the Standby state, the PW 359 MUST also not be used for forwarding at Slave endpoint. Clearance of 360 the PW Preferential Forwarding bit in PW Status TLV indicates that 361 the PW at the Master endpoint is used for forwarding and is in Active 362 state, and the receiving Slave endpoint MUST activate the PW if it 363 was previously not used for forwarding. 365 This mechanism is RECOMMENDED to be used with PWs signaled in groups 366 with common group-id in PWid FEC Element or Grouping TLV in 367 Generalized PWid FEC Element defined in [2]. When PWs are provisioned 368 with such grouping a termination point sends a single "wildcard" 369 Notification message using a PW FEC TLV with only the group ID set, 370 to denote this change in status for all affected PW connections. This 371 status message contains either the PW FEC TLV with only the Group ID 372 set, or else it contains the PW Generalized FEC TLV with only the PW 373 Grouping ID TLV. As mentioned in [2], the Group ID field of the PWid 374 FEC Element, or the PW Grouping TLV used with the Generalized ID FEC 375 Element, can be used to send status notification for all arbitrary 376 set of PWs. For example, Group-ID in PWiD may be used to send 377 wildcard status notification message for a group of PWs when PWid FEC 378 element is used for PW state signaling. When Generalized PWiD FEC 379 Element defined is used in PW state signaling, PW Grouping TLV may be 380 used for wildcard status notification for a group of PWs. 382 For MS-PWs, S-PEs MUST relay the PW status notification containing 383 both the operational and preferential forwarding status bits between 384 ingress and egress PW segments. 386 5.2.1. PW State Machine 388 It is convenient to describe the PW state change behavior in terms of 389 a state machine. The PW state machine is explained in detail in the 390 two defined states and the behavior is presented as a state 391 transition table. The same state machine is seamlessly applicable to 392 PW Groups. 394 PW State Transition State Table 396 STATE EVENT NEW STATE 398 ACTIVE PW put in Standby (master) STANDBY 400 Action: Transmit PW preferential forwarding bit set 402 Receive PW preferential forwarding STANDBY 404 bit set 406 Action: Stop forwarding over PW 407 Receive PW preferential forwarding ACTIVE 409 bit set but bit not supported 411 Action: None 413 Receive PW preferential forwarding ACTIVE 415 bit clear 417 Action: None. 419 STANDBY PW activated (master) ACTIVE 421 Action: Transmit PW preferential forwarding bit 422 clear 424 Receive PW preferential forwarding ACTIVE 426 bit clear 428 Action: Activate PW 430 Receive PW preferential forwarding STANDBY 432 bit clear but bit not supported 434 Action: None 436 Receive PW preferential forwarding STANDBY 438 bit set 440 Action: No action 442 5.3. Coordination of PW Path Switchover 444 There are PW redundancy applications which require that PE/T-PE nodes 445 coordinate the switchover to a PW/MS-PW path such that both endpoints 446 will be forwarding over the same path at any given time. One such 447 application of redundant MS-PW paths is identified in [5]. Multiple 448 MS-PWs are configured between a pair of T-PE nodes. The paths of 449 these MS-PWs are diverse and are switched at different S-PE nodes. 450 Only one of these MS-PWs is active at any given time. The others are 451 put in standby. The endpoints follow the Independent Mode procedures 452 to activate the PW which is UP and advertised Active 'preferential 453 forwarding' status bit by both endpoints. 455 The trigger for sending a request to switchover of the path of the 456 MS-PW by one endpoint can be due to an operational event, example a 457 failure, which caused the endpoints to not be able to match the 458 Active 'preferential forwarding' status bit. The other trigger is the 459 execution of an administrative maintenance operation by the network 460 operator in order to move the traffic away from the node/links to be 461 serviced. 463 Unlike the case of a Master/Slave mode of operation, the endpoint 464 requesting the switchover requires explicit acknowledgement from the 465 peer endpoint that the request is honored before it switches the path 466 of the PW. Furthermore, any of the endpoints can make the request to 467 switchover. 469 A new status bit is proposed to have a PE/T-PE node request the 470 switchover to its peer. This bit will be referred to as 'request PW 471 switchover' status bit. The 'preferential forwarding' status bit 472 continues to be used by each endpoint to indicate its current local 473 settings of the active/standby state of each PW in the redundancy 474 set. In other words, like in the Independent mode, it indicates to 475 the far-end which of the PWs is being used to forward packets and 476 which is being put in standby. It can thus be used as a way for the 477 far-end to acknowledge the requested switchover operation. 479 The following procedures must be followed by both endpoints of a 480 PW/MS-PW to coordinate the switchover of the PW/MS-PW path. These 481 procedures are enabled only when the user configured the use of the 482 'request switchover' status bit at both endpoints. 484 S-PEs nodes MUST relay the PW status notification containing the 485 operational status bits, as well as the 'preferential forwarding' and 486 'request switchover' status bits between ingress and egress PW 487 segments. 489 5.3.1. Procedures at the requesting endpoint 491 a. The requesting endpoint sends a LDP status notification message 492 with the 'request switchover' bit set on the PW it desires to 493 switch to. 495 b. The endpoint does not activate forwarding on that PW/MS-PW at 496 this point in time. It may however enable receiving on that 497 PW/MS-PW. Thus the 'preferential forwarding' status bit still 498 reflects the currently used PW path. 500 c. The requesting endpoint starts a timer while waiting the remote 501 endpoint to acknowledge the request. 503 d. If while waiting for the acknowledgment, the requesting endpoint 504 receives a request from its peer to switchover to the same or a 505 different PW path, it must perform the following: 507 i. If its system IP address is higher than that of the peer, 508 this endpoint ignores the request and continues to wait 509 for the acknowledgement from its peer. 511 ii. If its system IP address is lower than that of its peer, 512 it aborts the timer and immediately starts the 513 procedures of the receiving endpoint in Section 5.3.2. 515 e. If while waiting for the acknowledgment, the requesting endpoint 516 receives a status notification message from its peer with the 517 'preferential forwarding' status bit set in the requested PW, it 518 must treat this as an explicit acknowledgment of the request and 519 must perform the following: 521 i. Abort the timer. 523 ii. Activate the PW path. 525 iii. Send an update status notification message with the 526 'preferential forwarding' status bit set to the newly 527 active PW and the 'request switchover' bit reset in all 528 PWs in the redundancy set. 530 f. If while waiting for the acknowledgment, the requesting endpoint 531 detects that the requested PW went into operational Down state 532 locally, and could use an alternate PW which is operationally UP, 533 it must perform the following: 535 i. Abort the timer. 537 ii. Issue a new request to switchover to the alternate PW. 539 iii. Re-start the timer. 541 g. If while waiting for the acknowledgment, the requesting endpoint 542 detects that the requested PW went into operational Down state 543 locally, and could not use an alternate PW which is operationally 544 UP, it must perform the following: 546 i. Abort the timer. 548 ii. Send an update status notification message with the 549 'preferential forwarding' status bit unchanged and the 550 'request switchover' bit reset in all PWs in the 551 redundancy set. 553 h. If while waiting for the acknowledgment, the timer expired, the 554 requesting endpoint assumes the request is rejected and will 555 either issue a new request or do nothing. 557 i. If the requesting node receives the acknowledgment after the 558 request expired, it will treat it as if the remote endpoint 559 unilaterally switched the path of the PW without issuing a 560 request. In that case, it may issue a new request and follow the 561 requesting endpoint procedures to synchronize transmit and 562 receive paths of the PW. 564 5.3.2. Procedures at the receiving endpoint 566 a. Upon receiving a status notification message with the 'request 567 switchover' bit set on a PW different from the currently active 568 one, and the requested PW is operationally UP, the receiving 569 endpoint must perform the following: 571 i. Activate the PW. 573 ii. Send an update status notification message with the 574 'preferential forwarding' status bit set to the newly 575 active PW and the 'request switchover' bit reset in all 576 PWs in the redundancy set. 578 b. Upon receiving a status notification message with the 'request 579 switchover' bit set on a PW different from the currently active 580 one, and the requested PW is operationally Down, the receiving 581 endpoint must perform the following: 583 i. Ignore the request and do nothing. 585 6. Applicability and Backward Compatibility 587 The mechanism defined in this document is OPTIONAL and is applicable 588 to PWE3 applications where standby state signaling of PW or PW group 589 is required. 591 A PE implementation that uses the mechanisms described in this 592 document MUST negotiate the use of PW status TLV between its T-LDP 593 peers as per RFC 4447 [2]. If PW Status TLV is found to be not 594 supported by either of its endpoint after status negotiation 595 procedures, then the mechanisms specified in this document cannot be 596 used. 598 A PE implementation compliant to RFC 4447 [2], and which does not 599 support the generation or processing of the 'preferential forwarding' 600 status bit or of the 'request switchover'status bit, will not set 601 these bits in the status bits transmitted to a peer PE and will not 602 examine them in the received status bits from a peer PE. The 603 mechanisms specified in this document cannot be used. 605 7. Security Considerations 607 This document uses the LDP extensions that are needed for protecting 608 pseudo-wires. It will have the same security properties as in the 609 PWE3 control protocol [2]. 611 8. IANA Considerations 613 We have defined the following codes for the pseudo-wire redundancy 614 application. 616 8.1. Status Code for PW Preferential Forwarding Status 618 0x00000020 When the bit is set, it indicates "PW forwarding 620 standby". 622 When the bit is cleared, it indicates "PW forwarding 624 active". 626 8.2. Status Code for PW Request Switchover Status 628 0x00000040 When the bit is set, it represents "Request switchover to 629 this PW". 631 When the bit is cleared, it represents no specific 632 action. 634 9. Acknowledgments 636 The authors would like to thank Vach Kompella, Kendall Harvey, 637 Tiberiu Grigoriu, John Rigby, Prashanth Ishwar, Neil Hart, Kajal 638 Saha, Florin Balus and Philippe Niger for their valuable comments and 639 suggestions. 641 10. References 643 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 644 Levels", BCP 14, RFC 2119, March 1997. 646 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 647 LDP", RFC 4447, April 2006. 649 [3] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3- 650 segmented-pw-05.txt, July 2007. 652 [4] Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge (PWE3) 653 Architecture", RFC 3985, March 2005 655 [5] Praveen, Pranjal et al., "draft-muley-pwe3-redundancy-01.txt", 656 March 2007. 658 Author's Addresses 660 Praveen Muley 661 Alcatel-lucent 662 701 E. Middlefiled Road 663 Mountain View, CA, USA 664 Email: Praveen.muley@alcatel-lucent.com 665 Mustapha Aissaoui 666 Alcatel-lucent 667 600 March Rd 668 Kanata, ON, Canada K2K 2E6 669 Email: mustapha.aissaoui@alcatel-lucent.com 671 Matthew Bocci 672 Alcatel-Lucent 673 Voyager Place, Shoppenhangers Rd 674 Maidenhead, Berks, UK SL6 2PJ 675 Email: matthew.bocci@alcatel-lucent.co.uk 677 Pranjal Kumar Dutta 678 Alcatel-Lucent 679 Email: pdutta@alcatel-lucent.com 681 Marc Lasserre 682 Alcatel-Lucent 683 Email: mlasserre@alcatel-lucent.com 685 Jonathan Newton 686 Cable & Wireless 687 Email: Jonathan.Newton@cw.com 689 Olen Stokes 690 Extreme Networks 691 Email: ostokes@extremenetworks.com 693 Hamid Ould-Brahim 694 Nortel 695 Email: hbrahim@nortel.com 697 Luca Martini 698 Cisco Systems, Inc. 699 9155 East Nichols Avenue, Suite 400 700 Englewood, CO, 80112 701 Email: lmartini@cisco.com 703 Full Copyright Statement 705 Copyright (C) The IETF Trust (2007). 707 This document is subject to the rights, licenses and restrictions 708 contained in BCP 78, and except as set forth therein, the authors 709 retain all their rights. 711 This document and the information contained herein are provided on 712 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 713 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 714 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 715 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 716 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 717 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 718 FOR A PARTICULAR PURPOSE. 720 Intellectual Property Statement 722 The IETF takes no position regarding the validity or scope of any 723 Intellectual Property Rights or other rights that might be claimed to 724 pertain to the implementation or use of the technology described in 725 this document or the extent to which any license under such rights 726 might or might not be available; nor does it represent that it has 727 made any independent effort to identify any such rights. Information 728 on the procedures with respect to rights in RFC documents can be 729 found in BCP 78 and BCP 79. 731 Copies of IPR disclosures made to the IETF Secretariat and any 732 assurances of licenses to be made available, or the result of an 733 attempt made to obtain a general license or permission for the use of 734 such proprietary rights by implementers or users of this 735 specification can be obtained from the IETF on-line IPR repository at 736 http://www.ietf.org/ipr. 738 The IETF invites any interested party to bring to its attention any 739 copyrights, patents or patent applications, or other proprietary 740 rights that may cover technology that may be required to implement 741 this standard. Please address the information to the IETF at 742 ietf-ipr@ietf.org. 744 Acknowledgment 746 Funding for the RFC Editor function is currently provided by the 747 Internet Society.