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
Show full document text