Network Working Group Ping Pan Internet Draft (Hammerhead Systems) Expiration Date: July 2006 February 2006 Pseudo Wire Protection draft-pan-pwe3-protection-02.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. Copyright Notice Copyright (C) The Internet Society (2006). 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. Abstract This document describes a mechanism that helps to protect and recover user traffic when carried over pseudo-wires. The mechanism requires some minor modification to the existing pseudo-wire setup procedure, and is Pan [Page 1] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 fully backward compatible. The proposed mechanism allows the network operators to setup one or multiple backup pseudo-wires to protect a working pseudo-wire. Upon network failure, user traffic can be switched over to the next "best" pseudo-wire base on preference levels. This document first describes the motivation of the work base on the discussions with a number of carriers. Then we define the protocol extension itself. 1. Specification of Requirements 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. 2. Terminology The reader is assumed to be familiar with the terminology in [LDP], [PW-CTRL] and [MHOP-PW]. The new terms are the following: Working Pseudo-wire: A pseudo-wire that carries user traffic, and may be protected by one or multiple associated backup pseudo-wires. Backup Pseudo-wire: A pseudo-wire that is used to re-route user traffic from a working pseudo-wire at head-end. 3. Introduction Pseudo-wires have been deployed by a number of networks to carry customer layer-2 data traffic. Each Layer-2 data flow (or Attachment Circuit) is mapped to a pseudo-wire. Pseudo-wire setup, maintenance and packet encapsulation have been extensively described in a number of IETF PWE3 drafts [PWE3-CTRL, PWE3-TRANSPORT]. Recently, several carriers have requested that, when offered as a service, pseudo-wires need to possess the same protection and redundancy capabilities that have been deployed in transport networks. In this draft, we extend the LDP pseudo-wire proposal [PWE3-CTRL] to support protection and restoration operation. Pan [Page 2] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 Why is such work necessary? When it comes to traffic protection, the carriers need to ensure traffic protection on every network segment and in every layer of the network. Just because most of the pseudo-wire traffic will go through MPLS LSP's, we cannot therefore make the assumption that user traffic will be protected via MPLS Fast-Reroute [MPLS-FRR] or RSVP path protection. Here are some of the deployment scenario where pseudo-wire protection can be critically important: 3.1. Access Networks Pseudo-wire has been in deployment for multi-service data access. One reason is that pseudo-wire enables data aggregation, which in turn improves bandwidth utilization. In a typical metro network access location (Hub or CO), the statistical multiplexing gain is approximately 3-4 [ATT-REPORT]. The earlier user flows get aggregated, the better bandwidth utilization will be gained by the carriers, especially at the access locations where bandwidth is still expensive. More importantly, pseudo-wire provides a common data transport layer, where all layer-2 packets can be processed uniformly at provider edge. This enables the carriers to migrate from the traditional layer-2 (ATM or Frame Relay) circuits into high-speed Ethernet without service distraction. A common deployment scenario can be shown as the following: +--------+ +------------+ AC's | |====== Ethernet ======| | AC's or PW's ------| Access | | Service |-------------- | Device |====== DS3 ===========| Aggregator | +--------+ +------------+ Figure-1: Pseudo-wire network access Note that given the size of access networks, the cost of access device and access link management are some of the key deployment considerations, such that the access devices may not be IP routers, and the extensive IP routing and MPLS signaling (such as RSVP-TE) may be not applied in this part of the network. In this part of the network, one method may be to run pseudo-wires Pan [Page 3] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 over the access links, and conduct traffic protection at per-pseudo- wire level. 3.2. Metro Networks First of all, many of the MPLS-enabled metro networks today do not operate with RSVP-TE, which MPLS Fast-Reroute is based on. Secondly, many of the metro networks have already deployed pseudo-wires in one form or another (such as VPLS). Thus, pseudo-wire traffic protection becomes vital. Another issue is that given the heterogeneous nature and subsequent complexity in network topology, the metro networks may not be able to guarantee parallel MPLS tunnels between two edge nodes with the same bandwidth. In this case, pseudo-wire protection may be the only method for user traffic. +-----+ Tunnel-1 +-----+ AC's | |====== OC-48 ========| | AC's <------>| PE1 | | PE2 |<------> | | Tunnel-2 | | | |======= OC-3 ========| | +-----+ +-----+ Figure-2: Bandwidth Mismatch In Figure-2, there exist two parallel tunnels (LSP's) between two PE's with different link capacity. Whenever the bandwidth on a protecting link is smaller than that on the working link, we may run into trouble during protection and restoration. In the example, let's assume that both tunnels are MPLS LSP's. Network operators have enabled MPLS fast-reroute to enable both LSP's protecting each other. From the PE's, a number of AC's are aggregated into the LSP's as pseudo-wires. Some AC's carry mission-critical data, while others transport best-effort data. If Tunnel-1 fails, all traffic on Tunnel-1 will be switched into Tunnel-2. However, since both tunnels have different bandwidth, mission-critical traffic could be dropped or delayed as a result of link congestion during switch- over. This problem can be easily resolved if each pseudo-wire has its own preference, which allows the pseudo-wires to preempt each other when Pan [Page 4] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 it becomes necessary. Also note that, since the pseudo-wires are always bi-directional, the preference assignment must be consistent on both ends of the pseudo-wires. 3.3. Inter-Carrier Environment Multi-segment pseudo-wire [MS-ARCH, MHOP-PW, Segmented-PW] has gained much traction in carrier networks recently. It allows pseudo-wire traffic to transport over multiple provider networks. Within each network, the type of the PSN tunnels may be different. And there is no guarantee that the PSN tunnels within each network or over the inter-provider links will be protected. The multi-hop pseudo-wires use target LDP to setup end-to-end (or edge-to-edge) connection, so the head-end nodes (T-PE's) are able to detect any network failure that may effect the pseudo-wires, and can reroute user traffic on per-pseudo-wire basis. +----------+ | | +------------>|Provider 2|-------------+ | | | | | +----------+ | | | | | | | | v +----+-----+ +----------+ +----------+ | | | | | | ====>|Provider 1|======>|Provider 3|===X===>|Provider 5|====> | | | | | | +----+-----+ +----------+ +----------+ | ^ | | | | | | | +----------+ | | | | | +------------>|Provider 4|-------------+ | | +----------+ Figure-3: Multi-segment PW in inter-provider networks For example, in Figure-3, a multi-hop pseudo-wire traverses through Pan [Page 5] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 Provider 1, 3 and 5. Say, the link between Provider 3 and 5 has failed. From the head-end the pseudo-wire can be re-routed through Provider 2 or 4. 3.4. Planned Traffic Switch-over Finally, the network operators need to have the ability to support planned traffic shifting. In Figure-2, there are two links between two PE's carrying a number of pseudo-wires. During network maintenance, carriers may decide to shift all traffic from a set of pseudo-wires from one link to another temporally without causing traffic disturbance to users. To support this operation, pseudo-wire protection can be manually triggered from the operators [NOTE1]. 4. Design Considerations 4.1. Signaling a Backup Pseudo-wire When operating in multi-domain environment, the working and backup pseudo-wires may arrive on the same PE nodes (S-PE's). To make the message processing possible, the backup pseudo-wires must at least satisfy the following criteria: 1. Unambiguously and uniquely identifying the backup pseudo-wire 2. Unambiguously associating working PW with their backups. Pseudo-wires can be identified via either FEC 128 (PWid) or FEC 129 (Generalized FEC). In latter case, each pseudo-wire can be uniquely identified as a pair of and . Since there are a number of limitations in using FEC 128 in multi-hop environment, we will support pseudo-wire protection with FEC 129 only. There are a number of options in making the backup pseudo-wires unique: 1. Assign a new for each backup pseudo-wire: To make the association of working and backup pseudo-wires at T-PE's, we may put some grouping information inside the . For example, we may use the first two bytes of the Global ID field in AII Type 2 [MHOP-PW] as the protection group ID. However, this will require the format change in all AII's, and cause potential backward compatibility problem. Pan [Page 6] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 2. Assign a new for all the working and backup pseudo-wires: However, when used in L2VPN's, the is used as "VPN ID" [L2VPN], which has an entirely different meaning from the pseudo-wire protection grouping. In our design, we will use an opaque "Protection TLV", in which each working and backup pseudo-wires will have a different identification (or reference ID). All working and backup pseudo-wires will have the same and . At pseudo-wire setup time, each working and backup pseudo-wires will get its own MPLS labels for packet forwarding. 4.2. Determination of Protection Path RSVP-TE messages uses Explicit Routing Object (ERO) to setup the LSP's. CR-LDP [RFC3212] has also defined an Explicit Route TLV to achieve the same identical purpose. One key advantage in using explicit routes is that the working and backup pseudo-wires do not have to traverse through the same routes (i.e. no fate-sharing). However, when operating in multi-domain environment, the carriers may not want to share network resource information among each other. In this case, there is no need to specify the explicit routing information during pseudo-wire setup. On the other hand, the edge nodes may interface with some multi- lateral policy servers to obtain the exact inter-domain routing information for backup pseudo-wires. In our design, by default, we do not require the use of explicit routes during working and backup pseudo-wire setup. Instead, we rely on the intermediate nodes (S-PE's) to provide the best possible routes for the pseudo-wires. For example, the protection information can be distributed during L2VPN auto-discovery process, such that the working and protection pseudo-wires will not traverse through the same set of PSN tunnels. Currently, inter-domain protection path determination is outside the scope of this proposal. Pan [Page 7] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 4.3. Protection Schemes There are three basic types of point-to-point protection: 1+1, 1:1 and 1:N. 1+1 is to transmit same traffic over two parallel links. The receiver will only pick traffic from one link at any given time. In event of failure, at least one of the links still carries the actual traffic. However, in packet networks, this is not the best way to consume link bandwidth. 1:1 protection is to use one connection to protect another connection. The most popular 1:1 protection is SONET APS. 1:N is a generalized version of 1:1. In 1:N, one connection is established to protection multiple other connections. MPLS Facility Backup is one such example. In pseudo-wire protection, each AC may have its own layer-2 characteristics that need to be maintained separately. When applying 1:N protection to these AC's, it would seem odd, for example, to setup one backup pseudo-wire to protect both a best-effort Ethernet VLAN connection as well as an ATM SPVC with CBR and VBR traffic requirements at the same time. However, the 1:N protection creates less flows in the network, and therefore puts less stress to the management plane. One way to create 1:N backup pseudo-wires is to stack a common MPLS label to all the backup pseudo-wires. This would require the allocation of two labels at pseudo-wire setup time. In our design, we shall consider both 1:1 and 1:N schemes. But we will only define the operation sequence and protocol extension for 1:1 initially. 4.4. Protection Types Pseudo-wire protection will support the following types: cold, warm and hot standby. 4.4.1. Cold Standby This is a common method in optical transport network, where the nodes will only negotiate and establish backup pseudo-wires after the detection of network failure. Pan [Page 8] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 This type of protection can be implemented with the existing specification [PW-CTRL, MHOP-PW]. Upon the detection of network failure, the PE nodes will re-negotiate another pseudo-wire, and transmit packets over. The protection effectiveness depends on how fast two edge nodes can react to network failure and process control messages after the failure. 4.4.2. Warm Standby The edge nodes will negotiate backup pseudo-wires and exchange labels prior to any network failure. However, data forwarding path will not be programmed for label processing and QoS enforcement until after the detection of network failures. Such practice and requirement come from traditional transport carriers. In SONET/SDH networks, switches reserve the protection time slots ahead of time. Upon the detection of network failure, the nodes "wake-up" the protection connections. 4.4.3. Hot Standby This is the most efficient protection method. The protecting pseudo-wires are established before any network failure. This is also known as "make-before-break". Upon the detection of network failure, the edge nodes will switch data traffic into pre-established backup pseudo-wires directly. The protection efficiency is therefore depending on the speed for switch-over, which is in the order of milliseconds. This is the default operation in our proposal. 5. LDP Extension PW protection is based on [PW-CTRL], [LDP] and [MHOP-PW]. PW label binding uses targeted LDP, where two edge nodes first establish an LDP session using the Extended Discovery mechanism described in [LDP]. PW's are initiated via LDP Label Mapping messages. Each message contains a FEC TLV, a Label TLV, and some optional TLVs. We only support the Generalized ID FEC during the proposed operation. PW protection operates under the assumption that there exists more than one route between a pair of PE's to transport data traffic, as shown in Figure-3. Between PE1 and PE2, there may exist one or multiple provider networks, as described in [MS-ARCH]. Pan [Page 9] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 +-------+ +---------+ AC | | Working PW | | AC ---- +-+--+--O=======R0========O--+---+------- | | | | | | | | | | | | Backup PW-1 | | | | | | +--O=======R1========O--+ | | | | | | | | | | ... ... | | | | | | | | | | | Backup PW-N | | | | +-----O=======Rn========O------+ | | | | | +-------+ +---------+ PE1 PE2 Figure-4: PW Protection Example For each working PW, the PE's can setup one or multiple backup PW's. The procedure on setting up the working and backup PW's is the same as the one for regular PW's [PW-CTRL, MHOP-PW]. The only difference is that during PW initiation, a Protection TLV will be included in the mapping messages. The Label Mapping messages will be sent over multiple routes between two PE's. In case of multi-hop, the messages may be processed at multiple provider edge nodes. All working and backup PW's share the same attachment circuit information. The PE's will only transmit and receive data traffic over the PW that has the highest preference level. During network failure, the PE's will switch-over traffic into the PW that has the next highest preference level. After network recovery, the PE's will revert back to the previous PW. 5.1. The PROTECTION TLV Pan [Page 10] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Protection tlv (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Setup Pref Lvl | Hold Perf Lvl |Protection Type| Scheme | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference ID | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - U bit (always set) The PE nodes may not support the protection feature at the same time. On the node that does not support the PROTECTION TLV, only working pseudo-wire will be established. In case of network failure, no fast switch-over will be available. - Protection tlv The value of the new tlv type needs to be allocated by IANA. - Setup Preference Level The preference level with respect to initiate a PW. The value of 0 is the highest. The Setup Preference Level is used in deciding whether this PW can preempt another PW. - Holding Preference Level The preference level with respect to maintain a PW. The value of 0 is the highest. The Holding Preference Level is used in deciding whether this PW can be preempted by another PW. - Protection Type Currently we have defined the following values: Hot Standby: 0 Warm Standby: 1 The default value is 0 (Hot Standby). - Scheme Pan [Page 11] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 Currently, this can be one of the following: 1:1 protection: 0 1:N protection: 1 The default value is 0 (1:1 protection) - Reference ID This is assigned by the pseudo-wire originating nodes (T-PE's). The working and backup pseudo-wires must have a different value. This is used by the S-PE's during PW setup. - Flags This field contains the protection information used by the intermediate PEÆs (S-PE's) during MHOP-PW operation. Currently, it has the following flags: 0x01 F-flag: Fate Sharing Allowed 0x02 B-flag: Bandwidth CAC Required When the F-flag is set, the working and backup pseudo-wires may share the same routes in the network when necessary. By default, this flag is set. When the B-flag is set, the S-PE's must perform CAC on the backup pseudo-wires. Otherwise, the S-PE's can send a notification message to the originator, and continue on with the backup PW setup. By default, this flag is set. With the Protection TLV, the operator can configure the protection mechanism that they prefer. Since the pseudo-wires are always bidirectional, exchanging protection information between two edge nodes will help to achieve a consistent protection behavior for each pseudo-wire. 5.2. Signaling Procedures PW protection is an extension to the PW control and maintenance draft [PW-CTRL]. It is to enable the network operators to setup working and backup pseudo-wires. Upon network failure, user traffic can be switched over to the next "best" pseudo-wire base on preference levels. Pan [Page 12] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 5.2.1. Head-end PE Operation As illustrated in Figure-4, the operator can first initiate the Working PW over route R0, and then initiate the Backup PW-1 over route R1, the Backup PW-2 over route R2, and so on and so forth. The Label Mapping messages for both working and backup PW's must have the same Generalized ID FEC (that is, the same , and AC interface data). However, they must have different Label and Protection TLV's. The Label TLV contains the label value to carry the actual data traffic over each PW. The Protection TLV provides details traffic protection information. Each PW must have different Reference ID's in the Protection TLV. The head-end PE's (T-PE's) should not initiate the backup PW's until the working PW is up and running. The T-PE's should keep track of the PW-SW-POINT TLV [Segmented-PW] for both working and backup pseudo-wires. The PW-SW-POINT TLV has the information on the intermediate hops that the PW's have traversed. For the backup PW's that do not allow fate-sharing, their PW-SW-POINT TLV should not over-lap with the working PW. For the backup PW's that do not need bandwidth guarantee, it does not need to carry the PW Bandwidth TLV during setup, and the B-Flag must always be off. Otherwise, the backup PW's must carry the same PW Bandwidth TLV as in the working PW. 5.2.2. Switched PE Operation In case of multi-hop PW's, the intermediate PE's (S-PEÆs) will perform the following checks when receiving a Label Mapping message: If it does not support the Protection TLV, it will ignore the TLV and precede the regular PW setup. For a particular PW, the S-PE will only accept the first arrived Label Mapping message (for working PW's) and ignore the subsequent ones (for backup PW's). If it supports the Protection TLV, the S-PE will compare the Reference ID on the PW's that share the same and . If there is an entry with the same Reference ID, the Label Message will be rejected. Otherwise, the S-PE will interface with either static or dynamic (i.e. BGP) routing table, and place the backup PW's on a next-hop route that is different from the working PW. If the F-flag (Fate Sharing Flag) is set, and the S-PE cannot find an Pan [Page 13] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 alternative next-hop, the backup PW will go through the same route as the working PW. If the flag is reset, the S-PE will reject the Label Mapping message and terminate the backup PW setup. 5.2.3. Tail-end PW Operation As shown in Figure-4, when PE2 receives a Label Mapping message, it will perform the following checks: If PE2 does not support the Protection TLV, it will ignore the TLV and precede the regular PW setup. PE2 can only setup one PW with PE1 per AC. PE2 will reply a Label Release Message to reject the extra PW's from PE1. PE2 should however notify PE1 by signaling the "Unknown TLV" status code. If PE2 supports the Protection TLV, it will process the rest of the mapping message. PE2 needs to check if it already has the PW's with the same attachment ID (PWid or the combination of AGI, SAII and TAII) in its database. On each PE, all PW's with the same attachment ID must have different preference level. In this case, PE2 will always reject the mapping message with the same preference level by replying a Label Release message. PE2 should notify PE1 with a "Duplicated Preference" status code. If PE2 decides to accept the Label Mapping message, then it has to make sure that a LSP is setup in the opposite direction (PE1->PE2). If no corresponding tunnel, it must initiate it by sending a Label Mapping message to PE1. Other than reversing the SAI and TAI in PW FEC, PE2 must send the same Protection TLV back to PE1. 5.3. Consistent Protection Behavior PW's are bidirectional. Each PW must have the same protection behavior at both ends. Otherwise, a user traffic flow may have a hot-standby that can switch-over within 50 milliseconds on one direction, but slow to recover on the other direction. If the PW is initiated from one end (PE1), the other end (PE2) must comply by replying a Label Mapping message with the same Protection TLV. However, it is possible that the operators are to setup a PW from both ends (PE1 and PE2) manually. In this case, if the protection parameters are inconsistent, the PE's need to reject the PW setup, and notify the operators with a "Mismatched Preference" Pan [Page 14] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 status code. 5.4. Preference Levels Not all PW's are created equal. Some will have higher preference level than the others. In case of network failure, the PE's will first protect the PW's with a higher preference. Some PW's may have network resource (such as, bandwidth) association. The PE's will reject some of the backup PW's during the setup, when there is no enough resource available on a backup link. PE's will notify the operators with an "Out of Backup Resource" status code. 6. Security Considerations This document specifies the LDP extensions that are needed for protecting pseudo-wires. It will have the same security properties as in [LDP] and [PW-CTRL]. 7. IANA Considerations We have defined the following protocol extension: 7.1. PW Protection TLV This is a new LDP TLV type. 7.2. PW Status Code The edge nodes need to information each other in a number of error conditions. Several PW status code need to be defined: 0x00000XYZ "Duplicated preference levels" 0x00000XYZ "Mismatched Preference" 0x00000XYZ "Out of Backup Resource" 0x00000XYZ "Working and backup PW's share the same route" Pan [Page 15] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 8. Acknowledgement We are grateful for the opportunities of discussing this idea with various people in the past several months both inside Hammerhead Systems and in various carriers. 9. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. 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 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. 10. 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 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. Pan [Page 16] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 11. 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 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. 12. Normative Reference [PW-CTRL] L. Martini, et al, "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-14.txt [LDP] L. Andersson, et al, "LDP Specification", draft-ietf-mpls- rfc3036bis-00.txt [MPLS-FRR] P. Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC4090 [ATT-REPORT] T. Afferton, et al, "Packet Aware Transport for Metro Networks", IEEE Network Magazine, April 2004. [Segmented-PW] Martini et.al. " Segmented Pseudo Wire", draft-ietf- pwe3-segmented-pw-00.txt, July 2005 [MHOP-PW] Florin Balus et. al. ôDynamic Placement of Multi Segment Pseudo Wiresö, draft-ietf-pwe3-dynamic-ms-pw-00.txt [MS-ARCH] M Bocci et. al. ôAn Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edgeö, draft-ietf-pwe3-ms-pw-arch-00.txt [NOTE1] Other mechanism may also be applicable for planned shutdown. See ôLDP graceful restart for planned outages (draft-minei-mpls-ldp- planned-restart-01.txt)ö by Ina Minei, et al. [L2VPN] Rosen et. al. ôProvisioning, Autodiscovery, and Signaling in L2VPNsö, draft-ietf-l2vpn-signaling-06.txt Pan [Page 17] Internet Draft draft-pan-pwe3-protection-02.txt February 2006 13. Informative References None 14. Author Information Ping Pan Hammerhead Systems 640 Clyde Court Mountain View, CA 94043 e-mail: ppan@hammerheadsystems.com Pan [Page 18]