--- 1/draft-ietf-mpls-gmpls-lsp-reroute-04.txt 2009-09-10 15:12:10.000000000 +0200 +++ 2/draft-ietf-mpls-gmpls-lsp-reroute-05.txt 2009-09-10 15:12:10.000000000 +0200 @@ -1,106 +1,110 @@ Internet Draft Lou Berger (LabN) Updates: 3209 Dimitri Papadimitriou (Alcatel Lucent) 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 - draft-ietf-mpls-gmpls-lsp-reroute-04.txt + draft-ietf-mpls-gmpls-lsp-reroute-05.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the 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 Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Abstract This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a 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 - 1 Introduction .............................................. 3 - 1.1 Conventions used in this document ......................... 4 - 2 Reroute Requests .......................................... 4 - 2.1 Processing at Requesting Node ............................. 4 - 2.1.1 Reroute Request Timeouts .................................. 5 - 2.2 Processing at Upstream Node ............................... 6 - 2.3 Processing at Ingress ..................................... 6 - 3 Example Reroute Requests .................................. 7 - 3.1 Node Reroute Request ...................................... 7 - 3.2 Interface Reroute Request ................................. 7 - 3.3 Component Reroute Request ................................. 8 - 3.4 Label Reroute Request ..................................... 9 - 4 IANA Considerations ....................................... 9 - 5 Security Considerations ................................... 10 - 6 References ................................................ 10 - 6.1 Normative References ...................................... 10 - 6.2 Informative References .................................... 11 - 7 Acknowledgments ........................................... 12 - 8 Author's Addresses ........................................ 12 + 1 Introduction ........................................... 3 + 1.1 Conventions used in this document ...................... 4 + 2 Reroute Requests ....................................... 4 + 2.1 Processing at Requesting Node .......................... 4 + 2.1.1 Reroute Request Timeouts ............................... 5 + 2.2 Processing at Upstream Node ............................ 6 + 2.3 Processing at Ingress .................................. 6 + 3 Example Reroute Requests ............................... 7 + 3.1 Node Reroute Request ................................... 7 + 3.2 Interface Reroute Request .............................. 7 + 3.3 Component Reroute Request .............................. 8 + 3.4 Label Reroute Request .................................. 9 + 4 IANA Considerations .................................... 9 + 5 Security Considerations ................................ 10 + 6 References ............................................. 10 + 6.1 Normative References ................................... 10 + 6.2 Informative References ................................. 11 + 7 Acknowledgments ........................................ 12 + 8 Authors' Addresses ..................................... 12 1. Introduction Resource ReserVation Protocol (RSVP), see [RFC2205], has been extended to support the control of Traffic Engineering (TE) Label Switched Paths (LSPs) for both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) in, respectively, [RFC3209] and [RFC3473]. In all cases, a PathErr message is used to report errors to nodes upstream of the error detecting node. As defined in [RFC2205], and left unmodified by [RFC3209], PathErr messages "do not change path state in the nodes through which they pass". 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. (See [PATHERR] for a broader discussion on PathErr message handling.) Support for such usage was enhanced via the introduction of the Path_State_Removed flag in [RFC3473], which enables a processing node to free related LSP state and resources. The usage of PathErr messages during LSP establishment was further covered in [RFC4920] which describes in detail how a node may indicate that the node or one of its associated resources should be avoided, i.e., routed around, during LSP establishment. @@ -132,38 +136,39 @@ 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Reroute Requests This section describes how a downstream node can indicate that it - 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 + desires a node upstream (along the LSP path) to initiate the + rerouting of an LSP, and how the upstream nodes can respond to such a request. Initiating nodes, transit nodes, and ingress nodes are described separately. 2.1. Processing at Requesting Node 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 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 - LSP re-routing. Examples of events that may trigger reroutes are - avoiding an outgoing interface, a component, label resource, or a - next hop not explicitly listed in the ERO. In all cases, the actual - repair action SHOULD be performed after verification that the local - policy allows local repair for that LSP/state. That is, any traffic - re-routing action (associated to this state) must be initiated and - completed only as allowed by local node policy. + the Explicit Route Object (ERO), see [RFC3209], received in the LSP's + incoming Path message does not preclude LSP rerouting. Examples of + events that may trigger reroutes are avoiding an outgoing interface, + a component, label resource, or a next hop not explicitly listed in + the ERO. In all cases, the actual repair action SHOULD be performed + after verification that the local policy allows local repair for that + LSP/state. That is, any traffic rerouting action (associated to this + 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 indicating its inability to perform local rerouting. The PathErr message MUST contain an ERROR_SPEC object of the format defined in [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 compatibility and to reroute around the local node. @@ -176,21 +181,21 @@ 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 upstream node. It is important to note that the address and TLVs carried by the ERROR_SPEC object identify the resource to be avoided and not the error code and value. When the reroute decision redirects traffic around the local node, the local node MUST be indicated in the ERROR_SPEC object. Otherwise, i.e., when the reroute decision does not redirect traffic around 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. 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. @@ -223,36 +228,36 @@ When a transit node's policy permits it to support reroute request processing and local repair, the node MUST examine incoming PathErr messages to see it the node can perform a requested reroute. A reroute request is indicated in a received PathErr message which carries one of the error code and value combinations listed above in Section 2.1. Note that a conformant implementation MUST check for any of the the three combinations listed in Section 2.1. 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. When the reroute request can be processed locally, standard local 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 - 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 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 available, the node MUST terminate the PathErr message and issue a 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. When a transit node node cannot act on a reroute request locally, per standard processing, it MUST propagate the received PathErr message to the previous hop. 2.3. Processing at Ingress When reroute processing is supported, an ingress node MUST check received PathErr messages to identify them as indicating reroute @@ -458,38 +463,39 @@ 6.2. Informative References [RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006. [GRACEFUL] Ali, Z., et al., "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", - draft-ietf-ccamp-mpls-graceful-shutdown-08.txt, - Work in Progress, October 2008 + draft-ietf-ccamp-mpls-graceful-shutdown-10.txt, + Work in Progress, March 2009. [PATHERR] Vasseur, JP., Ed. "Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path - Error message", draft-ietf-mpls-3209-patherr-03.txt, - Work in Progress, August 2008. + Error message", draft-ietf-mpls-3209-patherr-05.txt, + Work in Progress, July 2009. [PREEMPTION] Meyer, M., Ed. "MPLS Traffic Engineering Soft - Preemption", draft-ietf-mpls-soft-preemption-14.txt, - Work in Progress, November 2008. + Preemption", draft-ietf-mpls-soft-preemption-18.txt, + Work in Progress, July 2009. 7. Acknowledgments 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 LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net Dimitri Papadimitriou Alcatel Lucent Francis Wellesplein 1, B-2018 Antwerpen, Belgium @@ -497,11 +503,11 @@ Email: Dimitri.Papadimitriou@alcatel-lucent.be JP Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France Email: jpv@cisco.com -Generated on: Fri Jan 30 15:42:58 EST 2009 +Generated on: Thu Sep 10 08:11:31 EDT 2009