Network Working Group Wei.Cao Internet Draft Mach. Chen Expires: May 2008 Huawei Co,.LTD Category: Standards Track November 17, 2007 Head Node Protection Extensions to RSVP-TE for LSP Tunnels draft-cao-mpls-te-p2mp-head-protection-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 May 17, 2008. Abstract Protection methods for RSVP-TE P2MP LSP have been described in [TE- FRR]([RFC4090]) and [P2MP-TE-Bypass], but there are no solutions to protect an RSVP-TE P2MP head node. This document discusses the scenario for RSVP-TE P2MP LSP head node failure protection and describes the protection procedures. RSVP-TE extensions for such protection are also described. To protect the head node, a backup head node is appointed which forwards traffic to downstream LSRs of the LSP when the protected head node fails. The backup head node is not on the path of protected LSP. Similar to [TE-FRR] there are two methods that can apply: one- Expires May 17, 2008 [Page 1] Internet-Draft November 2007 to-one backup and facility backup. Only one-to-one backup is described in detail here, facility backup will be discussed in a future version of this draft. 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. Table of Contents 1. Terminology.................................................3 2. Introduction................................................3 2.1. Motivation.............................................3 2.2. Head Node Protection Scenario...........................4 2.2.1. Solution Overview..................................5 2.3. Applicability Statement and Implementation Considerations7 2.3.1. Topology Limitation................................7 2.3.2. Implementation Consideration.......................8 3. Extensions to RSVP-TE........................................8 3.1. HEAD_PROTECTION Object..................................8 3.1.1. HEAD_PROTECTION for IPv4 address...................8 3.1.2. HEAD_PROTECTION for IPv6 address...................9 3.1.3. SESSION_ATTRIBUTE Flags...........................11 4. Behavior of MHN and BHN.....................................11 4.1. Behavior of MHN........................................11 4.1.1. Signaling BHN for Head Protection.................11 4.1.2. Revert back to MHN from BHN Behavior..............12 4.2. Behavior of BHN........................................13 4.2.1. Signaling BHN-Detour and Protection Procedures.....13 4.2.2. Revertive Procedures for BHN......................14 4.3. Protection Teardown....................................14 4.3.1. Protection Teardown...............................14 5. Behavior of Merge Nodes.....................................15 6. Behavior of All Other LSRs..................................15 7. Security Considerations.....................................15 8. IANA Considerations........................................15 9. Conclusions................................................15 10. Acknowledgments...........................................15 11. References................................................16 11.1. Normative References..................................16 Author's Addresses............................................16 Intellectual Property Statement................................16 Disclaimer of Validity........................................17 Copyright Statement...........................................17 Cao, et al. Expires May 17, 2008 [Page 2] Internet-Draft November 2007 1. Terminology LSR: Label-Switch Router. In this document all LSRs should support RSVP-TE extensions for P2MP LSP. LSP: An MPLS Label-Switched Path. In this document, an LSP will always be an explicitly routed LSP. MHN: Major Head Node. MHN is the head node of the protected RSVP-TE P2MP LSP . BHN: Backup Head Node. BHN is the head-end of the backup LSP. When there is a node failure in MHN, BHN will take the charge of forwarding packets on the backup up LSP protecting the traffic. MP: Merge Point. In this document a MP is generally the one hop downstream neighbour to the MHN. PLR: Point of local repair 2. Introduction RSVP-TE P2MP LSP has been deployed and many real-time applications are running over such LSPs, so there is motivation to improve their reliability. Much work has already been done to provide protection in RSVP-TE P2MP. Fast Reroute [FRR] has been an important mechanism to improve network resiliency. But the methods proposed in [TE-FRR] and [P2MP-TE-Bypass] do not provide a mechanism for protecting an LSP's head node which is a key element for high availability. This document discusses the scenario for RSVP-TE P2MP LSP head node failure protection and describes procedures and RSVP-TE extensions for such protection. This work requires that the procedures defined in [RSVP](RFC2205), [RSVP-TE](RFC3209),[TE-FRR]and [RSVP-P2MP](RFC4985) MUST be followed. 2.1. Motivation Traditional protection methods use a backup LSP or bypass tunnel to forward the traffic. In the event of protected LSP failure, including link or node failure, PLR will take action to detour the packets from PLR to MP through a backup LSP or bypass tunnel. This requires PLR must be a node on the path of the protected LSP and must be upstream of the failure point. Such mechanisms work well for protecting transit links and transit LSRs but have no ability to protect the head node of the LSP because it has no upstream node. In real applications, head node failure will cause serious outages and consequently there is a strong motivation for reducing and providing Cao, et al. Expires May 17, 2008 [Page 3] Internet-Draft November 2007 protection from that risk. One possible solution today is 1+1 protection: deploying another P2MP tree from a different LSR to all receivers. Obviously this is not an efficient method; it will double bandwidth usage and require maintaining twice the forwarding states in the devices. So it is highly desirable to find another solution to this problem. 2.2. Head Node Protection Scenario When real-time applications are deployed, service providers (SP) always try to avoid service interruption. Failures are not predictable so backup is a necessary and effective solution. It is common for SP to deploy multiple servers (traffic sources) and/or multi-home the application servers to multiple edge routers. Below is a typical topology for such applications: +---[R1]--[R2]--[R3]---[L1]----[ReceiverA] [S1]-| \/ | \/ | /\ | /\ +---[R4]--[R5]--[R6]---[L2]----[ReceiverB] Figure 1. Source Multi-homing In Figure 1, [S1] is an application server; [Rx] and [Lx] are RSVP-TE P2MP LSP capable devices. [S1] is multi-homed to LSR [R1] and [R4]. If multicast packets are sent by [S1]they need to be transmitted to [L1] and [L2], a P2MP LSP (LSP1)starting at [R1] can be created with two sub-LSPs: [R1]->[R2]->[R3]-[L1] and [R1]->[R5]->[R6]->[L2]. Thus packets from [S1] can be received by [ReceiverA] and [ReceiverB]. If the SP wants to improve robustness, another P2MP LSP (LSP2) starting from [R4] can be created with two sub-LSPs: [R4]->[R5]->[R6]->[L2] and [R4]->[R2]->[R3]-[L1]. Packets from [S1] can reach [R1] and [R4] at the same time and be forwarded to L1 and L2 separately through LSP1 and LSP2. [L1] and [L2] may choose one LSP (Suppose it is LSP1) as the major path and the other one (LSP2) as a backup one. Only traffic from LSP1 will be forwarded to receivers and traffic from LSP2 will be dropped. In case of [R1] failure, [L1] and [L2] detect the failure of LSP1 and then begin to accept packets received from LSP2. There may be some variations from Figure 1. The SP may want to protect against LSR and application server failure. A common solution is to deploy two application servers separately connected to two LSRs. This is shown in Figure 2 below: Cao, et al. Expires May 17, 2008 [Page 4] Internet-Draft November 2007 [S1]-|---[R1]--[R2]--[R3]---[L1]----[ReceiverA] \/ | \/ /\ | /\ [S2]-|---[R4]--[R5]--[R6]---[L2]----[ReceiverB] Figure 2. Separate Sources [S1] and [S2] are connected to [R1] and [R2] respectively, and both application servers generate the same traffic stream to receivers. Packets from [S1] will go through LSP1 and packets from [S2] will go through LSP2. [L1] and [L2] may accept the packets from LSP1 and drop the packets from LSP2. The protection procedure is similar to the case depicted in Figure 1. The above methods work but are inefficient. The protection bandwidth is wasted most of time. LSRs have to maintain as much as twice amount of P2MP LSP state. In addition all leaves have to deal with duplicated traffic and monitor the LSP state to determine which LSP is the active one. Comparing the two P2MP LSPs in above cases, it is easy to be noticed that the only differences between them are the head nodes; LSP1 starts from [R1] and LSP2 starts from [R4], the transit nodes and leaves are same. So in such a topology if [R1] and [R4] cooperate together with one acting as a backup node for the other, then it is possible to build only one P2MP LSP while gaining head node protection. 2.2.1. Solution Overview Similar to FRR defined in [TE-FRR], the head node protection method described in this document also relies on backup LSPs. Since there is no "upstream neighbour" of the head node to detour the traffic around it, an LSR has to be assigned as a backup head node in the event of head node failure. We call the head node of protected LSP as MHN (major head node) and the backup one BHN (backup head node). A backup LSP or bypass tunnel to protect MHN will be built from BHN to all NHOP LSRs of MHN. These NHOP LSRs are merge points (MP) for the LSPs. To ensure all branches receive the traffic the MP set SHOULD include ALL NHOP LSRs of MHN. Multicast packets from the source arrive at both MHN and BHN. Under normal operating conditions MHN forwards this traffic while BHN drops it; there is no traffic on backup LSP or bypass tunnels to MPs. When BHN detects there is a failure of MHN it will begin to forward packets to the MPs. The MPs will recognize which LSP the packets belong to and forward the packets along the rest of the protected LSP. Cao, et al. Expires May 17, 2008 [Page 5] Internet-Draft November 2007 The precise mechanism used to discover the node failure of MHN is outside the scope of this document. One possible method is to use multiple, diversely routed, BFD connections between MHN and BHN. If all these BFD sessions are lost, BHN can reasonably infer that MHN has failed. A LSR eligible to be a BHN MUST satisy the follow conditions: - Traffic to be protected can be received by it from the source without transiting MHN; - BHN can build traffic tunnels to all MPs. That means BHN must on the "upstream side" of all MPs. Ideally BHN should have direct connection links to all MPs. - BHN should have the ability to discover MHN's node failure and discover the recovery of MHN from node failure. (How to detect the node failure is outside the scope of this document) - BHN SHOULD NOT be on the path of protected LSP. In Figure1, if the head node of LSP1 is to be protected, [R1] is the MHN and [R4] can be assigned as BHN. The MP set includes LSR [R2] and [R5]. The backup LSP against MHN failure starts from BHN to MPs. Theoretically the backup LSP can use unicast LSPs or P2MP TE LSPs. Consequently there are two options for building backup LSPs: - Rely on one or multiple unicast LSPs from BHN to the set of merge points. - Rely on single P2MP TE LSP from BHN to the set of merge points. There is a constraint on the routing of the backup LSP(s): the backup LSP(s) MUST NOT transit the MHN. Since the BHN has to send traffic to all downstream MPs, a P2MP TE LSP is a natural choice and is the approach discussed in this document. In figure 1 the backup P2MP TE LSP is composed of two sub- LSPs: [R4]->[R2] and [R4]->[R5]. The backup P2MP TE LSP is referred to as a LSP BHN-Detour. When a failure occurs in the MHN ([R1]), the BHN ([R4]) detects the failure and begins transmitting traffic on to the BHN detour along links [R4]->[R2] and [R4]->[R5], using the label received from the MPs ([R2] and [R5])when it created the BHN-Detour. While [R4] is Cao, et al. Expires May 17, 2008 [Page 6] Internet-Draft November 2007 using the BHN-Detour it recognizes the multicast traffic and performs the MPLS encapsulation. Merge points receive the detoured traffic from BHN and merge them to the protected LSP. From the view of MPs, the process is the same as for link failure protection. Service interruption is not only caused by failure but may be caused by regular operations, such as hardware upgrade or software patch installation. Such operation is planned by the SP and the outage of the node can be predicted. This kind of operation is referred to as Planned-Maintenance (PM). The head protection method described in this document can also be used in this scenario. For example, in figure1, if [R1] has to stop forwarding due to some operational reason, [R1] can assign [R4] as BHN and after [R4] has built the BHN- Detour R1 can be removed from service and traffic transmitted through the BHN-Detour. After the maintenance of [R1] has been performed it can be returned to service. Head protection is a valuable protection against failure and a useful tool for normal network operation. Since head protection is performed by two LSRs, there are many important differences between [TE-FRR] and head protection. The fundamental difference between [TE-FRR] and head-node protection is how the PLR/BHN is informed of the details of the protected LSP. In [TE-FRR], PLR will receive PATH message sent by the head node and PLR will get all information about the protected LSP and process the relevant RSVP extensions. BHN is not on the path of the Protected LSP and so extra messages must be sent by MHN to BHN to convey this information. One other difference is that all LSRs on the path of P2MP LSP must be periodically refreshed by a PATH message, in the case of MHN failure, BHN must generate and send PATH messages to all downstream LSPs as if these messages were sent by the MHN. 2.3. Applicability Statement and Implementation Considerations 2.3.1. Topology Limitation This document describes a mechanism that works only with the topology constraint that a suitable backup head node exists. A suitable backup head node must satisfy the requirements listed in section 2.2.1. It is common to construct the topologies discussed in 2.2 in high availability environments and these constraints are not a significant additional burden in the deployment of head-node protection. Cao, et al. Expires May 17, 2008 [Page 7] Internet-Draft November 2007 2.3.2. Implementation Consideration Head node protection should be compatible with the existing protocols in so far as is possible. Some considerations/requirements are listed bellow: - Inherit existing protocol extensions: the new method should reuse existing protocol extensions defined in [TE-FRR] as much as possible; the new method should be backward compatible with current mechanisms. Ideally, only MHN and BHN should be upgraded and MPs and others LSR SHOULD be kept unchanged. - When a protection action is taken, as few nodes as possible should be affected. There should be no need to affect any nodes downstream of a MP. - After a protection switch has occured the BHN operates in an indentical manner to the old head node; it refreshes and processes all feedback from downstream LSRs which, with the exception of the MP, are unaware of the change from MHN to BHN. 3. Extensions to RSVP-TE This document defines an additional object, which is referred to as a HEAD_PROTECTION object. This new object is backward compatible with LSRs that do not recognize it. The new object is carried in RSVP PATH and RESV messages. 3.1. HEAD_PROTECTION Object The HEAD_PROTECTION object is used to exchange information between MHN and BHN. MHN uses this object to specify which LSR is BHN and advertise essential information about a protected LSP. BHN and MHN MUST NOT forward this object to their downstream LSRs. Ideally MHN and BHN are directly connected. If MHN is not directly connected with BHN, a tunnel should be created to transmit PATH/RESV message with HEAD_PROTECTION object. If tunnel is used, the HEAD_PROTECTION object will be invisible to transit LSRs. [RFC2746] describes transmission of RSVP messages over tunnels. 3.1.1. HEAD_PROTECTION for IPv4 address Class-Num: TBD Cao, et al. Expires May 17, 2008 [Page 8] Internet-Draft November 2007 C-Type: TBD 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | Protected_Head | +-------------+-------------+-------------+-------------+ | Backup_Head | +-------------+-------------+-------------+-------------+ | Flags | +-------------+ Protected_Head IPv4 address identifying the RSVP-TE LSP Head node. Any stable local address of the MHN can be used. Backup_Head IPv4 address identifying the LSR selected as BHN. Any stable local address of the BHN can be used. Flags 0x01(bit0): Head protection desired 0x02(bit1): Head protection available Bit0 is the lowest bit of the octet. 3.1.2. HEAD_PROTECTION for IPv6 address Class-Num TBD C-Type TBD Cao, et al. Expires May 17, 2008 [Page 9] Internet-Draft November 2007 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | Protected_Head | +-------------+-------------+-------------+-------------+ | Protected_Head (continued) | +-------------+-------------+-------------+-------------+ | Protected_Head (continued) | +-------------+-------------+-------------+-------------+ | Protected_Head (continued) | +-------------+-------------+-------------+-------------+ | Backup_Head | +-------------+-------------+-------------+-------------+ | Backup_Head (continued) | +-------------+-------------+-------------+-------------+ | Backup_Head (continued) | +-------------+-------------+-------------+-------------+ | Backup_Head (continued) | +-------------+-------------+-------------+-------------+ | Flags | +-------------+ Protected_Head An IPv6 128bits unicast address identifying the RSVP-TE LSP Head node. Any stable local address of the MHN can be used. Backup_Head An IPv6 128bits unicast address identifying the LSR selected as BHN. Any stable local address of the BHN can be used. Flags 0x01(bit0): Head protection desired 0x02(bit1): Head protection available Bit0 is the lowest bit of the octet. Cao, et al. Expires May 17, 2008 [Page 10] Internet-Draft November 2007 3.1.3. SESSION_ATTRIBUTE Flags The current SESSION_ATTRIBUTE object has several flags defined in it [RSVP_TE] and [TE_FRR]. To request head node protection the local protection desired, SE style desired and node protection desired flags should be set. 4. Behavior of MHN and BHN The head-end (MHN) of an RSVP-TE P2MP LSP determines whether head node protection is required and which LSR will be designated as backup head node (BHN). How MHN selects an LSR as BHN is out of the scope of this document. Manual configuration is an effective and obvious choice. MHN and BHN cooperate to setup the backup LSPs. To reduce the effect on other LSRs on the path of the P2MP tunnel, from the view of MP, BHN builds the backup LSP as if a link protection LSP between MHN and MP is being created. 4.1. Behavior of MHN If MHN decides to deploy head protection, all flags required for link protection should be set when MHN sends PATH messages. If one-to-one protection is desired, then MHN should include a FAST_REROUTE object and set "one-to-one backup desired" flag. There are two different procedures for MHN in head protection: - Signaling BHN and building BHN-Detour. - Revertive operation. After recovery from node failure, MHN should re-build RSVP-TE P2MP LSPs after which revertive switching MAY occur allowing MHN to assume its original role, i.e traffic is again sourced from MHN onto the first segment of the protected LSP and the use of BHN-Detour is discontinued. 4.1.1. Signaling BHN for Head Protection To build a BHN-Detour to protect the MHN the BHN must get information about the protected LSP. This includes: - Unambiguous and unique identification of the protected LSPs - Unique identification of the protected node ( MHN ) - Whether bandwidth protection is desired Cao, et al. Expires May 17, 2008 [Page 11] Internet-Draft November 2007 - Whether one-to-one protection or facility backup is desired. - Knowledge of which LSRs are merge points (that is the second hop LSRs of the P2MP LSP). BHN obtains this information from MHN using a PATH message containing the HEAD PROTECTION object defined in 3.1. If MHN decides to deploy head protection and selects a LSR as BHN, it MUST follow the behavior described bellow: - MHN records each PATH message sent to its down stream LSRs. MHN rebuilds PATH messages and inserts a HEAD PROTECTION object with "head protection desired" flag set. MHN may merge several original PATH messages into one PATH message to improve the efficiency, but MHN must not the change the flags and objects in original PATH messages. - MHN should fill the "protected head" field in HEAD_PROTECTION object with its own IP address, and fill "backup head" field with BHN's IP address. - MHN sends the PATH messages to BHN. If MHN and BHN are directly connected, the PATH message can be directly, otherwise, it should be sent through a tunnel. - If a topology change changes the MP then MHN should send an update PATH message to BHN immediately to indicate that fact. MHN sends the PATH message containing HEAD_PROTECION object and expects corresponding RESV message from BHN. After BHN has signaled the backup path, a RESV message with HEAD_PROTECTION object will be sent back to MHN by BHN as described in section 4.2.1. 4.1.2. Revert back to MHN from BHN Behavior - With head protection, traffic sent from MHN will be replaced by the traffic sent from BHN when MHN failure occurs. When MHN is recovers from failure, MHN SHOULD be able take the charge of sending traffic along the protected P2MP LSP again. The revertive switch SHOULD occur after the RSVP-TE P2MP LSP has been re- constructed. Some objectives are described here: Objectives: - All RSVP-TE P2MP LSPs being protected by BHN SHOULD be re- constructed by MHN. Cao, et al. Expires May 17, 2008 [Page 12] Internet-Draft November 2007 - LSPs reconstructed by MHN SHOULD have the same SESSION / SESSION_TEMPLATE attributes as original LSPs. - The revertive operation SHOULD be opaque to LSRs on the path of RSVP-TE LSP except MHN, BHN and MPs. - BHN SHOULD know the LSPs have been re-constructed and know when to stop forwarding the traffic. The detailed procedures will be defined in a later version of this document. 4.2. Behavior of BHN BHN is responsible for creating BHN-Detours to protect the head node and play the role of head node during MHN failure. In addition the BHN helps the MHN to re-construct protected LSPs after MHN recovers. There are two different procedures for BHN: - Signaling BHN-Detour and rerouting traffic for protection. - Revertive Procedures. 4.2.1. Signaling BHN-Detour and Protection Procedures As described in section 4.1.1, MHN periodically sends PATH messages with HEAD_PROTECTION object to BHN. By processing the PATH messages BHN identifies the protected P2MP LSP and calculates the backup LSP. BHN must follow the behavior described bellow: o Message handling: - BHN MUST check the SESSION object in PATH message. If BHN receives a PATH message with HEAD_PROTECTION Object from non-MHN LSR, it indicates that the BHN is on the path of a protected tunnel. BHN MUST discard this message and send a notification message (TBD) to the sender. - BHN MUST check the IP address in "backup head" in the HEAD_PROTECION object. If the BHN does not have such an IP address, BHN MUST send back notification to the BHN. - After check the validity of PATH message, BHN processes the objects in PATH message. BHN MUST record SESSION and Cao, et al. Expires May 17, 2008 [Page 13] Internet-Draft November 2007 SESSION_TEMPLATE objects to identify protected LSP tunnels. BHN also records all ERO/SERO and recognizes all MPs. o Signaling BHN-Detour - BHN can signal BHN-Detour in the way defined in [TE-FRR]. BHN can use one-to-on backup or facility backup method. From the viewpoint of the MPs, the backup LSP is used for link failure (MHN->MP) protection. - After the BHN-Detour is created, BHN send RESV message with "Head protection available" flag set to MHN, which informs MHN that BHN- Detour is ready. o Protection action - When BHN detects the MHN's node failure, BHN immediately forwards packet through backup LSP to MPs. - BHN MUST keep all attributes of the protected P2MP LSP. The SESSION and SESSION_ATTRIBUTE objects MUST remain unchanged. - BHN periodically sends PATH messages to all MPs to refresh the state of protected LSP. The downstream LSRs are unaware of the change. 4.2.2. Revertive Procedures for BHN As described in 4.1.2 it SHOULD be possible for a MHN to resume its normal role after recovery. Revertive switching from BHN to MHN will be described in a future version of this document. 4.3. Protection Teardown MHN can teardown head protection when necessary. 4.3.1. Protection Teardown The teardown procedure must be initiated by MHN. To initiate immediate explicit teardown MHN sends BHN a PATH Tear message containing a HEAD_PROTECTION object. This PATH message may contain SESSION and SESSION_TEMPLATE but no ERO/SERO objects. This informs BHN that all related states of the protected LSP should be removed. Cao, et al. Expires May 17, 2008 [Page 14] Internet-Draft November 2007 5. Behavior of Merge Nodes This document places no new requirements on MPs. MPs have the same behaviors described in [TE-FRR] and [P2MP-TE]. It should be noted that MPs may receive duplicate traffic during the switching period from MHN to BHN (PM scenario), and vice versa. MP's need to have the ability to robustly handle duplicate traffic; how they do so is out of the scope of this document and is vendor specific. 6. Behavior of All Other LSRs Behavior of other LSRs should be unchanged. 7. Security Considerations This document does not introduce new security issues. The security considerations pertaining to the original [RSVP-TE-FRR] remain relevant. Note that the head protection method requires that MHN and selected BHN trust RSVP messages received from each other. 8. IANA Considerations TBD 9. Conclusions Head node protection works not only for failure protection, but also helps the SP with planned maintenance. Service interruption is caused not only by network device failure but by administrative operation, such as line card upgrade or software patch installation. With the mechanisms described above, the SP can take LSP head end devices offline for maintenance and provide uninterrupted service by initiating a (manual) protection switch from MHN to BHN (and vice versa). 10. Acknowledgments We would like to thank Paul Doolan for his review and comments which have helped to clarify this draft. Cao, et al. Expires May 17, 2008 [Page 15] Internet-Draft November 2007 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RSVP-TE] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209. [RFC4461] S. Yasukawa et al., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC4461. [TE-FRR] Pan, Swallow, Atlas, et al., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC4090. [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC4985. Author's Addresses Wei Cao Huawei Technologies Room 201R, Kuike building, Shangdi, Haidian District of Beijing, P.R. China Email: caowayne@huawei.com Mach Chen Huawei Technologies Room 201R, Kuike building, Shangdi, Haidian District of Beijing, P.R. China Email: mach@huawei.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. Cao, et al. Expires May 17, 2008 [Page 16] Internet-Draft November 2007 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. 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. Cao, et al. Expires May 17, 2008 [Page 17]