idnits 2.17.1 draft-ietf-pwe3-redundancy-bit-01.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 34. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1223. 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 Copyright Line does not match the current year == Line 655 has weird spacing: '... of the reque...' == Line 739 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 (September 30, 2008) is 5680 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 789, 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-09 == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 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 Intended Status: Standards Track Matthew Bocci 4 Expires: March 2009 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 Giles Heron 21 Thomas Nadeau 22 BT 24 September 30, 2008 26 Preferential Forwarding Status bit definition 27 draft-ietf-pwe3-redundancy-bit-01.txt 29 Status of this Memo 31 By submitting this Internet-Draft, each author represents that any 32 applicable patent or other IPR claims of which he or she is aware 33 have been or will be disclosed, and any of which he or she becomes 34 aware will be disclosed, in accordance with Section 6 of BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that other 38 groups may also distribute working documents as Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on March 30, 2009. 52 Abstract 54 This document describes a mechanism for standby status signaling of 55 redundant PWs between their termination points. A set of redundant 56 PWs is configured between PE nodes in SS-PW applications, or between 57 T-PE nodes in MS-PW applications. 59 In order for the PE/T-PE nodes to indicate the preferred PW path to 60 forward to one another, a new status bit is needed to indicate a 61 preferential forwarding status of active or standby for each PW in 62 the redundancy set. 64 In addition, a second status bit is defined to allow peer PE/T-PE 65 nodes to coordinate a switchover operation of the PW/MS-PW path. 67 Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC-2119 [1]. 73 Table of Contents 75 1. Introduction...................................................3 76 2. Motivation and Scope...........................................4 77 3. Terminology....................................................7 78 4. Modes of Operation.............................................7 79 4.1. Independent Mode:.........................................8 80 4.2. Master/Slave Mode:........................................9 81 5. Signaling procedures of PW State Transition...................10 82 5.1. PW Standby notification procedures in Independent mode...10 83 5.2. PW Standby notification procedures in Master/Slave mode..11 84 5.2.1. PW State Machine....................................12 85 5.3. Coordination of PW Path Switchover.......................14 86 5.3.1. Procedures at the requesting endpoint...............15 87 5.3.2. Procedures at the receiving endpoint................16 88 6. Applicability and Backward Compatibility......................17 89 7. Security Considerations.......................................17 90 8. IANA Considerations...........................................17 91 8.1. Status Code for PW Preferential Forwarding Status........17 92 8.2. Status Code for PW Request Switchover Status.............18 93 9. Acknowledgments...............................................18 94 10. References...................................................18 95 10.1. Normative References....................................18 96 10.2. Informative References..................................18 97 11. Appendix A - Applications of PW Redundancy Procedures........19 98 11.1. One Multi-homed CE with single SS-PW redundancy.........19 99 11.2. Multiple Multi-homed CEs with single SS-PW redundancy...21 100 11.3. Multi-homed CE with MS-PW redundancy....................22 101 11.4. Single Homed CE with MS-PW redundancy...................24 102 11.5. PW redundancy between H-VPLS MTU-s and PE-rs............25 103 Author's Addresses...............................................27 104 Full Copyright Statement.........................................28 105 Intellectual Property Statement..................................28 106 Acknowledgment...................................................29 108 1. Introduction 110 In single-segment PW (SS-PW) services such as VPWS and VPLS, 111 protection for the PW is provided by the PSN layer. This may be an 112 RSVP-TE LSP with a FRR backup and/or an end-to-end backup LSP. There 113 are however applications where PSN protection is insufficient to 114 fully protect the PWE3 service and pseudowire redundancy is required. 115 These scenarios are described in the PW redundancy and framework 116 document [5]. 118 In a VPWS service, this is used to provide access AC redundancy to a 119 CE device which is dual-homed to target PE nodes. In a HVPLS service, 120 this is used to provide access PW redundancy to the MTU device which 121 is dual-homed to two PE-r devices. PSN protection mechanisms cannot 122 protect against failure of the target PE node or the failure of the 123 remote AC. These scenarios rely on a set of two or more pseudowires 124 to protect a given PWE3 service. Only one of these pseudowires is 125 used by the PEs to forward user traffic on at any given time. This is 126 the active PW. The other PWs in the set are considered standby and 127 are not used for forwarding unless they become active. In essence, 128 this provides a 1:1 or N:1 PW protection with the possibility of 129 multi-homing. 131 In order to support access AC or access PW redundancy, at least one 132 of the PEs on which a PW terminates must be different from that on 133 which the primary PW terminates, as described in [5]. Figure 1 134 illustrates an application of Active and Standby PWs. 136 |<-------------- Emulated Service ---------------->| 137 | | 138 | |<------- Pseudo Wire ------>| | 139 | | | | 140 | | |<-- PSN Tunnels-->| | | 141 | V V V V | 142 V AC +----+ +----+ AC V 143 +-----+ | | PE1|==================| | | +-----+ 144 | |----------|....|...PW1.(active)...|....|----------| | 145 | | | |==================| | | CE2 | 146 | CE1 | +----+ |PE2 | | | 147 | | +----+ | | +-----+ 148 | | | |==================| | 149 | |----------|....|...PW2.(standby)..| | 150 +-----+ | | PE3|==================| | 151 AC +----+ +----+ 153 Figure 1: Reference Model for PW Redundancy 155 In multi-segment PW (MS-PW) applications, multiple MS-PWs are 156 configured between a pair of T-PE nodes. The paths of these MS-PWs 157 are diverse and are switched at different S-PE nodes. Only one of 158 these MS-PWs is active at any given time. The others are put in 159 standby. In these applications, 1:1 or N:1 PW redundancy is important 160 to provide resilience in the event of failure of S-PE node since PSN 161 protection mechanisms cannot, and the desire is that MS-PW based 162 services have resiliency similar to that of SS-PW based services. 164 This document specifies a new PW status bit to indicate the 165 preferential forwarding status of the PW for the purpose of notifying 166 the remote PE of the active/standby state of each PW in the 167 redundancy set. This status bit is different from the operational 168 status bits already defined in the PWE3 control protocol [2]. In 169 addition, a second status bit is defined to allow peer PE/T-PE nodes 170 to coordinate a switchover operation of the PW/MS-PW path. 172 2. Motivation and Scope 174 The PWE3 control protocol [2] defines the following status codes in 175 PW the status TLV to indicate the operational state for an AC and a 176 PW: 178 0x00000000 - Pseudowire forwarding (clear all failures) 180 0x00000001 - Pseudowire Not Forwarding 181 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 183 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 185 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 187 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 189 The scenarios defined in [5] allow the provisioning of a primary PW 190 and one or many secondary PWs in the same VPWS or VPLS service. 192 A PE node makes a selection of which PW to activate at any given time 193 for the purpose of forwarding user packets. This selection takes into 194 account the local operational state of the PW as well as the remote 195 operational state of the PW as indicated in the status bits of the PW 196 it received from the peer PE node. 198 In the absence of faults, all PWs are operationally UP both locally 199 and remotely and a PE node needs to select a single PW to forward 200 user packets to. This is referred to as the active PW. All other PWs 201 will be in standby and must not be used to forward user packets. 203 In order for both ends of the service to select the same PW for 204 forwarding user packets, it is proposed that a PE node communicates a 205 new status bit to indicate the forwarding state of a PW to its peer 206 PE node. 208 In addition, a second status bit is defined to allow peer PE/T-PE 209 nodes to coordinate a switchover operation of the PW/MS-PW path if 210 required by the application. 212 Together, the mechanisms described in this document achieve the 213 following PW protection capabilities: 215 a. A mandatory 1:1 PW protection with a single active PW and one 216 standby PW. An active PW can forward data traffic and control 217 plane traffic, such as OAM packets. A standby PW does not 218 carry data traffic. 220 b. An optional N:1 PW protection scheme with a single active PW 221 and N standby PWs. 223 c. An independent mode of operation in which each PW endpoint 224 node uses its own local rule to select which PW it intends to 225 activate at any given time and advertises it to the remote 226 endpoints. Only a PW which is operationally UP and which 227 indicated Active status bit locally and remotely is in the 228 Active state and can be used to forward data packets. This is 229 described in Section 4.1. . 231 d. An optional mechanism to allow PW endpoints to coordinate the 232 switchover to a given PW path by using an explicit 233 request/acknowledgment switchover procedure. This mechanism is 234 complementary to the Independent mode of operation and is 235 described in Section 5.3. . This mechanism can be invoked 236 manually by the user, effectively providing a manual 237 switchover capability. It can also be invoked automatically to 238 resolve a situation where the PW endpoints could not match the 239 two directions of the PW. 241 e. A Master/Slave mode in which one PW endpoint, the Master 242 endpoint, selects and dictates to the other endpoint(s), the 243 Slave endpoint(s), which PW to activate. This is described in 244 Section 4.2. . 246 f. Multi-homing of a CE device to two or more PE/T-PE nodes. 248 g. Multi-homing of a PE/T-PE node to two or more PE/T-PE nodes. 250 h. Optionally, implementations can add support for precedence 251 parameter to govern the selection of a PW when more than one 252 PW qualify for the active state, as defined in sections 4.1. 253 and 4.2. The PW with the lowest precedence value has the 254 highest priority. This is a local configuration parameter to 255 the PW endpoint. 257 i. Optionally, implementations can designate by configuration one 258 PW in the 1:1 or N:1 set as a primary PW and the remaining as 259 secondary PWs. If more than one PW qualify for the active 260 state, as defined in sections 4.1. and 4.2. , a PE/T-PE node 261 selects the primary PW in preference to a secondary PW. In 262 other words, the primary PW has implicitly the lowest 263 precedence value. Furthermore, implementations can provide the 264 option to revert to the primary PW immediately after it comes 265 back up or after the expiration of a delay. The PE/T-PE node 266 can use the PW precedence parameter to select a secondary PW 267 among many that qualify for active state. 269 Appendix A shows how the mechanisms described in this document are 270 used to achieve the desired protection behavior for the scenarios 271 described in the PW redundancy and framework document [5]. 273 3. Terminology 275 UP PW: A PW which has been configured (label mapping exchanged 276 between PEs) and is not in any of the PW defect states 277 specified in [2]. Such a PW is available for forwarding 278 traffic. 280 DOWN PW: A PW that has either not been fully configured or has been 281 and is in any of the PW defect states specified in [2]. 282 Such a PW is not available for forwarding traffic. 284 Active PW: An UP PW used for forwarding user and OAM traffic. 286 Standby PW: An UP PW that is not used for forwarding user traffic, 287 but may forward OAM traffic. 289 Primary PW: the PW which a PW endpoint activates in preference to any 290 other PW when more than one PW qualify for active state. 291 When the primary PW comes back up after a failure and 292 qualifies for active state, the PW endpoint always reverts 293 to it. The designation of Primary is performed by local 294 configuration at the PW endpoint. 296 Secondary PW: when it qualifies for active state, a Secondary PW is 297 only selected if no Primary PW is configured or if the 298 configured primary PW does not qualify for active state 299 (e.g., is operationally Down). By default, a PW in a 300 redundancy PW set is considered secondary. There is no 301 Revertive mechanism among secondary PWs. 303 PW Precedence: this is a configuration parameter that dictates the 304 order in which a PW endpoint activates a PW among multiple 305 PWs which qualify for active state. The lowest the 306 precedence value, the highest is the priority of selecting 307 the PW. 309 PW Endpoint: A PE where a PW terminates on an NSP e.g. A SS-PW PE, an 310 MS-PW T-PE, or a VPLS MTU or PE-r. 312 4. Modes of Operation 314 There are two modes of operation for the use of the PW preferential 315 forwarding status bits: 317 o Independent mode 319 o Master/Slave mode. 321 4.1. Independent Mode: 323 PW endpoint nodes independently select which PW they intend to make 324 active and which PWs they intend to make standby. They advertise the 325 corresponding Active/Standby forwarding state for each PW. Each PW 326 endpoint compares local and remote status and uses the PW that is 327 operationally UP at both endpoints and that shows Active states at 328 both the local and remote endpoint. 330 If more than one PW qualify for the Active state, and the PW endpoint 331 implements the precedence parameter, it must use the PW with the 332 lowest precedence value. The precedence parameter is optional. 334 If more than one PW qualify for the Active state, and the PW endpoint 335 implements the primary/secondary procedures, it must use the primary 336 PW in preference to all secondary PWs. If a primary PW is not 337 available, it must use the secondary PW with the lowest precedence 338 value. If the primary PW becomes available, a PW endpoint may revert 339 to it immediately or after the expiration of a configurable delay. 340 These primary/secondary procedures are optional. 342 In steady state with consistent configuration, a PE will always find 343 an Active PW. However, it is possible that due to a misconfiguration, 344 such a PW is not found. In the event that an active PW is not found, 345 a management indication should be generated. If a management 346 indication for failure to find an active PW was generated and an 347 active PW is subsequently found, a management indication should be 348 generated, effectively clearing the previous failure indication. 349 Additionally, a PE may use the optional request switchover procedures 350 described in Section 5.3. to have both PE nodes switch to a common 351 PW path. 353 There may also be transient conditions where endpoints do not share a 354 common view of the active/standby state of the PWs. This could be 355 caused by propagation delay of the T-LDP status messages between 356 endpoints. In this case, the behavior of the receiving endpoint is 357 outside the scope of this document. 359 Thus, in this mode of operation, the following definition of Active 360 and Standby PW states apply: 362 o Active State 364 A PW is considered to be in Active state when the PW labels are 365 exchanged between its two endpoints in control plane, and the status 366 bits exchanged between the endpoints indicate the PW is UP and Active 367 at both endpoints. In this state user traffic can flow over the PW in 368 both directions. 370 o Standby State 372 A PW is considered to be in Standby state when the PW labels are 373 exchanged between its two endpoints in the control plane, but the 374 status bits exchanged indicate the PW is in Standby state at one or 375 both endpoints. In this state the endpoints MUST NOT forward data 376 traffic over the PW but MAY allow PW OAM packets, e.g., VCCV, to be 377 sent and received in order to test the liveliness of standby PWs. If 378 the PW is a spoke in H-VPLS, any MAC addresses learned via the PW 379 should be flushed when it transitions to Standby state. 381 4.2. Master/Slave Mode: 383 One endpoint node of the redundant set of PWs is designated the 384 Master and is responsible for selecting which PW both endpoints must 385 use to forward user traffic. 387 The Master indicates the forwarding state in the Active/Standby 388 status bit. The other endpoint node, the Slave, MUST follow the 389 decision of the Master node based on the received status bits. 391 One endpoint of the PW, the Master, actively selects which PW to 392 activate and uses it for forwarding user traffic. This status is 393 indicated to the Slave node by setting the preferential forwarding 394 status bit in the status bit TLV to Active. It does not forward user 395 traffic to any other of the PW's in the redundancy set to the slave 396 node and indicates this by setting the preferential forwarding status 397 bit in the status bit TLV to Standby for those PWs. The master node 398 MUST ignore any Active/Standby status bits received from the Slave 399 nodes. 401 If more than one PW qualify for the Active state, and the PW endpoint 402 implements the precedence parameter, it must use the PW with the 403 lowest precedence value. The precedence parameter is optional. 405 If more than one PW qualify for the Active state, and the PW endpoint 406 implements the primary/secondary procedures, it must use the primary 407 PW in preference to all secondary PWs. If a primary PW is not 408 available, it must use the secondary PW with the lowest precedence 409 value. If the primary PW becomes available, a PW endpoint may revert 410 to it immediately or after the expiration of a configurable delay. 411 These primary/secondary procedures are optional. The Slave 412 endpoint(s) are required to act on the status bits received from the 413 Master. When the received status bit transitions from Active to 414 Standby, a Slave node MUST stop forwarding over the previously active 415 PW. When the received status bit transitions from Standby to Active 416 for a given PW, the Slave node MUST start forwarding user traffic 417 over this PW. 419 There is a single PE/T-PE Master PW endpoint node and one or many 420 PE/T-PE PW endpoint Slave nodes. The assignment of Master/Slave roles 421 to the PW endpoints is performed by local configuration. Note that 422 the above behavior assumes correct configuration of the Master and 423 Slave endpoints. This document does not define a mechanism to detect 424 errors in the configuration. 426 In this mode of operation, the following definition of Active and 427 Standby PW states apply: 429 o Active State 431 A PW is considered to be in Active state when the PW labels are 432 exchanged between its two endpoints in control plane, and the status 433 bits exchanged between the endpoints indicate the PW is UP at both 434 endpoints, and the forwarding status sent by the Master endpoint 435 indicates Active state. In this state user traffic can flow over the 436 PW in both directions. 438 o Standby State 440 A PW is considered to be in Standby state when the PW labels are 441 exchanged between its two endpoints in the control plane, but the 442 status bits sent by the Master endpoint indicate the PW is in Standby 443 state. In this state the endpoints MUST NOT forward data traffic over 444 the PW but MAY allow PW OAM packets, e.g., VCCV, to be sent and 445 received. If the PW is a spoke in H-VPLS, any MAC addresses learned 446 via the PW should be flushed when it transitions to Standby state. 448 5. Signaling procedures of PW State Transition 450 This section describes the extensions proposed and the processing 451 rules for the extensions. It defines a new "PW preferential 452 forwarding" bit in Status Code that is to be used with PW Status TLV 453 proposed in RFC 4447 [2]. The PW preferential forwarding bit when set 454 is used to signal Standby state of PW by one terminating point to the 455 other end. 457 5.1. PW Standby notification procedures in Independent mode 459 PW endpoint nodes independently select which PW they intend to use 460 for forwarding, and which PWs they do not, based on the specific 461 application. They advertise the corresponding Active/Standby 462 forwarding state for each PW. An active forwarding state is indicated 463 by clearing the Active/Standby status bit in the PW status TLV. A 464 standby forwarding state is indicated by setting the Active/Standby 465 status bit in the PW status TLV. This advertisement occurs in both 466 the initial label mapping message and in a subsequent notification 467 message when the forwarding state transitions as a result of a state 468 change in the specific application. 470 Each endpoint compares the updated local and remote status and 471 effectively activates the PW which is operationally UP at both 472 endpoints and which shows both local Active and remote Active states. 474 When a PW is in active state, the endpoints can forward both user 475 packets and OAM packets. 477 When a PW is in standby state, the endpoints MUST NOT forward user 478 packets over the PW but MAY forward PW OAM packets. 480 For MS-PWs, S-PEs MUST relay the PW status notification containing 481 both the operational and preferential forwarding status bits between 482 ingress and egress PWs. 484 5.2. PW Standby notification procedures in Master/Slave mode 486 Whenever the Master PW endpoint "actively" selects or deselects a PW 487 for forwarding user traffic at its end, it explicitly notifies the 488 event to the remote Slave endpoint. The slave endpoint carries out 489 the corresponding action on receiving the PW state change 490 notification. 492 If the PW preferential forwarding bit in PW Status TLV received by 493 the slave is set, it indicates that the PW at the Master end is not 494 used for forwarding and is thus kept in the Standby state, the PW 495 MUST also not be used for forwarding at Slave endpoint. Clearance of 496 the PW Preferential Forwarding bit in PW Status TLV indicates that 497 the PW at the Master endpoint is used for forwarding and is in Active 498 state, and the receiving Slave endpoint MUST activate the PW if it 499 was previously not used for forwarding. 501 This mechanism is RECOMMENDED to be used with PWs signaled in groups 502 with common group-id in PWid FEC Element or Grouping TLV in 503 Generalized PWid FEC Element defined in [2]. When PWs are provisioned 504 with such grouping a termination point sends a single "wildcard" 505 Notification message using a PW FEC TLV with only the group ID set, 506 to denote this change in status for all affected PW connections. This 507 status message contains either the PW FEC TLV with only the Group ID 508 set, or else it contains the PW Generalized FEC TLV with only the PW 509 Grouping ID TLV. As mentioned in [2], the Group ID field of the PWid 510 FEC Element, or the PW Grouping TLV used with the Generalized ID FEC 511 Element, can be used to send status notification for all arbitrary 512 set of PWs. For example, Group-ID in PWiD may be used to send 513 wildcard status notification message for a group of PWs when PWid FEC 514 element is used for PW state signaling. When Generalized PWiD FEC 515 Element defined is used in PW state signaling, PW Grouping TLV may be 516 used for wildcard status notification for a group of PWs. 518 For MS-PWs, S-PEs MUST relay the PW status notification containing 519 both the operational and preferential forwarding status bits between 520 ingress and egress PW segments. 522 5.2.1. PW State Machine 524 It is convenient to describe the PW state change behavior in terms of 525 a state machine. The PW state machine is explained in detail in the 526 two defined states and the behavior is presented as a state 527 transition table. The same state machine is seamlessly applicable to 528 PW Groups. 530 PW State Transition State Table 532 STATE EVENT NEW STATE 534 ACTIVE PW put in Standby (master) STANDBY 536 Action: Transmit PW preferential forwarding bit set 538 Receive PW preferential forwarding STANDBY 540 bit set 542 Action: Stop forwarding over PW 544 Receive PW preferential forwarding ACTIVE 545 bit set but bit not supported 547 Action: None 549 Receive PW preferential forwarding ACTIVE 551 bit clear 553 Action: None. 555 STANDBY PW activated (master) ACTIVE 557 Action: Transmit PW preferential forwarding bit 558 clear 560 Receive PW preferential forwarding ACTIVE 562 bit clear 564 Action: Activate PW 566 Receive PW preferential forwarding STANDBY 568 bit clear but bit not supported 570 Action: None 572 Receive PW preferential forwarding STANDBY 574 bit set 576 Action: No action 578 5.3. Coordination of PW Path Switchover 580 There are PW redundancy applications which require that PE/T-PE nodes 581 coordinate the switchover to a PW/MS-PW path such that both endpoints 582 will be forwarding over the same path at any given time. One such 583 application of redundant MS-PW paths is identified in [5]. Multiple 584 MS-PWs are configured between a pair of T-PE nodes. The paths of 585 these MS-PWs are diverse and are switched at different S-PE nodes. 586 Only one of these MS-PWs is active at any given time. The others are 587 put in standby. The endpoints follow the Independent Mode procedures 588 to activate the PW which is UP and advertised Active 'preferential 589 forwarding' status bit by both endpoints. 591 The trigger for sending a request to switchover of the path of the 592 MS-PW by one endpoint can be due to an operational event, example a 593 failure, which caused the endpoints to not be able to match the 594 Active 'preferential forwarding' status bit. The other trigger is the 595 execution of an administrative maintenance operation by the network 596 operator in order to move the traffic away from the node/links to be 597 serviced. 599 Unlike the case of a Master/Slave mode of operation, the endpoint 600 requesting the switchover requires explicit acknowledgement from the 601 peer endpoint that the request is honored before it switches the path 602 of the PW. Furthermore, any of the endpoints can make the request to 603 switchover. 605 A new status bit is proposed to have a PE/T-PE node request the 606 switchover to its peer. This bit will be referred to as 'request PW 607 switchover' status bit. The 'preferential forwarding' status bit 608 continues to be used by each endpoint to indicate its current local 609 settings of the active/standby state of each PW in the redundancy 610 set. In other words, like in the Independent mode, it indicates to 611 the far-end which of the PWs is being used to forward packets and 612 which is being put in standby. It can thus be used as a way for the 613 far-end to acknowledge the requested switchover operation. 615 The following procedures must be followed by both endpoints of a 616 PW/MS-PW to coordinate the switchover of the PW/MS-PW path. These 617 procedures are enabled only when the user configured the use of the 618 'request switchover' status bit at both endpoints. 620 S-PEs nodes MUST relay the PW status notification containing the 621 operational status bits, as well as the 'preferential forwarding' and 622 'request switchover' status bits between ingress and egress PW 623 segments. 625 5.3.1. Procedures at the requesting endpoint 627 a. The requesting endpoint sends a Status TLV in the LDP 628 notification message with the 'request switchover' bit set on the 629 PW it desires to switch to. 631 b. The endpoint does not activate forwarding on that PW/MS-PW at 632 this point in time. It may however enable receiving on that 633 PW/MS-PW. Thus the 'preferential forwarding' status bit still 634 reflects the currently used PW path. 636 c. The requesting endpoint starts a timer while waiting the remote 637 endpoint to acknowledge the request. 639 d. If while waiting for the acknowledgment, the requesting endpoint 640 receives a request from its peer to switchover to the same or a 641 different PW path, it must perform the following: 643 i. If its system IP address is higher than that of the peer, 644 this endpoint ignores the request and continues to wait 645 for the acknowledgement from its peer. 647 ii. If its system IP address is lower than that of its peer, 648 it aborts the timer and immediately starts the 649 procedures of the receiving endpoint in Section 5.3.2. 651 e. If while waiting for the acknowledgment, the requesting 652 endpoint receives a status notification message from its peer 653 with the 'preferential forwarding' status bit cleared in the 654 requested PW and set in all other PWs, it must treat this as an 655 explicit acknowledgment of the request and must perform the 656 following: 658 i. Abort the timer. 660 ii. Activate the PW path. 662 iii. Send an update status notification message with the 663 'preferential forwarding' status bit clear on the newly 664 active PW and set in all other PWs in the redudancy set, 665 and the 'request switchover' bit reset in all PWs in the 666 redundancy set.. 668 f. If while waiting for the acknowledgment, the requesting endpoint 669 detects that the requested PW went into operational Down state 670 locally, and could use an alternate PW which is operationally UP, 671 it must perform the following: 673 i. Abort the timer. 675 ii. Issue a new request to switchover to the alternate PW. 677 iii. Re-start the timer. 679 g. If while waiting for the acknowledgment, the requesting endpoint 680 detects that the requested PW went into operational Down state 681 locally, and could not use an alternate PW which is operationally 682 UP, it must perform the following: 684 i. Abort the timer. 686 ii. Send an update status notification message with the 687 'preferential forwarding' status bit unchanged and the 688 'request switchover' bit reset in all PWs in the 689 redundancy set. 691 h. If while waiting for the acknowledgment, the timer expired, the 692 requesting endpoint assumes the request is rejected and will 693 either issue a new request or do nothing. 695 i. If the requesting node receives the acknowledgment after the 696 request expired, it will treat it as if the remote endpoint 697 unilaterally switched the path of the PW without issuing a 698 request. In that case, it may issue a new request and follow the 699 requesting endpoint procedures to synchronize transmit and 700 receive paths of the PW. 702 5.3.2. Procedures at the receiving endpoint 704 a. Upon receiving a status notification message with the 'request 705 switchover' bit set on a PW different from the currently active 706 one, and the requested PW is operationally UP, the receiving 707 endpoint must perform the following: 709 i. Activate the PW. 711 ii. Send an update status notification message with the 712 'preferential forwarding' status bit clear on the newly 713 active PW and set in all other PWs in the redudancy set, 714 and the 'request switchover' bit reset in all PWs in the 715 redundancy set. 717 b. Upon receiving a status notification message with the 'request 718 switchover' bit set on a PW different from the currently active 719 one, and the requested PW is operationally Down, the receiving 720 endpoint must perform the following: 722 i. Ignore the request and do nothing. 724 6. Applicability and Backward Compatibility 726 The mechanism defined in this document is OPTIONAL and is applicable 727 to PWE3 applications where standby state signaling of PW or PW group 728 is required. 730 A PE implementation that uses the mechanisms described in this 731 document MUST negotiate the use of PW status TLV between its T-LDP 732 peers as per RFC 4447 [2]. If PW Status TLV is found to be not 733 supported by either of its endpoint after status negotiation 734 procedures, then the mechanisms specified in this document cannot be 735 used. 737 A PE implementation compliant to RFC 4447 [2], and which does not 738 support the generation or processing of the 'preferential forwarding' 739 status bit or of the 'request switchover'status bit, will not set 740 these bits in the status bits transmitted to a peer PE and will not 741 examine them in the received status bits from a peer PE. The 742 mechanisms specified in this document cannot be used. 744 7. Security Considerations 746 This document uses the LDP extensions that are needed for protecting 747 pseudo-wires. It will have the same security properties as in the 748 PWE3 control protocol [2]. 750 8. IANA Considerations 752 We have defined the following codes for the pseudo-wire redundancy 753 application. 755 8.1. Status Code for PW Preferential Forwarding Status 757 0x00000020 When the bit is set, it indicates "PW forwarding 759 standby". 761 When the bit is cleared, it indicates "PW forwarding 762 active". 764 8.2. Status Code for PW Request Switchover Status 766 0x00000040 When the bit is set, it represents "Request switchover to 767 this PW". 769 When the bit is cleared, it represents no specific 770 action. 772 9. Acknowledgments 774 The authors would like to thank Vach Kompella, Kendall Harvey, 775 Tiberiu Grigoriu, John Rigby, Prashanth Ishwar, Neil Hart, Kajal 776 Saha, Florin Balus, Philippe Niger, Dave McDysan, and Roman 777 Krzanowski for their valuable comments and suggestions. 779 10. References 781 10.1. Normative References 783 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 784 Levels", BCP 14, RFC 2119, March 1997. 786 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 787 LDP", RFC 4447, April 2006. 789 [3] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN 790 Service (VPLS) Using LDP Signalling", RFC 4762, January 2007. 792 10.2. Informative References 794 [4] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3- 795 segmented-pw-09.txt, January 2009. 797 [5] Muley, P., et al., "Pseudowire (PW) Redundancy", draft-ietf- 798 pwe3-redundancy-01.txt", March 2009. 800 [6] Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge (PWE3) 801 Architecture", RFC 3985, March 2005 803 11. Appendix A - Applications of PW Redundancy Procedures 805 This section shows how the mechanisms described in this document are 806 used to achieve the desired protection behavior for the scenarios 807 described in the PW redundancy requirements and framework document 808 [5]. 810 11.1. One Multi-homed CE with single SS-PW redundancy 812 The following figure illustrates an application of single segment 813 pseudo-wire redundancy. 815 |<-------------- Emulated Service ---------------->| 816 | | 817 | |<------- Pseudo Wire ------>| | 818 | | | | 819 | | |<-- PSN Tunnels-->| | | 820 | V V V V | 821 V AC +----+ +----+ AC V 822 +-----+ | | PE1|==================| | | +-----+ 823 | |----------|....|...PW1.(active)...|....|----------| | 824 | | | |==================| | | CE2 | 825 | CE1 | +----+ |PE2 | | | 826 | | +----+ | | +-----+ 827 | | | |==================| | 828 | |----------|....|...PW2.(standby)..| | 829 +-----+ | | PE3|==================| | 830 AC +----+ +----+ 832 Figure 2 Multi-homed CE with single SS-PW redundancy 834 The application in Figure 2 makes use of the Independent mode of 835 operation. 837 CE1 is dual homed to PE1 and to PE3 by attachment circuits. The 838 method for dual-homing of CE1 to PE1 and to PE3 nodes, and the used 839 protocols such as Multi-chassis Link Aggregation Group (MC-LAG), is 840 outside the scope of this document. 842 In normal operation, PE1 and PE3 will advertise "Active" and 843 "Standby" 'preferential forwarding' status bit respectively to PE2. 844 This status reflects the forwarding state of the two AC's to CE1 as 845 determined by the AC dual-homing protocol used. PE2 advertises 846 'preferential forwarding' status bit of "Active" on both PW1 and PW2 847 since the AC to CE2 is single homed. As both the local and remote 848 operational and preferential forwarding status for PW1 are UP and 849 Active, traffic is forwarded over PW1 in both directions. 851 On failure of the AC between CE1 and PE1, the forwarding state of the 852 AC on PE3 transitions to Active. For example the MC-LAG control 853 protocol changes the link state on PE3 to active. PE3 then announces 854 the newly changed 'preferential forwarding' status bit of "active" to 855 PE2. PE1 will advertise a PW status notification message indicating 856 that the AC between CE1 and PE1 is operationally down. PE2 matches 857 the local and remote preferential forwarding status of "active" and 858 operational status "Up" and select PW2 as the new active pseudo-wire 859 to send traffic to. 861 On failure of PE1 node, PE3 will detect it and will transition the 862 forwarding state of its AC to Active. The method by which PE3 detects 863 that PE1 is down is outside the scope of this document. PE3 then 864 announces the newly changed 'preferential forwarding' status bit of 865 "active" to PE2. PE3 and PE2 match the local and remote preferential 866 forwarding status of "active" and operational status "Up" and select 867 PW2 as the new active pseudo-wire to send traffic to. Note that PE2 868 may have detected that the PW to PE1 went down via T-LDP Hello 869 timeout or via other means. However, it will not be able to forward 870 user traffic until it received the updated status bit from PE3. 872 Note in this example, the receipt of the operational status of the AC 873 on the CE1-PE1 link is normally sufficient to have PE2 switch the 874 path to PW2. However, the operator may want to trigger the switchover 875 of the path of the PW for administrative reasons, i.e., maintenance, 876 and thus the use of the 'preferential forwarding' status bit is 877 required to notify PE2 to trigger the switchover. 879 Note that the primary/secondary procedures do not apply in this case 880 as the PW Active/Standby status is driven by the AC forwarding state 881 as determined by the AC dual-homing protocol used. 883 11.2. Multiple Multi-homed CEs with single SS-PW redundancy 885 |<-------------- Emulated Service ---------------->| 886 | | 887 | |<------- Pseudo Wire ------>| | 888 | | | | 889 | | |<-- PSN Tunnels-->| | | 890 | V V V V | 891 V AC +----+ +----+ AC V 892 +-----+ | |....|.......PW1........|....| | +-----+ 893 | |----------| PE1|...... .........| PE3|----------| | 894 | CE1 | +----+ \ / PW3 +----+ | CE2 | 895 | | +----+ X +----+ | | 896 | | | |....../ \..PW4....| | | | 897 | |----------| PE2| | PE4|--------- | | 898 +-----+ | |....|.....PW2..........|....| | +-----+ 899 AC +----+ +----+ AC 901 Figure 3 Multiple Multi-homed CEs with single SS-PW redundancy 903 The application in Figure 3 makes use of the Independent mode of 904 operation. 906 CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The 907 method for dual-homing and the used protocols such as Multi-chassis 908 Link Aggregation Group (MC-LAG) are outside the scope of this 909 document. Note that the PSN tunnels are not shown in this figure for 910 clarity. However, it can be assumed that each of the PWs shown is 911 encapsulated in a separate PSN tunnel. 913 PE1 advertises the preferential status "active" and operational 914 status "UP" for pseudo-wires PW1 and PW4 connected to PE3 and PE4. 915 This status reflects the forwarding state of the AC attached to PE1. 916 PE2 advertises preferential status "standby" where as operational 917 status "UP" for pseudo-wires PW2 and PW3 to PE3 and PE4. PE3 918 advertises preferential status "standby" where as operational status 919 "UP" for pseudo-wires PW1 and PW3 to PE1 and PE2. PE4 advertise the 920 preferential status "active" and operational status "UP" for pseudo- 921 wires PW2 and PW4 to PE2 and PE1 respectively. The method of 922 deriving Active/Standby status of the AC is outside the scope of 923 this document. In case of MC-LAG it is derived by the Link 924 Aggregation Control protocol (LACP) negotiation. Thus by matching 925 the local and remote preferential forwarding status of "active" and 926 operational status "Up" of pseudo-wire, the PE nodes determine which 927 PW should be in the Active state. In this case it is PW4 that will 928 be selected. 930 On failure of the AC between CE1 and PE1, the forwarding state of 931 the AC on PE2 is changed to Active. For example the MC-LAG control 932 protocol changes the link state on PE2 to active. PE2 then announces 933 the newly changed 'preferential forwarding' status bit of "active" 934 to PE3 and PE4. PE1 will advertise a PW status notification message 935 indicating that the AC between CE1 and PE1 is operationally down. 936 PE2 and PE4 match the local and remote preferential forwarding 937 status of "active" and operational status "Up" and select PW2 as the 938 new active pseudo-wire to send traffic to. 940 On failure of PE1 node, PE2 will detect it and will transition the 941 forwarding state of its AC to Active. The method by which PE2 942 detects that PE1 is down is outside the scope of this document. PE2 943 then announces the newly changed 'preferential forwarding' status 944 bit of "active" to PE3 and PE4. PE2 and PE4 match the local and 945 remote preferential forwarding status of "active" and operational 946 status "Up" and select PW2 as the new active pseudo-wire to send 947 traffic to. Note that PE3 and PE4 may have detected that the PW to 948 PE1 went down via T-LDP Hello timeout or via other means. However, 949 they will not be able to forward user traffic until they received 950 the updated status bit from PE2. 952 Because each dual-homing algorithm running on the two node sets, 953 i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC 954 independently, there is a need to signal the active status of the AC 955 such that the PE nodes can select a common active PW path for end-to- 956 end forwarding between CE1 and CE2 as per the procedures in the 957 independent mode. 959 Note that the primary/secondary procedures do not apply in this use 960 case as the Active/Standby status is driven by the AC forwarding 961 state as determined by the AC dual-homing protocol used. 963 11.3. Multi-homed CE with MS-PW redundancy 965 The following figure illustrates an application of multi-segment 966 pseudo-wire redundancy. 968 Native |<-----------Pseudo Wire----------->| Native 969 Service | | Service 970 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 971 | V V V V V V | 972 | +-----+ +-----+ +-----+ 973 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 974 | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | 975 | | | |=========| |=========| | | | 976 | CE1| +-----+ +-----+ +-----+ | | 977 | | |.| +-----+ +-----+ | CE2| 978 | | |.|===========| |=========| | | | 979 | | |.....PW2-Seg1......|.PW2-Seg2......|-------| | 980 +----+ |=============|S-PE2|=========|T-PE4| | +----+ 981 +-----+ +-----+ AC 983 Figure 4 Multi-homed CE with MS-PW redundancy 985 The application in Figure 4 makes use of the Independent mode of 986 operation. 988 CE2 is dual-homed to T-PE2 and T-PE4. PW1 and PW2 are used to extend 989 the resilient connectivity all the way to T-PE1. PW1 has two segments 990 and is active pseudo-wire while PW2 has two segments and is a standby 991 pseudo-wire. This application requires support for MS-PW with 992 segments of the same type as described in [4]. 994 The operation in this case is the same as in the case of SS-PW as 995 described in Section 11.1. . The only difference is that the S-PE 996 nodes need to relay the PW status notification containing both the 997 operational and forwarding status to the T-PE nodes. 999 11.4. Single Homed CE with MS-PW redundancy 1001 The following is an application of the independent mode of operation 1002 along with the optional request switchover procedures in order to 1003 provide N:1 PW protection. A revertive behavior to a primary PW is 1004 shown as an example of configuring and using the primary/secondary 1005 procedures. 1007 Native |<------------Pseudo Wire------------>| Native 1008 Service | | Service 1009 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 1010 | V V V V V V | 1011 | +-----+ +-----+ +-----+ | 1012 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 1013 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 1014 | CE1| | |=========| |=========| | | CE2| 1015 | | +-----+ +-----+ +-----+ | | 1016 +----+ |.||.| |.||.| +----+ 1017 |.||.| +-----+ |.||.| 1018 |.||.|=========| |========== .||.| 1019 |.||...PW2-Seg1......|.PW2-Seg2...||.| 1020 |.| ===========|S-PE2|============ |.| 1021 |.| +-----+ |.| 1022 |.|============+-----+============= .| 1023 |.....PW3-Seg1.| | PW3-Seg2......| 1024 ==============|S-PE3|=============== 1025 | | 1026 +-----+ 1028 Figure 5 Single homed CE with multi-segment pseudo-wire redundancy 1030 CE1 is connected to PE1 in provider Edge 1 and CE2 to PE2 in provider 1031 edge 2 respectively. There are three segmented PWs. A primary PW, 1032 PW1, is switched at S-PE1. A primary PW has the highest precedence. A 1033 secondary PW, PW2, which is switched at S-PE2 and has a precedence of 1034 1. Finally, another secondary PW, PW3, is switched at S-PE3 and has a 1035 precedence of 2. The precedence is locally configured at the 1036 endpoints of the PW, i.e., T-PE1 and T-PE2. 1038 T-PE1 and T-PE2 will select the PW they intend to activate based on 1039 their local and remote operational state as well as the local 1040 primary/precedence configuration. In this case, they will both 1041 advertise preferential forwarding' status bit of "active" on PW1 and 1042 of "standby" on PW2 and PW3. Assuming all PWs are operationally UP, 1043 T-PE1 and T-PE2 will use PW1 to forward user packets. 1045 If PW1 fails, then the T-PE detecting the failure will send a status 1046 notification to the remote T-PE with a "PW Down" bit set as well as 1047 the 'preferential forwarding' status bit set on PW1. It will also 1048 clear 'preferential forwarding' status bit on PW2 as it is the next 1049 it has the next lowest precedence value. T-PE2 will also perform the 1050 same steps as soon as it is informed of the failure of PW1. Both T-PE 1051 nodes will perform a match on the 'preferential forwarding' status 1052 of "active" and operational status of "Up" and will use PW2 to 1053 forward user packets. 1055 However this does not guarantee that paths of the PW are synchronized 1056 at all times. This may be due to a mismatch of the configuration of 1057 the PW priority in each T-PE. This may also be due to a failure which 1058 caused the endpoints to not be able to match the Active 'preferential 1059 forwarding' status bit and operational status bits. In this case, T- 1060 PE1 and/or T-PE2 can invoke the optional request 1061 switchover/acknowledgement procedures to synchronize the PW paths in 1062 both directions. 1064 The trigger for sending a request to switchover can also be the 1065 execution of an administrative maintenance operation by the network 1066 operator in order to move the traffic away from the T-PE/S-PE nodes 1067 /links to be serviced. 1069 In case the request switchover is sent by both endpoints 1070 simultaneously, both T-PEs send status notification with the newly 1071 selected PW with 'request switchover' bit set, waiting for response 1072 from the other endpoint. In such situation, the T-PE with greater 1073 system address request is given precedence. This helps in 1074 synchronizing paths in event of mismatch of priority configuration as 1075 well. 1077 11.5. PW redundancy between H-VPLS MTU-s and PE-rs 1079 Following figure illustrates the application of use of PW redundancy 1080 in H-VPLS for the purpose of dual-homing an MTU-s node to PE nodes 1081 using PW spokes. This application makes use of the Master/Slave mode 1082 of operation. 1084 |<-PSN1-->| |<-PSN2-->| 1085 V V V V 1086 +-----+ +--------+ 1087 |MTU-s|=========|PE1-rs |======== 1088 |..Active PW group.... | H-VPLS-core 1089 | |=========| |========= 1090 +-----+ +--------+ 1091 |.| 1092 |.| +--------+ 1093 |.|===========| |========== 1094 |...Standby PW group |.H-VPLS-core 1095 =============| PE2-rs|========== 1096 +--------+ 1098 Figure 6 Multi-homed MTU-s in H-VPLS core 1100 MTU-s is dual homed to PE1-rs and PE2-rs. The primary spoke PWs from 1101 MTU-s are connected to PE1-rs while the secondary PWs are connected 1102 to PE2. PE1-rs and PE2-rs are connected to H-VPLS core on the other 1103 side of network. MTU-s communicates to PE1-rs and PE2-rs the 1104 forwarding status of its member PWs for a set of VSIs having common 1105 status Active/Standby. It may be signaled using PW grouping with 1106 common group-id in PWid FEC Element or Grouping TLV in Generalized 1107 PWid FEC Element as defined in [2] to scale better. MTU-s derives 1108 the status of the PWs based on local policy configuration. In this 1109 example, the primary/secondary procedures are used but this can be 1110 based on any other policy. 1112 Whenever MTU-s performs a switchover, it sends a wildcard 1113 Notification Message to PE2-rs for the Standby PW group containing PW 1114 Status TLV with PW Standby bit cleared. On receiving the notification 1115 PE-2rs unblocks all member PWs identified by the PW group and state 1116 of PW group changes from Standby to Active. All procedures described 1117 in Section 5.2. are applicable. 1119 The use of the 'preferential forwarding' status bit in Master/Slave 1120 mode is similar to Topology Change Notification in RSTP controlled 1121 IEEE Ethernet Bridges but is restricted over a single hop. When these 1122 procedures are implemented, PE-rs devices are aware of switchovers at 1123 MTU-s and could generate MAC Withdraw Messages to trigger MAC 1124 flushing within the H-VPLS full mesh. By default, MTU-s devices 1125 should still trigger MAC Withdraw messages as currently defined in 1126 [6] to prevent two copies of MAC withdraws to be sent, one by MTU-s 1127 and another one by PE-rs nodes. Mechanisms to disable MAC Withdraw 1128 trigger in certain devices is out of the scope of this document 1130 Author's Addresses 1132 Praveen Muley 1133 Alcatel-lucent 1134 701 E. Middlefiled Road 1135 Mountain View, CA, USA 1136 Email: Praveen.muley@alcatel-lucent.com 1138 Mustapha Aissaoui 1139 Alcatel-lucent 1140 600 March Rd 1141 Kanata, ON, Canada K2K 2E6 1142 Email: mustapha.aissaoui@alcatel-lucent.com 1144 Matthew Bocci 1145 Alcatel-Lucent 1146 Voyager Place, Shoppenhangers Rd 1147 Maidenhead, Berks, UK SL6 2PJ 1148 Email: matthew.bocci@alcatel-lucent.co.uk 1150 Pranjal Kumar Dutta 1151 Alcatel-Lucent 1152 Email: pdutta@alcatel-lucent.com 1154 Marc Lasserre 1155 Alcatel-Lucent 1156 Email: mlasserre@alcatel-lucent.com 1158 Jonathan Newton 1159 Cable & Wireless 1160 Email: Jonathan.Newton@cw.com 1162 Olen Stokes 1163 Extreme Networks 1164 Email: ostokes@extremenetworks.com 1166 Hamid Ould-Brahim 1167 Nortel 1168 Email: hbrahim@nortel.com 1170 Luca Martini 1171 Cisco Systems, Inc. 1172 9155 East Nichols Avenue, Suite 400 1173 Englewood, CO, 80112 1174 Email: lmartini@cisco.com 1176 Thomas Nadeau 1177 BT 1178 tnadeau@lucidvision.com 1180 Giles Heron 1181 BT 1182 giles.heron@gmail.com 1184 Full Copyright Statement 1186 Copyright (C) The IETF Trust (2008). 1188 This document is subject to the rights, licenses and restrictions 1189 contained in BCP 78, and except as set forth therein, the authors 1190 retain all their rights. 1192 This document and the information contained herein are provided on 1193 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1194 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1195 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1196 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1197 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1198 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1199 FOR A PARTICULAR PURPOSE. 1201 Intellectual Property Statement 1203 The IETF takes no position regarding the validity or scope of any 1204 Intellectual Property Rights or other rights that might be claimed to 1205 pertain to the implementation or use of the technology described in 1206 this document or the extent to which any license under such rights 1207 might or might not be available; nor does it represent that it has 1208 made any independent effort to identify any such rights. Information 1209 on the procedures with respect to rights in RFC documents can be 1210 found in BCP 78 and BCP 79. 1212 Copies of IPR disclosures made to the IETF Secretariat and any 1213 assurances of licenses to be made available, or the result of an 1214 attempt made to obtain a general license or permission for the use of 1215 such proprietary rights by implementers or users of this 1216 specification can be obtained from the IETF on-line IPR repository at 1217 http://www.ietf.org/ipr. 1219 The IETF invites any interested party to bring to its attention any 1220 copyrights, patents or patent applications, or other proprietary 1221 rights that may cover technology that may be required to implement 1222 this standard. Please address the information to the IETF at 1223 ietf-ipr@ietf.org. 1225 Acknowledgment 1227 Funding for the RFC Editor function is currently provided by the 1228 Internet Society.