CCAMP Working Group Xian Zhang Internet-Draft Haomian Zheng, Ed. Intended Status: Informational Huawei Expires: June 11, 2015 Rakesh Gandhi, Ed. Zafar Ali Gabriele Maria Galimberti Cisco Systems, Inc. Pawel Brzozowski ADVA Optical December 8, 2014 RSVP-TE Signaling Procedure for GMPLS Restoration and Resource Sharing- based LSP Setup and Teardown draft-ietf-teas-gmpls-resource-sharing-proc-00 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 restoration 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 when using restoration LSP where failed LSP is not torn down. This document compliments existing standards by explaining the missing pieces of information during the RSVP-TE signaling procedure in support of resource sharing-based LSP setup/teardown in GMPLS-controlled circuit networks. No new procedures or mechanisms 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 Zhang, et al Expires June 11, 2015 [Page 1] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 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. Copyright Notice Copyright (c) 2014 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. GMPLS Restoration . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . . 4 2.1.2. 1+1+R Restoration . . . . . . . . . . . . . . . . . . . 5 2.2. Resource Sharing-based LSP Setup/Teardown . . . . . . . . . 6 3. RSVP-TE Signaling For Restoration LSP Association . . . . . . . 7 4. RSVP-TE Signaling For Resource Sharing During LSP Setup/Teardown . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. LSPs with Identical Tunnel ID . . . . . . . . . . . . . . . 8 4.1.1. Restoration LSP Setup . . . . . . . . . . . . . . . . . 8 4.1.2. LSP Reversion . . . . . . . . . . . . . . . . . . . . . 10 4.1.2.1. Make-while-break Reversion . . . . . . . . . . . . 11 4.1.2.2. Make-before-break Reversion . . . . . . . . . . . . 13 4.1.3. Re-optimization LSP Setup and Reversion . . . . . . . . 15 4.2. LSPs with Different Tunnel IDs . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Zhang, et al Expires June 11, 2015 [Page 2] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 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 create Label Switched Paths (LSPs) in a number of deployment scenarios with various transport technologies. The GMPLS protocol set extends MPLS, which supports only Packet Switch Capable (PSC) and Layer 2 Switch Capable interfaces (L2SC), to also cater for interfaces capable of Time Division Multiplexing (TDM), Lambda Switching (LSC) and Fiber Switching (FSC). 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 [RFC4872][RFC4873], to establish Label Switched Paths (LSPs), typically for working LSP and protecting LSP. [RFC4427] Section 7 specifies various schemes for GMPLS recovery. In GMPLS recovery schemes generally considered, restoration LSP is signaled after the failure has been detected and notified on the working LSP. In non-revertive recovery mode, working LSP is assumed to be removed from the network before restoration LSP is signaled. 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 use the nominal path when the failure is repaired to provide deterministic behavior and guaranteed Service Level Agreement (SLA). Consequently, revertive recovery mode is usually preferred by recovery schemes used in transport networks. The Make-Before-Break (MBB) mechanisms exploiting the Shared-Explicit (SE) reservation style can be employed in MPLS networks to avoid double booking of resource during the process of LSP re-optimization as specified in [RFC3209]. This method is also used in GMPLS- controlled networks [RFC4872] [RFC4873] for end-to-end and segment recovery of LSPs. This was further generalized to support resource sharing oriented applications in MPLS networks as well as non-LSP contexts, as specified in [RFC6780]. Due to the fact that the features of GMPLS-controlled networks (specifically for TDM, LSC and FSC), are not identical to that of the MPLS networks, additional considerations for resource sharing based LSP association are needed. As defined in [RFC4872] and being considered in this document, "fully dynamic rerouting switches normal Zhang, et al Expires June 11, 2015 [Page 3] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 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". During the signaling procedure for resource sharing based LSP setup/teardown, the behaviors of the nodes along the path may be different from that in the MPLS networks as well as the effect it may have on the traffic delivery. As described in [RFC6689], ASSOCIATION Object is used to identify the LSPs for restoration using association type "Recovery" [RFC4872] and for resource sharing using association type "Resource Sharing" [RFC4873]. Following section describes the problem statements for the GMPLS restoration and resource sharing based LSP setup and teardown. 2. Problem Statement Problem statements for the GMPLS restoration schemes and resource sharing-based LSP setup and teardown are described in this section. 2.1. GMPLS Restoration 2.1.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. +-----+ +-----+ +-----+ +-----+ | 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 and working and restoration LSPs coexist in the network. Nonetheless, working and restoration Zhang, et al Expires June 11, 2015 [Page 4] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 LSPs can share network resources. Typically when failure is recovered on the working LSP, restoration LSP is no longer required and torn down (e.g., revertive mode). 2.1.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 notified on the working LSP or the protecting LSP. The 1+1+R 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. Restoration LSP is torn down when the failure on the working or protecting LSP is repaired. [RFC4872] Section 14 defines PROTECTION Object for GMPLS recovery signaling. As defined, the PROTECTION Object is used to identify primary and secondary LSPs using S bit and protecting and working LSPs using P bit. Furthermore, [RFC4872] defines the usage of ASSOCIATION Object for associating GMPLS working and protecting LSPs. [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. This document reviews how the LSP association is to be provided for GMPLS end-to-end recovery when using restoration LSP where working Zhang, et al Expires June 11, 2015 [Page 5] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 and protecting LSP resources are kept reserved in the network after the failure. 2.2. Resource Sharing-based LSP Setup/Teardown +-----+ +-----+ | F +------+ G +--------+ +--+--+ +-----+ | | | | | +-----+ +-----+ +--+--+ +-----+ +--+--+ | A +----+ B +-----+ C +--X---+ D +-----+ E | +-----+ +-----+ +-----+ +-----+ +-----+ Figure 3: A Simple OTN Network Using the Optical Transport Network (OTN) topology shown in Figure 3 as an example, GMPLS-controlled circuit 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 on which alternate path it will establish an LSP to reroute the traffic. In this case, A-B-C-F-G-E is chosen as the alternative path for the LSP and the resources on the path segment A-B-C are re-used by this LSP. Since this is an OTN network, which is different from the packet-switching network, the label has a mapping into the data plane resource used (e.g. wavelength) and also the nodes along the path need to send triggering commands to data plane nodes for setting up cross-connection accordingly during the RSVP-TE signaling process. In this case, the following issues are left un-described in the existing standards for resource sharing based LSP setup/teardown in GMPLS-controlled circuit networks: - Reservation style Shared-Explicit (SE) as defined in [RFC3209] may not be applicable due to the nature of the GMPLS-controlled circuits. It is not clear how reservation style is to be used by the GMPLS LSPs for resource sharing. - As described in [RFC3209], the purpose of Make-Before-Break (MBB) is to "not disrupt traffic or adversely impact network operations while TE tunnel rerouting is in progress". Due to the nature of the GMPLS-controlled circuit networks, this may not be fulfilled under certain scenarios. Thus, the name "Make-Before-Break" may no longer hold true. - The existing MBB method may not be sufficient to support LSP setup and teardown with resource sharing. Zhang, et al Expires June 11, 2015 [Page 6] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 - In [RFC3209], the MBB method assumes the old and new LSPs share the same tunnel ID (i.e., sharing the same source and destination nodes). [RFC4873] does not impose this constraint but limit the resource sharing usage in LSP recoveries only. [RFC6780] generalizes the resource sharing application, based on the ASSOCIATION Object, to be useful in MPLS networks as well as in non-LSP association such as Voice Call-Waiting. Recently, there are also requirements to generalize resource sharing of LSPs with different tunnel IDs, such as the one mentioned in [PCEP-RSO] and LSPs with LSP-stitching across multi-domains. In this case, how the signaling process can make intermediate nodes aware of the resource sharing constraint and behave accordingly is an issue that needs to be described. - The node behavior during traffic reversion in the GMPLS-controlled circuit network is missing and should be clarified. This document reviews the signaling procedure for resource sharing-based LSP setup and teardown for GMPLS-based circuits in OTN networks. This includes the node behavior description, besides clarifying some un-discussed points for this process. Two typical examples mentioned in this document are LSP restoration and LSP re- optimization, where it is desirable to share resources. This document does not define any RSVP-TE signaling extensions. If necessary, discussion is provided to identify potential extensions to the existing RSVP-TE protocol. It is expected that the extensions, if there are any, will be addressed in separate documents. 3. RSVP-TE Signaling For 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 [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. Zhang, et al Expires June 11, 2015 [Page 7] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 As discussed in Section 2 of this document, [RFC6689] Section 2.2 reviews the procedure for providing LSP associations for the GMPLS end-to-end recovery scheme using restoration LSP where the failed working LSP and/or protecting LSP are torn down. 4. RSVP-TE Signaling For Resource Sharing During LSP Setup/Teardown For LSP restoration upon failure, as explained in Section 11 of [RFC4872], the purpose of using MBB is to re-use existing resources. Thus, the behavior of the intermediate nodes during rerouting process will not further impact traffic since it has been interrupted due to the already broken working LSP. However, for the following two cases, the behavior of intermediate nodes may impact the traffic delivery: (1) LSP reversion; (2) LSP re-optimization. Another dimension that needs separate attention is how to correlate the two LSPs sharing resource. For the LSPs with the same Tunnel ID, [RFC4872] and reviewed in this section. For the LSPs with different Tunnel IDs, signaling procedure is clarified in Section 4.2 of this document. 4.1. LSPs with Identical Tunnel ID For resource sharing among LSPs with identical Tunnel IDs, SE flag and ASSOCIATION Object are used together. The SE flag is to enable resource sharing and the ASSOCIATION Object with association type "Resource Sharing" [RFC4873] is to identify the associated LSPs. As a first step, in order to allow resource sharing, the original LSP setup should explicitly carry the SE flag in the SESSION_ATTRIBUTE Object during the initial LSP setup, irrespective of the purpose of resource sharing. The basic signaling procedure for alternative LSP setup has been described by the existing standards. In [RFC3209], it describes the basic MBB signaling flow for MPLS-TE networks. [RFC4872] adds additional information when using MBB for LSP rerouting. As mentioned before, for LSP setup/teardown in GMPLS-controlled circuit networks, the network elements along the path need to send cross-connection setup/teardown commands to data plane node(s) either during the PATH message forwarding phase or the RESV message forwarding phase. 4.1.1. Restoration LSP Setup For LSP restoration, the complete signaling flow processes for both Zhang, et al Expires June 11, 2015 [Page 8] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 LSP restorations upon failure and LSP reversion upon link failure recovery are described in this section. 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. + This type of nodes only needs to book the existing + resource when receiving the PATH message and no cross- + connection setup command is needed when receiving + the RESV message. ---------+---------------------------------------------------------- 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. + This type of nodes needs to book the resources on the + interface where new resource are needed and re-use the + existing resource on the other interface when it receives + the PATH message. Upon receiving the RESV message, it + needs to send the re-configuration the cross-connection + command to its corresponding data plane node. ---------+--------------------------------------------------------- C3 + Using new resource on both interfaces. + This type of nodes needs to book the new resource when + receiving PATH and send the cross-connection setup + command upon receiving RESV. ---------+--------------------------------------------------------- For LSP rerouting upon working LSP failure, using the network shown in Figure 3 as an example. Working LSP: A-B-C-D-E Restoration LSP: A-B-C-F-G-E The restoration LSP may be calculated by the head-end node or a Path Computation Element (PCE) [RFC4655]. Assuming that the cross-connection configuration command is sent by the control plane nodes during the RESV forwarding phrase, the node behavior for setting up the alternative LSP can be classified into the following three categories as shown in Table 1. Zhang, et al Expires June 11, 2015 [Page 9] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 +---+ +---+ +---+ +---+ +---+ +---+ | A | | B | | C | | F | | G | | E | +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ | | | | | | | PATH | | | | | C1 +----------X+ C1 | | | | | | PATH | | | | | +----------X+ C2 | | | | | | PATH | | | | | +----------X+ C3 | | | | | | PATH | | | | | +----------X+ C3 | | | | | | PATH | | | | | +-----------X+ C2 | | | | | | | | | | | | | | | | | RESV | | | | | C3 +X-----------+ C2 | | | | RESV | | | | | C3 +X----------+ | | | | RESV | | | | | C2 +X----------+ | | | | RESV | | | | | C1 +X----------+ | | | | RESV | | | | | C1 +X----------+ | | | | Figure 4: Restoration LSP Setup Signaling Procedure As shown in Figure 4, 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 thus 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 following two cases holds true: (1) the PATH message received include a SE reservation style; (2) the PATH message identifies a LSP that sharing the same tunnel ID as the LSP to share resource with. For the second point, the processing rules and configuration of ASSOCIATION Object defined in [RFC4872] are followed. 4.1.2. LSP Reversion If the LSP rerouting is revertive, traffic can be reverted to the working or protecting LSP after its failure is recovered. From resource sharing perspective reversion can be divided into two types: Zhang, et al Expires June 11, 2015 [Page 10] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 o Make-while-break reversion, where resources associated with working or protecting LSP are reconfigured while removing reservations for restoration LSP. o Make-before-break reversion, where resources associated with working or protecting LSP are reconfigured before removing restoration LSP. It is worth mentioning that in GMPLS-controlled circuit OTN networks both reversion types will result in a short traffic disruption. 4.1.2.1. Make-while-break Reversion In this technique, restoration LSP is simply requested to be deleted. Removing reservations for restoration LSP triggers reconfiguration of resources associated with working or protecting LSP on every node where resources are shared. Hence, 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. +---+ +---+ +---+ +---+ +---+ +---+ | A | | B | | C | | F | | G | | E | +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ | | | | | | | PATHTEAR | | | | | D1 +----------X+ D1 | | | | | | PATHTEAR | | | | | +----------X+ D2 | | | | | | PATHTEAR | | | | | +----------X+ D3 | | | | | | PATHTEAR | | | | | +----------X+ D3 | | | | | | PATHTEAR | | | | | +----------X+ D2 | | | | | | Figure 5: Signaling Procedure for LSP Make-while-break Reversion Figure 5 shows signaling process of make-while-break reversion of LSP PathTear message. For alarm-free LSP deletion, the mechanisms described in Section 6 of [RFC4208] should be followed. Resource sharing between working and restoration LSP takes place on nodes A, B, C and E. These are the nodes where reconfiguration of resources associated with working LSP can take place. Zhang, et al Expires June 11, 2015 [Page 11] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 Node behavior upon removing reservation for restoration LSP depends on how resources are shared with working or protecting LSP: Table 2: Node behavior during LSP make-while-break reversion ---------+--------------------------------------------------------- Category | Node behavior during LSP make-while-break reversion ---------+--------------------------------------------------------- D1 + Working and restoration LSP share resources on both + incoming and outgoing interface. + + CP change: Reservation for restoration LSP is removed. + DP change: None, as data plane configuration already + reflects working LSP reservation. ---------+---------------------------------------------------------- D2 + Working and restoration LSP share resources on one of the + interfaces. + + CP change: Reservation for restoration LSP is removed. + DP change: Resource on the interface that is not shared + between working and restoration LSP is freed. + Cross-connection is updated to reflect working LSP + reservation. ---------+---------------------------------------------------------- D3 + Working and restoration LSP do not share resources. + + CP change: Reservation for restoration LSP is removed. + DP change: Resources associated with restoration LSP are + freed. ---------+---------------------------------------------------------- Make-while-break, while being relatively simple in its logic, has a few limitations which may be not acceptable in some implementations: o No rollback Deletion of a LSP 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 a LSP provides no guarantees of completion. In particular, if RSVP packets are lost due to nodal or DCN failures it is probable for a LSP to be only partially deleted. To mitigate this, RSVP could maintain soft state reservations Zhang, et al Expires June 11, 2015 [Page 12] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 and hence eventually remove remaining reservations due to refresh timeouts. This approach is not feasible in circuit networks however, since control and data channels are often separated and hence soft state reservations are not used. Finally, one could argue that graceful LSP deletion [RFC3473] would provide guarantee of completion. While this is true for most cases, many implementations will timeout graceful deletion if LSP is not removed within certain amount of time, e.g. due to a transit node fault. After that, deletion procedures that provide no completion guarantees will be attempted. Hence in corner cases completion guarantee cannot be provided. o No explicit notification of completion to ingress node In some cases it may be useful for ingress 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. 4.1.2.2. Make-before-break Reversion MBB reversion can be used to overcome limitations of make-while-break reversion. It is similar in spirit to MBB concept used for restoration. Instead of relying on deletion of restoration LSP, it chooses to establish a new LSP to reconfigure resources on the working or protection LSP path. Only if setup of this LSP is successful will other LSPs be deleted. MBB reversion consists of two parts: A) Make part: Creating a new reversion LSP following working or protection LSP's path - see Figure 6. Reversion LSP is sharing resources both with working and restoration LSPs. As reversion LSP is created, resources are reconfigured to match its reservations - nodes follow procedures described in Table 1. 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 Zhang, et al Expires June 11, 2015 [Page 13] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 starting restoration. Thus reversion is complete. +---+ +---+ +---+ +---+ +---+ | A | | B | | C | | D | | E | +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ | | | | | | PATH | | | | C1 +----------X+ C1 | | | | | PATH | | | | +----------X+ C2 | | | | | PATH | | | | +----------X+ C1 | | | | | PATH | | | | +----------X+ C2 | | | | | | | | | | | | | | RESV | | | | C1 +X----------+ C2 | | | RESV | | | | C2 +X----------+ | | | RESV | | | | C1 +X----------+ | | | RESV | | | | C1 +X----------+ | | | Figure 6: 'Make': Reversion LSP Setup follows Working LSP's Path Figure 6 shows signaling process of reversion LSP setup for working LSP from Section 4.1.1. In this example, resource sharing between reversion and restoration LSP takes place on nodes A, B, C and E. Resource sharing between working and reversion LSP takes place on whole working LPS's path, i.e. A, B, C, D and E. Before reversion LSP is signaled, data plane configuration on nodes A, B, C and E match restoration LSP reservations. On node D data plane configuration matches working LSP reservations. As already mentioned, MBB reversion uses make-before-break characteristics to overcome challenges related to make-while-break reversion: o Rollback If 'make' part fails, restoration LSP will still be used to carry existing traffic. Same logic applies here as for any MBB operation failure. o Completion guarantee Zhang, et al Expires June 11, 2015 [Page 14] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 LSP setup is resilient against RSVP message loss, as PATH and RESV messages are refreshed periodically. Hence, given that network recovers its DCN eventually, setup is guaranteed to finish with either success or failure. o Explicit notification of completion to ingress node Ingress knows that data plane has been reconfigured to match working or protection LSP reservations when it receives RESV for the reversion LSP. 4.1.3. Re-optimization LSP Setup and Reversion For LSP re-optimization where the new LSP and old LSPs share resource, the signaling flow for new LSP setup and old LSP teardown is similar to those shown in Figures 4 and 5. The issue that should be noted is the traffic will be disrupted if the new path setup process changes the cross-connection configuration of the nodes along the old LSP. If no traffic interruption is desirable, it should either ensure that the old and new LSP do not share the resource other than the source and destination nodes or use other mechanisms. This is out the scope of this document. Similarly, if LSP re-optimization fails and there is a need for LSP reversion, the traffic may be disrupted when resources are shared and cross-connections need to be reconfigured and reverted. 4.2. LSPs with Different Tunnel IDs For two LSPs with different Tunnel IDs, the ASSOCIATION Object is used to specify that they are sharing resource (by setting ASSOCIATION type as "Resource Sharing" (value 2) as well as to identify these correlated LSPs. There are two types: (1) Sharing the common nodes, such as segment recovery, the source and destination nodes of the segment recovery LSP is the intermediate nodes along the working LSPs; (2) Resource sharing is used in a generalized context (such as multi-layer or multi-domain networks); it may result in either sharing source nodes in common, or destination nodes in common, or non end-points in common, if viewed from one domain's perspective. The path computation can either be performed by the source node or edge nodes for the path/path segment or carried out by the PCE, such as the one explained in [PCEP-RSO]. This document does not impose any constraint with regard to path computation. Zhang, et al Expires June 11, 2015 [Page 15] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 [RFC4873] considers resource sharing for LSP segment recovery. The ASSOCIATION Object usage is limited. [RFC6780] extends the usage of ASSOCIATION Object to cover generalized resource sharing applications. The extended ASSOCIATION Object is primarily defined for MPLS-TP, but it can be applied in a wider scope [RFC6780]. It can be used in the second types mentioned above. The configuration and processing rules of extended ASSOCIATION Object defined in [RFC6780] should be followed. The only issue that need pay attention to is that uniqueness of LSP association for the second type should be guaranteed when crossing the layer or domain boundary. The mechanisms for how to ensure this are outside the scope of this document. Other than this, the signaling flow for this type of resource sharing is similar to the description provided in Section 4.1.1. Similar to what is discussed in previous sections, the traffic delivery may be interrupted. Depending on whether the short traffic interruption is acceptable or not, additional mechanisms may be needed and are outside the scope of this document. 5. Security Considerations This document reviews procedures defined in [RFC4872] and [RFC6689] and does not define any new procedure. This document does not incur any new security issues other than those already covered in [RFC3209] [RFC4872] [RFC4873] and [RFC6780]. 6. IANA Considerations This informational document does not make any requests for IANA action. 7. Acknowledgement The authors would like to thank George Swallow for the discussions on the GMPLS restoration. Zhang, et al Expires June 11, 2015 [Page 16] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 8. References 8.1. Normative References [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [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. [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. [RFC6780] L. Berger et al, "RSVP ASSOCIATION Object Extensions", RFC 6780, October 2012. 8.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. [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 June 11, 2015 [Page 17] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 [RFC4655] A. Farrel et al, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., Rekhter, Y., "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. Zhang, et al Expires June 11, 2015 [Page 18] Internet-Draft GMPLS Restoration and Resource Sharing December 8, 2014 9. 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 June 11, 2015 [Page 19]