TEAS Working Group Xian Zhang Internet-Draft Haomian Zheng, Ed. Intended Status: Informational Huawei Expires: February 5, 2016 Rakesh Gandhi, Ed. Zafar Ali Gabriele Maria Galimberti Cisco Systems, Inc. Pawel Brzozowski ADVA Optical August 4, 2015 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing draft-ietf-teas-gmpls-resource-sharing-proc-02 Abstract In transport networks, there are requirements where Generalized Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs. This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document clarifies the RSVP-TE signaling procedure to support resource sharing-based setup and teardown of LSPs as well as LSP reversion. No new extensions are defined by this document, and it is strictly informative in nature. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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." Zhang, et al Expires February 5, 2016 [Page 1] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 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. Copyright Notice Copyright (c) 2015 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 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . . 4 2.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . . 5 2.3. Resource Sharing By Restoration LSP . . . . . . . . . . . 6 3. RSVP-TE Signaling Procedure . . . . . . . . . . . . . . . . . 6 3.1. Restoration LSP Association . . . . . . . . . . . . . . . 6 3.2. Resource Sharing-based Restoration LSP Setup . . . . . . . 7 3.3. LSP Reversion . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Make-while-break Reversion . . . . . . . . . . . . . . 8 3.3.2. Make-before-break Reversion . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Zhang, et al Expires February 5, 2016 [Page 2] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 1. Introduction Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] defines a set of protocols, including Open Shortest Path First - Traffic Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used to setup Label Switched Paths (LSPs) in transport networks. The GMPLS protocol extends MPLS to support interfaces capable of Time Division Multiplexing (TDM), Lambda Switching and Fiber Switching. These switching technologies provide several protection schemes [RFC4426][RFC4427] (e.g., 1+1, 1:N and M:N). Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling has been extended to support various GMPLS recovery schemes, such as end-to-end recovery [RFC4872] and segment recovery [RFC4873]. As described in [RFC6689], ASSOCIATION object can be used to identify the LSPs for restoration using Association Type set to "Recovery" [RFC4872]. [RFC6689] Section 2.2 reviews the procedure for providing LSP associations for GMPLS end-to-end recovery and covers the schemes where the failed working LSP and/or protecting LSP are torn down. In GMPLS end-to-end recovery schemes generally considered, restoration LSP is signaled after the failure has been detected and notified on the working LSP. For revertive recovery mode, a restoration LSP is signaled while working LSP and/or protecting LSP are not torn down in control plane due to a failure. In transport networks, as working LSPs are typically signaled over a nominal path, service providers would like to keep resources associated with the working LSPs reserved. This is to make sure that the service (working LSP) can be reverted to the nominal path when the failure is repaired to provide deterministic behavior and guaranteed Service Level Agreement (SLA). Following behaviors are not fully documented in the existing standards for LSP associations, resource sharing based LSP setup, teardown and LSP reversion in transport networks: o The procedure for providing LSP associations for the GMPLS recovery using restoration LSP where working and protecting LSPs are not torn down after the failure is not clearly documented. o In [RFC3209], the MBB method assumes the old and new LSPs share the SESSION object and signal Shared Explicit (SE) flag in SESSION_ATTRIBUTE object. According to [RFC6689], ASSOCIATION object with Association Type "Resource sharing" enables the sharing of resources across LSPs with different SESSION objects. However, existing documents do not mention the usage of SE flag for resource Zhang, et al Expires February 5, 2016 [Page 3] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 sharing with ASSOCIATION object. o As described in [RFC3209], Section 2.5, the purpose of make before break (MBB) is "not to disrupt traffic, or adversely impact network operations while TE tunnel rerouting is in progress". In transport networks, the label has a mapping into the data plane resource used and the nodes along the LSP need to send triggering commands to data plane for setting up cross-connections accordingly during the RSVP-TE signaling procedure. Due to the nature of transport networks, node may not be able to fulfill this purpose when sharing resources in some scenarios. o When using end-to-end recovery with revertive mode, methods for LSP reversion and resource sharing have not been described. This document reviews how the LSP association is to be provided for GMPLS end-to-end recovery when using restoration LSP where working and protecting LSP resources are kept reserved in the network after the failure. In addition, this document clarifies the signaling procedure for sharing resources during setup and teardown of LSPs as well as LSP reversion. This document is strictly informative in nature and does not define any RSVP-TE signaling extensions. 2. Overview The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and being considered in this document, "fully dynamic rerouting switches normal traffic to an alternate LSP that is not even partially established only after the working LSP failure occurs. The new alternate route is selected at the LSP head-end node, it may reuse resources of the failed LSP at intermediate nodes and may include additional intermediate nodes and/or links". Two examples, 1+R and 1+1+R are described in the following sections. 2.1. 1+R Restoration One example of the recovery scheme considered in this document is 1+R recovery. The 1+R recovery is exemplified in Figure 1. In this example, working LSP on path A-B-C-Z is pre-established. Typically after a failure detection and notification on the working LSP, a second LSP on path A-H-I-J-Z is established as a restoration LSP. Unlike protection LSP, restoration LSP is signaled per need basis. Zhang, et al Expires February 5, 2016 [Page 4] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 +-----+ +-----+ +-----+ +-----+ | A +----+ B +-----+ C +-----+ Z | +--+--+ +-----+ +-----+ +--+--+ \ / \ / +--+--+ +-----+ +--+--+ | H +-------+ I +--------+ J | +-----+ +-----+ +-----+ Figure 1: An Example of 1+R Recovery Scheme During failure switchover with 1+R recovery scheme, in general, working LSP resources are not released so that working and restoration LSPs coexist in the network. Nonetheless, working and restoration LSPs can share network resources. Typically when failure is recovered on the working LSP, restoration LSP is no longer required and torn down, while the traffic is reverted to the original working LSP. 2.2. 1+1+R Restoration Another example of the recovery scheme considered in this document is 1+1+R. In 1+1+R, a restoration LSP is signaled for the working LSP and/or the protecting LSP after the failure has been detected, and this recovery is exemplified in Figure 2. +-----+ +-----+ +-----+ | D +-------+ E +--------+ F | +--+--+ +-----+ +--+--+ / \ / \ +--+--+ +-----+ +-----+ +--+--+ | A +----+ B +-----+ C +-----+ Z | +--+--+ +-----+ +-----+ +--+--+ \ / \ / +--+--+ +-----+ +--+--+ | H +-------+ I +--------+ J | +-----+ +-----+ +-----+ Figure 2: An Example of 1+1+R Recovery Scheme In this example, working LSP on path A-B-C-Z and protecting LSP on path A-D-E-F-Z are pre-established. After a failure detection and notification on a working LSP or protecting LSP, a third LSP on path A-H-I-J-Z is established as a restoration LSP. The restoration LSP in this case provides protection against a second order failure. Zhang, et al Expires February 5, 2016 [Page 5] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 During failure switchover with 1+1+R recovery scheme, in general, failed LSP resources are not released so that working, protecting and restoration LSPs coexist in the network. Nonetheless, restoration LSP with working LSP it is restoring as well as restoration LSP with protecting LSP it is restoring can share network resources. Typically, restoration LSP is torn down when the failure on the working or protecting LSP is repaired and while the traffic is reverted to the original LSP. 2.3. Resource Sharing By Restoration LSP +-----+ +-----+ | F +------+ G +--------+ +--+--+ +-----+ | | | | | +-----+ +-----+ +--+--+ +-----+ +--+--+ | A +----+ B +-----+ C +--X---+ D +-----+ E | +-----+ +-----+ +-----+ +-----+ +-----+ Figure 3: Resource Sharing in 1+R Recovery Scheme Using the network shown in Figure 3 as an example, LSP1 (A-B-C-D-E) is the working LSP and it allows for resource sharing when the LSP is dynamically rerouted due to link failure. Upon detecting the failure of a link along the LSP1, e.g. Link C-D, node A needs to decide which alternative path it will use to signal restoration LSP and reroute traffic. In this case, A-B-C-F-G-E is chosen as the restoration LSP path and the resources on the path segment A-B-C are re-used by this LSP when working LSP is not torn down as in 1+R recovery scheme. 3. RSVP-TE Signaling Procedure 3.1. Restoration LSP Association Where GMPLS end-to-end recovery scheme needs to employ restoration LSP while keeping resources for the working and/or protecting LSPs reserved in the network after the failure, restoration LSP is signaled with ASSOCIATION object that has Association Type set to "Recovery" [RFC4872] with the association ID set to the LSP ID of the LSP it is restoring. For example, when a restoration LSP is signaled for a working LSP, the ASSOCIATION object in the restoration LSP contains the association ID set to the LSP ID of the working LSP. Similarly, when a restoration LSP is signaled for a protecting LSP, the ASSOCIATION object in the restoration LSP contains the association ID set to the LSP ID of the protecting LSP. The procedure for signaling the PROTECTION object is specified in Zhang, et al Expires February 5, 2016 [Page 6] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 [RFC4872]. Specifically, restoration LSP being used as a working LSP is signaled with P bit cleared and being used as a protecting LSP is signaled with P bit set. 3.2. Resource Sharing-based Restoration LSP Setup GMPLS LSPs can share resources if they have Shared Explicit (SE) flag set in their SESSION_ATTRIBUTE objects and: o As defined in [RFC3209], LSPs have identical SESSION objects and/or o As defined in [RFC6689], LSPs have matching ASSOCIATION object with Association Type set to "Resource Sharing". LSPs in this case can have different SESSION objects i.e. different tunnel ID, source and destination. For LSP restoration upon failure, as explained in Section 11 of [RFC4872], reroute procedure may re-use existing resources. The behavior of the intermediate nodes during rerouting process to reconfigure cross-connections does not further impact the traffic since it has been interrupted due to the already failed LSP. The node behavior for setting up the restoration LSP can be categorized into the following three categories: Table 1: Node Behavior during Restoration LSP Setup ---------+--------------------------------------------------------- Category | Node Behavior during Restoration LSP Setup ---------+--------------------------------------------------------- C1 + Reusing existing resource on both input and output + interfaces (node A & B in Figure 3). + + This type of nodes only needs to book the existing + resources and no cross-connection setup + command is needed. ---------+--------------------------------------------------------- C2 + Reusing existing resource only on one of the interfaces, + either input or output interfaces and need to use new + resource on the other interface. (node C & E in Figure 3). + + This type of nodes needs to book the resources and send + the re-configuration cross-connection command to its + corresponding data plane node on the interfaces where new + resources are needed and re-use the + existing resources on the other interfaces. ---------+--------------------------------------------------------- C3 + Using new resources on both interfaces. Zhang, et al Expires February 5, 2016 [Page 7] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 + (node F & G in Figure 3). + + This type of nodes needs to book the new resources + and send the cross-connection setup + command on both interfaces. ---------+--------------------------------------------------------- Depending on whether the resource is re-used or not, the node behaviors differ. This deviates from normal LSP setup since some nodes do not need to re-configure the cross-connection, and it should not be viewed as an error. Also, the judgment whether the control plane node needs to send a cross-connection setup/modification command to its corresponding data plane node(s) relies on the check whether the LSPs are sharing resources. 3.3. LSP Reversion If the end-to-end LSP recovery is revertive, as described in Section 2, traffic can be reverted from the restoration LSP to the working or protecting LSP after its failure is recovered. The LSP reversion can be achieved using two methods: 1. Make-while-break reversion, where resources associated with working or protecting LSP are reconfigured while removing reservations for the restoration LSP. 2. Make-before-break reversion, where resources associated with working or protecting LSP are reconfigured before removing the restoration LSP. In transport networks, both of the above reversion methods will result in some traffic disruption when the restoration LSP and the LSP being restored are sharing resources and the cross-connections need to be reconfigured on intermediate nodes. 3.3.1. Make-while-break Reversion In this reversion method, restoration LSP is simply requested to be deleted by the head-end. Removing reservations for restoration LSP triggers reconfiguration of resources associated with working or protecting LSP on every node where resources are shared. Whenever reservation for restoration LSP is removed from a node, data plane configuration changes to reflect reservations of working or protection LSP as signaling progresses. Eventually, after the whole restoration LSP is deleted, data plane configuration will fully match working or protecting LSP reservations on the whole path. Thus reversion is complete. Zhang, et al Expires February 5, 2016 [Page 8] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 Make-while-break, while being relatively simple in its logic, has few limitations as follows which may not be acceptable in some networks: o No rollback Deletion of restoration LSPs is not a revertive process. If for some reason reconfiguration of data plane on one of the nodes to match working or protection LSP reservations fails, falling back to restoration LSP is no longer an option, as its state might have already been removed from other nodes. o No completion guarantee Deletion of an LSP provides no guarantees of completion. In particular, if RSVP packets are lost due to nodal or DCN failures it is possible for an LSP to be only partially deleted. To mitigate this, RSVP could maintain soft state reservations and hence eventually remove remaining reservations due to refresh timeouts. This approach is not feasible in transport networks however, where control and data channels are often separated and hence soft state reservations are not useful. Finally, one could argue that graceful LSP deletion [RFC3473] would provide guarantee of completion. While this is true for most cases, many implementations will time out graceful deletion if LSP is not removed within certain amount of time, e.g. due to a transit node fault. After that, deletion procedures which provide no completion guarantees will be attempted. Hence, in corner cases completion guarantee cannot be provided. o No explicit notification of completion to head-end node In some cases, it may be useful for a head-end node to know when the data plane has been reconfigured to match working or protection LSP reservations. This knowledge could be used for initiating operations like enabling alarm monitoring, power equalization and others. Unfortunately, for the reasons mentioned above, make-while-break reversion lacks such explicit notification. 3.3.2. Make-before-break Reversion This reversion method can be used to overcome limitations of make-while-break reversion. It is similar in spirit to MBB concept used for re-optimization. Instead of relying on deletion of restoration LSP, head-end chooses to establish a new LSP to reconfigure resources on the working or protection LSP path, and uses identical ASSOCIATION and PROTECTION objects from the LSP it is replacing. Only if setup of this LSP is successful will other Zhang, et al Expires February 5, 2016 [Page 9] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 (restoration and working/protecting) LSPs be deleted by the head-end. MBB reversion consists of two parts: A) Make part: Creating a new reversion LSP following working or protection LSP's path. Reversion LSP is sharing resources both with working and restoration LSPs. As reversion LSP is created, resources are reconfigured to match its reservations. Hence, after reversion LSP is created, data plane configuration essentially reflects working or protecting LSP reservations. B) Break part: After "make" part is finished, working and restoration LSPs are torn down. Removing reservations for working and restoration LSPs does not cause any resource reconfiguration on reversion LSP's path - nodes follow same procedures as for "break" part of any MBB operation. Hence, after working and restoration LSPs are removed, data plane configuration is exactly the same as before starting restoration. Thus reversion is complete. MBB reversion uses make-before-break characteristics to overcome challenges related to make-while-break reversion as follow: o Rollback If "make" part fails, (existing) restoration LSP will still be used to carry existing traffic. Same logic applies here as for any MBB operation failure. o Completion guarantee LSP setup is resilient against RSVP message loss, as Path and Resv messages are refreshed periodically. Hence, given that network recovers its DCN eventually, reversion LSP setup is guaranteed to finish with either success or failure. o Explicit notification of completion to head-end node Head-end knows that data plane has been reconfigured to match working or protection LSP reservations on intermediate nodes when it receives Resv for the reversion LSP. Zhang, et al Expires February 5, 2016 [Page 10] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 4. Security Considerations This document reviews procedures defined in [RFC3209] [RFC4872] [RFC4873] and [RFC6689] and does not define any new procedure. This document does not introduce any new security issues other than those already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6689]. 5. IANA Considerations This informational document does not make any request for IANA action. 6. Acknowledgement The authors would like to thank George Swallow for the discussions on the GMPLS restoration. Zhang, et al Expires February 5, 2016 [Page 11] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 7. References 7.1. Normative References [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4872] J.P. Lang et al, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] L. Berger et al, "GMPLS Segment Recovery", RFC 4873, May 2007. [RFC6689] L. Berger, "Usage of the RSVP ASSOCIATION Object", RFC 6689, July 2012. 7.2. Informative References [PCEP-RSO] X. Zhang, et al, "Extensions to Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation", work in progress, February 2014. [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4203] Kompella, K., and Rekhter, Y., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D., "Generalized Multiprotocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006. [RFC4427] Mannie, E., and Papadimitriou, D., "Recovery (Protection and Restoration) Terminology for Generalized Multi- Protocol Label Switching", RFC 4427, March 2006. Zhang, et al Expires February 5, 2016 [Page 12] Internet-Draft GMPLS Restoration and Resource Sharing August 4, 2015 8. Authors' Addresses Xian Zhang Huawei Technologies F3-1-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China EMail: zhang.xian@huawei.com Haomian Zheng (editor) Huawei Technologies F3-1-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China EMail: zhenghaomian@huawei.com Rakesh Gandhi (editor) Cisco Systems, Inc. EMail: rgandhi@cisco.com Zafar Ali Cisco Systems, Inc. EMail: zali@cisco.com Gabriele Maria Galimberti Cisco Systems, Inc. EMail: ggalimbe@cisco.com Pawel Brzozowski ADVA Optical EMail: PBrzozowski@advaoptical.com Zhang, et al Expires February 5, 2016 [Page 13]