CCAMP Working Group Zafar Ali Jean Philippe Vasseur Anca Zamfir Cisco Systems, Inc. IETF Internet Draft Category: Standard track Expires: August, 2005 February 2005 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Graceful Shutdown in MPLS Traffic Engineering Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Z. Ali, et al. Page 1 2/20/2005 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 Abstract Graceful shutdown is a method for explicitly notifying a set of nodes that either a Link or an entire node will remove itself from the network or the protocol is going to be disabled for a link or a node. Graceful shut down mechanisms are tailored towards addressing the planned outage in the network. This document provides requirements and protocol mechanisms so as to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [i]. Routing Area ID Summary (This section to be removed before publication.) SUMMARY This document describes graceful shutdown mechanisms used in MPLS Traffic Engineering network. WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK? This work requires protocol extension to signaling (RSVP-TE) and routing (OSPF/ ISIS) protocols being defined under IETF Routing Area. WHY IS IT TARGETED AT THIS WG? This work fits in the context of [RFC 3209], [RFC 3473] and extensions to these RFCs being defined in CCAMP. RELATED REFERENCES See the reference section. Table of Contents 1. Terminology........................................................3 2. Introduction.......................................................3 3. Requirements for Graceful Shutdown Mechanisms......................4 4. OSPF/ ISIS Mechanisms for graceful shutdown........................5 4.1 Graceful Shutdown of TE link(s).................................5 4.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link.....6 4.3 Graceful Shutdown of TE Node....................................6 Z. Ali, et al. Page 2 2/20/2005 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 4.4 Grace Period and Removal of Resource............................6 5. RSVP-TE Signaling Mechanism for graceful shutdown..................6 5.1 Graceful Shutdown of TE link(s).................................6 5.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link.....7 5.3 Graceful Shutdown of TE Node....................................7 6. Security Considerations............................................8 7. IANA Considerations................................................8 8. Full Copyright Statement...........................................8 9. Intellectual Property..............................................8 10. Acknowledgments...................................................8 11. Reference.........................................................9 11.1 Normative Reference............................................9 11.2 Informative Reference.........................................10 1. Terminology Node - Label Switching Device. LSP - An MPLS Label Switched Path Inter-AS MPLS TE LSP: TE LSP whose Head-end node and Tail-end node do not reside within the same Autonomous System (AS) or both Head-end node and Tail-end node are in the same AS but the TE tunnel transiting path may be across different ASes. Inter-Area MPLS TE LSP: TE LSP whose Head-end node and Tail-end node do not reside within the same IGP area/ level or both Head-end node and Tail-end node are in the same area/ level but the TE tunnel transiting path may be across different areas/ levels. Head-end node: In the draft term head-end node equally applies to the Ingress node that initiated signaling for the Path, or an intermediate node (in the case of loose hops path computation) or a Path Computation Element (PCS) that computes the routes on behave of its clients (PCC). Specification of PCE-PCC communication is beyond the scope of this document. However, the document lists set of roles that any entity computing a path should follow, i.e., Ingress node, intermediate nodes performing ERO extensions or PCE. 2. Introduction Some of the outages in a network are planned, in which case protocols extensions can be used so as to avoid traffic disruption by contrast with unplanned network element failure, where traffic disruption can be reduced but may not avoided. Hence, a Service Provider may desire to gracefully (temporarily or definitely) remove a TE Link, a group of TE Links or an entire node for administrative reasons such as link maintenance or software/hardware upgrade at a node. In all these cases, Z. Ali, et al. Page 3 2/20/2005 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 the goal is to minimize impact on the MPLS traffic engineered flows in the network. In an MPLS Traffic Engineering (TE) enabled network, there are currently no defined mechanisms to allow for graceful shutdown of network resources (TE links or TE nodes). In this document, we describe graceful shutdown mechanisms for MPLS Traffic Engineering network. Specifically, this document proposes signaling and routing extensions to alert the head-end node of the graceful shutdown events. 3. Requirements for Graceful Shutdown Mechanisms This section lists the requirements for graceful shutdown mechanisms. - Graceful shutdown mechanisms are applicable to removal a TE resource (e.g., link, a group of TE Links or an entire node). Trigger for the graceful shutdown event is a local matter at the node initiating the graceful shutdown. Typically graceful shutdown is triggered for administrative reasons, such as link maintenance or software/hardware upgrade at a node. - Graceful shutdown mechanisms are required to address graceful removal of a TE link (bundled or unbundled), a component link within a bundled TE link, a set of TE links, a set of component links or an entire node. - Graceful shutdown is equally applicable to MPLS, as well as GMPLS LSPs. - It is required to prevent other network nodes to use network resources which are about to be shutdown, should new TE LSP be set up. As RSVP mechanisms only convey the information for the transiting LSPs to the router along the upstream Path and not to all nodes in the network, indication of graceful shutdown via IGP flooding is required to discourage a node from establishing new LSPs through the resources being shut-down. - Graceful shutdown mechanisms are required to address TE LSPs spanning multiple domains, as well as intra domain TE LSPs. Here, a domain is defined as either an IGP area or an Autonomous System [INTER-AREA-AS]. An IGP based solution is not applicable when dealing with Inter-area and Inter-AS traffic engineering, as LSA or LSP flooding is restricted to IGP areas/levels. Consequently, RSVP based mechanisms are required to cope with TE LSPs spanning multiple domains. - Graceful shutdown mechanisms are required to reduce/eliminate traffic disruption by rerouting of the TE LSPs using the resource under graceful shutdown, in a non disruptive fashion. It is required to rely on existing mechanisms like make-before-break and protection Z. Ali, et al. Page 4 2/20/2005 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 (FRR, path/ segment protection); selection of actual mechanism is a local matter at the node handling graceful shutdown event. - It is required to co-ordinate graceful shutdown with the protection available for the TE link or the affected LSP, e.g., in packet switching capable nodes, when a graceful shutdown operation is performed along the path of a protected LSP, the PLR MAY trigger Fast Reroute [FRR] for the appropriate set of affected TE LSPs. Similarly, when unbundled TE link is protected and maintenance of components within the protected TE link is possible using means other than graceful shutdown mechanisms (e.g., by L2), graceful shutdown may be handled by a local switchover without informing the network of graceful shutdown condition. - In case of bundled TE links, RSVP flows are pinned to a component link, removal of the component link does affect the LSP using it. Hence, mechanisms to gracefully shutdown a component link(s) within a bundled TE link is/ are required. - In order to make rerouting effective, it is required to carry information about the resource under graceful shutdown in the signaling message. 4. OSPF/ ISIS Mechanisms for graceful shutdown The procedures provided in this section are equally applicable to OSPF and ISIS. 4.1 Graceful Shutdown of TE link(s) The link-attribute sub-TLV defined in [OSPF-LINK-ATTRI] and [ISIS-LINK- ATTRI] has been extended to allow a Service Provider to take a TE Link or a group of TE Links out of service for administrative reasons. Specifically, the node where graceful-shutdown of a link is desired MUST originate the TE LSA/LSP containing link-attribute sub-TLV with "local maintenance required" bit set (see OSPF-LINK-ATTRI] and [ISIS- LINK-ATTRI] for encoding details). Extension to link attribute sub-TLV is preferred over use of MAX-METRIC based solution, as links with MAX-METRIC bandwidth can be used as last resort links in path computation. Nonetheless, to deal with nodes not compliant with this document, the node initiating graceful shutdown MAY also originate the TE LSA/LSP containing Link TLV with 0 unreserved bandwidth, Traffic Engineering metric set to 0xffffffff, and if the Link is non-PSC then also with 0 as Max LSP Bandwidth. Neighbors of the node under graceful shutdown procedure (either at the link, or a group of links) SHOULD continue advertise the actual unreserved bandwidth on the TE links from the neighbors to that node, without any routing adjacency change. Z. Ali, et al. Page 5 2/20/2005 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 The motivation behind procedure outlined in this section is to discourage new LSP establishment through the resource being shutdown. Hence, nodes receiving link-attribute sub-TLV with graceful shutdown indication SHOULD mark the link as unusable for further path computation in both directions. 4.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link If graceful shutdown procedure is performed for a component link within a TE Link bundle and it is not the last component link available within the TE link, the link attributes associated with the TE link are recomputed. If the removal of the component link results in a significant change event, the TE link is re-flooded with the new traffic parameters. If the last component link is being shut-down, the routing procedure outlined in Section 4.1 is used. 4.3 Graceful Shutdown of TE Node In the event of Graceful Shutdown of the entire node, the node removes the Router Address TLV from the TE advertisement. Neighbors of the node under graceful shutdown procedure SHOULD continue advertise the actual unreserved bandwidth on the TE links from the neighbors to that node, without any routing adjacency change. 4.4 Grace Period and Removal of Resource The node initiating the graceful shutdown condition SHOULD delay the removal of resources in question for some period determined by local policy. This is to allow other nodes in the network to gracefully reroute their TE LSP away from the resources being removed. 5. RSVP-TE Signaling Mechanism for graceful shutdown 5.1 Graceful Shutdown of TE link(s) The "local TE link maintenance required" error code as defined in [PATH-REOPT] is used to explicitly signal graceful shutdown of a link to the head-end node for triggering the reroute of an affected TE LSP. Specifically, the node where graceful-shutdown of a link or a set of links is desired MUST trigger a Path Error message with "local link maintenance required" sub-code for all affected LSPs. However, in packet switching capable network, when a graceful shutdown operation is performed along the path of a protected LSP, the PLR MAY trigger Fast Reroute [FRR] for the appropriate set of affected TE LSPs and forward a Path Error with "Tunnel locally repaired" sub-code, as per the procedures specified in [MPLS-FRR]. When a head-end node receives Path Error notify message with sub-code "Local Maintenance on TE Link required Flag", it SHOULD immediately perform a make-before-break or if the LSP is protected, it SHOULD Z. Ali, et al. Page 6 2/20/2005 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 immediately perform switchover to avoid traffic loss. In either case, a head-end node SHOULD avoid the IP address contained in the PathErr in performing path computation for rerouting the LSP. 5.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link MPLS TE Link Bundling draft [BUNDLE] requires that an LSP is pinned down to component link(s). Hence, when a component link is shut-down, the LSPs affected by such maintenance action needs to be re-signaled. Graceful shutdown of a component link in a bundled TE link differs from graceful shutdown of unbundled TE link or entire bundled TE link. Specifically, in the former case, when only a subset of component links and not the entire TE bundled link is being shutdown, the remaining component links of the TE links may still be able to admit new LSPs. Consequently a new error sub-code for Path Error - Notify Error is needed: 9 (TBA) Local component link maintenance required Error Sub-code for "Local component link maintenance required" is to be assigned by IANA. If the last component link is being shut-down, the procedure outlined in Section 5.1 is used. When a head-end node receives an RSVP Path Error notification with sub- code "local component link maintenance required" Flag set, it SHOULD immediately perform a make-before-break to avoid traffic loss. The head-end node MAY still use the IP address contained in the PathErr in performing path computation for rerouting the LSP. This is because, as mentioned earlier, this address is an IP address of the component link and the flag is an implicit indication that the TE link may still have capacity to admit new LSPs. However, if the ERO is to be computed such that it also provides details of the component link selection(s) along the Path, the component link selection with IP address contained in the PathErr SHOULD be avoided. As in the case of singling for bundled TE link, the choice of the component link to use is always made by the sender of the Path/REQUEST message, a node receiving the Path Err with "Maintenance on component link required" Flag set SHOULD mark the component link blocked for any future selection. 5.3 Graceful Shutdown of TE Node When graceful shutdown at node level is desired, the node in question follows procedure specified in this section for all LSPs. Z. Ali, et al. Page 7 2/20/2005 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 6. Security Considerations This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RSVP] remain relevant. 7. IANA Considerations A new error sub-code for Path Error - Notify Error is needed for "Local component link maintenance required" flag. 8. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 10. Acknowledgments Z. Ali, et al. Page 8 2/20/2005 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 The authors would like to acknowledge useful comments from David Ward, Sami Boutros and Adrian Farrel. 11. Reference 11.1 Normative Reference [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version 1, Functional Specification", RFC 2205, September 1997. [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, L. Berger, et al, January 2003. [RFC3473] L. Berger, et al, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473. [OSPF-GMPLS] K. Kompella, Y. Rekhter, et al, "OSPF Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions- 12.txt. [ISIS-GMPLS] K. Kompella, Y. Rekhter, et al, "IS-IS Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-extensions-19.txt. [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-10.txt. [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-04.txt (work in progress). [MPLS-FRR] Ping Pan, George Swallow, Alia Atlas, et al "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp- fastreroute-05.txt. [OSPF-CAP] Jean-Philippe Vasseur, P. Psenak, and S. Yasukawa, "OSPF MPLS Traffic Engineering capabilities" draft-vasseur-ccamp-ospf-te- caps-00.txt. [ISIS-CAP] Jean-Philippe Vasseur, S. Previdi, J. Mabey, and Jean-Louis Le Roux, "IS-IS MPLS Traffic Engineering capabilities", draft-vasseur- ccamp-isis-te-caps-00.txt. [OSPF-LINK-ATTRI] work in progress. [ISIS-LINK_ATTRI] Jean-Philippe Vasseur, S. Previdi, "Definition of an IS-IS Link Attribute sub-TLV", draft-vasseur-isis-link-attr-00.txt. Z. Ali, et al. Page 9 2/20/2005 draft-ali-ccamp-mpls-graceful-shutdown-01.txt Feb. 2005 [PATH-REOPT] Jean-Philippe Vasseur, and Y. Ikejiri, "Reoptimization of MPLS Traffic Engineering loosely routed LSP paths", draft-vasseur- ccamp-loose-path-reopt-01.txt. 11.2 Informative Reference [INTER-AREA-AS] Adrian Farrel, Jean-Philippe Vasseur, Arthi Ayyangar, "A Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel- ccamp-inter-domain-framework-00.txt. [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS Traffic Engineering", draft-ietf-mpls-bunle-04.txt (work in progress) Authors' Address: Zafar Ali Cisco systems, Inc., 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Email: zali@cisco.com Canada. Email: zali@cisco.com Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Anca Zamfir Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada Email: ancaz@cisco.com Z. Ali, et al. Page 10 2/20/2005