draft-ietf-ccamp-mpls-graceful-shutdown-08.txt   draft-ietf-ccamp-mpls-graceful-shutdown-09.txt 
Network Working Group Z. Ali
Internet Draft JP. Vasseur CCAMP Working Group
Category: Informational A. Zamfir Internet Draft
Creater: October 29, 2008 Cisco Systems, Inc. Zafar Ali
Expires: April 29, 2009 J. Newton Jean-Philippe Vasseur
Anca Zamfir
Cisco Systems, Inc.
Jonathan Newton
Cable and Wireless Cable and Wireless
Category: Informational
Expires: September 08, 2009 March 09, 2009
draft-ietf-ccamp-mpls-graceful-shutdown-09.txt
Graceful Shutdown in MPLS and Generalized MPLS Graceful Shutdown in MPLS and Generalized MPLS
Traffic Engineering Networks Traffic Engineering Networks
draft-ietf-ccamp-mpls-graceful-shutdown-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with
any applicable patent or other IPR claims of which he or she is the provisions of BCP 78 and BCP 79. This document may contain
aware have been or will be disclosed, and any of which he or she material from IETF Documents or IETF Contributions published or
becomes aware will be disclosed, in accordance with Section 6 of made publicly available before November 10, 2008. The person(s)
BCP 79. controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining
an adequate license from the person(s) controlling the copyright
in such materials, this document may not be modified outside the
IETF Standards Process, and derivative works of it may not be
created outside the IETF Standards Process, except to format it
for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
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 September 08, 2009.
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.
skipping to change at page 2, line 11 skipping to change at page 2, line 26
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.
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction....................................................2
2. Terminology.....................................................3 2. Terminology.....................................................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 OSPF/ ISIS Mechanisms for graceful shutdown..................5 4.1 OSPF/ ISIS Mechanisms for graceful shutdown....................5
4.2 RSVP-TE Signaling Mechanisms for graceful shutdown...........6 4.2 RSVP-TE Signaling Mechanisms for graceful shutdown............6
5. Security Considerations.........................................8 5. Security Considerations.........................................7
6. IANA Considerations.............................................8 6. IANA Considerations.............................................7
7. Acknowledgments.................................................8 7. Acknowledgments.................................................7
8. Reference.......................................................9 8. Reference.......................................................8
8.1 Normative Reference..........................................9 8.1 Normative Reference...........................................8
8.2 Informative Reference........................................9 8.2 Informative Reference.........................................8
9. Authors' Addresses.............................................10 9. Authors' Address:...............................................9
10. Intellectual Property Considerations..........................11 10. Copyright Notice..............................................10
11. Disclaimer of Validity........................................11 11. Legal.........................................................10
12. Copyright Statement...........................................11
1. Introduction 1. 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 indefinitely) Provider may desire to gracefully (temporarily or indefinitely)
remove a TE Link, a group of TE Links or an entire node for remove a TE Link, a group of TE Links or an entire node for
administrative reasons such as link maintenance, administrative reasons such as link maintenance,
software/hardware upgrade at a node or significant TE software/hardware upgrade at a node or significant 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 traffic carried over TE LSPs in the minimize the impact on the traffic carried over TE LSPs in the
network by triggering notifications so as to gracefully reroute network by triggering notifications so as to gracefully reroute
such flows before the administrative procedures are started. such flows before the administrative procedures are started.
These operations are equally applicable to both MPLS and its
Generalized MPLS (GMPLS) extensions. These operations are equally applicable to both MPLS [RFC3209]
and its Generalized MPLS (GMPLS) extensions [RFC3471], [RFC3473].
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
is expected to introduce a delay between disabling the resource is expected to introduce a delay between disabling the resource
in the control plane and removing the resource for forwarding. in the control plane and removing the resource for forwarding.
This is to allow the control plane to gracefully divert the This is to allow the control plane to gracefully divert the
traffic away from the resource being gracefully shutdown. The traffic away from the resource being gracefully shutdown. The
trigger for the graceful shutdown event is a local matter at the trigger for the graceful shutdown event is a local matter at the
node initiating the graceful shutdown. Typically, graceful node initiating the graceful shutdown. Typically, graceful
shutdown is triggered for administrative reasons, such as link shutdown is triggered for administrative reasons, such as link
maintenance or software/hardware upgrade. maintenance or software/hardware upgrade.
This document describes the mechanisms that can be used to This document describes the mechanisms that can be used to
gracefully shutdown MPLS/ GMPLS Traffic Engineering on a gracefully shutdown MPLS/ GMPLS Traffic Engineering on a resource
resource. As mentioned earlier, the graceful shutdown of the such as a TE link, a component link within a bundled TE link, a
Traffic Engineering capability on a resource could be label resource or an entire TE node.
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 2. Terminology
Border node: Ingress LSR of an LSP segment (S-LSP). LSR - Label Switching Router. The terms node and LSR are used
interchangeably in this document.
GMPLS: The term GMPLS is used in this document to refer to 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.
Head-end node: Ingress LSR that initiated signaling for the Path. LSP - An MPLS-TE/ GMPLS-TE Label Switched Path.
Last resort resource: If a path to a destination from a given
head-end node cannot be found upon removal of a resource (e.g.,
TE link, TE node), the resource is called last resort to reach
that destination from the given head-end node.
LSP: An MPLS-TE/ GMPLS-TE Label Switched Path. Head-end node: Ingress LSR that initiated signaling for the Path.
LSR: Label Switching Router. The terms node and LSR are used Border node: Ingress LSR of an LSP segment (S-LSP).
interchangeably in this document.
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].
Last resort resource: If a path to a destination from a given
head-end node cannot be found upon removal of a resource (e.g.,
TE link, TE node), the resource is called last resort to reach
that destination from the given head-end node.
3. Requirements for Graceful Shutdown 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 is required to address graceful removal of - Graceful shutdown is required to address graceful removal of
one TE link, one component link within a bundled TE link, a set one TE link, one component link within a bundled TE link, a set
of TE links, a set of component links, label resource(s) or an of TE links, a set of component links, label resource(s) or an
entire node. entire node.
skipping to change at page 6, line 11 skipping to change at page 6, line 11
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.2 RSVP-TE Signaling Mechanisms for graceful shutdown 4.2 RSVP-TE Signaling Mechanisms 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. For this purpose the about the resource under graceful shutdown. For this purpose the
Graceful Shutdown uses LSP rerouting mechanism as defined in Graceful Shutdown uses LSP rerouting mechanism as defined in
[LSP-REROUTE]. Specifically, the node where graceful shutdown of [LSP-REROUTE].
an unbundled TE link or an entire bundled TE link is desired
triggers a PathErr message with the error code "Reroute" and an Specifically, the node where graceful shutdown of an unbundled TE
error value of "TE link Graceful Shutdown required" for all link or an entire bundled TE link is desired triggers a PathErr
affected LSPs. Similarly, the node that is being gracefully message with the error codes and error values of "Notify/Local
shutdown triggers a PathErr message with the error code "Reroute" link maintenance required", for all affected LSPs. Similarly, the
and an error value of "Node Graceful Shutdown required" for all node that is being gracefully shutdown triggers a PathErr message
LSPs. with the error codes and error values of "Notify/ Local node
maintenance required", for all LSPs. For graceful shutdown of a
node, an unbundled TE link or an entire bundled TE link, the
PathErr message may contain either an [RFC2205] format ERROR_SPEC
object, or an IF_ID [RFC3473] format ERROR_SPEC object. In either
case, it is the address and TLVs carried by the ERROR_SPEC object
and not the error value that indicates the resource that is to be
gracefully shutdown.
MPLS TE Link Bundling [RFC4201] requires that an LSP is pinned MPLS TE Link Bundling [RFC4201] requires that an LSP is pinned
down to a component link. Consequently, graceful shutdown of a down to a component link. Consequently, graceful shutdown of a
component link in a bundled TE link differs from graceful component link in a bundled TE link differs from graceful
shutdown of unbundled TE link or entire bundled TE link. shutdown of unbundled TE link or entire bundled TE link.
Specifically, in the former case, when only a subset of component Specifically, in the former case, when only a subset of component
links and not the entire TE bundled link is being shutdown, the links and not the entire TE bundled link is being shutdown, the
remaining component links of the bundled TE link may still be remaining component links of the bundled TE link may still be
able to admit new LSPs. The node where graceful shutdown of a able to admit new LSPs. The node where graceful shutdown of a
component link is desired triggers a PathErr message with the component link is desired triggers a PathErr message with the
error code "Reroute" and the new error value of "Component link error codes and error values of "Notify/Local link maintenance
Graceful Shutdown required" for all affected LSPs. The PathErr required". The rest of the ERROR_SPEC object is constructed using
message includes in the ERROR_SPEC the TE Link ID address. If the Component Reroute Request procedure defined in [LSP-REROUTE].
last component link is being shutdown, procedure for gracefully
shutdown entire bundled TE link outlined above is be used,
instead.
If graceful shutdown of a label resource is desired, the node If graceful shutdown of a label resource is desired, the node
initiating this action triggers a PathErr message with the error initiating this action triggers a PathErr message with the error
code "Reroute" and the new error value of "Label resource codes and error values of "Notify/Local link maintenance
Graceful Shutdown required" for the affected LSP. The PathErr required". The rest of the ERROR_SPEC object is constructed using
message includes in the ERROR_SPEC the TE Link ID address. Label Reroute Request procedure defined in [LSP-REROUTE].
The "Reroute" error code for the ERROR SPEC object is defined in
[LSP-REROUTE]. This document defines following four error value
for the "Reroute" error code [To Be Confirmed (TBC) by IANA upon
publication of this document]:
Error-value Meaning Reference
2 (TBC) Node Graceful Shutdown required This doc
3 (TBC) TE link Graceful Shutdown required This doc
4 (TBC) Component link Graceful Shutdown required This doc
5 (TBC) Label resource Graceful Shutdown required This doc
The PathErr message includes in the ERROR_SPEC the TE Link ID
address.
If unbundled TE link, component link of a bundled TE link, entire
bundled TE link, or label resource of a TE link is being
gracefully shutdown, the PathErr message includes the ERROR_SPEC
object containing IP address of the TE Link being gracefully
shutdown. If TE link is unnumbered, the PathErr message includes
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.
When a head-end node, or border node receives a PathErr message When a head-end node, or a transit node (including border node)
with "Reroute" error code and error value of "Node Graceful receives a PathErr message with error codes and error values of
Shutdown required" or "TE link Graceful Shutdown required", or "Notify/Local link maintenance required" or "Notify/ Local node
"Component link Graceful Shutdown required", or "Label resource maintenance required", it follows the make-before-break procedure
Graceful Shutdown required" it follows the procedures defined in defined in [LSP-REROUTE] to reroute the traffic around the
[LSP-REROUTE]. When performing path computation for the new LSP, resource being gracefully shutdown. When performing path
the head-end node, or border node avoids using the TE resources computation for the new LSP, the head-end node, or border node
identified by the IP address contained in the PathErr. If PCE is avoids using the TE resources identified by the ERROR_SPEC
used for path computation, head-end node or border node acts as object. If PCE is used for path computation, head-end node or
PCC to request the PCE via PCEP for path computation avoiding border node acts as PCC to request the PCE via PCEP for path
resource being gracefully shutdown. The amount of time the head- computation avoiding resource being gracefully shutdown. The
end node, or border node avoid using the TE resources identified amount of time the head-end node, or border node avoid using the
by the IP address contained in the PathErr is based on a local TE resources identified by the IP address contained in the
decision at head-end node or border node. PathErr is based on a local decision at head-end node or border
node.
If node initiating the graceful shutdown procedure received path If node initiating the graceful shutdown procedure received path
setup request for a new tunnel using resource being gracefully setup request for a new tunnel using resource being gracefully
shutdown, it sends a Path Error message with "Reroute" error code shutdown, it sends a Path Error message with "Notify" error code
in the ERROR SPEC object and an error value consistent with the in the ERROR SPEC object and an error value consistent with the
type of resource being gracefully shutdown. However, based on a type of resource being gracefully shutdown. However, based on a
local decision, if node initiating the graceful shutdown local decision, if an existing tunnel continues to use the
procedure received path setup request for an existing tunnel, it resource being gracefully shutdown, the node initiating the
may allow signaling for it. This is to allow resource being graceful shutdown procedure may allow resource being gracefully
gracefully shutdown as a "last resort". The node initiating the shutdown to be used as a "last resort". The node initiating the
graceful shutdown procedure can distinguish between new and graceful shutdown procedure can distinguish between new and
existing tunnels based on the tunnel ID in the SESSION object. existing tunnels based on the tunnel ID in the SESSION object.
Time or decision for removal of the resource being shutdown from Time or decision for removal of the resource being shutdown from
forwarding is based on a local decision at the node initiating forwarding is based on a local decision at the node initiating
the graceful shutdown procedure. the graceful shutdown procedure. For this purpose, the node
initiating graceful shutdown procedure follows the Reroute
Request Timeout procedure defined in [LSP-REROUTE].
5. Security Considerations 5. Security Considerations
This document introduces two new error values for "Reroute" error This document introduces no new security considerations as this
code of the ERROR SPEC object defined in [LSP-REROUTE]. This document describes usage of existing formats and mechanisms. This
document also introduces ways to make resources unavailable for document relies on existing procedures for advertisement of TE
the control plane. It is therefore recommended that procedures in LSA/LSP containing Link TLV. Tampering with TE LSAs may have an
[RFC2747], which provides mechanisms to protect against external effect on traffic engineering computations, and it is suggested
agents compromising the RSVP signaling state in an RSVP agent, be that any mechanisms used for securing the transmission of normal
used. Specifically, [RFC2747] mechanisms provide some degree of OSPF LSAs/ ISIS LSPs be applied equally to all Opaque LSAs/ LSPs
protection to the head-end node or border node RSVP agent against this document uses. Existing security considerations specified
making resources unavailable for control plan from an external in [RFC3630], [RFC5305], [RFC4203], [RFC5307] and [MPLS-GMPLS-
agent sending Path Error messages with existing or new error code SECURITY] remain relevant and suffice. Furthermore, security
and error values. In summary, existing security considerations considerations section in [LSP-REROUTE] and the Section 9 of
specified in [LSP-REROUTE], [RFC2747], [RFC2205], [RFC3209], [RFC4736] should be used for understanding the security
[RFC4736], [RFC3471], [RFC3473] and [MPLS-GMPLS-SECURITY] remain considerations related to the formats and mechanisms used in this
relevant and suffice. document.
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], [RFC5305], [RFC4203],
[RFC5307] and [MPLS-GMPLS-SECURITY] remain relevant and suffice.
6. IANA Considerations 6. IANA Considerations
The "Reroute" error code for the ERROR SPEC object is defined in This document has no IANA actions.
[LSP-REROUTE]. This document defines following four error value
for the "Reroute" error code [To Be Confirmed (TBC) by IANA upon
publication of this document]:
Error-value Meaning Reference
2 (TBC) Node Graceful Shutdown required This doc
3 (TBC) TE link Graceful Shutdown required This doc
4 (TBC) Component link Graceful Shutdown required This doc
5 (TBC) Label resource Graceful Shutdown required This doc
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
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
[RFC3209] Awduche D., Berger, L., Gan, D., Li T., Srinivasan, V., [RFC2205] Braden, R. Ed. et al, "Resource ReSerVation Protocol
Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", (RSVP) Version 1, Functional Specification", RFC 2205.
RFC 3209, December 2001.
[RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS
Traffic Engineering loosely routed LSP paths", RFC 4736,
November 2006.
[LSP-REROUTE] Berger, L., Papadimitriou, D., and J. Vasseur, [LSP-REROUTE] Berger, L., Papadimitriou, D., and J. Vasseur,
"PathErr Message Triggered MPLS and GMPLS LSP Reroute", "PathErr Message Triggered MPLS and GMPLS LSP Reroute", draft-
draft-ietf-mpls-gmpls-lsp-reroute, work in progress. ietf-mpls-gmpls-lsp-reroute (work in progress).
8.2 Informative Reference 8.2 Informative Reference
[RFC2205] Braden, R. Ed. et al, "Resource ReSerVation Protocol (RSVP) [RFC3209] Awduche D., Berger, L., Gan, D., Li T., Srinivasan, V.,
Version 1, Functional Specification", RFC 2205, December Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
1997. 3209.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC4736] Jean-Philippe Vasseur, et al "Reoptimization of MPLS
Authentication", RFC 2747, January 2000. Traffic Engineering loosely routed LSP paths", RFC 4736.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3630] Katz D., Kompella K., Yeung D., "Traffic Engineering
(GMPLS) Signaling Functional Description", RFC 3471, (TE) Extensions to OSPF Version 2", RFC 3630.
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC5305] Smit, H. and T. Li, "Intermediate System to
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Intermediate System (IS-IS) Extensions for Traffic Engineering
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. (TE)", RFC 5305.
[RFC3630] Katz D., Kompella K., Yeung D., "Traffic Engineering [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
(TE) Extensions to OSPF Version 2", RFC 3630, September Extensions in Support of Generalized Multi-Protocol Label
2003. Switching (GMPLS)", RFC 4203.
[RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
MPLS Traffic Engineering", RFC 4201, October 2005. System to Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in [RFC3471] Berger, L., "Generalized Multi-Protocol Label
Support of Generalized Multi-Protocol Label Switching Switching (GMPLS) Signaling Functional Description", RFC 3471.
(GMPLS)", RFC 4203, October 2005.
[RFC4206] Kompella K., Rekhter Y., "Label Switched Paths (LSP) [RFC3473] Berger, L., "Generalized Multi-Protocol Label
Hierarchy with Generalized Multi-Protocol Label Switching Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. Engineering (RSVP-TE) Extensions", RFC 3473.
[RFC4726] Farrel A, Vasseur, J.-P., Ayyangar A., "A Framework for [RFC4726] Farrel A, Vasseur, J.-P., Ayyangar A., "A Framework for
Inter-Domain MPLS Traffic Engineering", RFC 4726, November Inter-Domain MPLS Traffic Engineering", RFC 4726, November 2006.
2006.
[RFC5305] Smit, H. and T. Li, "Intermediate System to Intermediate [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling
System (IS-IS) Extensions for Traffic Engineering (TE)", in MPLS Traffic Engineering", RFC 4201.
RFC 5305, October 2008.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate [RFC4206] Kompella K., Rekhter Y., "Label Switched Paths (LSP)
System to Intermediate System (IS-IS) Extensions in Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS)
Support of Generalized Multi-Protocol Label Switching Traffic Engineering (TE)", RFC 4206.
(GMPLS)", RFC 5307, October 2008.
[MPLS-GMPLS-SECURITY] Fang, L. et al, "Security Framework for MPLS [MPLS-GMPLS-SECURITY] Luyuan Fang, Ed. "Security Framework for
and GMPLS Networks", draft-fang-mpls-gmpls-security- MPLS and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-
framework, work in progress. security-framework, work in progress.
9. Authors' Addresses 9. Authors' Address:
Zafar Ali Zafar Ali
Cisco systems, Inc., Cisco systems, Inc.,
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada.
Email: zali@cisco.com Email: zali@cisco.com
Jean Philippe Vasseur Jean Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com Email: jpv@cisco.com
Anca Zamfir Anca Zamfir
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
Email: ancaz@cisco.com Email: ancaz@cisco.com
Jonathan Newton Jonathan Newton
Cable and Wireless Cable and Wireless
jonathan.newton@cw.com jonathan.newton@cw.com
10. Intellectual Property Considerations 10. Copyright Notice
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copyright (c) 2009 IETF Trust and the persons identified as the
assurances of licenses to be made available, or the result of an document authors. All rights reserved.
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention This document is subject to BCP 78 and the IETF Trust's Legal
any copyrights, patents or patent applications, or other Provisions Relating to IETF Documents in effect on the date of
proprietary rights that may cover technology that may be required publication of this document (http://trustee.ietf.org/license-info).
to implement this standard. Please address the information to Please review these documents carefully, as they describe your
the IETF at ietf-ipr@ietf.org. rights and restrictions with respect to this document.
11. Disclaimer of Validity 11. Legal
This document and the information contained herein are provided This documents and the information contained therein 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 THEREIN WILL NOT
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
FITNESS FOR A PARTICULAR PURPOSE. OR FITNESS FOR A PARTICULAR PURPOSE.
12. Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document may contain material from IETF Documents or IETF
contained in BCP 78, and except as set forth therein, the authors Contributions published or made publicly available before November
retain all their rights. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
 End of changes. 50 change blocks. 
224 lines changed or deleted 166 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/