Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)
RFC 4736

Network Working Group                                   JP. Vasseur, Ed.
Request for Comments: 4736                           Cisco Systems, Inc.
Category: Informational                                       Y. Ikejiri
                                          NTT Communications Corporation
                                                                R. Zhang
                                                              BT Infonet
                                                           November 2006

     Reoptimization of Multiprotocol Label Switching (MPLS) Traffic
       Engineering (TE) Loosely Routed Label Switched Path (LSP)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   This document defines a mechanism for the reoptimization of loosely
   routed MPLS and GMPLS (Generalized Multiprotocol Label Switching)
   Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with
   Resource Reservation Protocol Traffic Engineering (RSVP-TE).  This
   document proposes a mechanism that allows a TE LSP head-end Label
   Switching Router (LSR) to trigger a new path re-evaluation on every
   hop that has a next hop defined as a loose or abstract hop and a
   mid-point LSR to signal to the head-end LSR that a better path exists
   (compared to the current path) or that the TE LSP must be reoptimized
   (because of maintenance required on the TE LSP path).  The proposed
   mechanism applies to the cases of intra- and inter-domain (Interior
   Gateway Protocol area (IGP area) or Autonomous System) packet and
   non-packet TE LSPs following a loosely routed path.

Vasseur, et al.              Informational                      [Page 1]
RFC 4736               MPLS-TE Loosely Routed LSP          November 2006

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
      2.1. Requirements Language ......................................4
   3. Establishment of a Loosely Routed TE LSP ........................4
   4. Reoptimization of a Loosely Routed TE LSP Path ..................6
   5. Signaling Extensions ............................................7
      5.1. Path Re-Evaluation Request .................................7
      5.2. New Error Value Sub-Codes ..................................7
   6. Mode of Operation ...............................................7
      6.1. Head-End Reoptimization Control ............................7
      6.2. Reoptimization Triggers ....................................8
      6.3. Head-End Request versus Mid-Point Explicit
           Notification Functions .....................................8
           6.3.1. Head-End Request Function ...........................8
           6.3.2. Mid-Point Explicit Notification ....................10
           6.3.3. ERO Caching ........................................10
   7. Applicability and Interoperability .............................11
   8. IANA Considerations ............................................11
   9. Security Considerations ........................................11
   10. Acknowledgements ..............................................12
   11. References ....................................................12
      11.1. Normative References .....................................12
      11.2. Informative References ...................................12

Vasseur, et al.              Informational                      [Page 2]
RFC 4736               MPLS-TE Loosely Routed LSP          November 2006

1.  Introduction

   This document defines a mechanism for the reoptimization of loosely
   routed MPLS and GMPLS (Generalized Multiprotocol Label Switching)
   Traffic Engineering LSPs signaled with RSVP-TE (see [RFC3209] and
   [RFC3473]).  A loosely routed LSP is defined as one that does not
   contain a full, explicit route identifying each LSR along the path of
   the LSP at the time it is signaled by the ingress LSR.  Such an LSP
   is signaled with no Explicit Route Object (ERO), with an ERO that
   contains at least one loose hop, or with an ERO that contains an
   abstract node that is not a simple abstract node (that is, an
   abstract node that identifies more than one LSR).

   The Traffic Engineering Working Group (TE WG) has specified a set of
   requirements for inter-area and inter-AS MPLS Traffic Engineering
   (see [RFC4105] and [RFC4216]).  Both requirements documents specify
   the need for some mechanism providing an option for the head-end LSR
   to control the reoptimization process should a more optimal path