Network Working Group A. Liu Internet Draft S. Kini Intended status: Standards Track Ericsson Expires: April 2010 October 13, 2009 RSVP-TE Graceful Restart under Fast Re-route conditions draft-liu-mpls-rsvp-te-gr-frr-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 April 13, 2010. Liu & Kini Expires April 13, 2010 [Page 1] Internet-Draft RSVP-TE Graceful Restart under October 2009 Fast Re-route conditions Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license- info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract During RSVP-TE graceful restart (GR), the LSR communicates with its directly connected neighbors to synchronize LSP state to recover from control plane failure conditions. However, when the LSP has undergone a Fast Re-route (FRR), the directly connected neighbor of the Point of Local Repair (PLR) or Merge Point (MP) could be down. The FRR condition of the LSP could exist for a substantial period of time. During this period the network is vulnerable to traffic loss if control plane experiences a failure on the PLR or MP. This draft describes a mechanism to extend RSVP- TE GR to work under conditions where FRR has occurred. Table of Contents 1. Introduction ..................................................2 2. Conventions Used in This Document .............................3 3. Problem Statement .............................................3 4. Extensions to RSVP Hello Message Handling .....................4 5. Security Considerations .......................................6 6. IANA Considerations ...........................................6 7. References ....................................................6 7.1. Normative References .....................................6 8. Acknowledgments ...............................................7 1. Introduction RSVP Graceful Restart ([RFC3473] and [RFC5063]) provides a mechanism to preserve the LSP during control plane failure so that traffic is not impacted. The mechanism uses the RSVP HELLO message defined in [RFC3209] to exchange graceful restart capability information and detect node failure. [RFC4558] introduces node-id based hello message. Liu & Kini Expires April 13, 2010 [Page 2] Internet-Draft RSVP-TE Graceful Restart under October 2009 Fast Re-route conditions RSVP fast reroute (FRR) is specified in [RFC4090] and provides a fast local repair mechanism when link or node failure occurs so that the traffic of protected LSP can be switched on PLR (Point of Local Repair) node to pre-established bypass or detour. The MP (merge point) node merges the traffic back to the protected LSP. When FRR is in effect, the traffic could stay in the bypass or detour for significant period of time. During this period of time, if PLR or MP's control plane restarts, there are certain scenarios where RSVP GR procedures cannot be applied. This document describes those scenarios and an extension to existing RSVP Hello mechanism to allow RSVP GR to operate between non directly connected neighbors. This enables RSVP GR to work when FRR is in effect. 2. 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 [RFC2119]. 3. Terminology The reader is assumed to be familiar with the terminology defined in [RFC3209], [RFC4090], [RFC3473] and [RFC5063]. 3. Problem Statement Per [RFC3209], RSVP Hello message is exchanged only between directly connected neighbors. [RFC3473] extends the RSVP hello mechanism to support RSVP Graceful Restart (GR) functionality. The hello message is used to carry graceful restart capability object and information used to preserve the LSP and recover the LSP state after control plane fails. If the hello session is not established, the graceful restart cannot be achieved. [RFC4090] specifies a fast local repair mechanism to re-route a protected LSP over a bypass tunnel. When the PLR detects a link/node failure, FRR is triggered and the PLR re-routes the protected LSP over a pre-established bypass tunnel. The protected LSP is merged back at the MP node. When the PLR and MP are not immediate neighbors there is no hello session between them. In such a situation if FRR is in effect and the control plane restarts on PLR or MP node, the protected LSP may be torn down thus leading to traffic loss. Liu & Kini Expires April 13, 2010 [Page 3] Internet-Draft RSVP-TE Graceful Restart under October 2009 Fast Re-route conditions Consider the example in Figure 1. A unidirectional protected LSP is setup as R1-R2-R3-R4-R5. The unidirectional bypass tunnel for node protection is established as R2-R6-R4. R2 is PLR node and R4 is MP node. When link between R2-R3 fails or node R3 fails, traffic flows through the bypass R2-R6-R4. If R2 or R4 restarts, since hello is not running between R2 and R4, GR is not going to take effect and the protected LSP is not preserved. As a result, the traffic will get impacted. (PLR) (MP) R1 ---- R2 ------ R3 ----- R4------R5 | | +------- R6 -------+ Figure 1 4. Extensions to RSVP Hello Message Handling A targeted hello session must be established through the exchange of hello messages between nodes that are not immediate neighbors but have a bypass tunnel between them. These Hellos may be sent via IP forwarding or via the bypass tunnel. If a bypass tunnel does not have an independent data plane failure detection mechanism (e.g. BFD) then a targeted Hello session sending Hellos via the bypass can act as one. If the bypass has independent failure detection mechanisms, the Hello should be sent via IP forwarding. For Hellos sent using IP forwarding an IP TTL value of 255 is recommended whereas for Hellos sent via bypass tunnel the TTL of 1 should be used. The remote address must be the node id (IPv4 or IPv6) of the targeted neighbor and must also be used in the destination fields of the hello packet. The corresponding hello message handling procedures described in [RFC3209]. [RFC3473] and [RFC4558] still apply. The RSVP graceful restart procedures described in [RFC3473] and [RFC5063] also applies to these non directly connected neighbors. At least one targeted hello session per pair of non directly connected PLR node and MP node must be established. If there are Liu & Kini Expires April 13, 2010 [Page 4] Internet-Draft RSVP-TE Graceful Restart under October 2009 Fast Re-route conditions multiple bypasses between the nodes, only one targeted hello session should be established, unless a targeted hello session is used to indicate data plane liveness. If there are multiple bypasses to a node, the selection of which one to use for sending the hello message is local policy. A hello session that uses IP forwarding should be used to avoid any forwarding problems specific to a LSP. A non directly connected neighbor may be configured to setup the targeted hello session. This configuration may be derived from the detour/bypass configuration. A targeted hello session may be automatically initiated by the node that is initiating the bypass. The peer node may create the hello session on receiving a hello. E.g. in Figure 1, R2 may create the Hello session to R4 when the bypass LSP R2-R6-R4 is initiated or a protected LSP R1-R2-R3-R4-R5 is associated with the bypass LSP. Also R4 may create a Hello session to R2 on seeing the Hello from R2. A targeted hello session may also be created automatically on receiving a PATH message from a neighbor that is not directly connected but has a LSP (bypass) to it. E.g. in Figure 1, if R2 does not initiate Hello session creation, R4 may initiate creation of a Hello session with R2 on receiving a PATH message of the protected LSP from R2. If RSVP graceful restarted is enabled, the Restart_Cap Object should be included in the hello message following procedures described in the [RFC3473]. Once the targeted hello session is established between the non- direct neighbors, the RSVP graceful restart procedures described in [RFC3473] and [RFC5063] should be followed if either node restarts. The support of the targeted hello can be enabled or disabled by configuration which is beyond the scope of this document. The hello session between direct neighbors should be able to co- exist with the targeted hello session. Liu & Kini Expires April 13, 2010 [Page 5] Internet-Draft RSVP-TE Graceful Restart under October 2009 Fast Re-route conditions 5. Security Considerations This document extends the RSVP hello message exchange to non- direct neighbors. The security considerations pertaining to the original [RFC3209] remain relevant. RSVP message security is described in [RFC2747] and provides integrity and authentication of the hello message. 6. IANA Considerations This document makes no request of IANA. 7. References 7.1. Normative References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC5063] Satyanarayana, A., Rahman, R., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, September 2007. [RFC4090] Pan, P., Swallow, G., Atlas, A., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005 [RFC4558] Ali, Z., Rahman, R., Prairie, D., Papadimitriou, D., "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement", RFC 4558, June 2006 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. Liu & Kini Expires April 13, 2010 [Page 6] Internet-Draft RSVP-TE Graceful Restart under October 2009 Fast Re-route conditions 8. Acknowledgments The authors would like to thank Venkatesan Pradeep and Loa Andersson for their comments. Authors' Addresses Autumn Liu Ericsson 300 Holger Way, San Jose, CA 95134 Email: autumn.liu@ericsson.com Sriganesh Kini Ericsson 300 Holger Way, San Jose, CA 95134 Email: sriganesh.kini@ericsson.com Liu & Kini Expires April 13, 2010 [Page 7]