Network Working Group F. Le Faucheur
Request for Comments: 3785 R. Uppili
BCP: 87 Cisco Systems, Inc.
Category: Best Current Practice A. Vedrenne
P. Merckx
Equant
T. Telkamp
Global Crossing
May 2004
Network Working Group F. Le Faucheur
Request for Comments: 3785 R. Uppili
BCP: 87 Cisco Systems, Inc.
Category: Best Current Practice A. Vedrenne
P. Merckx
Equant
T. Telkamp
Global Crossing
May 2004
Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric
使用内部网关协议（IGP）度量作为第二个MPLS流量工程（TE）度量
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices.
本文档描述了如何将内部网关协议（IGP）的现有度量用作多协议标签交换（MPLS）流量工程隧道中基于约束的路由的流量工程（TE）度量的替代度量。这有效地导致能够通过优化某些流量工程隧道（例如，数据中继）的一个度量（例如，链路带宽）来执行基于约束的路由，同时优化具有不同要求的其他隧道（例如，语音中继）的另一个度量（例如，传播延迟）。不需要协议扩展或修改。本文记录了当前路由器的实现和部署实践。
Interior Gateway Protocol (IGP) routing protocols (OSPF and IS-IS) as well as MultiProtocol Label Switching (MPLS) signaling protocols (RSVP-TE and CR-LDP) have been extended (as specified in [ISIS-TE], [OSPF-TE], [RSVP-TE] and [CR-LDP]) in order to support the Traffic Engineering (TE) functionality as defined in [TE-REQ].
内部网关协议（IGP）路由协议（OSPF和IS-IS）以及多协议标签交换（MPLS）信令协议（RSVP-TE和CR-LDP）已经扩展（如[ISIS-TE]、[OSPF-TE]、[RSVP-TE]和[CR-LDP]中所述），以支持[TE-REQ]中定义的流量工程（TE）功能。
These IGP routing protocol extensions currently include advertisement of a single additional MPLS TE metric to be used for Constraint Based Routing of TE tunnels.
这些IGP路由协议扩展目前包括单个附加MPLS TE度量的公布，用于TE隧道的基于约束的路由。
However, the objective of traffic engineering is to optimize the use and the performance of the network. So it seems relevant that TE tunnel placement may be optimized according to different optimization criteria. For example, some Service Providers want to perform traffic engineering of different classes of service separately so that each class of Service is transported on a different TE tunnel. One example motivation for doing so is to apply different fast restoration policies to the different classes of service. Another example motivation is to take advantage of separate Constraint Based Routing in order to meet the different Quality of Service (QoS) objectives of each Class of Service. Depending on QoS objectives one may require either (a) enforcement by Constraint Based Routing of different bandwidth constraints for the different classes of service as defined in [DS-TE], or (b) optimizing on a different metric during Constraint Based Routing or (c) both. This document discusses how optimizing on a different metric can be achieved during Constraint Based Routing.
然而，流量工程的目标是优化网络的使用和性能。因此，似乎可以根据不同的优化标准对TE隧道布置进行优化。例如，一些服务提供商希望分别执行不同类别服务的流量工程，以便在不同的TE隧道上传输每个类别的服务。这样做的动机之一是将不同的快速恢复策略应用于不同的服务类别。另一个示例动机是利用单独的基于约束的路由，以满足每类服务的不同服务质量（QoS）目标。根据QoS目标，可能需要（a）通过基于约束的路由为[DS-TE]中定义的不同类别的服务实施不同的带宽约束，或（b）在基于约束的路由过程中优化不同的度量，或（c）两者兼而有之。本文档讨论如何在基于约束的路由过程中实现不同度量的优化。
The most common scenario for a different metric calls for optimization of a metric reflecting delay (mainly propagation delay) when Constraint Based Routing TE Label Switched Paths (LSPs) that will be transporting voice, while optimizing a more usual metric (e.g., reflecting link bandwidth) when Constraint Based Routing TE LSPs that will be transporting data.
不同度量的最常见情况是，当基于约束的路由选择标签交换路径（LSP）传输语音时，需要优化度量反映延迟（主要是传播延迟），同时优化更常见的度量（例如，反映链路带宽）基于约束的路由选择将传输数据的LSP时。
Additional IGP protocol extensions could be defined so that multiple TE metrics could be advertised in the IGP (as proposed for example in [METRICS]) and would thus be available to Constraint Based Routing in order to optimize on a different metric. However this document describes how optimizing on a different metric can be achieved today by existing implementations and deployments, without any additional IGP extensions beyond [ISIS-TE] and [OSPF-TE], by effectively using the IGP metric as a "second" TE metric.
可以定义额外的IGP协议扩展，以便在IGP中公布多个TE度量（例如在[metrics]中提出的），并因此可用于基于约束的路由，以便在不同的度量上进行优化。然而，本文档描述了如何通过现有的实施和部署，通过有效地将IGP度量用作“第二个”TE度量，在没有任何超出[ISIS-TE]和[OSPF-TE]的额外IGP扩展的情况下，实现对不同度量的优化。
In current MPLS TE deployments, network administrators often want Constraint Based Routing of TE LSPs carrying data traffic to be based on the same metric as the metric used for Shortest Path Routing. Where this is the case, this practice allows the Constraint Based Routing algorithm running on the Head-End LSR to use the IGP metric advertised in the IGP to compute paths for data TE LSPs instead of the advertised TE metric. The TE metric can then be used to convey
在当前的MPLS TE部署中，网络管理员通常希望承载数据流量的TE LSP的基于约束的路由基于与用于最短路径路由的度量相同的度量。在这种情况下，该实践允许在前端LSR上运行的基于约束的路由算法使用在IGP中公布的IGP度量来计算数据TE lsp的路径，而不是公布的TE度量。然后可以使用TE度量来传递
another metric (e.g., a delay-based metric) which can be used by the Constraint Based Routing algorithm on the Head-End LSR to compute path for the TE LSPs with different requirements (e.g., Voice TE LSP).
另一个度量（例如，基于延迟的度量），其可由前端LSR上基于约束的路由算法用于计算具有不同需求的TE-LSP（例如，语音TE-LSP）的路径。
In some networks, network administrators configure the IGP metric to a value factoring the link propagation delay. In that case, this practice allows the Constraint Based Routing algorithm running on the Head-End LSR to use the IGP metric advertised in the IGP to compute paths for delay-sensitive TE LSPs (e.g., Voice TE LSPs) instead of the advertised TE metric. The TE metric can then be used to convey another metric (e.g., bandwidth based metric) which can be used by the Constraint Based Routing algorithm to compute paths for the data TE LSPs.
在某些网络中，网络管理员将IGP度量配置为一个考虑链路传播延迟的值。在这种情况下，该实践允许在前端LSR上运行的基于约束的路由算法使用在IGP中公布的IGP度量来计算延迟敏感TE lsp（例如，语音TE lsp）的路径，而不是公布的TE度量。TE度量随后可用于传送另一度量（例如，基于带宽的度量），其可由基于约束的路由算法用于计算数据TE lsp的路径。
More generally, the TE metric can be used to carry any arbitrary metric that may be useful for Constraint Based Routing of the set of LSPs which need optimization on another metric than the IGP metric.
更一般地，TE度量可用于携带可能对lsp集合的基于约束的路由有用的任何任意度量，该lsp集合需要在IGP度量以外的另一度量上进行优化。
A Head-End LSR implements the current practice by:
前端LSR通过以下方式实施当前实践：
(i) Allowing configuration, for each TE LSP to be routed, of whether the IGP metric or the TE metric is to be used by the Constraint Based Routing algorithm.
(i) 允许为每个要路由的TE LSP配置基于约束的路由算法是使用IGP度量还是TE度量。
(ii) Enabling the Constraint Based Routing algorithm to make use of either the TE metric or the IGP metric, depending on the above configuration for the considered TE-LSP
（ii）根据所考虑的TE-LSP的上述配置，使基于约束的路由算法能够使用TE度量或IGP度量
A Service Provider deploys this practice by:
服务提供商通过以下方式部署此做法：
(i) Configuring, on every relevant link, the TE metric to reflect whatever metric is appropriate (e.g., delay-based metric) for Constraint Based Routing of some LSPs as an alternative metric to the IGP metric
(i) 在每个相关链路上配置TE度量，以反映某些LSP基于约束的路由的适当度量（例如，基于延迟的度量），作为IGP度量的替代度量
(ii) Configuring, for every TE LSP, whether this LSP is to be constraint based routed according to the TE metric or IGP metric
（ii）为每个TE LSP配置该LSP是否根据TE度量或IGP度量基于约束路由
The practice described in this document has the following constraints:
本文件中描述的实践有以下限制：
(i) it only allows TE tunnels to be routed on either of two metrics (i.e., it cannot allow TE tunnels to be routed on one of three, or more, metrics). Extensions (for example such as those proposed in [METRICS]) could be defined in the future if necessary to relax this constraints, but this is outside the scope of this document.
(i) 它只允许根据两个指标中的任何一个来路由TE隧道（即，它不能允许根据三个或更多指标中的一个来路由TE隧道）。如果有必要放宽此限制，可以在将来定义扩展（例如[METRICS]中提出的扩展），但这超出了本文档的范围。
(ii) it can only be used where the IGP metric is appropriate as one of the two metrics to be used for constraint based routing (i.e., it cannot allow TE tunnels to be routed on either of two metrics while allowing IGP SPF to be based on a third metric). Extensions (for example such as those proposed in [METRICS]) could be defined in the future if necessary to relax this constraints, but this is outside the scope of this document.
（ii）它只能在IGP度量适合作为基于约束的路由使用的两个度量之一的情况下使用（即，它不能允许TE隧道基于两个度量之一进行路由，而允许IGP SPF基于第三个度量）。如果有必要放宽此限制，可以在将来定义扩展（例如[METRICS]中提出的扩展），但这超出了本文档的范围。
(iii) it can only be used on links which support an IGP adjacency so that an IGP metric is indeed advertised for the link. For example, this practice can not be used on Forwarding Adjacencies (see [LSP-HIER]).
（iii）它只能在支持IGP邻接的链路上使用，以便确实为链路宣传IGP度量。例如，这种做法不能用于转发邻接（参见[LSP-HIER]）。
Note that, as with [METRICS], this practice does not recommend that the TE metric and the IGP metric be used simultaneously during path computation for a given LSP. This is known to be an NP-complete problem.
注意，与[METRICS]一样，本实践不建议在给定LSP的路径计算期间同时使用TE度量和IGP度量。这是一个NP完全问题。
Where path computation is entirely performed by the Head-End (e.g., intra-area operations with path computation on Head-end), this practice does not raise any interoperability issue among LSRs since the use of one metric or the other is a matter purely local to the Head-End LSR.
如果路径计算完全由前端执行（例如，在前端进行路径计算的区域内操作），此实践不会在LSR之间产生任何互操作性问题，因为使用一个或另一个度量纯粹是前端LSR的局部问题。
Where path computation involves another component than the Head-End (e.g., with inter-area operations where path computation is shared between the Head-End and Area Boundary Routers or a Path Computation Server), this practice requires that which metric to optimize on, be signaled along with the other constraints (bandwidth, affinity) for the LSP. See [PATH-COMP] for an example proposal on how to signal which metric to optimize, to another component involved in path computation when RSVP-TE is used as the protocol to signal path computation information.
如果路径计算涉及头端以外的另一个组件（例如，在头端和区域边界路由器或路径计算服务器之间共享路径计算的区域间操作中），此实践要求在其他约束（带宽、亲和力）的同时通知要优化的度量对于LSP。有关当RSVP-TE用作发送路径计算信息的协议时，如何向路径计算中涉及的另一个组件发送要优化的度量的示例建议，请参见[PATH-COMP]。
Service Providers need to consider how to migrate from the current implementation to the new one supporting this practice.
服务提供商需要考虑如何从当前实现迁移到支持这种实践的新实现。
Although the head-end routers act independently from each other, some migration scenarios may require that all head-end routers be upgraded to the new implementation to avoid any disruption on existing TE-LSPs before two metrics can effectively be used by TE. The reason is that routers with current implementation are expected to always use the TE metric for Constraint Based Routing of all tunnels; so when the TE metric is reconfigured to reflect the "second metric" (say to a delay-based metric) on links in the network, then all TE-LSPs would get routed based on the "second metric" metric, while the intent may be that only the TE-LSPs explicitly configured so should be routed based on the "second metric".
尽管头端路由器相互独立，但某些迁移场景可能要求所有头端路由器升级到新的实现，以避免对现有TE LSP的任何中断，然后TE才能有效使用两个指标。原因是，当前实现的路由器预期总是使用TE度量来对所有隧道进行基于约束的路由；因此，当TE度量被重新配置以反映网络中链路上的“第二度量”（例如，基于延迟的度量）时，所有TE lsp将基于“第二度量”度量进行路由，而意图可能是只有显式配置的TE lsp应基于“第二度量”进行路由。
A possible migration scenario would look like this:
可能的迁移场景如下所示：
1) upgrade software on all head-end routers in the network to support this practice.
1) 升级网络中所有前端路由器上的软件以支持此做法。
2) change the TE-LSPs configuration on the head-end routers to use the IGP metric (e.g., bandwidth-based) for Constraint Based Routing rather than the TE metric.
2) 更改前端路由器上的TE LSPs配置，以使用基于约束的路由的IGP度量（例如，基于带宽），而不是TE度量。
3) configure TE metric on the links to reflect the "second metric" (e.g., delay-based).
3) 在链路上配置TE度量以反映“第二度量”（例如，基于延迟）。
4) modify the LSP configuration of the subset of TE-LSPs which need to be Constraint Based routed using the "second metric" (e.g., delay-based), and/or create new TE-LSPs with such a configuration.
4) 修改需要使用“第二度量”（例如，基于延迟）基于约束路由的TE LSP子集的LSP配置，和/或使用这种配置创建新的TE LSP。
It is desirable that step 2 is non-disruptive (i.e., the routing of a LSP will not be affected in any way, and the data transmission will not be interrupted) by the change of LSP configuration to use "IGP metric" as long as the actual value of the "IGP metric" and "TE metric" are equal on every link at the time of LSP reconfiguration (as would be the case at step 2 in migration scenario above which assumed that TE metric was initially equal to IGP metric).
希望通过改变LSP配置来使用“IGP度量”，只要在LSP重新配置时每个链路上“IGP度量”和“TE度量”的实际值相等，步骤2是无中断的（即，LSP的路由不会以任何方式受到影响，并且数据传输不会被中断）（与上面迁移场景中步骤2的情况相同，该步骤假设TE度量最初等于IGP度量）。
The practice described in this document does not raise specific security issues beyond those of existing TE. Those are discussed in the respective security sections of [TE-REQ], [RSVP-TE] and [CR-LDP].
本文件中描述的实践不会提出现有TE以外的具体安全问题。这些在[TE-REQ]、[RSVP-TE]和[CR-LDP]的相应安全章节中讨论。
This document has benefited from discussion with Jean-Philippe Vasseur.
本文件得益于与Jean-Philippe Vasseur的讨论。
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, Requirements for Traffic Engineering over MPLS, RFC 2702, September 1999.
[TE-REQ]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.和J.McManus，MPLS流量工程要求，RFC 2702，1999年9月。
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]Katz，D.，Kompella，K.和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE), RFC 3784, May 2004.
[ISIS-TE]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 3784，2004年5月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[CR-LDP] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[CR-LDP]Jamoussi，B.，Andersson，L.，Callon，R.，Dantu，R.，Wu，L.，Doolan，P.，Worster，T.，Feldman，N.，Fredette，A.，Girish，M.，Gray，E.，Heinanen，J.，Kilty，T.和A.Malis，“使用LDP的基于约束的LSP设置”，RFC 3212，2002年1月。
[METRICS] Fedyk, et al., "Multiple Metrics for Traffic Engineering with IS-IS and OSPF", Work in Progress, November 2000.
[METRICS]Fedyk等人，“IS-IS和OSPF流量工程的多重指标”，进展中的工作，2000年11月。
[DIFF-TE] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DIFF-TE]Le Faucheur，F.和W.Lai，“支持区分服务的MPLS流量工程的要求”，RFC 3564，2003年7月。
[PATH-COMP] Vasseur, et al., "RSVP Path computation request and reply messages", Work in Progress, June 2002.
[PATH-COMP]Vasseur等人，“RSVP路径计算请求和回复消息”，正在进行的工作，2002年6月。
[LSP-HIER] Kompella, et al., "LSP Hierarchy with Generalized MPLS TE", Work in Progress, September 2002.
[LSP-HIER]Kompella等人，“具有广义MPLS TE的LSP层次结构”，正在进行的工作，2002年9月。
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France
Francois Le Faucheur Cisco Systems，Inc.绿边企业村-法国索菲亚-安提波利斯大街T3400号巴蒂门特酒店
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Ramesh Uppili Cisco Systems, 2000 Innovation Drive Kanata, ONTARIO, Canada - K2K 3E8
Ramesh Uppili Cisco Systems，2000年加拿大安大略省卡纳塔创新大道-K2K 3E8
Phone: 01-613-254 4578 Email: ruppili@cisco.com
电话：01-613-254 4578电子邮件：ruppili@cisco.com
Alain Vedrenne Equant Heraklion, 1041 route des Dolines, BP347 06906 Sophia Antipolis Cedex FRANCE
Alain Vedrene Equant Heraklion，Doline路线1041号，BP347 06906索菲亚-安提波利斯-塞德克斯法国
Phone: +33 4 92 96 57 22
EMail: alain.vedrenne@equant.com
Phone: +33 4 92 96 57 22
EMail: alain.vedrenne@equant.com
Pierre Merckx Equant 1041 route des Dolines - BP 347 06906 SOPHIA ANTIPOLIS Cedex FRANCE
Pierre Merckx Equant 1041 Doline路线-英国石油公司347 06906索菲亚-安提波利斯-塞德克斯法国公司
Phone: +33 (0)492 96 6454
EMail: pierre.merckx@equant.com
Phone: +33 (0)492 96 6454
EMail: pierre.merckx@equant.com
Thomas Telkamp Global Crossing, Ltd. Croeselaan 148 NL-3521CG Utrecht The Netherlands
Thomas Telkamp Global Crosselaan有限公司荷兰乌得勒支148 NL-3521CG
Phone: +31 30 238 1250
EMail: telkamp@gblx.net
Phone: +31 30 238 1250
EMail: telkamp@gblx.net
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。