Network Working Group JiangWeilian(ZTE Corporation) FengJun(ZTE Corporation) Internet-Draft CuiYing(ZTE Corporation) Expires: May 20, 2006 KongYong(ZTE Corporation) LuoJian(ZTE Corporation) November 20, 2005 Mechanism of multiple adjacent nodes RSVP graceful restart Simultaneously draft-jian-ccamp-multinodes-rsvp-restart-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 5 of RFC3209, Section 9 of RFC3473. 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. 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 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Luojian Expires: May 2006 [Page 1] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 Abstract Based on the RSVP graceful restart defined in the RFC3473, RFC3209, Node ID RSVP Hello:A Clarification Statement (draft-ietf-ccamp-rsvp -node-id-based-hello-02) and the Extensions to GMPLS RSVP Graceful Restart (draft-ietf-ccamp-rsvp-restart-ext-05), this document puts forward extension to solve the problem for the restart node to actively inform RSVP graceful restart to the neighbor, and further provides the relevant mechanism to support recovery processing of RSVP graceful restart at simultaneous restart of multiple adjacent nodes. Table of Contents 1. Conventions used in this document. . . . . . . . . . . . . . 3 2. Terms and abbreviation . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Actively Informing Neighbor of RSVP GR Capability by Restarted Node . . . . . . . . . . . 4 4.1 Adopting Multicast Address . . . . . . . . . . . . . . . . . 4 4.2 Adopting Hot Backup . . . . . . . . . . . . . . . . . . . . . 5 5. RSVP GR Processing at Simultaneous Restart of Multiple Adjacent Nodes . . . . . . . . . . . . . . . . 5 5.1 Multiple Adjacent Restart Nodes are Intermediate Nodes of the Tunnel . . . . . . . . . . . . . . . . . . . . . 5 5.2 Multiple Adjacent Restart Nodes Contain Tunnel Tail Node . . . . . . . . . . . . . . . . . . . . . . 7 5.3 Multiple Adjacent Restart Nodes Contain Tunnel Head Node. . . . . . . . . . . . .. . . . . . . . . 7 5.4 Multiple Adjacent Restart Nodes Contain All the Tunnel Nodes. . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . 9 Luojian Expires: May 2006 [Page 2] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 1 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]. 2 Terms and abbreviation Suppose the reader is familiar with terms defined in [RFC3209], [RFC3473]. 3 Overview In the RSVP Graceful Restart defined in Section 9 of RFC3473, the Hello mechanism defined by RFC3209 is extended to support GR (Graceful Restart) capability informing and fault detection between RSVP neighbors. It aims to define Resatrt_Cap object for Hello extension to carry GR capability parameter and inform it to the neighbor through Hello message interaction. The Hello mechanism defined by RFC3209 defines the message destination address and source address as the inter-neighbor interface IP address in turn. In draft-ietf-ccamp-rsvp-node-id-based -hello-02, the extension defines that the destination address and source address of Hello message supporting GR are TE RouterID of respective nodes. Then, the restart node is usually at a passive position. Only after it receives the RSVP GR Hello message from the neighbor, will it inform the neighbor of its GR capability b returning the ACK message. For restart of a single node, GR capability informing in the passive mode is also acceptable. If multiple adjacent nodes restart at the same time, however, these nodes cannot learn about the GR capability from each other. This document puts forward the solution of using the multicast address as destination address or adopting the hot backup technology to implement active informing of restarted node RSVP GR capability, and further provides the relevant mechanism to support recovery processing of RSVP GR at simultaneous restart of multiple adjacent nodes. Luojian Expires: May 2006 [Page 3] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 4 Actively Informing Neighbor of RSVP GR Capability by Restarted Node 4.1 Adopting Multicast Address After the node restarts and makes sure it supports RSVP GR Recovery, it can periodically send the GR HELLO message outward in the 1/2 RecoveryTime through all the RSVP interfaces to inform its GR capability. Main field data composing the GR HELLO request message: The destination IP address is multicast address (IPv4: 224.0.0.2; IPv6: FF02:0:0:0:0:0:0:2). The source IP address is the local TE RouterID. The source instance value is the created value (the neighbors under different interfaces can be the same). The destination instance value is 0. The Restart time value of Restart_Cap object is the local configuration value. The Recovery time of Restart_Cap object is the local configuration value. The R digit value of Capability object is 1 (it indicates the node supports receiving of the RecoveryPath message). The T digit value of Capability object is 1 (it indicates the node supports sending of the RecoveryPath message). The S digit value of Capability object is 0 (it indicates the node does not support abstract refreshing message; for support, it can be set as 1). The Reserved digit value of Capability object is 0. When the neighbor receives the GR HELLO request message with this destination address as multicast address, it can first use the informed source RouterID as the neighbor RouterID and local RouterID to query if the corresponding HELLO instance exists: If the instance does not exist, it will create a corresponding instance, save the GR capability parameter informed by the peer, and confirms restart of the peer node based on the fact that the destination IP address is the multicast address. According to the informed GR capability parameter, it confirms that the peer is in the Recovery stage, replies the ACK message to the restart neighbor based on its GR capability, and then creates the corresponding Recovery Timer. Luojian Expires: May 2006 [Page 4] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 Oct. 2005 If the instance exists, it will save the GR capability parameter informed by the peer, and reply the ACK message to the restart neighbor based on its GR capability. After receiving the ACK reply message from the neighbor, the restart node can create the corresponding GR Hello instance in accordance with the information in the message. By now, the GR Hello relation between the restart node and neighbor node is reestablished. If the destination IP address of the GR HELLO request message received by the restart node from its neighbor is also the multicast address, it means that the neighbor node is also a restart node. In this case, it similarly creates a corresponding instance, saves the GR capability parameter informed by the peer, confirms that the peer node is restarted and in the Recovery stage, and creates the corresponding Recovery Timer. After 1/2RecoveryTime, the restart node must stop sending of the GR Hello message with the destination IP address as multicast address. In stead, it just implements GR Hello communication according to the created GR Hello instance. 4.2 Adopting Hot Backup If the node conducts hot backup of key data for the established GR HELLO instance, such as the neighbor RouterID, local RouterID, source instance value, destination instance value, outgoing interface and the next-hop address. Then, the restart node, after hot backup switching and restart, can get the hot backup GR HELLO instance data before restart, and actively constitute a GR Hello instance based on these data to send a new GR Hello message to inform the neighbor. Then, it reestablishes the GR HELLO relation with the neighbor node. 5 RSVP GR Processing at Simultaneous Restart of Multiple Adjacent Nodes Suppose Tunnel1 is established along with the LSR1-LSR2-LSR3-LSR4 path. LSR1, LSR2, LSR3 and LSR4 all support RSVP GR, and all the nodes support sending and receiving of the Recovery Path message. 5.1 Multiple Adjacent Restart Nodes are Intermediate Nodes of the Tunnel Suppose LSR2 and LSR3 start at the same time. LSR1 and LSR4 enter the Restart stage, and they send the GR Hello message to LSR2 and LSR3 in turn. Luojian Expires: May 2006 [Page 5] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 After the LSR2 and LSR3 restart, they will enter the GR Recovery stage according to the configuration. With the method described in Section 4, a GR Hello relation can be set up between LSR2 and LSR3, and they can learn that the peer party is in the GR Recovery stage. At the same time, LSR1 and LSR4 will send the GR Hello request message to LSR2 and LSR3 in turn, and LSR2 and LSR3 will create the corresponding GR HELLO instance, respond to the request messages from LSR1 and LSR4, inform the peer party of support to GR, and then enter the Recovery stage together. After that, LSR1 will send the Path message with Recovery Label object to LSR2. (if sending and receiving of RecoveryPath message are supported, LSR4 will also send the RecoveryPath message to LSR3). After receiving the Path message with Recovery Label object, LSR2 will check if the corresponding PSB exists. Suppose it cannot be found, but the corresponding entry is found from the MPLS forwarding table, LSR2 will create the corresponding PSB. However, because the GR Hello relation has been established between LSR2 and LSR3, and they learn that the peer part is in the GR Recovery stage, then LSR2 can send the Path message carrying Recovery Label object to LSR3. Here, the outgoing label and outgoing interface are obtained by query of the forwarding table, and the next-hop address can be obtained through the ERO object of Path message sent upstream. After receiving the Path message carrying Recovery Label object from the restart node LSR2, LSR3 will find out if the corresponding PSB exists according to the received Path message. Suppose it is not found, but the corresponding entry is found from the MPLS forwarding table. Then, LSR3 creates the corresponding PSB, constitutes the Path message containing Suggested Label object and sends it to the downstream LSR4. After receiving the Path refreshing message containing Suggested Label object from the restart node LSR3, LSR4 resolves the incoming label of LSP for recovery through the Suggested_Label object in the Path message. Then, it matches the corresponding RSB, refreshes (clears) the stale flag for the corresponding forwarding table entry, and triggers the corresponding Resv message to send it to LSR3. LSR3 receives the Resv message from LSR4, creates RSB and associates the corresponding PSB. Now, both the incoming label and outgoing label are refreshed. LSR3 clears the stale flag for the corresponding forwarding entry and sends the Resv message to LSR2. Luojian Expires: May 2006 [Page 6] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 LSR2 receives the Resv message from LSR3, creates RSB and associates the corresponding PSB. Now, both the incoming label and outgoing label are refreshed. LSR2 clears the stale flag for the corresponding forwarding entry and sends the Resv message to LSR1. LSR1 receives the Resv message, refreshes RSB, and clears the stale flag of relevant protocol state. Now, Tunnel1 is completely recovered. 5.2 Multiple Adjacent Restart Nodes Contain Tunnel Tail Node Suppose LSR2, LSR3 and LSR4 start at the same time. LSR1 enters the Restart stage, and it sends the GR Hello message to LSR2. After LSR2, LSR3 and LSR4 all restart, they will enter the GR Recovery stage according to the configuration. With the method described in Section 4, a GR Hello relation can be set up between LSR2, LSR3 and LSR4, and they can learn that the peer party is in the GR Recovery stage. At the same time, LSR1 will send the GR Hello request message to LSR2, and LSR2 will create the corresponding GR HELLO instance, respond to the request messages from LSR1, inform the peer party of support to GR, and then enter the Recovery stage together. After that, LSR1 will send the Path message with Recovery Label object to LSR2. The following handing is the same as the description in Section 5.1. The Path message is sent to LSR3. After handing by LSR3, the Path carrying Recovery Label object is sent to LSR4, instead of the Path message carrying Suggested Label object. Then, LSR4 sends the Resv message upstream, and each hop is recovered in turn along with the upstream path till LSR1. Finally, Tunnel1 is completely recovered. 5.3 Multiple Adjacent Restart Nodes Contain Tunnel Head Node Suppose LSR1, LSR2 and LSR3 start at the same time. LSR4 enters the Restart stage, and it sends the GR Hello message to LSR3. After LSR1, LSR2 and LSR3 all restart, they will enter the GR Recovery stage according to the configuration. With the method described in Section 4, a GR Hello relation can be set up between LSR1, LSR2 and LSR3, and they can learn that the peer party is in the GR Recovery stage. Luojian Expires: May 2006 [Page 7] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 At the same time, LSR4 will send the GR Hello request message to LSR3, and LSR3 will create the corresponding GR HELLO instance, respond to the request messages from LSR4, inform the peer party of support to GR, and then enter the Recovery stage together. After that, only LSR4 will send the Recovery Path message to LSR3. (therefore, we suppose all the nodes support sending and receiving of the Recovery Path message.) When receiving the RecoveryPath message from the assistant node LSR4, LSR3 will find out if the corresponding PSB exists according to the received PATH message. Suppose it is not found, but the corresponding entry is found from the MPLS forwarding table. Then, LSR3 creates the corresponding PSB (possibly the original Path message should have the RRO object, which can be used to get the previous-hop address and recover the ERO containing the previous-hop address), and constitutes the Path message containing Suggested Label object to send it to the downstream LSR4 and wait for the Resv message from LSR4. After receiving the Path refreshing message containing Suggested Label object from the restart node LSR3, LSR4 resolves the incoming label of LSP for recovery through the Suggested_Label object in the Path message. Then, it matches the corresponding RSB, refreshes (clears) the stale mark for the corresponding forwarding table entry, and triggers the corresponding Resv message to send it to LSR3. After receiving the Resv message from LSR4, LSR3 creates the corresponding RSB, and refreshes (clears) the stale flag for the corresponding forwarding table entry. Then, LSR3 will send the Recovery Path message to LSR2. The same as handling of LSR3, LSR2, after receiving the RecoveryPath message from LSR3, will create the corresponding PSB, constitute the Path message containing Suggested Label object to send it to the downstream LSR3 and wait for the Resv message from LSR3. After receiving the Resv message from LSR3, LSR2 creates the corresponding RSB, and refreshes (clears) the stale flag for the corresponding forwarding table entry. Then, LSR2 will send the Recovery Path message to LSR1. Similarly, LSR1 creates the corresponding PSB and RSB, and refreshes (clears) the stale flag for the corresponding forwarding table entry. Now, Tunnel1 is completely recovered. Luojian Expires: May 2006 [Page 8] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 5.4 Multiple Adjacent Restart Nodes Contain All the Tunnel Nodes Suppose LSR1, LSR2, LSR3 and LSR4 start at the same time. After LSR1, LSR2, LSR3 and LSR4 all restart, they will enter the GR Recovery stage according to the configuration. With the method described in Section 4, a GR Hello relation can be set up between LSR1, LSR2, LSR3 and LSR4, and they can learn that the peer party is in the GR Recovery stage. However, none of the four LSRs has the Tunnel1 protocol state data before restart, so they cannot constitute any recovery Path message to be sent to the neighbor. In this case, Tunnel1 can only wait for reestablishment of LSR1 after the GR Recovery stage ends. 6 References [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP Tunnels", December 2001. [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", January 2003. [RFC1112] Deering, S., "Host Extensions for IP Multicasting", Stanford University, August 1989. [RFC2375] Hinden, R., et al., "IPv6 Multicast Address Assignments", July 1998. IANA ˇ°INTERNET MULTICAST ADDRESSESˇ±, September 2005 [draft-ietf-ccamp-rsvp-node-id-based-hello-02] Zafar Ali, et al.,"Node ID based RSVP Hello: A Clarification Statement", September 2005. [draft-ietf-ccamp-rsvp-restart-ext-05] Satyanarayana, et al., "Extension to GMPLS RSVP Graceful Restart", September 2005. Luojian Expires: May 2006 [Page 9] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 Authors Addresses JiangWeilian No.68 Zijinghua Road, Yuhuatai District Nanjing, China Phone: +86-025-52871644 Email: jiang.weilian@zte.com.cn FengJun No.68 Zijinghua Road, Yuhuatai District Nanjing, China Phone: +86-025-52871631 Email: feng.jun99@zte.com.cn CuiYing No.68 Zijinghua Road, Yuhuatai District Nanjing, China Phone: +86-025-52871631 Email: cui.ying@zte.com.cn KongYong No.68 Zijinghua Road, Yuhuatai District Nanjing, China Phone: +86-025-52871177 Email: kong.yong@zte.com.cn LuoJian No.68 Zijinghua Road, Yuhuatai District Nanjing, China Phone: +86-025-51803814 Email: luo.jian@zte.com.cn Comments are solicited and should be addressed to the working group's mailing list at ccamp@ops.ietf.org and/or the author(s). Luojian Expires: May 2006 [Page 10] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights, which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 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. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgments The authors would like to thank XuZhijun, DuKe, ZhuXinhua, ChenJianye and all the other people who have contributed to this draft, and also would like to thank all the future participants for their comments and suggestions. Luojian Expires: May 2006 [Page 11] Internet-Draft draft-jian-ccamp-multinodes-rsvp-restart-00 October 2005