draft-ietf-mpls-gmpls-lsp-reroute-02.txt   draft-ietf-mpls-gmpls-lsp-reroute-03.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Updates: 3209 Dimitri Papadimitriou (Alcatel Lucent) Updates: 3209 Dimitri Papadimitriou (Alcatel Lucent)
Category: Standards Track JP. Vasseur (Cisco) Category: Standards Track JP. Vasseur (Cisco)
Expiration Date: March 19, 2009 Expiration Date: May 25, 2009
September 19, 2008 November 25, 2008
PathErr Message Triggered MPLS and GMPLS LSP Reroute PathErr Message Triggered MPLS and GMPLS LSP Reroute
draft-ietf-mpls-gmpls-lsp-reroute-02.txt draft-ietf-mpls-gmpls-lsp-reroute-03.txt
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.
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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work 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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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 March 19, 2009. This Internet-Draft will expire on May 25, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes how Resource ReserVation Protocol (RSVP) This document describes how Resource ReserVation Protocol (RSVP)
PathErr Messages may be used to trigger rerouting of Multi-Protocol PathErr Messages may be used to trigger rerouting of Multi-Protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point
Engineering (TE) Label Switched Paths (LSPs) without first removing Traffic Engineering (TE) Label Switched Paths (LSPs) without first
LSP state or resources. Such LSP rerouting may be desirable in a removing LSP state or resources. Such LSP rerouting may be desirable
number of cases including, for example, soft-preemption and graceful in a number of cases including, for example, soft-preemption and
shutdown. This document describes the usage of existing Standards graceful shutdown. This document describes the usage of existing
Track mechanisms to support LSP rerouting. In this case, it relies on Standards Track mechanisms to support LSP rerouting. In this case, it
mechanisms already defined as part of RSVP-TE and simply describes a relies on mechanisms already defined as part of RSVP-TE and simply
sequence of actions to be executed. While existing protocol describes a sequence of actions to be executed. While existing
definition can be used to support reroute applications, this document protocol definition can be used to support reroute applications, this
also defines a new reroute-specific error code to allow for the document also defines a new reroute-specific error code to allow for
future definition of reroute application-specific error values. the future definition of reroute application-specific error values.
Table of Contents Table of Contents
1 Introduction .............................................. 3 1 Introduction .............................................. 3
1.1 Conventions used in this document ......................... 4 1.1 Conventions used in this document ......................... 4
2 Reroute Requests .......................................... 4 2 Reroute Requests .......................................... 4
2.1 Processing at Requesting Node ............................. 4 2.1 Processing at Requesting Node ............................. 4
2.1.1 Reroute Request Timeouts .................................. 5 2.1.1 Reroute Request Timeouts .................................. 5
2.2 Processing at Upstream Node ............................... 5 2.2 Processing at Upstream Node ............................... 6
2.3 Processing at Ingress ..................................... 6 2.3 Processing at Ingress ..................................... 6
3 IANA Considerations ....................................... 6 3 Example Reroute Requests .................................. 7
4 Security Considerations ................................... 7 3.1 Node Reroute Request ...................................... 7
5 References ................................................ 7 3.2 Interface Reroute Request ................................. 7
5.1 Normative References ...................................... 7 3.3 Component Reroute Request ................................. 8
5.2 Informative References .................................... 8 3.4 Label Reroute Request ..................................... 9
6 Acknowledgments ........................................... 8 4 IANA Considerations ....................................... 9
7 Author's Addresses ........................................ 8 5 Security Considerations ................................... 10
8 Full Copyright Statement .................................. 9 6 References ................................................ 10
9 Intellectual Property ..................................... 9 6.1 Normative References ...................................... 10
6.2 Informative References .................................... 11
7 Acknowledgments ........................................... 12
8 Author's Addresses ........................................ 12
9 Full Copyright Statement .................................. 12
10 Intellectual Property ..................................... 13
1. Introduction 1. Introduction
Resource ReserVation Protocol (RSVP), see [RFC2205], has been Resource ReserVation Protocol (RSVP), see [RFC2205], has been
extended to support the control of Traffic Engineering (TE) Label extended to support the control of Traffic Engineering (TE) Label
Switched Paths (LSPs) for both Multi-Protocol Label Switching (MPLS) Switched Paths (LSPs) for both Multi-Protocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) in, respectively, [RFC3209] and and Generalized MPLS (GMPLS) in, respectively, [RFC3209] and
[RFC3473]. In all cases, a PathErr message is used to report errors [RFC3473]. In all cases, a PathErr message is used to report errors
to nodes upstream of the error detecting node. As defined in to nodes upstream of the error detecting node. As defined in
[RFC2205], and left unmodified by [RFC3209], PathErr messages "do not [RFC2205], and left unmodified by [RFC3209], PathErr messages "do not
skipping to change at page 3, line 37 skipping to change at page 3, line 37
PathErr messages can also be used to support a number of other cases PathErr messages can also be used to support a number of other cases
that can occur after an LSP is established. This document focuses on that can occur after an LSP is established. This document focuses on
the cases where PathErr messages can be used for a node to indicate the cases where PathErr messages can be used for a node to indicate
that it desires an upstream node to reroute an LSP around the that it desires an upstream node to reroute an LSP around the
indicating node or a resources associated with the indicating node. indicating node or a resources associated with the indicating node.
Some examples of such cases are soft-preemption and graceful Some examples of such cases are soft-preemption and graceful
shutdown. (See [PREEMPTION] and [GRACEFUL]). shutdown. (See [PREEMPTION] and [GRACEFUL]).
This document uses the terminology "reroute request" to refer to the This document uses the terminology "reroute request" to refer to the
indication by a node that an upstream reroute should take place. This indication by a node that an upstream reroute should take place. This
document how a node can initiate a reroute request without disrupting document describes how a node can initiate a reroute request without
LSP data traffic or, when so desired, with the disruption of data disrupting LSP data traffic or, when so desired, with the disruption
traffic and removal of LSP associated state and resources. of data traffic and removal of LSP associated state and resources.
The applicability of this document is limited to point-to-point LSPs.
Support for point-to-multipoint LSPs are for further study.
The mechanisms used to indicate reroute requests are derived from the The mechanisms used to indicate reroute requests are derived from the
mechanisms described in [RFC4920], and the error codes defined in mechanisms described in [RFC4920], and the error codes defined in
[RFC4736]. This document describes (1) how a non-disruptive reroute [RFC4736]. This document describes (1) how a non-disruptive reroute
request may be issued and, (2) based on an optional "timeout" period, request may be issued and, (2) based on an optional "timeout" period,
how rerouting may be forced by removing LSP state and associated how rerouting may be forced by removing LSP state and associated
resources and signaling such removal. While this document describes resources and signaling such removal. While this document describes
how existing protocol definitions can be used to support rerouting, how existing protocol definitions can be used to support rerouting,
it also defines a new reroute-specific error code to allow for the it also defines a new reroute-specific error code to allow for the
future definition of reroute application-specific error values. future definition of reroute application-specific error values.
skipping to change at page 4, line 34 skipping to change at page 4, line 34
the ERO received in the LSP's incoming Path message does not preclude the ERO received in the LSP's incoming Path message does not preclude
LSP re-routing. Examples of events that may trigger reroutes are LSP re-routing. Examples of events that may trigger reroutes are
avoiding an outgoing interface, a component, label resource, or a avoiding an outgoing interface, a component, label resource, or a
next hop not explicitly listed in the ERO. In all cases, the actual next hop not explicitly listed in the ERO. In all cases, the actual
repair action SHOULD be performed after verification that the local repair action SHOULD be performed after verification that the local
policy allows local repair for that LSP/state. That is, any traffic policy allows local repair for that LSP/state. That is, any traffic
re-routing action (associated to this state) must be initiated and re-routing action (associated to this state) must be initiated and
completed only as allowed by local node policy. completed only as allowed by local node policy.
When the node cannot act locally, it MUST issue a PathErr message When the node cannot act locally, it MUST issue a PathErr message
indicating its inability to perform local rerouting. Such a message indicating its inability to perform local rerouting. The PathErr
MUST include one of the following combinations of error codes and message MUST contain an ERROR_SPEC object of the format defined in
error values: [RFC2205] or [RFC3473]. Such a message MUST include one of the
following combinations of error codes and error values:
1. "Notify/Local node maintenance required" to support backwards 1. "Notify/Local node maintenance required" to support backwards
compatibility and to reroute around the local node. compatibility and to reroute around the local node.
2. "Notify/Local link maintenance required" to support backwards 2. "Notify/Local link maintenance required" to support backwards
compatibility and to reroute around a local interface. compatibility and to reroute around a local interface.
3. "Reroute/<any Reroute error value>" for future compatibility 3. "Reroute/<any Reroute error value>" for future compatibility
and when backwards compatibility is not a concern. and when backwards compatibility is not a concern.
The rest of the ERROR_SPEC object is constructed based on the local The rest of the ERROR_SPEC object is constructed based on the local
rerouting decision. When the reroute decision redirects traffic rerouting decision and the resource that is to be avoided by an
around the local node, the local node MUST be indicated in the upstream node. It is important to note that the address and TLVs
ERROR_SPEC object. Otherwise, i.e., when the reroute decision does carried by the ERROR_SPEC object identify the resource to be avoided
not redirect traffic around the local node, the impacted interface and not the error code and value.
MUST be indicated in the ERROR_SPEC object. The IF_ID ERROR_SPEC
SHOULD also be used when supported. The TLVs defined in [RFC4920] When the reroute decision redirects traffic around the local node,
MAY also be used when supported and when they can provide specific the local node MUST be indicated in the ERROR_SPEC object. Otherwise,
additional reroute request information, e.g., reroute around a i.e., when the reroute decision does not redirect traffic around the
specific label. The principles related to ERROR_SPEC object local node, the impacted interface MUST be indicated in the
construction defined in section 6.3.1. of [RFC4920] SHOULD be ERROR_SPEC object and the IF_IF [RFC3473] ERROR_SPEC object formats
followed. SHOULD be used to indicate the impacted interface.
The IF_ID [RFC3473] ERROR_SPEC object format MUST be used to indicate
a reroute request that is more specific than an interface. The TLVs
defined in [RFC3471], as updated by [RFC3477] and [RFC4201], and
[RFC4920] MAY be used to provide specific additional reroute request
information, e.g., reroute around a specific label. The principles
related to ERROR_SPEC object construction defined in section 6.3.1.
of [RFC4920] SHOULD be followed.
2.1.1. Reroute Request Timeouts 2.1.1. Reroute Request Timeouts
Reroute request timeouts are used to remove an LSP when there is no Reroute request timeouts are used to remove an LSP when there is no
response to a reroute request. Reroute request timeouts MUST NOT be response to a reroute request. A reroute request timeout is used
used, when the LSP is not to be removed at the expiration of the when an LSP is to be removed at the expiration of the Reroute request
Reroute request timeout period. When such LSP removal is desired and timeout period. When such LSP removal is desired and after
after initiating a reroute request, the initiating node MUST initiate initiating a reroute request, the initiating node MUST initiate a
a timeout during which it expects to receive a response to the timeout during which it expects to receive a response to the reroute
reroute request. Valid responses are a PathTear message or a trigger request. Valid responses are a PathTear message or a trigger Path
Path message with an ERO avoiding the resource that was indicated in message with an ERO avoiding the resource that was indicated in the
the reroute request. If either type of message is received, the reroute request. If either type of message is received, the timeout
timeout period MUST be canceled and no further action is needed. period MUST be canceled and no further action is needed. Note,
Note, normal refresh processing is not modified by the introduction normal refresh processing is not modified by the introduction of
of reroute request timeouts. Such processing may result in Path reroute request timeouts. Such processing may result in Path state
state being removed during the timeout period, in which case the being removed during the timeout period, in which case the timeout
timeout period MUST also be canceled. period MUST also be canceled.
If the reroute request timeout is reached, the initiating node MUST If the reroute request timeout is reached, the initiating node MUST
remove the LSP and its associated state and resources. Removal of remove the LSP and its associated state and resources. Removal of
LSP state is indicated downstream via a corresponding PathTear LSP state is indicated downstream via a corresponding PathTear
message. Removal is indicated upstream via a PathErr message with message. Removal is indicated upstream via a PathErr message with
the error code of "Service preempted". The Path_State_Removed flag the error code of "Service preempted". The Path_State_Removed flag
MUST be set if supported. When the Path_State_Removed flag is not MUST be set if supported. When the Path_State_Removed flag is not
supported, a corresponding ResvTear MUST also be sent. supported, a corresponding ResvTear MUST also be sent.
2.2. Processing at Upstream Node 2.2. Processing at Upstream Node
skipping to change at page 6, line 43 skipping to change at page 7, line 8
2.1. 2.1.
Upon receiving a reroute request, the ingress MUST attempt to Upon receiving a reroute request, the ingress MUST attempt to
identify an alternate path, avoiding the node, interface, resource, identify an alternate path, avoiding the node, interface, resource,
etc. identified within the ERROR_SPEC object. When an alternate path etc. identified within the ERROR_SPEC object. When an alternate path
cannot be identified the reroute request MUST be discarded. When an cannot be identified the reroute request MUST be discarded. When an
alternate path is identified, a corresponding make-before-break LSP alternate path is identified, a corresponding make-before-break LSP
SHOULD be initiated, and standard make-before-break procedures MUST SHOULD be initiated, and standard make-before-break procedures MUST
be followed. be followed.
3. IANA Considerations 3. Example Reroute Requests
This section provides example reroute requests. This section is
informative rather than prescriptive. Reroute requests are always
sent via PathErr messages. As described above, a PathErr message may
contain either an [RFC2205] format ERROR_SPEC object, or an IF_ID
[RFC3473] format ERROR_SPEC object and 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 avoided by the reroute.
3.1. Node Reroute Request
To indicate that the node should be avoided by an upstream node, the
node originating the reroute may format the ERROR_SPEC per [RFC2205],
for example:
o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1
+-------------+-------------+-------------+-------------+
| IPv4 Error Node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+
The node address is set to the local node's TE router address. Error
code is set to either "Notify/Local node maintenance required" or
"Reroute/<any Reroute error value>".
3.2. Interface Reroute Request
To indicate that a numbered interface should be avoided by an
upstream node, the node originating the reroute may format the
ERROR_SPEC per [RFC3473], for example:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The node address is set to the local node's TE router address. Error
code is set to either "Notify/Local link maintenance required" or
"Reroute/<any Reroute error value>". IP address is set to the TE
address of the interface to be avoided.
3.3. Component Reroute Request
To indicate that an unnumbered component should be avoided by an
upstream node, the node originating the reroute formats the
ERROR_SPEC per [RFC4201], for example:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length (12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The node address is set to the local TE address used in the
advertisement of the bundle associated with the component. Error
code is set to either "Notify/Local link maintenance required" or
"Reroute/<any Reroute error value>". Router ID is set to the local
router ID and Interface ID is the identifier assigned to the
component link by the local node.
3.4. Label Reroute Request
To indicate that a label should be avoided by an upstream node, the
node originating the reroute may format the ERROR_SPEC per [RFC4920],
for example:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (6) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DOWNSTREAM_LABEL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The node address is set to the local node's TE router address. Error
code is set to either "Notify/Local link maintenance required" or
"Reroute/<any Reroute error value>". IP address is set to the TE
address of the interface which supports the label to be avoided.
DOWNSTREAM_LABEL indicates the label to be avoided.
4. IANA Considerations
IANA is requested to administer assignment of new values for IANA is requested to administer assignment of new values for
namespaces defined in this document and reviewed in this section. namespaces defined in this document and reviewed in this section.
Upon approval of this document, the IANA will make the assignment in Upon approval of this document, the IANA will make the assignment in
the "Error Codes and Globally-Defined Error Value Sub-Codes" section the "Error Codes and Globally-Defined Error Value Sub-Codes" section
of the "RSVP Parameters" registry located at of the "RSVP Parameters" registry located at
http://www.iana.org/assignments/rsvp-parameters: http://www.iana.org/assignments/rsvp-parameters:
34* Reroute [This document] 34* Reroute [This document]
skipping to change at page 7, line 23 skipping to change at page 10, line 21
Reroute error values should be allocated based on the following Reroute error values should be allocated based on the following
allocation policy as defined in [RFC5226]. allocation policy as defined in [RFC5226].
Range Registration Procedures Range Registration Procedures
-------- ------------------------ -------- ------------------------
0-32767 IETF Consensus 0-32767 IETF Consensus
32768-65535 Private Use 32768-65535 Private Use
(*) Suggested value. (*) Suggested value.
4. Security Considerations 5. Security Considerations
This document introduces no new security considerations as this This document introduces no new security considerations as this
document describes usage of existing formats and mechanisms. This document describes usage of existing formats and mechanisms. This
document does introduce a new error code value, but this value is document does introduce a new error code value, but this value is
functionally equivalent to existing semantics. The Section 9 of functionally equivalent to existing semantics. The Section 9 of
[RFC4920] and [RFC4736] should be used as the starting point for [RFC4920] and [RFC4736] should be used as the starting point for
reviewing the security considerations related to the formats and reviewing the security considerations related to the formats and
mechanisms discussed in this document. mechanisms discussed in this document.
5. References 6. References
5.1. Normative References 6.1. Normative References
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, "Resource ReSerVation Protocol (RSVP) -- Version 1,
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001. to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions for [RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing an [RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
5.2. Informative References 6.2. Informative References
[RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol [RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol
Label Switching (MPLS) Traffic Engineering (TE) Loosely Label Switching (MPLS) Traffic Engineering (TE) Loosely
Routed Label Switched Path (LSP)", RFC 4736, November Routed Label Switched Path (LSP)", RFC 4736, November
2006. 2006.
[GRACEFUL] Ali, Z., et al., "Graceful Shutdown in MPLS and [GRACEFUL] Ali, Z., et al., "Graceful Shutdown in MPLS and
Generalized MPLS Traffic Engineering Networks", Generalized MPLS Traffic Engineering Networks",
draft-ietf-ccamp-mpls-graceful-shutdown-06.txt, draft-ietf-ccamp-mpls-graceful-shutdown-08.txt,
Work in Progress, October 2008
[PATHERR] Vasseur, JP., Ed. "Node behavior upon originating and [PATHERR] Vasseur, JP., Ed. "Node behavior upon originating and
receiving Resource ReserVation Protocol (RSVP) Path receiving Resource ReserVation Protocol (RSVP) Path
Error message", draft-ietf-mpls-3209-patherr-03.txt, Error message", draft-ietf-mpls-3209-patherr-03.txt,
Work in Progress, August 2008. Work in Progress, August 2008.
[PREEMPTION] Meyer, M., Ed. "MPLS Traffic Engineering Soft [PREEMPTION] Meyer, M., Ed. "MPLS Traffic Engineering Soft
Preemption", draft-ietf-mpls-soft-preemption-12.txt, Preemption", draft-ietf-mpls-soft-preemption-14.txt,
Work in Progress, September 2008. Work in Progress, November 2008.
6. Acknowledgments 7. Acknowledgments
This document was conceived along with Matthew Meyer. George Swallow This document was conceived along with Matthew Meyer. George Swallow
provided valuable feedback. provided valuable feedback.
7. Author's Addresses 8. Author's Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Lucent Alcatel Lucent
Francis Wellesplein 1, Francis Wellesplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel-lucent.be Email: Dimitri.Papadimitriou@alcatel-lucent.be
JP Vasseur JP Vasseur
Cisco Systems, Inc Cisco Systems, Inc
1414 Massachusetts Avenue 11, Rue Camille Desmoulins
Boxborough, MA 01719 L'Atlantis
USA 92782 Issy Les Moulineaux
France
Email: jpv@cisco.com Email: jpv@cisco.com
8. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The IETF Trust (2008). 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.
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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. Intellectual Property 10. Intellectual Property
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 claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology 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 rights such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
skipping to change at line 405 skipping to change at line 548
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 the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Generated on: Fri Sep 19 10:17:15 EDT 2008 Generated on: Tue Nov 25 09:47:22 EST 2008
 End of changes. 27 change blocks. 
70 lines changed or deleted 213 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/