draft-atlas-mpls-te-express-path-03.txt   draft-atlas-mpls-te-express-path-04.txt 
MPLS Working Group A. Atlas MPLS Working Group A. Atlas
Internet-Draft J. Drake Internet-Draft J. Drake
Intended status: Informational Juniper Networks Intended status: Informational Juniper Networks
Expires: January 13, 2014 S. Giacalone Expires: March 16, 2014 S. Giacalone
Thomson Reuters Thomson Reuters
D. Ward D. Ward
S. Previdi S. Previdi
C. Filsfils C. Filsfils
Cisco Systems Cisco Systems
July 12, 2013 September 12, 2013
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-atlas-mpls-te-express-path-03 draft-atlas-mpls-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 uses
network performance data, such as is advertised via the OSPF and ISIS network performance data, such as is advertised via the OSPF and ISIS
TE metric extensions (defined outside the scope of this document) to TE metric extensions (defined outside the scope of this document) to
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 13, 2014. This Internet-Draft will expire on March 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 3 1.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 4
1.2. Oscillation and Stability Considerations . . . . . . . . 4 1.2. Oscillation and Stability Considerations . . . . . . . . 4
2. Using Performance Data Constraints . . . . . . . . . . . . . 5 2. Using Performance Data Constraints . . . . . . . . . . . . . 5
2.1. End-to-End Constraints . . . . . . . . . . . . . . . . . 5 2.1. End-to-End Constraints . . . . . . . . . . . . . . . . . 5
2.2. Link Constraints . . . . . . . . . . . . . . . . . . . . 6 2.2. Link Constraints . . . . . . . . . . . . . . . . . . . . 6
2.3. Links out of compliance with Link Performance Objectives 7 2.3. Links out of compliance with Link Performance Objectives 6
2.3.1. Use of Anomalous Links for New Paths . . . . . . . . 7 2.3.1. Use of Anomalous Links for New Paths . . . . . . . . 7
2.3.2. Links entering the Anomalous State . . . . . . . . . 7 2.3.2. Links entering the Anomalous State . . . . . . . . . 7
2.3.3. Links leaving the Anomalous State . . . . . . . . . . 8 2.3.3. Links leaving the Anomalous State . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 2, line 36 skipping to change at page 3, line 4
2.3.3. Links leaving the Anomalous State . . . . . . . . . . 8 2.3.3. Links leaving the Anomalous State . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
In certain networks, such as financial information networks, network In certain networks, such as financial information networks, network
performance information is becoming as critical to data path performance information is becoming as critical to data path
selection as other existing metrics. Network performance information selection as other existing metrics. Network performance information
can be obtained via either the TE Metric Extensions in OSPF can be obtained via either the TE Metric Extensions in OSPF
[I-D.ietf-ospf-te-metric-extensions] or ISIS [I-D.ietf-ospf-te-metric-extensions] or ISIS
[I-D.previdi-isis-te-metric-extensions] or via a management system. [I-D.ietf-isis-te-metric-extensions] or via a management system. As
As with other TE information flooded via OSPF or ISIS, the TE metric with other TE information flooded via OSPF or ISIS, the TE metric
extensions have a flooding scope limited to the local area or level. extensions have a flooding scope limited to the local area or level.
This document describes how to use that information for path This document describes how to use that information for path
selection for explicitly routed LSPs signaled via RSVP-TE [RFC3209]. selection for explicitly routed LSPs signaled via RSVP-TE [RFC3209].
Methods of optimizing path selection for multiple parameters are Methods of optimizing path selection for multiple parameters are
generally computationally complex. The methods proposed here are to generally computationally complex. However, there are good
either make use of either a single metric in path selection, such as heuristics for the delay-constrained lowest-cost (DCLC) computation
minimal path delay, or to make use of another single metric, such as problem [k-Paths_DCLC] that can be applied to consider both path cost
the existing TE metric with additional constraints, such as target and a maximum delay bound. Some of the network performance
link delay bounds and target path delay bounds. information can also be used to prune links from a topology before
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 ERO where every sub-object is strict. This allows the
head-end to consider IGP-distributed performance data without head-end to consider IGP-distributed performance data without
requiring the ability to signal the performance constraints in an requiring the ability to signal the performance constraints in an
object of the RSVP Path message. 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 beyond just the links. Clearly end-to-end additional contributors to latency beyond just the links. Clearly
latency is a combination of router latency, queuing latency, physical end-to-end latency is a combination of router latency (e.g. latency
link latency and other factors. While traversing a router can cause from traversing a router without queueing delay), queuing latency,
delay, that can be included in the advertised link delay. As physical link latency and other factors. While traversing a router
described in [I-D.ietf-ospf-te-metric-extensions] and can cause delay, that router latency can be included in the
[I-D.previdi-isis-te-metric-extensions], queuing delay must not be advertised link delay. As described in
[I-D.ietf-ospf-te-metric-extensions] and
[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.
Queuing latency is specifically excluded to insure freedom from Queuing latency is specifically excluded to insure freedom from
oscillations and stability issues that have plagued prior attempts to oscillations and stability issues that have plagued prior attempts to
use delay as a routing metric. If application traffic which follows use delay as a routing metric. If application traffic follows a path
path based upon latency constraints, the same traffic might be in an based upon latency constraints, the same traffic might be in an
Expedited Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing Expedited Forwarding Per-Hop-Behavior [RFC3246] with minimal queuing
delay or another PHB with potentially very substantial per-hop delay or another PHB with potentially very substantial per-hop
queuing delay. Only traffic which experiences relatively low queuing delay. Only traffic which experiences relatively low
congestion, such as Expedited Forwarding traffic, will experience congestion, such as Expedited Forwarding traffic, will experience
delays very close to the sum of the reported link delays. delays very close to the sum of the reported link delays.
This document does not specify how a router determines what values to This document does not specify how a router determines what values to
advertise by the IGP; it does assume that the constraints specified advertise by the IGP; it does assume that the constraints specified
in [I-D.ietf-ospf-te-metric-extensions] and in [I-D.ietf-ospf-te-metric-extensions] and
[I-D.previdi-isis-te-metric-extensions] are followed. Additionally, [I-D.ietf-isis-te-metric-extensions] are followed. Additionally, the
the end-to-end performance that is computed for an LSP path should be end-to-end performance that is computed for an LSP path should be
built from the individual link data. Any end-to-end characterization built from the individual link data. Any end-to-end characterization
used to determine an LSP's performance compliance should be fully used to determine an LSP's performance compliance should be fully
reflected in the Traffic Engineering Database so that a CSPF reflected in the Traffic Engineering Database so that a path
calculation can also determine whether a path under consideration calculation can also determine whether a path under consideration
would be in compliance. 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 solution.
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 that a TE tunnel's current LSP 3. Ability to periodically verify with the TE LSDB that a TE
complies with its configured end-to-end performance requirements. tunnel's current LSP complies with its configured end-to-end
performance requirements.
4. Ability to move tunnels, using make-before-break, based upon 4. Ability to move tunnels, using make-before-break, based upon
computed end-to-end performance complying with constraints. computed end-to-end performance complying with constraints.
5. Ability to move tunnels away from any link that is violating an 5. Ability to move tunnels away from any link that is violating an
underlying link performance objective. underlying link performance objective.
6. Ability to optionally avoid setting up tunnels using any link 6. Ability to optionally avoid setting up tunnels using any link
that is violating a link performance objective, regardless of that is violating a link performance objective, regardless of
whether end-to-end performance would still meet requirements. whether end-to-end performance would still meet requirements.
7. Ability to revert back to the best path after a configurable 7. Ability to revert back using make-before-break to the best path
period. after a configurable period.
1.2. Oscillation and Stability Considerations 1.2. Oscillation and Stability Considerations
Past attempts to use unbounded delay or loss as metric sufferred from Past attempts to use unbounded delay or loss as metric sufferred from
severe oscillations. The use of performance based data must be such severe oscillations. The use of performance based data must be such
that undampened oscillations are not possible and stability cannot be that undampened oscillations are not possible and stability cannot be
impacted. impacted.
The use of timers is often cited as a cure. Oscillation that is The use of timers is often cited as a cure. Oscillation that is
damped by timers is known as "slosh". If advertisement timers are damped by timers is known as "slosh". If advertisement timers are
skipping to change at page 5, line 13 skipping to change at page 5, line 35
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.
2. Using Performance Data Constraints 2. Using Performance Data Constraints
2.1. End-to-End Constraints 2.1. End-to-End Constraints
The per-link performance data available in the IGP The per-link performance data available in the IGP
[I-D.ietf-ospf-te-metric-extensions] [I-D.ietf-ospf-te-metric-extensions]
[I-D.previdi-isis-te-metric-extensions] includes: unidirectional link [I-D.ietf-isis-te-metric-extensions] includes: unidirectional link
delay, unidirectional delay variation, and link loss. Each (or all) delay, unidirectional delay variation, and link loss. Each (or all)
of these parameters can be used to create the path-level link-based of these parameters can be used to create the path-level link-based
parameter. parameter.
It is possible to compute a CSPF where the link latency values are It is possible to compute a CSPF where the link latency values are
used instead of TE metrics, this results in ignoring the TE metrics used instead of TE metrics, this results in ignoring the TE metrics
and causing LSPs to prefer the lowest-latency paths. An alternative and causing LSPs to prefer the lowest-latency paths. In practical
to this approach to minimize path latency is an approach to place an scenarios, latency constraints are typically a bound constraint
upper bound on path latency. An end-to-end latency upper bound rather than a minimization objective. An end-to-end latency upper
merely requires that the path computed be no more than that bound and bound merely requires that the path computed be no more than that
does not require that it be the minimum latency path. This upper bound and does not require that it be the minimum latency path. The
bound can be used as a constraint in CSPF to prevent exploring links latter is exactly the delay-constrained lowest-cost (DCLC) problem to
that would create a path over the end-to-end latency bound. Both which good heuristics have been proposed in the literature (e.g.
approaches are valid. [k-Paths_DCLC]).
Basic pseudo-code to further explain this pruning is given below.
The change is to decide whether to explore a link based on whether
the resulting path would violate the specified latency-bound and to
accumulate the latency used along the path.
CSPF_with_bound(root, latency_bound)
root.distance = 0
root.latency = 0
fibheap_insert(root, root.distance)
while (fibheap_not_empty())
next_rtr = fibheap_pop
for each link next_link attached to next_rtr
if (next_rtr.latency + next_link.latency) < latency_bound
explore_link(next_rtr, next_link)
Explore_Link(next_rtr, next_link)
if ((next_rtr.distance + next_link.metric) <
next_link->neighbor.distance)
next_link->neighbor.distance = next_rtr.distance +
next_link.metric
next_link->neighbor.latency = next_rtr.latency +
next_link.latency
if ((next_rtr.distance + next_link.metric) ==
next_link->neighbor.distance)
if ((next_rtr.latency + next_link.latency) <
next_link->neighbor.latency)
next_link->neighbor.latency = next_rtr.latency +
next_link.latency
Partial Pseudo-Code for latency-pruned SPF
An end-to-end bound on delay variation can be used similarly as a 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 constraint in the path computation on what links to explore where the
delay variation is the sum of the used links' delay variations. path's delay variation is the sum of the used links' delay
variations.
For link loss, the path loss is not the sum of the used links' For link loss, the path loss is not the sum of the used links'
losses. Instead, the path loss percentage is 100 - (100 - losses. Instead, the path loss percentage is 100 - (100 -
loss_L1)*(100 - loss_L2)*...*(100 - loss_Ln), where the links along 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 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 this fashion, can also be used as a constraint in the path
links to explore. computation.
The heuristic algorithms for DCLC only address one constraint bound
but having a CSPF that limits the paths explored (i.e. based on hop-
count) can be combined [hop-count_DCLC].
2.2. Link Constraints 2.2. Link Constraints
In addition to selecting paths that conform to a bound on performance 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 data, it is also useful to avoid using links that do not meet a
necessary constraint. Naturally, if such a parameter were a known necessary constraint. Naturally, if such a parameter were a known
fixed value, then resource attribute flags could be used to express fixed value, then resource attribute flags could be used to express
this behavior. However, when the parameter associated with a link this behavior. However, when the parameter associated with a link
may vary dynamically, there is not currently a configuration-time may vary dynamically, there is not currently a configuration-time
mechanism to enforce such behavior. An example of this is described mechanism to enforce such behavior. An example of this is described
in Section 2.3, where links may move in and out of conformance for in Section 2.3, where links may move in and out of conformance for
link performance objectives with regards to latency, delay variation, link performance objectives with regards to latency, delay variation,
and link loss. and link loss.
When doing path selection for TE tunnels, it has not been possible to When doing path selection for TE tunnels, it has not been possible to
know how much actual bandwidth is available that includes the know how much actual bandwidth is available that includes the
bandwidth used by non-RSVP-TE traffic. In bandwidth used by non-RSVP-TE traffic. In
[I-D.ietf-ospf-te-metric-extensions] [I-D.ietf-ospf-te-metric-extensions]
[I-D.previdi-isis-te-metric-extensions], the Unidirectional Available [I-D.ietf-isis-te-metric-extensions], the Unidirectional Available
Bandwidth is advertised as is the Residual Bandwidth. When computing Bandwidth is advertised as is the Residual Bandwidth. When computing
the path for a TE tunnel, only links with at least a configurable the path for a TE tunnel, only links with at least a minimum amount
amount of Unidirectional Available Bandwidth might be permitted. of Unidirectional Available Bandwidth might be permitted.
Similarly, only links whose loss is under a configurable value might Similarly, only links whose loss is under a configurable value might
be acceptable. For these constraints, each link can be tested be acceptable. For these constraints, each link can be tested
against the constraint and only explored in the CSPF if the link against the constraint and only explored in the path computation if
passes. In essence, a link that fails the constraint test is treated the link passes. In essence, a link that fails the constraint test
as if it contained a resource attribute in the exclude-any filter. is treated as if it contained a resource attribute in the exclude-any
filter.
2.3. Links out of compliance with Link Performance Objectives 2.3. Links out of compliance with Link Performance Objectives
Link conformance to a link performance objective can change as a Link conformance to a link performance objective can change as a
result of rerouting at lower layers. This could be due to optical result of rerouting at lower layers. This could be due to optical
regrooming or simply rerouting of a FA-LSP. When this occurs, there regrooming or simply rerouting of a FA-LSP. When this occurs, there
are two questions to be asked: are two questions to be asked:
a. Should the link be trusted and used for the setup of new LSPs? a. Should the link be trusted and used for the setup of new LSPs?
b. Should LSPs using this link automatically be moved to a secondary b. Should LSPs using this link automatically be moved to a secondary
path? path?
skipping to change at page 7, line 22 skipping to change at page 7, line 19
a. Should the link be trusted and used for the setup of new LSPs? a. Should the link be trusted and used for the setup of new LSPs?
b. Should LSPs using this link automatically be moved to a secondary b. Should LSPs using this link automatically be moved to a secondary
path? path?
2.3.1. Use of Anomalous Links for New Paths 2.3.1. Use of Anomalous Links for New Paths
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[I-D.ietf-ospf-te-metric-extensions] Link Delay sub-TLV[I-D.ietf-ospf-te-metric-extensions]
[I-D.previdi-isis-te-metric-extensions] should be removed from the [I-D.ietf-isis-te-metric-extensions] should be removed from the
topology before a CSPF calculation is used to compute a new path. In topology before a path calculation is used to compute a new path. In
essence, the link should be treated exactly as if it fails the essence, the link should be treated exactly as if it fails the
exclude-any resource attributes filter.[RFC3209]. exclude-any resource attributes 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 Los sub-TLV should be treated as if it fails the exclude-any resource
attributes filter. If the answer to (a) is no for link jitter attributes filter. If the answer to (a) is no for link jitter
performance objectives, then any link that has the Anomalous bit set performance objectives, then any link that has the Anomalous bit set
in the Unidirectional Delay Variation sub- in the Unidirectional Delay Variation sub-
TLV[I-D.previdi-isis-te-metric-extensions] should be treated as if it TLV[I-D.ietf-isis-te-metric-extensions] should be treated as if it
fails the exclude-any resource attributes filter. fails the exclude-any resource attributes filter.
2.3.2. Links entering the Anomalous State 2.3.2. Links entering the Anomalous State
When a link enters the Anomalous state with respect to a parameter, 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 this is an indication that LSPs using that link might also no longer
be in compliance with their performance bounds. It can also be be in compliance with their performance bounds. It can also be
considered an indication that something is changing that link and so considered an indication that something is changing that link and so
it might no longer be trustworthy to carry performance-critical it might no longer be trustworthy to carry performance-critical
traffic. Naturally, which performance criteria are important for a traffic. Naturally, which performance criteria are important for a
skipping to change at page 8, line 46 skipping to change at page 8, line 46
The authors would like to thank Curtis Villamizar for his extensive The authors would like to thank Curtis Villamizar for his extensive
detailed comments and suggested text in the Section 1 and detailed comments and suggested text in the Section 1 and
Section 1.2. The authors would also like to thank Xiaohu Xu and Section 1.2. The authors would also like to thank Xiaohu Xu and
Sriganesh Kini for their review. Sriganesh Kini for their review.
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-isis-te-metric-extensions]
Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas,
A., and C. Filsfils, "IS-IS Traffic Engineering (TE)
Metric Extensions", draft-ietf-isis-te-metric-
extensions-00 (work in progress), June 2013.
[I-D.ietf-ospf-te-metric-extensions] [I-D.ietf-ospf-te-metric-extensions]
Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", draft-ietf-ospf-te-metric-extensions-04 (work Extensions", draft-ietf-ospf-te-metric-extensions-04 (work
in progress), June 2013. in progress), June 2013.
[I-D.previdi-isis-te-metric-extensions]
Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas,
A., and C. Filsfils, "IS-IS Traffic Engineering (TE)
Metric Extensions", draft-previdi-isis-te-metric-
extensions-03 (work in progress), February 2013.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
6.2. Informative References 6.2. Informative References
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. Behavior)", RFC 3246, March 2002.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, August Guidelines for DiffServ Service Classes", RFC 4594, August
2006. 2006.
[hop-count_DCLC]
Agrawal, H., Grah, M., and M. Gregory, "Optimization of
QoS Routing", 6th IEEE/AACIS International Conference on
Computer and Information Science 2007, 2007, <http://
ieeexplore.ieee.org/xpl/
articleDetails.jsp?arnumber=4276447>.
[k-Paths_DCLC]
Jia, Z. and P. Varaiya, "Heuristic methods for delay
constrained least cost routing using k-shortest-paths",
IEEE Transactions on Automatic Control 51(4), 2006, <http:
//paleale.eecs.berkeley.edu/~varaiya/papers_ps.dir/kdclc-
ieeev4.pdf>.
Authors' Addresses Authors' Addresses
Alia Atlas Alia Atlas
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
John Drake John Drake
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: jdrake@juniper.net Email: jdrake@juniper.net
Spencer Giacalone Spencer Giacalone
Thomson Reuters Thomson Reuters
 End of changes. 29 change blocks. 
91 lines changed or deleted 80 lines changed or added

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