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