MPLS Working Group A. Atlas
Internet-Draft J. Drake
Intended status: Informational Juniper Networks
Expires: August 10, 2013 S. Giacalone
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
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 http://datatracker.ietf.org/drafts/current/.
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 (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
(http://trustee.ietf.org/license-info) 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.
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