MPLS-TE Shutdown: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks
Telling the network a link is about to go away, so traffic can be moved first.
Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", RFC 5817, DOI 10.17487/RFC5817, April 2010, <https://www.rfc-editor.org/info/rfc5817>.
@misc{rfc5817,
series = {Request for Comments},
number = 5817,
howpublished = {RFC 5817},
publisher = {RFC Editor},
doi = {10.17487/RFC5817},
url = {https://www.rfc-editor.org/info/rfc5817},
author = {Z. Ali and JP. Vasseur and A. Zamfir and J. Newton},
title = {{Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks}},
pagetotal = 11,
year = 2010,
month = apr,
} RFC text
Contents
Internet Engineering Task Force (IETF) Z. Ali
Request for Comments: 5817 JP. Vasseur
Category: Informational A. Zamfir
ISSN: 2070-1721 Cisco Systems, Inc.
J. Newton
Cable and Wireless
April 2010
Graceful Shutdown in MPLS and Generalized MPLS
Traffic Engineering Networks
Abstract
MPLS-TE Graceful Shutdown is a method for explicitly notifying the
nodes in a Traffic Engineering (TE) enabled network that the TE
capability on a link or on an entire Label Switching Router (LSR) is
going to be disabled. MPLS-TE graceful shutdown mechanisms are
tailored toward addressing planned outage in the network.
This document provides requirements and protocol mechanisms to reduce
or eliminate traffic disruption in the event of a planned shutdown of
a network resource. These operations are equally applicable to both
MPLS-TE and its Generalized MPLS (GMPLS) extensions.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5817.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Requirements for Graceful Shutdown ..............................4
4. Mechanisms for Graceful Shutdown ................................5
4.1. OSPF / IS-IS Mechanisms for Graceful Shutdown ..............5
4.2. RSVP-TE Signaling Mechanisms for Graceful Shutdown .........6
5. Manageability Considerations ....................................8
6. Security Considerations .........................................8
7. Acknowledgments .................................................8
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
1. Introduction
When outages in a network are planned (e.g., for maintenance
purposes), some mechanisms can be used to avoid traffic disruption.
This is in contrast with unplanned network element failure, where
traffic disruption can be minimized thanks to recovery mechanisms,
but may not be avoided. Therefore, a Service Provider may desire to
gracefully (temporarily or indefinitely) remove a TE link, a group of
TE links, or an entire node for administrative reasons such as link
maintenance, software/hardware upgrade at a node, or significant TE
configuration changes. In all these cases, the goal is to minimize
the impact on the traffic carried over TE LSPs in the network by
triggering notifications so as to gracefully reroute such flows
before the administrative procedures are started.
These operations are equally applicable to both MPLS-TE [RFC3209] and
its Generalized MPLS (GMPLS) extensions [RFC3471] [RFC3473].
This document describes the mechanisms that can be used to gracefully
shut down MPLS-TE / GMPLS-TE on a resource such as a TE link, a
component link within a bundled TE link, a label resource, or an
entire TE node.
Graceful shutdown of a resource may require several steps. These
steps can be broadly divided into two sets: disabling the resource in
the control plane and disabling the resource in the data plane. The
node initiating the graceful shutdown condition introduces a delay
between the two sets to allow the control plane to gracefully divert
the traffic away from the resource being gracefully shut down. The
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.
2. Terminology
LSR: Label Switching Router. The terms node and LSR are used
interchangeably in this document.
GMPLS: The term GMPLS is used in this document to refer to packet
MPLS-TE, as well as GMPLS extensions to MPLS-TE.
TE Link: The term TE link refers to a single link or a bundle of
physical links or FA-LSPs (see below) on which traffic engineering
is enabled.
TE LSP: A Traffic Engineered Label Switched Path.
S-LSP: A segment of a TE LSP.
FA-LSP (Forwarding Adjacency LSP): An LSP that is announced as a TE
link into the same instance of the GMPLS control plane as the one
that was used to create the LSP [RFC4206].
ISIS-LSP: Link State Packet that is generated by IS-IS routers and
that contains routing information.
LSA: Link State Advertisement that is generated by OSPF routers and
that contains routing information.
TE LSA / TE-IS-IS-LSP: The traffic engineering extensions to OSPF /
IS-IS.
Head-end node: Ingress LSR that initiated signaling for the Path.
Border node: Ingress LSR of a TE LSP segment (S-LSP).
PCE (Path Computation Element): An entity that computes the routes on
behalf of its clients (PCC) [RFC4655].
Last-resort resource: If a path to a destination from a given head-
end node cannot be found upon removal of a resource (e.g., TE
link, TE node), the resource is called "last resort" to reach that
destination from the given head-end node.
3. Requirements for Graceful Shutdown
This section lists the requirements for graceful shutdown in the
context of GMPLS.
- Graceful shutdown is required to address graceful removal of one TE
link, one component link within a bundled TE link, a set of TE
links, a set of component links, label resources, or an entire
node.
- Once an operator has initiated graceful shutdown of a network
resource, no new TE LSPs may be set up that use the resource. Any
signaling message for a new TE LSP that explicitly specifies the
resource, or that would require the use of the resource due to
local constraints, is required to be rejected as if the resource
were unavailable.
- It is desirable for new TE LSP set-up attempts that would be
rejected because of graceful shutdown of a resource (as described
in the previous requirement) to avoid any attempt to use the
resource by selecting an alternate route or other resources.
- If the resource being shut down is a last-resort resource, based on
a local decision, the node initiating the graceful shutdown
procedure can cancel the shutdown operation.
- It is required to give the ingress node the opportunity to take
actions in order to reduce or eliminate traffic disruption on the
TE LSPs that are using the network resources that are about to be
shut down.
- Graceful shutdown mechanisms are equally applicable to intra-domain
TE LSPs and those spanning multiple domains, as defined in
[RFC4726]. Examples of such domains include IGP areas and
Autonomous Systems.
- Graceful shutdown is equally applicable to packet and non-packet
networks.
- In order to make rerouting effective, it is required that when a
node initiates the graceful shutdown of a resource, it notifies all
other network nodes about the TE resource under graceful shutdown.
- Depending on switching technology, it may be possible to shut down
a label resource, e.g., shutting down a lambda in a Lambda Switch
Capable (LSC) node.
4. Mechanisms for Graceful Shutdown
An IGP-only solution based on [RFC3630], [RFC5305], [RFC4203] and
[RFC5307] is not applicable when dealing with inter-area and inter-AS
traffic engineering, as IGP flooding is restricted to IGP
areas/levels. An RSVP-based solution is proposed in this document to
handle TE LSPs spanning multiple domains. In addition, in order to
discourage nodes from establishing new TE LSPs through the resources
being shut down, existing IGP mechanisms are used for the shutdown
notification.
A node where a link or the whole node is being shut down first
triggers the IGP updates as described in Section 4.1 and then, with
some delay to allow network convergence, uses the signaling mechanism
described in Section 4.2.
4.1. OSPF / IS-IS Mechanisms for Graceful Shutdown
This section describes the use of existing OSPF and IS-IS mechanisms
for the graceful shutdown in GMPLS networks.
The OSPF and IS-IS procedures for graceful shutdown of TE links are
similar to the graceful restart of OSPF and IS-IS as described in
[RFC4203] and [RFC5307], respectively. Specifically, the node where
graceful shutdown of a link is desired originates the TE LSA or IS-
IS-LSP containing a Link TLV for the link under graceful shutdown
with the Traffic Engineering metric set to 0xffffffff, 0 as
unreserved bandwidth. If the TE link has LSC or FSC as its Switching
Capability, then it also has 0 in the "Max LSP Bandwidth" field of
the Interface Switching Capability Descriptor (ISCD) sub-TLV. A node
may also specify a value that is greater than the available bandwidth
in the "Minimum LSP bandwidth" field of the same ISCD sub-TLV. This
would discourage new TE LSP establishment through the link under
graceful shutdown.
If the 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. Similarly, if the graceful shutdown
procedure is performed on a label resource within a TE link, the link
attributes associated with the TE link are recomputed. If the
removal of the component link or label resource results in a
significant bandwidth change event, a new LSA is originated with the
new traffic parameters. If the last component link is being shut
down, the routing procedure related to TE link removal is used.
Neighbors of the node where graceful shutdown procedure is in
progress continue to advertise the actual unreserved bandwidth of the
TE links from the neighbors to that node, without any routing
adjacency change.
When graceful shutdown at node level is desired, the node in question
follows the procedure specified in the previous section for all TE
links.
4.2 RSVP-TE Signaling Mechanisms for Graceful Shutdown
As discussed in Section 3, one of the requirements for the signaling
mechanism for graceful shutdown is to carry information about the
resource under graceful shutdown. For this purpose, the graceful
shutdown procedure uses TE LSP rerouting mechanism as defined in
[RFC5710].
Specifically, the node where graceful shutdown of an unbundled TE
link or an entire bundled TE link is desired triggers a PathErr
message with the error code "Notify" and error value "Local link
maintenance required", for all affected TE LSPs. Similarly, the node
that is being gracefully shut down triggers a PathErr message with
the error code "Notify" and error value "Local node maintenance
required", for all TE LSPs. For graceful shutdown of a node, an
unbundled TE link, or an entire bundled TE link, the PathErr message
may contain either an [RFC2205] format ERROR_SPEC object or an IF_ID
[RFC3473] format ERROR_SPEC object. In either case, it is the
address and TLVs carried by the ERROR_SPEC object and not the error
value that indicate the resource that is to be gracefully shut down.
MPLS-TE link bundling [RFC4201] requires that an TE LSP is pinned
down to a component link. Consequently, 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
bundled TE link is being shut down, the remaining component links of
the bundled TE link may still be able to admit new TE LSPs. The node
where graceful shutdown of a component link is desired triggers a
PathErr message with the error code "Notify" and error value of
"Local link maintenance required". The rest of the ERROR_SPEC object
is constructed using Component Reroute Request procedure defined in
[RFC5710].
If graceful shutdown of a label resource is desired, the node
initiating this action triggers a PathErr message with the error
codes and error values of "Notify/Local link maintenance required".
The rest of the ERROR_SPEC object is constructed using the Label
Reroute Request procedure defined in [RFC5710].
When a head-end node, a transit node, or a border node receives a
PathErr message with the error code "Notify" and error value "Local
link maintenance required" or "Local node maintenance required", it
follows the procedures defined in [RFC5710] to reroute the traffic
around the resource being gracefully shut down. When performing path
computation for the new TE LSP, the head-end node or border node
avoids using the TE resources identified by the ERROR_SPEC object.
If the PCE is used for path computation, the head-end (or border)
node acting as PCC specifies in its requests to the PCE that path
computation should avoid the resource being gracefully shut down.
The amount of time the head-end node or border node avoids using the
TE resources identified by the IP address contained in the PathErr is
based on a local decision at that node.
If the node initiating the graceful shutdown procedure receives a
path setup request for a new tunnel-using resource being gracefully
shut down, it sends a PathErr message with "Notify" error code in the
ERROR SPEC object and an error value consistent with the type of
resource being gracefully shut down. However, based on a local
decision, if an existing tunnel continues to use the resource being
gracefully shut down, the node initiating the graceful shutdown
procedure may allow that resource being gracefully shut down to be
used as a "last resort". The node initiating the graceful shutdown
procedure can distinguish between new and existing tunnels by
inspecting the SENDER TEMPLATE and SESSION objects.
If the resource being shut down is a last-resort resource, it can be
used; i.e., based on a local decision, the node initiating the
graceful shutdown procedure can cancel the shutdown operation.
Similarly, based on a local decision, the node initiating the
graceful shutdown procedure can delay the actual removal of resource
for forwarding. This is to give time to the network to move traffic
from the resource being shut down. For this purpose, the node
initiating graceful shutdown procedure follows the Reroute Request
Timeout procedure defined in [RFC5710].
5. Manageability Considerations
When a TE link is being shut down, a linkDown trap as defined in
[RFC2863] should be generated for the TE link. Similarly, if a
bundled TE link is being shut down, a linkDown trap as defined in
[RFC2863] should be generated for the bundled TE link, as well as for
each of its component links. If a TE node is being shut down, a
linkDown trap as defined in [RFC2863] should be generated for all TE
links at the node.
6. Security Considerations
This document introduces no new security considerations as it
describes usage of existing formats and mechanisms. This document
relies on existing procedures for advertisement of TE LSA / IS-IS-
LSPs containing Link TLVs. Tampering with TE LSAs / IS-IS-LSPs may
have an effect on traffic engineering computations, and it is
suggested that any mechanisms used for securing the transmission of
normal LSAs / IS-IS-LSPs be applied equally to all Opaque LSAs / IS-
IS-LSPs that this document uses. Existing security considerations
specified in [RFC3630], [RFC5305], [RFC4203], [RFC5307], and
[MPLS-GMPLS-SEC] remain relevant and suffice. Furthermore, the
Security Considerations section in [RFC5710] and section 9 of
[RFC4736] should be used for understanding the security
considerations related to the formats and mechanisms used in this
document.
7. Acknowledgments
The authors would like to thank Adrian Farrel for his detailed
comments and suggestions. The authors would also like to acknowledge
useful comments from David Ward, Sami Boutros, and Dimitri
Papadimitriou.
8. References
8.1. Normative References
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
and S. Jamin, "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC5710] Berger, L., Papadimitriou, D., and JP. Vasseur,
"PathErr Message Triggered MPLS and GMPLS LSP
Reroutes", RFC 5710, January 2010.
8.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
"Reoptimization of Multiprotocol Label Switching
(MPLS) Traffic Engineering (TE) Loosely Routed Label
Switched Path (LSP)", RFC 4736, November 2006.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Framework for Inter-Domain Multiprotocol Label
Switching Traffic Engineering", RFC 4726, November
2006.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link
Bundling in MPLS Traffic Engineering (TE)", RFC
4201, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol
Label Switching (GMPLS) Traffic Engineering (TE)",
RFC 4206, October 2005.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC
4655, August 2006.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces
Group MIB", RFC 2863, June 2000.
[MPLS-GMPLS-SEC] Luyuan F., Ed., "Security Framework for PLS and
GMPLS Networks", Work in Progress, March 2010.
Authors' Addresses
Zafar Ali
Cisco systems, Inc.,
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
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
Jonathan Newton
Cable and Wireless
EMail: jonathan.newton@cw.com
ISO Plain Language
On this page
§1Introduction
When outages in a network are planned, for maintenance for example, mechanisms can be used to avoid traffic disruption. This is different from unplanned element failure, where traffic disruption can be minimised by recovery mechanisms but may not be avoided. A service provider may therefore want to remove a traffic-engineered link, a group of links or an entire node temporarily or indefinitely, for reasons such as link maintenance, a software or hardware upgrade at a node, or significant traffic engineering configuration changes. In all of these cases the goal is to minimise the impact on the traffic carried over traffic-engineered label switched paths by triggering notifications so that the flows are rerouted gracefully before the administrative procedures start.
The operations described apply equally to MPLS-TE and to its Generalized MPLS extensions. The document describes graceful shutdown of a resource such as a traffic-engineered link, a component link inside a bundled link, a label resource or an entire traffic-engineered node.
Graceful shutdown may take several steps, divided into two sets: disabling the resource in the control plane and disabling it in the data plane. The node that starts the shutdown introduces a delay between the two sets, so that the control plane has time to divert traffic away from the resource. The trigger for the event is a local matter at the node that starts it, and graceful shutdown is typically triggered for administrative reasons such as link maintenance or an upgrade.
A planned shutdown has two parts. The network is first told that the link is going away, and traffic is moved elsewhere. Only after a pause is the link actually switched off, so that nothing is dropped.
- IGP UPDATEThe link is advertised with the traffic engineering metric set to 0xffffffff, so no new path is built over it.
- PATH COMPUTATIONThe network converges on paths that avoid the link.
- PATHERR NOTIFYThe affected paths are told that local link maintenance is required, naming the resource in the ERROR_SPEC object.
- NEW PATHThe head-end signals a replacement path that avoids the resource, and the old path is torn down.
§3Requirements for Graceful Shutdown
The requirements cover graceful removal of one traffic-engineered link, one component link within a bundled link, a set of links, a set of component links, label resources, or an entire node.
Once an operator has started the shutdown of a resource, no new traffic-engineered path may be set up that uses it. Any signalling message for a new path that explicitly specifies the resource, or that would need it because of local constraints, is required to be rejected as if the resource were unavailable. It is desirable for such set-up attempts to avoid the resource altogether by selecting an alternate route or other resources.
If the resource being shut down is the last-resort resource for reaching a destination from a given head-end node, then the node that started the shutdown can cancel the operation, based on a local decision. The ingress node must be given the opportunity to take actions that reduce or eliminate traffic disruption on the paths using the resources that are about to be shut down.
The mechanisms are equally applicable to paths inside one domain and to paths spanning multiple domains, such as IGP areas and autonomous systems, and to packet and non-packet networks. For rerouting to work, a node that starts the shutdown has to notify all the other network nodes about the resource under shutdown. Depending on the switching technology it may also be possible to shut down a label resource, for example one lambda in a lambda switch capable node.
While a resource is being closed, new paths must not be set up over it, and the nodes at the ends of the affected paths must be told so that they can build new paths. If there is no other way to reach a destination, the operator's node can call the whole thing off.
§4.1OSPF and IS-IS Notification
An approach based only on the interior gateway protocols is not applicable to inter-area and inter-autonomous-system traffic engineering, because IGP flooding is restricted to IGP areas and levels. The document therefore uses RSVP signalling for paths that span multiple domains, and uses existing IGP mechanisms for the shutdown notification, which discourages nodes from setting up new paths over the resources being shut down. A node where a link or the whole node is being shut down first triggers the IGP updates, and then, after a delay that allows the network to converge, uses the RSVP signalling.
The OSPF and IS-IS procedures are similar to the graceful restart procedures of those protocols. The node where the shutdown of a link is wanted originates the traffic engineering LSA or IS-IS LSP containing a Link TLV for the link under shutdown, with the traffic engineering metric set to 0xffffffff, that is, 0 as unreserved bandwidth. If the link has a lambda or fibre switching capability, it also has 0 in the maximum LSP bandwidth field of the Interface Switching Capability Descriptor sub-TLV. A node may also specify a value greater than the available bandwidth in the minimum LSP bandwidth field of the same sub-TLV, which discourages new path establishment through the link.
If the shutdown covers a component link inside a bundle and it is not the last component link available, the link attributes for the bundle are recomputed, and the same is done when a label resource inside a link is shut down. If that removal causes a significant bandwidth change event, a new LSA is originated with the new traffic parameters. If the last component link is being shut down, the routing procedure for link removal is used instead. Neighbours of the node where the shutdown is in progress continue to advertise the actual unreserved bandwidth of their links to that node, without any routing adjacency change. A node-level shutdown follows the same procedure for all of its traffic-engineered links.
The first step uses the routing protocol the network already runs. The node advertises the link as having no bandwidth left, so every router in the area stops sending new traffic over it and can plan a different path.
§4.2RSVP-TE Signalling and Rerouting
The signalling part of the shutdown uses the TE LSP rerouting mechanism defined in RFC 5710. A node where the shutdown of an unbundled link or of an entire bundled link is wanted triggers a PathErr message with the error code Notify and the error value Local link maintenance required, for all affected paths. A node that is itself being shut down triggers a PathErr with the error code Notify and the error value Local node maintenance required, for all paths. The PathErr message may carry either an RFC 2205 format ERROR_SPEC object or an IF_ID format one, and it is the address and TLVs carried by that object, not the error value, that indicate which resource is being shut down.
Shutting down one component link of a bundle is different, because a path is pinned to a component link, and the remaining component links may still admit new paths. The node triggers a PathErr with the error code Notify and the error value Local link maintenance required, and builds the rest of the ERROR_SPEC object using the component reroute request procedure. Shutting down a label resource uses the error code and value Notify with Local link maintenance required, and the label reroute request procedure.
When a head-end node, a transit node or a border node receives one of these PathErr messages, it follows the procedures of RFC 5710 to reroute the traffic around the resource. When it computes the new path it avoids the resources named in the ERROR_SPEC object. If a Path Computation Element does the computation, the node acting as its client states in the request that the computation should avoid the resource. How long the node keeps avoiding the resource is a local decision.
If the node that started the shutdown receives a path setup request for a new tunnel that would use the resource, it answers with a PathErr carrying the Notify code and an error value consistent with the type of resource. If the resource is the last-resort resource for a destination, the node can cancel the shutdown instead. The node can also delay the actual removal of the resource from forwarding, following the reroute request timeout procedure, which gives the network time to move traffic away. New and existing tunnels are told apart by inspecting the sender template and session objects.
The second step uses the signalling that already sets up traffic-engineered paths. The node that is closing the link sends a message to the paths affected, naming the link or node being closed, and the far end of each path then works out a new route that avoids it.
- Notify / Local link maintenance requiredLink shutdown — Sent for an unbundled link, a bundle, or a component link inside a bundle that is not the last one.
- Notify / Local node maintenance requiredNode shutdown — Sent for all paths when the node itself is being shut down.
- RFC 2205 ERROR_SPECResource identification — The address and TLVs in the object name the resource to be shut down.
- IF_ID ERROR_SPECAlternative object format — The GMPLS interface identifier form of the same object may be used instead.
§5Manageability Considerations
When a traffic-engineered link is being shut down, a linkDown trap as defined in RFC 2863 should be generated for that link. When a bundled link is being shut down, a linkDown trap should be generated for the bundled link and for each of its component links. When a traffic-engineered node is being shut down, a linkDown trap should be generated for all of the traffic-engineered links at that node.
The management system is told about the shutdown the same way it is told about a broken link, so that the usual monitoring reacts in the usual way.
§6Security Considerations
The document introduces no new security considerations, because it describes the use of existing formats and mechanisms. It relies on the existing procedures for advertising traffic engineering LSAs and IS-IS LSPs containing Link TLVs. Tampering with those advertisements may affect traffic engineering computations, and the memo suggests that any mechanisms used to secure the transmission of normal LSAs and IS-IS LSPs be applied equally to the opaque LSAs and IS-IS LSPs this document uses. The security considerations given in RFC 3630, RFC 5305, RFC 4203 and RFC 5307 remain relevant and sufficient, together with the security considerations of RFC 5710 and Section 9 of RFC 4736.
No new security rules are introduced, because the shutdown reuses messages that already exist. The existing rules for protecting routing advertisements apply to these messages too.