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