Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering
RFC 4829

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Network Working Group                                J. de Oliveira, Ed.
Request for Comments: 4829                             Drexel University
Category: Informational                                 JP. Vasseur, Ed.
                                                     Cisco Systems, Inc.
                                                                 L. Chen
                                                    Verizon Laboratories
                                                              C. Scoglio
                                                 Kansas State University
                                                              April 2007

           Label Switched Path (LSP) Preemption Policies for
                        MPLS Traffic Engineering

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 (2007).

IESG Note

   This RFC is not a candidate for any level of Internet Standard.  The
   IETF disclaims any knowledge of the fitness of this RFC for any
   purpose and, in particular, notes that the decision to publish is not
   based on IETF review for such things as security, congestion control,
   or inappropriate interaction with deployed protocols.  The RFC Editor
   has chosen to publish this document at its discretion.  Readers of
   this document should exercise caution in evaluating its value for
   implementation and deployment.  See RFC 3932 for more information.

Abstract

   When the establishment of a higher priority (Traffic Engineering
   Label Switched Path) TE LSP requires the preemption of a set of lower
   priority TE LSPs, a node has to make a local decision to select which
   TE LSPs will be preempted.  The preempted LSPs are then rerouted by
   their respective Head-end Label Switch Router (LSR).  This document
   presents a flexible policy that can be used to achieve different
   objectives: preempt the lowest priority LSPs; preempt the minimum
   number of LSPs; preempt the set of TE LSPs that provide the closest
   amount of bandwidth to the required bandwidth for the preempting TE
   LSPs (to minimize bandwidth wastage); preempt the LSPs that will have
   the maximum chance to get rerouted.  Simulation results are given and

de Oliveira, et al.          Informational                      [Page 1]
RFC 4829          LSP Preemption Policies for MPLS-TE         April 2007

   a comparison among several different policies, with respect to
   preemption cascading, number of preempted LSPs, priority, wasted
   bandwidth and blocking probability is also included.

Table of Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  LSP Setup Procedure and Preemption . . . . . . . . . . . . . .  5
   4.  Preemption Cascading . . . . . . . . . . . . . . . . . . . . .  6
   5.  Preemption Heuristic . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Preempting Resources on a Path . . . . . . . . . . . . . .  7
     5.2.  Preemption Heuristic Algorithm . . . . . . . . . . . . . .  8
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Simple Case: Single Link . . . . . . . . . . . . . . . . . 10
     6.2.  Network Case . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 17

de Oliveira, et al.          Informational                      [Page 2]
RFC 4829          LSP Preemption Policies for MPLS-TE         April 2007

1.  Motivation

   The IETF Traffic Engineering Working Group has defined the
   requirements and protocol extensions for DiffServ-aware MPLS Traffic
   Engineering (DS-TE) [RFC3564] [RFC4124].  Several Bandwidth
   Constraint models for use with DS-TE have been proposed [RFC4127]
   [RFC4128] [RFC4126] and their performance was analyzed with respect
   to the use of preemption.

   Preemption can be used as a tool to help ensure that high priority
   LSPs can always be routed through relatively favorable paths.
   Preemption can also be used to implement various prioritized access
   policies as well as restoration policies following fault events
   [RFC2702].

   Although not a mandatory attribute in the traditional IP world,
   preemption becomes important in networks using online, distributed
   Constrained Shortest Path First (CSPF) strategies for their Traffic
   Engineering Label Switched Path (TE LSP) path computation to limit
   the impact of bandwidth fragmentation.  Moreover, preemption is an
   attractive strategy in an MPLS network in which traffic is treated in
   a differentiated manner and high-importance traffic may be given