draft-ietf-ccamp-mpls-graceful-shutdown-05.txt   draft-ietf-ccamp-mpls-graceful-shutdown-06.txt 
Networking Working Group CCAMP Working Group
Internet Draft Internet Draft
Zafar Ali Zafar Ali
Jean-Philippe Vasseur Jean-Philippe Vasseur
Anca Zamfir Anca Zamfir
Cisco Systems, Inc. Cisco Systems, Inc.
Jonathan Newton Jonathan Newton
Cable and Wireless Cable and Wireless
Intended status: Informational July 03, 2008
Expires: January 02, 2009
Category: Informational draft-ietf-ccamp-mpls-graceful-shutdown-06.txt
Expires: July 2008 January 2008
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt
Graceful Shutdown in MPLS and Generalized MPLS Graceful Shutdown in MPLS and Generalized MPLS
Traffic Engineering Networks Traffic Engineering Networks
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
skipping to change at page 1, line 45 skipping to change at page 1, line 44
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 2008. This Internet-Draft will expire on January 02, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07 draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
Abstract Abstract
MPLS-TE Graceful Shutdown is a method for explicitly notifying MPLS-TE Graceful Shutdown is a method for explicitly notifying
the nodes in a Traffic Engineering (TE) enabled network that the the nodes in a Traffic Engineering (TE) enabled network that the
TE capability on a link or on an entire Label Switching Router TE capability on a link or on an entire Label Switching Router
(LSR) is going to be disabled. MPLS-TE graceful shutdown (LSR) is going to be disabled. MPLS-TE graceful shutdown
mechanisms are tailored toward addressing planned outage in the mechanisms are tailored toward addressing planned outage in the
network. network.
This document provides requirements and protocol mechanisms to This document provides requirements and protocol mechanisms to
reduce/eliminate traffic disruption in the event of a planned reduce/eliminate traffic disruption in the event of a planned
shutdown of a network resource. These operations are equally shutdown of a network resource. These operations are equally
applicable to both MPLS and its Generalized MPLS (GMPLS) applicable to both MPLS and its Generalized MPLS (GMPLS)
extensions. extensions.
Conventions used in this document Table of Contents
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 1. Introduction................................................2
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 2. Terminology.................................................3
"OPTIONAL" in this document are to be interpreted as described in 3. Requirements for Graceful Shutdown..........................4
RFC-2119 [RFC2119]. 4. Mechanisms for Graceful Shutdown............................5
4.1 OSPF/ ISIS Mechanisms for graceful shutdown................5
4.2 RSVP-TE Signaling Mechanisms for graceful shutdown.........6
5. Security Considerations.....................................8
6. IANA Considerations.........................................8
7. Acknowledgments.............................................8
8. Reference...................................................8
8.1 Normative Reference........................................8
8.2 Informative Reference......................................9
9. Authors' Address:..........................................10
10. Intellectual Property Considerations......................10
11. Disclaimer of Validity....................................11
12. Copyright Statement.......................................11
Table of Contents 1. Introduction
1. Terminology.....................................................3 When outages in a network are planned (e.g. for maintenance
2. Introduction....................................................3 purpose), some mechanisms can be used to avoid traffic
3. Requirements for Graceful Shutdown..............................4 disruption. This is in contrast with unplanned network element
4. Mechanisms for Graceful Shutdown................................5 failure, where traffic disruption can be minimized thanks to
4.1 OSPF/ ISIS Mechanisms for graceful shutdown....................5 recovery mechanisms but may not be avoided. Hence, a Service
4.1.1 Graceful Shutdown of TE link(s)..............................5 Provider may desire to gracefully (temporarily or indefinitely)
4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link .5 remove a TE Link, a group of TE Links or an entire node for
4.1.3 Graceful Shutdown of TE Node.................................6 administrative reasons such as link maintenance,
4.1.4 Graceful Shutdown of Label Resource..........................6 software/hardware upgrade at a node or significant TE
4.2 RSVP-TE Signaling Mechanism for graceful shutdown..............6 configuration changes. In all these cases, the goal is to
4.2.1 Graceful Shutdown of TE link(s)..............................6 minimize the impact on the traffic carried over TE LSPs in the
4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link .7 network by triggering notifications so as to gracefully reroute
4.2.3 Graceful Shutdown of TE Node.................................8 draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
4.2.2 Graceful Shutdown of a Label Resource........................8
5. Security Considerations.........................................8
6. IANA Considerations.............................................9
7. Acknowledgments.................................................9
8. Reference.......................................................9
8.1 Normative Reference............................................9
8.2 Informative Reference..........................................9
9. Authors' Address:..............................................10
10. Intellectual Property Considerations..........................10
11. Disclaimer of Validity........................................11
12. Copyright Statement...........................................11
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07
1. Terminology such flows before the administrative procedures are started.
These operations are equally applicable to both MPLS and its
Generalized MPLS (GMPLS) extensions.
LSR (Label Switching Router): The terms node and LSR are used 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 removing the resource for
forwarding. The node initiating the graceful shutdown condition
is expected to introduce a delay between disabling the resource
in the control plane and removing the resource for forwarding.
This is to allow the control plane to gracefully divert the
traffic away from the resource being gracefully shutdown. 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.
This document describes the mechanisms that can be used to
gracefully shutdown MPLS/ GMPLS Traffic Engineering on a
resource. As mentioned earlier, the graceful shutdown of the
Traffic Engineering capability on a resource could be
incorporated in the shutdown operation of an interface, but it is
a separate step that is taken before the IGP on the link is
brought down and before the interface is brought down at
different layers. This document only addresses TE nodes and TE
resources.
2. Terminology
LSR - Label Switching Router. The terms node and LSR are used
interchangeably in this document. interchangeably in this document.
GMPLS: The term GMPLS is used in this document to refer to GMPLS -
- The term GMPLS is used in this document to refer to
packet MPLS-TE, as well as GMPLS extensions to MPLS-TE. packet MPLS-TE, as well as GMPLS extensions to MPLS-TE.
LSP: An MPLS-TE/ GMPLS-TE Label Switched Path. LSP - An MPLS-TE/ GMPLS-TE Label Switched Path.
Head-end node: Ingress LSR that initiated signaling for the Path. Head-end node: Ingress LSR that initiated signaling for the Path.
Border node: Ingress LSR of an LSP segment (S-LSP). Border node: Ingress LSR of an LSP segment (S-LSP).
Path Computation Element (PCE): An entity that computes the Path Computation Element (PCE): An entity that computes the
routes on behalf of its clients (PCC). routes on behalf of its clients (PCC).
TE Link: The term TE link refers to single or a bundle of TE Link -
- The term TE link refers to single or a bundle of
physical link(s) or FA-LSP(s) on which traffic engineering is physical link(s) or FA-LSP(s) on which traffic engineering is
enabled [RFC4206], [RFC4201]. enabled [RFC4206], [RFC4201].
2. Introduction 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.,
When outages in a network are planned (e.g. for maintenance draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
purpose), 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. 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,
software/hardware upgrade at a node or significant TE
configuration changes. In all these cases, the goal is to
minimize the impact on the GMPLS traffic engineered flows carried
over TE LSPs in the network by triggering notifications so as to
gracefully reroute such flows before the administrative
procedures are started.
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 removing the resource for
forwarding. The node initiating the graceful shutdown condition
SHOULD introduce a delay between disabling the resource in the
control plane and removing the resource for forwarding. This is
to allow the control plane to gracefully divert the traffic away
from the resource being gracefully shutdown. 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.
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07
This document describes the mechanisms that can be used to TE link, TE node), the resource is called last resort to reach
gracefully shutdown GMPLS Traffic Engineering on a resource. As that destination from the given head-end node.
mentioned earlier, the graceful shutdown of the Traffic
Engineering capability on a resource could be incorporated in the
shutdown operation of an interface, but it is a separate step
that is taken before the IGP on the link is brought down and
before the interface is brought down at different layers. This
document only addresses TE nodes and TE resources.
3. Requirements for Graceful Shutdown 3. Requirements for Graceful Shutdown
This section lists the requirements for graceful shutdown in the This section lists the requirements for graceful shutdown in the
context of GMPLS Traffic Engineering. context of GMPLS Traffic Engineering.
- Graceful shutdown must address graceful removal of one TE link, - Graceful shutdown is required to address graceful removal of
one component link within a bundled TE link, a set of TE links, a one TE link, one component link within a bundled TE link, a set
set of component links or an entire node. of TE links, a set of component links, label resource(s) or an
entire node.
- Once an operator has initiated graceful shutdown of a network - Once an operator has initiated graceful shutdown of a network
resource, no new TE LSPs may be set up that use the resource. resource, no new TE LSPs may be set up that use the resource.
Any signaling message for a new LSP that explicitly specifies the Any signaling message for a new LSP that explicitly specifies the
resource, or that would require the use of the resource due to resource, or that would require the use of the resource due to
local constraints, must be rejected as if the resource were local constraints, is required to be rejected as if the resource
unavailable. were unavailable.
- It is desirable for new LSP setup attempts that would be - It is desirable for new LSP setup attempts that would be
rejected because of graceful shutdown of a resource (as described rejected because of graceful shutdown of a resource (as described
in the previous requirement) to avoid any attempt to use the in the previous requirement) to avoid any attempt to use the
resource by selecting an alternate route or other resources. resource by selecting an alternate route or other resources.
- If the resource being shutdown is a last resort, it can be - If the resource being shutdown is a last resort, it can be
used. Time or decision for removal of the resource being shutdown used. Time or decision for removal of the resource being shutdown
is based on a local decision at the node initiating the graceful is based on a local decision at the node initiating the graceful
shutdown procedure. shutdown procedure.
skipping to change at page 5, line 4 skipping to change at page 4, line 50
- Graceful shutdown mechanisms are equally applicable to intra- - Graceful shutdown mechanisms are equally applicable to intra-
domain and TE LSPs spanning multiple domains. Here, a domain is domain and TE LSPs spanning multiple domains. Here, a domain is
defined as either an IGP area or an Autonomous System [RFC4726]. defined as either an IGP area or an Autonomous System [RFC4726].
- Graceful shutdown is equally applicable to GMPLS-TE, as well as - Graceful shutdown is equally applicable to GMPLS-TE, as well as
packet-based (MPLS) TE LSPs. packet-based (MPLS) TE LSPs.
- In order to make rerouting effective, it is required that when - In order to make rerouting effective, it is required that when
a node initiates the graceful shutdown of a resource, it a node initiates the graceful shutdown of a resource, it
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07
identifies to all other network nodes the TE resource under identifies to all other network nodes the TE resource under
graceful shutdown. graceful shutdown.
- Depending on switching technology, it may be possible to - Depending on switching technology, it may be possible to
shutdown a label resource, e.g., shutting down a lambda in a shutdown a label resource, e.g., shutting down a lambda in a
Lambda Switch Capable (LSC) node. Lambda Switch Capable (LSC) node.
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
4. Mechanisms for Graceful Shutdown 4. Mechanisms for Graceful Shutdown
An IGP only based solution is not applicable when dealing with An IGP only solution based on [RFC3630], [RFC3784], [RFC4203] and
Inter-area and Inter-AS traffic engineering, as IGP LSA/LSP [RFC4205] are not applicable when dealing with Inter-area and
flooding is restricted to IGP areas/levels. Consequently, RSVP Inter-AS traffic engineering, as IGP LSA/LSP flooding is
based mechanisms are required to cope with TE LSPs spanning restricted to IGP areas/levels. Consequently, RSVP based
multiple domains. At the same time, RSVP mechanisms only convey mechanisms are required to cope with TE LSPs spanning multiple
the information for the transiting LSPs to the router along the domains. At the same time, 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. Furthermore, upstream Path and not to all nodes in the network. Furthermore,
it must be noted that graceful shutdown notification via IGP graceful shutdown notification via IGP flooding is required to
flooding is required to discourage a node from establishing new discourage a node from establishing new LSPs through the
LSPs through the resources being shutdown. In the following resources being shutdown. In the following sections the
sections the complementary mechanisms for RSVP-TE and IGP for complementary mechanisms for RSVP-TE and IGP for Graceful
Graceful Shutdown are described. Shutdown are described.
A node where a link or the whole node is being shutdown SHOULD A node where a link or the whole node is being shutdown may first
first trigger the IGP updates as described in Section 4.1, trigger the IGP updates as described in Section 4.1, introduce a
introduce a delay to allow network convergence and only then use delay to allow network convergence and only then use the
the signaling mechanism described in Section 4.2. signaling mechanism described in Section 4.2.
4.1 OSPF/ ISIS Mechanisms for graceful shutdown 4.1 OSPF/ ISIS Mechanisms for graceful shutdown
The procedures provided in this section are equally applicable to The procedures provided in this section are equally applicable to
OSPF and ISIS. OSPF and ISIS.
4.1.1 Graceful Shutdown of TE link(s) OSPF and ISIS procedure for graceful shutdown of TE link(s) is
similar to graceful restart of OSPF and ISIS as described in
The node where graceful-shutdown of a link is desired MUST [RFC4203] and [RFC4205], respectively. Specifically, the node
originate the TE LSA/LSP containing Link TLV for the link under where graceful-shutdown of a link is desired originates the TE
graceful shutdown with Traffic Engineering metric set to LSA/LSP containing Link TLV for the link under graceful shutdown
0xffffffff, 0 as unreserved bandwidth, and if the link has LSC or with Traffic Engineering metric set to 0xffffffff, 0 as
FSC as its Switching Capability then also with 0 as Max LSP unreserved bandwidth, and if the link has LSC or FSC as its
Bandwidth. A node MAY also specify a value for Minimum LSP Switching Capability then also with 0 as Max LSP Bandwidth. A
bandwidth which is greater than the available bandwidth. This node may also specify a value for Minimum LSP bandwidth which is
would discourage new LSP establishment through the link under greater than the available bandwidth. This would discourage new
graceful shutdown. LSP establishment through the link under graceful shutdown.
Neighbors of the node where graceful shutdown procedure is in
progress SHOULD continue to advertise the actual unreserved
bandwidth of the TE links from the neighbors to that node,
without any routing adjacency change.
4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07
If graceful shutdown procedure is performed for a component link If graceful shutdown procedure is performed for a component link
within a TE Link bundle and it is not the last 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 available within the TE link, the link attributes associated with
the TE link are recomputed. If the removal of the component link the TE link are recomputed. Similarly, If graceful shutdown
results in a significant bandwidth change event, a new LSA is procedure is performed on a label resource within a TE Link, the
originated with the new traffic parameters. If the last component link attributes associated with the TE link are recomputed. If
link is being shutdown, the routing procedure outlined in Section the removal of the component link or label resource results in a
4.2.1 is used. significant bandwidth change event, a new LSA is originated with
the new traffic parameters. If the last component link is being
shutdown, the routing procedure related to TE link removal is
used.
4.1.3 Graceful Shutdown of TE Node draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
Neighbors of the node where graceful shutdown procedure is in
progress continues 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 When graceful shutdown at node level is desired, the node in
question follows the procedure specified in the previous section question follows the procedure specified in the previous section
for all TE Links. for all TE Links.
4.1.4 Graceful Shutdown of Label Resource 4.2 RSVP-TE Signaling Mechanisms for graceful shutdown
If 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 label resource results in a
significant change event, a new LSA is originated with the new
traffic parameters.
4.2 RSVP-TE Signaling Mechanism for graceful shutdown
As discussed in Section 3, one of the requirements for the As discussed in Section 3, one of the requirements for the
signaling mechanism for graceful shutdown is to carry information signaling mechanism for graceful shutdown is to carry information
about the resource under graceful shutdown. The Graceful Shutdown about the resource under graceful shutdown. The Graceful Shutdown
mechanism outlined in the following section, uses PathErr and mechanism outlined in the following section uses PathErr in order
where available, Notify message, in order to achieve this to achieve this requirement. These mechanisms apply to both
requirement. These mechanisms apply to both existing and new existing and new LSPs.
LSPs.
4.2.1 Graceful Shutdown of TE link(s)
The node where graceful shutdown of a link or a set of links is
desired MUST trigger a PathErr message with the error code
"Notify" and an error value of "Local link maintenance required"
for all affected LSPs. The "Notify" error code is defined in
[RFC3209] while the "local link maintenance required" error value
is defined in [RFC4736]. The PathErr message SHOULD include the
ERROR_SPEC object containing IP address of the TE Link being
gracefully shutdown. If TE link is unnumbered, the PathErr
message SHOULD include the ERROR_SPEC object containing
unnumbered ID and TE router ID for the TE Link being gracefully
shutdown. If available, and where notify requests were included
when the LSPs were initially setup, Notify message (as defined in
RFC 3471, RFC 3473) MAY also be used for delivery of this
information to the head-end node, border node or PCE.
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07
When a graceful shutdown operation is performed along the path of
a protected LSP, based on a local decision, the PLR or branch
node MAY redirect the traffic onto the local detour or protecting
segment. In all cases, the PLR or branch node MUST forward the
PathErr to the head-end node, border node, or PCE.
When a head-end node, border node, or PCE receives a PathErr (or
Notify) message with error value of " Local link maintenance
required", it MAY trigger a make-before-break procedure. When
performing path computation for the new LSP, the head-end node,
border node, or PCE SHOULD avoid using the TE resources
identified by the IP address contained in the PathErr (or Notify
message)
4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link The node where graceful shutdown of an unbundled link or an
entire bundled TE link is desired triggers a PathErr message with
the error code "Notify" and an error value of "Local link
maintenance required" for all affected LSPs. Similarly, the node
that is being gracefully shutdown triggers a PathErr message with
the error code "Notify" and an error value of "Local node
maintenance required" for all LSPs.
MPLS TE Link Bundling [RFC4201] requires that an LSP is pinned MPLS TE Link Bundling [RFC4201] requires that an LSP is pinned
down to component link(s). Hence, when a component link is down to a component link(s). Consequently, graceful shutdown of a
shutdown, the TE LSPs affected by this action need to be component link in a bundled TE link differs from graceful
resignaled. shutdown of unbundled TE link or entire bundled TE link.
Specifically, in the former case, when only a subset of component
Graceful shutdown of a component link in a bundled TE link links and not the entire TE bundled link is being shutdown, the
differs from graceful shutdown of unbundled TE link or entire remaining component links of the bundled TE link may still be
bundled TE link. Specifically, in the former case, when only a able to admit new LSPs. The node where graceful shutdown of a
subset of component links and not the entire TE bundled link is component link is desired triggers a PathErr message with the
being shutdown, the remaining component links of the bundled TE error code "Notify" and the new error value of "Local component
link may still be able to admit new LSPs. link maintenance required" for all affected LSPs. The PathErr
The node where graceful shutdown of a component link is desired message includes in the ERROR_SPEC the TE Link ID address. If the
MUST trigger a PathErr message with the error code "Notify" and last component link is being shutdown, procedure for gracefully
the new error value of "Local component link maintenance shutdown entire bundled TE link outlined above is be used,
required" for all affected LSPs. The "Notify" error code is instead.
defined in [RFC3209] while the "local component link maintenance
required" error value is introduced by this proposal:
12 (TBA) Local component link maintenance required
Error value for "Local component link maintenance required" is to
be assigned by IANA.
The PathErr message should include in the ERROR_SPEC the TE Link
ID address.
If the last component link is being shutdown, the procedure
outlined in Section 4.2.1 is used.
When a head-end node, border node, or PCE receives an RSVP If graceful shutdown of a label resource is desired, the node
PathErr or Notify message with error value "local component link initiating this action triggers a PathErr message with the error
maintenance required" Flag set, it MAY immediately perform a code "Notify" and the new error value of "Local label resource
make-before-break to avoid traffic loss. The head-end node, maintenance required" for the affected LSP. The PathErr message
border node, or PCE MAY still use the IP address contained in the includes in the ERROR_SPEC the TE Link ID address.
PathErr or Notify message in performing path computation for
rerouting the LSP. This is because, this address is an IP address
of the TE link and the flag is an implicit indication that the TE
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07
link may still have capacity to admit new LSPs. However, if the The "Notify" error code for the ERROR SPEC object is defined in
ERO is computed such that it also provides details of the [RFC3209]. The "local link maintenance required" and "local node
component link selection(s) along the Path, the component link maintenance required" error value for the "Notify" error code are
previously selected MAY be avoided. draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
4.2.3 Graceful Shutdown of TE Node defined in [RFC4736]. This document defines following two error
value for the "Notify" error code:
The node that is being gracefully shutdown MUST trigger a PathErr 12 (TBA) Local component link maintenance required
message with the error code "Notify" and an error value of "Local 13 (TBA) Local label resource maintenance required
node maintenance required" for all LSPs. The "Notify" error code
is defined in [RFC3209] while the "local node maintenance
required" error value is defined in [RFC4736].
The PathErr message should include in the ERROR_SPEC object the
MPLS-TE Node ID address
4.2.2 Graceful Shutdown of a Label Resource The PathErr message includes in the ERROR_SPEC the TE Link ID
address.
The node where graceful shutdown of a label resource is desired If unbundled TE link, component link of a bundled TE link, entire
MUST trigger a PathErr message with the error code "Notify" and bundled TE link, or label resource of a TE link is being
the new error value of "Local component link maintenance gracefully shutdown, the PathErr message includes the ERROR_SPEC
required" for the affected LSP. The "Notify" error code is object containing IP address of the TE Link being gracefully
defined in [RFC3209] while the "local component link maintenance shutdown. If TE link is unnumbered, the PathErr message includes
required" error value is introduced by this proposal: the ERROR_SPEC object containing unnumbered ID and TE node ID for
the TE Link being gracefully shutdown. Similarly, if the TE node
is being gracefully shutdown, the PathErr message includes in the
ERROR_SPEC object the MPLS-TE node ID address.
13 (TBA) Local label resource maintenance required When a head-end node, or border node receives a PathErr message
with "Notify" error code and error value of "local link
maintenance required" or "local node maintenance required", or
"local component link maintenance required", or "local label
resource maintenance required" it triggers a make-before-break
procedure. When performing path computation for the new LSP, the
head-end node, or border node avoids using the TE resources
identified by the IP address contained in the PathErr. If PCE is
used for path computation, head-end node or border node acts as
PCC to request the PCE via PCEP for path computation avoiding
resource being gracefully shutdown. The amount of time the head-
end node, or border node avoid using the TE resources identified
by the IP address contained in the PathErr is based on a local
decision at head-end node or border node.
Error value for "Local label resource maintenance required" is to If node initiating the graceful shutdown procedure received path
be assigned by IANA. setup request for a new tunnel using resource being gracefully
The PathErr message should include in the ERROR_SPEC the TE Link shutdown, it sends a Path Error message with "Notify" error code
ID address. in the ERROR SPEC object and an error value consistent with the
type of resource being gracefully shutdown. However, based on a
local decision, if node initiating the graceful shutdown
procedure received path setup request for an existing tunnel, it
may allow signaling for it. This is to allow resource being
gracefully shutdown as a "last resort". The node initiating the
graceful shutdown procedure can distinguish between new and
existing tunnels based on the tunnel ID in the SESSION object.
If the last component link is being shutdown, the procedure Time or decision for removal of the resource being shutdown from
outlined in Section 4.2.1 is used. forwarding is based on a local decision at the node initiating
the graceful shutdown procedure.
When a head-end node, border node, or PCE receives an RSVP draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
PathErr or Notify message with error value "local label resource
maintenance required" Flag set, it MAY immediately perform a
make-before-break to avoid traffic loss. The head-end node,
border node, or PCE MAY still use the IP address contained in the
PathErr or Notify message in performing path computation for
rerouting the LSP. This is because, this address is an IP address
of the TE link and the flag is an implicit indication that the TE
link may still have capacity to admit new LSPs.
5. Security Considerations 5. Security Considerations
This document introduces no new security considerations beyond This document introduces two new error values for "Notify" error
those already addressed for existing RSVP PathErr or Notify code of the ERROR SPEC object defined in [RFC3209]. The procedure
messages, or advertisement of TE LSA/LSP containing Link TLV. In in this document also uses two error values for "Notify" error
this regard, the security considerations specified in [RFC2205], code of the ERROR SPEC object already defined in [RFC4736]. This
[RFC3209] and [MPLS-GMPLS-SECURITY] remain relevant. document also introduces ways to make resources unavailable for
the control plane. It is therefore recommended that procedures in
[RFC2747], which provides mechanisms to protect against external
agents compromising the RSVP signaling state in an RSVP agent, be
used. Specifically, [RFC2747] mechanisms provide some degree of
protection to the head-end node or border node RSVP agent against
making resources unavailable for control plan from an external
agent sending Path Error messages with existing or new error code
and error values. In summary, existing security considerations
specified in [RFC2747], [RFC2205], [RFC3209], [RFC4736],
[RFC3471], [RFC3473] and [MPLS-GMPLS-SECURITY] remain relevant
and suffice.
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07 This document relies on existing procedures for advertisement of
TE LSA/LSP containing Link TLV. Tampering with TE LSAs may have
an effect on traffic engineering computations, and it is
suggested that any mechanisms used for securing the transmission
of normal OSPF LSAs/ ISIS LSPs be applied equally to all Opaque
LSAs/ LSPs this document uses. In summary, existing security
considerations specified in [RFC3630], [RFC3784], [RFC4203],
[RFC4205] and [MPLS-GMPLS-SECURITY] remain relevant and suffice.
6. IANA Considerations 6. IANA Considerations
The following assignment is required in the "Notify" subsection The following assignment is required in the "Notify" subsection
of "Error Codes and Values" section of the "RSVP PARAMETERS" of "Error Codes and Values" section of the "RSVP PARAMETERS"
registry (located at http://www.iana.org/assignments/rsvp- registry (located at http://www.iana.org/assignments/rsvp-
parameters): parameters):
12 (TBA) - "Local component link maintenance required" flag. 12 (TBA) - "Local component link maintenance required" flag.
13 (TBA) Local label resource maintenance required. 13 (TBA) Local label resource maintenance required.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Adrian Farrel for his detailed The authors would like to thank Adrian Farrel for his detailed
skipping to change at page 9, line 26 skipping to change at page 8, line 55
The authors would like to thank Adrian Farrel for his detailed The authors would like to thank Adrian Farrel for his detailed
comments and suggestions. The authors would also like to comments and suggestions. The authors would also like to
acknowledge useful comments from David Ward, Sami Boutros, and acknowledge useful comments from David Ward, Sami Boutros, and
Dimitri Papadimitriou. Dimitri Papadimitriou.
8. Reference 8. Reference
8.1 Normative Reference 8.1 Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3209] Awduche D., Berger, L., Gan, D., Li T., Srinivasan, V.,
Requirement Levels", BCP 14, RFC 2119, March 1997. Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS [RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS
Traffic Engineering loosely routed LSP paths", RFC 4736. Traffic Engineering loosely routed LSP paths", RFC 4736, November
2006.
8.2 Informative Reference 8.2 Informative Reference
[RFC2205] Braden, et al, "Resource ReSerVation Protocol (RSVP) [RFC3630] Katz D., Kompella K., Yeung D., "Traffic Engineering
Version 1, Functional Specification", RFC 2205, December 1997. (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC4726] Adrian Farrel, Jean-Philippe Vasseur, Arthi Ayyangar, [RFC3784] Smit, H. and T. Li, "Intermediate System to
"A Framework for Inter-Domain MPLS Traffic Engineering", RFC Intermediate System (IS-IS) Extensions for Traffic Engineering
4726. (TE)", RFC 3784, June 2004.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4203, October 2005.
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
System to Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205,
October 2005.
[RFC2205] Braden, R. Ed. et al, "Resource ReSerVation Protocol
(RSVP) Version 1, Functional Specification", RFC 2205, December
1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "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., Ayyangar A., "A Framework for
Inter-Domain MPLS Traffic Engineering", RFC 4726, November 2006.
[RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling
in MPLS Traffic Engineering", RFC 4201. in MPLS Traffic Engineering", RFC 4201, October 2005.
[RFC4206] Label Switched Paths (LSP) Hierarchy with Generalized [RFC4206] Kompella K., Rekhter Y., "Label Switched Paths (LSP)
Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE), Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS)
RFC 4206. Traffic Engineering (TE)", RFC 4206, October 2005.
[MPLS-GMPLS-SECURITY] Fang, et al, "Security Framework for MPLS [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
and GMPLS Networks", draft-fang-mpls-gmpls-security-framework- Cryptographic Authentication", RFC 2747, January 2000.
00.txt, work in progress. [MPLS-GMPLS-SECURITY] Fang, L. et al, "Security Framework for
MPLS and GMPLS Networks", draft-fang-mpls-gmpls-security-
framework-01.txt, work in progress.
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07 draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
9. Authors' Address: 9. Authors' Address:
Zafar Ali Zafar Ali
Cisco systems, Inc., Cisco systems, Inc.,
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada. Canada.
Email: zali@cisco.com Email: zali@cisco.com
skipping to change at page 11, line 5 skipping to change at page 11, line 5
use of such proprietary rights by implementers or users of this use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to to implement this standard. Please address the information to
the IETF at ietf-ipr@ietf.org. the IETF at ietf-ipr@ietf.org.
draft-ietf-ccamp-mpls-graceful-shutdown-05.txt July 07 draft-ietf-ccamp-mpls-graceful-shutdown-06.txt July 07
11. Disclaimer of Validity 11. Disclaimer of Validity
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
12. Copyright Statement 12. Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 54 change blocks. 
273 lines changed or deleted 276 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/