Network Working Group R. Zhang, Ed.
Request for Comments: 4216 Infonet Services Corporation
Category: Informational J.-P. Vasseur, Ed.
Cisco Systems, Inc.
November 2005
Network Working Group R. Zhang, Ed.
Request for Comments: 4216 Infonet Services Corporation
Category: Informational J.-P. Vasseur, Ed.
Cisco Systems, Inc.
November 2005
MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements
MPLS自治系统间（AS）流量工程（TE）要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios.
本文档讨论支持内部AS MPLS流量工程（MPLS TE）的要求。其主要目标是提出一组需求和场景，从而为满足这些需求和支持场景的任何技术解决方案的定义、选择和规范开发提供一般指导。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Contributing Authors ............................................4
3. Definitions and Requirements Statement ..........................5
3.1. Definitions ................................................5
3.2. Objectives and Requirements of Inter-AS Traffic
Engineering ................................................7
3.2.1. Inter-AS Bandwidth Guarantees .......................7
3.2.2. Inter-AS Resource Optimization ......................8
3.2.3. Fast Recovery across ASes ...........................8
3.3. Inter-AS Traffic Engineering Requirements Statement ........9
4. Application Scenarios ...........................................9
4.1. Application Scenarios Requiring Inter-AS Bandwidth
Guarantees .................................................9
4.1.1. Scenario I - Extended or Virtual PoP (VPoP) .........9
4.1.2. Scenario II - Extended or Virtual Trunk ............11
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Contributing Authors ............................................4
3. Definitions and Requirements Statement ..........................5
3.1. Definitions ................................................5
3.2. Objectives and Requirements of Inter-AS Traffic
Engineering ................................................7
3.2.1. Inter-AS Bandwidth Guarantees .......................7
3.2.2. Inter-AS Resource Optimization ......................8
3.2.3. Fast Recovery across ASes ...........................8
3.3. Inter-AS Traffic Engineering Requirements Statement ........9
4. Application Scenarios ...........................................9
4.1. Application Scenarios Requiring Inter-AS Bandwidth
Guarantees .................................................9
4.1.1. Scenario I - Extended or Virtual PoP (VPoP) .........9
4.1.2. Scenario II - Extended or Virtual Trunk ............11
4.1.3. Scenario III - End-to-End Inter-AS MPLS TE
from CE to CE ......................................12
4.2. Application Scenarios Requiring Inter-AS Resource
Optimization ..............................................13
4.2.1. Scenario IV - TE across multi-AS within a
Single SP ..........................................13
4.2.2. Scenario V - Transit ASes as Primary and
Redundant Transport ................................14
5. Detailed Requirements for Inter-AS MPLS Traffic Engineering ....16
5.1. Requirements within One SP Administrative Domain ..........16
5.1.1. Inter-AS MPLS TE Operations and Interoperability ...16
5.1.2. Protocol Signaling and Path Computations ...........16
5.1.3. Optimality .........................................17
5.1.4. Support of Diversely Routed Inter-AS TE LSP ........17
5.1.5. Re-Optimization ....................................18
5.1.6. Fast Recovery Support Using MPLS TE Fast Reroute ...18
5.1.7. DS-TE Support ......................................18
5.1.8. Scalability and Hierarchical LSP Support ...........19
5.1.9. Mapping of Traffic onto Inter-AS MPLS TE Tunnels ...19
5.1.10. Inter-AS MPLS TE Management .......................19
5.1.10.1. Inter-AS MPLS TE MIB Requirements ........19
5.1.10.2. Inter-AS MPLS TE Fault Management
Requirements .............................20
5.1.11. Extensibility .....................................21
5.1.12. Complexity and Risks ..............................21
5.1.13. Backward Compatibility ............................21
5.1.14. Performance .......................................21
5.2. Requirements for Inter-AS MPLS TE across Multiple SP ......22
5.2.1. Confidentiality ....................................22
5.2.2. Policy Control .....................................23
5.2.2.1. Inter-AS TE Agreement Enforcement
Polices ...................................23
5.2.2.2. Inter-AS TE Rewrite Policies ..............24
5.2.2.3. Inter-AS Traffic Policing .................24
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. Normative References ...........................................25
9. Informative References .........................................25
Appendix A. Brief Description of BGP-based Inter-AS Traffic
Engineering ...........................................27
4.1.3. Scenario III - End-to-End Inter-AS MPLS TE
from CE to CE ......................................12
4.2. Application Scenarios Requiring Inter-AS Resource
Optimization ..............................................13
4.2.1. Scenario IV - TE across multi-AS within a
Single SP ..........................................13
4.2.2. Scenario V - Transit ASes as Primary and
Redundant Transport ................................14
5. Detailed Requirements for Inter-AS MPLS Traffic Engineering ....16
5.1. Requirements within One SP Administrative Domain ..........16
5.1.1. Inter-AS MPLS TE Operations and Interoperability ...16
5.1.2. Protocol Signaling and Path Computations ...........16
5.1.3. Optimality .........................................17
5.1.4. Support of Diversely Routed Inter-AS TE LSP ........17
5.1.5. Re-Optimization ....................................18
5.1.6. Fast Recovery Support Using MPLS TE Fast Reroute ...18
5.1.7. DS-TE Support ......................................18
5.1.8. Scalability and Hierarchical LSP Support ...........19
5.1.9. Mapping of Traffic onto Inter-AS MPLS TE Tunnels ...19
5.1.10. Inter-AS MPLS TE Management .......................19
5.1.10.1. Inter-AS MPLS TE MIB Requirements ........19
5.1.10.2. Inter-AS MPLS TE Fault Management
Requirements .............................20
5.1.11. Extensibility .....................................21
5.1.12. Complexity and Risks ..............................21
5.1.13. Backward Compatibility ............................21
5.1.14. Performance .......................................21
5.2. Requirements for Inter-AS MPLS TE across Multiple SP ......22
5.2.1. Confidentiality ....................................22
5.2.2. Policy Control .....................................23
5.2.2.1. Inter-AS TE Agreement Enforcement
Polices ...................................23
5.2.2.2. Inter-AS TE Rewrite Policies ..............24
5.2.2.3. Inter-AS Traffic Policing .................24
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. Normative References ...........................................25
9. Informative References .........................................25
Appendix A. Brief Description of BGP-based Inter-AS Traffic
Engineering ...........................................27
The MPLS Traffic Engineering (TE) mechanism documented in [TE-RSVP] may be deployed by Service Providers (SPs) to achieve some of the most important objectives of network traffic engineering as described in [TE-OVW]. These objectives are summarized as:
[TE-RSVP]中记录的MPLS流量工程（TE）机制可由服务提供商（SP）部署，以实现[TE-OVW]中所述的一些最重要的网络流量工程目标。这些目标总结如下：
- Supporting end-to-end services requiring Quality of Service (QoS) guarantees - Performing network resource optimization - Providing fast recovery
- 支持需要服务质量（QoS）保证的端到端服务-执行网络资源优化-提供快速恢复
However, this traffic engineering mechanism can only be used within an Autonomous System (AS).
然而，这种流量工程机制只能在自治系统（AS）中使用。
This document discusses requirements for an inter-AS MPLS Traffic Engineering mechanism that may be used to achieve the same set of objectives across AS boundaries within or beyond an SP's administrative domains.
本文档讨论了AS间MPLS流量工程机制的要求，该机制可用于在SP管理域内或之外跨AS边界实现相同的目标集。
The document will also present a set of application scenarios where the inter-AS traffic engineering mechanism may be required. This mechanism could be implemented based upon the requirements presented in this document.
本文件还将介绍一组可能需要AS间流量工程机制的应用场景。可根据本文件中提出的要求实施该机制。
These application scenarios will also facilitate discussions for a detailed requirements list for this inter-AS Traffic Engineering mechanism.
这些应用场景还将有助于讨论此AS间流量工程机制的详细需求列表。
Please note that there are other means of traffic engineering including Interior Gateway Protocol (IGP); metrics-based (for use within an AS); and Border Gateway Protocol (BGP) attribute-based (for use across ASes, as described in Appendix A), which provide coarser control of traffic paths. However, this document addresses requirements for a MPLS-based, fine-grained approach for inter-AS TE.
请注意，还有其他流量工程方法，包括内部网关协议（IGP）；基于度量（用于AS中）；和基于属性的边界网关协议（BGP）（用于跨ASE使用，如附录A所述），提供了对流量路径的粗略控制。然而，本文档提出了基于MPLS的、细粒度的内部AS TE方法的要求。
This document doesn't make any claims with respect to whether it is possible to have a practical solution that meets all the requirements listed in this document.
本文件未就是否有可能获得满足本文件所列所有要求的实用解决方案提出任何主张。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
The co-authors listed below contributed to the text and content of this document. (The contact information for the editors appears in section 9, and is not repeated below.)
下列共同作者对本文件的文本和内容做出了贡献。（编辑的联系信息见第9节，下文不再重复。）
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN EMail : ke-kumaki@kddi.com
Kenji Kumaki KDDI公司日本东京千代田区Iidabashi花园航空塔102-8460电子邮件：ke-kumaki@kddi.com
Paul Mabey Qwest Communications 950 17th Street, Denver, CO 80202, USA EMail: pmabey@qwest.com
美国科罗拉多州丹佛市第17街950号Paul Mabey Qwest Communications邮编：80202电子邮件：pmabey@qwest.com
Nadim Constantine Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025. USA EMail: nadim_constantine@infonet.com
纳迪姆·康斯坦丁信息网络服务公司，加利福尼亚州埃尔塞贡多大道东2160号，邮编90025。美国电子邮件：nadim_constantine@infonet.com
Pierre Merckx EQUANT 1041 route des Dolines - BP 347 06906 SOPHIA ANTIPOLIS Cedex, FRANCE EMail: pierre.merckx@equant.com
Pierre Merckx EQUANT 1041 Doline路线-BP 347 06906 SOPHIA ANTIPOLIS Cedex，法国电子邮件：Pierre。merckx@equant.com
Ting Wo Chung Bell Canada 181 Bay Street, Suite 350 Toronto, Ontario, Canada, M5J 2T3 EMail: ting_wo.chung@bell.ca
Ting Wo Chung Bell Canada加拿大安大略省多伦多市海湾街181号350室M5J 2T3电子邮件：Ting_Wo。chung@bell.ca
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, France EMail: jeanlouis.leroux@francetelecom.com
Jean-Louis Le Roux法国电信2号，Pierre Marzin大街22307兰尼昂塞德斯，法国电子邮件：jeanlouis。leroux@francetelecom.com
Yonghwan Kim SBC Laboratories, Inc. 4698 Willow Road Pleasanton, CA 94588, USA EMail: Yonghwan_Kim@labs.sbc.com
Yonghwan Kim SBC Laboratories，Inc.美国加利福尼亚州普莱森顿柳树路4698号，邮编94588电子邮件：Yonghwan_Kim@labs.sbc.com
The following provides a list of abbreviations and acronyms specifically pertaining to this document:
以下列出了与本文件相关的缩略语和首字母缩略词：
SP: Service Providers including regional or global providers.
SP：服务提供商，包括区域或全球提供商。
SP Administrative Domain: a single SP administration over a network or networks that may consist of one AS or multiple ASes.
SP管理域：一个或多个网络上的单个SP管理，这些网络可能由一个AS或多个AS组成。
IP-only networks: SP's network where IP routing protocols such as IGP/BGP are activated.
仅限IP网络：SP的网络，在该网络中，IP路由协议（如IGP/BGP）被激活。
IP/MPLS networks: SP's network where MPLS switching capabilities and signaling controls (e.g., ones described in [MPLS-ARCH]) are activated in addition to IP routing protocols.
IP/MPLS网络：SP的网络，其中除了IP路由协议外，还激活了MPLS交换能力和信令控制（如[MPLS-ARCH]中所述）。
Intra-AS TE: A generic definition for traffic engineering mechanisms operating over IP-only and/or IP/MPLS network within an AS.
内部AS TE：在AS内仅通过IP和/或IP/MPLS网络运行的流量工程机制的通用定义。
Inter-AS TE: A generic definition for traffic engineering mechanisms operating over IP-only and/or IP/MPLS network across one or multiple ASes. Since this document only addresses IP/MPLS networks, any reference to Inter-AS TE in this document refers only to IP/MPLS networks and is not intended to address IP-only TE requirements.
Inter-AS-TE：一种通用定义，用于在一个或多个ASE上仅通过IP和/或IP/MPLS网络运行的流量工程机制。由于本文件仅涉及IP/MPLS网络，因此本文件中提及的Inter-AS TE仅指IP/MPLS网络，并不旨在满足IP-only TE要求。
TE LSP: MPLS Traffic Engineering Label Switched Path.
TE LSP:MPLS流量工程标签交换路径。
Intra-AS MPLS TE: An MPLS Traffic Engineering mechanism where its TE Label Switched Path (LSP), Head-end Label Switching Router (LSR), and Tail-end LSR reside in the same AS for traffic engineering purposes.
内部AS MPLS TE：一种MPLS流量工程机制，其TE标签交换路径（LSP）、前端标签交换路由器（LSR）和后端LSR与流量工程目的位于同一个位置。
Inter-AS MPLS TE: An MPLS Traffic Engineering mechanism where its TE LSPs, Head-end LSR, and Tail-end LSR do not reside within the same AS or both Head-end LSR and Tail-end LSR are in the same AS, but the TE LSP transiting path may be across different ASes.
Inter-AS-MPLS-TE：一种MPLS流量工程机制，其中其TE-LSP、前端LSR和后端LSR不位于同一个AS中，或者前端LSR和后端LSR都位于同一个AS中，但TE-LSP传输路径可能跨越不同的AS。
ASBRs: Autonomous System Border Routers used to connect to another AS of a different or the same Service Provider via one or more links that interconnect ASes.
ASBR：自治系统边界路由器，用于通过一个或多个连接ASE的链路连接到不同或相同服务提供商的另一个AS。
Inter-AS TE Path: A TE path traversing multiple ASes and ASBRs, e.g., AS1-ASBR1-inter-AS link(s)-ASBR2-AS2... ASBRn-ASn.
AS间TE路径：穿越多个ASE和ASBR的TE路径，例如AS1-ASBR1-AS间链路-ASBR2-AS2。。。ASBRn。
Inter-AS TE Segment: A portion of the Inter-AS TE path.
内部AS TE段：内部AS TE路径的一部分。
Inter-AS DS-TE: Diffserv-aware Inter-AS TE.
Inter-AS-TE：区分服务感知的Inter-AS-TE。
CE: Customer Edge Equipment
CE：客户边缘设备
PE: Provider Edge Equipment that has direct connections to CEs.
PE：直接连接到CEs的提供商边缘设备。
P: Provider Equipment that has backbone trunk connections only.
P：仅具有主干中继连接的提供商设备。
VRF: Virtual Private Network (VPN) Routing and Forwarding Instance.
VRF：虚拟专用网（VPN）路由和转发实例。
PoP: Point of presence or a node in SP's network.
PoP：SP网络中的存在点或节点。
SRLG: A set of links may constitute a 'shared risk link group' (SRLG) if they share a resource whose failure may affect all links in the set as defined in [GMPLS-ROUT].
SRLG：如果一组链路共享一个资源，其故障可能会影响[GMPLS-ROUT]中定义的该组链路中的所有链路，则该组链路可能构成“共享风险链路组”（SRLG）。
PCC: Path Computation Client; any client application requesting a path computation to be performed by the Path Computation Element.
PCC：路径计算客户端；请求由路径计算元素执行的路径计算的任何客户端应用程序。
PCE: Path Computation Element; an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：路径计算单元；能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
Please note that the terms of CE, PE, and P used throughout this document are generic in their definitions. In particular, whenever such acronyms are used, it does not necessarily mean that CE is connected to a PE in a VRF environment described in such IETF documents as [BGP-MPLSVPN].
请注意，本文件中使用的CE、PE和P术语在其定义中是通用的。特别是，每当使用此类首字母缩写词时，并不一定意味着CE连接到IETF文档[BGP-MPLSVPN]中描述的VRF环境中的PE。
As mentioned in section 1 above, some SPs have requirements for achieving the same set of traffic engineering objectives as presented in [TE-OVW] across AS boundaries.
如上文第1节所述，一些SP要求实现[TE-OVW]中所述的跨越As边界的交通工程目标。
This section examines these requirements in each of the key corresponding areas: 1) Inter-AS bandwidth guarantees; 2) Inter-AS Resource Optimization and 3) Fast Recovery across ASes, i.e., Recovery of Inter-AS Links/SRLG and ASBR Nodes.
本节检查每个关键对应领域的这些要求：1）AS间带宽保证；2） AS间资源优化和3）跨ASE的快速恢复，即AS间链路/SRLG和ASBR节点的恢复。
The Diffserv IETF working group has defined a set of mechanisms described in [DIFF_ARCH], [DIFF_AF], and [DIFF_EF] or [MPLS-Diff]. These mechanisms can be activated at the edge of or over a Diffserv domain to contribute to the enforcement of a QoS policy (or a set of QoS policies), which can be expressed in terms of maximum one-way transit delay, inter-packet delay variation, loss rate, etc.
Diffserv IETF工作组定义了[DIFF_ARCH]、[DIFF_AF]和[DIFF_EF]或[MPLS DIFF]中描述的一组机制。这些机制可在区分服务域的边缘或之上激活，以有助于QoS策略（或一组QoS策略）的实施，QoS策略可表示为最大单向传输延迟、包间延迟变化、丢失率等。
Many SPs have partial or full deployment of Diffserv implementations in their networks today, either across the entire network or minimally on the edge of the network across CE-PE links.
如今，许多SP在其网络中部分或全部部署了Diffserv实现，可以跨整个网络，也可以跨CE-PE链路在网络边缘部署。
In situations where strict QoS bounds are required, admission control inside the backbone of a network is in some cases required in addition to current Diffserv mechanisms.
在需要严格QoS边界的情况下，除了当前的Diffserv机制之外，在某些情况下还需要网络主干内的准入控制。
When the propagation delay can be bounded, the performance targets, such as maximum one-way transit delay, may be guaranteed by providing bandwidth guarantees along the Diffserv-enabled path.
当传播延迟可以有界时，可以通过沿启用区分服务的路径提供带宽保证来保证性能目标，例如最大单向传输延迟。
One typical example of this requirement is to provide bandwidth guarantees over an end-to-end path for VoIP traffic classified as EF (Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled network. When the EF path is extended across multiple ASes, inter-AS bandwidth guarantee is then required.
该要求的一个典型示例是，在支持区分服务的网络中，为分类为EF（加速转发[DIFF_EF]）类的VoIP流量提供端到端路径上的带宽保证。当EF路径扩展到多个ASE时，需要AS间带宽保证。
Another case for inter-AS bandwidth guarantee is the requirement for guaranteeing a certain amount of transit bandwidth across one or multiple ASes.
AS间带宽保证的另一种情况是在一个或多个AS间保证一定数量的传输带宽。
Several application scenarios are presented to further illustrate this requirement in section 4 below.
下文第4节介绍了几个应用场景，以进一步说明这一要求。
In Service Provider (SP) networks, the BGP protocol [BGP] is deployed to exchange routing information between ASes. The inter-AS capabilities of BGP may also be employed for traffic engineering purposes across the AS boundaries. Appendix A provides a brief description of the current BGP-based inter-AS traffic engineering practices.
在服务提供商（SP）网络中，部署BGP协议[BGP]以在ASE之间交换路由信息。BGP的AS间能力也可用于跨AS边界的流量工程目的。附录A简要介绍了当前基于BGP的AS间流量工程实践。
SPs have managed to survive with this coarse set of BGP-based traffic engineering facilities across inter-AS links in a largely best-effort environment. Certainly, in many cases, ample bandwidth within an SP's network and across inter-AS links reduces the need for more elaborate inter-AS TE policies.
SP已成功地通过这套基于BGP的粗略流量工程设施，在基本上尽力而为的环境中，跨AS间链路生存下来。当然，在许多情况下，SP网络内和跨AS间链路的充足带宽减少了对更详细的AS间策略的需要。
However, in the case where a SP network is deployed over multiple ASes (for example, as the number of inter-AS links grows), the complexity of the inter-AS policies and the difficulty in inter-AS TE path optimization increase to a level such that it may soon become unmanageable.
然而，在SP网络部署在多个ASE上的情况下（例如，随着as间链路数量的增加），as间策略的复杂性和as间路径优化的难度增加到可能很快变得难以管理的程度。
Another example is where inter-AS links are established between different SP administrative domains. Nondeterministic factors such as uncoordinated routing and network changes, as well as sub-optimum traffic conditions, would potentially lead to a complex set of inter-AS traffic engineering policies where current traffic engineering mechanisms would probably not scale well.
另一个示例是在不同SP管理域之间建立AS间链路。不确定因素，如不协调的路由和网络变化，以及次优流量条件，可能会导致一组复杂的as间流量工程政策，而当前的流量工程机制可能无法很好地扩展。
In these situations where resource optimization is required and/or specific routing requirements arise, the BGP-based inter-AS facilities will need to be complemented by a more granular inter-AS traffic engineering mechanism.
在这些需要资源优化和/或出现特定路由要求的情况下，基于BGP的AS间设施需要由更细粒度的AS间流量工程机制来补充。
When extending services such as VoIP across ASes, customers often require SPs to maintain the same level of performance targets, such as packet loss and service availability, as achieved within an AS. As a consequence, fast convergence in a stable fashion upon link/SRLG/node failures becomes a strong requirement. This is clearly difficult to achieve with current inter-domain techniques, especially in cases of link/SRLG failures between ASBRs or ASBR node failures.
在跨ASE扩展VoIP等服务时，客户通常要求SP保持与as相同的性能目标水平，如数据包丢失和服务可用性。因此，在链路/SRLG/节点故障时以稳定的方式快速收敛成为一项强烈的要求。这显然很难用当前的域间技术实现，特别是在ASBR或ASBR节点故障之间的链路/SRLG故障的情况下。
Just as in the applicable case of deploying MPLS TE in an SP's network, an inter-AS TE method in addition to BGP-based traffic engineering capabilities needs to be deployed across inter-AS links where resource optimization, bandwidth guarantees and fast recovery are required.
正如在SP网络中部署MPLS TE的适用情况一样，除了基于BGP的流量工程功能之外，还需要在需要资源优化、带宽保证和快速恢复的as间链路上部署as间TE方法。
This is especially critical in a Diffserv-enabled, multi-class environment described in [PSTE] where statistical performance targets must be maintained consistently over the entire path across different ASes.
在[PSTE]中描述的支持区分服务的多类环境中，这一点尤其重要，在这种环境中，必须在不同ASE的整个路径上一致地维护统计性能目标。
The approach of extending current intra-AS MPLS TE capabilities [TE-RSVP] across inter-AS links for IP/MPLS networks is considered here because of already available implementations and operational experiences.
鉴于已有的实施和运营经验，本文考虑了跨IP/MPLS网络的AS间链路扩展当前AS内MPLS TE能力[TE-RSVP]的方法。
Please note that the inter-AS traffic engineering over an IP-only network is for future consideration since there is not sufficient interest for similar requirements to those of IP/MPLS networks at this time. More specifically, this document only covers the inter-AS TE requirements for packet-based IP/MPLS networks.
请注意，仅IP网络上的AS间流量工程供将来考虑，因为目前对IP/MPLS网络的类似要求没有足够的兴趣。更具体地说，本文档仅涵盖基于分组的IP/MPLS网络的AS TE间要求。
The following sections present a few application scenarios over IP/MPLS networks where requirements cannot be addressed with the current intra-AS MPLS TE mechanism and give rise to considerations for inter-AS MPLS traffic engineering requirements.
以下各节介绍了IP/MPLS网络上的一些应用场景，在这些场景中，当前的AS-MPLS内部TE机制无法满足需求，因此需要考虑AS-MPLS内部流量工程需求。
Although not explicitly noted in the following discussions, fast recovery of traffic path(s) crossing multiple ASes in a stable fashion is particularly important in the case of link/SRLG/node failures at AS boundaries for all application scenarios presented here.
尽管在下面的讨论中没有明确指出，但是对于此处介绍的所有应用场景，在AS边界处发生链路/SRLG/节点故障的情况下，以稳定的方式快速恢复跨越多个ASE的通信路径尤为重要。
A global service provider (SP1) would like to expand its reach into a region where a regional service provider's (SP2) network has already established a denser network presence.
全球服务提供商（SP1）希望将其业务范围扩展到区域服务提供商（SP2）网络已建立更密集网络的地区。
In this scenario, the SP1 may establish interconnections with SP2 in one or multiple points in that region. In their customer-dense regions, SP1 may utilize SP2's network as an extended transport by co-locating aggregation routers in SP2's PoPs.
在这种情况下，SP1可以在该区域的一个或多个点上与SP2建立互连。在客户密集的地区，SP1可以通过在SP2的POP中共同定位聚合路由器，将SP2的网络用作扩展传输。
In order to ensure bandwidth capacity provided by SP2 and to achieve some degrees of transparency to SP2's network changes in terms of capacity and network conditions, one or more inter-AS MPLS TE LSPs can be built between SP1's ASBR or PE router inside AS1 and SP1's PE routers co-located in SP2's PoPs, as illustrated in the diagram below:
为了确保SP2提供的带宽容量，并在容量和网络条件方面对SP2的网络变化实现一定程度的透明度，可以在SP1的ASBR或AS1内的PE路由器和SP1位于SP2的PoPs内的PE路由器之间构建一个或多个inter-AS MPLS TE LSP，如下图所示：
<===========Inter-AS MPLS TE Tunnel===========>
----- -----
________|ASBR |___Inter-AS___|ASBR |________
| | RTR | Link | RTR | |
---- ----- ----- ----- -----
|SP1 |_Inter-AS_| SP2 | | SP1 |
|VPoP| Link |P/PE | |P/PE |
---- ----- ----- ----- -----
|________|ASBR |___Inter-AS___|ASBR |________|
| RTR | Link | RTR |
----- -----
<=================Inter-AS MPLS TE Tunnel======================>
+-SP1 AS1-+ +---SP2 AS2-----+ +------SP1 AS1------+
<===========Inter-AS MPLS TE Tunnel===========>
----- -----
________|ASBR |___Inter-AS___|ASBR |________
| | RTR | Link | RTR | |
---- ----- ----- ----- -----
|SP1 |_Inter-AS_| SP2 | | SP1 |
|VPoP| Link |P/PE | |P/PE |
---- ----- ----- ----- -----
|________|ASBR |___Inter-AS___|ASBR |________|
| RTR | Link | RTR |
----- -----
<=================Inter-AS MPLS TE Tunnel======================>
+-SP1 AS1-+ +---SP2 AS2-----+ +------SP1 AS1------+
In situations where end-to-end Diffserv paths must be maintained, both SPs' networks may need to provision Diffserv PHB at each hop in order to support a set of traffic classes with compatible performance targets. The subsequent issues regarding Service Level Agreement (SLA) boundaries, reporting and measuring system interoperability and support demarcations are beyond the scope of this document and are not discussed further.
在必须维护端到端区分服务路径的情况下，两个SP的网络可能需要在每个跃点提供区分服务PHB，以便支持一组具有兼容性能目标的流量类别。有关服务级别协议（SLA）边界、报告和度量系统互操作性以及支持划分的后续问题超出了本文档的范围，不再进一步讨论。
If either SP1's or SP2's network is not a Diffserv-aware network, the scenario would still apply to provide bandwidth guarantees.
如果SP1或SP2的网络不是区分服务感知网络，则该场景仍然适用于提供带宽保证。
The SP2, on the other hand, can similarly choose to expand its reach beyond its servicing region over SP1's network via inter-AS MPLS TE tunnels.
另一方面，SP2可以类似地选择通过inter-AS-MPLS-TE隧道将其服务范围扩展到SP1网络的服务区域之外。
It is worth mentioning that these remote aggregation routers co-located in another SP's network are unlikely to host SP1's IGP and BGP routing planes and will more likely maintain their own AS or be part of the SP1's AS. In this case, such TE tunnels may cross several ASes, but the Head-end and Tail-end LSRs of TE tunnel may have the same AS number, as shown in the diagram above.
值得一提的是，这些位于另一个SP网络中的远程聚合路由器不太可能承载SP1的IGP和BGP路由平面，它们更有可能维护自己的AS或成为SP1的AS的一部分。在这种情况下，此类TE隧道可能跨越多个ASE，但TE隧道的前端和后端LSR可能具有相同的AS编号，如上图所示。
Instead of co-locating a PE router in SP2's PoP, SP1 may also choose to aggregate customer VPN sites onto a SP2's PE router where inter-AS TE tunnels can be built and signaled through SP2's MPLS network between the SP2 PoP (to which SP1 and customer CEs are directly connected) and SP1's ASBR or PE routers inside SP1's network. This allows SP1's customers connected to SP2 PE router to receive a guaranteed bandwidth service up to the TE LSP tail-end router located in SP1's network.
SP1也可以选择将客户VPN站点聚合到SP2的PE路由器上，在SP2的PE路由器上，可以在SP2的PoP（SP1和客户CE直接连接到SP1的PoP）和SP1的ASBR或SP1网络内的PE路由器之间通过SP2的MPLS网络建立和发送内部通道，而不是在SP2的PoP中共同定位PE路由器。这允许连接到SP2 PE路由器的SP1客户接收到保证带宽服务，直至位于SP1网络中的TE LSP终端路由器。
In this scenario, there could be two applicable cases:
在这种情况下，可能有两种适用情况：
Case 1 - the inter-AS MPLS TE tunnel functions as an extended or virtual trunk aggregating SP1's CE's local-loop access circuits on SP2's MPLS network over which the bandwidth can be guaranteed to the TE LSP tail-end router located in SP1's network, as shown in the diagram below:
案例1-inter-AS MPLS TE隧道作为SP2 MPLS网络上的SP1 CE本地环路接入电路的扩展或虚拟中继聚合，通过该中继可以保证位于SP1网络中的TE LSP终端路由器的带宽，如下图所示：
<====Inter-AS MPLS TE Tunnel====>
or
< ===Inter-AS MPLS TE Tunnel===============>
<====Inter-AS MPLS TE Tunnel====>
or
< ===Inter-AS MPLS TE Tunnel===============>
---- ----- ----- ----- -----
| CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
---- ----- ----- ----- -----
| CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
+SP1 Customer ASx+ +-----SP2 AS2---+ +-SP1 AS1-------+
+SP1 Customer ASx+ +-----SP2 AS2---+ +-SP1 AS1-------+
Case 2 - the inter-AS MPLS TE tunnel in this case functions as an extended or virtual local access link from SP1's CE on SP2's network to the SP1's ASBR or PE:
案例2-在这种情况下，inter-AS MPLS TE隧道作为SP2网络上SP1的CE到SP1的ASBR或PE的扩展或虚拟本地访问链路：
<==============Inter-AS MPLS TE Tunnel==============>
or
<==============Inter-AS MPLS TE Tunnel========================>
<==============Inter-AS MPLS TE Tunnel==============>
or
<==============Inter-AS MPLS TE Tunnel========================>
---- ----- ----- ----- -----
| CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
---- ----- ----- ----- -----
| CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 |
| | Loop | PE | | RTR | Link | RTR | |PE |
---- ----- ----- ----- -----
+SP1 Customer ASx+ +------SP2 AS2---+ +--SP1 AS1-----+
+SP1 Customer ASx+ +------SP2 AS2---+ +--SP1 AS1-----+
In Case 2 above, SP2 may elect to establish an aggregating or hierarchical intra-AS MPLS TE tunnel between the transiting P or PE router and SP2's ASBR router just to reduce the number of tunnel states signaled from the SP2 PE to where SP1's CEs are connected.
在上面的情况2中，SP2可以选择在传输的P或PE路由器和SP2的ASBR路由器之间建立聚合或分层的内部AS MPLS TE隧道，只是为了减少从SP2 PE发信号到SP1的CE连接的地方的隧道状态的数量。
In this scenario as illustrated below, customers require the establishment of MPLS TE tunnel from CE1 to CE2 end-to-end across several SPs' networks.
在这种情况下，如下图所示，客户需要跨多个SP的网络建立从CE1到CE2的端到端MPLS TE隧道。
<======================Inter-AS MPLS TE Tunnel==================>
<======================Inter-AS MPLS TE Tunnel==================>
--- ----- ----- ----- ----- ---
|CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2|
| | | PE | | RTR | Link | RTR | | PE | | |
--- ----- ----- ----- ----- ---
--- ----- ----- ----- ----- ---
|CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2|
| | | PE | | RTR | Link | RTR | | PE | | |
--- ----- ----- ----- ----- ---
+Cust ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+
+Cust ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+
The diagram below illustrates another example where CE1 and CE2 are customers of SP1 with external BGP (eBGP) peering relationships established across the CE-PE links. An inter-AS MPLS TE tunnel may then be established from CE1 in ASx to CE2, which may belong to the same AS or a different AS than that of CE1 across SP1's network in AS2.
下图显示了另一个示例，其中CE1和CE2是SP1的客户，通过CE-PE链路建立了外部BGP（eBGP）对等关系。然后，可以建立从ASx中的CE1到CE2的AS-MPLS-TE隧道，该隧道可能与AS2中的SP1网络中的CE1隧道相同或不同。
<===============Inter-AS MPLS TE Tunnel=====================>
<===============Inter-AS MPLS TE Tunnel=====================>
--- ----- ---- ---- ----- ---
|CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2|
| | | PE1 | |P1 | |P2 | | PE2 | | |
--- ----- ---- ---- ----- ---
--- ----- ---- ---- ----- ---
|CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2|
| | | PE1 | |P1 | |P2 | | PE2 | | |
--- ----- ---- ---- ----- ---
+-Cust ASx-+ +-------------SP1 AS2----------------+ +-Cust ASy-+
+-Cust ASx-+ +-------------SP1 AS2----------------+ +-Cust ASy-+
The above example shows that SP1's network has a single AS. Obviously, there may be multiple ASes between CE1 and CE2, as well as in the SP1's network.
上面的示例显示SP1的网络具有单个AS。显然，CE1和CE2之间以及SP1的网络中可能存在多个ASE。
In addition, where both CE1 and CE2 reside in the same AS, they will likely share the same private AS number.
此外，如果CE1和CE2都位于同一个AS中，则它们很可能共享同一个专用AS编号。
However, Scenario III will not scale well if there is a greater number of inter-AS TE MPLS tunnels in some degrees of partial mesh or full mesh. Therefore, it is expected that this scenario will have few deployments, unless some mechanisms such as hierarchical intra-AS TE-LSPs are used to reduce the number of signaling states.
然而，如果在某些程度的部分网格或全网格中存在更多的AS-TE MPLS隧道，场景III将无法很好地扩展。因此，除非使用诸如分层内部as TE lsp之类的机制来减少信令状态的数量，否则预计该场景将很少部署。
The scenarios presented in this section mainly deal with inter-AS resource optimization.
本节介绍的场景主要涉及AS间资源优化。
4.2.1. Scenario IV - TE across multi-AS within a Single SP Administrative Domain
4.2.1. 场景四-单个SP管理域内跨多个AS的TE
As mentioned in [TE-APP], SPs have generally admitted that the current MPLS TE mechanism provides a great deal of tactical and strategic value in areas of traffic path optimization [TE-RSVP] and rapid local repair capabilities [TE-FRR] via a set of on-line or off-line constraint-based path computation algorithms.
如[TE-APP]中所述，SPs普遍承认，当前的MPLS TE机制通过一组在线或离线基于约束的路径计算算法，在流量路径优化[TE-RSVP]和快速局部修复能力[TE-FRR]领域提供了大量战术和战略价值。
From a service provider's perspective, another way of stating the objectives of traffic engineering is to utilize available capacity in the network for delivering customer traffic without violating performance targets, and/or to provide better QoS services via an improved network utilization, more likely operating below congestion thresholds.
从服务提供商的角度来看，说明流量工程目标的另一种方式是利用网络中的可用容量来交付客户流量，而不违反性能目标，和/或通过提高网络利用率来提供更好的QoS服务，更可能在拥塞阈值以下运行。
It is worth noting that situations where resource provisioning is not an issue (e.g., low density in inter-AS connectivity or ample inter-AS capacity), it may not require more scalable and granular TE facilities beyond BGP routing policies. This is because such policies can be rather simple and because inter-AS resource optimization is not an absolute requirement.
值得注意的是，在资源调配不是问题的情况下（例如，AS间连接密度低或AS间容量充足），除了BGP路由策略外，可能不需要更具可扩展性和粒度的TE设施。这是因为此类策略可能相当简单，而且AS间资源优化不是绝对要求。
However many SPs, especially those with networks across multiple continents, as well as those with sparsely connected networks, have designed their multi-AS routing policies along or within the continental or sub-continental boundaries where the number of ASes can range from a very few to dozens. Generally, inter-continent or sub-continent capacity is very expensive. Some Service Providers have multiple ASes in the same country and would like to optimize resources over their inter-region links. This would demand a more scalable degree of resource optimization, which warrants the consideration of extending current intra-AS MPLS TE capabilities across inter-AS links.
然而，许多SP，特别是那些网络跨越多个大陆的SP，以及那些网络连接稀疏的SP，已经在大陆或次大陆边界沿线或之内设计了其多as路由策略，其中ASE的数量可以从极少数到几十个不等。一般来说，跨大陆或次大陆的产能非常昂贵。一些服务提供商在同一个国家拥有多个ASE，并希望通过其区域间链接优化资源。这将需要更可扩展的资源优化程度，这就需要考虑跨AS间链路扩展当前的AS内MPLS TE能力。
In addition, one may only realize higher efficiency in conducting traffic optimization and path protection/restoration planning when coordinating all network resources as a whole, rather than partially. For a network which may consist of many ASes, this could be realized via the establishment of inter-AS TE LSPs, as shown in the diagram below:
此外，当将所有网络资源作为一个整体而不是部分地进行协调时，可能只会在进行流量优化和路径保护/恢复规划时实现更高的效率。对于可能由多个ASE组成的网络，这可以通过建立AS-TE LSP间来实现，如下图所示：
<===================Inter-AS MPLS Tunnel=============>
-------- -------- --------
| |_______________| |____________| |
| SP1 |_______________| SP1 |____________| SP1 |
| AS1 |_______________| AS2 |____________| AS3 |
| | | | | |
-------- -------- --------
|| ||
|| --------- ||
||___________________| SP1 |________________||
|____________________| AS4 |_________________|
| |
---------
<===================Inter-AS MPLS Tunnel=============>
-------- -------- --------
| |_______________| |____________| |
| SP1 |_______________| SP1 |____________| SP1 |
| AS1 |_______________| AS2 |____________| AS3 |
| | | | | |
-------- -------- --------
|| ||
|| --------- ||
||___________________| SP1 |________________||
|____________________| AS4 |_________________|
| |
---------
The motivation for inter-AS MPLS TE is even more prominent in a Diffserv-enabled network over which statistical performance targets are to be maintained from any point to any point of the network as illustrated in the diagram below with an inter-AS DS-TE LSP:
在支持区分服务的网络中，采用inter-AS-MPLS-TE的动机更为突出，在该网络上，从网络的任何一点到任何一点都要保持统计性能目标，如下图所示，使用inter-AS-TE LSP：
<===================Inter-AS MPLS DS-TE Tunnel=============>
---- ----- ----- ----- ----- ----
| PE |__| P |___|ASBR |___Inter-AS___|ASBR |___|P |___|PE |
| RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR |
---- ----- ----- ----- ----- ----
+------------SP1 AS1---------+ +------------SP1 AS2------+
<===================Inter-AS MPLS DS-TE Tunnel=============>
---- ----- ----- ----- ----- ----
| PE |__| P |___|ASBR |___Inter-AS___|ASBR |___|P |___|PE |
| RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR |
---- ----- ----- ----- ----- ----
+------------SP1 AS1---------+ +------------SP1 AS2------+
For example, the inter-AS MPLS DS-TE LSP shown in the diagram above could be used to transport a set of L2 Pseudo Wires or VoIP traffic with corresponding bandwidth requirement.
例如，上图中所示的inter-AS-MPLS DS-TE LSP可用于传输具有相应带宽需求的一组L2伪线或VoIP业务。
Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR node failure is a strong requirement for such services.
此外，在ASBR-ASBR链路故障或ASBR节点故障的情况下快速恢复是此类服务的强烈要求。
Scenario V presents another possible deployment case. SP1 with AS1 wants to link a regional network to its core backbone by building an inter-AS MPLS TE tunnel over one or multiple transit ASes belonging to SP2, SP3, etc., as shown in the following diagram:
场景五介绍了另一种可能的部署情况。带有AS1的SP1希望通过在属于SP2、SP3等的一个或多个传输ASE上构建AS-MPLS-TE隧道，将区域网络链接到其核心主干网，如下图所示：
<===========Inter-AS MPLS TE Tunnel=======>
[ ] [ ] [ ]
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR| |P/PE|]
[ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |]
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ ] [ ] [ ]
<================Inter-AS MPLS TE Tunnel=====================>
+SP1 Regional ASx+ +Transit SP2 AS2,etc...SPi ASi+ +------SP1 AS1-+
<===========Inter-AS MPLS TE Tunnel=======>
[ ] [ ] [ ]
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR| |P/PE|]
[ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |]
[ ---- ---- ] [ ---- ---- ] [ ---- ---- ]
[ ] [ ] [ ]
<================Inter-AS MPLS TE Tunnel=====================>
+SP1 Regional ASx+ +Transit SP2 AS2,etc...SPi ASi+ +------SP1 AS1-+
This scenario can be viewed as a broader case of Scenario I shown in section 4.1.1 where the "VPoP" could be expanded into a regional network of SP1. By the same token, the AS number for SP1's regional network ASx may be the same as or different from AS1.
该场景可视为第4.1.1节中所示场景I的更广泛案例，“VPoP”可以扩展为SP1的区域网络。同样，SP1区域网络ASx的AS编号可能与AS1相同或不同。
The inter-AS MPLS TE LSP in this case may also be used to backup an internal path, as depicted in the diagram below, although this could introduce routing complexities:
在这种情况下，inter-AS-MPLS-TE-LSP也可用于备份内部路径，如下图所示，尽管这可能会引入路由复杂性：
<===========Inter-AS MPLS TE Tunnel=======>
+----------------------------SP1 AS1-----------------------------+
[ ]
[ ---- ---- ---- ---- ]
[ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |]
[ |RTR | |RTR | Link |RTR | |RTR |]
[ ---- ---- ---- ---- ]
[ | | ]
[ ---- ---- ]
[ |ASBR| |ASBR| ]
[ |RTR | |RTR | ]
[ ---- ---- ]
^ | | ^
| | | |
| | [ ] | |
| | [ ---- ---- ] | |
| |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| |
| Link [|RTR | |RTR |] Link |
| [ ---- ---- ] |
| [ ] |
| |
+======Backup Inter-AS MPLS TE Tunnel======+
+Transit SP2 AS2,SP3 AS3,etc....SPi ASi+
<===========Inter-AS MPLS TE Tunnel=======>
+----------------------------SP1 AS1-----------------------------+
[ ]
[ ---- ---- ---- ---- ]
[ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |]
[ |RTR | |RTR | Link |RTR | |RTR |]
[ ---- ---- ---- ---- ]
[ | | ]
[ ---- ---- ]
[ |ASBR| |ASBR| ]
[ |RTR | |RTR | ]
[ ---- ---- ]
^ | | ^
| | | |
| | [ ] | |
| | [ ---- ---- ] | |
| |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| |
| Link [|RTR | |RTR |] Link |
| [ ---- ---- ] |
| [ ] |
| |
+======Backup Inter-AS MPLS TE Tunnel======+
+Transit SP2 AS2,SP3 AS3,etc....SPi ASi+
This section discusses detailed requirements for inter-AS MPLS TE in two principal areas: 1) requirements for inter-AS MPLS TE in the same SP administrative domain and 2) requirements for inter-AS MPLS TE across different SP administrative domains.
本节从两个主要方面讨论了对内部AS MPLS TE的详细要求：1）对同一SP管理域中的内部AS MPLS TE的要求，以及2）对跨不同SP管理域的内部AS MPLS TE的要求。
This section presents detailed requirements for inter-AS MPLS TE within the same SP administrative domain.
本节介绍了同一SP管理域内的内部AS MPLS TE的详细要求。
The inter-AS MPLS TE solution SHOULD be consistent with requirements discussed in [TE-REQ] and the derived solution MUST be such that it will interoperate seamlessly with the current intra-AS MPLS TE mechanism and inherit its capability sets from [TE-RSVP].
内部AS MPLS TE解决方案应与[TE-REQ]中讨论的要求一致，派生解决方案必须能够与当前内部AS MPLS TE机制无缝互操作，并从[TE-RSVP]继承其能力集。
The proposed solution SHOULD allow the provisioning of a TE LSP at the Head/Tail-end with end-to-end Resource Reservation Protocol (RSVP) signaling (eventually with loose paths) traversing across the interconnected ASBRs, without further provisioning required along the transit path.
建议的解决方案应允许在头/尾端提供TE LSP，通过端到端资源预留协议（RSVP）信令（最终采用松散路径）穿越互连的ASBR，而无需沿传输路径进一步提供。
One can conceive that an inter-AS MPLS TE tunnel path signaled across inter-AS links consists of a sequence of ASes, ASBRs, and inter-AS links.
可以设想，跨AS间链路发送信号的AS间MPLS TE隧道路径由一系列AS、asbr和AS间链路组成。
The proposed solution SHOULD provide the ability either to select explicitly or to auto-discover the following elements when signaling the inter-AS TE LSP path:
建议的解决方案应提供明确选择或在向inter-AS-TE LSP路径发送信号时自动发现以下元素的能力：
- a set of AS numbers as loose hops and/or - a set of LSRs including ASBRs
- 一组AS编号，如松散跃点和/或-一组LSR，包括ASBR
It should also specify the above elements in the Explicit Route Object (ERO) and record them in the Record Route Object (RRO) of the Resv message just to keep track of the set of ASes or ASBRs traversed by the inter-AS TE LSP.
它还应在显式路由对象（ERO）中指定上述元素，并将其记录在Resv消息的记录路由对象（RRO）中，以便跟踪AS TE LSP间所遍历的ASE或ASBR集。
In the case of establishing inter-AS TE LSP traversing multiple ASes within the same SP networks, the solution SHOULD also allow the Head-end LSR to explicitly specify the hops across any one of the transiting ASes and the TE tunnel Head-end SHOULD also check the explicit segment to make sure that the constraints are met.
在建立跨同一SP网络内多个ASE的AS-TE LSP的情况下，解决方案还应允许前端LSR显式指定跨任何一个传输ASE的跳数，并且TE隧道前端还应检查显式段以确保满足约束。
In addition, the proposed solution SHOULD provide the ability to specify and signal that certain loose or explicit nodes (e.g., AS numbers, etc.) and resources are to be explicitly excluded in the inter-AS TE LSP path establishment, such as one defined in [EXCLUDE-ROUTE].
此外，所提议的解决方案应提供指定和发出信号的能力，即在AS-TE-LSP路径建立中明确排除某些松散或显式节点（例如，AS号码等）和资源，例如在[EXCLUDE-ROUTE]中定义的节点。
The solution SHOULD allow the set-up of an inter-AS TE LSP that complies with a set of TE constraints defined in [TE-REQ]) and follows an optimal path.
该解决方案应允许设置符合[TE-REQ]中定义的一组TE约束并遵循最佳路径的AS TE间LSP。
An optimal path is defined as a path whose end-to-end cost is minimal, based upon either an IGP or a TE metric. Note that in the case of an inter-AS path across several ASes having completely different IGP metric policies, the notion of minimal path might require IGP metric normalization.
最优路径定义为基于IGP或TE度量的端到端成本最小的路径。注意，在跨具有完全不同IGP度量策略的多个ASE的AS间路径的情况下，最小路径的概念可能需要IGP度量规范化。
The solution SHOULD provide mechanism(s) to compute and establish an optimal end-to-end path for the inter-AS TE LSP and SHOULD also allow for reduced optimality (or sub-optimality) since the path may not remain optimal for the lifetime of the LSP.
解决方案应提供计算和建立AS TE LSP的最佳端到端路径的机制，还应考虑降低的最优性（或次最优性），因为路径在LSP的生命周期内可能不会保持最佳。
Setting up multiple inter-AS TE LSPs between a pair of LSRs might be desirable when:
在以下情况下，可能需要在一对LSR之间设置多个AS TE LSP：
(1) a single TE LSP satisfying the required set of constraints cannot be found, in which case it may require load sharing;
(1) 无法找到满足所需约束集的单个TE LSP，在这种情况下，可能需要负载共享；
(2) multiple TE paths may be required to limit the impact of a network element failure to a portion of the traffic (as an example, two VoIP gateways may load balance the traffic among a set of inter-AS TE LSPs);
(2) 可能需要多个TE路径来限制网元故障对部分业务的影响（例如，两个VoIP网关可以在一组as-TE-lsp之间对业务进行负载平衡）；
(3) path protection (e.g., 1:1 or 1:N) as discussed in [MPLS-Recov].
(3) 如[MPLS Recov]中所述的路径保护（例如，1:1或1:N）。
In the examples above, being able to set up diversely routed TE LSPs becomes a requirement for inter-AS TE.
在上面的示例中，能够设置不同路由的TE LSP成为AS TE间的一个要求。
The solution SHOULD be able to set up a set of link/SRLG/Node diversely routed inter-AS TE LSPs.
该解决方案应能够设置一组链路/SRLG/节点，这些链路/节点作为TE LSP间不同路由。
Once an inter-AS TE LSP has been established, and should there be any resource or other changes inside anyone of the ASes, the solution MUST be able to re-optimize the LSP accordingly and non-disruptively, either upon expiration of a configurable timer or upon being triggered by a network event or a manual request at the TE tunnel Head-End.
一旦建立了AS间TE LSP，并且如果任何ASE内部存在任何资源或其他更改，则解决方案必须能够在可配置计时器过期时或由网络事件或TE隧道前端的手动请求触发时，相应地无中断地重新优化LSP。
The solution SHOULD provide an option for the Head-End LSRs to control if re-optimizing or not should there exist a more optimal path in one of the ASes.
该解决方案应为前端LSR提供一个选项，以便在其中一个ASE中存在更优化的路径时，控制是否重新优化。
In the case of an identical set of traversed paths, the solution SHOULD provide an option for the Head-End LSRs to control whether re-optimization will occur because there could exist a more optimal path in one of the transit ASes along the inter-AS TE LSP path.
在一组相同的遍历路径的情况下，该解决方案应为前端lsr提供一个选项，以控制是否会发生重新优化，因为在沿中间AS TE LSP路径的一个传输ase中可能存在更优化的路径。
Furthermore, the solution MUST provide the ability to reject re-optimization at AS boundaries.
此外，解决方案必须能够拒绝AS边界处的重新优化。
There are, in general, two or more inter-AS links between multiple pairs of ASBRs for redundancy. The topological density between ASes in a SP network with multi-ASes is generally much higher. In the event of an inter-AS link failure, rapid local protection SHOULD also be made available and SHOULD interoperate with the current intra-AS MPLS TE fast re-route mechanism from [TE-FRR].
通常，多对ASBR之间存在两个或多个AS间链路以实现冗余。在具有多个ASE的SP网络中，ASE之间的拓扑密度通常要高得多。在AS间链路故障的情况下，还应提供快速本地保护，并应与[TE-FRR]的当前AS内MPLS TE快速重路由机制进行互操作。
The traffic routed onto an inter-AS TE tunnel SHOULD also be fast protected against any node failure where the node could be internal to an AS or at the AS boundary.
如果节点可能位于AS内部或AS边界处，则路由到AS-TE隧道的流量也应受到快速保护，以防止任何节点故障。
The proposed inter-AS MPLS TE solution SHOULD satisfy core requirements documented in [DS-TE].
建议的内部AS MPLS TE解决方案应满足[DS-TE]中记录的核心要求。
It is worth pointing out that the compatibility clause in section 4.1 of [DS-TE] SHOULD also be faithfully applied to the solution development.
值得指出的是，[DS-TE]第4.1节中的兼容性条款也应忠实地应用于解决方案开发。
The proposed solution(s) MUST have a minimum impact on network scalability from both intra- and inter-AS perspectives.
建议的解决方案必须从AS内部和AS之间的角度对网络可伸缩性产生最小的影响。
This requirement applies to all of the following:
本要求适用于以下所有情况：
- IGP (impact in terms of IGP flooding, path computation, etc.) - BGP (impact in terms of additional information carried within BGP, number of routes, flaps, overload events, etc.) - RSVP TE (impact in terms of message rate, number of retained states, etc.)
- IGP（对IGP泛洪、路径计算等的影响）-BGP（对BGP内携带的附加信息、路由数、襟翼、过载事件等的影响）-RSVP TE（对消息速率、保留状态数等的影响）
It is also conceivable that there would potentially be scalability issues as the number of required inter-AS MPLS TE tunnels increases. In order to reduce the number of tunnel states to be maintained by each transiting PoP, the proposed solution SHOULD allow TE LSP aggregation such that individual tunnels can be carried onto one or more aggregating LSP(s). One such mechanism, for example, is described in [MPLS-LSPHIE].
还可以想象，随着所需的inter-as-MPLS-TE隧道数量的增加，可能存在可伸缩性问题。为了减少每个传输PoP要维护的隧道状态数量，建议的解决方案应允许TE LSP聚合，以便单个隧道可以承载到一个或多个聚合LSP上。例如，在[MPLS-LSPHIE]中描述了一种这样的机制。
There SHOULD be several possibilities to map particular traffic to a particular destination onto a specific inter-AS TE LSP.
应该有几种可能将特定流量映射到特定目的地到特定的inter-AS TE LSP。
For example, static routing could be used if IP destination addresses are known. Another example is to utilize static routing using recursive BGP route resolution.
例如，如果IP目标地址已知，则可以使用静态路由。另一个例子是使用递归BGP路由解析利用静态路由。
The proposed solution SHOULD also provide the ability to "announce" the inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF) with the link's cost associated with it. By doing so, PE routers that do not participate in the inter-AS TE path computation can take into account such links in its IGP-based SPF computation.
建议的解决方案还应提供“宣布”作为接入IGPs（ISIS或OSPF）的链路的MPLS TE隧道的能力，以及与之相关的链路成本。通过这样做，不参与AS-TE路径计算的PE路由器可以在其基于IGP的SPF计算中考虑此类链路。
An inter-AS TE Management Information Base (MIB) is required for use with network management protocols by SPs to manage and configure inter-AS traffic engineering tunnels. This new MIB SHOULD extend (and not reinvent) the existing MIBs to accommodate this new functionality.
SPs需要一个内部AS TE管理信息库（MIB）与网络管理协议一起使用，以管理和配置内部AS流量工程隧道。这个新的MIB应该扩展（而不是改造）现有的MIB以适应这个新功能。
An inter-AS TE MIB should have features that include:
内部AS TE MIB应具有以下功能：
- The setup of inter-AS TE tunnels with associated constraints (e.g., resources). - The collection of traffic and performance statistics not only at the tunnel head-end, but any other points of the TE tunnel. - The inclusion of both IPv4/v6 + AS# or AS# subobjects in the ERO in the path message, e.g.:
- 具有相关约束条件（如资源）的内部隧道的设置不仅在隧道前端，而且在TE隧道的任何其他点收集交通和性能统计数据。-在路径消息的ERO中包含IPv4/v6+AS或AS子对象，例如：
EXPLICIT_ROUTE class object: address1 (loose IPv4 Prefix, /AS1) address2 (loose IPv4 Prefix, /AS1) AS2 (AS number) address3 (loose IPv4 prefix, /AS3) address4 (loose IPv4 prefix, /AS3) - destination
显式路由类对象：address1（松散IPv4前缀，/AS1）address2（松散IPv4前缀，/AS1）AS2（作为编号）address3（松散IPv4前缀，/AS3）address4（松散IPv4前缀，/AS3）-目标
or
或
address1 (loose IPv4 Prefix, /AS1) address2 (loose IPv4 Prefix, /AS1) address3 (loose IPv4 Prefix, /AS2) address4 (loose IPv4 Prefix, /AS2) address5 (loose IPv4 prefix, /AS3) address6 (loose IPv4 prefix, /AS3) - destination
address1（松散IPv4前缀，/AS1）address2（松散IPv4前缀，/AS1）address3（松散IPv4前缀，/AS2）address4（松散IPv4前缀，/AS2）address5（松散IPv4前缀，/AS3）address6（松散IPv4前缀，/AS3）-目标
- Similarly, the inclusion of the RRO object in the Resv message recording sub-objects such as interface IPv4/v6 address (if not hidden), AS number, a label, a node-id (when required), etc. - Inter-AS specific attributes as discussed in section 5 of this document including, for example, inter-AS MPLS TE tunnel accounting records across each AS segment.
- 类似地，将RRO对象包含在Resv消息中，记录子对象，如接口IPv4/v6地址（如果未隐藏）、as编号、标签、节点id（需要时）等，以及本文件第5节中讨论的特定属性，包括：，跨每个AS段的AS间MPLS TE隧道记帐记录。
In a MPLS network, an SP wants to detect both control plane and data plane failures. But tools for fault detection over LSPs haven't been widely developed so far. SPs today manually troubleshoot such failures in a hop-by-hop fashion across the data path. If they detect an error on the data plane, they have to check the control plane in order to determine where the faults come from.
在MPLS网络中，SP希望检测控制平面和数据平面故障。但迄今为止，LSP故障检测工具尚未得到广泛开发。如今，SPs以逐跳方式跨数据路径手动排除此类故障。如果他们在数据平面上检测到错误，他们必须检查控制平面，以确定故障来自何处。
The proposed solution SHOULD be able to interoperate with fault detection mechanisms of intra-AS TE and MAY or MAY NOT require the inter-AS TE tunnel ending addresses to be known or routable across IGP areas (OSPF) or levels (IS-IS) within the transiting ASes with working return paths.
建议的解决方案应能够与内部AS TE的故障检测机制进行互操作，并且可能需要也可能不需要知道内部AS TE隧道结束地址，或者在具有工作返回路径的过渡ASE内的IGP区域（OSPF）或级别（IS-IS）之间进行路由。
For example, [LSPPING] is being considered as a failure detection mechanism over the data plane against the control plane and could be used to troubleshoot intra-AS TE LSPs. Such facilities, if adopted, SHOULD then be extended to inter-AS TE paths.
例如，[lsping]被视为针对控制平面的数据平面上的故障检测机制，可用于对as TE内部LSP进行故障排除。如果采用此类设施，则应将其扩展到内部AS TE路径。
However, the above example depicts one such mechanism that does require a working return path such that diagnostic test packets can return via an alternate data plane, such as a global IPv4 path in the event that the LSP is broken.
然而，上面的示例描述了一种这样的机制，该机制确实需要工作返回路径，使得在LSP被破坏的情况下，诊断测试包可以经由备用数据平面（例如全局IPv4路径）返回。
[MPLS-TTL] presents how TTL may be processed across hierarchical MPLS networks, and such a facility as this SHOULD also be extended to inter-AS TE links.
[MPLS-TTL]介绍了如何在分层MPLS网络中处理TTL，这样的设施也应该扩展到as-TE链路。
The solution(s) MUST allow extensions as both inter-AS MPLS TE and current intra-AS MPLS TE specifications evolve.
随着内部as MPLS TE和当前内部as MPLS TE规范的发展，解决方案必须允许扩展。
The proposed solution(s) SHOULD NOT introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution over SP networks.
建议的解决方案不应给当前运营网络带来不必要的复杂性，从而影响稳定性并降低在SP网络上部署此类解决方案的好处。
The deployment of inter-AS MPLS TE SHOULD NOT impact existing BGP-based traffic engineering or MPLS TE mechanisms, but allow for a smooth migration or co-existence.
内部AS MPLS TE的部署不应影响现有的基于BGP的流量工程或MPLS TE机制，而是允许平滑迁移或共存。
The solution SHOULD be evaluated taking into account various performance criteria:
评估解决方案时应考虑各种性能标准：
- Degree of path optimality of the inter-AS TE LSP path - TE LSP setup time - Failure and restoration time - Impact and scalability of the control plane due to added overheads, etc. - Impact and scalability of the data/forwarding plane due to added overheads, etc.
- AS TE LSP路径的路径优化程度-TE LSP设置时间-故障和恢复时间-由于额外开销等对控制平面的影响和可伸缩性-由于额外开销等对数据/转发平面的影响和可伸缩性。
5.2. Requirements for Inter-AS MPLS TE across Multiple SP Administrative Domains
5.2. 跨多个SP管理域的内部AS MPLS TE要求
The requirements for inter-AS MPLS TE across multiple SP admin domains SHOULD include all requirements discussed in section 5.1 above in addition to those that are presented in this section here.
跨多个SP管理域的内部AS MPLS TE要求应包括上文第5.1节中讨论的所有要求，以及本节中介绍的要求。
Please note that the SP with multi-AS networks may choose not to turn on the features discussed in the following two sections when building TE tunnels across ASes in its own domain.
请注意，具有多AS网络的SP在其自己的域中跨ASE构建TE隧道时，可能会选择不启用以下两节中讨论的功能。
Since an inter-AS TE LSP may span multiple ASes belonging to different SPs, the solution MIGHT allow hiding the set of hops used by the TE LSP within an AS, as illustrated in the following example:
由于AS间TE LSP可以跨越属于不同sp的多个AS，因此该解决方案可以允许在AS内隐藏TE LSP使用的跳集，如以下示例所示：
[ ASBR1-----ASBR2 ]
[ ] [ ]
[ A ] [ B ]
[ AS1 ] [ AS2 ]
[ SP1 ]-----[ SP2 ]
[ ] [ ]
[ ASBR1-----ASBR2 ]
[ ] [ ]
[ A ] [ B ]
[ AS1 ] [ AS2 ]
[ SP1 ]-----[ SP2 ]
[ ] [ ]
Suppose there is an inter-AS TE LSP from A (within AS1 of SP1) to B (within AS2 of SP2). When computing an inter-AS TE LSP path, the set of hops within AS2 might be hidden to AS1. In this case, the solution will allow A to learn that the more optimal TE LSP path to B (that complies with the set of constraints) traverses ASBR2, without a detailed knowledge of the lists of hops used within AS2.
假设有一个从A（在SP1的AS1内）到B（在SP2的AS2内）的AS TE间LSP。当计算AS TE LSP路径时，AS2内的跳集可能对AS1隐藏。在这种情况下，解决方案将允许A了解到到到B的更优化TE LSP路径（符合约束集）穿过ASBR2，而不需要详细了解AS2中使用的跳列表。
Optionally, the TE LSP path cost within AS2 could be provided to A via, for example, PCC-PCE communication, such that A (PCC) could use this information to compute an optimal path, even if the computed path is not provided by AS2. (See [PCE-COM] for PCC-PCE communication and [PCE] for a description of the PCE-based path computation architecture.)
可选地，AS2内的TE LSP路径成本可以提供给via，例如PCC-PCE通信，使得A（PCC）可以使用该信息来计算最佳路径，即使计算出的路径不是由AS2提供的。（参见[PCE-COM]了解PCC-PCE通信，参见[PCE]了解基于PCE的路径计算体系结构的描述。）
In addition, the management requirements discussed in section 5.1.10 above, when used across different SP admin domains, SHOULD include similar confidentiality requirements discussed here in terms of "hiding" intermediate hops or interface address and/or labels in the transiting or peering SPs.
此外，上文第5.1.10节中讨论的管理要求，在跨不同SP管理域使用时，应包括此处讨论的类似保密要求，即在传输或对等SP中“隐藏”中间跃点或接口地址和/或标签。
In some cases, policy control might be necessary at the AS boundaries, namely ingress policy controls enabling SPs to enforce the inter-AS policies per interconnect agreements or to modify some requested parameters conveyed by incoming inter-AS MPLS TE signaling requests.
在某些情况下，可能需要在AS边界处进行策略控制，即入口策略控制，使SP能够根据互连协议强制实施AS间策略，或修改传入AS间MPLS TE信令请求传递的一些请求参数。
It is worth noting that such a policy control mechanism may also be used between ASes within a SP.
值得注意的是，这种策略控制机制也可以在SP内的ASE之间使用。
This section discusses only the elements that may be used to form a set of ingress control policies, but exactly how SPs establish bilateral or multilateral agreements upon which the control policies can be built is beyond the scope of this document.
本节仅讨论可用于形成一套入口控制政策的要素，但SPs如何建立双边或多边协议以制定控制政策超出了本文件的范围。
The following provides a set of TE-LSP parameters in the inter-AS TE Requests (RSVP Path Message) that could be enforced at the AS boundaries:
以下提供了一组可在AS边界强制执行的内部AS TE请求（RSVP路径消息）中的TE-LSP参数：
- RSVP-TE session attributes: affinities and preemption priorities - Per AS or SP bandwidth admission control to ensure that RSVP-TE messages do not request for bandwidth resources over their allocation - Request origins which can be represented by Head-End tunnel ending IP address, originating AS#, neighbor AS#, neighbor ASBR interface IP address, etc. - DS-TE TE-Class <Class-Type, Preemption> - FRR attribute: local protection desired bit, node protection desired bit, and bandwidth protection desired bit carried in the - SESSION ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message as defined in [TE-FRR] - Optimization allowed or not allowed
- RSVP-TE会话属性：亲和力和抢占优先级-根据AS或SP带宽许可控制，以确保RSVP-TE消息不会通过其分配请求带宽资源-请求来源可表示为前端隧道结束IP地址，起始为#，邻居为#，邻居ASBR接口IP地址，etc.-DS-TE TE Class<Class Type，Preemption>-FRR属性：本地保护所需位、节点保护所需位和带宽保护所需位，如[TE-FRR]中定义的，在会话属性或RSVP路径消息中的快速重路由对象中携带-允许或不允许优化
In some cases, a TE policy server could also be used for the enforcement of inter-AS TE policies. Implementations SHOULD allow the use of a policy enforcement server. This requirement could allow SPs to make the inter-AS TE policies scale better.
在某些情况下，TE策略服务器还可用于实施AS TE策略间的交互。实现应允许使用策略实施服务器。这一要求可以使SP更好地扩展AS TE策略。
The signaling of a non-policy-compliant request SHOULD trigger the generation of a RSVP Path Error message by the policy enforcing node towards the Head-end LSR, indicating the cause. The Head-end LSR SHOULD take appropriate actions, such as re-route, upon receipt of such a message.
非策略兼容请求的信令应触发策略实施节点向前端LSR生成RSVP路径错误消息，指示原因。在收到此类消息后，前端LSR应采取适当的措施，例如重新路由。
In some situations, SPs may need to rewrite some attributes of the incoming inter-AS TE signaling requests due to a lack of resources for a particular TE-Class, non-compliant preemption, or mutual agreements. The following provides a non-exhaustive list of the parameters that can potentially be rewritten at the AS boundaries:
在某些情况下，由于缺乏特定TE类的资源、不兼容抢占或相互协议，SP可能需要重写传入AS TE间信令请求的某些属性。以下提供了可能在AS边界重写的参数的非详尽列表：
- RSVP-TE session attributes: affinities and preemption priorities - DS-TE TE-Class <Class-Type, Preemption> - ERO expansion requests
- RSVP-TE会话属性：亲和力和抢占优先级-DS-TE TE类<类类型，抢占>-ERO扩展请求
Similarly, the rewriting node SHOULD generate a RSVP Path Error Message towards the Head-end LSR indicating the cause in terms of types of changes made so as to maintain the end-to-end integrity of the inter-AS TE LSP.
类似地，重写节点应生成朝向前端LSR的RSVP路径错误消息，该消息根据所做更改的类型指示原因，以保持as TE LSP的端到端完整性。
The proposed solution SHOULD also provide a set of policing mechanisms which could be configured on the inter-AS links to ensure that traffic routed through the tunnel does not exceed the bandwidth negotiated during LSP signaling.
建议的解决方案还应提供一组可在AS间链路上配置的监管机制，以确保通过隧道路由的流量不会超过LSP信令期间协商的带宽。
For example, an ingress policer could be configured to enforce the traffic contract on the mutually agreed resource requirements of the established inter-AS TE LSP (i.e., RSVP bandwidth) on the interface to which the inter-AS link is connected.
例如，入口策略可被配置为在AS间链路所连接的接口上对所建立的AS间TE LSP（即，RSVP带宽）的相互商定的资源需求强制执行业务契约。
The proposed solution(s) MUST address security issues across multiple SP administrative domains. Although inter-AS MPLS TE is not expected to add specific security extensions beyond those of current intra-AS TE, greater considerations MUST be given in terms of how to establish a trusted model across AS boundaries. SPs SHOULD have a means to authenticate (such as using RSVP INTEGRITY Object), to allow, and to possibly deny inter-AS signaling requests. Also, SPs SHOULD be protected from DoS attacks.
建议的解决方案必须解决跨多个SP管理域的安全问题。尽管预期内部AS MPLS TE不会在当前内部AS TE之外添加特定的安全扩展，但必须更多地考虑如何跨AS边界建立可信模型。SP应具有身份验证（例如使用RSVP完整性对象）、允许和可能拒绝as间信令请求的方法。此外，应保护SP免受DoS攻击。
We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella, Ed Kern, Jim Boyle, Thomas Nadeau, Yakov Rekhter, and Bert Wijnen for their suggestions and helpful comments during the discussions of this document.
我们要感谢Yuichi Ikejiri、David Allan、Kurt Erik Lindqvist、Dave McDysan、Christian Jacquenet、Kireeti Kompella、Ed Kern、Jim Boyle、Thomas Nadeau、Yakov Rekhter和Bert Wijnen在讨论本文件期间提出的建议和有益意见。
[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月。
[TE-RSVP] 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.
[TE-RSVP]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE:LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[BGP-MPLSVPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP VPNs", Work in Progress, October 2004.
[BGP-MPLSVPN]Rosen，E.和Y.Rekhter，“BGP/MPLS IP VPN”，正在进行的工作，2004年10月。
[DIFF_ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[DIFF_ARCH]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[DIFF_AF] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[DIFF_AF]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保证货运PHB集团”，RFC 25971999年6月。
[DIFF_EF] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[DIFF_EF]Davie，B.，Charny，A.，Bennet，J.C.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[MPLS-Diff] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[MPLS Diff]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[TE-OVW] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[TE-OVW]Awduche，D.，Chiu，A.，Elwalid，A.，Widjaja，I.，和X.Xiao，“互联网流量工程概述和原则”，RFC 3272，2002年5月。
[PSTE] Li, T. and Y. Rekhter, "A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[PSTE]Li，T.和Y.Rekhter，“差异化服务和流量工程的提供商架构（PASTE）”，RFC 2430，1998年10月。
[TE-APP] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002.
[TE-APP]Boyle，J.，Gill，V.，Hannan，A.，Cooper，D.，Awduche，D.，Christian，B.，和W.Lai，“MPLS流量工程的适用性声明”，RFC 33462002年8月。
[GMPLS-ROUT] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[GMPLS-ROUT]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[LSPPING] Kompella, K. and G. Swallow, "Detecting MPLS Data Plane Failures", Work in Progress, May 2005.
[LSping]Kompella，K.和G.Swallow，“检测MPLS数据平面故障”，正在进行的工作，2005年5月。
[MPLS-TTL] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[MPLS-TTL]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
[DS-TE] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DS-TE]Le Faucheur，F.和W.Lai，“支持区分服务感知MPLS流量工程的要求”，RFC 3564，2003年7月。
[TE-FRR] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[TE-FRR]Pan，P.，Swallow，G.和A.Atlas，“LSP隧道RSVP-TE快速改线扩展”，RFC 40902005年5月。
[MPLS-LSPHIE] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, September 2005.
[MPLS-LSPHIE]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年9月。
[MPLS-Recov] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[MPLS Recov]Sharma，V.和F.Hellstrand，“基于多协议标签交换（MPLS）的恢复框架”，RFC 3469，2003年2月。
[EXCLUDE-ROUTE] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to RSVP-TE", Work in Progress, August 2005.
[EXCLUDE-ROUTE]Lee，CY.，Farrel，A.和S.De Cnodder，“EXCLUDE-Routes-延伸至RSVP-TE”，在建工程，2005年8月。
[PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "Path Computation Element (PCE) Architecture", Work in Progress, September 2005.
[PCE]Farrel，A.，Vasseur，J.-P.，和J.Ash，“路径计算元素（PCE）架构”，正在进行的工作，2005年9月。
[PCE-COM] Vasseur, J.-P., et al., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", Work in Progress, September 2005.
[PCE-COM]Vasseur，J.-P.，等，“路径计算元素（PCE）通信协议（PCEP）-第1版”，正在进行的工作，2005年9月。
Appendix A. Brief Description of BGP-based Inter-AS Traffic Engineering
附录A.基于BGP的AS间流量工程简要说明
In today's Service Provider (SP) network, BGP is deployed to meet two different sets of requirements:
在当今的服务提供商（SP）网络中，部署BGP可满足两组不同的要求：
- Establishing a scalable exterior routing plane separate from the data forwarding plane within SP's administrative domain - Exchanging network reachability information with different BGP autonomous systems (ASes) that could belong to a different SP or simply, a different AS within a SP network
- 在SP的管理域内建立一个与数据转发平面分离的可扩展外部路由平面-与不同的BGP自治系统（ASE）交换网络可达性信息，这些系统可能属于不同的SP，也可能属于SP网络内的不同AS
Over connections across the AS boundaries, traffic engineering may also be accomplished via a set of BGP capabilities by appropriately enforcing BGP-based inter-AS routing policies. The current BGP-based inter-AS traffic engineering practices may be summarized as follows:
通过跨越AS边界的连接，还可以通过一组BGP功能通过适当实施基于BGP的AS间路由策略来完成流量工程。当前基于BGP的AS间流量工程实践可总结如下：
- "Closest exit" routing where egress traffic from one SP to another follows the path defined by the lowest IGP or intra-AS MPLS TE tunnel metrics of the BGP next-HOP of exterior routes learned from other ASes over the inter-AS links - "BGP path attribute"-based routing selection mechanism where the egress traffic path is determined by interconnect (peering or transit) policies based upon one or a combination of BGP path attributes, like AS_PATH, MULTI_EXIT_DISC (MED), and Local_Pref.
- “最近出口”路由，其中从一个SP到另一个SP的出口流量遵循最低IGP或内部AS MPLS TE隧道度量定义的路径，该路径是通过AS间链路从其他ASE学习的外部路由的BGP下一跳——“BGP路径属性”——基于路由选择机制，其中出口流量路径由互连确定（对等或传输）策略基于BGP路径属性的一个或组合，如AS_路径、多_退出_光盘（MED）和本地_Pref。
SPs have often faced a number of nondeterministic factors in the practices of inter-AS traffic engineering employing the methods mentioned above:
SP在采用上述方法的AS间流量工程实践中经常面临许多不确定因素：
- Sub-optimum traffic distribution across inter-AS links - Nondeterministic traffic condition changes due to uncoordinated IGP routing policies or topology changes within other AS and uncoordinated BGP routing policy changes (MED or as-prepend, etc.)
- 跨AS间链路的次优流量分布-由于不协调的IGP路由策略或其他AS内的拓扑变化以及不协调的BGP路由策略变化（MED或AS前置器等），导致不确定的流量条件变化
In addition, to achieve some degrees of granularity, SPs may choose to enforce BGP inter-AS policies. These policies are specific to one inter-AS link or to a set of inter-AS links for ingress traffic. By tagging certain sets of routes with a specific attribute when announcing to another AS, the ingress traffic is destined to certain PoPs or to regions within SP's network from another AS. Of course, this operates on the assumption that the other AS permits automated egress policy by matching the predefined attribute from incoming routes.
此外，为了达到一定的粒度，SP可以选择强制实施BGP内部AS策略。这些策略特定于入口流量的一个AS间链路或一组AS间链路。通过在向另一个AS通告时使用特定属性标记某些路由集，入口流量将从另一个AS发送到特定POP或SP网络内的区域。当然，这是基于另一个AS通过匹配传入路由的预定义属性来允许自动出口策略的假设。
Editors' Addresses
编辑地址
Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA
美国加利福尼亚州埃尔塞贡多大大街东2160号张雷蒙信息网服务公司，邮编90025
EMail: raymond_zhang@infonet.com
EMail: raymond_zhang@infonet.com
J.-P. Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
J.-P.Vasseur Cisco Systems，Inc.美国马萨诸塞州Boxborough市比弗布鲁克路300号，邮编01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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.
本文件受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编辑功能的资金目前由互联网协会提供。