idnits 2.17.1 draft-roch-ccamp-combined-recovery-reqts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 4432 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Evelyne Roch 2 Internet Draft Lyndon Ong 3 Intended status: Informational Ciena 4 March 5, 2012 6 Requirements for Combined Protection and Restoration 7 draft-roch-ccamp-combined-recovery-reqts-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with 12 the provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on September 5, 2012. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 48 This Internet-Draft proposes requirements for combinations of 49 rerouting and protection schemes that are of interest to carrier 50 networks. 52 Table of Contents 54 1. Introduction and Problem Statement.............................2 55 2. Maintenance operations of protected services...................2 56 3. Combined restoration and protection schemes....................4 57 3.1. Second Level Restoration..................................4 58 3.2. Always on protection......................................5 59 4. Security Considerations........................................6 60 5. IANA Considerations............................................6 61 6. Acknowledgments................................................7 63 1. Introduction and Problem Statement 65 Combination of protection and rerouting mechanisms allow carriers 66 to: 68 - Perform maintenance activities on the protected/protection LSPs 69 while maintaining the protection. 71 - Offer services with higher availability by automatically combining 72 restoration and protection schemes. 74 This document defines use cases for the combination of protection 75 and rerouting mechanisms that are of interest to carriers that could 76 be candidates for support in GMPLS. 78 2. Maintenance operations of protected services 80 The first area to consider is the combination of maintenance 81 activities with the protection and restoration schemes. For example, 82 it is possible to perform maintenance operation on one of the legs 83 of a 1+1 connection but the operator may want to maintain the 1+1 84 protection during the maintenance activity. Temporarily or 85 permanently rerouting the traffic of one of the legs for maintenance 86 purposes requires proper support in the signaling procedures. 88 The requirement is to support up to 3 related LSPs that have 89 resources reserved but of which at most 2 are instantiated end-to- 90 end in the data plane. 92 Consider the following network topology: 94 B --- C --- D 95 / \ 96 A --- E --- F --- Z 97 \ / 98 G --- H --- I 100 The detailed signaling scenario for rerouting is as follows: 102 - Preconditions: The working (A-B-C-D-Z) and protecting (A-E-F-Z) 103 LSPs are both established and neither of them has a failure 104 condition. 106 - A third LSP (A-G-H-I) is established with resources reserved and 107 established on nodes G, H and I but reserved only at nodes A and 108 Z. 110 - The LSP that is put under maintenance is de-activated by keeping 111 the resources reserved but no established at nodes A and Z while 112 maintaining resources reserved and established at nodes B, C and 113 D if maintenance is applied to working LSP or nodes E and F if 114 maintenance is applied to protecting LSP. 116 - The maintenance LSP is activated by establishing the resources 117 for the maintenance LSP at nodes A and Z. 119 - At this stage, if this is a permanent reroute operation, the 120 original working or protecting LSP is torn down. Otherwise, the 121 LSP is maintained for reversion at a later stage. 123 The reversion stage: 125 - The maintenance LSP is deactivated by de-establishing the 126 resources for the maintenance LSP at nodes A and Z. 128 - The original LSP (working or protecting) is activated at nodes A 129 and Z by establishing resources (working or protecting) at nodes 130 A and Z. 132 - The maintenance LSP is torn down. 134 3. Combined restoration and protection schemes 136 In order to provide higher reliability, some service levels may 137 combine restoration and protection. Two combinations that are useful 138 to operators are included here. These combinations may require more 139 than two LSPs to be associated together in case of make-before-break 140 or when reversion is desired. Signaling extensions that support 141 combined protection and restoration are required by identifying the 142 type of recovery as a combination of protection (e.g. 1+1 bi- 143 directional) and restoration types (e.g. full rerouting). The 144 signaling extensions should also provide an indication of the 145 relationship between the two mechanisms to distinguish the following 146 scenarios: 148 - Second level restoration: offers protection against dual failures 149 in the case of protected services. It offers the option to 150 restore the LSP if both working and protection LSPs fail. 152 - Always on protection: offers the assurance of fast protection 153 even after a failure by restoring the failed leg of a protected 154 service. 156 3.1. Second Level Restoration 158 The requirement is to support up to 3 related LSPs that have 159 resources reserved but of which at most 2 are instantiated end-to- 160 end in the data plane. When both the working and protecting LSPs are 161 under failure condition, this triggers restoration. 163 Consider the following network topology: 165 B --- C --- D 166 / \ 167 A --- E --- F --- Z 168 \ / 169 G --- H --- I 171 The detailed signaling scenario for rerouting is as follows: 173 - Preconditions: The working (A-B-C-D-Z) and protecting (A-E-F-Z) 174 LSPs are both established and both are under failure condition. 176 - One of the original LSPs (working or protecting), as determined 177 by the head-end local policy is deactivated at the A and Z nodes 178 while maintaining the resources reserved. 180 - A restoration LSP (A-G-H-I) is established with resources 181 reserved and established. 183 - At this stage, if this is non-revertive restoration, the original 184 working or protecting LSP is torn down. Otherwise, the LSP is 185 maintained for reversion at a later stage. 187 The reversion stage: 189 - The restoration LSP is deactivated by de-establishing the 190 resources for the restoration LSP at nodes A and Z. 192 - The original LSP (working or protecting) is activated at nodes A 193 and Z by establishing resources (working or protecting) at nodes 194 A and Z. 196 - The restoration LSP is torn down. 198 3.2. Always on protection 200 The requirement is to support up to 4 related LSPs that have 201 resources reserved but of which at most 2 are instantiated end-to- 202 end in the data plane. When one of the working or protecting LSPs is 203 under failure condition, this triggers restoration of that LSP. 205 Consider the following network topology: 207 B --- C --- D 208 / \ 209 A --- E --- F --- Z 210 \ \ / / 211 \ G --- H --- I / 212 \ / 213 J ------- L 215 The detailed signaling scenario for rerouting is as follows: 217 - Preconditions: The working (A-B-C-D-Z) and protecting (A-E-F-Z) 218 LSPs are both established and at least one is under failure 219 condition. For the purpose of this example, let's assume working 220 has failed. 222 - The failed LSP (working in this example), is deactivated at the A 223 and Z nodes while maintaining the resources reserved. 225 - A restoration working LSP (A-G-H-I) is established with resources 226 reserved and established. 228 - At this stage, we have 3 LSPs that are associated but only 2 are 229 established end-to-end in the data plane. If this is a non- 230 revertive restoration, the working LSP (A-B-C-D-Z) is torn down. 231 Otherwise, it is maintained until reversion. 233 - If the second original LSP also fails (protecting LSP in this 234 example), it is also deactivated at the A and Z nodes while 235 maintaining the resources reserved and a restoration protecting 236 LSP (A-J-L-Z) is established with resources reserved and 237 established. Similarly to the previous bullet, if this is a non- 238 revertive restoration, the protecting LSP is torn down. 239 Otherwise, it is maintained until reversion. 241 The reversion stage: 243 - The working or protecting restoration LSP is deactivated by de- 244 establishing the resources for the restoration LSP at nodes A and 245 Z. 247 - The original LSP (working or protecting) is activated at nodes A 248 and Z by establishing resources (working or protecting) at nodes 249 A and Z. 251 - The working or protecting restoration LSP is torn down. 253 4. Security Considerations 255 None identified at this time 257 5. IANA Considerations 259 None identified at this time 261 6. Acknowledgments 263 The authors would like to thank members of the OIF Network & Operations 264 WG and the CCAMP co-chairs for their comments and suggestions to this 265 document. 267 Authors' Addresses 269 Evelyne Roch 270 Ciena 271 Email: eroch@ciena.com 273 Lyndon Ong 274 Ciena 275 Email: lyong@ciena.com