Network Working Group Evelyne Roch Internet Draft Lyndon Ong Intended status: Informational Ciena March 5, 2012 Requirements for Combined Protection and Restoration draft-roch-ccamp-combined-recovery-reqts-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 5, 2012. Copyright Notice Copyright (c) 2012 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. Abstract Roch Expires September 5, 2012 [Page 1] Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012 This Internet-Draft proposes requirements for combinations of rerouting and protection schemes that are of interest to carrier networks. Table of Contents 1. Introduction and Problem Statement.............................2 2. Maintenance operations of protected services...................2 3. Combined restoration and protection schemes....................4 3.1. Second Level Restoration..................................4 3.2. Always on protection......................................5 4. Security Considerations........................................6 5. IANA Considerations............................................6 6. Acknowledgments................................................7 1. Introduction and Problem Statement Combination of protection and rerouting mechanisms allow carriers to: - Perform maintenance activities on the protected/protection LSPs while maintaining the protection. - Offer services with higher availability by automatically combining restoration and protection schemes. This document defines use cases for the combination of protection and rerouting mechanisms that are of interest to carriers that could be candidates for support in GMPLS. 2. Maintenance operations of protected services The first area to consider is the combination of maintenance activities with the protection and restoration schemes. For example, it is possible to perform maintenance operation on one of the legs of a 1+1 connection but the operator may want to maintain the 1+1 protection during the maintenance activity. Temporarily or permanently rerouting the traffic of one of the legs for maintenance purposes requires proper support in the signaling procedures. The requirement is to support up to 3 related LSPs that have resources reserved but of which at most 2 are instantiated end-to- end in the data plane. Consider the following network topology: Roch Expires September 5, 2012 [Page 2] Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012 B --- C --- D / \ A --- E --- F --- Z \ / G --- H --- I The detailed signaling scenario for rerouting is as follows: - Preconditions: The working (A-B-C-D-Z) and protecting (A-E-F-Z) LSPs are both established and neither of them has a failure condition. - A third LSP (A-G-H-I) is established with resources reserved and established on nodes G, H and I but reserved only at nodes A and Z. - The LSP that is put under maintenance is de-activated by keeping the resources reserved but no established at nodes A and Z while maintaining resources reserved and established at nodes B, C and D if maintenance is applied to working LSP or nodes E and F if maintenance is applied to protecting LSP. - The maintenance LSP is activated by establishing the resources for the maintenance LSP at nodes A and Z. - At this stage, if this is a permanent reroute operation, the original working or protecting LSP is torn down. Otherwise, the LSP is maintained for reversion at a later stage. The reversion stage: - The maintenance LSP is deactivated by de-establishing the resources for the maintenance LSP at nodes A and Z. - The original LSP (working or protecting) is activated at nodes A and Z by establishing resources (working or protecting) at nodes A and Z. - The maintenance LSP is torn down. Roch Expires September 5, 2012 [Page 3] Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012 3. Combined restoration and protection schemes In order to provide higher reliability, some service levels may combine restoration and protection. Two combinations that are useful to operators are included here. These combinations may require more than two LSPs to be associated together in case of make-before-break or when reversion is desired. Signaling extensions that support combined protection and restoration are required by identifying the type of recovery as a combination of protection (e.g. 1+1 bi- directional) and restoration types (e.g. full rerouting). The signaling extensions should also provide an indication of the relationship between the two mechanisms to distinguish the following scenarios: - Second level restoration: offers protection against dual failures in the case of protected services. It offers the option to restore the LSP if both working and protection LSPs fail. - Always on protection: offers the assurance of fast protection even after a failure by restoring the failed leg of a protected service. 3.1. Second Level Restoration The requirement is to support up to 3 related LSPs that have resources reserved but of which at most 2 are instantiated end-to- end in the data plane. When both the working and protecting LSPs are under failure condition, this triggers restoration. Consider the following network topology: B --- C --- D / \ A --- E --- F --- Z \ / G --- H --- I The detailed signaling scenario for rerouting is as follows: - Preconditions: The working (A-B-C-D-Z) and protecting (A-E-F-Z) LSPs are both established and both are under failure condition. Roch Expires September 5, 2012 [Page 4] Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012 - One of the original LSPs (working or protecting), as determined by the head-end local policy is deactivated at the A and Z nodes while maintaining the resources reserved. - A restoration LSP (A-G-H-I) is established with resources reserved and established. - At this stage, if this is non-revertive restoration, the original working or protecting LSP is torn down. Otherwise, the LSP is maintained for reversion at a later stage. The reversion stage: - The restoration LSP is deactivated by de-establishing the resources for the restoration LSP at nodes A and Z. - The original LSP (working or protecting) is activated at nodes A and Z by establishing resources (working or protecting) at nodes A and Z. - The restoration LSP is torn down. 3.2. Always on protection The requirement is to support up to 4 related LSPs that have resources reserved but of which at most 2 are instantiated end-to- end in the data plane. When one of the working or protecting LSPs is under failure condition, this triggers restoration of that LSP. Consider the following network topology: B --- C --- D / \ A --- E --- F --- Z \ \ / / \ G --- H --- I / \ / J ------- L The detailed signaling scenario for rerouting is as follows: Roch Expires September 5, 2012 [Page 5] Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012 - Preconditions: The working (A-B-C-D-Z) and protecting (A-E-F-Z) LSPs are both established and at least one is under failure condition. For the purpose of this example, let's assume working has failed. - The failed LSP (working in this example), is deactivated at the A and Z nodes while maintaining the resources reserved. - A restoration working LSP (A-G-H-I) is established with resources reserved and established. - At this stage, we have 3 LSPs that are associated but only 2 are established end-to-end in the data plane. If this is a non- revertive restoration, the working LSP (A-B-C-D-Z) is torn down. Otherwise, it is maintained until reversion. - If the second original LSP also fails (protecting LSP in this example), it is also deactivated at the A and Z nodes while maintaining the resources reserved and a restoration protecting LSP (A-J-L-Z) is established with resources reserved and established. Similarly to the previous bullet, if this is a non- revertive restoration, the protecting LSP is torn down. Otherwise, it is maintained until reversion. The reversion stage: - The working or protecting restoration LSP is deactivated by de- establishing the resources for the restoration LSP at nodes A and Z. - The original LSP (working or protecting) is activated at nodes A and Z by establishing resources (working or protecting) at nodes A and Z. - The working or protecting restoration LSP is torn down. 4. Security Considerations None identified at this time 5. IANA Considerations None identified at this time Roch Expires September 5, 2012 [Page 6] Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012 6. Acknowledgments The authors would like to thank members of the OIF Network & Operations WG and the CCAMP co-chairs for their comments and suggestions to this document. Roch Expires September 5, 2012 [Page 7] Internet-Draft draft-roch-ccamp-combined-recovery-reqts March 2012 Authors' Addresses Evelyne Roch Ciena Email: eroch@ciena.com Lyndon Ong Ciena Email: lyong@ciena.com Roch Expires September 5, 2012 [Page 8]