idnits 2.17.1 draft-ietf-pwe3-redundancy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 35. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 597. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 60 has weird spacing: '...path to forw...' == Line 61 has weird spacing: '...ate the pref...' == Line 62 has weird spacing: '...h PW in the ...' == Line 333 has weird spacing: '...side of netwo...' -- 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 (March 28, 2008) is 5873 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '6' is defined on line 527, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 533, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (ref. '2') (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 3036 (ref. '4') (Obsoleted by RFC 5036) == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-02 == Outdated reference: A later version (-02) exists of draft-muley-dutta-pwe3-redundancy-bit-00 Summary: 5 errors (**), 0 flaws (~~), 9 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: Informational Matthew Bocci 4 Expires: August 2008 Pranjal Kumar Dutta 5 Marc Lasserre 6 Alcatel 8 Jonathan Newton 9 Cable & Wireless 11 Olen Stokes 12 Extreme Networks 14 Hamid Ould-Brahim 15 Nortel 17 Dave Mcdysan 18 Verizon 20 Giles Heron 21 Thomas Nadeau 22 British Telecom 24 March 28, 2008 26 Pseudowire (PW) Redundancy 27 draft-ietf-pwe3-redundancy-00.txt 29 Status of this Memo 31 By submitting this Internet-Draft, each author represents that 32 any applicable patent or other IPR claims of which he or she is 33 aware have been or will be disclosed, and any of which he or she 34 becomes aware will be disclosed, in accordance with Section 6 of 35 BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 This Internet-Draft will expire on August 28, 2008. 54 Abstract 56 This document describes a framework comprised of few scenarios and 57 associated requirements where PW redundancy is needed. A set of 58 redundant PWs is configured between PE nodes in SS-PW applications, 59 or between T-PE nodes in MS-PW applications. In order for the PE/T-PE 60 nodes to indicate the preferred PW path to forward to one another, 61 a new status is needed to indicate the preferential forwarding 62 status of active or standby for each PW in the redundancy set. 64 Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC-2119 [1]. 70 Table of Contents 72 1. Terminology ......................................... 3 73 2. Introduction......................................... 4 74 3. Reference Model...................................... 4 75 3.1. Multiple Multi-homed CEs with single SS-PW redundancy... 5 76 3.2. Single Homed CE with MS-PW redundancy................ 6 77 3.3. PW redundancy between MTU-s and PEs in a multi-homed VPLS 78 application ......................................... 8 79 3.4. PW redundancy between n-PEs........................ 9 80 3.5. PW redundancy in Bridge Module Model................. 9 81 4. Generic PW redundancy requirements...................... 11 82 4.1. Protection switching requirements.................. 11 83 4.2. Operational requirements.......................... 11 84 5. Security Considerations............................... 12 85 6. Acknowledgments..................................... 12 86 7. References......................................... 12 87 7.1. Normative References............................. 12 88 7.2. Informative References........................... 12 89 Author's Addresses..................................... 13 90 Intellectual Property Statement .......................... 13 91 Disclaimer of Validity.................................. 14 92 Acknowledgment ........................................ 14 94 1. Terminology 96 o PW Terminating Provider Edge (T-PE). A PE where the customer- 97 facing attachment circuits (ACs) are bound to a PW forwarder. A 98 Terminating PE is present in the first and last segments of a MS- 99 PW. This incorporates the functionality of a PE as defined in 100 RFC3985 [3]. 102 o Single-Segment Pseudo Wire (SS-PW). A PW setup directly between 103 two T-PE devices. Each PW in one direction of a SS-PW traverses 104 one PSN tunnel that connects the two T-PEs. 106 o Multi-Segment Pseudo Wire (MS-PW). A static or dynamically 107 configured set of two or more contiguous PW segments that behave 108 and function as a single point-to-point PW. Each end of a MS-PW by 109 definition MUST terminate on a T-PE. 111 o PW Segment. A part of a single-segment or multi-segment PW, which 112 is set up between two PE devices, T-PEs and/or S-PEs. 114 o PW Switching Provider Edge (S-PE). A PE capable of switching the 115 control and data planes of the preceding and succeeding PW 116 segments in a MS-PW. The S-PE terminates the PSN tunnels of the 117 preceding and succeeding segments of the MS-PW. 119 o PW switching point for a MS-PW. A PW Switching Point is never the 120 S-PE and the T-PE for the same MS-PW. A PW switching point runs 121 necessary protocols to setup and manage PW segments with other PW 122 switching points and terminating PEs 124 o Active PW. A PW whose preferential status is set to Active and 125 Operational status is UP. 127 o Standby PW. A PW whose preferential status is set to Standby and 128 Operational status is UP. 130 o Primary Path. The configured path which is preferred when 131 revertive protection switching is used. 133 o Secondary Path. One or more configured paths that are used by 134 protection switching when current active PW path enters 135 Operational DOWN state. 137 o Revertive protection switching. Traffic will be carried by primary 138 path if it is Operationally UP and the wait-to-restore timer 139 expires and primary path is made the Active PW. 141 o Non-revertive protection switching. Traffic will be carried by the 142 last PW path selected as a result of previous active path entering 143 Operationally DOWN state. 145 o Manual selection of PW path. Ability for the operator to manually 146 select the primary/secondary paths. 148 2. Introduction 150 In single-segment PW (SS-PW) applications, protection for the PW is 151 provided by the PSN layer. This may be an RSVP LSP with a FRR backup 152 and/or an end-to-end backup LSP. There are however applications where 153 the backup PW terminates on a different target PE node. PSN 154 protection mechanisms cannot protect against failure of the target PE 155 node or the failure of the remote AC. 157 In multi-segment PW (MS-PW) applications, a primary and one or more 158 secondary PWs in standby mode are configured in the network. The 159 paths of these PWs are diverse in the sense that they are switched at 160 different S-PE nodes. In these applications, PW redundancy is 161 important for the service resilience. 163 In some deployments, it is important for operators that 164 particular PW is preferred if it is available. For example, PW path 165 with least latency may be preferred. 167 This document describes framework for these applications and its 168 associated operational requirements. The framework comprises of new 169 required status called preferential status to PW apart from the 170 operational status already defined in the PWE3 control protocol [2]. 171 The definition and operation of the preferential status is covered in 172 ref.[7] 174 3. Reference Model 176 Following figures shows the reference model for the PW redundancy and 177 its usage in different topologies and applications. 179 3.1. Multiple Multi-homed CEs with single SS-PW redundancy 181 |<-------------- Emulated Service ---------------->| 182 | | 183 | |<------- Pseudo Wire ------>| | 184 | | | | 185 | | |<-- PSN Tunnels-->| | | 186 | V V V V | 187 V AC +----+ +----+ AC V 188 +-----+ | |....|.......PW1........|....| | +-----+ 189 | |----------| PE1|...... .........| PE3|----------| | 190 | CE1 | +----+ \ / PW3 +----+ | CE2 | 191 | | +----+ X +----+ | | 192 | | | |....../ \..PW4....| | | | 193 | |----------| PE2| | PE4|--------- | | 194 +-----+ | |....|.....PW2..........|....| | +-----+ 195 AC +----+ +----+ AC 197 Figure 1 Multiple Multi-homed CEs with single SS-PW redundancy 199 In the Figure 1 illustrated above both CEs, CE1 and CE2 are dual- 200 homed with PEs, PE1, PE2 and PE3, PE4 respectively. The method for 201 dual-homing and the used protocols such as Multi-chassis Link 202 Aggregation Group (MC-LAG) are outside the scope of this document. 203 Note that the PSN tunnels are not shown in this figure for clarity. 204 However, it can be assumed that each of the PWs shown is encapsulated 205 in a separate PSN tunnel. 207 PE1 has PW1 and PW4 service connecting PE3 and PE4 208 respectively. Similarly PE2 has PW2 and Pw3 pseudo wire service 209 connecting PE4 and PE3 respectively. PW1,PW2, PW3 and PW4 are all 210 operationally UP. In order to support N:1 or 1:1 only one PW is 211 required to be selected to forward the traffic. Thus the PW needs to 212 reflect his new status apart from the operational status. We call 213 this as preferential forwarding status with state representing 214 'active' the one carrying traffic while the other 'standby' which is 215 operationally UP but not forwarding traffic. The method of deriving 216 Active/Standby status of the AC is outside the scope of this 217 document. In case of MC-LAG it is derived by the Link Aggregation 218 Control protocol (LACP) negotiation. 220 A new algorithm needs to be developed using the preferential 221 forwarding state of PW and select only one PW to forward. 223 On failure of AC between the dual homed CE1 in this 224 case lets say PE1 the preferential status on PE2 needs to be 225 changed. Different mechanisms/protocols can be used to achieve this 226 and these are beyond the scope of this document. For example the MC- 227 LAG control protocol changes the link status on PE2 to active. After 228 the change in status the algorithm for selection of PW needs to 229 revaluate and select PW to forward the traffic. 231 In this application, because each dual-homing algorithm running on 232 the two node sets, i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects 233 the active AC independently, there is a need to signal the active 234 status of the AC such that the PE nodes can select a common active PW 235 path for end-to-end forwarding between CE1 and CE2. This helps in 236 restricting the changes occurring on one side of network due to 237 failure to the other side of the network. Note this method also 238 protects against any single PE failure or some dual PE failures. 240 One Multi-homed CE with single SS-PW redundancy 241 application is a subset of above. Only PW1 and PW3 exist in this 242 case. This helps against AC failure and PE failure of dual homed AC. 243 Similar requirements applies in usage MS-PW redundancy as well. An 244 additional requirement applicable to MS-PW is forwarding of status 245 notification through S-PE. In general from customer view, SS-PW and 246 MS-PW has similar resiliency requirement. 248 There is also a 1:1 protection switching case that is a subset of the 249 above where PW3 and PW4 are not present and the CEs do not perform 250 native service protection switching, but instead may use load 251 balancing. This protects against AC failures and can use the native 252 service to indicate active/failed state. 254 If each CE homes to different PEs, then the CEs can implement 255 native service protection switching, without any PW redundancy 256 functions. All that the PW needs to do is detect AC, PE, or PSN 257 tunnel failures and convey that information to both PEs at the end of 258 the PW. This is applicable to MS-PW as well. 260 3.2. Single Homed CE with MS-PW redundancy 262 This is the main application of interest and the network setup is 263 shown in Figure 2 264 Native |<------------Pseudo Wire------------>| Native 265 Service | | Service 266 (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) 267 | V V V V V V | 268 | +-----+ +-----+ +-----+ | 269 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 270 | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | 271 | CE1| | |=========| |=========| | | CE2| 272 | | +-----+ +-----+ +-----+ | | 273 +----+ |.||.| |.||.| +----+ 274 |.||.| +-----+ |.||.| 275 |.||.|=========| |========== .||.| 276 |.||...PW2-Seg1......|.PW2-Seg2...||.| 277 |.| ===========|S-PE2|============ |.| 278 |.| +-----+ |.| 279 |.|============+-----+============= .| 280 |.....PW3-Seg1.| | PW3-Seg2......| 281 ==============|S-PE3|=============== 282 | | 283 +-----+ 285 Figure 2 Single homed CE with multi-segment pseudo-wire redundancy 287 In Figure 2, CE1 is connected to PE1 in provider Edge 1 and CE2 to 288 PE2 in provider edge 2 respectively. There are three segmented PWs. A 289 PW1, is switched at S-PE1, PW2, which is switched at S-PE2 and PW3, 290 is switched at S-PE3. 292 Since there is no multi-homing running on the AC, the T- 293 PE nodes would advertise 'Active" for the forwarding status based on the 294 priority. Priorities associate meaning of 'primary PW' and 'secondary 295 PW'. These priorities MUST be used in revertive mode as well and paths 296 must be switched accordingly. The priority can be configuration or 297 derivation from the PWid. Lower the PWid higher the priority. However 298 this does not guarantee that paths of the PW are synchronized because 299 for example of mismatch of the configuration of the PW priority in each 300 T-PE.The intent of this application is to have T-PE1 and T-PE2 301 synchronize the transmit and receive paths of the PW over the network. 302 In other words, both T-PE nodes are required to transmit over the PW 303 segment which is switched by the same S-PE. This is desirable for ease 304 of operation and troubleshooting. 306 3.3. PW redundancy between MTU-s and PEs in a multi-homed VPLS 307 application 309 Following figure illustrates the application of use of PW redundancy 310 in spoke PW by dual homed MTU-s to PEs. 312 |<-PSN1-->| |<-PSN2-->| 313 V V V V 314 +-----+ +-----+ 315 |MTU-s|=========|PE1 |======== 316 |..Active PW group....| H-VPLS-core 317 | |=========| |========= 318 +-----+ +-----+ 319 |.| 320 |.| +-----+ 321 |.|===========| |========== 322 |...Standby PW group|.H-VPLS-core 323 =============| PE2|========== 324 +-----+ 326 Figure 3 Multi-homed MTU-s in H-VPLS core 328 In Figure 3, MTU-s is dual homed to PE1 and PE2 and has spoke PWs to 329 each of them. MTU-s needs to choose only one of the spoke PW (active 330 PW) to one of the PE to forward the traffic and the other to standby 331 status. MTU-s can derive the status of the PWs based on local policy 332 configuration. PE1 and PE2 are connected to H-VPLS core on the other 333 side of network. MTU-s communicates the status of its member PWs for 334 a set of VSIs having common status Active/Standby. Here MTU-s 335 controls the selection of PWs to forward the traffic. Signaling 336 using PW grouping with common group-id in PWid FEC Element or 337 Grouping TLV in Generalized PWid FEC Element as defined in [2] to PE1 338 and PE2 respectively, is encouraged to scale better. 340 Whenever MTU-s performs a switchover, it requires 341 to communicate to PE2-rs for the Standby PW group the changed status 342 of active . 344 In this scenario, PE devices are aware of switchovers 345 at MTU-s and could generate MAC Withdraw Messages to trigger MAC 346 flushing within the H-VPLS full mesh. By default, MTU-s devices 347 should still trigger MAC Withdraw messages as currently defined in 348 [5] to prevent two copies of MAC withdraws to be sent (one by MTU-s 349 and another one by PEs). Mechanisms to disable MAC Withdraw trigger 350 in certain devices is out of the scope of this document. 352 3.4. PW redundancy between n-PEs 354 Following figure illustrates the application of use of PW redundancy 355 for dual homed connectivity between PE devices in a ring topology. 357 +-------+ +-------+ 359 | PE1 |=====================| PE2 |====... 361 +-------+ PW Group 1 +-------+ 363 || || 365 VPLS Domain A || || VPLS Domain B 367 || || 369 +-------+ +-------+ 371 | PE3 |=====================| PE4 |==... 373 +-------+ PW Group 2 +-------+ 375 Figure 4 Redundancy in Ring topology 377 In Figure 4, PE1 and PE3 from VPLS domain A are connected to PE2 and 378 PE4 in VPLS domain B via PW group 1 and group 2. Each of the PE in 379 respective domain is connected to each other as well to form the ring 380 topology. Such scenarios may arise in inter-domain H-VPLS deployments 381 where RSTP or other mechanisms may be used to maintain loop free 382 connectivity of PW groups. 384 Ref.[5] outlines about multi-domain VPLS service without 385 specifying how redundant border PEs per domain per VPLS instance can 386 be supported. In the example above, PW group1 may be blocked at PE1 387 by RSTP and it is desirable to block the group at PE2 by virtue of 388 exchanging the PW preferential status as Standby. How the PW grouping 389 should be done here is again deployment specific and is out of scope 390 of the solution. 392 3.5. PW redundancy in Bridge Module Model 394 ----------------------------+ Provider +------------------------ 395 . Core . 397 +------+ . . +------+ 399 | n-PE |======================| n-PE | 401 Provider | (P) |---------\ /-------| (P) | Provider 403 Access +------+ ._ \ / . +------+ Access 405 Network . \/ . Network 407 (1) +------+ . /\ . +------+ (2) 409 | n-PE |----------/ \--------| n-PE | 411 | (B) |----------------------| (B) |_ 413 +------+ . . +------+ 415 . . 417 ----------------------------+ +------------------------ 419 Figure 5 Bridge Module Model 421 In Figure 5, two provider access networks, each having two n-PEs, 422 where the n-PEs are connected via a full mesh of PWs for a given VPLS 423 instance. As shown in the figure, only one n-PE in each access 424 network is serving as a Primary PE (P) for that VPLS instance and the 425 other n-PE is serving as the backup PE (B).In this figure, each 426 primary PE has two active PWs originating from it. Therefore, when a 427 multicast, broadcast, and unknown unicast frame arrives at the 428 primary n-PE from the access network side, the n-PE replicates the 429 frame over both PWs in the core even though it only needs to send the 430 frames over a single PW (shown with == in the figure) to the primary 431 n-PE on the other side. This is an unnecessary replication of the 432 customer frames that consumes core-network bandwidth (half of the 433 frames get discarded at the receiving n-PE). This issue gets 434 aggravated when there is three or more n-PEs per provider, access 435 network. For example if there are three n-PEs or four n-PEs per 436 access network, then 67% or 75% of core-BW for multicast, broadcast 437 and unknown unicast are respectively wasted. 439 In this scenario, Standby PW signaling defined in 440 [7] can be used among n-PEs that can disseminate the status of PWs 441 (active or blocked) among themselves and furthermore to have it tied 442 up with the redundancy mechanism such that per VPLS instance the 443 status of active/backup n-PE gets reflected on the corresponding PWs 444 emanating from that n-PE. 446 4. Generic PW redundancy requirements 448 4.1. Protection switching requirements 450 o Protection architecture such as N:1,1:1 or 1+1 can be used. N:1 451 protection case is somewhat inefficient in terms of capacity 452 consumption hence implementations SHOULD support this method while 453 1:1 being subset and efficient MUST be supported. 1+1 protection 454 architecture can be supported but is left for further study. 456 o Non-revertive mode MUST be supported, while revertive mode is an 457 optional one. 459 o Protection switchover can be operator driven like Manual 460 lockout/force switchover or due to signal failure. Both methods 461 MUST be supported and signal failure MUST be given higher priority 462 than any local or far end request. 464 4.2. Operational requirements 466 o (T-)PEs involved in protecting a PW SHOULD automatically discover 467 and attempt to resolve inconsistencies in the configuration of 468 primary/secondary PW. 470 o (T-)PEs involved in protecting a PW SHOULD automatically discover 471 and attempt to resolve inconsistencies in the configuration of 472 revertive/non-revertive protection switching mode. 474 o (T-)PEs that do not automatically discover or resolve 475 inconsistencies in the configuration of primary/secondary, 476 revertive/non-revertive, or other parameters MUST generate an 477 alarm upon detection of an inconsistent configuration. 479 o (T-)PEs involved with protection switching MUST support the 480 configuration of revertive or non-revertive protection switching 481 mode. 483 o (T-)PEs involved with protection switching SHOULD support the 484 local invocation of protection switching. 486 o (T-)PEs involved with protection switching SHOULD support the 487 local invocation of a lockout of protection switching. 489 o In standby status PW can still receive packets in order to avoid 490 black holing of in-flight packets during switchover. However in 491 case of use of VPLS application packets are dropped in standby 492 status except for the OAM packets. 494 5. Security Considerations 496 This document expects extensions to LDP that are needed for 497 protecting pseudo-wires. It will have the same security properties as 498 in LDP [4] and the PW control protocol [2]. 500 6. Acknowledgments 502 The authors would like to thank Vach Kompella, Kendall Harvey, 503 Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus and Philippe 504 Niger for their valuable comments and suggestions. 506 7. References 508 7.1. Normative References 510 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 511 Levels", BCP 14, RFC 2119, March 1997. 513 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 514 LDP", RFC 4447, April 2006. 516 [3] Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge (PWE3) 517 Architecture", March 2005 519 [4] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 520 Thomas, "LDP Specification", RFC 3036, January 2001 522 [5] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN 523 Service (VPLS) Using LDP Signalling", RFC 4762, January 2007 525 7.2. Informative References 527 [6] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3- 528 segmented-pw-02.txt, March 2006. 530 [7] Muley, P. et al., "Preferential forwarding status bit", draft- 531 muley-dutta-pwe3-redundancy-bit-00.txt, August 2007. 533 [8] IEEE Std. 802.1D-2003-Media Access Control (MAC) Bridges. 535 Author's Addresses 537 Praveen Muley 538 Alcatel 539 701 E. Middlefiled Road 540 Mountain View, CA, USA 541 Email: Praveen.muley@alcatel.com 543 Mustapha Aissaoui 544 Alcatel 545 600 March Rd 546 Kanata, ON, Canada K2K 2E6 547 Email: mustapha.aissaoui@alcatel.com 549 Matthew Bocci 550 Alcatel 551 Voyager Place, Shoppenhangers Rd 552 Maidenhead, Berks, UK SL6 2PJ 553 Email: matthew.bocci@alcatel-lucent.co.uk 555 Pranjal Kumar Dutta 556 Alcatel-Lucent 557 Email: pdutta@alcatel-lucent.com 559 Marc Lasserre 560 Alcatel-Lucent 561 Email: mlasserre@alcatel-lucent.com 563 Jonathan Newton 564 Cable & Wireless 565 Email: Jonathan.Newton@cwmsg.cwplc.com 567 Olen Stokes 568 Extreme Networks 569 Email: ostokes@extremenetworks.com 571 Hamid Ould-Brahim 572 Nortel 573 Email: hbrahim@nortel.com 575 Intellectual Property Statement 577 The IETF takes no position regarding the validity or scope of any 578 Intellectual Property Rights or other rights that might be claimed to 579 pertain to the implementation or use of the technology described in 580 this document or the extent to which any license under such rights 581 might or might not be available; nor does it represent that it has 582 made any independent effort to identify any such rights. Information 583 on the procedures with respect to rights in RFC documents can be 584 found in BCP 78 and BCP 79. 586 Copies of IPR disclosures made to the IETF Secretariat and any 587 assurances of licenses to be made available, or the result of an 588 attempt made to obtain a general license or permission for the use of 589 such proprietary rights by implementers or users of this 590 specification can be obtained from the IETF on-line IPR repository at 591 http://www.ietf.org/ipr. 593 The IETF invites any interested party to bring to its attention any 594 copyrights, patents or patent applications, or other proprietary 595 rights that may cover technology that may be required to implement 596 this standard. Please address the information to the IETF at 597 ietf-ipr@ietf.org. 599 Disclaimer of Validity 601 This document and the information contained herein are provided on an 602 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 603 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 604 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 605 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 606 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 607 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 609 Copyright Statement 611 Copyright (C) The IETF Trust (2007). 613 This document is subject to the rights, licenses and restrictions 614 contained in BCP 78, and except as set forth therein, the authors 615 retain all their rights. 617 Acknowledgment 619 Funding for the RFC Editor function is currently provided by the 620 Internet Society.