Internet Engineering Task Force Y. Shen Internet-Draft Juniper Networks Intended status: Standards Track Y. Kamite Expires: August 12, 2013 NTT Communications Corporation February 8, 2013 RSVP Setup Protection draft-shen-mpls-rsvp-setup-protection-02 Abstract RFC 4090 specifies an RSVP facility-backup fast reroute mechanism for protecting established LSPs against link and node failures. This document extends the mechanism to provide so-called "setup protection" for LSPs during their initial Path message signaling time. In particular, it enables a router to reroute an LSP via an existing bypass LSP, when there is a failure of the immediate downstream link or node along the desired path. Therefore, it can be used to reduce LSP setup time in such a situation, or allow LSPs with strict paths to be established successfully when alternative paths are unavailable in the network or unable to be computed by ingress. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 12, 2013. Copyright Notice Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of Shen & Kamite Expires August 12, 2013 [Page 1] Internet-Draft RSVP Setup Protection February 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 3.1. New RSVP Attribute Flag . . . . . . . . . . . . . . . . . 5 3.2. New RSVP Attributes TLVs . . . . . . . . . . . . . . . . . 5 3.2.1. Protected LSP Sender IPv4 Address TLV . . . . . . . . 6 3.2.2. Protected LSP Sender IPv6 Address TLV . . . . . . . . 6 3.3. PLR behavior . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. MP behavior . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Local Revertive Mode . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Shen & Kamite Expires August 12, 2013 [Page 2] Internet-Draft RSVP Setup Protection February 2013 1. Introduction In RSVP facility-backup fast reroute (FRR) [RFC 4090], the router at a point of local repair (PLR) of an LSP can redirect traffic via a bypass LSP upon a failure of the immediate downstream link or node. Such protection is normally established after the LPS has been set up. This is because the PLR must know the label and address of the next-hop router (in the case of link protection) or those of the next-next-hop router (in the case of node protection), before it can select or signal a bypass LSP to protect the LSP. The information of the label and the address is carried in a Resv message. Imagine a scenario where a new LSP is being signaled, but its Path message carries an EXPLICIT_ROUTE object (ERO) with a strict path that is statically configured or computed offline based on a topology that assumes no failure in the network. In such a case, if a link or node along the path happens to be in a failure condition, RSVP signaling will stop at the router upstream adjacent to the failure. This will be the case even if there is an existing bypass LSP protecting the link or node for some existing LSPs. In other words, this new LSP is not protected during this setup phase, i.e. the initial Path message signaling time. In this situation, the network would normally rely on IGP to update traffic engineering (TE) information throughout the network, and the router upstream adjacent to the failure to send a PathErr message to trigger the ingress router to compute and signal a new path. However, this approach may not always be possible, desirable, or even relevant in the following scenarios: 1. Static strict path. As described above, if the ERO carries an explicit path with a sequence of strict hops that are statically configured or computed offline based on a topology assuming no network failure, the LSP will never be established. 2. LSPs with a strict requirement for setup time. IGP TE information flooding, PathErr message propagation, and path re- computation and re-signaling may introduce a significant delay to LSP establishment. This may impact on the setup time of services that have a strict requirement for it, such as on-demand transport services for real-time data. 3. Sibling P2MP sub-LSPs sharing a common link. In this case, the new LSP is a sub-LSP of a P2MP LSP, and its desired path is supposed to share the failed link with an existing sibling sub- LSP, i.e. another sub-LSP of the same P2MP LSP, which is being protected by a bypass LSP. If the new sub-LSP is rerouted via a different path, it will not be able to share the data flow over Shen & Kamite Expires August 12, 2013 [Page 3] Internet-Draft RSVP Setup Protection February 2013 the bypass LSP with that sibling sub-LSP, creating unnecessary traffic flow in the network. This document extends the RSVP facility-backup fast reroute mechanism to provide so-called "setup protection". During the initial Path message signaling of an LSP, if there is a link or node failure along the desired path, and if there is a bypass LSP protecting the link or node, the LSP will be signaled through the bypass LSP. The LSP will be established as if it was originally set up along the desired path (aka. primary path) and then failed over to the bypass LSP after the failure. After the failure is resolved, the LSP MAY be reverted to the primary path. The mechanism is applicable to both P2P and P2MP LSPs. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Theory of Operation When an LSP is being signaled by RSVP, a Path message is sent hop by hop from the ingress router to the egress router, following the path defined by an ERO. The setup protection mechanism in this document enables an ingress or transit router to reroute the LSP via a bypass LSP, if the router detects a failure of the immediate downstream link or node represented by the next hop in the ERO, called "next ERO hop". In this case, the current router is referred to as a PLR. The mechanism is relevant when the Path message carries the "local protection desired" flag in the SESSION_ATTRIBUTE object [RFC 4090] and a new "setup protection desired" flag defined in this document (Section 3.1). On a PLR, the mechanism is only applicable when the next ERO hop is a strict hop, and in the case of node protection, the next-next ERO hop is also a strict hop. A strict next ERO hop allows the PLR to unambiguously decide the intended downstream link or node along the desired path, and hence reliably detect its status. In link protection, the strict next ERO hop also indicates the merge point (MP), i.e. the destination of the bypass LSP to be used to reroute the LSP. In node protection, the strict next-next ERO hop indicates the MP. When performing setup protection, the PLR signals a backup LSP by Shen & Kamite Expires August 12, 2013 [Page 4] Internet-Draft RSVP Setup Protection February 2013 tunneling Path message through the bypass LSP. Like the Path message of a backup LSP in the normal facility-backup FRR ([RFC 4090]), this Path message carries an address of the PLR as the sender address in SENDER_TEMPLATE object. In addition, the Path message also carries the information of the protected LSP (Section 3.2). When the MP receives the Path message, it terminates the backup LSP, and re- creates the protected LSP. If the MP is the egress router of the protected LSP, it terminates the protected LSP as well. If the MP is a transit router of the protected LSP, it signals the LSP further downstream. Eventually, the LSP will be established end to end, with the backup LSP tunneled through the bypass LSP from the PLR to the MP. The RSVP state on the PLR and the MP and the RSVP messages generated by these routers are no different than those in a post-failure situation of a normal facility-backup FRR. Later, when the failure is resolved, the PLR MAY revert the LSP to the primary path, in the same manner as the local revertive mode specified in [RFC 4090]. The setup protection MAY be enabled and disabled on a router based on configuration. For an LSP to be setup-protected, the mode MUST be enabled on both PLR and MP. If it is enabled on the PLR but disabled on the MP, the MP SHOULD reject the Path message of the backup LSP and send a PathErr message, as described Section 3.4. 3.1. New RSVP Attribute Flag In order for an LSP to explicit request for setup protection, this document defines a new "setup protection desired" flag in the Attribute Flags TLV of the LSP_ATTRIBUTES object [RFC5420]. It is carried in the Path message of the LSP, i.e. the protected LSP. 3.2. New RSVP Attributes TLVs This document defines two new RSVP Attributes TLVs [RFC 5420]. They are used by a PLR to convey to an MP the original sender address in the SENDER_TEMPLATE object of a protected LSP. Both TLVs are carried in the LSP_REQUIRED_ATTRIBUTES object in the Path message of a backup LSP. o Protected LSP Sender IPv4 Address TLV o Protected LSP Sender IPv6 Address TLV Shen & Kamite Expires August 12, 2013 [Page 5] Internet-Draft RSVP Setup Protection February 2013 3.2.1. Protected LSP Sender IPv4 Address TLV The Protected LSP Sender IPv4 Address TLV is defined with type TBD. It is allowed on LSP_REQUIRED_ATTRIBUTES object, and not allowed on LSP_ATTRIBUTES object. The encoding is as below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Type TBD Length 8 Value Original sender address in the IPv4 SENDER_TEMPLATE object of the protected LSP. 3.2.2. Protected LSP Sender IPv6 Address TLV The Protected LSP Sender IPv6 Address TLV is defined with type TBD. It is allowed on LSP_REQUIRED_ATTRIBUTES object, and not allowed on LSP_ATTRIBUTES object. The encoding is as below. Shen & Kamite Expires August 12, 2013 [Page 6] Internet-Draft RSVP Setup Protection February 2013 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length (20) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Value // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Type TBD Length 20 Value Original sender address in the IPv6 SENDER_TEMPLATE object of the protected LSP. 3.3. PLR behavior When a router has a Path message to send out, if the Path message carries the "local protection desired" flag in the SESSION_ATTRIBUTE object and the "setup protection desired" flag in the LSP_ATTRIBUTES object, and if the next ERO hop is a strict IPv4 or IPv6 prefix, the router SHOULD validate the reachability of the prefix against routing tables, traffic engineering (TE) database, and/or any database that reflects the current status of the network topology. If the prefix is reachable and is one hop away from the current router, the router should send out the Path message as it is. Otherwise, there is a possibility that the link or node associated by the prefix has experienced a failure. The router SHOULD determine this by searching for an existing bypass LSP that is protecting the prefix. If the protected LSP desires link protection, the destination of the bypass LSP (i.e. MP) is considered as the router that owns the prefix. If the LSP desires node protection with the "node protection desired" flag set in the SESSION_ATTRIBUTE object and the next-next ERO hop of the LSP is also a strict prefix, the MP is considered as the router that owns this prefix. Shen & Kamite Expires August 12, 2013 [Page 7] Internet-Draft RSVP Setup Protection February 2013 If a bypass LSP is not found by the above criteria, the router MUST originate a PathErr with code = 24 (routing problem) and sub-code = 2 (bad strict node). If a bypass LSP is found, the router MUST act as a PLR for setup protection, and reroute the protected LSP via the bypass LSP. If multiple satisfactory bypass LSPs exist, the PLR MAY select one based on bandwidth constraints or local policies. Specifically, if the protected LSP is a sub-LSP of a P2MP LSP, a bypass LSP that is protecting an existing sibling sub-LSP MUST be preferred, in order to minimize traffic duplication in the network. The PLR SHOULD NOT send the Path message of the protected LSP any further. Instead, it MUST create a backup LSP, and send a Path message of the backup LSP to the MP via the bypass LSP. The Path message is constructed by using the sender template specific method [RFC 4090]. In particular, it has the sender address in the SENDER_TEMPLATE object set to an address of the PLR. It MUST also carry an LSP_REQUIRED_ATTRIBUTES object with a Protected LSP Sender IPv4 Address TLV or Protected LSP Sender IPv6 Address TLV. Upon receiving a Resv message of the backup LSP from the MP, the PLR SHOULD brings up both of the backup LSP and the protected LSP. If the PLR is the ingress router of the protected LSP, the LSP has been set up successfully. If the PLR is a transit router, it MUST send a Resv message upstream for the protected LSP, with the "local protection available", "local protection in use", and optionally "node protection" and "bandwidth protection" flags set to 1, in the RRO hop corresponding to the PLR [RFC 4090]. The PLR SHOULD originate a PathErr message with code = 25 (notify error) and sub- code = 3 (tunnel locally repaired). The PLR SHOULD also install a forwarding entry for the protected LSP. In the typical case, the forwarding entry should result in two outgoing labels for packets. The inner label is the backup LSP's label, and the outer label is the bypass LSP's label. However, the forwarding entry may result in one or no label, if either or both of the backup LSP and the bypass LSP have the Implicit NULL label. If the PLR receives a PathErr message when signaling the backup LSP, the PLR MUST NOT bring up the backup LSP or the protected LSP. If the PLR is a transit router of the protected LSP, it MUST send a PathErr message upstream for the protected LSP. Likewise, if the PLR receives a PathErr message of the backup LSP after the backup LSP and the primary LSP have previously been brought up, and the PLR is a transit router of the protected LSP, it MUST also send a PathErr message upstream for the protected LSP. Shen & Kamite Expires August 12, 2013 [Page 8] Internet-Draft RSVP Setup Protection February 2013 When the PLR receives a ResvTear message of the backup LSP, the PLR MUST bring down both the backup LSP and the protected LSP. If the PLR is a transit router of the protected LSP, it MUST send a ResvTear message upstream for the protected LSP. In any cases where the PLR needs to bring down the protected LSP due to a received PathTear message, an RSVP state time-out, a configuration change, an administrative command, etc, the PLR MUST also bring down the backup LSP by sending a PathTear message through the bypass LSP. 3.4. MP behavior When an MP receives the Path message of a backup LSP, it MUST realize the setup protection condition based on the presence of Protected LSP Sender IPv4 Address TLV or Protected LSP Sender IPv6 Address TLV in LSP_REQUIRED_ATTRIBUTES object. If setup protection mode is disabled on the MP, it MUST reject the Path message, by sending a PathErr with code = 2 (policy control failure) to the PLR. Otherwise, the MP MUST terminate the backup LSP and re-create the protected LSP. If the MP is the egress router of the protected LSP, it MUST also terminate the protected LSP. If the MP is a transit router of the LSP, it MUST send a Path message downstream for the protected LSP. The Path message has the sender address in SENDER_TEMPLATE object set to the original address of the ingress router, based on the above received Protected LSP Sender IPv4 Address TLV or Protected LSP Sender IPv6 Address TLV. The Path message MUST NOT carry any Protected LSP Sender IPv4 Address TLV or Protected LSP Sender IPv6 Address TLV in LSP_REQUIRED_ATTRIBUTES object. The MP MUST allocate a label for the backup LSP, and distribute it to the PLR via Resv message of the backup LSP. If the protected LSP is a sub-LSP of a P2MP LSP and there is an existing sibling sub-LSP whose backup LSP is tunneled through the same bypass LSP, the MP MUST allocate the same label as the sibling sub-LSP, in order to avoid traffic duplication at the PLR. When the MP receives a PathTear message for the backup LSP, it MUST bring down both the backup LSP and the protected LSP. If the MP is a transit router of the protected LSP, it MUST send a PathTear message downstream for the protected LSP. In any cases where the MP receives or originates a PathErr or ResvTear message for the protected LSP, the MP MUST translate the message to a same type of message for the backup LSP and send it to Shen & Kamite Expires August 12, 2013 [Page 9] Internet-Draft RSVP Setup Protection February 2013 the PLR. 3.5. Local Revertive Mode When the failed link or node is restored, the PLR MAY revert the protected LSP to its desired primary path, by following the procedure of local revertive mode described in [RFC 4090]. 4. IANA Considerations This document defines a new flag for the Attribute Flags TLV, which is carried in the LSP_ATTRIBUTES Object of Path message. This flag is used to communicate whether setup protection is desired for an LSP. The value of the new flag needs to be assigned by IANA. Setup Protection Desired: TBD This document defines two new RSVP Attributes TLVs, which are carried in the LSP_REQUIRED_ATTRIBUTES object of Path message. The values of the new types need to be assigned by IANA. Protected LSP Sender IPv4 Address TLV Protected LSP Sender IPv6 Address TLV 5. Security Considerations The security considerations discussed in RFC 3209, RFC 4090 and RFC 4875 apply to this document. 6. Acknowledgements Thanks to Rahul Aggarwal, Disha Chopra, and Nischal Sheth for their contribution. 7. References 7.1. Normative References [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., Shen & Kamite Expires August 12, 2013 [Page 10] Internet-Draft RSVP Setup Protection February 2013 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi- Protocol Label Switching (GMPLS) Signaling Constraint- based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. 7.2. Informative References [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. Authors' Addresses Yimin Shen Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Phone: +1 9785890722 Email: yshen@juniper.net Shen & Kamite Expires August 12, 2013 [Page 11] Internet-Draft RSVP Setup Protection February 2013 Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan Email: y.kamite@ntt.com Shen & Kamite Expires August 12, 2013 [Page 12]