TEAS Working Group R. Gandhi, Ed. Internet-Draft Cisco Systems, Inc. Intended Status: Standards Track H. Shah Expires: September 11, 2017 Ciena Jeremy Whittaker Verizon March 10, 2017 Fast Reroute Procedures For Associated Bidirectional Label Switched Paths (LSPs) draft-gandhishah-teas-assoc-corouted-bidir-04 Abstract Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional LSPs into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forward LSP. This document describes Fast Reroute (FRR) procedures for both single-sided and double-sided provisioned associated bidirectional LSPs. The FRR procedures are applicable to co-routed and non co-routed LSPs. For co-routed LSPs, the FRR procedures can ensure that traffic flows on co-routed paths in the forward and reverse directions after a failure event. 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." Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the Gandhi, et al. Expires September 11, 2017 [Page 1] Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017 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 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. Conventions Used in This Document . . . . . . . . . . . . . . 3 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.1. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 4 3.2. Bidirectional LSP Association At Mid-Points . . . . . . . 5 4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 6 4.1. Bidirectional LSP Fast Reroute . . . . . . . . . . . . . . 6 4.2. Bidirectional LSP Association At Mid-points . . . . . . . 7 5. Message and Object Definitions . . . . . . . . . . . . . . . . 7 5.1. Extended ASSOCIATION Object . . . . . . . . . . . . . . . 7 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Gandhi, et al. Expires September 11, 2017 [Page 2] Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017 1. Introduction The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION Object is specified in [RFC6780] which can be used generically to associate (G)Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). [RFC7551] defines mechanisms for binding two point-to- point unidirectional LSPs [RFC3209] into an associated bidirectional LSP. There are two models described in [RFC7551] for provisioning an associated bidirectional LSP, single-sided and double-sided. In both models, the reverse LSP of the bidirectional LSP may or may not be co-routed and follow the same path as its forward LSP. [GMPLS-FRR] defines Fast Reroute (FRR) procedure for GMPLS signaled LSPs to co-ordinate bypass tunnel assignments in the forward and reverse directions. The mechanisms defined in [GMPLS-FRR] are applicable to FRR of associated bidirectional LSPs. In packet transport networks, there are requirements where the reverse LSP of a bidirectional LSP needs to follow the same path as its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370] architecture facilitates the co-routed bidirectional LSP by using the GMPLS extensions [RFC3473] to achieve congruent paths. However, the RSVP association signaling allows to enable co-routed bidirectional LSPs without having to deploy GMPLS extensions in the existing networks. The association signaling also allows to take advantage of the existing Traffic Engineering (TE) and FRR mechanisms in the network. This document describes FRR procedures for both single-sided and double-sided provisioned associated bidirectional LSPs. The FRR procedures are applicable to co-routed and non co-routed LSPs. For co-routed LSPs, the FRR procedures can ensure that traffic flows on co-routed paths in the forward and reverse directions after a failure event. 2. Conventions Used in This Document 2.1. Key Word Definitions 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 [RFC2119]. 2.2. Terminology The reader is assumed to be familiar with the terminology in [RFC2205], [RFC3209], [RFC4090] and [RFC7551]. Gandhi, et al. Expires September 11, 2017 [Page 3] Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017 2.2.1. Reverse Co-routed Unidirectional LSPs Two reverse unidirectional point-to-point (P2P) LSPs are setup in the opposite directions between a pair of source and destination nodes to form an associated bidirectional LSP. A reverse unidirectional LSP originates on the same node where the forward unidirectional LSP terminates, and it terminates on the same node where the forward unidirectional LSP originates. A reverse co-routed unidirectional LSP traverses along the same path of the forward direction unidirectional LSP in the opposite direction. 3. Overview As specified in [RFC7551], in the single-sided provisioning case, the RSVP TE tunnel is configured only on one endpoint node of the bidirectional LSP. An LSP for this tunnel is initiated by the originating endpoint with (Extended) ASSOCIATION Object containing Association Type set to "single-sided associated bidirectional LSP" and REVERSE_LSP Object inserted in the Path message. The remote endpoint then creates the corresponding reverse TE tunnel and signals the reverse LSP in response using the information from the REVERSE_LSP Object and other objects present in the received Path message. As specified in [RFC7551], in the double-sided provisioning case, the RSVP TE tunnel is configured on both endpoint nodes of the bidirectional LSP. Both forward and reverse LSPs are initiated independently by the two endpoints with (Extended) ASSOCIATION Object containing Association Type set to "double-sided associated bidirectional LSP". In both single-sided and double-sided provisioned bidirectional LSPs, the reverse LSP may or may not be congruent (i.e. co-routed) and follow the same path as its forward LSP. In the case of single-sided provisioned LSP, the originating LSP with REVERSE_LSP Object is identified as a forward LSP. In the case of double-sided provisioned LSP, the LSP originating from the higher node address (as source) and terminating on the lower node address (as destination) is identified as a forward LSP. The reverse LSP of the bidirectional LSP traverses in the opposite direction of the forward LSP. Both single-sided and double-sided associated bidirectional LSPs require solutions to the following issues for fast reroute. 3.1. Fast Reroute Bypass Tunnel Assignment In order to ensure that the traffic flows on a co-routed path after a link or node failure on the protected LSP path, the mid-point Point Gandhi, et al. Expires September 11, 2017 [Page 4] Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017 of Local Repair (PLR) nodes need to assign matching bidirectional bypass tunnels for fast reroute. Even for a non co-routed bidirectional LSP, it is desired that the same bidirectional bypass tunnel is used in both directions of the protected LSP. Such bypass assignment requires co-ordination between the forward and reverse direction PLR nodes when more than one bypass tunnels are present on a PLR node. <-- Bypass N --> +-----+ +-----+ | H +---------+ I | +--+--+ +--+--+ | | | | LSP1 --> | LSP1 --> | LSP1 --> LSP1 --> +----+ +--+--+ +--+--+ +----+ +----+ | A +---------+ B +----X----+ C +---------+ D +---------+ E | +----+ +--+--+ +--+--+ +----+ +----+ <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 | | | | +--+--+ +--+--+ | F +---------+ G | +-----+ +-----+ <-- Bypass S --> Figure 1: Multiple Bidirectional Bypass Tunnels As shown in Figure 1, there are two bypass tunnels available, Bypass N on path B-H-I-C and Bypass S on path B-F-G-C. The mid-point PLR nodes B and C need to co-ordinate bypass tunnel assignment to ensure that traffic in both directions flow through either on the Bypass N path B-H-I-C or the Bypass S path B-F-G-C, after the link B-C failure. 3.2. Bidirectional LSP Association At Mid-Points In packet transport networks, a restoration LSP is signaled after a link failure on the protected LSP and the protected LSP may or may not be torn down [GMPLS-REST]. In this case, multiple forward and reverse LSPs of a bidirectional LSP may be present at mid-point nodes with identical (Extended) ASSOCIATION Objects. This creates an ambiguity at mid-point nodes to identify the correct associated LSP pair for fast reroute bypass assignment (e.g. during the recovery phase of RSVP graceful restart procedure). Gandhi, et al. Expires September 11, 2017 [Page 5] Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017 LSP3 --> LSP3 --> LSP3 --> LSP1 --> LSP1 --> LSP1 --> LSP1 --> +----+ +-----+ +-----+ +----+ +----+ | A +---------+ B +----X----+ C +---------+ D +---------+ E | +----+ +--+--+ +--+--+ +----+ +----+ <-- LSP2 | <-- LSP2 | <-- LSP2 <-- LSP2 <-- LSP4 | | <-- LSP4 <-- LSP4 | | | LSP3 --> | +--+--+ +--+--+ | F +---------+ G | +-----+ +-----+ <-- LSP4 Figure 2: Restoration LSP Set-up After Link Failure As shown in Figure 2, protected LSPs LSP1 and LSP2 are an associated LSP pair, similarly restoration LSPs LSP3 and LSP4 are an associated LSP pair, both pairs belong to the same associated bidirectional LSP and carry identical (Extended) ASSOCIATION Objects. In this example, mid-point node D may mistakenly associate LSP1 with reverse LSP4 instead of reverse LSP3 due to the matching (Extended) ASSOCIATION Objects. This may cause the bidirectional LSP to become non co- routed. Since a reverse LSP reflects the bypass tunnel assignment received in the forward LSP, this can also lead to undesired bypass tunnel assignments. 4. Signaling Procedure 4.1. Bidirectional LSP Fast Reroute The mechanisms defined in [GMPLS-FRR] are used for fast reroute of both single-sided and double-sided associated bidirectional LSPs as following. o As described in [GMPLS-FRR], BYPASS_ASSIGNMENT subobject is signaled in the RRO of the Path message to co-ordinate bypass tunnel assignment between the forward and reverse direction PLR nodes. A BYPASS_ASSIGNMENT subobject MUST be added by the forward direction PLR node in the Path message of the forward LSP to indicate the bypass tunnel assigned. o The forward direction PLR node always initiates the bypass tunnel assignment for the forward LSP. The reverse direction PLR (forward direction LSP Merge Point (MP)) node simply reflects the bypass tunnel assignment for the reverse direction LSP. Gandhi, et al. Expires September 11, 2017 [Page 6] Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017 o After a link or node failure, the PLR nodes in both forward and reverse directions trigger fast reroute independently using the procedures defined in [RFC4090]. o When using a node protection bypass tunnel, asymmetry of paths can occur in the forward and reverse directions of the bidirectional LSP after a link failure when using co-routed LSPs [GMPLS-FRR]. This can be corrected using the re-corouting procedure defined in [GMPLS-FRR]. Unlike GMPLS LSPs, the asymmetry of paths in the forward and reverse directions does not result in RSVP soft-state time-out with the associated bidirectional LSPs. 4.2. Bidirectional LSP Association At Mid-points In order to associate the correct LSPs at a mid-point node, an endpoint node MUST signal Extended ASSOCIATION Object and add unique Extended Association ID for each associated forward and reverse LSP pair forming the bidirectional LSP. As an example, an endpoint node MAY set the Extended Association ID to the value specified in Section 5.1 of this document. o For single-sided provisioned bidirectional LSPs [RFC7551], the originating endpoint signals the Extended ASSOCIATION Object with a unique Extended Association ID. The remote endpoint copies the contents of the received Extended ASSOCIATION Object including the Extended Association ID in the RSVP Path message of the reverse LSP's Extended ASSOCIATION Object. o For double-sided provisioned bidirectional LSPs [RFC7551], both endpoints need to ensure that the bidirectional LSP has a unique Extended ASSOCIATION Object for each forward and reverse LSP pair by provisioning appropriate Extended Association IDs signaled by them. 5. Message and Object Definitions 5.1. Extended ASSOCIATION Object The Extended Association ID in the Extended ASSOCIATION Object can be set to the value specified as following to uniquely identify associated forward and reverse LSP pair of a bidirectional LSP. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 LSP Source Address | Gandhi, et al. Expires September 11, 2017 [Page 7] Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Variable Length ID : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPv4 Extended Association ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 LSP Source Address | + + | (16 bytes) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Variable Length ID : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: IPv6 Extended Association ID LSP Source Address IPv4/IPv6 source address of the forward LSP. LSP-ID 16-bits LSP-ID of the forward LSP. Variable Length ID Variable length ID inserted by the endpoint node of the associated bidirectional LSP [RFC6780]. 6. Compatibility Gandhi, et al. Expires September 11, 2017 [Page 8] Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017 This document describes the procedures for fast reroute for associated bidirectional LSPs. Operators wishing to use this function SHOULD ensure that it is supported on the nodes on the LSP path. 7. Security Considerations This document uses signaling mechanisms defined in [RFC7551] and [GMPLS-FRR] and does not introduce any additional security considerations other than already covered in [RFC7551], [GMPLS-FRR] and the MPLS/GMPLS security framework [RFC5920]. 8. IANA Considerations This document does not make any request for IANA action. Gandhi, et al. Expires September 11, 2017 [Page 9] Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP Association Object Extensions", RFC 6780, October 2012. [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE Extensions for Associated Bidirectional LSPs", RFC 7551, May 2015. [GMPLS-FRR] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., Bhatia, M., "Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs", draft-ietf-teas-gmpls-lsp-fastreroute, work in progress. 9.2. Informative 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. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. Gray, "MPLS Transport Profile (MPLS-TP) Control Plane Framework", RFC 6373, September 2011. [GMPLS-REST] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., Gandhi, et al. Expires September 11, 2017 [Page 10] Internet-Draft FRR For Associated Bidirectional LSPs March 10, 2017 Brzozowski, P., "RSVP-TE Signaling Procedure for End-to- End GMPLS Restoration and Resource Sharing", draft-ietf- teas-gmpls-resource-sharing-proc, work in progress. Authors' Addresses Rakesh Gandhi (editor) Cisco Systems, Inc. EMail: rgandhi@cisco.com Himanshu Shah Ciena EMail: hshah@ciena.com Jeremy Whittaker Verizon EMail: jeremy.whittaker@verizon.com Gandhi, et al. Expires September 11, 2017 [Page 11]