CCAMP Working Group Zafar Ali Jean Philippe Vasseur Anca Zamfir Cisco Systems, Inc. IETF Internet Draft Category: Standard Expires: December, 2004 June 2004 draft-ali-ccamp-mpls-graceful-shutdown-00.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. Z. Ali, et al. Page 1 6/14/2004 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 Abstract Graceful shutdown is a method for explicitly notifying a set of LSRs 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 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 that are 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 4.1. Graceful Shutdown of TE link(s).................................4 4.2. Graceful Shutdown of Component Link(s) in a Bundled TE Link.....5 4.3. Graceful Shutdown of TE Node....................................5 4.4. Grace Period and Removal of Resource............................5 5.1. Graceful Shutdown of TE link(s).................................5 5.2. Graceful Shutdown of Component Link(s) in a Bundled TE Link.....6 Z. Ali, et al. Page 2 6/14/2004 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 5.3. Graceful Shutdown of TE Node....................................6 9.1. Normative Reference.............................................7 9.2. Informative Reference...........................................8 1. Terminology LSR - Label Switch Router LSP - An MPLS Label Switched Path Inter-AS MPLS TE LSP: TE LSP whose Head-end LSR and Tail-end LSR do not reside within the same Autonomous System (AS) or both Head-end LSR and Tail-end LSR 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 LSR and Tail-end LSR do not reside within the same IGP area/ level or both Head-end LSR and Tail-end LSR are in the same area/ level but the TE tunnel transiting path may be across different areas/ levels. PCE: Path Computation Element whose function is to compute the path of a TE LSP it is not the head-end for. The PCE may be an LSR (e.g ABR or ASBR) in the context of some distributed PCE-based path computation scenario as defined in [INTER-AREA-AS] or a centralized Path Computation Element not forwarding packet. 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 LSR software/hardware upgrade. In all these cases, 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 LSR of the graceful shutdown events. Graceful shutdown mechanisms allow for the rerouting of the affected TE LSPs in a non disruptive fashion using the so-called make-before-break technique. Furthermore, such mechanisms also prevent other network Z. Ali, et al. Page 3 6/14/2004 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 nodes to use network resources which are about to be shutdown, should new TE LSP be set up. 3. Applicability of IGP and RSVP-TE Mechanisms 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, where a domain is defined as either an IGP area or an Autonomous System. Nonetheless, 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. The following sections specify OSPF/ISIS flooding and RSVP-TE signaling procedures for graceful removal of resources. 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 LSRs 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 has LSC or FSC as its Switching Capability 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 4 6/14/2004 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 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, procedure outlined in Section 4.1 is applied to all the links advertised by the node under shutdown. 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 LSRs 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 LSR 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, when a GS 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 or an intermediate node (in the case of loose hops path computation) or a PCE receives Path Error notify message with sub- code "Local Maintenance on TE Link required Flag", it SHOULD Z. Ali, et al. Page 5 6/14/2004 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 immediately perform a make-before-break to avoid traffic loss. A head- end router or an intermediate node (in the case of loose hops path computation) or a PCE 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 or an intermediate node (in the case of loose hops path computation) or a PCE 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 router or an intermediate node (in the case of loose hops path computation) or a PCE MAY NOT avoid 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 Z. Ali, et al. Page 6 6/14/2004 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 When graceful shutdown at node level is desired, the node in question follows procedure specified in this section for all LSPs. 6. Security Considerations This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RSVP] remain relevant. 7. Intellectual Property Considerations Cisco Systems may have intellectual property rights claimed in regard to some of the specification contained in this document 8. Acknowledgments The authors would like to acknowledge useful comments from their colleagues David Ward and Sami Boutros. 9. Reference 9.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). Z. Ali, et al. Page 7 6/14/2004 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 [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. [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. 9.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. 100 South Main St. #200 Ann Arbor, MI 48104 USA 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 Z. Ali, et al. Page 8 6/14/2004 draft-ali-ccamp-mpls-graceful-shutdown-00.txt June 2004 Kanata, Ontario, K2K 3E8 Canada ancaz@cisco.com Z. Ali, et al. Page 9 6/14/2004