idnits 2.17.1 draft-ietf-ccamp-mpls-graceful-shutdown-13.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 20, 2010) is 5202 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group 2 Internet Draft 3 Zafar Ali 4 Jean-Philippe Vasseur 5 Anca Zamfir 6 Cisco Systems, Inc. 7 Jonathan Newton 8 Cable and Wireless 10 Category: Informational 11 Expires: July 19, 2010 January 20, 2010 13 draft-ietf-ccamp-mpls-graceful-shutdown-13.txt 15 Graceful Shutdown in MPLS and Generalized MPLS 16 Traffic Engineering Networks 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance 21 with the provisions of BCP 78 and BCP 79. This document may 22 contain material from IETF Documents or IETF Contributions 23 published or made publicly available before November 10, 2008. 24 The person(s) controlling the copyright in some of this material 25 may not have granted the IETF Trust the right to allow 26 modifications of such material outside the IETF Standards 27 Process. Without obtaining an adequate license from the 28 person(s) controlling the copyright in such materials, this 29 document may not be modified outside the IETF Standards Process, 30 and derivative works of it may not be created outside the IETF 31 Standards Process, except to format it for publication as an RFC 32 or to translate it into languages other than English. 34 Internet-Drafts are working documents of the Internet 35 Engineering Task Force (IETF), its areas, and its working 36 groups. Note that other groups may also distribute working 37 documents as Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other 41 documents at any time. It is inappropriate to use Internet- 42 Drafts as reference material or to cite them other than as "work 43 in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt. 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 This Internet-Draft will expire on July 19, 2010. 53 Copyright 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described 65 in Section 4.e of the Trust Legal Provisions and are provided 66 without warranty as described in the Simplified BSD License. 68 Abstract 70 MPLS-TE Graceful Shutdown is a method for explicitly notifying 71 the nodes in a Traffic Engineering (TE) enabled network that the 72 TE capability on a link or on an entire Label Switching Router 73 (LSR) is going to be disabled. MPLS-TE graceful shutdown 74 mechanisms are tailored toward addressing planned outage in the 75 network. 77 This document provides requirements and protocol mechanisms to 78 reduce/eliminate traffic disruption in the event of a planned 79 shutdown of a network resource. These operations are equally 80 applicable to both MPLS-TE and its Generalized MPLS (GMPLS) 81 extensions. 83 Table of Contents 85 1. Introduction....................................................2 86 2. Terminology.....................................................3 87 3. Requirements for Graceful Shutdown..............................4 88 4. Mechanisms for Graceful Shutdown................................5 89 4.1 OSPF/ ISIS Mechanisms for graceful shutdown...................5 90 4.2 RSVP-TE Signaling Mechanisms for graceful shutdown............6 91 5. Manageability Considerations....................................7 92 6. Security Considerations.........................................8 93 7. IANA Considerations.............................................8 94 8. Acknowledgments.................................................8 95 9. Reference.......................................................8 96 9.1 Normative Reference...........................................8 97 9.2 Informative Reference.........................................8 98 10. Authors' Address:..............................................9 100 1. Introduction 102 When outages in a network are planned (e.g., for maintenance 103 purposes), some mechanisms can be used to avoid traffic 104 disruption. This is in contrast with unplanned network element 105 failure, where traffic disruption can be minimized thanks to 106 recovery mechanisms, but may not be avoided. Therefore, a Service 107 Provider may desire to gracefully (temporarily or indefinitely) 108 remove a TE Link, a group of TE Links or an entire node for 109 administrative reasons such as link maintenance, 110 software/hardware upgrade at a node or significant TE 111 configuration changes. In all these cases, the goal is to 112 minimize the impact on the traffic carried over TE LSPs in the 113 network by triggering notifications so as to gracefully reroute 114 such flows before the administrative procedures are started. 116 These operations are equally applicable to both MPLS-TE [RFC3209] 117 and its Generalized MPLS (GMPLS) extensions [RFC3471], [RFC3473]. 119 This document describes the mechanisms that can be used to 120 gracefully shutdown MPLS-TE/ GMPLS Traffic Engineering on a 121 resource such as a TE link, a component link within a bundled TE 122 link, a label resource or an entire TE node. 124 Graceful shutdown of a resource may require several steps. These 125 steps can be broadly divided into two sets: disabling the 126 resource in the control plane and disabling the resource in the 127 data plane. The node initiating the graceful shutdown condition 128 introduces a delay between the two sets to allow the control 129 plane to gracefully divert the traffic away from the resource 130 being gracefully shutdown. The trigger for the graceful shutdown 131 event is a local matter at the node initiating the graceful 132 shutdown. Typically, graceful shutdown is triggered for 133 administrative reasons, such as link maintenance or 134 software/hardware upgrade. 136 2. Terminology 138 LSR: Label Switching Router. The terms node and LSR are used 139 interchangeably in this document. 141 GMPLS: The term GMPLS is used in this document to refer to packet 142 MPLS-TE, as well as GMPLS extensions to MPLS-TE. 144 TE Link: The term TE link refers to single or a bundle of 145 physical links or FA-LSPs (see below) on which traffic 146 engineering is enabled. 148 TE LSP: A Traffic Engineered Label Switched Path. 150 S-LSP: A segment of a TE LSP 152 FA-LSP (Forwarding Adjacency LSP): An LSP that is announced as a 153 TE link into the same instance of the GMPLS control plane as the 154 one that was used to create the LSP [RFC4206]. 156 ISIS-LSP: Link State Packets generated by ISIS routers and that 157 contain routing information. 159 LSA: Link State Advertisements generated by OSPF routers and that 160 contain routing information. 162 TE-LSA/ TE-ISIS-LSP: The traffic engineering extensions to OSPF/ 163 ISIS. 165 Head-end node: Ingress LSR that initiated signaling for the Path. 167 Border node: Ingress LSR of a TE LSP segment (S-LSP). 169 PCE (Path Computation Element): An entity that computes the 170 routes on behalf of its clients (PCC) [RFC4655]. 172 Last resort resource: If a path to a destination from a given 173 head-end node cannot be found upon removal of a resource (e.g., 174 TE link, TE node), the resource is called last resort to reach 175 that destination from the given head-end node. 177 3. Requirements for Graceful Shutdown 179 This section lists the requirements for graceful shutdown in the 180 context of GMPLS. 182 - Graceful shutdown is required to address graceful removal of 183 one TE link, one component link within a bundled TE link, a set 184 of TE links, a set of component links, label resources, or an 185 entire node. 187 - Once an operator has initiated graceful shutdown of a network 188 resource, no new TE LSPs may be set up that use the resource. 189 Any signaling message for a new TE LSP that explicitly specifies 190 the resource, or that would require the use of the resource due 191 to local constraints, is required to be rejected as if the 192 resource were unavailable. 194 - It is desirable for new TE LSP setup attempts that would be 195 rejected because of graceful shutdown of a resource (as described 196 in the previous requirement) to avoid any attempt to use the 197 resource by selecting an alternate route or other resources. 199 - If the resource being shut down is a last resort resource, 200 based on a local decision, the node initiating the graceful 201 shutdown procedure can cancel the shutdown operation. 203 - It is required to give the ingress node the opportunity to take 204 actions in order to reduce/eliminate traffic disruption on the TE 205 LSPs that are using the network resources which are about to be 206 shut down. 208 - Graceful shutdown mechanisms are equally applicable to intra- 209 domain and TE LSPs spanning multiple domains, as defined in 210 [RFC4726]. Examples of such domains include IGP areas and 211 Autonomous Systems. 213 - Graceful shutdown is equally applicable to packet and non- 214 packet networks. 216 - In order to make rerouting effective, it is required that when 217 a node initiates the graceful shutdown of a resource, it 218 identifies to all other network nodes the TE resource under 219 graceful shutdown. 220 - Depending on switching technology, it may be possible to shut 221 down a label resource, e.g., shutting down a lambda in a Lambda 222 Switch Capable (LSC) node. 224 4. Mechanisms for Graceful Shutdown 226 An IGP only solution based on [RFC3630], [RFC5305], [RFC4203] and 227 [RFC5307] is not applicable when dealing with inter-area and 228 inter-AS traffic engineering, as IGP flooding is restricted to 229 IGP areas/levels. An RSVP based solution is proposed in this 230 document to handle TE LSPs spanning multiple domains. 231 In addition, in order to prevent LSRs in a domain to use the 232 resource being shut down. 233 In addition, in order to discourage nodes from establishing new 234 TE LSPs through the resources being shutdown, existing IGP 235 mechanisms are used for the shutdown notification. 237 A node where a link or the whole node is being shutdown first 238 triggers the IGP updates as described in Section 4.1 and then, 239 with some delay to allow network convergence, uses the signaling 240 mechanism described in Section 4.2. 242 4.1 OSPF/ ISIS Mechanisms for graceful shutdown 244 This section describes the use of existing OSPF and ISIS 245 mechanisms for the graceful shutdown in GMPLS networks. 247 The OSPF and ISIS procedures for graceful shutdown of TE links 248 are similar to the graceful restart of OSPF and ISIS as described 249 in [RFC4203] and [RFC5307], respectively. Specifically, the node 250 where graceful shutdown of a link is desired originates the TE 251 LSA/ISIS-LSP containing a Link TLV for the link under graceful 252 shutdown with Traffic Engineering metric set to 0xffffffff, 0 as 253 unreserved bandwidth, and if the TE link has LSC or FSC as its 254 Switching Capability then also with 0 in the "Max LSP Bandwidth" 255 field of the Interface Switching Capability Descriptor (ISCD) 256 sub-TLV. A node may also specify a value which is greater than 257 the available bandwidth in the "Minimum LSP bandwidth" field of 258 the same ISCD sub-TLV. This would discourage new TE LSP 259 establishment through the link under graceful shutdown. 261 If graceful shutdown procedure is performed for a component link 262 within a TE Link bundle and it is not the last component link 263 available within the TE link, the link attributes associated with 264 the TE link are recomputed. Similarly, If graceful shutdown 265 procedure is performed on a label resource within a TE Link, the 266 link attributes associated with the TE link are recomputed. If 267 the removal of the component link or label resource results in a 268 significant bandwidth change event, a new LSA is originated with 269 the new traffic parameters. If the last component link is being 270 shut down, the routing procedure related to TE link removal is 271 used. 273 Neighbors of the node where graceful shutdown procedure is in 274 progress continue to advertise the actual unreserved bandwidth of 275 the TE links from the neighbors to that node, without any routing 276 adjacency change. 278 When graceful shutdown at node level is desired, the node in 279 question follows the procedure specified in the previous section 280 for all TE Links. 282 4.2 RSVP-TE Signaling Mechanisms for graceful shutdown 284 As discussed in Section 3, one of the requirements for the 285 signaling mechanism for graceful shutdown is to carry information 286 about the resource under graceful shutdown. For this purpose the 287 Graceful Shutdown uses TE LSP rerouting mechanism as defined in 288 [RFC5710]. 290 Specifically, the node where graceful shutdown of an unbundled TE 291 link or an entire bundled TE link is desired triggers a PathErr 292 message with the error code "Notify" and error value "Local link 293 maintenance required", for all affected TE LSPs. Similarly, the 294 node that is being gracefully shut down triggers a PathErr 295 message with the error code "Notify" and error value "Local node 296 maintenance required", for all TE LSPs. For graceful shutdown of 297 a node, an unbundled TE link or an entire bundled TE link, the 298 PathErr message may contain either an [RFC2205] format ERROR_SPEC 299 object, or an IF_ID [RFC3473] format ERROR_SPEC object. In either 300 case, it is the address and TLVs carried by the ERROR_SPEC object 301 and not the error value that indicates the resource that is to be 302 gracefully shut down. 304 MPLS TE Link Bundling [RFC4201] requires that an TE LSP is pinned 305 down to a component link. Consequently, graceful shutdown of a 306 component link in a bundled TE link differs from graceful 307 shutdown of unbundled TE link or entire bundled TE link. 308 Specifically, in the former case, when only a subset of component 309 links and not the entire bundled TE link is being shutdown, the 310 remaining component links of the bundled TE link may still be 311 able to admit new TE LSPs. The node where graceful shutdown of a 312 component link is desired triggers a PathErr message with the 313 error code "Notify" and error value of "Local link maintenance 314 required". The rest of the ERROR_SPEC object is constructed using 315 Component Reroute Request procedure defined in [RFC5710]. 317 If graceful shutdown of a label resource is desired, the node 318 initiating this action triggers a PathErr message with the error 319 codes and error values of "Notify/Local link maintenance 320 required". The rest of the ERROR_SPEC object is constructed using 321 Label Reroute Request procedure defined in [RFC5710]. 323 When a head-end node, a transit node or a border node receives a 324 PathErr message with the error code "Notify" and error value 325 "Local link maintenance required" or "Local node maintenance 326 required", it follows the procedures defined in [RFC5710] to 327 reroute the traffic around the resource being gracefully 328 shutdown. When performing path computation for the new TE LSP, 329 the head-end node, or border node avoids using the TE resources 330 identified by the ERROR_SPEC object. If PCE is used for path 331 computation, head-end (or border) node acting as PCC specifies in 332 its requests to the PCE that path computation should avoid the 333 resource being gracefully shutdown. The amount of time the head- 334 end node, or border node avoids using the TE resources identified 335 by the IP address contained in the PathErr is based on a local 336 decision at head-end node or border node. 338 If the node initiating the graceful shutdown procedure receives a 339 path setup request for a new tunnel using resource being 340 gracefully shutdown, it sends a Path Error message with "Notify" 341 error code in the ERROR SPEC object and an error value consistent 342 with the type of resource being gracefully shut down. However, 343 based on a local decision, if an existing tunnel continues to use 344 the resource being gracefully shutdown, the node initiating the 345 graceful shutdown procedure may allow resource being gracefully 346 shutdown to be used as a "last resort". The node initiating the 347 graceful shutdown procedure can distinguish between new and 348 existing tunnels by inspecting the SENDER TEMPLATE and SESSION 349 objects. 351 If the resource being shut down is a last resort resource, it 352 can be used, i.e., based on a local decision the node initiating 353 the graceful shutdown procedure can cancel the shutdown operation. 354 Similarly, based on a local decision the node initiating 355 the graceful shutdown procedure can delay the actual removal of 356 resource for forwarding. This is to give time to network to move 357 traffic from the resource being shutdown. For this purpose, the 358 node initiating graceful shutdown procedure follows the Reroute 359 Request Timeout procedure defined in [RFC5710]. 361 5. Manageability Considerations 363 When a TE link is being showdown, a linkDown trap as defined in 364 [RFC2863] should be generated for the TE link. Similarly, if a 365 bundled TE links is being showdown, a linkDown trap as defined 366 in [RFC2863] should be generated for the bundled TE link, as well 367 as for each of its component links. If a TE node is being 368 shutdown, a linkDown trap as defined in [RFC2863] should be 369 generated for all TE links at the node. 371 6. Security Considerations 373 This document introduces no new security considerations as this 374 document describes usage of existing formats and mechanisms. This 375 document relies on existing procedures for advertisement of TE 376 LSA/ISIS-LSP containing Link TLV. Tampering with TE LSAs/ISIS- 377 LSPs may have an effect on traffic engineering computations, and 378 it is suggested that any mechanisms used for securing the 379 transmission of normal LSAs/ISIS-LSPs be applied equally to all 380 Opaque LSAs/ISIS-LSPs this document uses. Existing security 381 considerations specified in [RFC3630], [RFC5305], [RFC4203], 382 [RFC5307] and [MPLS-GMPLS-SECURITY] remain relevant and suffice. 383 Furthermore, security considerations section in [RFC5710] and 384 section 9 of [RFC4736] should be used for understanding the 385 security considerations related to the formats and mechanisms 386 used in this document. 388 7. IANA Considerations 390 This document has no IANA actions. 392 8. Acknowledgments 394 The authors would like to thank Adrian Farrel for his detailed 395 comments and suggestions. The authors would also like to 396 acknowledge useful comments from David Ward, Sami Boutros, and 397 Dimitri Papadimitriou. 399 9. Reference 401 9.1 Normative Reference 403 [RFC2205] Braden, R. Ed. et al, "Resource ReSerVation Protocol 404 (RSVP) Version 1, Functional Specification", RFC 2205. 406 [RFC5710] Berger, L., Papadimitriou, D., and J. Vasseur, 407 "PathErr Message Triggered MPLS and GMPLS LSP Reroute", 408 RFC5710. 410 9.2 Informative Reference 412 [RFC3209] Awduche D., Berger, L., Gan, D., Li T., Srinivasan, V., 413 Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 414 3209. 416 [RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS 417 Traffic Engineering loosely routed LSP paths", RFC 4736. 419 [RFC3630] Katz D., Kompella K., Yeung D., "Traffic Engineering 420 (TE) Extensions to OSPF Version 2", RFC 3630. 422 [RFC5305] Smit, H. and T. Li, "Intermediate System to 423 Intermediate System (IS-IS) Extensions for Traffic Engineering 424 (TE)", RFC 5305. 426 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF 427 Extensions in Support of Generalized Multi-Protocol Label 428 Switching (GMPLS)", RFC 4203. 430 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate 431 System to Intermediate System (IS-IS) Extensions in Support of 432 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307. 434 [RFC3471] Berger, L., "Generalized Multi-Protocol Label 435 Switching (GMPLS) Signaling Functional Description", RFC 3471. 437 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 438 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 439 Engineering (RSVP-TE) Extensions", RFC 3473. 441 [RFC4726] Farrel A, Vasseur, J.-P., Ayyangar A., "A Framework for 442 Inter-Domain MPLS Traffic Engineering", RFC 4726, November 2006. 444 [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling 445 in MPLS Traffic Engineering", RFC 4201. 447 [RFC4206] Kompella K., Rekhter Y., "Label Switched Paths (LSP) 448 Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) 449 Traffic Engineering (TE)", RFC 4206. 451 [RFC4655] A. Farrel, J.-P. Vasseur, J. Ash, "A Path Computation 452 Element (PCE)-Based Architecture", RFC 4655. 454 [RFC2863] McCloghrie K., Kastenholz F., "The Interfaces Group 455 MIB", RFC 2863. 457 [MPLS-GMPLS-SECURITY] Luyuan F., Ed. "Security Framework for 458 MPLS and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls- 459 security-framework, work in progress. 461 10. Authors' Address: 463 Zafar Ali 464 Cisco systems, Inc., 465 2000 Innovation Drive 466 Kanata, Ontario, K2K 3E8 467 Canada. 468 Email: zali@cisco.com 469 Jean Philippe Vasseur 470 Cisco Systems, Inc. 471 300 Beaver Brook Road 472 Boxborough , MA - 01719 473 USA 474 Email: jpv@cisco.com 476 Anca Zamfir 477 Cisco Systems, Inc. 478 2000 Innovation Drive 479 Kanata, Ontario, K2K 3E8 480 Canada 481 Email: ancaz@cisco.com 483 Jonathan Newton 484 Cable and Wireless 485 jonathan.newton@cw.com