Internet Engineering Task Force (IETF) A. Atlas
Request for Comments: 7823 J. Drake
Category: Informational Juniper Networks
ISSN: 2070-1721 S. Giacalone
Microsoft
S. Previdi
Cisco Systems
May 2016
Internet Engineering Task Force (IETF) A. Atlas
Request for Comments: 7823 J. Drake
Category: Informational Juniper Networks
ISSN: 2070-1721 S. Giacalone
Microsoft
S. Previdi
Cisco Systems
May 2016
Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions
使用TE度量扩展的显式路由标签交换路径（LSP）基于性能的路径选择
Abstract
摘要
In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections.
在某些网络中，当选择显式路由RSVP TE标签交换路径（LSP）时，考虑网络性能标准是至关重要的。此类性能标准可包括延迟、抖动和丢失或其他指示，如符合链路性能目标和非RSVP TE流量负载。本规范描述了路径计算功能如何使用网络性能数据，例如通过OSPF和is-is TE度量扩展（定义在本文档范围之外）公布的数据来执行此类路径选择。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7823.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7823.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 4
1.2. Oscillation and Stability Considerations . . . . . . . . 4
2. Using Performance Data Constraints . . . . . . . . . . . . . 5
2.1. End-to-End Constraints . . . . . . . . . . . . . . . . . 5
2.2. Link Constraints . . . . . . . . . . . . . . . . . . . . 6
2.3. Links out of Compliance with Link Performance Objectives 6
2.3.1. Use of Anomalous Links for New Paths . . . . . . . . 7
2.3.2. Links Entering the Anomalous State . . . . . . . . . 7
2.3.3. Links Leaving the Anomalous State . . . . . . . . . . 8
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Normative References . . . . . . . . . . . . . . . . . . 8
4.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 4
1.2. Oscillation and Stability Considerations . . . . . . . . 4
2. Using Performance Data Constraints . . . . . . . . . . . . . 5
2.1. End-to-End Constraints . . . . . . . . . . . . . . . . . 5
2.2. Link Constraints . . . . . . . . . . . . . . . . . . . . 6
2.3. Links out of Compliance with Link Performance Objectives 6
2.3.1. Use of Anomalous Links for New Paths . . . . . . . . 7
2.3.2. Links Entering the Anomalous State . . . . . . . . . 7
2.3.3. Links Leaving the Anomalous State . . . . . . . . . . 8
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Normative References . . . . . . . . . . . . . . . . . . 8
4.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
In certain networks, such as financial information networks, network performance information is becoming as critical to data-path selection as other existing metrics. Network performance information can be obtained via either the TE Metric Extensions in OSPF [RFC7471] or IS-IS [RFC7810] or via a management system. As with other TE information flooded via OSPF or IS-IS, the TE metric extensions have a flooding scope limited to the local area or level. This document describes how a path computation function, whether in an ingress LSR or a PCE [RFC4655], can use that information for path selection for explicitly routed LSPs. The selected path may be signaled via RSVP-TE [RFC3209] [RFC3473] or simply used by the ingress with segment
在某些网络（如金融信息网络）中，网络性能信息对数据路径选择的重要性与其他现有指标一样。网络性能信息可以通过OSPF[RFC7471]或IS-IS[RFC7810]中的TE度量扩展或通过管理系统获得。与通过OSPF或IS-IS淹没的其他TE信息一样，TE度量扩展的淹没范围仅限于本地区域或级别。本文档描述了路径计算函数（无论是在入口LSR还是PCE[RFC4655]中）如何将该信息用于显式路由LSP的路径选择。所选路径可通过RSVP-TE[RFC3209][RFC3473]发出信号，或仅由具有段的入口使用
routing [SEG-ROUTE-MPLS] to properly forward the packet. Methods of optimizing path selection for multiple parameters are generally computationally complex. However, there are good heuristics for the delay-constrained lowest-cost (DCLC) computation problem [k-Paths_DCLC] that can be applied to consider both path cost and a maximum delay bound. Some of the network performance information can also be used to prune links from a topology before computing the path.
路由[SEG-ROUTE-MPLS]以正确转发数据包。多参数路径选择的优化方法通常计算复杂。然而，对于延迟约束的最低成本（DCLC）计算问题[K-PosisS.DCLC ]有很好的启发，可以应用于考虑路径代价和最大延迟界。在计算路径之前，还可以使用一些网络性能信息来修剪拓扑中的链接。
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 Explicit Route Object (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.
本文档中描述的路径选择机制适用于由LSP的前端完全计算的路径，然后在每个子对象都严格的显式路由对象（ERO）中发出信号。这允许头端考虑IGP分布式性能数据，而不需要在RSVP路径消息的对象中指示性能约束的能力。
When considering performance-based data, it is obvious that there are additional contributors to latency beyond just the links. Clearly end-to-end latency is a combination of router latency (e.g., latency from traversing a router without queueing delay), queuing latency, physical link latency, and other factors. While traversing a router can cause delay, that router latency can be included in the advertised link delay. As described in [RFC7471] and [RFC7810], queuing delay must not be included in the measurements advertised by OSPF or IS-IS.
在考虑基于性能的数据时，很明显，除了链接之外，还有其他因素会影响延迟。显然，端到端延迟是路由器延迟（例如，无排队延迟穿越路由器的延迟）、排队延迟、物理链路延迟和其他因素的组合。当穿越路由器可能导致延迟时，路由器延迟可以包括在公布的链路延迟中。如[RFC7471]和[RFC7810]所述，OSPF或IS-IS公布的测量中不得包括排队延迟。
Queuing latency is specifically excluded to insure freedom from oscillations and stability issues that have plagued prior attempts to use delay as a routing metric. If application traffic follows a path based upon latency constraints, the same traffic might be in an Expedited Forwarding Per-Hop Behavior (PHB) [RFC3246] with minimal queuing delay or another PHB with potentially very substantial per-hop queuing delay. Only traffic that experiences relatively low congestion, such as Expedited Forwarding traffic, will experience delays very close to the sum of the reported link delays.
排队等待时间被特别排除在外，以确保不受振荡和稳定性问题的影响，这些问题困扰着以前使用延迟作为路由度量的尝试。如果应用程序流量遵循基于延迟约束的路径，则相同的流量可能在具有最小排队延迟的加速每跳转发行为（PHB）[RFC3246]中，或者在具有潜在非常大每跳排队延迟的另一PHB中。只有经历相对较低拥塞的流量（如快速转发流量）才会经历非常接近报告的链路延迟总和的延迟。
This document does not specify how a router determines what values to advertise by the IGP; it does assume that the constraints specified in [RFC7471] and [RFC7810] are followed. 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 characterization used to determine an LSP's performance compliance should be fully reflected in the Traffic Engineering Database so that a path calculation can also determine whether a path under consideration would be in compliance.
本文件未规定路由器如何确定IGP公布的值；它假定遵循[RFC7471]和[RFC7810]中指定的约束。此外，为LSP路径计算的端到端性能应根据单个链路数据构建。用于确定LSP性能符合性的任何端到端特征都应充分反映在流量工程数据库中，以便路径计算也可以确定所考虑的路径是否符合要求。
The following are the requirements considered for a path computation function that uses network performance criteria.
以下是使用网络性能标准的路径计算功能的要求。
1. Select a TE tunnel's path based upon a combination of existing constraints as well as on link-latency, packet loss, jitter, conformance with link performance objectives, and bandwidth consumed by non-RSVP-TE traffic.
1. 基于现有约束的组合以及链路延迟、数据包丢失、抖动、与链路性能目标的一致性以及非RSVP TE流量消耗的带宽，选择TE隧道的路径。
2. Ability to define different end-to-end performance requirements for each TE tunnel regardless of common use of resources.
2. 能够为每个TE隧道定义不同的端到端性能要求，而不考虑资源的共同使用。
3. Ability to periodically verify with the TE Link State Database (LSDB) that a TE tunnel's current LSP complies with its configured end-to-end performance requirements.
3. 能够使用TE链路状态数据库（LSDB）定期验证TE隧道的当前LSP是否符合其配置的端到端性能要求。
4. Ability to move tunnels, using make-before-break, based upon computed end-to-end performance complying with constraints.
4. 基于符合约束条件的计算端到端性能，使用先通后断的方式移动隧道的能力。
5. Ability to move tunnels away from any link that is violating an underlying link performance objective.
5. 能够将隧道从任何违反基本链路性能目标的链路移开。
6. Ability to optionally avoid setting up tunnels using any link that is violating a link performance objective, regardless of whether end-to-end performance would still meet requirements.
6. 能够选择性地避免使用任何违反链路性能目标的链路建立隧道，而不管端到端性能是否仍然满足要求。
7. Ability to revert back, using make-before-break, to the best path after a configurable period.
7. 能够使用先通后断，在可配置的时间段后恢复到最佳路径。
Past attempts to use unbounded delay or loss as a metric suffered from severe oscillations. The use of performance based data must be such that undamped oscillations are not possible and stability cannot be impacted.
过去使用无界延迟或损失作为度量标准的尝试遭受了严重的振荡。基于性能的数据的使用必须确保不可能出现无阻尼振荡，且稳定性不会受到影响。
The use of timers is often cited as a cure. Oscillation that is damped by timers is known as "slosh". If advertisement timers are very short relative to the jitter applied to RSVP-TE Constrained Shortest Path First (CSPF) timers, then a partial oscillation occurs. If RSVP-TE CSPF timers are short relative to advertisement timers, full oscillation (all traffic moving back and forth) can occur. Even a partial oscillation causes unnecessary reordering that is considered at least minimally disruptive.
使用计时器经常被认为是一种治疗方法。由定时器阻尼的振荡称为“晃动”。如果广告定时器相对于应用于RSVP-TE约束最短路径优先（CSPF）定时器的抖动非常短，则会发生部分振荡。如果RSVP-TE CSPF定时器相对于广告定时器较短，则可能发生完全振荡（所有通信量来回移动）。即使是部分振荡也会导致不必要的重新排序，这至少被认为是破坏性最小的。
Delay variation or jitter is affected by even small traffic levels. At even tiny traffic levels, the probability of a queue occupancy of one can produce a measured jitter proportional to or equal to the packet serialization delay. Very low levels of traffic can increase the probability of queue occupancies of two or three packets enough to further increase the measured jitter. Because jitter measurement is extremely sensitive to very low traffic levels, any use of jitter is likely to oscillate. However, there may be uses of a jitter measurement in path computation that can be considered free of oscillation.
即使是很小的流量水平也会影响延迟变化或抖动。即使在很小的流量级别上，队列占用的概率为1，也会产生与数据包序列化延迟成比例或相等的测量抖动。非常低的流量水平会增加两个或三个数据包的队列占用概率，足以进一步增加测量的抖动。因为抖动测量对非常低的流量水平非常敏感，所以抖动的任何使用都可能发生振荡。然而，在路径计算中可能会使用抖动测量，这可以被认为是无振荡的。
Delay measurements that are not sensitive to traffic loads may be safely used in path computation. Delay measurements made at the link layer or measurements made at a queuing priority higher than any significant traffic (such as Differentiated Services Code Point (DSCP) CS7 or CS6 [RFC4594], but not CS2 if traffic levels at CS3 and higher or Expedited Forwarding and Assured Forwarding can affect the measurement). Making delay measurements at the same priority as the traffic on affected paths is likely to cause oscillations.
对交通负荷不敏感的延迟测量可以安全地用于路径计算。在链路层进行的延迟测量或在高于任何重要流量的排队优先级下进行的测量（例如，区分服务代码点（DSCP）CS7或CS6[RFC4594]，但如果CS3和更高或加速转发和保证转发的流量级别会影响测量，则不是CS2）。以与受影响路径上的流量相同的优先级进行延迟测量可能会导致振荡。
The per-link performance data available in the IGP [RFC7471] [RFC7810] 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.
IGP[RFC7471][RFC7810]中可用的每链路性能数据包括：单向链路延迟、单向延迟变化和链路丢失。这些参数中的每一个（或全部）都可用于创建基于路径级别链接的参数。
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 and causing LSPs to prefer the lowest-latency paths. In practical scenarios, latency constraints are typically a bound constraint rather than a minimization objective. An end-to-end latency upper bound merely requires that the path computed be no more than that bound and does not require that it be the minimum latency path. The latter is exactly the DCLC problem to which good heuristics have been proposed in the literature (e.g., [k-Paths_DCLC]).
可以计算使用链路延迟值而不是TE度量的CSPF；这会导致忽略TE度量，并导致LSP选择最低延迟路径。在实际场景中，延迟约束通常是有界约束，而不是最小化目标。端到端延迟上限仅要求计算的路径不超过该上限，而不要求它是最小延迟路径。后者正是文献中提出的好的启发式方法（例如[k-path_-DCLC]）的DCLC问题。
An end-to-end bound on delay variation can be used similarly as a constraint in the path computation on what links to explore where the 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'
losses. Instead, the path loss fraction is 1 - (1 - loss_L1)*
(1 - loss_L2)*...*(1 - loss_Ln), where the links along the path are
L1 to Ln with loss_Li in fractions. This computation is discussed in
For link loss, the path loss is not the sum of the used links'
losses. Instead, the path loss fraction is 1 - (1 - loss_L1)*
(1 - loss_L2)*...*(1 - loss_Ln), where the links along the path are
L1 to Ln with loss_Li in fractions. This computation is discussed in
more detail in Sections 5.1.4 and 5.1.5 in [RFC6049]. The end-to-end link loss bound, computed in this fashion, can also be used as a constraint in the path computation.
更多详情请参见[RFC6049]第5.1.4节和第5.1.5节。以这种方式计算的端到端链路损耗界也可以用作路径计算中的约束。
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].
DCLC的启发式算法只处理一个约束边界，但具有限制探索路径的CSPF（即，基于跳数），可以组合[hop-count_DCLC]。
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 Section 2.3, where links may move in and out of conformance for link performance objectives with regards to latency, delay variation, and link loss.
除了选择符合性能数据绑定的路径外，还可以避免使用不满足必要约束的链接。当然，如果这样的参数是已知的固定值，那么可以使用资源属性标志来表示这种行为。但是，当与链接关联的参数可能动态变化时，当前没有配置时机制来强制执行此类行为。第2.3节中描述了这方面的一个示例，其中链路可能会根据链路性能目标（关于延迟、延迟变化和链路丢失）移入或移出一致性。
When doing path selection for TE tunnels, it has not been possible to know how much actual bandwidth is available that includes the bandwidth used by non-RSVP-TE traffic. In [RFC7471] and [RFC7810], 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 minimum amount of Unidirectional Available Bandwidth might be permitted.
在为TE隧道进行路径选择时，不可能知道有多少实际带宽可用，其中包括非RSVP TE流量使用的带宽。在[RFC7471]和[RFC7810]中，单向可用带宽与剩余带宽一样公布。当计算TE隧道的路径时，可能只允许具有至少最小单向可用带宽的链路。
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 path computation 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.
类似地，只有丢失低于可配置值的链接才可以接受。对于这些约束，可以针对约束测试每个链接，并且只有当链接通过时，才能在路径计算中进行探索。本质上，未通过约束测试的链接被视为在排除任何筛选器中包含资源属性。
Link conformance to a link performance objective can change as a result of rerouting at lower layers. This could be due to optical regrooming or simply rerouting of an FA-LSP. When this occurs, there are two questions to be asked:
链路与链路性能目标的一致性可能会因较低层的重新路由而改变。这可能是由于光学重磨或FA-LSP的简单重路由。出现这种情况时，需要问两个问题：
a. Should the link be trusted and used for the setup of new LSPs?
a. 是否应信任该链接并将其用于设置新的LSP？
b. Should LSPs using this link automatically be moved to a secondary path?
b. 使用此链接的LSP是否应自动移动到辅助路径？
If the answer to (a) is no for link latency performance objectives, then any link that has the Anomalous bit set in the Unidirectional Link Delay sub-TLV [RFC7471] [RFC7810] should be removed from the 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 exclude-any resource attributes filter [RFC3209].
如果对于链路延迟性能目标（a）的回答为否，则在使用路径计算来计算新路径之前，应将单向链路延迟子TLV[RFC7471][RFC7810]中设置了异常位的任何链路从拓扑中删除。本质上，链接应被视为未通过排除任何资源属性过滤器[RFC3209]。
Similarly, if the answer to (a) is no for link loss performance objectives, then any link that has the Anomalous bit set in the Link Loss sub-TLV should be treated as if it fails the exclude-any resource attributes filter.
类似地，如果对于链路丢失性能目标（a）的回答为否，则在链路丢失子TLV中设置了异常位的任何链路都应被视为未通过排除任何资源属性过滤器。
When the Anomalous bit transitions from clear to set, this indicates that the associated link has entered the Anomalous state with respect to the associated parameter; similarly, a transition from set to clear indicates that the Anomalous state has been exited for that link and associated parameter.
当异常位从清除转换为设置时，这表示关联链路已进入关于关联参数的异常状态；类似地，从set到clear的转换表示该链接和相关参数的异常状态已退出。
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; thus, the compliance of a link with respect to a particular link performance objective is indicated per performance criterion.
当链路进入与参数相关的异常状态时，这表明使用该链路的LSP可能也不再符合其性能界限。它还可以被视为一种迹象，表明有什么东西正在改变该链路，因此承载性能关键的流量可能不再可靠。当然，对于特定LSP，哪些性能标准是重要的取决于LSP的配置；因此，根据性能标准指示链路相对于特定链路性能目标的符合性。
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.
在TE隧道的入口处，TE隧道可被配置为相对于延迟、延迟变化和/或丢失对链路的异常状态敏感。此外，这样的TE隧道可被配置为验证持续遵从性、立即切换到备用LSP或移动到不同路径。
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 have its continued compliance verified, be switched to a hot standby, or do a make-before-break to a secondary path.
当接收到子TLV时，当先前清除异常位时，必须扫描感兴趣的TE隧道列表。每一个这样的TE隧道都应该验证其持续的合规性，切换到热备用，或者先接通再断开到辅助路径。
It is not sufficient to just look at the Anomalous bit in order to determine when TE tunnels must have their compliance verified. When changing to set, the Anomalous bit merely provides a hint that
仅仅通过查看异常钻头来确定TE隧道何时必须验证其合规性是不够的。当更改为set时，异常位仅提供以下提示：
interested TE tunnels should have their continued compliance verified.
感兴趣的TE隧道应进行持续合规性验证。
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 due to administrative policy when the link entered the Anomalous state, may want to reoptimize to a better path. The hint provided by the Anomalous state change may help optimize when to recompute for a better path.
当链路离开与参数相关的异常状态时，这可以作为指示，当链路进入异常状态时，由于管理策略而更改了其LSP的TE隧道可能希望重新优化到更好的路径。异常状态更改提供的提示可能有助于优化何时重新计算以获得更好的路径。
This document is not currently believed to introduce new security concerns.
目前认为该文件不会带来新的安全问题。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <http://www.rfc-editor.org/info/rfc7471>.
[RFC7471]Giacalone，S.，Ward，D.，Drake，J.，Atlas，A.，和S.Previdi，“OSPF交通工程（TE）度量扩展”，RFC 7471，DOI 10.17487/RFC7471，2015年3月<http://www.rfc-editor.org/info/rfc7471>.
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/7810, May 2016, <http://www.rfc-editor.org/info/rfc7810>.
[RFC7810]Previdi，S.，Ed.，Giacalone，S.，Ward，D.，Drake，J.，和Q.Wu，“IS-IS交通工程（TE）度量扩展”，RFC 7810，DOI 10.17487/7810，2016年5月<http://www.rfc-editor.org/info/rfc7810>.
[hop-count_DCLC] Agrawal, H., Grah, M., and M. Gregory, "Optimization of QoS Routing", 6th IEEE/AACIS International Conference on Computer and Information Science, DOI 10.1109/ICIS.2007.144, July 2007, <http://ieeexplore.ieee.org/xpl/ articleDetails.jsp?arnumber=4276447>.
[hop-count_DCLC]Agrawal，H.，Grah，M.和M.Gregory，“QoS路由优化”，第六届IEEE/AACIS计算机和信息科学国际会议，DOI 10.1109/ICIS.2007.144，2007年7月<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, vol. 51, no. 4, April 2006, <http://dx.doi.org/10.1109/TAC.2006.872827>.
[k-Paths_DCLC]Jia，Z.和P.Varaiya，“使用k-最短路径的延迟约束最小成本路由的启发式方法”，IEEE自动控制交易，第51卷，第4期，2006年4月<http://dx.doi.org/10.1109/TAC.2006.872827>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <http://www.rfc-editor.org/info/rfc3246>.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 3246，DOI 10.17487/RFC3246，2002年3月<http://www.rfc-editor.org/info/rfc3246>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <http://www.rfc-editor.org/info/rfc4594>.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 4594，DOI 10.17487/RFC4594，2006年8月<http://www.rfc-editor.org/info/rfc4594>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<http://www.rfc-editor.org/info/rfc4655>.
[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, <http://www.rfc-editor.org/info/rfc6049>.
[RFC6049]Morton，A.和E.Stephan，“度量的空间构成”，RFC 6049，DOI 10.17487/RFC6049，2011年1月<http://www.rfc-editor.org/info/rfc6049>.
[SEG-ROUTE-MPLS] Filsfils, C., Ed., Previdi, S., Ed., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., and E. Crabbe, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-04, March 2016.
[SEG-ROUTE-MPLS]Filsfils，C.，Ed.，Previdi，S.，Ed.，Bashandy，A.，DeClaene，B.，Litkowski，S.，Horneffer，M.，Shakir，R.，Tantsura，J.，和E.Crabbe，“使用MPLS数据平面的段路由”，正在进行中，草案-ietf-spring-Segment-Routing-MPLS-042016年3月。
Acknowledgements
致谢
The authors would like to thank Curtis Villamizar for his extensive detailed comments and suggested text in Sections 1 and 1.2. The authors would like to thank Dhruv Dhody for his useful comments and his care and persistence in making sure that these important corrections weren't missed. The authors would also like to thank Xiaohu Xu and Sriganesh Kini for their reviews.
作者感谢Curtis Villamizar在第1节和第1.2节中提出的广泛详细评论和建议文本。作者要感谢Dhruv Dhody的有用评论，以及他在确保这些重要更正不被遗漏方面的关心和坚持。作者还要感谢徐晓虎和斯里加内什·基尼的评论。
Contributors
贡献者
Dave Ward and Clarence Filsfils contributed to this document.
Dave Ward和Clarence Filsfils对此文档做出了贡献。
Authors' Addresses
作者地址
Alia Atlas Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States
美国马萨诸塞州韦斯特福德科技园大道10号Alia Atlas Juniper Networks 01886
Email: akatlas@juniper.net
Email: akatlas@juniper.net
John Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States
约翰·德雷克·朱尼珀网络公司美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
Email: jdrake@juniper.net
Email: jdrake@juniper.net
Spencer Giacalone Microsoft
斯宾塞·贾卡隆微软公司
Email: spencer.giacalone@gmail.com
Email: spencer.giacalone@gmail.com
Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 00142 Italy
Stefano Previdi Cisco Systems Via Del Serafico 200意大利罗马00142
Email: sprevidi@cisco.com
Email: sprevidi@cisco.com