Network Working Group Wei Cao Internet Draft Mach Chen Expires: January 2008 Huawei Technologies Co.,Ltd Category: Standards Track July 2, 2007 Head Node Protection Extensions to RSVP-TE for LSP Tunnels draft-cao-mpls-te-p2mp-head-protection-00.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 January 2, 2008. Abstract Protection methods for RSVP-TE P2MP LSP have been discussed by [TE- FRR]([RFC4090]) and [P2MP-TE-Bypass], but there are no solutions to protect 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 extension for such protection is also described. To protect the head node, a backup head node must be appointed and take the responsibility to forward the traffic to downstream LSRs of the protected head node. Generally, the backup head node is not on the path of protected LSP. Similar to [TE-FRR] there are two methods Expires January 2, 2008 [Page 1] Internet-Draft July 2007 can apply: one-to-one backup and facility backup and facility backup. Only one-to-one backup is described in details, facility backup will be discussed in 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.................................................4 2. Introduction................................................4 2.1. Motivation.............................................4 2.2. Head Node Protection Scenario...........................5 2.2.1. Solution Overview..................................6 2.3. Applicability Statement and Implementation Considerations8 2.3.1. Topology Limitation................................8 2.3.2. Implementation Consideration.......................9 3. Extensions to RSVP-TE........................................9 3.1. HEAD_PROTECION Object...................................9 3.1.1. HEAD_PROTECTION for IPv4 address..................10 3.1.2. HEAD_PROTECTION for IPv6 address..................11 3.1.3. SESSION_ATTRIBUTE Flags...........................12 4. Behavior of MHN and BHN.....................................12 4.1. Behavior of MHN........................................12 4.1.1. Signaling BHN for Head Protection.................13 4.1.2. Revert back to MHN from BHN Behavior..............14 4.2. Behavior of BHN........................................16 4.2.1. Signaling BHN-Detour and Protection Procedures.....17 4.2.2. Revertive Procedures for BHN......................18 4.3. Protection Teardown....................................18 4.3.1. Protection Teardown...............................19 5. Behavior of Merge Nodes.....................................19 6. Behavior of All Other LSRs..................................19 7. Security Considerations.....................................20 8. IANA Considerations........................................20 8.1. HEAD_PROTECION Object..................................20 8.2. Error Code............................................20 9. Conclusions................................................20 10. Acknowledgments...........................................20 11. References................................................20 11.1. Normative References..................................20 11.2. Informative References................................21 Author's Addresses............................................21 Cao, et al. Expires January 2, 2008 [Page 2] Internet-Draft July 2007 Intellectual Property Statement................................22 Disclaimer of Validity........................................22 Copyright Statement...........................................22 Cao, et al. Expires January 2, 2008 [Page 3] Internet-Draft July 2007 1. Terminology LSR: Label-Switch Router. In this document all LSR should support RSVP-TE extensions for P2MP LSP. LSP: An MPLS Label-Switched Path. In this document, an LSP will always be 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 backup up LSP for protecting the traffic. MP: Merge Point. In this document MP generally is one hop downstream neighbour to the MHN. 2. Introduction RSVP-TE P2MP LSP has been deployed and many real-time applications are running with such LSPs, so there is a strong requirement to improve the robustness of the transmission. Before this document, there are a lot of work have been done in RSVP-TE P2MP protection. 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 give solution for the LSP head node protection, which is a key element for network 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. Procedures defined in [RSVP](RFC2205), [RSVP-TE](RFC3209),[TE-FRR]and [RSVP-P2MP](RFC4985)MUST be followed. 2.1. Motivation Traditional protection methods use backup LSP or bypass tunnel to forward the traffic. In the event of protected LSP failure, include link failure or node failure, PLR will take the action to detour the packets from PLR to MP through backup LSP or bypass tunnel. This requires PLR must be a node of protected LSP and must be upstream to the failure point. Such mechanism works well for protecting transit links and transit LSRs. But it has no ability to protect the head node of the LSP because there is no "upstream neighbour" to the head node. In the real application, head node failure will cause more serious side effect than transit link or nodes. So there is strong requirement for reducing head node failure risk. One possible Cao, et al. Expires January 2, 2008 [Page 4] Internet-Draft July 2007 solution today is 1+1 protection: deploying another P2MP tree from a different LSR to all receivers. Obvious this is not a good method: it will cost double bandwidth and require maintaining double forwarding states in the devices. So it is highly desirable to find a method to resolve this problem. 2.2. Head Node Protection Scenario When real-time application is deployed, service providers (SP) always try their best to avoid service interruption. Since failures are not predictable so backup is always an effective and necessary solution. It is common for SP to deploy double Source Server or make the application server multi-homing to multiple edge routers. It can be a typical environment for such applications: [S1]-|---[R1]--[R2]--[R3]---[L1]----[ReceiverA] | \/ | \/ | /\ | /\ |---[R4]--[R5]--[R6]---[L2]----[ReceiverB] Figure 1. Source Multi-homing In the simple topology shown in Figure 1, [S1] is an application server; [Rx] and [Lx] are RSVP-TE P2MP LSP capable devices. [S1] is multi-homing to LSR [R1] and [R4]. If multicast packets sent by [S1] need to be transmitted to [L1] and [L2], a P2MP LSP (LSP1)start with [R1] can be created with two sub-LSPs: [R1]->[R2]->[R3]-[L1] and [R1]->[R5]->[R6]->[L2]. Packets from [S1] can be received by [R1] and [R4]. If SP want to improve the robustness, another P2MP LSP (LSP2) start 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 major path and the other one (LSP2) as 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 then begin to accept packets received from LSP2. There may have some variations from Figure 1. The SP may want to protect not only LSR failure but also application server failure. So it is frequently found that two applications servers are deployed and connected to two LSRs separately. It is shown in Figure 2 below: Cao, et al. Expires January 2, 2008 [Page 5] Internet-Draft July 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 generates 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 above case depicted with Figure 1. The above methods can work well but not in an effective way. Half of the bandwidth is wasted during the most of time. LSRs have to maintain as much as twice amount of P2MP LSP states. Also all leaves have to deal with duplication traffic and monitor the LSP state to determine which LSP is the major one. Comparing the two LSPs in above cases, it is easy to be noticed that the only difference of the two LSPs are the head nodes: LSP1 starts from [R1] and LSP2 starts from [R4]. The transit nodes and leaves are same. So in such topology if [R1] and [R4] cooperate together and act as backup node for each other, then it is possible to build only one P2MP LSP and gains head node protection ability as well. 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" to head node to detour the traffic, a LSR have 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). Backup LSP or bypass tunnel to protect MHN will be built from BHN to all NHOP LSRs of MHN. In such case, those NHOP LSRs are the merge point (MP) LSPs. To ensure all branches receive the traffic the MP set should include all NHOP LSRs of MHN. In normal operation source packets will arrive at MHN and BHN. BHN drops the packets and there is no traffic on backup LSP or bypass tunnels. When BHN detects there is a failure on MHN (There are different mechanism to discover the node failure of MHN. The special Cao, et al. Expires January 2, 2008 [Page 6] Internet-Draft July 2007 methods for discovering the failure are outside the scope of this document), BHN will forward these packets to MPs and MPs will recognize which LSP the packets belong to and forward the packets along with rest of the protected LSP. A LSR is eligible to be a BHN MUST satisfies the follow conditions: - Traffic to be protected can be received from BHN without 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 is not 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. MP set includes LSR [R2] and [R5]. Backup LSP against MHN failure starts from BHN to MPs. Theoretically backup LSP can use unicast LSPs or P2MP TE LSPs. Consequently there are two options for building backup LSP: - 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 limitation to the backup LSP(s): the backup LSP(s) MUST not transit MHN. Since BHN, instead of MHN, has to send traffic to all downstream MPs, BHN has to bind all the correlative backup LSPs info of a protected P2MP LSP to one specific traffic source and MHN, a P2MP TE LSP is more convenient to protect a P2MP LSP. And it is suitable for facility backup. So P2MP LSP is chosen and discussed in this document. In figure1 the backup P2MP TE LSP is composed with two sub-LSP: [R4]- >[R2] and [R4]->[R5], which is referred to as a LSP BHN-Detour. When a failure occurs in the MHN ([R1]), the BHN ([R4]) detects the failure and redirects traffic on to the BHN detour along links [R4]- >[R2] and [R4]->[R5], using the label received from the MPs ([R2] and [R5])when [R4] created the BHN-Detour. While [R4] is using the BHN- Cao, et al. Expires January 2, 2008 [Page 7] Internet-Draft July 2007 Detour, [R4] will recognize the traffic and should perform the MPLS encapsulation. Merge points receive the detoured traffic from BHN and merge them to protected LSP. From the view of MPs, the process is the same to link failure protection. Service interruption is not only caused by failure but may be caused by regular operations, such as hardware upgrading or software patch installation. Such operation is planned by SP and the un-availability of the device can be predicted. This kind of operation is referred to as Plan-Maintenance (PM). The head protection method described in this document can also be used in PM scenario. For example, in figure1, if [R1] has to stop forwarding due to some operation reason, [R1] can assign [R4] as BHN and after [R4] build up BHN-Detour, traffic can be transmitted through BHN-Detour. After the operation of [R1] has been performed, [R1] can take over the traffic stream. So by head-protection, side affection caused by [R1] operation can be minimized. Since head protection is performed by two LSRs, there are many important differences between [TE-FRR] and head protection. One big difference between [TE-FRR] and head-node protection is how to tell PLR and BHN the information of 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 relative RSVP Extensions. But BHN is not on the path of Protected LSP, so extra messages will be sent by MHN to BHN to indicate BHN how to act. Another difference is all LSRs on the path of P2MP LSP must be refreshed by PATH message periodically. So in the case of MHN failure, BHN must generate and send PATH messages to all downstream LSPs as if these messages are sent by MHN. The third difference is after the failure is repaired, how to revert traffic from BHN back to original LSP. After MHN recovering from node failure, MHN may lose all the RSVP TE P2MP states. So the before the MHN takes the role of ingress node, MHN MUST synchronize the P2MP LSP states between MHN and BHN. All the procedures will be described in later of this draft. 2.3. Applicability Statement and Implementation Considerations 2.3.1. Topology Limitation This document describes a mechanism that works only with the topology that a suitable backup head node exists. A suitable backup head node must satisfy the requirement listed in section 2.2.1. It is common to Cao, et al. Expires January 2, 2008 [Page 8] Internet-Draft July 2007 construct such a network to get high availability, so it is not too strict limitation for deploying head node protection. 2.3.2. Implementation Consideration Head node protection should be compatible with existing protocols as much as possible. Some consideration/requirement is listed bellow: - Inherit existing protocol extensions. The new method should reuse existing protocol extensions defined in [TE-FRR] as much as possible. And the new method should be back compatible with current mechanisms. Ideally, only MHN and BHN should be upgraded and MPs and other LSR can be kept unchanged. - When protection action is taken, the influence scope should be limited. There should be no need to affect any MPs' downstream nodes. - After protection action is taken, BHN should works as the real head node and can process all feedback from downstream LSRs. 3. Extensions to RSVP-TE This document defines an additional object, which is referred to as HEAD_PROTECTION object. This new object is backward compatible with LSRs that do not recognize them. The new object is carried in RSVP PATH message and RESV message. 3.1. HEAD_PROTECION Object The HEAD_PROTECTION object is used to facilitate exchanging information between MHN and BHN. MHN uses this object to specify which LSR is BHN and advertise essential information of a protected LSP. BHN also uses this object to facilitate synchronizing the relevant information of the protected RSVP-TE P2MP LSP to MHN after MHN is recovered from its node failure. BHN or MHN MUST not forward this object to its 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. Mechanism of transmit RSVP message over tunnel is described in [RFC2746]. Cao, et al. Expires January 2, 2008 [Page 9] Internet-Draft July 2007 Details of transmission through tunnel will be discussed in later version of this document. 3.1.1. HEAD_PROTECTION for IPv4 address Class-Num: TBD 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 local address of the MHN can be used. Backup_Head IPv4 address identifying the LSR selected as BHN. Any local address of the BHN can be used. Flags 0x01(bit0): Head protection desired 0x02(bit1): Head protection available 0x04(bit2): Synchronization desired 0x08(bit3): Synchronization end 0x16(bit4): Synchronization end ack 0x32(bit5): Revertive indication Bit0 is the lowest bit of the octet. Cao, et al. Expires January 2, 2008 [Page 10] Internet-Draft July 2007 3.1.2. HEAD_PROTECTION for IPv6 address Class-Num TBD C-Type TBD 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 local address of the MHN can be used. Backup_Head An IPv6 128bits unicast address identifying the LSR selected as BHN. Any local address of the BHN can be used. Flags 0x01(bit0): Head protection desired 0x02(bit1): Head protection available 0x04(bit2): Synchronization desired Cao, et al. Expires January 2, 2008 [Page 11] Internet-Draft July 2007 0x08(bit3): Synchronization end 0x16(bit4): Synchronization end ack 0x32(bit5): Revertive indication Bit0 is the lowest bit of the octet. 3.1.3. SESSION_ATTRIBUTE Flags Current SESSION_ATTRIBULTE object has defined several flags in [RSVP_TE] and [TE_FRR]. To request head node protection, 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 should be requested and which LSR will be assigned as backup head node (BHN). How to find a suitable LSR as BHN is out of the scope of this document. Manual configuration is an effective and easy choice. MHN and BHN cooperate to setup backup LSPs. To reduce the affection to other LSR on the path of P2MP tunnel, from the view of MP, BHN builds the backup LSP as if a link protection LSP between MHN and MP is created. 4.1. Behavior of MHN If MHN decides to deploy head protection, MHN should act as link protection is being deployed. That is, all flags required by link protection should be set and necessary object required by link protection should be carried in the PATH message. 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 and the traffic should be reverted to protected LSP from BHN-Detour. Cao, et al. Expires January 2, 2008 [Page 12] Internet-Draft July 2007 4.1.1. Signaling BHN for Head Protection To build a BHN-Detour to protect the MHN, BHN must get enough information about the protected LSP. A number of objectives must be met: - Unambiguously and uniquely identifying protected LSPs. - Uniquely identifying the protected node. - Clearly describing if bandwidth protection is desired - Clear describing if one-to-one protection or facility backup is desired. - BHN should unambiguously know which LSRs are merge points (that is the second hop LSRs of the P2MP LSP). Fortunately most of the information is already included in PATH message and this make the signaling easy. If MHN decides to deploy head protection and selects a LSR as BHN, it MUST follow the behavior described bellow: - MHN record each PATH message sent to its down stream LSRs. MHN rebuilds PATH messages according to the records 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. The object content should not be changed during the same session. - MHN sends the re-built PATH messages to BHN. If MHN and BHN are directly connected, PATH message can be sent directly. Otherwise, PATH message should be sent through a tunnel. - If there is a topology change and there is a MP is newly desired or newly grafted, MHN should send relevant PATH message to BHN immediately to reflect the topology change. MHN sends the PATH message containing HEAD_PROTECION object and expects corresponding RESV message from BHN. After BHN has signaling 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. Cao, et al. Expires January 2, 2008 [Page 13] Internet-Draft July 2007 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 occur node failure. When MHN is recovered from a node failure, MHN should take the charge of sending traffic along the protected P2MP LSP again. The revertive procedure must be taken after RSVP-TE P2MP LSP has been re-constructed. One big difficulty here is, after the node failure, MHN lost all states about original LSPs. So fully retrieving the LSP states is the premise of the revertive behavior. Since BHN receives all PATH messages from MHN to build BHN-Detour, it is feasible for MHN to retrieve the lost states and correlative information about the protected P2MP LSP from BHN. A number of assumptions must be satisfied and a number of objectives must be met. Assumption: - After node failure, MHN should recognize which LSR is BHN that will help it to recover. - BHN has the ability to detect the recovering of a specific MHN. Objectives: - All RSVP-TE P2MP LSPs being protected by BHN SHOULD be re- constructed by MHN. - 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. - The re-constructed LSP should have the same topology as before the node failure. - BHN should know the LSPs have been re-constructed and know when to stop forwarding the traffic. - BHN should know all essential information has already been sent to MHN successfully. After recovering from the node failure, MHN retrieves the RSVP-TE P2MP LSPs' states by receiving PATH messages from BHN. BHN detects the recovery and sends the PATH messages it receives from MHN before Cao, et al. Expires January 2, 2008 [Page 14] Internet-Draft July 2007 the failure back to MHN. All PATH messages sent to MHN should contain HEAD_PROTECTION object with "Synchronization desired" or "synchronization end" flag set. A PATH message containing a HEAD PROTECTION object with "synchronization end" flag set means the end of synchronization. After synchronization, MHN has the ability to re- construct the protected P2MP LSP again. The process has three phases as below: o State Synchronization By receiving PATH message sent by BHN, MHN retrieves lost states of the protected RSVP-TE P2MP LSP. Since each LSP contains one or more sub-LSP, so there will one or multiple PATH messages to be received. One PATH message carries one or more sub-LSP information, and each sub-LSP should be explicitly described by ERO/Sub-ERO object. MHN should response BHN by sending corresponding RESV messages to BHN. RESV message should contain RRO/Sub-RRO corresponding to those PATH messages. During synchronization phase, all PATH and RESV messages MUST contain HEAD_PROTECTION object. "Synchronization desired" or "Synchronization end" flag should be set by BHN in PATH messages. If MHN receives a PATH message with "Synchronization end" flag set in HEAD_PROTECION object, which means all the states corresponding to a specific protected P2MP LSP have been exchanged. The PATH message with "Synchronization end" flag set can be referred to as a SYN-END PATH message. MHN would respond SYN-END PATH message in two different ways: a) RESV message with "Synchronization end ack" flag set in HEAD_PROTECTION object. This message is referred to as SYN-END- ACK RESV message. SYN-END-ACK RESV message is used to inform BHN that all states have been retrieved successfully but the original protected P2MP LSP has not been re-constructed, BHN should continue to take the charge of sending traffic along the backup LSP(s) and hence to the rest of the protected P2MP LSP. b) RESV message with "Revertive indication" flag set in HEAD_PROTECTION object. Such RESV message is referred to as SYN- REVERT RESV message. SYN-REVERT RESV message is used to inform BHN MHN has already prepared for sending traffic again. When received such message BHN should stop sending traffic on to the backup LSP. Before MHN finishes re-constructing LSP, MHN send SYN-END-ACK RESV message to BHN to keep BHN maintaining the synchronization session Cao, et al. Expires January 2, 2008 [Page 15] Internet-Draft July 2007 and continue forwarding traffic on to the protected P2MP LSP. SYN- REVERT RESV message will be sent after protected LSP re-construction has been completed. o LSP Re-Construction Have retrieving the states of the protected P2MP LSPs, MHN can re- construct the LSP segments from MHN to MPs. LSP tunnels are identified by SESSION and SESSION TEMPLATE objects. MHN must keep the relevant fields (Tunnel end point address, Tunnel ID, Extended tunnel ID, Tunnel sender address and LSP ID) value be same as those before the node failure. MHN should use the global revertive mode for link failure described in [RSVP-TE-FRR]. o Traffic revert back to MHN After MHN re-constructing the protected P2MP LSP, MHN sends SYN- REVERT RESV message to BHN. Then MHN begins to sending traffic ont to the protected P2MP LSP. To reduce the side effect of SYN-REVERT RESV message loss, MHN may send multiple (default value is 2) messages to BHN continuously. After sending SYN-END-REVERT message to BHN, MHN must not respond any PATH messages sent by BHN for the same session. After the traffic is reverted, MHN takes the role as a normal head- end of a P2MP LSP. MHN begins to send PATH message to all egress leaves and process RESV messages received. Also MHN sends PATH message to BHN as described in section 4.1.1 to deploy head node protection. MHN MUST NOT send PATH message contain HEAD_PROTECTION object to BHN before traffic is reverted back because this will cause BHN stop forwarding packets through BHN-Detour. 4.2. Behavior of BHN BHN is responsible to create BHN-Detours to protect the head node and play the role as a head node during the MHN failure. Also BHN helps MHN to re-construct protected LSP after the recovery of the node failure. There are two different procedures for BHN: - Signaling BHN-Detour and rerouting traffic for protection. Cao, et al. Expires January 2, 2008 [Page 16] Internet-Draft July 2007 - 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 has received PATH message from other LSR of the same SESSION, that means BHN is on the path of protected tunnel, BHN MUST send RESV message with HEAD_PROTECTION_ERROR notification to MHN. - BHN MUST check the IP address in "backup head" in HEAD_PROTECION object. If the BHN dose not have such IP address, BHN must send back ERROR notification to MHN. - After check the validity of PATH message, BHN processes the objects in PATH message. BHN MUST record SESSION and 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. In the view of MPs, the backup LSP is used for link failure (MHN->MP) protection. - After BHN-Detour is created, BHN send RESV message with "Head protection available" flag set. This informs MHN that BHN-Detour is ready. This is important for PM scenario. 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 be unchanged. - BHN periodically sends PATH messages to all MPs to refresh the state of protected LSP. In the view of downstream LSRs, the PATH messages are generated by MHN but not BHN. Cao, et al. Expires January 2, 2008 [Page 17] Internet-Draft July 2007 4.2.2. Revertive Procedures for BHN During the protection period, BHN should take some action to detect if MHN is recovered. The detection methods are out of the scope of this document. Once BHN detects MHN is recovered, follow action should be taken to coordinate MHN complete revertive procedures: The process has two phases: o State Synchronization Before protection, BHN records all states of protected P2MP LSPs. BHN build PATH messages according to the records as the messages received from MHN. Each PATH message contains ERO/SERO of sub-LSPs and HEAD_PROTECTION object. The PATH message MUST have HEAD_PROTECION object with "Synchronization desired" flag set. BHN periodically sends PATH messages to MHN and expects RESV message corresponding to PATH message. If BHN receives acknowledgement from MHN with RESV message, BHN checks the RRO/SRRO and identify which sub-LSP information has been synchronized. If all sub-LSP information has been synchronized by PATH message, BHN sends SYN-END PATH message to MHN and wait SYN-END-ACK or REVERTIVE- INDICATION RESV message. Before REVERTIVE-INDICATION PATH message is received, BHN keep forwarding the traffic through BHN-Detour. If REVERTIVE-INDICATION PATH message is received, BHN stops forwarding and come into BHN-Detour refresh phases as described bellow. o BHN-Detour Refresh Receiving REVERTIVE-INDICATION RESV message indicates MHN has completed all revertive procedures and take the role as a normal head end. BHN expects the PATH message with HEAD_PROTECTION object from MHN. If BHN dose not receive such PATH message, BHN should regard BHN-Detour is not needed by MHN and all states should be timed out and records should be removed, backup LSP should be tore down. 4.3. Protection Teardown MHN can teardown head protection when necessary. Cao, et al. Expires January 2, 2008 [Page 18] Internet-Draft July 2007 4.3.1. Protection Teardown MHN may decide to destroy the head protection. There are two ways to indicate BHN: implicit and explicit. o Implicit teardown If MHN decides use implicit teardown method, it just stops sending PATH message to BHN. States of protected tunnels in BHN will be expired because of less of refreshment. BHN then teardown BHN-Detour and clear all states and records expired. BHN has to distinguish state expiration because of implicit teardown and because of MHN failure. If BHN find MHN is in error, implicit teardown can not be taken. o Explicit teardown If MHN decides use explicit teardown to inform BHN teardown immediately, BHN sends PATH Tear message with HEAD_PROTECTION. This PATH message may contain SESSION and SESSION_TEMPLATE and without any ERO/SERO objects, which is used to inform BHN all related states of the protected LSP should be removed. 5. Behavior of Merge Nodes As stated before in this document, in order to reduce the compact to MPs, this document does not try to add new functionalities to MPs. From the aspect of MPs, they still have the same behaviors as described in [TE-FRR] and [P2MP-TE]. It means that MPs do not need to be aware of such head node protection, they just consider themselves as the MPs of normal link protection. One thing needs to be noted that MPs would receive duplicated traffic for the same data, it may happens during the switching period from MHN to BHN (PM scenario), and vice versa. Currently, from the control plane, there is no good method to resolve this issue. So MPs should better have the ability to handle such situation, especially for the data plane of MPs, how to handle the duplicated traffic is out of scope this document. 6. Behavior of All Other LSRs To deploy head protection, only MHN and BHN should upgrade to support new extensions and execute new procedures. Other LSRs' behavior is not changed. Cao, et al. Expires January 2, 2008 [Page 19] Internet-Draft July 2007 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 The new number of Class-Num and C-Type for the new defined RSVP-TE objects should be assigned by IANA. 8.1. HEAD_PROTECION Object TBD 8.2. Error Code TDB 9. Conclusions Head node protection can not only work for failure protection, but also can help for SP planned maintenance. Service interruption is caused by not only network device failure but also some inevitable administrative operation, such as line card upgrade or software patch installation. With mechanisms described above, SP can provide service without interruption by switching the two LSP as active at appropriate time. 10. Acknowledgments 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. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. Cao, et al. Expires January 2, 2008 [Page 20] Internet-Draft July 2007 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture", RFC 3031. [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. 11.2. Informative References [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-1583. [MPLS-UPSTREAM] Aggarwal, Rekhter, Rosen, "MPLS Upstream Label Assignment and Context Specific Label Space", draft-ietf- mpls-upstream-label, work in progress. [RSVP-UP] Aggarwal, Le Roux, " MPLS Upstream Label Assignment for RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress [P2MP-TE-Bypass] Le Roux, Aggarwal, R., Vasseur, J.P., and Vigoureux, M., "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", draft-ietf-mpls-p2mp-te-bypass-00.txt, work in progress. Author's Addresses Wei Cao Huawei Technologies Room 201R, Kuike building, Shangdi, Haidian District of Beijing, P.R. China Email: caowayne@huawei.com Cao, et al. Expires January 2, 2008 [Page 21] Internet-Draft July 2007 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. 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). Cao, et al. Expires January 2, 2008 [Page 22] Internet-Draft July 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 January 2, 2008 [Page 23]