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 20071. 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
datatracker.ietf.org