One document matched: draft-atlas-mpls-te-express-path-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY I-D.ietf-ospf-te-metric-extensions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-te-metric-extensions.xml">
<!ENTITY I-D.previdi-isis-te-metric-extensions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.previdi-isis-te-metric-extensions.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC5420 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5420.xml">
<!ENTITY RFC3246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3246.xml">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-atlas-mpls-te-express-path-02" ipr="trust200902" >
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="MPLS-TE-Express-Path">Performance-based Path Selection for Explicitly Routed LSPs</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Alia Atlas" initials="A.K.A." surname="Atlas">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>akatlas@juniper.net</email>
</address>
</author>
<author fullname="John Drake" initials="J.D." surname="Drake">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>jdrake@juniper.net</email>
</address>
</author>
<author fullname="Spencer Giacalone" initials="S.G." surname="Giacalone">
<organization>Thomson Reuters</organization>
<address>
<postal>
<street>195 Broadway</street>
<city>New York</city>
<region>NY</region>
<code>10007</code>
<country>USA</country>
</postal>
<email>Spencer.giacalone@thomsonreuters.com</email>
</address>
</author>
<author fullname="Dave Ward" initials="D.W." surname="Ward">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dward@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S.P." surname="Previdi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Via Del Serafico 200</street>
<city>Rome</city>
<code>00142</code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Clarence Filsfils" initials="C.F." surname="Filsfils">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Brussels</city>
<country>Belgium</country>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>
<date year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <xref
target="I-D.ietf-ospf-te-metric-extensions"/> and in ISIS <xref
target="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 <xref target="RFC3209"/>. The method suggested
is not optimal for both minimizing path cost and additional
constraints, such as latency; optimal solutions are computationally
complex.</t>
<t>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.</t>
<!--
<t>If there are use-cases where loose EROs are desired, then the
performance-related constraints can be signaled in new TLVs in the
LSP_REQUIRED_ATTRIBUTES<xref target="RFC5420"/>. Each LSR would
receive the constraints, make its path selection decision, and
update the associated TLVs with the reduced constraint.</t> -->
<t>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<xref
target="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.</t>
<t>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
Engineering Database so that a CSPF calculation can also determine
whether a path under consideration would be in compliance.</t>
<section title="Basic Requirements">
<t>The following are the requirements that motivate this solution.</t>
<t><list style="numbers">
<t>Select a TE tunnel's path based upon a combination of existing
constraints as well as on link-latency, packet loss, jitter, link SLA
conformance, and bandwidth consumed by non-RSVP-TE traffic.</t>
<t>Ability to define different end-to-end performance requirements
for each TE tunnel regardless of common use of resources.</t>
<t>Ability to periodically verify that a TE tunnel's current LSP
complies with its configured end-to-end perforance requirements.</t>
<t>Ability to move tunnels, using make-before-break, based upon
computed end-to-end performance complying with configuration</t>
<t>Ability to move tunnels away from any link that is violating an underlying SLA</t>
<t>Ability to optionally avoid setting up tunnels using any link that
is violating an SLA, regardless of whether end-to-end performance
would still meet requirements.</t>
<t>Ability to revert back to the best path after a configurable period.</t>
</list></t>
</section>
</section>
<section title="Using Performance Data Constraints" >
<section title="End-to-End Constraints">
<t>The per-link performance data available in the IGP <xref
target="I-D.ietf-ospf-te-metric-extensions"/> <xref
target="I-D.previdi-isis-te-metric-extensions" /> includes:
unidirectional link delay, unidirectional delay variation, and link
loss. Each (or all) of these parameters can be used to create the
path-level link-based parameter.</t>
<t>While it has been possible to compute a CSPF where the link latency
values are used instead of TE metrics, this results in ignoring the TE
metrics and causing LSPs to prefer the lowest-latency paths. Instead
of this approach to minimize path latency, an end-to-end latency bound
merely requires that the path computed be no more than that bound
without being the minimum. This bound can be used as a constraint in
CSPF to prevent exploring links that would create a path over the
end-to-end latency bound.</t>
<t>This is illustrated as follows. Let the LSP have an end-to-end
latency bound of 20ms. Assume that the path to node X has been
minimized and its latency is 12ms. When X's links are to be explored,
the link X<->Y has a link latency of 5ms and the link
X<->Z has a link latency of 9ms. The path via X to Y along link
X<->Y would have a path latency of 12ms + 5ms = 17ms < 20ms;
therefore, the link X<->Y can be explored. In contrast,
reaching Z via link X<->Z would result in a path latency of 12ms
+ 9ms = 21ms > 20ms; therefore the link X<->Z would not be
explored in the CSPF.</t>
<t>An end-to-end bound on delay variation can be used similarly as a
constraint in the CSPF on what links to explore where the path's delay
variation is the sum of the used links' delay variations.</t>
<t>For link loss, the path loss is not the sum of the used links'
losses. Instead, the path loss percentage is (100 - loss_L1)*(100 -
loss_L2)*...*(100 - loss_Ln), where the links along the path are L1 to
Ln. The end-to-end link loss bound, computed in this fashion, can
also be used as a constraint in the CSPF on what links to explore.</t>
</section>
<section title="Link Constraints">
<t>In addition to selecting paths that conform to a bound on
performance data, it is also useful to avoid using links that do not
meet a necessary constraint. Naturally, if such a parameter were a
known fixed value, then resource attribute flags could be used to
express this behavior. However, when the parameter associated with a
link may vary dynamically, there is not currently a configuration-time
mechanism to enforce such behavior. An example of this is described
in <xref target="Anomalous links"/>, where links may move in and out
of SLA-conformance with regards to latency, delay variation, and link
loss.</t>
<t>When doing path selection for TE tunnels, it has not been possible
to know how much actual bandwidth is available that inludes the
bandwidth used by non-RSVP-TE traffic. In <xref
target="I-D.ietf-ospf-te-metric-extensions"/> <xref
target="I-D.previdi-isis-te-metric-extensions" />, the Unidirectional
Available Bandwidth is advertised as is the Residual Bandwidth. When
computing the path for a TE tunnel, only links with at least a
configurable amount of Unidirectional Available Bandwidth might be
permitted.</t>
<t>Similarly, only links whose loss is under a configurable value
might be acceptable. For these constraints, each link can be tested
against the constraint and only explored in the CSPF if the link
passes. In essence, a link that fails the constraint test is treated
as if it contained a resource attribute in the exclude-any filter.</t>
</section>
<section anchor="Anomalous links" title="Links out of SLA">
<t>Link conformance to an SLA can change as a result of
rerouting at lower layers. This could be due to optical regrooming or
simply rerouting of a FA-LSP. When this occurs, there are three
questions to be asked:</t>
<t><list style="letters">
<t>Should the link be trusted and used for the setup of new LSPs?</t>
<t>Should LSPs using this link be immediately verified for continued
compliance to their end-to-end constraints?</t>
<t>Should LSPs using this link automatically be moved to a secondary
path?</t>
</list></t>
<section title="Use of Anomalous Links for New Paths">
<t>If the answer to (a) is no for latency SLAs, then any link which
has the Anomalous bit set in the Unidirectional Link Delay
sub-TLV<xref target="I-D.ietf-ospf-te-metric-extensions"/> <xref
target="I-D.previdi-isis-te-metric-extensions" /> should be removed
from the topology before a CSPF calculation is used to compute a new path. In
essence, the link should be treated exactly as if it fails the
exclude-any resource attributes filter.<xref target="RFC3209"/>.</t>
<t>Similarly, if the answer to (a) is no for link loss SLAs, then any
link which has the Anomalous bit set in the Link Los sub-TLV should be
treated as if it fails the exclude-any resource attributes filter. If
the answer to (a) is no for jitter SLAs, then any link that has the
Anomalous bit set in the Unidirectional Delay Variation sub-TLV<xref
target="I-D.previdi-isis-te-metric-extensions" /> should be treated as
if it fails the exclude-any resource attributes filter.</t>
</section>
<section title="Links entering the Anomalous State">
<t>When a link enters the Anomalous state with respect to a parameter,
this is an indication that LSPs using that link might also no longer
be in compliance with their performance bounds. It can also be
considered an indication that something is changing that link and so
it might no longer be trustworthy to carry performance-critical
traffic. Naturally, which performance criteria are important for a
particular LSP is dependent upon the LSP's configuration and thus the
SLA compliance of a link is indicated per performance criterion.</t>
<t>At the ingress of a TE tunnel, a TE tunnel may be configured to be
sensitive to the Anomalous state of links in reference to latency,
delay variation, and/or loss. Additionally, such a TE tunnel may
be configured to either verify continued compliance, to switch
immediately to a standby LSP, or to move to a different path.</t>
<t>When a sub-TLV is received with the Anomalous bit set when
previously it was clear, the list of interested TE tunnels must be
scanned. Each such TE tunnel should either have its continued
compliance verified, be switched to a hot standby, or do a
make-before-break to a secondary path.</t>
</section>
<section title="Links leaving the Anomalous State">
<t>When a link leaves the Anomalous state with respect to a parameter,
this can serve as an indication that those TE tunnels, whose LSPs were
changed when the link entered the Anomalous state, may want to reoptimize
to a better path.</t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document is not currently believed to introduce new security concerns.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References">
&RFC3209;
&I-D.ietf-ospf-te-metric-extensions;
&I-D.previdi-isis-te-metric-extensions;
</references>
<references title="Informative References">
&RFC3246;
&RFC5420;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 03:37:41 |