draft-ietf-teas-te-express-path-03.txt   draft-ietf-teas-te-express-path-04.txt 
TEAS Working Group A. Atlas TEAS Working Group A. Atlas
Internet-Draft J. Drake Internet-Draft J. Drake
Intended status: Informational Juniper Networks Intended status: Informational Juniper Networks
Expires: January 28, 2016 S. Giacalone Expires: April 3, 2016 S. Giacalone
Unaffiliated Unaffiliated
S. Previdi S. Previdi
Cisco Systems Cisco Systems
July 27, 2015 October 1, 2015
Performance-based Path Selection for Explicitly Routed LSPs using TE Performance-based Path Selection for Explicitly Routed LSPs using TE
Metric Extensions Metric Extensions
draft-ietf-teas-te-express-path-03 draft-ietf-teas-te-express-path-04
Abstract Abstract
In certain networks, it is critical to consider network performance In certain networks, it is critical to consider network performance
criteria when selecting the path for an explicitly routed RSVP-TE criteria when selecting the path for an explicitly routed RSVP-TE
LSP. Such performance criteria can include latency, jitter, and loss LSP. Such performance criteria can include latency, jitter, and loss
or other indications such as the conformance to link performance or other indications such as the conformance to link performance
objectives and non-RSVP TE traffic load. This specification uses objectives and non-RSVP TE traffic load. This specification
network performance data, such as is advertised via the OSPF and ISIS describes how a path computation function may use network performance
TE metric extensions (defined outside the scope of this document) to data, such as is advertised via the OSPF and ISIS TE metric
perform such path selections. extensions (defined outside the scope of this document) to perform
such path selections.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 28, 2016. This Internet-Draft will expire on April 3, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
packet. Methods of optimizing path selection for multiple parameters packet. Methods of optimizing path selection for multiple parameters
are generally computationally complex. However, there are good are generally computationally complex. However, there are good
heuristics for the delay-constrained lowest-cost (DCLC) computation heuristics for the delay-constrained lowest-cost (DCLC) computation
problem [k-Paths_DCLC] that can be applied to consider both path cost problem [k-Paths_DCLC] that can be applied to consider both path cost
and a maximum delay bound. Some of the network performance and a maximum delay bound. Some of the network performance
information can also be used to prune links from a topology before information can also be used to prune links from a topology before
computing the path. computing the path.
The path selection mechanisms described in this document apply to The path selection mechanisms described in this document apply to
paths that are fully computed by the head-end of the LSP and then 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 signaled in an Explicit Route Object (ERO) where every sub-object is
head-end to consider IGP-distributed performance data without strict. This allows the head-end to consider IGP-distributed
requiring the ability to signal the performance constraints in an performance data without requiring the ability to signal the
object of the RSVP Path message. performance constraints in an object of the RSVP Path message.
When considering performance-based data, it is obvious that there are When considering performance-based data, it is obvious that there are
additional contributors to latency beyond just the links. Clearly additional contributors to latency beyond just the links. Clearly
end-to-end latency is a combination of router latency (e.g. latency end-to-end latency is a combination of router latency (e.g. latency
from traversing a router without queueing delay), queuing latency, from traversing a router without queueing delay), queuing latency,
physical link latency and other factors. While traversing a router physical link latency and other factors. While traversing a router
can cause delay, that router latency can be included in the can cause delay, that router latency can be included in the
advertised link delay. As described in [RFC7471] and advertised link delay. As described in [RFC7471] and
[I-D.ietf-isis-te-metric-extensions], queuing delay must not be [I-D.ietf-isis-te-metric-extensions], queuing delay must not be
included in the measurements advertised by OSPF or ISIS. included in the measurements advertised by OSPF or ISIS.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
in [RFC7471] and [I-D.ietf-isis-te-metric-extensions] are followed. in [RFC7471] and [I-D.ietf-isis-te-metric-extensions] are followed.
Additionally, the end-to-end performance that is computed for an LSP Additionally, the end-to-end performance that is computed for an LSP
path should be built from the individual link data. Any end-to-end path should be built from the individual link data. Any end-to-end
characterization used to determine an LSP's performance compliance characterization used to determine an LSP's performance compliance
should be fully reflected in the Traffic Engineering Database so that should be fully reflected in the Traffic Engineering Database so that
a path calculation can also determine whether a path under a path calculation can also determine whether a path under
consideration would be in compliance. consideration would be in compliance.
1.1. Basic Requirements 1.1. Basic Requirements
The following are the requirements that motivate this solution. The following are the requirements that motivate this document.
1. Select a TE tunnel's path based upon a combination of existing 1. Select a TE tunnel's path based upon a combination of existing
constraints as well as on link-latency, packet loss, jitter, link constraints as well as on link-latency, packet loss, jitter, link
performance objectives conformance, and bandwidth consumed by performance objectives conformance, and bandwidth consumed by
non-RSVP-TE traffic. non-RSVP-TE traffic.
2. Ability to define different end-to-end performance requirements 2. Ability to define different end-to-end performance requirements
for each TE tunnel regardless of common use of resources. for each TE tunnel regardless of common use of resources.
3. Ability to periodically verify with the TE LSDB that a TE 3. Ability to periodically verify with the TE LSDB that a TE
skipping to change at page 4, line 52 skipping to change at page 4, line 52
moving back and forth) can occur. Even a partial oscillation causes moving back and forth) can occur. Even a partial oscillation causes
unnecessary reordering which is considered at least minimally unnecessary reordering which is considered at least minimally
disruptive. disruptive.
Delay variation or jitter is affected by even small traffic levels. Delay variation or jitter is affected by even small traffic levels.
At even tiny traffic levels, the probability of a queue occupancy of At even tiny traffic levels, the probability of a queue occupancy of
one can produce a measured jitter proportional to or equal to the one can produce a measured jitter proportional to or equal to the
packet serialization delay. Very low levels of traffic can increase packet serialization delay. Very low levels of traffic can increase
the probability of queue occupancies of two or three packets enough the probability of queue occupancies of two or three packets enough
to further increase the measured jitter. Because jitter measurement to further increase the measured jitter. Because jitter measurement
is extremely sensitive to even very low traffic levels, any use of is extremely sensitive to very low traffic levels, any use of jitter
jitter is likely to oscillate. There may be legitimate use of a is likely to oscillate. However, there may be uses of a jitter
jitter measurement in path computation that can be considered free of measurement in path computation that can be considered free of
oscillation. oscillation.
Delay measurements that are not sensitive to traffic loads may be Delay measurements that are not sensitive to traffic loads may be
safely used in path computation. Delay measurements made at the link safely used in path computation. Delay measurements made at the link
layer or measurements made at a queuing priority higher than any layer or measurements made at a queuing priority higher than any
significant traffic (such as DSCP CS7 or CS6 [RFC4594], but not CS2 significant traffic (such as DSCP CS7 or CS6 [RFC4594], but not CS2
if traffic levels at CS3 and higher or EF and AF can affect the if traffic levels at CS3 and higher or EF and AF can affect the
measurement). Making delay measurements at the same priority as the measurement). Making delay measurements at the same priority as the
traffic on affected paths is likely to cause oscillations. traffic on affected paths is likely to cause oscillations.
skipping to change at page 7, line 17 skipping to change at page 7, line 17
If the answer to (a) is no for link latency performance objectives, If the answer to (a) is no for link latency performance objectives,
then any link which has the Anomalous bit set in the Unidirectional then any link which has the Anomalous bit set in the Unidirectional
Link Delay sub-TLV[RFC7471] [I-D.ietf-isis-te-metric-extensions] Link Delay sub-TLV[RFC7471] [I-D.ietf-isis-te-metric-extensions]
should be removed from the topology before a path calculation is used should be removed from the topology before a path calculation is used
to compute a new path. In essence, the link should be treated to compute a new path. In essence, the link should be treated
exactly as if it fails the exclude-any resource attributes exactly as if it fails the exclude-any resource attributes
filter.[RFC3209]. filter.[RFC3209].
Similarly, if the answer to (a) is no for link loss performance Similarly, if the answer to (a) is no for link loss performance
objectives, then any link which has the Anomalous bit set in the Link objectives, 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 Loss sub-TLV should be treated as if it fails the exclude-any
attributes filter. If the answer to (a) is no for link jitter resource attributes filter.
performance objectives, then any link that has the Anomalous bit set
in the Unidirectional Delay Variation sub-
TLV[I-D.ietf-isis-te-metric-extensions] should be treated as if it
fails the exclude-any resource attributes filter.
2.3.2. Links entering the Anomalous State 2.3.2. Links entering the Anomalous State
When the Anomalous bit transitions from clear to set, this indicates When the Anomalous bit transitions from clear to set, this indicates
that the associated link has entered the Anomalous state with respect that the associated link has entered the Anomalous state with respect
to the associated parameter; similarly, a transition from set to to the associated parameter; similarly, a transition from set to
clear indicates that the Anomalous state has been exited for that clear indicates that the Anomalous state has been exited for that
link and associated parameter. link and associated parameter.
When a link enters the Anomalous state with respect to a parameter, When a link enters the Anomalous state with respect to a parameter,
 End of changes. 9 change blocks. 
22 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/