Internet Draft                                         Lou Berger (LabN)
Category: Best Common Practice
Expiration Date: February 5, 2009
Updates: 3209                     Dimitri Papadimitriou (Alcatel Lucent)
Category: Standards Track                            JP. Vasseur (Cisco)

                                                          August 5,
Expiration Date: March 2, 2009

                                                       September 2, 2008

          PathErr Message Triggered MPLS and GMPLS LSP Reroute



Status of this Memo

   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 Section 6 of 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on February 5, March 2, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   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) 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 and defines no new formats or mechanisms.  It 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  ...............................   5
 2.3    Processing at Ingress  .....................................   6
 3      IANA Considerations  .......................................   6
 4      Security Considerations  ...................................   6   7
 5      References  ................................................   6   7
 5.1    Normative References  ......................................   6   7
 5.2    Informative References  ....................................   7   8
 6      Acknowledgments  ...........................................   7   8
 7      Author's Addresses  ........................................   8
 8      Full Copyright Statement  ..................................   8   9
 9      Intellectual Property  .....................................   8   9

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
   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.

   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
   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
   indicating node or a resources associated with the indicating node.
   Some examples of such cases are soft-preemption and graceful
   shutdown.  (See [PREEMPTION] and [GRACEFUL]).

   This document uses the terminology "reroute request" to refer to the
   indication by a node that an upstream reroute should take place. This
   document how a node can initiate a reroute request without disrupting
   LSP data traffic or, when so desired, with the disruption of data
   traffic and removal of LSP associated state and resources.

   The mechanisms used to indicate reroute requests are derived from the
   mechanisms described in [RFC4920], and the error codes defined in
   [RFC4736].  This document describes (1) how a non-disruptive reroute
   request may be issued and, (2) based on an optional "timeout" period,
   how rerouting may be forced by removing LSP state and associated
   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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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
   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 MUST first determine determines if it can act on the reroute
   request locally.  A reroute request may SHOULD be acted on locally if the
   ERO received in the LSP's incoming Path message does not precluded
   the reroute and the node's policy allows local repair. Examples of
   reroute requests that may be permissible are reroutes avoiding
   outgoing interface, component, label resource, or next hops not
   explicitly listed in the ERO.  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.  The
   expected norm is for local repair and, thereby, this case to be
   precluded by policy.

   When the requesting node cannot act on a reroute request locally, it
   MUST issue a PathErr message with indicating a reroute request.  A reroute
   request MUST be indicated via one of the following combinations of
   error code "Notify" codes and a value
   of either "Local link error values:

      1. "Notify/Local node maintenance required" or "Local node to support backwards
         compatibility and to reroute around the local node.

      2. "Notify/Local link maintenance required".  The required" to support backwards
         compatibility and to reroute around a local interface.

      3. "Reroute/<any Reroute error value value>" for future compatibility
         and when backwards compatibility is not a concern.

   The rest of the ERROR_SPEC object is constructed based on the local
   reroute request.  If  When the local reroute 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  When the local request does not direct a to reroute
   around the local node, the error value "Local link maintenance required" MUST be used, and
   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

   Reroute request timeouts are used to remove an LSP when there is no
   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
   Reroute request timeout period.  When such LSP removal is desired and
   after initiating a reroute request, the initiating node MUST initiate
   a timeout during which it expects to receive a response to the
   reroute request.  Valid responses are a PathTear message or a trigger
   Path message with an ERO avoiding the resource that was indicated in
   the reroute request.  If either type of message is received, the
   timeout period MUST be canceled and no further action is needed.
   Note, normal refresh processing is not modified by the introduction
   of reroute request timeouts.  Such processing may result in Path
   state being removed during the timeout period, in which case the
   timeout period MUST also be canceled.

   If the reroute request timeout is reached, the initiating node MUST
   remove the LSP and its associated state and resources.  Removal of
   LSP state is indicated downstream via a corresponding PathTear
   message.  Removal is indicated upstream via a PathErr message with
   the error code of "Service preempted".  The Path_State_Removed flag
   MUST be set if supported.  When the Path_State_Removed flag is not
   supported, a corresponding ResvTear MUST also be sent.

2.2. Processing at Upstream Node

   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 by in a received PathErr message which
   carries one of the error code and value of
   "Notify/Local (link or node) maintenance required" combinations listed above in
   Section 2.1.  Note that a received
   PathErr message. 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
   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
   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
   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
   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
   requests.  A reroute request is indicated by in a received PathErr
   message which carries one of the error code and value
   of "Notify/Local (link or node) maintenance required" combinations
   listed above in Section 2.1.  Note that a received
   PathErr message. conformant implementation
   MUST check for any of the the three combinations listed in Section

   Upon receiving a reroute request, the ingress MUST attempt to
   identify an alternate path, avoiding the node, interface, resource,
   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 make-before-break procedures MUST
   be followed.

3. IANA Considerations

   No new

   IANA administered values are is requested by to administer assignment of new values for
   namespaces defined in this document. 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

      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

   This document introduces no new security considerations as this
   document describes usage of existing formats and mechanisms.  This
   document does introduce a new error code value, but this value is
   functionally equivalent to existing semantics.  The Section 9 of
   [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.1. Normative References

   [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
             "Resource ReSerVation Protocol (RSVP) -- Version 1,
             Functional Specification", RFC 2205, September 1997.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels," RFC 2119.

   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
             Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
             to RSVP for LSP Tunnels", RFC 3209, December 2001.

   [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
             Switching (GMPLS) Signaling - Resource ReserVation
             Protocol-Traffic Engineering (RSVP-TE) Extensions",
             RFC 3473, January 2003.

   [RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions for
             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

   [RFC4736] Vasseur, JP., et al, "Reoptimization of Multiprotocol
             Label Switching (MPLS) Traffic Engineering (TE) Loosely
             Routed Label Switched Path (LSP)", RFC 4736, November

   [GRACEFUL] Ali, Z., et al., "Graceful Shutdown in MPLS and
              Generalized MPLS Traffic Engineering Networks",
              Work in Progress, January 2008
   [PATHERR] Vasseur, JP., Ed. "Node behavior upon originating and
             receiving Resource ReserVation Protocol (RSVP) Path
             Error message", draft-ietf-mpls-3209-patherr-02.txt, draft-ietf-mpls-3209-patherr-03.txt,
             Work in Progress, February August 2008.

   [PREEMPTION] Meyer, M., Ed. "MPLS Traffic Engineering Soft
                Preemption", draft-ietf-mpls-soft-preemption-10.txt, draft-ietf-mpls-soft-preemption-12.txt,
                Work in Progress, February September 2008.

6. Acknowledgments

   This document was conceived along with Matthew Meyer.

7. Author's Addresses

   Lou Berger
   LabN Consulting, L.L.C.
   Phone: +1-301-468-9228
   Dimitri Papadimitriou
   Alcatel Lucent
   Francis Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240-8491

   JP Vasseur
   Cisco Systems, Inc
   1414 Massachusetts Avenue
   Boxborough, MA  01719

8. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

9. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to rights
   in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Generated on: Tue Aug 5 17:48:17 Sep 2 13:05:25 EDT 2008