Performance-based Path Selection for Explicitly Routed LSPs

The information below is for an old version of the document
Document Type Active Internet-Draft (mpls WG)
Last updated 2013-04-06 (latest revision 2013-02-06)
Replaced by draft-ietf-mpls-te-express-path
Stream IETF
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream WG state (None)
Document shepherd None
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
MPLS Working Group                                              A. Atlas
Internet-Draft                                                  J. Drake
Intended status: Informational                          Juniper Networks
Expires: August 10, 2013                                    S. Giacalone
                                                         Thomson Reuters
                                                                 D. Ward
                                                              S. Previdi
                                                             C. Filsfils
                                                           Cisco Systems
                                                        February 6, 2013

      Performance-based Path Selection for Explicitly Routed LSPs


   In certain networks, it is critical to consider network performance
   criteria when selecting the path for an explicitly routed RSVP-TE
   LSP.  Such performance criteria can include latency, jitter, and loss
   or other indications such as the conformance to link SLAs and non-
   RSVP TE traffic load.  This specification uses IGP extension data
   (which is defined outside the scope of this document) to perform such
   path selections.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 10, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

Atlas, et al.            Expires August 10, 2013                [Page 1]
Internet-Draft            MPLS-TE-Express-Path             February 2013

   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   In certain networks, such as financial information networks, network
   performance information is becoming as critical to data path
   selection as other existing metrics.  The ability to distribute
   network performance information in OSPF
   [I-D.ietf-ospf-te-metric-extensions] and in ISIS
   [I-D.previdi-isis-te-metric-extensions] is being defined (outside the
   scope of this document).  This document describes how to use that
   information for path selection for explicitly routed LSPs signaled
   via RSVP-TE [RFC3209].  The method suggested is not optimal for both
   minimizing path cost and additional constraints, such as latency;
   optimal solutions are computationally complex.

   The path selection mechanisms described in this document apply to
   paths that are fully computed by the head-end of the LSP and then
   signaled in an ERO where every sub-object is strict.  This allows the
   head-end to consider IGP-distributed performance data without
   requiring the ability to signal the performance constraints in an
   object of the RSVP Path message.

   When considering performance-based data, it is obvious that there are
   additional contributors beyond just the links.  Clearly end-to-end
   latency is a combination of router latency, queuing latency, physical
   link latency and other factors.  However, if application traffic
   requires paths to be selected based upon latency constraints, the
   same traffic might be in an Expedited Forwarding Per-Hop-
   Behavior[RFC3246] with minimal queuing delay or another PHB with
   known maximal per-hop queuing delay.  While traversing a router can
   cause delay, that can be included in the advertised link delay.

   This document does not specify how a router determines what values to
   advertise by the IGP.  However, the end-to-end performance that is
   computed for an LSP path SHOULD be built from the individual link
   data.  Any end-to-end characterization used to determine an LSP's
   performance compliance should be fully reflected in the Traffic
Show full document text