draft-ietf-mpls-gmpls-lsp-reroute-00.txt   draft-ietf-mpls-gmpls-lsp-reroute-01.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Category: Best Common Practice Updates: 3209 Dimitri Papadimitriou (Alcatel Lucent)
Expiration Date: February 5, 2009 Dimitri Papadimitriou (Alcatel Lucent) Category: Standards Track JP. Vasseur (Cisco)
JP. Vasseur (Cisco) Expiration Date: March 2, 2009
August 5, 2008 September 2, 2008
PathErr Message Triggered MPLS and GMPLS LSP Reroute PathErr Message Triggered MPLS and GMPLS LSP Reroute
draft-ietf-mpls-gmpls-lsp-reroute-00.txt draft-ietf-mpls-gmpls-lsp-reroute-01.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 February 5, 2009. This Internet-Draft will expire on March 2, 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) Traffic
Engineering (TE) Label Switched Paths (LSPs) without first removing Engineering (TE) Label Switched Paths (LSPs) without first removing
LSP state or resources. Such LSP rerouting may be desirable in a LSP state or resources. Such LSP rerouting may be desirable in a
number of cases including, for example, soft-preemption and graceful number of cases including, for example, soft-preemption and graceful
shutdown. This document describes the usage of existing Standards shutdown. This document describes the usage of existing Standards
Track mechanisms and defines no new formats or mechanisms. It relies Track mechanisms to support LSP rerouting. In this case, it relies on
on mechanisms already defined as part of RSVP-TE and simply describes mechanisms already defined as part of RSVP-TE and simply describes a
a sequence of actions to be executed. sequence of actions to be executed. While existing protocol
definition can be used to support reroute applications, this document
also defines a new reroute-specific error code to allow for 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 ............................... 5
2.3 Processing at Ingress ..................................... 6 2.3 Processing at Ingress ..................................... 6
3 IANA Considerations ....................................... 6 3 IANA Considerations ....................................... 6
4 Security Considerations ................................... 6 4 Security Considerations ................................... 7
5 References ................................................ 6 5 References ................................................ 7
5.1 Normative References ...................................... 6 5.1 Normative References ...................................... 7
5.2 Informative References .................................... 7 5.2 Informative References .................................... 8
6 Acknowledgments ........................................... 7 6 Acknowledgments ........................................... 8
7 Author's Addresses ........................................ 8 7 Author's Addresses ........................................ 8
8 Full Copyright Statement .................................. 8 8 Full Copyright Statement .................................. 9
9 Intellectual Property ..................................... 8 9 Intellectual Property ..................................... 9
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 46 skipping to change at page 3, line 46
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 how a node can initiate a reroute request without disrupting
LSP data traffic or, when so desired, with the disruption of data LSP data traffic or, when so desired, with the disruption of data
traffic and removal of LSP associated state and resources. traffic and removal of LSP associated state and resources.
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. resources and signaling such removal. While this document describes
how existing protocol definitions can be used to support rerouting,
it also defines a new reroute-specific error code to allow for the
future definition of reroute application-specific error values.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Reroute Requests 2. Reroute Requests
This section describes how a downstream node can indicate that it This section describes how a downstream node can indicate that it
desires a node upstream (along the LSP path) to initiate the re- desires a node upstream (along the LSP path) to initiate the re-
routing of an LSP, and how the upstream nodes can respond to such a routing of an LSP, and how the upstream nodes can respond to such a
request. Initiating nodes, transit nodes, and ingress nodes are request. Initiating nodes, transit nodes, and ingress nodes are
described separately. described separately.
2.1. Processing at Requesting Node 2.1. Processing at Requesting Node
When a transit or egress node desires to request the rerouting of an When a transit or egress node desires to request the rerouting of an
established LSP, it MUST first determine if it can act on the reroute established LSP, it first determines if it can act on the reroute
request locally. A reroute request may be acted on locally if the request locally. A reroute request SHOULD be acted on locally if the
ERO received in the LSP's incoming Path message does not precluded ERO received in the LSP's incoming Path message does not precluded
the reroute and the node's policy allows local repair. Examples of the reroute and the node's policy allows local repair. Examples of
reroute requests that may be permissible are reroutes avoiding reroute requests that may be permissible are reroutes avoiding
outgoing interface, component, label resource, or next hops not outgoing interface, component, label resource, or next hops not
explicitly listed in the ERO. When the reroute request can be explicitly listed in the ERO. When the reroute request can be
processed locally, standard local repair processing MUST be followed. processed locally, standard local repair processing MUST be followed.
The node SHOULD limit the number of local repair attempts. The The node SHOULD limit the number of local repair attempts. The
expected norm is for local repair and, thereby, this case to be expected norm is for local repair and, thereby, this case to be
precluded by policy. precluded by policy.
When the requesting node cannot act on a reroute request locally, it When the requesting node cannot act on a reroute request locally, it
MUST issue a PathErr message with the error code "Notify" and a value MUST issue a PathErr message indicating a reroute request. A reroute
of either "Local link maintenance required" or "Local node request MUST be indicated via one of the following combinations of
maintenance required". The error value is based on the local reroute error codes and error values:
request. If the local request directs a reroute around the local
node, the error value "Local node maintenance required" MUST be used
and the local node MUST be indicated in the ERROR_SPEC object.
If the local request does not direct a reroute around the local node, 1. "Notify/Local node maintenance required" to support backwards
the error value "Local link maintenance required" MUST be used, and compatibility and to reroute around the local node.
the impacted interface MUST be indicated in the ERROR_SPEC object.
The IF_ID ERROR_SPEC SHOULD also be used when supported. The TLVs 2. "Notify/Local link maintenance required" to support backwards
defined in [RFC4920] MAY also be used when supported and when they compatibility and to reroute around a local interface.
can provide specific additional reroute request information, e.g.,
reroute around a specific label. The principles related to 3. "Reroute/<any Reroute error value>" for future compatibility
ERROR_SPEC object construction defined in section 6.3.1. of [RFC4920] and when backwards compatibility is not a concern.
SHOULD be followed.
The rest of the ERROR_SPEC object is constructed based on the local
reroute request. When the local reroute request directs a reroute
around the local node, the local node MUST be indicated in the
ERROR_SPEC object. When the local request does not direct to reroute
around the local node, the impacted interface MUST be indicated in
the ERROR_SPEC object. The IF_ID ERROR_SPEC SHOULD also be used when
supported. The TLVs defined in [RFC4920] MAY also be used when
supported and when they can 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. Reroute request timeouts MUST NOT be
used, when the LSP is not to be removed at the expiration of the used, when the LSP is not to be removed at the expiration of the
Reroute request timeout period. When such LSP removal is desired and Reroute request timeout period. When such LSP removal is desired and
after initiating a reroute request, the initiating node MUST initiate after initiating a reroute request, the initiating node MUST initiate
a timeout during which it expects to receive a response to the a timeout during which it expects to receive a response to the
reroute request. Valid responses are a PathTear message or a trigger reroute request. Valid responses are a PathTear message or a trigger
skipping to change at page 5, line 35 skipping to change at page 5, line 43
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
When a transit node's policy permits it to support reroute request When a transit node's policy permits it to support reroute request
processing and local repair, the node MUST examine incoming PathErr processing and local repair, the node MUST examine incoming PathErr
messages to see it the node can perform a requested reroute. A messages to see it the node can perform a requested reroute. A
reroute request is indicated by the error code and value of reroute request is indicated in a received PathErr message which
"Notify/Local (link or node) maintenance required" in a received carries one of the error code and value combinations listed above in
PathErr message. A transit node MAY act on a reroute request locally Section 2.1. Note that a conformant implementation MUST check for
when the ERO received in the LSP's incoming Path message does not any of the the three combinations listed in Section 2.1.
precluded the reroute. As before, examples include loosely routed
LSP next hops. When the reroute request can be processed locally, A transit node MAY act on a reroute request locally when the ERO
standard local repair processing MUST be followed. The node SHOULD received in the LSP's incoming Path message does not precluded the
limit the number of local repair attempts. Again, the expected norm reroute. As before, examples include loosely routed LSP next hops.
is for local repair and, thereby, this case to be precluded due to When the reroute request can be processed locally, standard local
policy. repair processing MUST be followed. The node SHOULD limit the number
of local repair attempts. Again, the expected norm is for local
repair and, thereby, this case to be precluded due to policy.
When the transit node supports [RFC4920], is a boundary node and When the transit node supports [RFC4920], is a boundary node and
Boundary Re-routing is allowed, it SHOULD use a route request as a Boundary Re-routing is allowed, it SHOULD use a route request as a
trigger to reroute the LSP. (Per [RFC4920], the Flags field of the trigger to reroute the LSP. (Per [RFC4920], the Flags field of the
LSP_ATTRIBUTES object of the initial Path message indicate "Boundary LSP_ATTRIBUTES object of the initial Path message indicate "Boundary
re-routing".) In the case the node triggers rerouting, it first MUST re-routing".) In the case the node triggers rerouting, it first MUST
identify an alternate path within the domain. When such a path is identify an alternate path within the domain. When such a path is
available, the node MUST terminate the PathErr message and issue a available, the node MUST terminate the PathErr message and issue a
Path message reflecting the identified alternate path. Processing Path message reflecting the identified alternate path. Processing
then continues per [RFC4920]. When an alternate path is note then continues per [RFC4920]. When an alternate path is note
available, the node cannot act on the reroute request. available, the node cannot act on the reroute request.
When a transit node node cannot act on a reroute request locally, per When a transit node node cannot act on a reroute request locally, per
standard processing, it MUST propagate the received PathErr message standard processing, it MUST propagate the received PathErr message
to the previous hop. to the previous hop.
2.3. Processing at Ingress 2.3. Processing at Ingress
When reroute processing is supported, an ingress node MUST check When reroute processing is supported, an ingress node MUST check
received PathErr messages to identify them as indicating reroute received PathErr messages to identify them as indicating reroute
requests. A reroute request is indicated by the error code and value requests. A reroute request is indicated in a received PathErr
of "Notify/Local (link or node) maintenance required" in a received message which carries one of the error code and value combinations
PathErr message. Upon receiving a reroute request, the ingress MUST listed above in Section 2.1. Note that a conformant implementation
attempt to identify an alternate path, avoiding the node, interface, MUST check for any of the the three combinations listed in Section
resource, etc. identified within the ERROR_SPEC object. When an 2.1.
alternate path cannot be identified the reroute request MUST be
discarded. When an alternate path is identified, a corresponding Upon receiving a reroute request, the ingress MUST attempt to
make-before-break LSP SHOULD be initiated, and standard make-before- identify an alternate path, avoiding the node, interface, resource,
break procedures MUST be followed. etc. identified within the ERROR_SPEC object. When an alternate path
cannot be identified the reroute request MUST be discarded. When an
alternate path is identified, a corresponding make-before-break LSP
SHOULD be initiated, and standard make-before-break procedures MUST
be followed.
3. IANA Considerations 3. IANA Considerations
No new IANA administered values are requested by this document. IANA is requested to administer assignment of new values for
namespaces defined in this document and reviewed in this section.
Upon approval of this document, the IANA will make the assignment in
the "Error Codes and Globally-Defined Error Value Sub-Codes" section
of the "RSVP Parameters" registry located at
http://www.iana.org/assignments/rsvp-parameters:
34* Reroute [This document]
This Error Code has the following defined Error Value sub-code:
0 = Generic LSP reroute request
Reroute error values should be allocated based on the following
allocation policy as defined in [RFC5226].
Range Registration Procedures
-------- ------------------------
0-32767 IETF Consensus
32768-65535 Private Use
(*) Suggested value.
4. Security Considerations 4. 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. The document describes usage of existing formats and mechanisms. This
Section 9 of [RFC4920] and [RFC4736] should be used as the starting document does introduce a new error code value, but this value is
point for reviewing the security considerations related to the functionally equivalent to existing semantics. The Section 9 of
formats and mechanisms discussed in this document. [RFC4920] and [RFC4736] should be used as the starting point for
reviewing the security considerations related to the formats and
mechanisms discussed in this document.
5. References 5. References
5.1. Normative References 5.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
skipping to change at page 7, line 20 skipping to change at page 8, line 13
to RSVP for LSP Tunnels", RFC 3209, December 2001. to RSVP for LSP Tunnels", RFC 3209, December 2001.
[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.
[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
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
5.2. Informative References 5.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-05.txt, draft-ietf-ccamp-mpls-graceful-shutdown-06.txt,
Work in Progress, January 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-02.txt, Error message", draft-ietf-mpls-3209-patherr-03.txt,
Work in Progress, February 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-10.txt, Preemption", draft-ietf-mpls-soft-preemption-12.txt,
Work in Progress, February 2008. Work in Progress, September 2008.
6. Acknowledgments 6. Acknowledgments
This document was conceived along with Matthew Meyer. This document was conceived along with Matthew Meyer.
7. Author's Addresses 7. 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
skipping to change at line 359 skipping to change at line 404
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: Tue Aug 5 17:48:17 EDT 2008 Generated on: Tue Sep 2 13:05:25 EDT 2008
 End of changes. 20 change blocks. 
65 lines changed or deleted 111 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/