Network Working Group Praveen Muley Internet Draft Mustapha Aissaoui Intended Status: Informational Matthew Bocci Expires: August 2007 Pranjal Kumar Dutta Marc Lasserre Alcatel Jonathan Newton Cable & Wireless Olen Stokes Extreme Networks Hamid Ould-Brahim Nortel March 5, 2007 Pseudowire (PW) Redundancy draft-muley-pwe3-redundancy-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 5, 2007. Abstract Muley et al. Expires September 5, 2007 [Page 1] Internet-Draft Pseudowire (PW) Redundancy) March 2007 This document describes few scenarios where PW redundancy is needed. A set of redundant PWs is configured between PE nodes in SS- PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status bit is needed to indicate the preferential forwarding status of active or standby for each PW in the redundancy set as defined in [7]. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Terminology....................................................3 2. Introduction...................................................3 3. Multi-homing Single SS-PW redundancy applications..............4 3.1. One Multi-homed CE with single SS-PW redundancy...........4 3.2. Multiple Multi-homed CEs with single SS-PW redundancy.....6 4. Multi-homing MS-PW redundancy applications.....................7 4.1. Multi-homed CE with MS-PW redundancy......................7 4.2. Single Homed CE with MS-PW redundancy.....................8 5. Multi-homing VPLS applications.................................9 5.1. PW redundancy between MTU-s and PEs.......................9 5.2. PW redundancy between n-PEs..............................10 5.3. PW redundancy in Bridge Module Model.....................11 6. Design considerations.........................................13 7. IANA Considerations...........................................13 8. Security Considerations.......................................13 9. Acknowledgments...............................................14 10. References...................................................14 10.1. Normative References....................................14 10.2. Informative References..................................14 Author's Addresses...............................................14 Intellectual Property Statement..................................15 Disclaimer of Validity...........................................16 Acknowledgment...................................................16 Muley et al. Expires September 5, 2007 [Page 2] Internet-Draft Pseudowire (PW) Redundancy) March 2007 1. Terminology o PW Terminating Provider Edge (T-PE). A PE where the customer- facing attachment circuits (ACs) are bound to a PW forwarder. A Terminating PE is present in the first and last segments of a MS- PW. This incorporates the functionality of a PE as defined in RFC3985 [3]. o Single-Segment Pseudo Wire (SS-PW). A PW setup directly between two T-PE devices. Each PW in one direction of a SS-PW traverses one PSN tunnel that connects the two T-PEs. o Multi-Segment Pseudo Wire (MS-PW). A static or dynamically configured set of two or more contiguous PW segments that behave and function as a single point-to-point PW. Each end of a MS-PW by definition MUST terminate on a T-PE. o PW Segment. A part of a single-segment or multi-segment PW, which is set up between two PE devices, T-PEs and/or S-PEs. o PW Switching Provider Edge (S-PE). A PE capable of switching the control and data planes of the preceding and succeeding PW segments in a MS-PW. The S-PE terminates the PSN tunnels of the preceding and succeeding segments of the MS-PW. o PW switching point for a MS-PW. A PW Switching Point is never the S-PE and the T-PE for the same MS-PW. A PW switching point runs necessary protocols to setup and manage PW segments with other PW switching points and terminating PEs o Active PW. A PW whose preferential status is set to Active and Operational status is UP. o Standby PW. A PW whose preferential status is set to Standby. 2. Introduction In single-segment PW (SS-PW) applications, protection for the PW is provided by the PSN layer. This may be an RSVP LSP with a FRR backup and/or an end-to-end backup LSP. There are however applications where the backup PW terminates on a different target PE node. PSN protection mechanisms cannot protect against failure of the target PE node or the failure of the remote AC. In multi-segment PW (MS-PW) applications, a primary and multiple secondary PWs in standby mode are configured in the network. The paths of these PWs are diverse and are switched at different S-PE Muley et al. Expires September 5, 2007 [Page 3] Internet-Draft Pseudowire (PW) Redundancy) March 2007 nodes. In these applications, PW redundancy is important for the service resilience. This document describes these applications and uses a new PW status bit defined in [7] to indicate the preferential forwarding status of the PW for the purpose of notifying the remote T-PE of the active/standby state of each PW in the redundancy set. This status bit is different from the operational status bits already defined in the PWE3 control protocol [2]. The PW with both local and remote operational UP status and local and remote preferential active status is selected to forward traffic. 3. Multi-homing Single SS-PW redundancy applications 3.1. One Multi-homed CE with single SS-PW redundancy The following figure illustrates an application of single segment pseudo-wire redundancy. |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnels-->| | | | V V V V | V AC +----+ +----+ AC V +-----+ | | PE1|==================| | | +-----+ | |----------|....|...PW1.(active)...|....|----------| | | | | |==================| | | CE2 | | CE1 | +----+ |PE2 | | | | | +----+ | | +-----+ | | | |==================| | | |----------|....|...PW2.(standby)..| | +-----+ | | PE3|==================| | AC +----+ +----+ Figure 1 Multi-homed CE with single SS-PW redundancy In Figure 1, CE1 is dual homed to PE1 and to PE3 by attachment circuits. The method for dual-homing of CE1 to PE1 and PE3 nodes and the used protocols such as Multi-chassis Link Aggregation Group (MC- LAG), are outside the scope of this document. PE2 has an attachment circuit from CE2. Two pseudo-wires pw1 and pw2 are established, one connects PE1 to PE2 and the other one connects PE3 to PE2. On PE2, PW1 has a higher priority than PW2 by local configuration. In case of MC-LAG Active/Standby status is derived by the Link Aggregation Muley et al. Expires September 5, 2007 [Page 4] Internet-Draft Pseudowire (PW) Redundancy) March 2007 Control protocol (LACP) negotiation which is used in determining the priority of the PW. In normal operation, PE1 and PE3 will advertise "Active" and "Standby" preferential forwarding status (apart from operational status) respectively to PE2. This status reflects the forwarding state of the two AC's to CE1. PE2 advertises preferential status of "Active" on both PW1 and PW2. As both the local and remote operational and administrative status for PW1 are UP and Active, traffic is forwarded over PW1 in both directions. On failure of AC to PE1, PE1 sends a PW status notification to PE2 indicating that the AC operational status changed to DOWN. It will also set the forwarding status of PW1 to "standby". PE3 AC will change preferential status to active and this status is also communicated to PE2 using the newly proposed forwarding status bit in the PW status TLV notification message. The changing of preferential status on PE3 due to failure of AC at PE1 is achieved by various methods depending of the used dual-homing protocol and is outside the scope of this draft. For example the MC-LAG control protocol changes the link status on PE3 to active. On receipt of the status notifications, PE2 switches the path to the standby pseudo-wire PW2 as the newly changed status turns PW2 as Active PW. Note in this example, the receipt of the operational status of the AC on the CE1- PE1 link is normally sufficient to have PE2 switch the path to PW2. However, the operator may want to trigger the switchover of the path of the PW for administrative reasons, i.e., maintenance, and thus the proposed PW forwarding active/standby bit is required to notify PE2 to trigger the switchover. Muley et al. Expires September 5, 2007 [Page 5] Internet-Draft Pseudowire (PW) Redundancy) March 2007 3.2. Multiple Multi-homed CEs with single SS-PW redundancy |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnels-->| | | | V V V V | V AC +----+ +----+ AC V +-----+ | |....|.......PW1........|....| | +-----+ | |----------| PE1|...... .........| PE3|----------| | | CE1 | +----+ \ / PW3 +----+ | CE2 | | | +----+ X +----+ | | | | | |....../ \..PW4....| | | | | |----------| PE2| | PE4|--------- | | +-----+ | |....|.....PW2..........|....| | +-----+ AC +----+ +----+ AC Figure 2 Multiple Multi-homed CEs with single SS-PW redundancy In the Figure 2 illustrated above both CEs, CE1 and CE2 are dual- homed with PEs, PE1, PE2 and PE3, PE4 respectively. The method for dual-homing and the used protocols such as Multi-chassis Link Aggregation Group (MC-LAG) are outside the scope of this document. Note that the PSN tunnels are not shown in this figure for clarity. However, it can be assumed that each of the PWs shown is encapsulated in a separate PSN tunnel. PE1 advertises the preferential status "active" and operational status "UP" for pseudo-wires PW1 and PW4 connected to PE3 and PE4. This status reflects the forwarding state of the AC attached to PE1. PE2 advertises preferential status "standby" where as operational status "UP" for pseudo-wires PW2 and PW3 to PE3 and PE4. PE3 advertises preferential status "standby" where as operational status "UP" for pseudo-wires PW1 and PW3 to PE1 and PE2. PE4 advertise the preferential status "active" and operational status "UP" for pseudo- wires PW2 and PW4 to PE2 and PE1 respectively. The method of deriving Active/Standby status of the AC is outside the scope of this document. In case of MC-LAG it is derived by the Link Aggregation Control protocol (LACP) negotiation. Thus by matching the local and remote preferential status "active" and operational status "Up" of pseudo-wire the active pseudo-wire is selected. In this case it is the PW4 that will be selected. Muley et al. Expires September 5, 2007 [Page 6] Internet-Draft Pseudowire (PW) Redundancy) March 2007 On failure of AC between the CE1 and PE1 the preferential status on PE2 is changed. Different mechanisms/protocols can be used to achieve this and these are beyond the scope of this document. For example the MC-LAG control protocol changes the link status on PE2 to active. PE2 then announces the newly changed preferential status "active" to PE3 and PE4. PE1 will advertise a PW status notification message indicating that the AC between CE1 and PE1 is operationally down. PE2 and PE4 checks the local and remote preferential status "active" and operational status "Up" and selects PW2 as the new active pseudo- wire to send traffic. In this application, because each dual-homing algorithm running on the two node sets, i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently, there is a need to signal the active status of the AC such that the PE nodes can select a common active PW path for end-to-end forwarding between CE1 and CE2. 4. Multi-homing MS-PW redundancy applications 4.1. Multi-homed CE with MS-PW redundancy The following figure illustrates an application of multi-segment pseudo-wire redundancy. Native |<-----------Pseudo Wire----------->| Native Service | | Service (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) | V V V V V V | | +-----+ +-----+ +-----+ +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ | |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| | | | | |=========| |=========| | | | | CE1| +-----+ +-----+ +-----+ | | | | |.| +-----+ +-----+ | CE2| | | |.|===========| |=========| | | | | | |.....PW2-Seg1......|.PW2-Seg2......|-------| | +----+ |=============|S-PE2|=========|T-PE4| | +----+ +-----+ +-----+ AC Figure 3 Muti-homed CE with MS-PW redundancy In Figure 3, the PEs that provides PWE3 to CE1 and CE2 are Terminating-PE1 (T-PE1) and Terminating-PE2 (T-PE2) respectively. A PSN tunnel extends from T-PE1 to switching-PE1 (S-PE1) across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PW1 and PW2 are used to connect the attachment circuits (ACs) between T- Muley et al. Expires September 5, 2007 [Page 7] Internet-Draft Pseudowire (PW) Redundancy) March 2007 PE1 and T-PE2. Each PW segment on the tunnel across PSN1 is switched to a PW segment in the tunnel across PSN2 at S-PE1 to complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore the PW switching point. PW1 has two segments and is active pseudo- wire while PW2 has two segments and is a standby pseudo-wire. This application requires support for MS-PW with segments of the same type as described in [6]. The operation in this case is the same as in the case of SS-PW. The only difference is that the S-PW nodes need to relay the PW status notification containing both the operational and forwarding status to the T-PE nodes. 4.2. Single Homed CE with MS-PW redundancy This is the main application of interest and the network setup is shown in Figure 4 Native |<------------Pseudo Wire------------>| Native Service | | Service (AC) | |<-PSN1-->| |<-PSN2-->| | (AC) | V V V V V V | | +-----+ +-----+ +-----+ | +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ | |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| | | CE1| | |=========| |=========| | | CE2| | | +-----+ +-----+ +-----+ | | +----+ |.||.| |.||.| +----+ |.||.| +-----+ |.||.| |.||.|=========| |========== .||.| |.||...PW2-Seg1......|.PW2-Seg2...||.| |.| ===========|S-PE2|============ |.| |.| +-----+ |.| |.|============+-----+============= .| |.....PW3-Seg1.| | PW3-Seg2......| ==============|S-PE3|=============== | | +-----+ Figure 4 Single homed CE with multi-segment pseudo-wire redundancy In Figure 4, CE1 is connected to PE1 in provider Edge 1 and CE2 to PE2 in provider edge 2 respectively. There are three segmented PWs. A primary PW, PW1, is switched at S-PE1. A standby PW, PW2, which is switched at S-PE2 and has a priority of 1. Finally, another standby PW, PW3, is switched at S-PE3 and has a priority of 2. This means T- PE1 and T-PE2 will select PW1 over PW2, and PW2 over PW3 if all of them are in the UP state. Moreover, a T-PE node will revert back to the primary PW, PW1, whenever it comes back up. Muley et al. Expires September 5, 2007 [Page 8] Internet-Draft Pseudowire (PW) Redundancy) March 2007 The intent of this application is to have T-PE1 and T-PE2 synchronize the transmit and receive paths of the PW over the network. In other words, both T-PE nodes will transmit over the PW segment which is switched by the same S-PE. This is desirable for ease of operation and troubleshooting. Since there is no multi-homing running on the AC, the T-PE nodes would advertise 'Active" for the forwarding status. However, this does not guarantee that the paths of the PW are synchronized because for example of mismatch of the configuration of the PW priority in each T-PE. Thus, there is a need to devise an augmented mechanism to achieve the desirable synchronization of the PW paths and to add the ability to have a T-PE instruct the remote T-PE to perform a coordinated switchover to a common Active path. The solution required for this specific scenario is left for further study. 5. Multi-homing VPLS applications 5.1. PW redundancy between MTU-s and PEs Following figure illustrates the application of use of PW redundancy in spoke PW by dual homed MTU-s to PEs. |<-PSN1-->| |<-PSN2-->| V V V V +-----+ +-----+ |MTU-s|=========|PE1 |======== |..Active PW group....| H-VPLS-core | |=========| |========= +-----+ +-----+ |.| |.| +-----+ |.|===========| |========== |...Standby PW group|.H-VPLS-core =============| PE2|========== +-----+ Figure 5 Muti-homed MTU-s in H-VPLS core In Figure 5, MTU-s is dual homed to PE1 and PE2. The active spoke PWs from MTU-s are connected to PE1 while the standby PWs are connected to PE2. PE1 and PE2 are connected to H-VPLS core on the other side of network. MTU-s communicates the status of its member PWs for a set of VSIs having common status Active/Standby. It is signaled using PW grouping with common group-id in PWid FEC Element or Grouping TLV in Muley et al. Expires September 5, 2007 [Page 9] Internet-Draft Pseudowire (PW) Redundancy) March 2007 Generalized PWid FEC Element as defined in [2] to PE1 and PE2 respectively, to scale better. MTU-s derives the status of the PWs based on local policy configuration. Whenever MTU-s performs a switchover, it sends a wildcard Notification Message to PE2-rs for the Standby PW group containing PW Status TLV with PW Standby bit cleared. On receiving the notification PE-2 unblocks all member PWs identified by the PW group and state of PW group changes from Standby to Active. It is to note that in this mechanism unless there is a failure to unblock PW groups at PE2, always a single wildcard Notification Message is exchanged per PW group. On failure to unblock the PW group PE2 may have to send Notifications of the fatal error per PW as PW grouping is unidirectional as per [2](in this case from MTU-s to PE2 only). The status notification defined here is similar to Topology Change Notification in RSTP controlled IEEE Ethernet Bridges in [8] but restricted over a single hop. When the mechanism defined in this document is implemented, PE devices are aware of switchovers at MTU-s and could generate MAC Withdraw Messages to trigger MAC flushing within the H-VPLS full mesh. By default, MTU-s devices should still trigger MAC Withdraw messages as currently defined in [5] to prevent two copies of MAC withdraws to be sent (one by MTU-s and another one by PEs). Mechanisms to disable MAC Withdraw trigger in certain devices is out of the scope of this document. 5.2. PW redundancy between n-PEs Following figure illustrates the application of use of PW redundancy for dual homed connectivity between PE devices in a ring topology. Muley et al. Expires September 5, 2007 [Page 10] Internet-Draft Pseudowire (PW) Redundancy) March 2007 +-------+ +-------+ | PE1 |=====================| PE2 |====... +-------+ PW Group 1 +-------+ || || VPLS Domain A || || VPLS Domain B || || +-------+ +-------+ | PE3 |=====================| PE4 |==... +-------+ PW Group 2 +-------+ Figure 6 Redundancy in Ring Topology In Figure 6, PE1 and PE3 from VPLS domain A are connected to PE2 and PE4 in VPLS domain B via PW group 1 and group 2. Each of the PE in respective domain is connected to each other as well to form the ring topology. Such scenarios may arise in inter-domain H-VPLS deployments where RSTP or other mechanisms may be used to maintain loop free connectivity of PW groups. Ref.[5] outlines about multi-domain VPLS service without specifying how redundant border PEs per domain per VPLS instance can be supported. In the example above, PW group1 may be blocked at PE1 by RSTP and it is desirable to block the group at PE2 by virtue of exchanging the PW preferential status as Standby. How the PW grouping should be done here is again deployment specific and is out of scope of the solution. 5.3. PW redundancy in Bridge Module Model Muley et al. Expires September 5, 2007 [Page 11] Internet-Draft Pseudowire (PW) Redundancy) March 2007 --------------------------+ Provider +------------------------ . Core . +------+ . . +------+ | n-PE |======================| n-PE | Provider | (P) |---------\ /-------| (P) | Provider Access +------+ ._ \ / . +------+ Access Network . \/ . Network (1) +------+ . /\ . +------+ (2) | n-PE |----------/ \--------| n-PE | | (B) |----------------------| (B) |_ +------+ . . +------+ . . -------------------------+ +------------------------ Figure 7 Bridge Module Model In Figure 7, two provider access networks, each having two n-PEs, where the n-PEs are connected via a full mesh of PWs for a given VPLS instance. As shown in the figure, only one n-PE in each access network is serving as a Primary PE (P) for that VPLS instance and the other n-PE is serving as the backup PE (B).In this figure, each primary PE has two active PWs originating from it. Therefore, when a multicast, broadcast, and unknown unicast frame arrives at the primary n-PE from the access network side, the n-PE replicates the frame over both PWs in the core even though it only needs to send the frames over a single PW (shown with == in the figure) to the primary n-PE on the other side. This is an unnecessary replication of the customer frames that consumes core-network bandwidth (half of the frames get discarded at the receiving n-PE). This issue gets aggravated when there is three or more n-PEs per provider, access network. For example if there are three n-PEs or four n-PEs per access network, then 67% or 75% of core-BW for multicast, broadcast and unknown unicast are respectively wasted. Muley et al. Expires September 5, 2007 [Page 12] Internet-Draft Pseudowire (PW) Redundancy) March 2007 In this scenario, Standby PW signaling defined in [7] can be used among n-PEs that can disseminate the status of PWs (active or blocked) among themselves and furthermore to have it tied up with the redundancy mechanism such that per VPLS instance the status of active/backup n-PE gets reflected on the corresponding PWs emanating from that n-PE. 6. Design considerations While using the pseudo-wire redundancy application, the T-LDP peers MUST negotiate the usage of PW status TLV. The status code defined below carries the active/standby preferential forwarding status of the pseudo-wire. The pseudo-wire is only considered active pseudo- wire only when both the local PW status and the remote PW status indicate preferential status "active" and operational status as Up. Any other status combination keeps the pseudo-wire in standby mode. The pseudo-wires are given different preference level. In case of network failure, the PE/T-PE will first switch to the standby PW with a higher preference. Although the configuration of the pseudo-wire preference is matter of local policy matter and is outside the scope of this, it is desirable to have the preferences configured on both end points be similar. In mis-configuration, a method to force the synchronization of the PW paths is required is for further study. While in standby status, a pseudo-wire can still receive packets in order to avoid black holing of the in-flight packets during switchover. The application of Standby PWs in VPLS redundancy is OPTIONAL and is a tradeoff between savings in bandwidth/resources and traffic switchover time on PW state change from Standby to Active. Implementations SHOULD provide facilities to administratively enable or disable this mechanism based on whether the resulting switchover time is acceptable to SLA between a provider and its customers or not. The target environment of the current solution is H-VPLS redundancy scenarios defined in [5] and is equally applicable to other possible VPLS redundancy scenarios. 7. IANA Considerations This document does not require any IANA assignments or action. 8. Security Considerations This document uses the LDP extensions that are needed for protecting pseudo-wires. It will have the same security properties as in LDP [4] and the PW control protocol [2]. Muley et al. Expires September 5, 2007 [Page 13] Internet-Draft Pseudowire (PW) Redundancy) March 2007 9. Acknowledgments The authors would like to thank Vach Kompella, Kendall Harvey, Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus and Philippe Niger for their valuable comments and suggestions. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Martini, L., et al., "Pseudowire Setup and Maintenance using LDP", RFC 4447, April 2006. [3] Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", March 2005 [4] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001 [5] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN Service (VPLS) Using LDP Signalling", RFC 4762, January 2007 10.2. Informative References [6] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3- segmented-pw-02.txt, March 2006. [7] Muley, P. et al., "Preferential forwarding status bit", draft- muley-dutta-pwe3-redundancy-bit-00.txt, August 2007. [8] IEEE Std. 802.1D-2003-Media Access Control (MAC) Bridges. Author's Addresses Praveen Muley Alcatel 701 E. Middlefiled Road Mountain View, CA, USA Email: Praveen.muley@alcatel.com Muley et al. Expires September 5, 2007 [Page 14] Internet-Draft Pseudowire (PW) Redundancy) March 2007 Mustapha Aissaoui Alcatel 600 March Rd Kanata, ON, Canada K2K 2E6 Email: mustapha.aissaoui@alcatel.com Matthew Bocci Alcatel Voyager Place, Shoppenhangers Rd Maidenhead, Berks, UK SL6 2PJ Email: matthew.bocci@alcatel.co.uk Pranjal Kumar Dutta Alcatel-Lucent Email: pdutta@alcatel-lucent.com Marc Lasserre Alcatel-Lucent Email: mlasserre@alcatel-lucent.com Jonathan Newton Cable & Wireless Email: Jonathan.Newton@cwmsg.cwplc.com Olen Stokes Extreme Networks Email: ostokes@extremenetworks.com Hamid Ould-Brahim Nortel Email: hbrahim@nortel.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of Muley et al. Expires September 5, 2007 [Page 15] Internet-Draft Pseudowire (PW) Redundancy) March 2007 such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Muley et al. Expires September 5, 2007 [Page 16]