draft-ietf-ccamp-mpls-graceful-shutdown-03.txt   draft-ietf-ccamp-mpls-graceful-shutdown-04.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Networking Working Group Networking 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
Category: Informational Category: Informational
Graceful Shutdown in GMPLS Traffic Engineering Networks Graceful Shutdown in MPLS and Generalized MPLS
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
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 5 skipping to change at page 2, line 5
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 December 07, 2007. This Internet-Draft will expire on December 07, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
draft-ietf-ccamp-mpls-graceful-shutdown-03.txt June 07 draft-ietf-ccamp-mpls-graceful-shutdown-04.txt July 07
Abstract Abstract
GMPLS-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. GMPLS-TE graceful shutdown (LSR) is going to be disabled. MPLS-TE graceful shutdown
mechanisms are tailored towards addressing the planned outage in mechanisms are tailored toward addressing planned outage in the
the network. network.
This document provides requirements and protocol mechanisms so as This document provides requirements and protocol mechanisms to
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 for both MPLS and its GMPLS extensions. applicable to both MPLS and its Generalized MPLS (GMPLS)
extensions.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC-2119 [i]. RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Terminology.....................................................2 1. Terminology.....................................................3
2. Introduction....................................................3 2. Introduction....................................................3
3. Requirements for Graceful Shutdown..............................4 3. Requirements for Graceful Shutdown..............................4
4. Mechanisms for Graceful Shutdown................................4 4. Mechanisms for Graceful Shutdown................................5
4.1 RSVP-TE Signaling Mechanism for graceful shutdown............5 4.1 OSPF/ ISIS Mechanisms for graceful shutdown....................5
4.1.1 Graceful Shutdown of TE link(s)............................5 4.1.1 Graceful Shutdown of TE link(s)..............................5
4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 5 4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link .5
4.1.3 Graceful Shutdown of TE Node...............................6 4.1.3 Graceful Shutdown of TE Node.................................6
4.2 OSPF/ ISIS Mechanisms for graceful shutdown..................6 4.1.4 Graceful Shutdown of Label Resource..........................6
4.2.1 Graceful Shutdown of TE link(s)............................6 4.2 RSVP-TE Signaling Mechanism for graceful shutdown..............6
4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 7 4.2.1 Graceful Shutdown of TE link(s)..............................6
4.2.3 Graceful Shutdown of TE Node...............................7 4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link .7
5. Security Considerations.........................................7 4.2.3 Graceful Shutdown of TE Node.................................8
6. IANA Considerations.............................................7 4.2.2 Graceful Shutdown of a Label Resource........................8
7. Acknowledgments.................................................7 5. Security Considerations.........................................8
8. Reference.......................................................7 6. IANA Considerations.............................................9
8.1 Normative Reference..........................................7 7. Acknowledgments.................................................9
8.2 Informative Reference........................................8 8. Reference.......................................................9
9. Authors' Address:...............................................8 8.1 Normative Reference............................................9
10. Intellectual Property Considerations...........................8 8.2 Informative Reference..........................................9
11. Disclaimer of Validity.........................................9 9. Authors' Address:..............................................10
12. Copyright Statement............................................9 10. Intellectual Property Considerations..........................10
11. Disclaimer of Validity........................................11
12. Copyright Statement...........................................11
draft-ietf-ccamp-mpls-graceful-shutdown-04.txt July 07
1. Terminology 1. Terminology
LSR - Label Switching Device. LSR (Label Switching Router): The terms node and LSR are used
interchangeably in this document.
draft-ietf-ccamp-mpls-graceful-shutdown-03.txt June 07 GMPLS: The term GMPLS is used in this document to refer to
packet MPLS-TE, as well as GMPLS extensions to MPLS-TE.
LSP - An MPLS Label Switched Path LSP: An MPLS-TE/ GMPLS-TE Label Switched Path.
Head-end or Ingress node: In this document the terms "head-end Head-end node: Ingress LSR that initiated signaling for the Path.
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 (PCE) that
computes the routes on behalf of its clients (PCC).
GMPLS - The term GMPLS is used in this document to refer to both Border node: Ingress LSR of an LSP segment (S-LSP).
classic MPLS, as well as the GMPLS extensions to MPLS.
TE Link - The term TE link refers to a physical link or an FA- Path Computation Element (PCE): An entity that computes the
LSP, on which traffic engineering is enabled. A TE link can be routes on behalf of its clients (PCC).
bundled or unbundled.
The terms node and LSR will be used interchangeably in this TE Link: The term TE link refers to single or a bundle of
document. physical link(s) or FA-LSP(s) on which traffic engineering is
enabled [RFC4206], [RFC4201].
2. Introduction 2. Introduction
When outages in a network are planned (e.g. for maintenance When outages in a network are planned (e.g. for maintenance
purpose), some mechanisms can be used to avoid traffic purpose), some mechanisms can be used to avoid traffic
disruption. This is in contrast with unplanned network element disruption. This is in contrast with unplanned network element
failure, where traffic disruption can be minimized thanks to failure, where traffic disruption can be minimized thanks to
recovery mechanisms but may not be avoided. Hence, a Service recovery mechanisms but may not be avoided. Hence, a Service
Provider may desire to gracefully (temporarily or definitely) Provider may desire to gracefully (temporarily or definitely)
disable Traffic Engineering on a TE Link, a group of TE Links or remove a TE Link, a group of TE Links or an entire node for
an entire node for administrative reasons such as link administrative reasons such as link maintenance,
maintenance, software/hardware upgrade at a node or significant software/hardware upgrade at a node or significant TE
TE configuration changes. In all these cases, the goal is to configuration changes. In all these cases, the goal is to
minimize the impact on the GMPLS traffic engineered flows carried minimize the impact on the GMPLS traffic engineered flows carried
over TE LSPs in the network by triggering notifications so as to over TE LSPs in the network by triggering notifications so as to
graceful reroute such flows before the administrative procedures gracefully reroute such flows before the administrative
are started. procedures are started.
Graceful shutdown of a resource may require several steps. These Graceful shutdown of a resource may require several steps. These
steps can be broadly divided into two sets: disabling the steps can be broadly divided into two sets: disabling the
resource in the control plane and removing the resource for resource in the control plane and removing the resource for
forwarding. The node initiating the graceful shutdown condition forwarding. The node initiating the graceful shutdown condition
SHOULD delay the removal of the resources for forwarding, for SHOULD introduce a delay between disabling the resource in the
some period determined by local policy. This is to allow control control plane and removing the resource for forwarding. This is
plane to gracefully divert the traffic away from the resource to allow the control plane to gracefully divert the traffic away
being gracefully shutdown. Similarly, trigger for the graceful from the resource being gracefully shutdown. The trigger for the
shutdown event is a local matter at the node initiating the graceful shutdown event is a local matter at the node initiating
graceful shutdown. Typically, graceful shutdown is triggered for the graceful shutdown. Typically, graceful shutdown is triggered
administrative reasons, such as link maintenance or for administrative reasons, such as link maintenance or
software/hardware upgrade at a node. software/hardware upgrade.
draft-ietf-ccamp-mpls-graceful-shutdown-04.txt July 07
This document describes the mechanisms that can be used to This document describes the mechanisms that can be used to
gracefully shutdown GMPLS Traffic Engineering on a resource. As gracefully shutdown GMPLS Traffic Engineering on a resource. As
mentioned earlier, the graceful shutdown of the Traffic mentioned earlier, the graceful shutdown of the Traffic
draft-ietf-ccamp-mpls-graceful-shutdown-03.txt June 07
Engineering capability on a resource could be incorporated in the Engineering capability on a resource could be incorporated in the
traditional shutdown operation of an interface, but it is a shutdown operation of an interface, but it is a separate step
separate step that is taken before the IGP on the link is brought that is taken before the IGP on the link is brought down and
down and before the interface is brought down at different before the interface is brought down at different layers. This
layers. This document only addresses TE node and TE resources. 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 must address graceful removal of one TE link,
one component link within a bundled TE link, a set of TE links, a one component link within a bundled TE link, a set of TE links, a
set of component links or an entire node. set of component links or an entire node.
- It is required to prevent other network nodes to use the - Once an operator has initiated graceful shutdown of a network
network resources that are about to be shutdown, should new TE resource, no new TE LSPs may be set up that use the resource.
LSP be set up. However, if the resource being shutdown is a last Any signaling message for a new LSP that explicitly specifies the
resort, it can be used. Time or decision for removal of the resource, or that would require the use of the resource due to
resource being shutdown is based on a local decision at the node local constraints, must be rejected as if the resource were
initiating the graceful shutdown procedure. unavailable.
- It is required to reduce/eliminate traffic disruption on the - It is desirable for new LSP setup attempts that would be
LSP(s) using the network resources which are about to 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 shutdown is a last resort, it can be
used. Time or decision for removal of the resource being shutdown
is based on a local decision at the node initiating the graceful
shutdown procedure.
- It is required to give the ingress node the opportunity to take
actions in order to reduce/eliminate traffic disruption on the
LSP(s) that are using the network resources which are about to be
shutdown. shutdown.
- 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 [INTER- defined as either an IGP area or an Autonomous System [RFC4726].
AREA-AS].
- 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 to - In order to make rerouting effective, it is required that when
communicate information about the TE resource under graceful a node initiates the graceful shutdown of a resource, it
shutdown. draft-ietf-ccamp-mpls-graceful-shutdown-04.txt July 07
identifies to all other network nodes the TE resource under
graceful shutdown.
- Depending on switching technology, it may be possible to
shutdown a label resource, e.g., shutting down a lambda in a
Lambda Switch Capable (LSC) node.
4. Mechanisms for Graceful Shutdown 4. Mechanisms for Graceful Shutdown
An IGP only based solution is not applicable when dealing with An IGP only based solution is not applicable when dealing with
Inter-area and Inter-AS traffic engineering, as IGP LSA/LSP Inter-area and Inter-AS traffic engineering, as IGP LSA/LSP
flooding is restricted to IGP areas/levels. Consequently, RSVP flooding is restricted to IGP areas/levels. Consequently, RSVP
based mechanisms are required to cope with TE LSPs spanning based mechanisms are required to cope with TE LSPs spanning
multiple domains. At the same time, RSVP mechanisms only convey multiple domains. At the same time, RSVP mechanisms only convey
the information for the transiting LSPs to the router along the 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 it must be noted that graceful shutdown notification via IGP
flooding is required to discourage a node from establishing new flooding is required to discourage a node from establishing new
LSPs through the resources being shutdown. In the following LSPs through the resources being shutdown. In the following
draft-ietf-ccamp-mpls-graceful-shutdown-03.txt June 07
sections the complementary mechanisms for RSVP-TE and IGP for sections the complementary mechanisms for RSVP-TE and IGP for
Graceful Shutdown are described. Graceful Shutdown are described.
4.1 RSVP-TE Signaling Mechanism for graceful shutdown A node where a link or the whole node is being shutdown SHOULD
first trigger the IGP updates as described in Section 4.1,
introduce a delay to allow network convergence and only then use
the signaling mechanism described in Section 4.2.
4.1 OSPF/ ISIS Mechanisms for graceful shutdown
The procedures provided in this section are equally applicable to
OSPF and ISIS.
4.1.1 Graceful Shutdown of TE link(s)
The node where graceful-shutdown of a link is desired MUST
originate the TE LSA/LSP containing Link TLV for the link under
graceful shutdown with Traffic Engineering metric set to
0xffffffff, 0 as unreserved bandwidth, and if the link has LSC or
FSC as its Switching Capability then also with 0 as Max LSP
Bandwidth. A node MAY also specify a value for Minimum LSP
bandwidth which is greater than the available bandwidth. This
would discourage new 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-04.txt July 07
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 bandwidth change event, a new LSA is
originated with the new traffic parameters. If the last component
link is being shutdown, the routing procedure outlined in Section
4.2.1 is used.
4.1.3 Graceful Shutdown of TE Node
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.1.4 Graceful Shutdown of Label Resource
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 Path Error and mechanism outlined in the following section, uses PathErr and
where available, Notify message, in order to achieve this where available, Notify message, in order to achieve this
requirement. Such mechanisms relying on signaling are only requirement. These mechanisms apply to both existing and new
applicable to the existing LSPs. LSPs.
Setup request for new LSPs over the TE resource being gracefully
shutdown SHOULD be rejected using the existing mechanisms that
are applied when the TE resource is not available.
4.1.1 Graceful Shutdown of TE link(s) 4.2.1 Graceful Shutdown of TE link(s)
The node where graceful shutdown of a link or a set of links is The node where graceful shutdown of a link or a set of links is
desired MUST trigger a Path Error message with "local link desired MUST trigger a PathErr message with the error code
maintenance required" sub-code for all affected LSPs. The "local "Notify" and an error value of "Local link maintenance required"
TE link maintenance required" error code is defined in [PATH- for all affected LSPs. The "Notify" error code is defined in
REOPT]. If available, and where notify requests were included [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 when the LSPs were initially setup, Notify message (as defined in
RFC 3471, RFC 3473) MAY also be used for delivery of this RFC 3471, RFC 3473) MAY also be used for delivery of this
information to the head-end nodes. information to the head-end node, border node or PCE.
When a GS operation is performed along the path of a protected draft-ietf-ccamp-mpls-graceful-shutdown-04.txt July 07
LSP, based on a local decision, the PLR or branch node MAY
redirect the traffic onto the local detour or protecting segment.
In any case, the PLR or branch node MUST forward the Path Error
to the head-end LSR.
When a head-end LSR receives a Path Error (or Notify) message When a graceful shutdown operation is performed along the path of
with sub-code "Local Maintenance on TE Link required Flag", it a protected LSP, based on a local decision, the PLR or branch
SHOULD immediately trigger a make-before-break procedure. A head- node MAY redirect the traffic onto the local detour or protecting
end node SHOULD avoid the IP address contained in the PathErr (or segment. In all cases, the PLR or branch node MUST forward the
Notify message) when performing path computation for the new LSP. PathErr to the head-end node, border node, or PCE.
If the resource being gracefully shutdown is on the Path of the When a head-end node, border node, or PCE receives a PathErr (or
protecting LSP/ local detour, the branch node/ PLR reroutes the Notify) message with error value of " Local link maintenance
protecting LSP/ local detour just a head-end LSR would reroute required", it MAY trigger a make-before-break procedure. When
any other LSP. 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.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link
MPLS TE Link Bundling [BUNDLE] 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 component link(s). Hence, when a component link is
shutdown, the TE LSPs affected by such maintenance action needs shutdown, the TE LSPs affected by this action need to be
to be resignaled. resignaled.
draft-ietf-ccamp-mpls-graceful-shutdown-03.txt June 07
Graceful shutdown of a component link in a bundled TE link Graceful shutdown of a component link in a bundled TE link
differs from graceful shutdown of unbundled TE link or entire differs from graceful shutdown of unbundled TE link or entire
bundled TE link. Specifically, in the former case, when only a bundled TE link. Specifically, in the former case, when only a
subset of component links and not the entire TE bundled link is subset of component links and not the entire TE bundled link is
being shutdown, the remaining component links of the TE links may being shutdown, the remaining component links of the bundled TE
still be able to admit new LSPs. Consequently a new error sub- link may still be able to admit new LSPs.
code for the RSVP error-code "Routing Problem" (24) [RSVP-TE] is The node where graceful shutdown of a component link is desired
needed: MUST trigger a PathErr message with the error code "Notify" and
the new error value of "Local component link maintenance
required" for all affected LSPs. The "Notify" error code is
defined in [RFC3209] while the "local component link maintenance
required" error value is introduced by this proposal:
9 (TBA) Local component link maintenance required 12 (TBA) Local component link maintenance required
Error Sub-code for "Local component link maintenance required" is Error value for "Local component link maintenance required" is to
to be assigned by IANA. 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 If the last component link is being shutdown, the procedure
outlined in Section 5.1 is used. outlined in Section 4.2.1 is used.
When a head-end LSR receives an RSVP Path Error or Notify message
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 LSR MAY still use the IP address
contained in the Path Error or Notify message in performing path
computation for rerouting the LSP. This is because, 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 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 Path Error or Notify message SHOULD be avoided.
Based on a local decision, PLR/ branch node MAY trigger FRR/
segment recovery to recover from failure of a component link.
4.1.3 Graceful Shutdown of TE Node
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 OSPF/ ISIS Mechanisms for graceful shutdown When a head-end node, border node, or PCE receives an RSVP
PathErr or Notify message with error value "local component link
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
draft-ietf-ccamp-mpls-graceful-shutdown-04.txt July 07
The procedures provided in this section are equally applicable to link may still have capacity to admit new LSPs. However, if the
OSPF and ISIS. ERO is computed such that it also provides details of the
component link selection(s) along the Path, the component link
previously selected MAY be avoided.
4.2.1 Graceful Shutdown of TE link(s) 4.2.3 Graceful Shutdown of TE Node
The node where graceful-shutdown of a link is desired MUST The node that is being gracefully shutdown MUST trigger a PathErr
originate the TE LSA/LSP containing Link TLV for the link under message with the error code "Notify" and an error value of "Local
graceful shutdown with Traffic Engineering metric set to node maintenance required" for all LSPs. The "Notify" error code
0xffffffff, 0 as unreserved bandwidth, and if the link has LSC or is defined in [RFC3209] while the "local node maintenance
FSC as its Switching Capability then also with 0 as Max LSP required" error value is defined in [RFC4736].
draft-ietf-ccamp-mpls-graceful-shutdown-03.txt June 07 The PathErr message should include in the ERROR_SPEC object the
MPLS-TE Node ID address
Bandwidth. This would discourage new LSP establishment through 4.2.2 Graceful Shutdown of a Label Resource
the link under graceful shutdown.
Neighbors of the node where graceful shutdown procedure is in The node where graceful shutdown of a label resource is desired
progress SHOULD continue to advertise the actual unreserved MUST trigger a PathErr message with the error code "Notify" and
bandwidth of the TE links from the neighbors to that node, the new error value of "Local component link maintenance
without any routing adjacency change. required" for the affected LSP. The "Notify" error code is
defined in [RFC3209] while the "local component link maintenance
required" error value is introduced by this proposal:
4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 13 (TBA) Local label resource maintenance required
If graceful shutdown procedure is performed for a component link Error value for "Local label resource maintenance required" is to
within a TE Link bundle and it is not the last component link be assigned by IANA.
available within the TE link, the link attributes associated with The PathErr message should include in the ERROR_SPEC the TE Link
the TE link are recomputed. If the removal of the component link ID address.
results in a 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 outlined in Section
4.2.1 is used.
4.2.3 Graceful Shutdown of TE Node If the last component link is being shutdown, the procedure
outlined in Section 4.2.1 is used.
When graceful shutdown at node level is desired, the node in When a head-end node, border node, or PCE receives an RSVP
question follows the procedure specified in the previous section PathErr or Notify message with error value "local label resource
for all TE Links. 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 does not introduce new security issues. The This document introduces no new security considerations beyond
security considerations pertaining to the original RSVP protocol those already addressed for existing RSVP PathErr or Notify
[RSVP] remain relevant. messages, or advertisement of TE LSA/LSP containing Link TLV. In
this regard, the security considerations specified in [RFC2205],
[RFC3209] and [MPLS-GMPLS-SECURITY] remain relevant.
6. IANA Considerations draft-ietf-ccamp-mpls-graceful-shutdown-04.txt July 07
A new error sub-code for Path Error and Notify message is needed 6. IANA Considerations
for "Local component link maintenance required" flag. The following assignment is required in the "Notify" subsection
of "Error Codes and Values" section of the "RSVP PARAMETERS"
registry (located at http://www.iana.org/assignments/rsvp-
parameters):
12 (TBA) - "Local component link maintenance required" flag.
13 (TBA) Local label resource maintenance required.
7. Acknowledgments 7. Acknowledgments
The authors would like to acknowledge useful comments from David The authors would like to thank Adrian Farrel for his detailed
Ward, Sami Boutros, Adrian Farrel and Dimitri Papadimitriou. comments and suggestions. The authors would also like to
acknowledge useful comments from David Ward, Sami Boutros, and
Dimitri Papadimitriou.
8. Reference 8. Reference
8.1 Normative Reference 8.1 Normative Reference
[RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001. RFC 3209, December 2001.
[PATH-REOPT] Jean-Philippe Vasseur, et al "Reoptimization of MPLS [RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS
draft-ietf-ccamp-mpls-graceful-shutdown-03.txt June 07 Traffic Engineering loosely routed LSP paths", RFC 4736.
8.2 Informative Reference 8.2 Informative Reference
[RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - [RFC2205] Braden, et al, "Resource ReSerVation Protocol (RSVP)
Version 1, Functional Specification", RFC 2205, December 1997. Version 1, Functional Specification", RFC 2205, December 1997.
[INTER-AREA-AS] Adrian Farrel, Jean-Philippe Vasseur, Arthi [RFC4726] Adrian Farrel, Jean-Philippe Vasseur, Arthi Ayyangar,
Ayyangar, "A Framework for Inter-Domain MPLS Traffic "A Framework for Inter-Domain MPLS Traffic Engineering", RFC
Engineering", RFC 4726. 4726.
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling
MPLS Traffic Engineering", RFC 4201. in MPLS Traffic Engineering", RFC 4201.
[RFC4206] Label Switched Paths (LSP) Hierarchy with Generalized
Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE),
RFC 4206.
[MPLS-GMPLS-SECURITY] Fang, et al, "Security Framework for MPLS
and GMPLS Networks", draft-fang-mpls-gmpls-security-framework-
00.txt, work in progress.
draft-ietf-ccamp-mpls-graceful-shutdown-04.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 9, line 5 skipping to change at page 10, line 45
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79. rights in RFC documents can be found in BCP 78 and BCP 79.
draft-ietf-ccamp-mpls-graceful-shutdown-03.txt June 07
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the attempt made to obtain a general license or permission for the
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-04.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.
 End of changes. 63 change blocks. 
191 lines changed or deleted 281 lines changed or added

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