draft-ietf-mpls-gmpls-lsp-reroute-04.txt   draft-ietf-mpls-gmpls-lsp-reroute-05.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: July 30, 2009 Expiration Date: March 10, 2010
January 30, 2009 September 10, 2009
PathErr Message Triggered MPLS and GMPLS LSP Reroute PathErr Message Triggered MPLS and GMPLS LSP Reroute
draft-ietf-mpls-gmpls-lsp-reroute-04.txt draft-ietf-mpls-gmpls-lsp-reroute-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with BCP 78 and 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
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 months Internet-Drafts are draft documents valid for a maximum of six months
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 July 30, 2009. This Internet-Draft will expire on March 10, 2010.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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) point-to-point Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point
Traffic Engineering (TE) Label Switched Paths (LSPs) without first Traffic Engineering (TE) Label Switched Paths (LSPs) without first
removing LSP state or resources. Such LSP rerouting may be desirable removing LSP state or resources. Such LSP rerouting may be desirable
in a number of cases including, for example, soft-preemption and in a number of cases including, for example, soft-preemption and
graceful shutdown. This document describes the usage of existing graceful shutdown. This document describes the usage of existing
Standards Track mechanisms to support LSP rerouting. In this case, it Standards Track mechanisms to support LSP rerouting. In this case, it
relies on mechanisms already defined as part of RSVP-TE and simply relies on mechanisms already defined as part of RSVP-TE and simply
describes a sequence of actions to be executed. While existing describes a sequence of actions to be executed. While existing
protocol definition can be used to support reroute applications, this protocol definition can be used to support reroute applications, this
document also defines a new reroute-specific error code to allow for document also defines a new reroute-specific error code to allow for
the 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 ............................... 6 2.2 Processing at Upstream Node ............................ 6
2.3 Processing at Ingress ..................................... 6 2.3 Processing at Ingress .................................. 6
3 Example Reroute Requests .................................. 7 3 Example Reroute Requests ............................... 7
3.1 Node Reroute Request ...................................... 7 3.1 Node Reroute Request ................................... 7
3.2 Interface Reroute Request ................................. 7 3.2 Interface Reroute Request .............................. 7
3.3 Component Reroute Request ................................. 8 3.3 Component Reroute Request .............................. 8
3.4 Label Reroute Request ..................................... 9 3.4 Label Reroute Request .................................. 9
4 IANA Considerations ....................................... 9 4 IANA Considerations .................................... 9
5 Security Considerations ................................... 10 5 Security Considerations ................................ 10
6 References ................................................ 10 6 References ............................................. 10
6.1 Normative References ...................................... 10 6.1 Normative References ................................... 10
6.2 Informative References .................................... 11 6.2 Informative References ................................. 11
7 Acknowledgments ........................................... 12 7 Acknowledgments ........................................ 12
8 Author's Addresses ........................................ 12 8 Authors' Addresses ..................................... 12
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
change path state in the nodes through which they pass". change path state in the nodes through which they pass".
Notwithstanding this definition, PathErr messages are most commonly Notwithstanding this definition, PathErr messages are most commonly
used to report errors during LSP establishment, i.e. the RSVP-TE used to report errors during LSP establishment, i.e., the RSVP-TE
processing that occurs prior to the ingress receiving a Resv message. processing that occurs prior to the ingress receiving a Resv message.
(See [PATHERR] for a broader discussion on PathErr message handling.) (See [PATHERR] for a broader discussion on PathErr message handling.)
Support for such usage was enhanced via the introduction of the Support for such usage was enhanced via the introduction of the
Path_State_Removed flag in [RFC3473], which enables a processing node Path_State_Removed flag in [RFC3473], which enables a processing node
to free related LSP state and resources. The usage of PathErr to free related LSP state and resources. The usage of PathErr
messages during LSP establishment was further covered in [RFC4920] messages during LSP establishment was further covered in [RFC4920]
which describes in detail how a node may indicate that the node or which describes in detail how a node may indicate that the node or
one of its associated resources should be avoided, i.e., routed one of its associated resources should be avoided, i.e., routed
around, during LSP establishment. around, during LSP establishment.
skipping to change at page 4, line 14 skipping to change at page 4, line 14
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
routing of an LSP, and how the upstream nodes can respond to such a rerouting 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 first determines if it can act on the reroute established LSP, it first determines if it can act on the reroute
request locally. Such a check MUST be performed on the condition that request locally. Such a check MUST be performed on the condition that
the ERO received in the LSP's incoming Path message does not preclude the Explicit Route Object (ERO), see [RFC3209], received in the LSP's
LSP re-routing. Examples of events that may trigger reroutes are incoming Path message does not preclude LSP rerouting. Examples of
avoiding an outgoing interface, a component, label resource, or a events that may trigger reroutes are avoiding an outgoing interface,
next hop not explicitly listed in the ERO. In all cases, the actual a component, label resource, or a next hop not explicitly listed in
repair action SHOULD be performed after verification that the local the ERO. In all cases, the actual repair action SHOULD be performed
policy allows local repair for that LSP/state. That is, any traffic after verification that the local policy allows local repair for that
re-routing action (associated to this state) must be initiated and LSP/state. That is, any traffic rerouting action (associated to this
completed only as allowed by local node policy. state) must be initiated and 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. The PathErr indicating its inability to perform local rerouting. The PathErr
message MUST contain an ERROR_SPEC object of the format defined in message MUST contain an ERROR_SPEC object of the format defined in
[RFC2205] or [RFC3473]. Such a message MUST include one of the [RFC2205] or [RFC3473]. Such a message MUST include one of the
following combinations of error codes and error values: 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.
skipping to change at page 5, line 11 skipping to change at page 5, line 12
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 and the resource that is to be avoided by an rerouting decision and the resource that is to be avoided by an
upstream node. It is important to note that the address and TLVs upstream node. It is important to note that the address and TLVs
carried by the ERROR_SPEC object identify the resource to be avoided carried by the ERROR_SPEC object identify the resource to be avoided
and not the error code and value. and not the error code and value.
When the reroute decision redirects traffic around the local node, When the reroute decision redirects traffic around the local node,
the local node MUST be indicated in the ERROR_SPEC object. Otherwise, the local node MUST be indicated in the ERROR_SPEC object. Otherwise,
i.e., when the reroute decision does not redirect traffic around the i.e., when the reroute decision does not redirect traffic around the
local node, the impacted interface MUST be indicated in the local node, the impacted interface MUST be indicated in the
ERROR_SPEC object and the IF_IF [RFC3473] ERROR_SPEC object formats ERROR_SPEC object and the IF_ID [RFC3473] ERROR_SPEC object formats
SHOULD be used to indicate the impacted interface. SHOULD be used to indicate the impacted interface.
The IF_ID [RFC3473] ERROR_SPEC object format MUST be used to indicate 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 a reroute request that is more specific than an interface. The TLVs
defined in [RFC3471], as updated by [RFC3477] and [RFC4201], and defined in [RFC3471], as updated by [RFC3477] and [RFC4201], and
[RFC4920] MAY be used to provide specific additional reroute request [RFC4920] MAY be used to provide specific additional reroute request
information, e.g., reroute around a specific label. The principles information, e.g., reroute around a specific label. The principles
related to ERROR_SPEC object construction defined in section 6.3.1. related to ERROR_SPEC object construction defined in section 6.3.1.
of [RFC4920] SHOULD be followed. of [RFC4920] SHOULD be followed.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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 in a received PathErr message which reroute request is indicated in a received PathErr message which
carries one of the error code and value combinations listed above in carries one of the error code and value combinations listed above in
Section 2.1. Note that a conformant implementation MUST check for Section 2.1. Note that a conformant implementation MUST check for
any of the the three combinations listed in Section 2.1. any of the the three combinations listed in Section 2.1.
A transit node MAY act on a reroute request locally when the ERO A transit node MAY act on a reroute request locally when the ERO
received in the LSP's incoming Path message does not precluded the received in the LSP's incoming Path message does not preclude the
reroute. As before, examples include loosely routed LSP next hops. reroute. As before, examples include loosely routed LSP next hops.
When the reroute request can be processed locally, standard local When the reroute request can be processed locally, standard local
repair processing MUST be followed. The node SHOULD limit the number repair processing MUST be followed. The node SHOULD limit the number
of local repair attempts. Again, the expected norm is for local of local repair attempts. Again, the expected norm is for local
repair and, thereby, this case to be precluded due to policy. 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 rerouting 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 rerouting".) 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 not
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
skipping to change at page 11, line 33 skipping to change at page 11, line 33
6.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-08.txt, draft-ietf-ccamp-mpls-graceful-shutdown-10.txt,
Work in Progress, October 2008 Work in Progress, March 2009.
[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-05.txt,
Work in Progress, August 2008. Work in Progress, July 2009.
[PREEMPTION] Meyer, M., Ed. "MPLS Traffic Engineering Soft [PREEMPTION] Meyer, M., Ed. "MPLS Traffic Engineering Soft
Preemption", draft-ietf-mpls-soft-preemption-14.txt, Preemption", draft-ietf-mpls-soft-preemption-18.txt,
Work in Progress, November 2008. Work in Progress, July 2009.
7. 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. The General Area Review Team (Gen-ART)
review was performed by Francis Dupont.
8. Author's Addresses 8. Authors' 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
skipping to change at line 507 skipping to change at line 513
Email: Dimitri.Papadimitriou@alcatel-lucent.be Email: Dimitri.Papadimitriou@alcatel-lucent.be
JP Vasseur JP Vasseur
Cisco Systems, Inc Cisco Systems, Inc
11, Rue Camille Desmoulins 11, Rue Camille Desmoulins
L'Atlantis L'Atlantis
92782 Issy Les Moulineaux 92782 Issy Les Moulineaux
France France
Email: jpv@cisco.com Email: jpv@cisco.com
Generated on: Fri Jan 30 15:42:58 EST 2009 Generated on: Thu Sep 10 08:11:31 EDT 2009
 End of changes. 21 change blocks. 
52 lines changed or deleted 58 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/