Networking Working Group JP. Vasseur, Ed.
Request for Comments: 5152 Cisco Systems, Inc.
Category: Standards Track A. Ayyangar, Ed.
Juniper Networks
R. Zhang
BT
February 2008
Networking Working Group JP. Vasseur, Ed.
Request for Comments: 5152 Cisco Systems, Inc.
Category: Standards Track A. Ayyangar, Ed.
Juniper Networks
R. Zhang
BT
February 2008
A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)
一种建立域间流量工程（TE）标签交换路径（LSP）的单域路径计算方法
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.
本文档规定了一种用于建立域间流量工程（TE）多协议标签交换（MPLS）和通用MPLS（GMPLS）标签交换路径（LSP）的域路径计算技术。在本文档中，域是指地址管理或路径计算责任的公共范围内的网络元素集合，例如内部网关协议（IGP）区域和自治系统。
Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain.
每域计算适用于域间TE LSP的完整路径不能在TE LSP的入口节点处确定或未确定，并且不跨域边界发送信号的情况。这很可能是由于TE可见性限制而产生的。信令消息指示到达下一个域边界的目的地和节点。它还可以指示进一步的域边界或域标识符。必须在域内确定通过每个域的路径，可能包括从域中选择退出点。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. General Assumptions .............................................4
3.1. Common Assumptions .........................................4
3.2. Example of Topology for the Inter-Area TE Case .............6
3.3. Example of Topology for the Inter-AS TE Case ...............7
4. Per-Domain Path Computation Procedures ..........................8
4.1. Example with an Inter-Area TE LSP .........................11
4.1.1. Case 1: T0 Is a Contiguous TE LSP ..................11
4.1.2. Case 2: T0 Is a Stitched or Nested TE LSP ..........12
4.2. Example with an Inter-AS TE LSP ...........................13
4.2.1. Case 1: T1 Is a Contiguous TE LSP ..................13
4.2.2. Case 2: T1 Is a Stitched or Nested TE LSP ..........14
5. Path Optimality/Diversity ......................................14
6. Reoptimization of an Inter-Domain TE LSP .......................15
6.1. Contiguous TE LSPs ........................................15
6.2. Stitched or Nested (non-contiguous) TE LSPs ...............16
6.3. Path Characteristics after Reoptimization .................17
7. Security Considerations ........................................17
8. Acknowledgements ...............................................18
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
1. Introduction ....................................................2
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. General Assumptions .............................................4
3.1. Common Assumptions .........................................4
3.2. Example of Topology for the Inter-Area TE Case .............6
3.3. Example of Topology for the Inter-AS TE Case ...............7
4. Per-Domain Path Computation Procedures ..........................8
4.1. Example with an Inter-Area TE LSP .........................11
4.1.1. Case 1: T0 Is a Contiguous TE LSP ..................11
4.1.2. Case 2: T0 Is a Stitched or Nested TE LSP ..........12
4.2. Example with an Inter-AS TE LSP ...........................13
4.2.1. Case 1: T1 Is a Contiguous TE LSP ..................13
4.2.2. Case 2: T1 Is a Stitched or Nested TE LSP ..........14
5. Path Optimality/Diversity ......................................14
6. Reoptimization of an Inter-Domain TE LSP .......................15
6.1. Contiguous TE LSPs ........................................15
6.2. Stitched or Nested (non-contiguous) TE LSPs ...............16
6.3. Path Characteristics after Reoptimization .................17
7. Security Considerations ........................................17
8. Acknowledgements ...............................................18
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
The requirements for inter-domain Traffic Engineering (inter-area and inter-AS TE) have been developed by the Traffic Engineering Working Group and have been stated in [RFC4105] and [RFC4216]. The framework for inter-domain MPLS Traffic Engineering has been provided in [RFC4726].
域间流量工程（区域间和AS-TE间）的要求已由流量工程工作组制定，并已在[RFC4105]和[RFC4216]中说明。[RFC4726]中提供了域间MPLS流量工程的框架。
Some of the mechanisms used to establish and maintain inter-domain TE LSPs are specified in [RFC5151] and [RFC5150].
[RFC5151]和[RFC5150]中规定了用于建立和维护域间TE LSP的一些机制。
This document exclusively focuses on the path computation aspects and defines a method for establishing inter-domain TE LSPs where each node in charge of computing a section of an inter-domain TE LSP path is always along the path of such a TE LSP.
本文档专门关注路径计算方面，并定义了用于建立域间TE LSP的方法，其中负责计算域间TE LSP路径的一部分的每个节点始终沿着这样的TE LSP的路径。
When the visibility of an end-to-end complete path spanning multiple domains is not available at the Head-end LSR (the LSR that initiated the TE LSP), one approach described in this document consists of using a per-domain path computation technique during LSP setup to determine the inter-domain TE LSP as it traverses multiple domains.
当在前端LSR（启动TE LSP的LSR）处无法看到跨多个域的端到端完整路径时，本文档中描述的一种方法包括在LSP设置期间使用每域路径计算技术，以确定跨多个域的域间TE LSP。
The mechanisms proposed in this document are also applicable to MPLS TE domains other than IGP areas and ASs.
本文件中提出的机制也适用于除IGP区域和ASs之外的MPLS TE域。
The solution described in this document does not attempt to address all the requirements specified in [RFC4105] and [RFC4216]. This is acceptable according to [RFC4216], which indicates that a solution may be developed to address a particular deployment scenario and might, therefore, not meet all requirements for other deployment scenarios.
本文件中描述的解决方案并不试图满足[RFC4105]和[RFC4216]中规定的所有要求。根据[RFC4216]，这是可以接受的，这表明可以开发解决方案来解决特定部署场景，因此可能无法满足其他部署场景的所有要求。
It must be pointed out that the inter-domain path computation technique proposed in this document is one among many others. The choice of the appropriate technique must be driven by the set of requirements for the path attributes and the applicability to a particular technique with respect to the deployment scenario. For example, if the requirement is to get an end-to-end constraint-based shortest path across multiple domains, then a mechanism using one or more distributed PCEs could be used to compute the shortest path across different domains (see [RFC4655]). Other off-line mechanisms for path computation are not precluded either. Note also that a Service Provider may elect to use different inter-domain path computation techniques for different TE LSP types.
必须指出，本文中提出的域间路径计算技术是众多技术之一。选择适当的技术必须由路径属性的一组需求以及特定技术在部署场景中的适用性来驱动。例如，如果要求获得跨多个域的基于端到端约束的最短路径，则可以使用使用一个或多个分布式PCE的机制来计算跨不同域的最短路径（请参见[RFC4655]）。路径计算的其他离线机制也不排除。还要注意，服务提供商可以选择对不同的TE LSP类型使用不同的域间路径计算技术。
Terminology used in this document:
本文件中使用的术语：
AS: Autonomous System.
AS：自治系统。
ABR: Area Border Router, a router used to connect two IGP areas (areas in OSPF or levels in Intermediate System to Intermediate System (IS-IS)).
ABR：区域边界路由器，用于连接两个IGP区域（OSPF中的区域或中间系统中的层到中间系统（IS-IS））的路由器。
ASBR: Autonomous System Border Router, a router used to connect together ASs of a different or the same Service Provider via one or more inter-AS links.
ASBR：自治系统边界路由器，用于通过一个或多个AS间链路将不同或相同服务提供商的ASs连接在一起的路由器。
Boundary LSR: A boundary LSR is either an ABR in the context of inter-area TE or an ASBR in the context of inter-AS TE.
边界LSR：边界LSR是区域间TE上下文中的ABR或区域间TE上下文中的ASBR。
ERO: Explicit Route Object.
ERO：显式路由对象。
IGP: Interior Gateway Protocol.
IGP：内部网关协议。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
内部AS TE LSP：跨越AS边界的TE LSP。
Inter-area TE LSP: A TE LSP that crosses an IGP area.
区域间TE LSP：穿过IGP区域的TE LSP。
LSR: Label Switching Router.
标签交换路由器。
LSP: Label Switched Path.
标签交换路径。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：流量工程标签交换路径。
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：路径计算元素，能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
TED: Traffic Engineering Database.
交通工程数据库。
The notion of contiguous, stitched, and nested TE LSPs is defined in [RFC4726] and will not be repeated here.
[RFC4726]中定义了连续、缝合和嵌套TE LSP的概念，此处不再重复。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
- Each domain in all the examples below is assumed to be capable of doing Traffic Engineering (i.e., running OSPF-TE or ISIS-TE and RSVP-TE (Resource Reservation Protocol Traffic Engineering)). A domain may itself comprise multiple other domains, e.g., an AS may itself be composed of several other sub-ASs (BGP confederations) or areas/levels. In this case, the path computation technique described for inter-area and inter-AS MPLS Traffic Engineering applies recursively.
- 假设以下所有示例中的每个域都能够进行流量工程（即，运行OSPF-TE或ISIS-TE和RSVP-TE（资源预留协议流量工程））。域本身可包括多个其他域，例如，AS本身可由若干其他子ASs（BGP联盟）或区域/级别组成。在这种情况下，针对区域间和区域间AS-MPLS流量工程描述的路径计算技术递归地应用。
- The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and [RFC3473]).
- 域间TE lsp使用RSVP-TE（[RFC3209]和[RFC3473]）发送信号。
- The path (specified by an ERO (Explicit Route Object) in an RSVP-TE Path message) for an inter-domain TE LSP may be signaled as a set of (loose and/or strict) hops.
- 域间TE LSP的路径（由RSVP-TE路径消息中的ERO（显式路由对象）指定）可以作为一组（松散和/或严格）跳发送信号。
- The hops may identify:
- 啤酒花可识别：
* The complete strict path end-to-end across different domains
* 跨不同域端到端的完整严格路径
* The complete strict path in the source domain followed by boundary LSRs (or domain identifiers, e.g., AS numbers)
* 源域中的完整严格路径，后跟边界LSR（或域标识符，如数字）
* The complete list of boundary LSRs along the path
* 沿路径的边界LSR的完整列表
* The current boundary LSR and the LSP destination
* 当前边界LSR和LSP目标
The set of (loose or strict) hops can be either statically configured on the Head-end LSR or dynamically computed. A per-domain path computation method is defined in this document with an optional auto-discovery mechanism (e.g., based on IGP, BGP, policy routing information) yielding the next-hop boundary node (domain exit point, such as an Area Border Router (ABR) or an Autonomous System Border Router (ASBR)) along the path as the TE LSP is being signaled, along with potential crankback mechanisms. Alternatively, the domain exit points may be statically configured on the Head-end LSR, in which case next-hop boundary node auto-discovery would not be required.
可以在前端LSR上静态配置（松散或严格）跳集，也可以动态计算跳集。本文件中定义了每域路径计算方法，该方法具有可选的自动发现机制（例如，基于IGP、BGP、策略路由信息），在发送TE LSP信号时沿路径生成下一跳边界节点（域出口点，例如区域边界路由器（ABR）或自治系统边界路由器（ASBR）），以及潜在的回退机制。或者，域出口点可以在前端LSR上静态配置，在这种情况下，不需要下一跳边界节点自动发现。
- Boundary LSRs are assumed to be capable of performing local path computation for expansion of a loose next hop in the signaled ERO if the path is not signaled by the Head-end LSR as a set of strict hops or if the strict hop is an abstract node (e.g., an AS). In any case, no topology or resource information needs to be distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple routing domains.
- 如果路径不是由前端LSR作为一组严格跳发送的，或者如果严格跳是一个抽象节点（例如，as），则假设边界LSR能够执行本地路径计算，以扩展有信号的ERO中的松散下一跳。在任何情况下，不需要在域之间分发拓扑或资源信息（按照[RFC4105]和[RFC4216]的规定），这对于在跨多个路由域的TE LSP的情况下保持IGP/BGP可伸缩性和机密性至关重要。
- The paths for the intra-domain Hierarchical LSP (H-LSP) or Stitched LSP (S-LSP) or for a contiguous TE LSP within the domain may be pre-configured or computed dynamically based on the arriving inter-domain LSP setup request (depending on the requirements of the transit domain). Note that this capability is explicitly specified as a requirement in [RFC4216]. When the paths for the H-LSP/S-LSP are pre-configured, the constraints as well as other parameters like a local protection scheme for the intra-domain H-LSP/S-LSP are also pre-configured.
- 域内的域内分层LSP（H-LSP）或缝合LSP（S-LSP）或连续TE LSP的路径可以基于到达的域间LSP设置请求（取决于传输域的要求）预先配置或动态计算。注意，该功能在[RFC4216]中明确规定为要求。当H-LSP/S-LSP的路径被预配置时，约束以及诸如域内H-LSP/S-LSP的本地保护方案等其他参数也被预配置。
- While certain constraints like bandwidth can be used across different domains, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] may need to be translated at domain boundaries. If required, it is assumed that, at the domain boundary LSRs, there will exist some sort of local mapping based on policy agreement in order to translate such constraints across domain boundaries. It is expected that such an assumption particularly applies to inter-AS TE: for example, the local mapping would be similar to the inter-AS TE agreement enforcement polices stated in [RFC4216].
- 虽然带宽等某些约束可以跨不同的域使用，但[RFC2702]中列出的资源亲和力、颜色、度量等某些其他TE约束可能需要在域边界处转换。如果需要，假设在域边界LSR处，存在基于策略协议的某种局部映射，以便跨域边界转换此类约束。预计这种假设特别适用于AS TE间：例如，本地映射类似于[RFC4216]中规定的AS TE间协议执行策略。
- The procedures defined in this document are applicable to any node (not just a boundary node) that receives a Path message with an ERO that constrains a loose hop or an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR).
- 本文档中定义的过程适用于接收路径消息的任何节点（不仅仅是边界节点），该路径消息具有约束松散跃点的ERO或不是简单抽象节点的抽象节点（即，标识多个LSR的抽象节点）。
The following example will be used for the inter-area TE case in this document.
以下示例将用于本文件中的区域间TE案例。
<-area 1-><-- area 0 --><--- area 2 --->
------ABR1------------ABR3-------
| / | | \ |
R0--X1 | | X2---X3--R1
| | | / |
------ABR2-----------ABR4--------
<=========== Inter-area TE LSP =======>
<-area 1-><-- area 0 --><--- area 2 --->
------ABR1------------ABR3-------
| / | | \ |
R0--X1 | | X2---X3--R1
| | | / |
------ABR2-----------ABR4--------
<=========== Inter-area TE LSP =======>
Figure 1 - Example of topology for the inter-area TE case
图1-区域间TE情况的拓扑示例
Description of Figure 1:
图1的说明：
- ABR1, ABR2, ABR3, and ABR4 are ABRs. - X1 is an LSR in area 1. - X2 and X3 are LSRs in area 2. - An inter-area TE LSP T0 originated at R0 in area 1 and terminated at R1 in area 2.
- ABR1、ABR2、ABR3和ABR4是ABR。-X1是区域1中的LSR。-X2和X3是区域2中的LSR。-区域间TE LSP T0起源于区域1中的R0，终止于区域2中的R1。
Notes:
笔记：
- The terminology used in the example above corresponds to OSPF, but the path computation technique proposed in this document equally applies to the case of an IS-IS multi-level network.
- 上述示例中使用的术语对应于OSPF，但本文中提出的路径计算技术同样适用于IS-IS多级网络的情况。
- Just a few routers in each area are depicted in the diagram above for the sake of simplicity.
- 为了简单起见，上图中只描述了每个区域中的几个路由器。
- The example depicted in Figure 1 shows the case where the Head-end and Tail-end areas are connected by means of area 0. The case of an inter-area TE LSP between two IGP areas that does not transit through area 0 is not precluded.
- 图1所示的示例显示了通过区域0连接前端和后端区域的情况。不排除两个IGP区域之间不通过区域0的区域间TE LSP的情况。
We consider the following general case, built on a superset of the various scenarios defined in [RFC4216]:
我们考虑下面的一般情况，建立在[RCF4216]中定义的各种场景的超集上：
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | |
R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
<---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | |
R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
<======= Inter-AS TE LSP (LSR to LSR)===========>
or
<======= Inter-AS TE LSP (LSR to LSR)===========>
or
<======== Inter-AS TE LSP (CE to ASBR) =>
<======== Inter-AS TE LSP (CE to ASBR) =>
or
或
<================= Inter-AS TE LSP (CE to CE)===============>
<================= Inter-AS TE LSP (CE to CE)===============>
Figure 2 - Example of topology for the inter-AS TE case
图2-内部AS TE情况的拓扑示例
The diagram depicted in Figure 2 covers all the inter-AS TE deployment cases described in [RFC4216].
图2中所示的图涵盖了[RFC4216]中描述的所有AS-TE间部署案例。
Description of Figure 2:
图2的说明：
- Three interconnected ASs, respectively AS1, AS2, and AS3. Note that in some scenarios described in [RFC4216] AS1=AS3.
- 三个相互连接的ASs，分别为AS1、AS2和AS3。请注意，在[RFC4216]AS1=AS3中描述的某些场景中。
- The ASBRs in different ASs are BGP peers. There is usually no IGP running on the single hop links interconnecting the ASBRs and also referred to as inter-ASBR links.
- 不同ASs中的ASBR是BGP对等点。通常在连接ASBR的单跳链路上没有IGP运行，也被称为ASBR间链路。
- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In other words, the ASs are TE enabled.
- 每个AS运行具有所需IGP TE扩展的IGP（IS-IS或OSPF）（参见[RFC3630]、[RFC3784]、[RFC4203]和[RFC4205]）。换句话说，ASs是启用的。
- CE: Customer Edge router.
- CE：客户边缘路由器。
- Each AS can be made of several IGP areas. The path computation technique described in this document applies to the case of a single AS made of multiple IGP areas, multiple ASs made of a single IGP area, or any combination of the above. For the sake of simplicity, each routing domain will be considered as a single area
- 每个AS可以由几个IGP区域组成。本文件中描述的路径计算技术适用于由多个IGP区域构成的单个AS、由单个IGP区域构成的多个ASs或上述任意组合的情况。为了简单起见，每个路由域将被视为单个区域
in this document. The case of an inter-AS TE LSP spanning multiple ASs where some of those ASs are themselves made of multiple IGP areas can be easily derived from the examples above: the per-domain path computation technique described in this document is applied recursively in this case.
在本文件中。跨越多个ASs的AS-TE LSP的情况，其中一些ASs本身由多个IGP区域构成，可以容易地从上述示例中导出：在这种情况下，递归地应用本文档中描述的每域路径计算技术。
- An inter-AS TE LSP T1 originated at R0 in AS1 and terminated at R6 in AS3.
- AS间TE LSP T1在AS1中起源于R0，在AS3中终止于R6。
The mechanisms for inter-domain TE LSP computation as described in this document can be used regardless of the nature of the inter-domain TE LSP (contiguous, stitched, or nested).
无论域间TE LSP的性质如何（连续、缝合或嵌套），都可以使用本文档中描述的域间TE LSP计算机制。
Note that any path can be defined as a set of loose and strict hops. In other words, in some cases, it might be desirable to rely on the dynamic path computation in some domains, and exert a strict control on the path in other domains (defining strict hops).
请注意，任何路径都可以定义为一组松散和严格的跃点。换句话说，在某些情况下，可能需要依赖某些域中的动态路径计算，并对其他域中的路径施加严格控制（定义严格的跳数）。
When an LSR that is a boundary node such as an ABR/ASBR receives a Path message with an ERO that contains a strict node, the procedures specified in [RFC3209] apply and no further action is needed.
当作为边界节点（如ABR/ASBR）的LSR接收到带有包含严格节点的ERO的路径消息时，[RFC3209]中规定的程序适用，无需采取进一步措施。
When an LSR that is a boundary node such as an ABR/ASBR receives a Path message with an ERO that contains a loose hop or an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR), then it MUST follow the procedures as described in [RFC5151].
当作为边界节点（如ABR/ASBR）的LSR接收到包含松散跃点的ERO的路径消息或不是简单抽象节点的抽象节点（即，标识多个LSR的抽象节点）时，它必须遵循[RFC5151]中所述的过程。
In addition, the following procedures describe the path computation procedures that SHOULD be carried out on the LSR:
此外，以下程序描述了应在LSR上执行的路径计算程序：
1) If the next hop is not present in the TED, the two following conditions MUST be checked:
1) 如果TED中不存在下一个跃点，则必须检查以下两个条件：
o Whether the IP address of the next-hop boundary LSR is outside of the current domain
o 下一跳边界LSR的IP地址是否在当前域之外
o Whether the next-hop domain is PSC (Packet Switch Capable) and uses in-band control channel
o 下一跳域是否为PSC（支持分组交换）并使用带内控制信道
If the two conditions above are satisfied, then the boundary LSR SHOULD check if the next hop has IP reachability (via IGP or BGP). If the next hop is not reachable, then a signaling failure occurs and the LSR SHOULD send back an RSVP PathErr message upstream with error code=24 ("Routing Problem") and error subcode as described in section 4.3.4 of [RFC3209]. If the available routing information indicates
如果满足上述两个条件，则边界LSR应检查下一跳是否具有IP可达性（通过IGP或BGP）。如果无法到达下一跳，则发生信令故障，LSR应向上游发送RSVP PathErr消息，错误代码为24（“路由问题”）和错误子代码，如[RFC3209]第4.3.4节所述。如果可用的路由信息显示
that next hop is reachable, the selected route will be expected to pass through a domain boundary via a domain boundary LSR. The determination of domain boundary point based on routing information is what we term as "auto-discovery" in this document. In the absence of such an auto-discovery mechanism, a) the ABR in the case of inter-area TE or the ASBR in the next-hop AS in the case of inter-AS TE should be the signaled loose next hop in the ERO and hence should be accessible via the TED, or b) there needs to be an alternate scheme that provides the domain exit points. Otherwise, the path computation for the inter-domain TE LSP will fail.
如果下一跳是可到达的，则所选路由将通过域边界LSR通过域边界。基于路由信息确定域边界点在本文中被称为“自动发现”。在缺乏这种自动发现机制的情况下，a）区域间TE情况下的ABR或下一跳情况下的ASBR（如区域间TE情况下的ASBR）应为ERO中的信号松散下一跳，因此应可通过TED访问，或b）需要提供域出口点的替代方案。否则，域间TE LSP的路径计算将失败。
An implementation MAY support the ability to disable such an IP reachability fall-back option should the next-hop boundary LSR not be present in the TED. In other words, an implementation MAY support the possibility to trigger a signaling failure whenever the next hop is not present in the TED.
如果TED中不存在下一跳边界LSR，则实现可支持禁用此类IP可达性回退选项的能力。换句话说，实现可以支持每当下一跳不在TED中时触发信令失败的可能性。
2) Once the next-hop boundary LSR has been determined (according to the procedure described in 1)) or if the next-hop boundary is present in the TED:
2) 一旦确定了下一跳边界LSR（根据1中描述的过程），或者如果下一跳边界存在于TED中：
o Case of a contiguous TE LSP. Unless not allowed by policy, the boundary LSR that processes the ERO SHOULD perform an ERO expansion (a process consisting of computing the constrained path up to the next loose hop and adding the list of hops as strict nodes in the ERO). If no path satisfying the set of constraints can be found, then this is treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent for the inter-domain TE LSP based on section 4.3.4 of [RFC3209].
o 连续TE LSP的情况。除非政策不允许，否则处理ERO的边界LSR应执行ERO扩展（该过程包括计算到下一个松散跃点的受限路径，并将跃点列表添加为ERO中的严格节点）。如果找不到满足约束集的路径，则这将被视为路径计算和信令故障，并且应根据[RFC3209]第4.3.4节为域间TE LSP发送RSVP PathErr消息。
o Case of a stitched or nested TE LSP
o 缝合或嵌套TE LSP的情况
* If the boundary LSR is a candidate LSR for intra-area H-LSP/ S-LSP setup (the boundary has local policy for nesting or stitching), the TE LSP is a candidate for hierarchy/nesting (the "Contiguous LSP" bit defined in [RFC5151] is not set), and if there is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR that satisfies the constraints, it SHOULD signal an H-LSP/S-LSP to the next-hop boundary LSR. If a pre-configured H-LSP(s) or S-LSP(s) already exists, then it will try to select from among those intra-domain LSPs. Depending on local policy, it MAY signal a new H-LSP/S-LSP if this selection fails. If the H-LSP/S-LSP is successfully signaled or selected, it propagates the inter-domain Path message to the next hop following the procedures described in [RFC5151]. If for some reason the dynamic H-LSP/S-LSP setup to the next-hop boundary LSR fails, then this SHOULD
* 如果边界LSR是区域内H-LSP/S-LSP设置的候选LSR（边界具有嵌套或缝合的本地策略），则TE LSP是层次/嵌套的候选LSR（未设置[RFC5151]中定义的“连续LSP”位），并且如果从该LSR到下一跳边界LSR没有满足约束的H-LSP/S-LSP，它应该向下一跳边界LSR发送H-LSP/S-LSP信号。如果预先配置的H-LSP或s-LSP已经存在，则它将尝试从这些域内LSP中进行选择。根据本地策略，如果此选择失败，它可能会发出新的H-LSP/S-LSP信号。如果H-LSP/S-LSP成功发送信号或被选择，它将按照[RFC5151]中描述的步骤将域间路径消息传播到下一跳。如果由于某种原因，下一跳边界LSR的动态H-LSP/S-LSP设置失败，则应
be treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent upstream for the inter-domain LSP. Similarly, if selection of a pre-configured H-LSP/S-LSP fails and local policy prevents dynamic H-LSP/S, this SHOULD be treated as a path computation and signaling failure and an RSVP PathErr message SHOULD be sent upstream for the inter-domain TE LSP. In both of these cases, procedures described in section 4.3.4 of [RFC3209] SHOULD be followed to handle the failure.
将被视为路径计算和信令故障，并且应向域间LSP的上游发送RSVP PathErr消息。类似地，如果预先配置的H-LSP/S-LSP的选择失败并且本地策略阻止动态H-LSP/S，则这应被视为路径计算和信令失败，并且应向上游发送域间TE LSP的RSVP PathErr消息。在这两种情况下，应遵循[RFC3209]第4.3.4节中描述的程序来处理故障。
* If, however, the boundary LSR is not a candidate for intra-domain H-LSP/S-LSP (the boundary LSR does not have local policy for nesting or stitching) or the TE LSP is not a candidate for hierarchy/nesting (the "Contiguous LSP" bit defined in [RFC5151] is set), then it SHOULD apply the same procedure as for the contiguous case.
* 然而，如果边界LSR不是域内H-LSP/S-LSP的候选（边界LSR没有用于嵌套或缝合的本地策略）或TE LSP不是层次结构/嵌套的候选（设置了[RFC5151]中定义的“连续LSP”位），则其应应用与连续情况相同的过程。
The ERO of an inter-domain TE LSP may comprise abstract nodes such as ASs. In such a case, upon receiving the ERO whose next hop is an AS, the boundary LSR has to determine the next-hop boundary LSR, which may be determined based on the auto-discovery process mentioned above. If multiple ASBR candidates exist, the boundary LSR may apply some policies based on peering contracts that may have been pre-negotiated. Once the next-hop boundary LSR has been determined, a similar procedure as the one described above is followed.
域间TE LSP的ERO可以包括抽象节点，例如ASs。在这种情况下，在接收到其下一跳是as的ERO时，边界LSR必须确定下一跳边界LSR，该下一跳边界LSR可以基于上述自动发现过程来确定。如果存在多个ASBR候选者，则边界LSR可基于可能已预先协商的对等合同应用某些策略。一旦确定了下一跳边界LSR，则遵循与上述步骤类似的步骤。
Note the following related to the inter-AS TE case:
请注意以下与inter AS TE案例相关的内容：
In terms of computation of an inter-AS TE LSP path, an interesting optimization technique consists of allowing the ASBRs to flood the TE information related to the inter-ASBR link(s) although no IGP TE is enabled over those links (and so there is no IGP adjacency over the inter-ASBR links). This of course implies that the inter-ASBR links be TE-enabled although no IGP is running on those links.
就计算AS-TE-LSP路径而言，一种有趣的优化技术包括允许ASBR淹没与ASBR链路相关的TE信息，尽管在这些链路上没有启用IGP-TE（因此在ASBR链路上没有IGP邻接）。当然，这意味着ASBR之间的链路将启用TE，尽管这些链路上没有运行IGP。
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | |
R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
<---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | |
R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
Figure 3 - Flooding of the TE-related information for the inter-ASBR links
图3-ASBR间链路TE相关信息的泛滥
Referring to Figure 3, ASBR1 for example would advertise in its OSPF Link State Advertisement (LSA)/IS-IS LSP the Traffic Engineering TLVs related to the link ASBR1-ASBR4.
参考图3，例如，ASBR1将在其OSPF链路状态公告（LSA）/IS-IS LSP中公告与链路ASBR1-ASBR4相关的流量工程TLV。
This allows an LSR (could be the entry ASBR) in the previous AS to make a more appropriate route selection up to the entry ASBR in the immediately downstream AS taking into account the constraints associated with the inter-ASBR links. This reduces the risk of call setup failure due to inter-ASBR links not satisfying the inter-AS TE LSP set of constraints. Note that the TE information is only related to the inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not only the TE-enabled links contained in the AS but also the inter-ASBR links.
这允许前面AS中的LSR（可以是入口ASBR）在考虑到与ASBR间链路相关的约束的情况下，对直接下游的入口ASBR进行更合适的路由选择。这降低了由于ASBR间链路不满足AS TE LSP间约束集而导致呼叫设置失败的风险。请注意，TE信息仅与ASBR间链路相关：ASBR淹没的TE LSA/LSP不仅包括AS中包含的启用TE的链路，还包括ASBR间链路。
Note that no summarized TE information is leaked between ASs, which is compliant with the requirements listed in [RFC4105] and [RFC4216].
注意，ASs之间未泄露任何TE汇总信息，符合[RFC4105]和[RFC4216]中列出的要求。
For example, consider the diagram depicted in Figure 2: when ASBR1 floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) in its routing domain, it reflects the reservation states and TE properties of the following links: X1-ASBR1, ASBR1-ASBR2, and ASBR1-ASBR4.
例如，考虑图2所示的图：当ASBR1在其路由域中淹没其IGP TE LSA（OSPF OSPF）/LSP（IS-IS的TLV 22）时，它反映以下链路的保留状态和TE特性：X1-ASBR1、ASBR1-ASBR2和ASBR1-ASBR4。
Thanks to such an optimization, the inter-ASBR TE link information corresponding to the links originated by the ASBR is made available in the TED of other LSRs in the same domain to which the ASBR belongs. Consequently, the path computation for an inter-AS TE LSP path can also take into account the inter-ASBR link(s). This will improve the chance of successful signaling along the next AS in case of resource shortage or unsatisfied constraints on inter-ASBR links, and it potentially reduces one level of crankback. Note that no topology information is flooded, and these links are not used in IGP SPF computations. Only the TE information for the outgoing links directly connected to the ASBR is advertised.
由于这种优化，与ASBR发起的链路相对应的ASBR间TE链路信息在ASBR所属的同一域中的其他lsr的TED中可用。因此，AS-TE-LSP路径的路径计算也可以考虑AS-br链路。这将提高在资源短缺或ASBR间链路上的约束不满足的情况下，在下一条链路上成功发送信号的机会，并可能减少一级回退。请注意，没有拓扑信息被淹没，并且这些链路不用于IGP SPF计算。仅公布直接连接到ASBR的传出链接的TE信息。
Note that an operator may decide to operate a stitched segment or 1-hop hierarchical LSP for the inter-ASBR link.
注意，操作员可能决定为ASBR间链路操作缝合段或1跳分层LSP。
The following example uses Figure 1 as a reference.
下面的示例使用图1作为参考。
The Head-end LSR (R0) first determines the next-hop ABR (which could be manually configured by the user or dynamically determined by using the auto-discovery mechanism). R0 then computes the path to reach the selected next-hop ABR (ABR1) and signals the Path message. When
前端LSR（R0）首先确定下一跳ABR（可由用户手动配置或使用自动发现机制动态确定）。然后，R0计算到达所选下一跳ABR（ABR1）的路径，并向路径消息发送信号。什么时候
the Path message reaches ABR1, it first determines the next-hop ABR from its area 0 along the LSP path (say, ABR3), either directly from the ERO (if for example the next-hop ABR is specified as a loose hop in the ERO) or by using the auto-discovery mechanism specified above.
路径消息到达ABR1时，它首先从其区域0沿LSP路径（例如，ABR3）确定下一跳ABR，或者直接从ERO（例如，如果下一跳ABR在ERO中被指定为松散跳）或者通过使用上面指定的自动发现机制。
- Example 1 (set of loose hops): R0-ABR1(loose)-ABR3(loose)-R1(loose)
- 示例1（一组松散跃点）：R0-ABR1（松散）-ABR3（松散）-R1（松散）
- Example 2 (mix of strict and loose hops): R0-X1-ABR1-ABR3(loose)-X2-X3-R1
- 示例2（严格啤酒花和松散啤酒花的混合）：R0-X1-ABR1-ABR3（松散）-X2-X3-R1
Note that a set of paths can be configured on the Head-end LSR, ordered by priority. Each priority path can be associated with a different set of constraints. It may be desirable to systematically have a last-resort option with no constraint to ensure that the inter-area TE LSP could always be set up if at least a TE path exists between the inter-area TE LSP source and destination. In case of setup failure or when an RSVP PathErr is received indicating that the TE LSP has suffered a failure, an implementation might support the possibility of retrying a particular path option a configurable amount of times (optionally with dynamic intervals between each trial) before trying a lower-priority path option.
请注意，可以在前端LSR上按优先级顺序配置一组路径。每个优先级路径都可以与一组不同的约束相关联。如果在区域间TE LSP源和目的地之间至少存在TE路径，则可能希望系统地具有无约束的最后手段选项以确保始终可以设置区域间TE LSP。在设置失败的情况下，或者当接收到指示TE LSP已发生故障的RSVP PathErr时，实现可能支持在尝试较低优先级的路径选项之前以可配置的次数重试特定路径选项（可选地，每次尝试之间具有动态间隔）。
Once it has computed the path up to the next-hop ABR (ABR3), ABR1 sends the Path message along the computed path. Upon receiving the Path message, ABR3 then repeats a similar procedure. If ABR3 cannot find a path obeying the set of constraints for the inter-area TE LSP, the signaling process stops and ABR3 sends a PathErr message to ABR1. Then ABR1 can in turn trigger a new path computation by selecting another egress boundary LSR (ABR4 in the example above) if crankback is allowed for this inter-area TE LSP (see [RFC4920]). If crankback is not allowed for that inter-area TE LSP or if ABR1 has been configured not to perform crankback, then ABR1 MUST stop the signaling process and MUST forward a PathErr up to the Head-end LSR (R0) without trying to select another ABR.
一旦计算到下一跳ABR（ABR3）的路径，ABR1就沿着计算出的路径发送路径消息。在接收到Path消息后，ABR3随后重复类似的过程。如果ABR3无法找到符合区域间TE LSP约束集的路径，则信令过程停止，ABR3向ABR1发送PathErr消息。然后，如果该区域间TE LSP允许回退，则ABR1可以通过选择另一出口边界LSR（上例中为ABR4）来触发新的路径计算（参见[RFC4920]）。如果该区域间TE LSP不允许回退，或者如果ABR1已配置为不执行回退，则ABR1必须停止信令过程，并且必须将PathErr转发到前端LSR（R0），而不尝试选择另一个ABR。
The Head-end LSR (R0) first determines the next-hop ABR (which could be manually configured by the user or dynamically determined by using the auto-discovery mechanism). R0 then computes the path to reach the selected next-hop ABR and signals the Path message. When the Path message reaches ABR1, it first determines the next-hop ABR from its area 0 along the LSP path (say ABR3), either directly from the ERO (if for example the next-hop ABR is specified as a loose hop in the ERO) or by using an auto-discovery mechanism, specified above.
前端LSR（R0）首先确定下一跳ABR（可由用户手动配置或使用自动发现机制动态确定）。然后，R0计算到达所选下一跳ABR的路径，并向路径消息发送信号。当路径消息到达ABR1时，它首先从其区域0沿LSP路径（例如ABR3）确定下一跳ABR，或者直接从ERO（例如，如果下一跳ABR在ERO中被指定为松散跳）或者通过使用上面指定的自动发现机制。
ABR1 then checks whether it has an H-LSP or S-LSP to ABR3 matching the constraints carried in the inter-area TE LSP Path message. If not, ABR1 computes the path for an H-LSP or S-LSP from ABR1 to ABR3 satisfying the constraint and sets it up accordingly. Note that the H-LSP or S-LSP could have also been pre-configured.
然后，ABR1检查其是否具有与区域间TE LSP路径消息中携带的约束相匹配的H-LSP或S-LSP到ABR3。如果没有，ABR1计算满足该约束的H-LSP或S-LSP从ABR1到ABR3的路径，并相应地进行设置。请注意，H-LSP或S-LSP也可以预先配置。
Once ABR1 has selected the H-LSP/S-LSP for the inter-area LSP, using the signaling procedures described in [RFC5151], ABR1 sends the Path message for the inter-area TE LSP to ABR3. Note that irrespective of whether ABR1 does nesting or stitching, the Path message for the inter-area TE LSP is always forwarded to ABR3. ABR3 then repeats the exact same procedures. If ABR3 cannot find a path obeying the set of constraints for the inter-area TE LSP, ABR3 sends a PathErr message to ABR1. Then ABR1 can in turn either select another H-LSP/S-LSP to ABR3 if such an LSP exists or select another egress boundary LSR (ABR4 in the example above) if crankback is allowed for this inter-area TE LSP (see [RFC4920]). If crankback is not allowed for that inter-area TE LSP or if ABR1 has been configured not to perform crankback, then ABR1 forwards the PathErr up to the inter-area Head-end LSR (R0) without trying to select another egress LSR.
一旦ABR1使用[RFC5151]中描述的信令过程为区域间LSP选择了H-LSP/S-LSP，ABR1就向ABR3发送区域间TE LSP的路径消息。注意，无论ABR1是嵌套还是缝合，用于区域间TE LSP的路径消息总是转发给ABR3。ABR3然后重复完全相同的程序。如果ABR3无法找到符合区域间TE LSP约束集的路径，ABR3将向ABR1发送PathErr消息。然后，如果存在另一个H-LSP/S-LSP到ABR3，则ABR1可以依次选择另一个H-LSP/S-LSP，或者如果该区域间TE LSP允许回退，则选择另一个出口边界LSR（上例中为ABR4）（参见[RFC4920]）。如果区域间TE LSP不允许回退，或者如果ABR1已配置为不执行回退，则ABR1将路径转发至区域间前端LSR（R0），而不尝试选择其他出口LSR。
The following example uses Figure 2 as a reference.
下面的示例使用图2作为参考。
The path computation procedures for establishing an inter-AS TE LSP are very similar to those of an inter-area TE LSP described above. The main difference is related to the presence of inter-ASBR link(s).
用于建立区域间AS TE LSP的路径计算过程与上述区域间TE LSP的路径计算过程非常相似。主要差异与ASBR间链路的存在有关。
The inter-AS TE path may be configured on the Head-end LSR as a set of strict hops, loose hops, or a combination of both.
在前端LSR上，可以将内部AS TE路径配置为一组严格跳、松散跳或两者的组合。
- Example 1 (set of loose hops): ASBR4(loose)-ASBR9(loose)-R6(loose)
- 示例1（松散跃点集）：ASBR4（松散）-ASBR9（松散）-R6（松散）
- Example 2 (mix of strict and loose hops): R2-ASBR3-ASBR2-ASBR1-ASBR4-ASBR10(loose)-ASBR9-R6
- 示例2（严格和松散啤酒花的混合）：R2-ASBR3-ASBR2-ASBR1-ASBR4-ASBR10（松散）-ASBR9-R6
In example 1 above, a per-AS path computation is performed, respectively on R0 for AS1, ASBR4 for AS2, and ASBR9 for AS3. Note that when an LSR has to perform an ERO expansion, the next hop either must belong to the same AS or must be the ASBR directly connected to the next hop AS. In this latter case, the ASBR reachability is announced in the IGP TE LSA/LSP originated by its neighboring ASBR. In example 1 above, the TE LSP path is defined as: ASBR4(loose)- ASBR9(loose)-R6(loose). This implies that R0 must compute the path
在上面的示例1中，分别对AS1的R0、AS2的ASBR4和AS3的ASBR9执行按AS路径计算。请注意，当LSR必须执行ERO扩展时，下一跳必须属于相同的AS，或者必须是直接连接到下一跳AS的ASBR。在后一种情况下，ASBR可达性在其相邻ASBR发起的IGP TE LSA/LSP中宣布。在上面的示例1中，TE LSP路径定义为：ASBR4（松散）-ASBR9（松散）-R6（松散）。这意味着R0必须计算路径
from R0 to ASBR4, hence the need for R0 to get the TE reservation state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In addition, ASBR1 must also announce the IP address of ASBR4 specified in T1's path configuration.
从R0到ASBR4，因此R0需要获取与ASBR1-ASBR4链路相关的TE保留状态（ASBR1在AS1中淹没）。此外，ASBR1还必须宣布在T1的路径配置中指定的ASBR4的IP地址。
Once it has computed the path up to the next-hop ASBR, ASBR1 sends the Path message for the inter-area TE LSP to ASBR4 (supposing that ASBR4 is the selected next-hop ASBR). ASBR4 then repeats the exact same procedures. If ASBR4 cannot find a path obeying the set of constraints for the inter-AS TE LSP, then ASBR4 sends a PathErr message to ASBR1. Then ASBR1 can in turn either select another ASBR (ASBR5 in the example above) if crankback is allowed for this inter-AS TE LSP (see [RFC4920]), or if crankback is not allowed for that inter-AS TE LSP or if ASBR1 has been configured not to perform crankback, ABR1 stops the signaling process and forwards a PathErr up to the Head-end LSR (R0) without trying to select another egress LSR. In this case, the Head-end LSR can in turn select another sequence of loose hops, if configured. Alternatively, the Head-end LSR may decide to retry the same path; this can be useful in case of setup failure due to an outdated IGP TE database in some downstream AS. An alternative could also be for the Head-end LSR to retry the same sequence of loose hops after having relaxed some constraint(s).
在计算到下一跳ASBR的路径后，ASBR1将区域间TE LSP的路径消息发送到ASBR4（假设ASBR4是选定的下一跳ASBR）。ASBR4然后重复完全相同的过程。如果ASBR4找不到符合inter AS TE LSP约束集的路径，则ASBR4将向ASBR1发送PathErr消息。然后，ASBR1可以依次选择另一个ASBR（上例中的ASBR5），如果此AS-TE LSP允许回退（请参见[RFC4920]），或者如果该AS-TE LSP不允许回退，或者如果ASBR1已配置为不执行回退，则ABR1停止信令过程并将路径转发到前端LSR（R0）无需尝试选择其他出口LSR。在这种情况下，如果配置了，前端LSR可以依次选择另一个松散跃点序列。或者，前端LSR可以决定重试相同的路径；如果由于某些下游AS中的IGP TE数据库过时而导致设置失败，这将非常有用。另一种选择是，前端LSR在放松一些约束后重试相同的松散跳跃序列。
The path computation procedures are very similar to the inter-area LSP setup case described earlier. In this case, the H-LSPs or S-LSPs are originated by the ASBRs at the entry to the AS.
路径计算过程与前面描述的区域间LSP设置情况非常相似。在这种情况下，H-LSP或S-LSP由AS入口的ASBR发起。
Since the inter-domain TE LSP is computed on a per-domain (area, AS) basis, one cannot guarantee that the optimal inter-domain path can be found.
由于域间TE LSP是基于每个域（区域，AS）计算的，因此不能保证可以找到最佳域间路径。
Moreover, computing two diverse paths using a per-domain path computation approach may not be possible in some topologies (due to the well-known "trapping" problem).
此外，在某些拓扑中，使用每域路径计算方法计算两条不同的路径可能是不可能的（由于众所周知的“陷阱”问题）。
For example, consider the following simple topology:
例如，考虑下面的简单拓扑：
+-------+
/ \
A----B-----C------D
\ /
+---------+
+-------+
/ \
A----B-----C------D
\ /
+---------+
Figure 4 - Example of the "trapping" problem
图4“陷阱”问题示例
In the simple topology depicted in Figure 4, with a serialized approach using the per-domain path computation technique specified in this document, a first TE LSP may be computed following the path A-B-C-D, in which case no diverse path could be found although two diverse paths actually exist: A-C-D and A-B-D. The aim of that simple example that can easily be extended to the inter-domain case is to illustrate the potential issue of not being able to find diverse paths using the per-domain path computation approach when diverse paths exist.
在图4所示的简单拓扑中，通过使用本文档中指定的每域路径计算技术的序列化方法，可以沿着路径a-B-C-D计算第一个TE LSP，在这种情况下，虽然实际上存在两条不同的路径：A-C-D和A-B-D，但无法找到不同的路径。该简单示例的目的是很容易扩展到域间情况，以说明存在不同路径时，无法使用每域路径计算方法找到不同路径的潜在问题。
As already pointed out, the required path computation method can be selected by the Service Provider on a per-LSP basis.
如前所述，所需的路径计算方法可由服务提供商基于每个LSP来选择。
If the per-domain path computation technique does not meet the set of requirements for a particular TE LSP (e.g., path optimality, requirements for a set of diversely routed TE LSPs), other techniques such as PCE-based path computation techniques may be used (see [RFC4655]).
如果每域路径计算技术不满足特定TE LSP的一组要求（例如，路径优化、一组不同路由TE LSP的要求），则可以使用其他技术，例如基于PCE的路径计算技术（参见[RFC4655]）。
As stated in [RFC4216] and [RFC4105], the ability to reoptimize an already established inter-domain TE LSP constitutes a requirement. The reoptimization process significantly differs based upon the nature of the TE LSP and the mechanism in use for the TE LSP computation.
如[RFC4216]和[RFC4105]所述，重新优化已建立的域间TE LSP的能力构成了一项要求。根据TE LSP的性质和用于TE LSP计算的机制，重新优化过程明显不同。
The following mechanisms can be used for reoptimization and are dependent on the nature of the inter-domain TE LSP.
以下机制可用于重新优化，并取决于域间TE LSP的性质。
After an inter-domain TE LSP has been set up, a better route might appear within any traversed domain. Then in this case, it is desirable to get the ability to reroute an inter-domain TE LSP in a non-disruptive fashion (making use of the so-called Make-Before-Break procedure) to follow a better path. This is a known as a TE LSP reoptimization procedure.
在建立域间TE LSP之后，在任何经过的域中都可能出现更好的路由。然后，在这种情况下，希望能够以无中断方式（利用所谓的先通后断过程）重新路由域间TE LSP，以遵循更好的路径。这就是所谓的TE LSP再优化程序。
[RFC4736] proposes a mechanism that allows the Head-end LSR to be notified of the existence of a more optimal path in a downstream domain. The Head-end LSR may then decide to gracefully reroute the TE LSP using the Make-Before-Break procedure. In case of a contiguous LSP, the reoptimization process is strictly controlled by the Head-end LSR that triggers the Make-Before-Break procedure as defined in [RFC3209], regardless of the location of the better path.
[RFC4736]提出了一种机制，允许向前端LSR通知下游域中存在更优路径。然后，前端LSR可以决定使用先通后断程序优雅地重新路由TE LSP。在连续LSP的情况下，重新优化过程由前端LSR严格控制，该LSR触发[RFC3209]中定义的先通后断程序，而不考虑更好路径的位置。
In the case of a stitched or nested inter-domain TE LSP, the reoptimization process is treated as a local matter to any domain. The main reason is that the inter-domain TE LSP is a different LSP (and therefore different RSVP session) from the intra-domain S-LSP or H-LSP in an area or an AS. Therefore, reoptimization in a domain is done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since the inter-domain TE LSPs are transported using S-LSP or H-LSP across each domain, optimality of the inter-domain TE LSP in a domain is dependent on the optimality of the corresponding S-LSP or H-LSP. If after an inter-domain LSP is set up a more optimal path is available within a domain, the corresponding S-LSP or H-LSP will be reoptimized using Make-Before-Break techniques discussed in [RFC3209]. Reoptimization of the H-LSP or S-LSP automatically reoptimizes the inter-domain TE LSPs that the H-LSP or S-LSP transports. Reoptimization parameters like frequency of reoptimization, criteria for reoptimization like metric or bandwidth availability, etc. can vary from one domain to another and can be configured as required, per intra-domain TE S-LSP or H-LSP if it is pre-configured or based on some global policy within the domain.
在缝合或嵌套域间TE LSP的情况下，重新优化过程被视为任何域的局部问题。主要原因是域间TE-LSP是不同于区域或AS中的域内S-LSP或H-LSP的LSP（因此不同的RSVP会话）。因此，通过局部地重新优化域内H-LSP或S-LSP来完成域中的重新优化。由于域间TE-LSP使用S-LSP或H-LSP跨每个域传输，因此域中域间TE-LSP的最优性取决于相应S-LSP或H-LSP的最优性。如果在建立域间LSP后，域内有一条更优的路径可用，则将使用[RFC3209]中讨论的先通后断技术重新优化相应的S-LSP或H-LSP。重新优化H-LSP或S-LSP会自动重新优化H-LSP或S-LSP传输的域间TE LSP。重新优化参数（如重新优化频率）、重新优化标准（如度量或带宽可用性等）可能因域而异，并且可以根据需要根据域内TE S-LSP或H-LSP进行配置（如果预先配置或基于域内的某些全局策略）。
Hence, in this scheme, since each domain takes care of reoptimizing its own S-LSPs or H-LSPs, and therefore the corresponding inter-domain TE LSPs, the Make-Before-Break can happen locally and is not triggered by the Head-end LSR for the inter-domain LSP. So, no additional RSVP signaling is required for LSP reoptimization, and reoptimization is transparent to the Head-end LSR of the inter-domain TE LSP.
因此，在该方案中，由于每个域负责重新优化其自身的S-LSP或H-LSP，以及相应的域间TE-LSP，因此先通后断可以在本地发生，并且不会由域间LSP的前端LSR触发。因此，LSP重新优化不需要额外的RSVP信令，并且重新优化对域间TE LSP的头端LSR是透明的。
If, however, an operator desires to manually trigger reoptimization at the Head-end LSR for the inter-domain TE LSP, then this solution does not prevent that. A manual trigger for reoptimization at the Head-end LSR SHOULD force a reoptimization thereby signaling a "new" path for the same LSP (along the more optimal path) making use of the Make-Before-Break procedure. In response to this new setup request, the boundary LSR either may initiate new S-LSP setup, in case the inter-domain TE LSP is being stitched to the intra-domain S-LSP, or it may select an existing or new H-LSP, in case of nesting. When the LSP setup along the current path is complete, the Head-end LSR should switch over the traffic onto that path, and the old path is eventually torn down. Note that the Head-end LSR does not know a priori whether a more optimal path exists. Such a manual trigger from the Head-end LSR of the inter-domain TE LSP is, however, not considered to be a frequent occurrence.
然而，如果运营商希望在域间TE LSP的前端LSR处手动触发重新优化，则该解决方案不会阻止这一点。在前端LSR处进行再优化的手动触发器应强制进行再优化，从而利用先通后断程序为同一LSP（沿着更优化的路径）发出“新”路径的信号。响应于这个新的设置请求，边界LSR可以在域间TE LSP被缝合到域内S-LSP的情况下启动新的S-LSP设置，或者在嵌套的情况下它可以选择现有的或新的H-LSP。当沿着当前路径的LSP设置完成时，前端LSR应将流量切换到该路径，旧路径最终被拆除。注意，前端LSR不知道是否存在更优的路径。然而，来自域间TE LSP的头端LSR的这种手动触发不被认为是频繁发生的。
Procedures described in [RFC4736] MUST be used if the operator does not desire local reoptimization of certain inter-domain LSPs. In this case, any reoptimization event within the domain MUST be reported to the Head-end node. This SHOULD be a configurable policy.
如果操作员不希望局部重新优化某些域间LSP，则必须使用[RFC4736]中描述的程序。在这种情况下，域中的任何重新优化事件都必须报告给前端节点。这应该是一个可配置的策略。
Note that in the case of loose hop reoptimization of contiguous inter-domain TE LSP or local reoptimization of stitched/nested S-LSP where boundary LSRs are specified as loose hops, the TE LSP may follow a preferable path within one or more domain(s) but would still traverse the same set of boundary LSRs. In contrast, in the case of PCE-based path computation techniques, because the end-to-end optimal path is computed, the reoptimization process may lead to following a completely different inter-domain path (including a different set of boundary LSRs).
注意，在相邻域间TE-LSP的松跳重新优化或缝合/嵌套S-LSP的局部重新优化（其中边界lsr被指定为松跳）的情况下，TE-LSP可在一个或多个域内遵循优选路径，但仍将穿过同一组边界lsr。相反，在基于PCE的路径计算技术的情况下，由于计算了端到端最优路径，因此重新优化过程可能导致遵循完全不同的域间路径（包括不同的边界lsr集合）。
Signaling of inter-domain TE LSPs raises security issues (discussed in section 7 of [RFC5151]).
域间TE LSP的信令引起安全问题（在[RFC5151]第7节中讨论）。
[RFC4726] provides an overview of the requirements for security in an MPLS-TE or GMPLS multi-domain environment. In particular, when signaling an inter-domain RSVP-TE LSP, an operator may make use of the security features already defined for RSVP-TE ([RFC3209]). This may require some coordination between the domains to share the keys (see [RFC2747] and [RFC3097]), and care is required to ensure that the keys are changed sufficiently frequently. Note that this may involve additional synchronization, should the domain border nodes be protected with Fast Reroute ([RFC4090], since the Merge Point (MP) and Point of Local Repair (PLR) should also share the key. For an inter-domain TE LSP, especially when it traverses different administrative or trust domains, the following mechanisms SHOULD be provided to an operator (also see [RFC4216]):
[RFC4726]概述了MPLS-TE或GMPLS多域环境中的安全要求。具体地，当向域间RSVP-TE LSP发信号时，运营商可以利用已经为RSVP-TE定义的安全特性（[RFC3209]）。这可能需要在域之间进行一些协调以共享密钥（请参见[RFC2747]和[RFC3097]），并且需要注意确保密钥的更改足够频繁。注意，由于合并点（MP）和本地修复点（PLR），如果域边界节点受到快速重路由（[RFC4090]）的保护，这可能涉及额外的同步还应共享密钥。对于域间TE LSP，尤其是当它穿越不同的管理或信任域时，应向操作员提供以下机制（另请参见[RFC4216]）：
1) A way to enforce policies and filters at the domain borders to process the incoming inter-domain TE LSP setup requests (Path messages) based on certain agreed trust and service levels/contracts between domains. Various LSP attributes such as bandwidth, priority, etc. could be part of such a contract.
1) 一种在域边界强制执行策略和筛选器的方法，以根据域之间的某些约定信任和服务级别/契约处理传入的域间TE LSP设置请求（路径消息）。各种LSP属性（如带宽、优先级等）可以是此类合同的一部分。
2) A way for the operator to rate-limit LSP setup requests or error notifications from a particular domain.
2) 操作员对特定域的LSP设置请求或错误通知进行分级限制的一种方法。
3) A mechanism to allow policy-based outbound RSVP message processing at the domain border node, which may involve filtering or modification of certain addresses in RSVP objects and messages.
3) 允许在域边界节点上处理基于策略的出站RSVP消息的机制，这可能涉及过滤或修改RSVP对象和消息中的某些地址。
This document relates to inter-domain path computation. It must be noted that the process for establishing paths described in this document does not increase the information exchanged between ASs and preserves topology confidentiality, in compliance with [RFC4105] and [RFC4216]. That being said, the signaling of inter-domain TE LSP according to the procedure defined in this document requires path computation on boundary nodes that may be exposed to various attacks. Thus, it is RECOMMENDED to support policy decisions to reject the ERO expansion of an inter-domain TE LSP if not allowed.
本文档涉及域间路径计算。必须注意，根据[RFC4105]和[RFC4216]，本文件中描述的建立路径的过程不会增加ASs之间交换的信息，并保持拓扑机密性。也就是说，根据本文中定义的过程的域间TE LSP的信令需要在可能暴露于各种攻击的边界节点上进行路径计算。因此，如果不允许，建议支持拒绝域间TE LSP的ERO扩展的政策决策。
We would like to acknowledge input and helpful comments from Adrian Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou, and Faisal Aslam.
我们感谢阿德里安·法雷尔、让·路易斯·勒鲁、迪米特里·帕帕迪米特里欧和费萨尔·阿斯拉姆的意见和帮助。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3209] 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.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4920]Farrel，A.，Ed.，Satyanarayana，A.，Iwata，A.，Fujita，N.，和G.Ash，“MPLS和GMPLS RSVP-TE的回退信令扩展”，RFC 4920，2007年7月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151]Farrel，A.，Ed.，Ayyangar，A.，和JP。Vasseur，“域间MPLS和GMPLS流量工程——资源预留协议流量工程（RSVP-TE）扩展”，RFC 51512008年2月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 51502008年2月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]Le Roux，J.-L.，Ed.，Vasseur，J.-P.，Ed.，和J.Boyle，Ed.，“区域间MPLS流量工程的要求”，RFC 4105，2005年6月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的中间系统到中间系统（IS-IS）扩展”，RFC 4205，2005年10月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.，Ed.，和J.-P.Vasseur，Ed.，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年11月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.-P.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4736]Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“多协议标签交换（MPLS）流量工程（TE）松路由标签交换路径（LSP）的再优化”，RFC 47362006年11月。
Authors' Addresses
作者地址
JP Vasseur (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP Vasseur（编辑）思科系统公司，美国马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Arthi Ayyangar (editor) Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
Arthi Ayangar（编辑）Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州94089
EMail: arthi@juniper.net
EMail: arthi@juniper.net
Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90025 USA
美国加利福尼亚州埃尔塞贡多大道东2160号雷蒙德张BT 90025
EMail: raymond.zhang@bt.com
EMail: raymond.zhang@bt.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.