Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering
RFC 4829
Document | Type | RFC - Informational (April 2007; No errata) | |
---|---|---|---|
Authors | Vasseur Jp , Caterina Scoglio , Leonardo Chen , Jaudelice Oliveira | ||
Last updated | 2013-03-02 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4829 (Informational) | |
Action Holders |
(None)
|
||
Telechat date | |||
Responsible AD | Ross Callon | ||
Send notices to | jau@ece.gatech.edu |
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 givenShow full document text