draft-ietf-ccamp-mpls-graceful-shutdown-00.txt   draft-ietf-ccamp-mpls-graceful-shutdown-01.txt 
Networking Working Group Networking Working
Group
Zafar Ali Zafar Ali
Jean-Philippe Vasseur Jean-Philippe Vasseur
Anca Zamfir Anca Zamfir
Cisco Systems, Inc. Cisco Systems, Inc.
IETF Internet Draft IETF Internet Draft
Category: Informational Category: Informational
September 2006 Expires: April 2006 October 2006
draft-ietf-ccamp-mpls-graceful-shutdown-00.txt draft-ietf-ccamp-mpls-graceful-shutdown-01.txt
Graceful Shutdown in GMPLS Traffic Engineering Networks Graceful Shutdown in GMPLS Traffic Engineering Networks
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line 33 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Terminology........................................................2 1. Terminology........................................................2
2. Introduction.......................................................3 2. Introduction.......................................................3
3. Requirements for Graceful Shutdown.................................3 3. Requirements for Graceful Shutdown.................................3
4. Mechanisms for Graceful Shutdown...................................4 4. Mechanisms for Graceful Shutdown...................................4
4.1 RSVP-TE Signaling Mechanism for graceful shutdown...............4 4.1 RSVP-TE Signaling Mechanism for graceful shutdown...............4
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..................................5 4.1.3 Graceful Shutdown of TE Node..................................6
4.2 OSPF/ ISIS Mechanisms for graceful shutdown.....................6 4.2 OSPF/ ISIS Mechanisms for graceful shutdown.....................6
4.2.1 Graceful Shutdown of TE link(s)...............................6 4.2.1 Graceful Shutdown of TE link(s)...............................6
4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link...6 4.2.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link...6
4.2.3 Graceful Shutdown of TE Node..................................6 4.2.3 Graceful Shutdown of TE Node..................................6
5. Security Considerations............................................6 5. Security Considerations............................................7
6. IANA Considerations................................................6 6. IANA Considerations................................................7
7. Intellectual Property Considerations...............................7 7. Intellectual Property Considerations...............................7
8. Full Copyright Statement...........................................7 8. Full Copyright Statement...........................................7
9. Acknowledgments....................................................7 9. Acknowledgments....................................................7
10. Reference.........................................................7 10. Reference.........................................................8
10.1 Normative Reference............................................7 10.1 Normative Reference............................................8
10.2 Informative Reference..........................................8 10.2 Informative Reference..........................................8
1. Terminology 1. Terminology
LSR - Label Switching Device. LSR - Label Switching Device.
LSP - An MPLS Label Switched Path LSP - An MPLS Label Switched Path
Head-end or Ingress node: In this document the terms head-end node Head-end or Ingress node: In this document the terms ‘‘head-end node
equally applies to the Ingress node that initiated signaling for the equally applies to the Ingress node that initiated signaling for the
Path, or an intermediate node (in the case of loose hops path Path, or an intermediate node (in the case of loose hops path
computation) or a Path Computation Element (PCE) that computes the computation) or a Path Computation Element (PCE) that computes the
routes on behalf of its clients (PCC). routes on behalf of its clients (PCC).
GMPLS - The term GMPLS is used in this document to refer to both GMPLS - - The term GMPLS is used in this document to refer to both
classic MPLS, as well as the GMPLS extensions to MPLS. classic MPLS, as well as the GMPLS extensions to MPLS.
TE Link - The term TE link refers to a physical link or an FA-LSP, on TE Link - - The term TE link refers to a physical link or an FA-LSP, on
which traffic engineering is enabled. A TE link can be bundled or which traffic engineering is enabled. A TE link can be bundled or
unbundled. unbundled.
The terms node and LSR will be used interchangeably in this document. The terms node and LSR will be used interchangeably in this document.
2. Introduction 2. Introduction
When outages in a network are planned (e.g. for maintenance purpose), When outages in a network are planned (e.g. for maintenance purpose),
some mechanisms can be used to avoid traffic disruption. This is in some mechanisms can be used to avoid traffic disruption. This is in
contrast with unplanned network element failure, where traffic contrast with unplanned network element failure, where traffic
skipping to change at page 5, line 12 skipping to change at page 5, line 12
shutdown SHOULD be rejected using the existing mechanisms that are shutdown SHOULD be rejected using the existing mechanisms that are
applied when the TE resource is not available. applied when the TE resource is not available.
4.1.1 Graceful Shutdown of TE link(s) 4.1.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 Path Error message with ‘‘local link
maintenance required’’ sub-code for all affected LSPs. The ‘‘local TE maintenance required’’ sub-code for all affected LSPs. The ‘‘local TE
link maintenance required’’ error code is defined in [PATH-REOPT]. If link maintenance required’’ error code is defined in [PATH-REOPT]. If
available, and where notify requests were included when the LSPs were available, and where notify requests were included when the LSPs were
initially setup, Notify message (as defined in []) MAY also be used initially setup, Notify message (as defined in RFC 3471, RFC 3473)
for delivery of this information to the head-end nodes. MAY also be used for delivery of this information to the head-end
nodes. When a GS operation is performed along the path of a protected
LSP, the PLR or branch node SHOULD NOT redirect the traffic onto the
local detour or protecting segment. This is to make rerouting process
local to the headend node, without intervention of the recovery
process. Please recall that head-end node terminology in this
document equally applies to the Ingress node that initiated signaling
for the Path, or an intermediate node (in the case of loose hops path
computation). If the resource being gracefully shutdown is on the
Path of the protecting LSP/ local detour, the branch node/ PLR
reroutes the protecting LSP/ local detour just a head-end LSR would
reroute any other LSP.
When a head-end LSR receives a Path Error (or Notify) message with When a head-end LSR receives a Path Error (or Notify) message with
sub-code "Local Maintenance on TE Link required Flag", it SHOULD sub-code "Local Maintenance on TE Link required Flag", it SHOULD
immediately trigger a make-before-break procedure. A head-end node immediately trigger a make-before-break procedure. A head-end node
SHOULD avoid the IP address contained in the PathErr (or Notify SHOULD avoid the IP address contained in the PathErr (or Notify
message) when performing path computation for the new LSP. message) when performing path computation for the new LSP.
4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link 4.1.2 Graceful Shutdown of Component Link(s) in a Bundled TE Link
MPLS TE Link Bundling [BUNDLE] requires that an LSP is pinned down to MPLS TE Link Bundling [BUNDLE] requires that an LSP is pinned down to
skipping to change at page 7, line 26 skipping to change at page 7, line 37
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 use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
8. Full Copyright Statement 8. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9. Acknowledgments 9.
The authors would like to acknowledge useful comments from David Ward, The authors would like to acknowledge useful comments from David Ward,
Sami Boutros, Adrian Farrel and Dimitri Papadimitriou. Sami Boutros, Adrian Farrel and Dimitri Papadimitriou.
10. Reference 10. Reference
10.1 Normative Reference 10.1 Normative Reference
[RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version [RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP) - Version
1, Functional Specification", RFC 2205, September 1997. 1, Functional Specification", RFC 2205, September 1997.
skipping to change at page 8, line 43 skipping to change at page 9, line 5
Authors' Address: 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
Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Anca Zamfir Anca Zamfir
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
 End of changes. 14 change blocks. 
18 lines changed or deleted 28 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/