Network Working Group J.-L. Le Roux, Ed.
Request for Comments: 4105 France Telecom
Category: Informational J.-P. Vasseur, Ed.
Cisco Systems, Inc.
J. Boyle, Ed.
PDNETs
June 2005
Network Working Group J.-L. Le Roux, Ed.
Request for Comments: 4105 France Telecom
Category: Informational J.-P. Vasseur, Ed.
Cisco Systems, Inc.
J. Boyle, Ed.
PDNETs
June 2005
Requirements for Inter-Area MPLS Traffic Engineering
区域间MPLS流量工程的要求
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 lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements.
本文件列出了支持区域间MPLS流量工程（区域间MPLS TE）的一组详细功能需求。旨在为区域间MPLS TE指定过程和协议扩展的解决方案满足这些要求。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Current Intra-Area Uses of MPLS Traffic Engineering .............4
4.1. Intra-Area MPLS Traffic Engineering Architecture ...........4
4.2. Intra-Area MPLS Traffic Engineering Applications ...........4
4.2.1. Intra-Area Resource Optimization ....................4
4.2.2. Intra-Area QoS Guarantees ...........................5
4.2.3. Fast Recovery within an IGP Area ....................5
4.3. Intra-Area MPLS TE and Routing .............................6
5. Problem Statement, Requirements, and Objectives of Inter-Area ...6
5.1. Inter-Area Traffic Engineering Problem Statement ...........6
5.2. Overview of Requirements for Inter-Area MPLS TE ............7
5.3. Key Objectives for an Inter-Area MPLS-TE Solution ..........8
5.3.1. Preserving the IGP Hierarchy Concept ................8
5.3.2. Preserving Scalability ..............................8
6. Application Scenario.............................................9
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Current Intra-Area Uses of MPLS Traffic Engineering .............4
4.1. Intra-Area MPLS Traffic Engineering Architecture ...........4
4.2. Intra-Area MPLS Traffic Engineering Applications ...........4
4.2.1. Intra-Area Resource Optimization ....................4
4.2.2. Intra-Area QoS Guarantees ...........................5
4.2.3. Fast Recovery within an IGP Area ....................5
4.3. Intra-Area MPLS TE and Routing .............................6
5. Problem Statement, Requirements, and Objectives of Inter-Area ...6
5.1. Inter-Area Traffic Engineering Problem Statement ...........6
5.2. Overview of Requirements for Inter-Area MPLS TE ............7
5.3. Key Objectives for an Inter-Area MPLS-TE Solution ..........8
5.3.1. Preserving the IGP Hierarchy Concept ................8
5.3.2. Preserving Scalability ..............................8
6. Application Scenario.............................................9
7. Detailed Requirements for Inter-Area MPLS TE ...................10
7.1. Inter-Area MPLS TE Operations and Interoperability ........10
7.2. Inter-Area TE-LSP Signaling ...............................10
7.3. Path Optimality ...........................................11
7.4. Inter-Area MPLS-TE Routing ................................11
7.5. Inter-Area MPLS-TE Path Computation .......................12
7.6. Inter-Area Crankback Routing ..............................12
7.7. Support of Diversely-Routed Inter-Area TE LSPs ............13
7.8. Intra/Inter-Area Path Selection Policy ....................13
7.9. Reoptimization of Inter-Area TE LSP .......................13
7.10. Inter-Area LSP Recovery ..................................14
7.10.1. Rerouting of Inter-Area TE LSPs ..................14
7.10.2. Fast Recovery of Inter-Area TE LSP ...............14
7.11. DS-TE support ............................................15
7.12. Hierarchical LSP Support .................................15
7.13. Hard/Soft Preemption .....................................15
7.14. Auto-Discovery of TE Meshes ..............................16
7.15. Inter-Area MPLS TE Fault Management Requirements .........16
7.16. Inter-Area MPLS TE and Routing ...........................16
8. Evaluation criteria ............................................17
8.1. Performances ..............................................17
8.2. Complexity and Risks ......................................17
8.3. Backward Compatibility ....................................17
9. Security Considerations ........................................17
10. Acknowledgements ..............................................17
11. Contributing Authors ..........................................18
12. Normative References ..........................................19
13. Informative References ........................................19
7. Detailed Requirements for Inter-Area MPLS TE ...................10
7.1. Inter-Area MPLS TE Operations and Interoperability ........10
7.2. Inter-Area TE-LSP Signaling ...............................10
7.3. Path Optimality ...........................................11
7.4. Inter-Area MPLS-TE Routing ................................11
7.5. Inter-Area MPLS-TE Path Computation .......................12
7.6. Inter-Area Crankback Routing ..............................12
7.7. Support of Diversely-Routed Inter-Area TE LSPs ............13
7.8. Intra/Inter-Area Path Selection Policy ....................13
7.9. Reoptimization of Inter-Area TE LSP .......................13
7.10. Inter-Area LSP Recovery ..................................14
7.10.1. Rerouting of Inter-Area TE LSPs ..................14
7.10.2. Fast Recovery of Inter-Area TE LSP ...............14
7.11. DS-TE support ............................................15
7.12. Hierarchical LSP Support .................................15
7.13. Hard/Soft Preemption .....................................15
7.14. Auto-Discovery of TE Meshes ..............................16
7.15. Inter-Area MPLS TE Fault Management Requirements .........16
7.16. Inter-Area MPLS TE and Routing ...........................16
8. Evaluation criteria ............................................17
8.1. Performances ..............................................17
8.2. Complexity and Risks ......................................17
8.3. Backward Compatibility ....................................17
9. Security Considerations ........................................17
10. Acknowledgements ..............................................17
11. Contributing Authors ..........................................18
12. Normative References ..........................................19
13. Informative References ........................................19
The set of MPLS Traffic Engineering components, defined in [RSVP-TE], [OSPF-TE], and [ISIS-TE], which supports the requirements defined in [TE-REQ], is used today by many network operators to achieve major Traffic Engineering objectives defined in [TE-OVW]. These objectives include:
[RSVP-TE]、[OSPF-TE]和[ISIS-TE]中定义的MPLS流量工程组件集支持[TE-REQ]中定义的要求，目前许多网络运营商使用该组件来实现[TE-OVW]中定义的主要流量工程目标。这些目标包括：
- Aggregated Traffic measurement - Optimization of network resources utilization - Support for services requiring end-to-end QoS guarantees - Fast recovery against link/node/Shared Risk Link Group (SRLG) failures
- 聚合流量测量-优化网络资源利用率-支持需要端到端QoS保证的服务-针对链路/节点/共享风险链路组（SRLG）故障的快速恢复
Furthermore, the applicability of MPLS to traffic engineering in IP networks is discussed in [TE-APP].
此外，在[TE-APP]中讨论了MPLS在IP网络流量工程中的适用性。
The set of MPLS Traffic Engineering mechanisms, to date, has been limited to use within a single Interior Gateway Protocol (IGP) area.
迄今为止，MPLS流量工程机制集仅限于在单个内部网关协议（IGP）区域内使用。
This document discusses the requirements for an inter-area MPLS Traffic Engineering mechanism that may be used to achieve the same set of objectives across multiple IGP areas.
本文件讨论了区域间MPLS流量工程机制的要求，该机制可用于跨多个IGP区域实现相同的目标集。
Basically, it would be useful to extend MPLS TE capabilities across IGP areas to support inter-area resources optimization, to provide strict QoS guarantees between two edge routers located within distinct areas, and to protect inter-area traffic against Area Border Router (ABR) failures.
基本上，将MPLS TE能力扩展到IGP区域以支持区域间资源优化、在位于不同区域内的两个边缘路由器之间提供严格的QoS保证以及保护区域间流量不受区域边界路由器（ABR）故障的影响是有用的。
First, this document addresses current uses of MPLS Traffic Engineering within a single IGP area. Then, it discusses a set of functional requirements that a solution must or should satisfy in order to support inter-area MPLS Traffic Engineering. Because the scope of requirements will vary between operators, some requirements will be mandatory (MUST), whereas others will be optional (SHOULD). Finally, a set of evaluation criteria for any solution meeting these requirements is given.
首先，本文档介绍了单个IGP区域内MPLS流量工程的当前用途。然后，讨论了解决方案必须或应该满足的一组功能需求，以支持区域间MPLS流量工程。由于要求的范围因运营商而异，一些要求是强制性的（必须），而其他要求是可选的（应该）。最后，给出了满足这些要求的任何解决方案的一组评估标准。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
LSR: Label Switching Router
标签交换路由器
LSP: Label Switched Path
标签交换路径
TE LSP: Traffic Engineering Label Switched Path
TE LSP：流量工程标签交换路径
Inter-area TE LSP: TE LSP whose head-end LSR and tail-end LSR do not reside within the same IGP area or whose head-end LSR and tail-end LSR are both in the same IGP area although the TE-LSP transiting path is across different IGP areas.
区域间TE LSP：其前端LSR和后端LSR不在同一IGP区域内的TE LSP，或其前端LSR和后端LSR都在同一IGP区域内的TE LSP，尽管TE-LSP过渡路径跨越不同的IGP区域。
IGP area: OSPF area or IS-IS level.
IGP区域：OSPF区域或IS-IS级别。
ABR: Area Border Router, a router used to connect two IGP areas (ABR in OSPF, or L1/L2 router in IS-IS).
ABR：区域边界路由器，用于连接两个IGP区域的路由器（OSPF中的ABR，或IS-IS中的L1/L2路由器）。
CSPF: Constraint-based Shortest Path First.
CSPF：基于约束的最短路径优先。
SRLG: Shared Risk Link Group.
SRLG：共享风险链接组。
This section addresses architecture, capabilities, and uses of MPLS TE within a single IGP area. It first summarizes the current MPLS-TE architecture, then addresses various MPLS-TE capabilities, and finally lists various approaches to integrate MPLS TE into routing. This section is intended to help define the requirements for MPLS-TE extensions across multiple IGP areas.
本节介绍单个IGP区域内MPLS TE的体系结构、功能和使用。它首先总结了当前的MPLS-TE体系结构，然后介绍了各种MPLS-TE功能，最后列出了将MPLS-TE集成到路由中的各种方法。本节旨在帮助定义跨多个IGP区域的MPLS-TE扩展的要求。
The MPLS-TE control plane allows establishing explicitly routed MPLS LSPs whose paths follow a set of TE constraints. It is used to achieve major TE objectives such as resource usage optimization, QoS guarantee and fast failure recovery. It consists of three main components:
MPLS-TE控制平面允许建立显式路由的MPLS LSP，其路径遵循一组TE约束。它用于实现资源使用优化、QoS保证和快速故障恢复等主要TE目标。它由三个主要部分组成：
- The routing component, responsible for the discovery of the TE topology. This is ensured thanks to extensions of link state IGP: [ISIS-TE], [OSPF-TE]. - The path computation component, responsible for the placement of the LSP. It is performed on the head-end LSR thanks to a CSPF algorithm, which takes TE topology and LSP constraints as input. - The signaling component, responsible for the establishment of the LSP (explicit routing, label distribution, and resources reservation) along the computed path. This is ensured thanks to RSVP-TE [RSVP-TE].
- 路由组件，负责发现TE拓扑。这得益于链路状态IGP的扩展：[ISIS-TE]，[OSPF-TE]。-路径计算组件，负责LSP的放置。由于采用了CSPF算法，该算法将TE拓扑和LSP约束作为输入，因此可在前端LSR上执行信令组件，负责沿计算路径建立LSP（显式路由、标签分发和资源保留）。由于RSVP-TE[RSVP-TE]，这一点得以确保。
MPLS TE can be used within an area to redirect paths of aggregated flows away from over-utilized resources within a network. In a small scale, this may be done by explicitly configuring a path to be used between two routers. On a grander scale, a mesh of LSPs can be established between central points in a network. LSPs paths can be defined statically in configuration or arrived at by an algorithm that determines the shortest path given administrative constraints such as bandwidth. In this way, MPLS TE allows for greater control over how traffic demands are routed over a network topology and utilize a network's resources.
MPLS TE可在区域内用于重定向聚合流的路径，使其远离网络内过度利用的资源。在小范围内，这可以通过显式配置两个路由器之间使用的路径来实现。在更大的范围内，可以在网络的中心点之间建立LSP网格。LSP路径可以在配置中静态定义，也可以通过在给定管理约束（如带宽）的情况下确定最短路径的算法来实现。通过这种方式，MPLS TE允许更好地控制流量需求如何在网络拓扑上路由并利用网络资源。
Note also that TE LSPs allow measuring traffic matrix in a simple and scalable manner. The aggregated traffic rate between two LSRs is easily measured by accounting of traffic sent onto a TE LSP provisioned between the two LSRs in question.
还请注意，TE LSP允许以简单且可扩展的方式测量流量矩阵。两个LSR之间的聚合流量率很容易通过计算发送到两个LSR之间供应的TE LSP上的流量来测量。
The DiffServ IETF working group has defined a set of mechanisms described in [DIFF-ARCH], [DIFF-AF], and [DIFF-EF] or [MPLS-DIFF], that can be activated at the edge of or over a DiffServ domain to contribute to the enforcement of a QoS policy (or set of policies), which can be expressed in terms of maximum one-way transit delay, inter-packet delay variation, loss rate, etc. Many Operators have some or full deployment of DiffServ implementations in their networks today, either across the entire network or at least at its edge.
DiffServ IETF工作组定义了[DIFF-ARCH]、[DIFF-AF]和[DIFF-EF]或[MPLS-DIFF]中描述的一组机制，这些机制可在DiffServ域的边缘或之上激活，以促进QoS策略（或一组策略）的实施，QoS策略可以用最大单向传输延迟表示，数据包间延迟变化、丢失率等。如今，许多运营商在其网络中部署了部分或全部DiffServ实现，无论是在整个网络中，还是至少在其边缘。
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. 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.
在需要严格QoS边界的情况下，除了当前的DiffServ机制之外，在某些情况下还需要网络主干内的准入控制。当传播延迟可以有界时，可以通过沿启用区分服务的路径提供带宽保证来保证性能目标，例如最大单向传输延迟。
MPLS TE can be simply used with DiffServ: in that case, it only ensures aggregate QoS guarantees for the whole traffic. It can also be more intimately combined with DiffServ to perform per-class of service admission control and resource reservation. This requires extensions to MPLS TE called DiffServ-Aware TE, which are defined in [DSTE-PROTO]. DS-TE allows ensuring strict end-to-end QoS guarantees. For instance, an EF DS-TE LSP may be provisioned between voice gateways within the same area to ensure strict QoS to VoIP traffic.
MPLS TE可以简单地与DiffServ一起使用：在这种情况下，它只能确保整个流量的聚合QoS保证。它还可以与DiffServ更紧密地结合，以执行每类服务的准入控制和资源预留。这需要对MPLS TE进行扩展，称为区分服务感知TE，定义见[DSTE-PROTO]。DS-TE允许确保严格的端到端QoS保证。例如，可以在同一区域内的语音网关之间提供EF DS-TE LSP，以确保对VoIP业务的严格QoS。
MPLS TE allows computing intra-area shortest paths, which satisfy various constraints, including bandwidth. For the sake of illustration, if the IGP metrics reflects the propagation delay, it allows finding a minimum propagation delay path, which satisfies various constraints, such as bandwidth.
MPLS TE允许计算满足各种约束条件（包括带宽）的区域内最短路径。为了说明，如果IGP度量反映了传播延迟，则它允许找到满足各种约束（例如带宽）的最小传播延迟路径。
As quality-sensitive applications are deployed, one of the key requirements is to provide fast recovery mechanisms, allowing traffic recovery to be guaranteed on the order of tens of msecs, in case of network element failure. Note that this cannot be achieved by relying only on classical IGP rerouting.
在部署对质量敏感的应用程序时，关键要求之一是提供快速恢复机制，允许在网元故障的情况下保证流量恢复在数十毫秒左右。请注意，仅依靠经典的IGP重路由无法实现这一点。
Various recovery mechanisms can be used to protect traffic carried onto TE LSPs. They are defined in [MPLS-RECOV]. Protection mechanisms are based on the provisioning of backup LSPs that are used to recover traffic in case of failure of protected LSPs. Among those protection mechanisms, local protection (also called Fast Reroute) is intended to achieve sub-50ms recovery in case of link/node/SRLG
各种恢复机制可用于保护传输到TE LSP上的流量。它们在[MPLS-RECOV]中定义。保护机制基于备份LSP的配置，这些LSP用于在受保护LSP发生故障时恢复通信量。在这些保护机制中，本地保护（也称为快速重路由）旨在在链路/节点/SRLG的情况下实现低于50ms的恢复
failure along the LSP path [FAST-REROUTE]. Fast Reroute is currently used by many operators to protect sensitive traffic inside an IGP area.
LSP路径故障[快速重路由]。快速重路由目前被许多运营商用于保护IGP区域内的敏感流量。
[FAST-REROUTE] defines two modes for backup LSPs. The first, called one-to-one backup, consists of setting up one detour LSP per protected LSP and per element to protect. The second, called facility backup, consists of setting up one or several bypass LSPs to protect a given facility (link or node). In case of failure, all protected LSPs are nested into the bypass LSPs (benefiting from the MPLS label stacking property).
[FAST-REROUTE]为备份LSP定义了两种模式。第一种称为一对一备份，包括为每个受保护的LSP和每个要保护的元素设置一个迂回LSP。第二种称为设施备份，包括设置一个或多个旁路LSP以保护给定的设施（链路或节点）。如果出现故障，所有受保护的LSP都嵌套到旁路LSP中（受益于MPLS标签堆叠属性）。
There are several possibilities for directing traffic into intra-area TE LSPs:
有几种将流量引导到区域内TE LSP的可能性：
1) Static routing to the LSP destination address or any other addresses. 2) IGP routes beyond the LSP destination, from an IGP SPF perspective (IGP shortcuts). 3) BGP routes announced by a BGP peer (or an MP-BGP peer) that is reachable through the TE LSP by means of a single static route to the corresponding BGP next-hop address (option 1) or by means of IGP shortcuts (option 2). This is often called BGP recursive routing. 4) The LSP can be advertised as a link into the IGP to become part of IGP database for all nodes, and thus can be taken into account during SPF for all nodes. Note that, even if similar in concept, this is different from the notion of Forwarding-Adjacency, as defined in [LSP-HIER]. Forwarding-Adjacency is when the LSP is advertised as a TE-link into the IGP-TE to become part of the TE database and taken into account in CSPF.
1) 到LSP目标地址或任何其他地址的静态路由。2） 从IGP SPF（IGP快捷方式）的角度来看，超出LSP目的地的IGP路由。3） BGP对等方（或MP-BGP对等方）宣布的BGP路由，可通过TE LSP通过单个静态路由到达相应的BGP下一跳地址（选项1）或通过IGP快捷方式（选项2）到达。这通常称为BGP递归路由。4） LSP可以作为到IGP的链路进行广告，以成为所有节点的IGP数据库的一部分，因此可以在所有节点的SPF期间考虑LSP。注意，即使在概念上相似，这也不同于[LSP-HIER]中定义的转发邻接概念。转发邻接是指LSP作为TE链路播发到IGP-TE，成为TE数据库的一部分，并在CSPF中予以考虑。
5. Problem Statement, Requirements, and Objectives of Inter-Area MPLS TE
5. 区域间MPLS TE的问题陈述、要求和目标
As described in Section 4, MPLS TE is deployed today by many operators to optimize network bandwidth usage, to provide strict QoS guarantees, and to ensure sub-50ms recovery in case of link/node/SRLG failure.
如第4节所述，目前许多运营商都部署了MPLS TE，以优化网络带宽使用，提供严格的QoS保证，并确保在链路/节点/SRLG故障时进行低于50毫秒的恢复。
However, MPLS-TE mechanisms are currently limited to a single IGP area. The limitation comes more from the Routing and Path computation components than from the signaling component. This is basically because the hierarchy limits topology visibility of head-
然而，MPLS-TE机制目前仅限于单个IGP区域。限制更多地来自路由和路径计算组件，而不是来自信令组件。这基本上是因为层次限制了头部的拓扑可见性-
end LSRs to their IGP area, and consequently head-end LSRs can no longer run a CSPF algorithm to compute the shortest constrained path to the tail-end, as CSPF requires the whole topology to compute an end-to-end shortest constrained path.
将LSR端到其IGP区域，因此前端LSR不能再运行CSPF算法来计算到后端的最短约束路径，因为CSPF需要整个拓扑来计算端到端的最短约束路径。
Several operators have multi-area networks, and many operators that are still using a single IGP area may have to migrate to a multi-area environment, as their network grows and single area scalability limits are approached.
一些运营商拥有多区域网络，许多仍在使用单个IGP区域的运营商可能不得不迁移到多区域环境，因为他们的网络不断增长，单区域可扩展性限制越来越接近。
Thus, those operators may require inter-area traffic engineering to:
因此，这些运营商可能需要区域间交通工程来：
- Perform inter-area resource optimization. - Provide inter-area QoS guarantees for traffic between edge nodes located in different areas. - Provide fast recovery across areas, to protect inter-area traffic in case of link or node failure, including ABR node failures.
- 执行区域间资源优化。-为位于不同区域的边缘节点之间的流量提供区域间QoS保证。-提供跨区域的快速恢复，以在链路或节点故障（包括ABR节点故障）时保护区域间通信。
For instance, an operator running a multi-area IGP may have voice gateways located in different areas. Such VoIP transport requires inter-area QoS guarantees and inter-area fast protection.
例如，运行多区域IGP的运营商可以在不同区域设置语音网关。这种VoIP传输需要区域间QoS保证和区域间快速保护。
One possible approach for inter-area traffic engineering could consist of deploying MPLS TE on a per-area basis, but such an approach has several limitations:
区域间流量工程的一种可能方法可以包括在每个区域的基础上部署MPLS TE，但这种方法有几个局限性：
- Traffic aggregation at the ABR levels implies some constraints that do not lead to efficient traffic engineering. Actually, this per-area TE approach might lead to sub-optimal resource utilization, by optimizing resources independently in each area. What many operators want is to optimize their resources as a whole; in other words, as if there was only one area (flat network). - This does not allow computing an inter-area constrained shortest path and thus does not ensure end-to-end QoS guarantees across areas. - Inter-area traffic cannot be protected with local protection mechanisms such as [FAST-REROUTE] in case of ABR failure.
- ABR级别的流量聚合意味着一些无法实现高效流量工程的约束。实际上，这种按区域TE方法可能会导致次优资源利用率，因为它会独立优化每个区域的资源。许多运营商想要的是从整体上优化他们的资源；换句话说，好像只有一个区域（平面网络）。-这不允许计算区域间受约束的最短路径，因此无法确保跨区域的端到端QoS保证。-在ABR故障的情况下，无法使用本地保护机制（如[FAST-REROUTE]）保护区域间通信。
Therefore, existing MPLS TE mechanisms have to be enhanced to support inter-area TE LSPs.
因此，必须增强现有MPLS-TE机制以支持区域间TE-lsp。
For the reasons mentioned above, it is highly desired to extend the current set of MPLS-TE mechanisms across multiple IGP areas in order to support the intra-area applications described in Section 4 across areas.
出于上述原因，非常希望跨多个IGP区域扩展MPLS-TE机制的当前集合，以便跨区域支持第4节中描述的区域内应用。
The solution MUST allow setting up inter-area TE LSPs; i.e., LSPs whose path crosses at least two IGP areas.
解决方案必须允许设置区域间TE LSP；i、 例如，路径至少穿过两个IGP区域的LSP。
Inter-area MPLS-TE extensions are highly desired in order to provide:
为了提供：
- Inter-area resources optimization. - Strict inter-area QoS guarantees. - Fast recovery across areas, particularly to protect inter-area traffic against ABR failures.
- 区域间资源优化严格的区域间QoS保证。-跨区域快速恢复，特别是保护区域间流量免受ABR故障的影响。
It may be desired to compute inter-area shortest paths that satisfy some bandwidth constraints or any other constraints, as is currently possible within a single IGP area. For the sake of illustration, if the IGP metrics reflects the propagation delay, it may be necessary to be able to find the optimal (shortest) path satisfying some constraints (e.g., bandwidth) across multiple IGP areas. Such a path would be the inter-area path offering the minimal propagation delay.
可能需要计算满足某些带宽约束或任何其他约束的区域间最短路径，正如当前在单个IGP区域内可能的那样。为了说明，如果IGP度量反映了传播延迟，则可能需要能够找到跨多个IGP区域满足某些约束（例如带宽）的最佳（最短）路径。这样的路径将是提供最小传播延迟的区域间路径。
Thus, the solution SHOULD provide the ability to compute inter-area shortest paths satisfying a set of constraints (i.e., bandwidth).
因此，解决方案应提供计算满足一组约束（即带宽）的区域间最短路径的能力。
Any solution for inter-area MPLS TE should be designed with preserving IGP hierarchy concept, and preserving routing and signaling scalability as key objectives.
任何区域间MPLS-TE解决方案的设计都应以保持IGP层次结构概念、保持路由和信令可伸缩性为关键目标。
The absence of a full link-state topology database makes the computation of an end-to-end optimal path by the head-end LSR not possible without further signaling and routing extensions. There are several reasons that network operators choose to break up their network into different areas. These often include scalability and containment of routing information. The latter can help isolate most of a network from receiving and processing updates that are of no consequence to its routing decisions. Containment of routing information MUST not be compromised to allow inter-area traffic engineering. Information propagation for path-selection MUST continue to be localized. In other words, the solution MUST entirely preserve the concept of IGP hierarchy.
由于缺少完整链路状态拓扑数据库，因此在没有进一步信令和路由扩展的情况下，无法通过前端LSR计算端到端最佳路径。网络运营商选择将其网络划分为不同的区域有几个原因。这些通常包括路由信息的可伸缩性和包含性。后者有助于将大部分网络与接收和处理对其路由决策没有影响的更新隔离开来。路由信息的包含不得被破坏，以允许区域间流量工程。路径选择的信息传播必须继续本地化。换句话说，解决方案必须完全保留IGP层次结构的概念。
Achieving the requirements listed in this document MUST be performed while preserving the IGP scalability, which is of the utmost importance. The hierarchy preservation objective addressed in the above section is actually an element to preserve IGP scalability.
必须在保持IGP可扩展性的同时实现本文件中列出的要求，这一点至关重要。上一节中提到的层次结构保留目标实际上是保持IGP可伸缩性的一个要素。
The solution also MUST not increase IGP load unreasonably, which could compromise IGP scalability. In particular, a solution satisfying those requirements MUST not require the IGP to carry some unreasonable amount of extra information and MUST not unreasonably increase the IGP flooding frequency.
解决方案也不能不合理地增加IGP负载，这可能会损害IGP的可扩展性。特别是，满足这些要求的解决方案不得要求IGP携带不合理数量的额外信息，也不得不合理地增加IGP泛洪频率。
Likewise, the solution MUST also preserve scalability of RSVP-TE ([RSVP-TE]).
同样，解决方案还必须保持RSVP-TE（[RSVP-TE]）的可伸缩性。
Additionally, the base specification of MPLS TE is architecturally structured and relatively devoid of excessive state propagation in terms of routing or signaling. Its strength in extensibility can also be seen as an Achilles heel, as there is no real limit to what is possible with extensions. It is paramount to maintain architectural vision and discretion when adapting it for use for inter-area MPLS TE. Additional information carried within an area or propagated outside of an area (via routing or signaling) should be neither excessive, patchwork, nor non-relevant.
此外，MPLS-TE的基本规范在架构上是结构化的，并且在路由或信令方面相对没有过度的状态传播。它在可扩展性方面的优势也可以看作是一个致命弱点，因为扩展的可能性没有真正的限制。在将其用于区域间MPLS TE时，保持体系结构的远见和判断力是至关重要的。在一个区域内承载或在该区域外传播的附加信息（通过路由或信令）不应过多、零散或不相关。
Particularly, as mentioned in Section 5.2, it may be desired for some inter-area TE LSP carrying highly sensitive traffic to compute a shortest inter-area path, satisfying a set of constraints such as bandwidth. This may require an additional routing mechanism, as base CSPF at head-end can no longer be used due to the lack of topology and resource information. Such a routing mechanism MUST not compromise the scalability of the overall system.
特别是，如第5.2节所述，可能需要一些承载高度敏感业务的区域间TE LSP计算最短区域间路径，以满足一组约束，例如带宽。这可能需要额外的路由机制，因为由于缺乏拓扑和资源信息，前端的基本CSPF无法再使用。这样的路由机制不能损害整个系统的可伸缩性。
---area1--------area0------area2--
------R1-ABR1-R2-------ABR3-------
| \ | / | |
| R0 \ | / | R4 |
| R5 \ |/ | |
---------ABR2----------ABR4-------
---area1--------area0------area2--
------R1-ABR1-R2-------ABR3-------
| \ | / | |
| R0 \ | / | R4 |
| R5 \ |/ | |
---------ABR2----------ABR4-------
- ABR1, ABR2: Area0-Area1 ABRs - ABR3, ABR4: Area0-Area2 ABRs
- ABR1，ABR2:0区-1区ABRs-ABR3，ABR4:0区-2区ABRs
- R0, R1, R5: LSRs in area 1 - R2: an LSR in area 0 - R4: an LSR in area 2
- R0、R1、R5：区域1中的LSR-R2：区域0中的LSR-R4：区域2中的LSR
Although the terminology and examples provided in this document make use of the OSPF terminology, this document equally applies to IS-IS.
尽管本文件中提供的术语和示例使用了OSPF术语，但本文件同样适用于IS-IS。
Typically, an inter-area TE LSP will be set up between R0 and R4, where both LSRs belong to different IGP areas. Note that the solution MUST support the capability to protect such an inter-area TE LSP from the failure on any Link/SRLG/Node within any area and the failure of any traversed ABR. For instance, if the TE LSP R0->R4 goes through R1->ABR1->R2, then it can be protected against ABR1 failure, thanks to a backup LSP (detour or bypass) that may follow the alternate path R1->ABR2->R2.
通常，区域间TE LSP将设置在R0和R4之间，其中两个LSR属于不同的IGP区域。注意，该解决方案必须支持保护这样一个区域间TE LSP的能力，使其不受任何区域内任何链路/SRLG/节点上的故障和任何经过的ABR的故障的影响。例如，如果TE LSP R0->R4经过R1->ABR1->R2，则由于备用LSP（绕道或旁路）可能沿着备用路径R1->ABR2->R2，因此可以防止ABR1故障。
For instance, R0 and R4 may be two voice gateways located in distinct areas. An inter-area DS-TE LSP with class-type EF is set up from R1 to R4 to route VoIP traffic classified as EF. Per-class inter-area constraint-based routing allows the DS-TE LSP to be routed over a path that will ensure strict QoS guarantees for VoIP traffic.
例如，R0和R4可以是位于不同区域中的两个语音网关。在R1到R4之间设置类别类型为EF的区域间DS-TE LSP，以路由分类为EF的VoIP流量。基于每类区域间约束的路由允许DS-TE LSP通过一条路径进行路由，该路径将确保VoIP流量的严格QoS保证。
In another application, R0 and R4 may be two pseudo wire gateways residing in different areas. An inter-area LSP may be set up to carry pseudo wires.
在另一应用中，R0和R4可以是驻留在不同区域中的两个伪线网关。可以设置区域间LSP以承载伪线。
In some cases, it might also be possible to have an inter-area TE LSP from R0 to R5 transiting via the backbone area (or any other levels with IS-IS). There may be cases where there are no longer enough resources on any intra area path R0-to-R5, and where there is a feasible inter-area path through the backbone area.
在某些情况下，也可能有一个从R0到R5的区域间TE LSP通过主干区域（或IS-IS的任何其他级别）传输。可能存在这样的情况，即在任何区域内路径R0到R5上不再有足够的资源，并且存在通过骨干区域的可行区域间路径。
The inter-area MPLS TE solution MUST be consistent with requirements discussed in [TE-REQ], and the derived solution MUST interoperate seamlessly with current intra-area MPLS TE mechanisms and inherit its capability sets from [RSVP-TE].
区域间MPLS TE解决方案必须与[TE-REQ]中讨论的要求一致，衍生解决方案必须与当前区域内MPLS TE机制无缝互操作，并从[RSVP-TE]继承其能力集。
The proposed solution MUST allow provisioning at the head-end with end-to-end RSVP signaling (potentially with loose paths) traversing across the interconnected ABRs, without further provisioning required along the transit path.
建议的解决方案必须允许在前端进行资源调配，端到端RSVP信令（可能具有松散路径）穿过互连的ABR，而无需沿传输路径进行进一步的资源调配。
The solution MUST allow for the signaling of inter-area TE LSPs, using RSVP-TE.
解决方案必须允许使用RSVP-TE发送区域间TE LSP的信令。
In addition to the signaling of classical TE constraints (bandwidth, admin-groups), the proposed solution MUST allow the head-end LSR to specify a set of LSRs explicitly, including ABRs, by means of strict or loose hops for the inter-area TE LSP.
除了经典TE约束（带宽、管理组）的信令外，所提议的解决方案必须允许前端LSR通过区域间TE LSP的严格或松散跳数来明确地指定一组LSR，包括abr。
In addition, the proposed solution SHOULD also provide the ability to specify and signal certain resources to be explicitly excluded in the inter-area TE-LSP path establishment.
此外，建议的解决方案还应能够指定并发出信号，表明在区域间TE-LSP路径建立中明确排除某些资源。
In the context of this requirement document, an optimal path is defined as the shortest path across multiple areas, taking into account either the IGP or TE metric [METRIC]. In other words, such a path is the path that would have been computed by making use of some CSPF algorithm in the absence of multiple IGP areas.
在本需求文件的上下文中，最佳路径定义为跨多个区域的最短路径，同时考虑IGP或TE度量[metric]。换句话说，这样的路径是在没有多个IGP区域的情况下，通过使用某些CSPF算法计算的路径。
As mentioned in Section 5.2, the solution SHOULD provide the capability to compute an optimal path dynamically, satisfying a set of specified constraints (defined in [TE-REQ]) across multiple IGP areas. Note that this requirement document does not mandate that all inter-area TE LSPs require the computation of an optimal (shortest) inter-area path. Some inter-area TE-LSP paths may be computed via some mechanisms that do not guarantee an optimal end-to-end path, whereas some other inter-area TE-LSP paths carrying sensitive traffic could be computed by making use of mechanisms allowing an optimal end-to-end path to be computed dynamically. Note that regular constraints such as bandwidth, affinities, IGP/TE metric optimization, path diversity, etc., MUST be taken into account in the computation of an optimal end-to-end path.
如第5.2节所述，该解决方案应提供动态计算最优路径的能力，满足一组规定的约束条件（在[TE-REQ]中定义），跨越多个IGP区域。请注意，本要求文件并不要求所有区域间TE LSP需要计算最佳（最短）区域间路径。一些区域间TE-LSP路径可以通过一些不保证最佳端到端路径的机制来计算，而承载敏感业务的一些其他区域间TE-LSP路径可以通过使用允许动态计算最佳端到端路径的机制来计算。注意，在计算最佳端到端路径时，必须考虑诸如带宽、亲和力、IGP/TE度量优化、路径多样性等常规约束。
As mentioned in Section 5.3, IGP hierarchy does not allow the head-end LSR to compute an end-to-end optimal path. Additional mechanisms are required to compute an optimal path. These mechanisms MUST not alter the IGP hierarchy principles. Particularly, in order to maintain containment of routing information and to preserve the overall IGP scalability, the solution SHOULD avoid any dynamic-TE-topology-related information from leaking across areas, even in a summarized form.
如第5.3节所述，IGP层次结构不允许前端LSR计算端到端最佳路径。需要额外的机制来计算最佳路径。这些机制不得改变IGP层级原则。特别是，为了保持路由信息的包含并保持整体IGP可伸缩性，解决方案应避免任何动态TE拓扑相关信息跨区域泄漏，即使是以摘要形式泄漏。
Conversely, this does not preclude the leaking of non-topology-related information that is not taken into account during path selection, such as static TE Node information (TE router ids or TE node capabilities).
相反，这并不排除路径选择期间未考虑的非拓扑相关信息的泄漏，例如静态TE节点信息（TE路由器ID或TE节点能力）。
Several methods may be used for path computation, including the following:
路径计算可使用多种方法，包括以下方法：
- Per-area path computation based on ERO expansion on the head-end LSR and on ABRs, with two options for ABR selection:
- 基于前端LSR和ABR上ERO扩展的每区域路径计算，ABR选择有两个选项：
1) Static configuration of ABRs as loose hops at the head-end LSR. 2) Dynamic ABR selection.
1) ABR的静态配置为头端LSR处的松散跃点。2） 动态ABR选择。
- Inter-area end-to-end path computation, which may be based on (for instance) a recursive constraint-based searching thanks to collaboration between ABRs.
- 区域间端到端路径计算，可基于（例如）基于递归约束的搜索，这得益于ABR之间的协作。
Note that any path computation method may be used provided that it respect key objectives pointed out in Section 5.3.
注意，可使用任何路径计算方法，前提是该方法符合第5.3节中指出的关键目标。
If a solution supports more than one method, it should allow the operator to select by configuration, and on a per-LSP basis, the desired option.
如果解决方案支持多种方法，则应允许操作员通过配置并基于每个LSP选择所需选项。
Crankback routing, as defined in [CRANKBACK], may be used for inter-area TE LSPs. For paths computed thanks to ERO expansions with a dynamic selection of downstream ABRs, crankback routing can be used when there is no feasible path from a selected downstream ABR to the destination. The upstream ABR or head-end LSR selects another downstream ABR and performs ERO expansion.
[Crankback]中定义的回退布线可用于区域间TE LSP。对于通过动态选择下游ABR的ERO扩展计算的路径，当从所选下游ABR到目的地没有可行路径时，可以使用回退路由。上游ABR或前端LSR选择另一个下游ABR并执行ERO扩展。
Note that this method does not allow computing an optimal path but just a feasible path. Note also that there can be 0(N^2) LSP setup failures before finding a feasible path, where N is the average number of ABR between two areas. This may have a non-negligible impact on the LSP setup delay.
请注意，此方法不允许计算最优路径，只允许计算可行路径。还要注意的是，在找到可行路径之前，可能会有0（N^2）个LSP设置失败，其中N是两个区域之间ABR的平均数。这可能会对LSP设置延迟产生不可忽略的影响。
Crankback may also be used for inter-area LSP recovery. If a link/node/SRLG failure occurs in the backbone or tail-end area, the ABR upstream to the failure computes an alternate path and reroutes the LSP locally.
回退也可用于区域间LSP恢复。如果链路/节点/SRLG故障发生在主干或尾端区域，则故障上游的ABR计算备用路径并在本地重新路由LSP。
An inter-area MPLS-TE solution MAY support [CRANKBACK]. A solution that does, MUST allow [CRANKBACK] to be activated/deactivated via signaling, on a per-LSP basis.
区域间MPLS-TE解决方案可支持[回退]。这样做的解决方案必须允许在每个LSP的基础上通过信令激活/停用[回退]。
There are several cases where the ability to compute diversely-routed TE-LSP paths may be desirable. For instance, in the case of LSP protection, primary and backup LSPs should be diversely routed. Another example is the requirement to set up multiple diversely-routed TE LSPs between a pair of LSRs residing in different IGP areas. For instance, when a single TE LSP satisfying the bandwidth constraint cannot be found between two end-points, a solution would consist of setting up multiple TE LSPs so that the sum of their bandwidth satisfy the bandwidth requirement. In this case, it may be desirable to have these TE LSPs diversely routed in order to minimize the impact of a failure, on the traffic between the two end-points.
在一些情况下，可能需要计算不同路由的TE-LSP路径的能力。例如，在LSP保护的情况下，主LSP和备用LSP应分别路由。另一个例子是要求在位于不同IGP区域的一对LSR之间设置多个不同路由的TE LSP。例如，当在两个端点之间找不到满足带宽约束的单个TE-LSP时，解决方案将包括设置多个TE-LSP，以便它们的带宽总和满足带宽要求。在这种情况下，为了最小化故障对两个端点之间的通信量的影响，可能需要对这些TE-lsp进行不同的路由。
Thus, the solution MUST be able to establish diversely-routed inter-area TE LSPs when diverse paths exist. It MUST support all kinds of diversity (link, node, SRLG).
因此，当存在不同路径时，解决方案必须能够建立不同路由的区域间TE LSP。它必须支持各种多样性（链路、节点、SRLG）。
The solution SHOULD allow computing an optimal placement of diversely-routed LSPs. There may be various criteria to determine an optimal placement. For instance, the placement of two diversely routed LSPs for load-balancing purposes may consist of minimizing their cumulative cost. The placement of two diversely-routed LSPs for protection purposes may consist of minimizing the cost of the primary LSP while bounding the cost or hop count of the backup LSP.
该解决方案应允许计算不同路由LSP的最佳位置。可能有各种标准来确定最佳位置。例如，出于负载平衡目的放置两个不同路由的LSP可能包括最小化其累积成本。出于保护目的放置两个不同路由的LSP可能包括最小化主LSP的成本，同时限制备份LSP的成本或跳数。
For inter-area TE LSPs whose head-end and tail-end LSRs reside in the same IGP area, there may be intra-area and inter-area feasible paths. If the shortest path is an inter-area path, an operator either may want to avoid, as far as possible, crossing area and thus may prefer selecting a sub-optimal intra-area path or, conversely, may prefer to use a shortest path, even if it crosses areas. Thus, the solution should allow IGP area crossing to be enabled/disabled, on a per-LSP basis, for TE LSPs whose head-end and tail-end reside in the same IGP area.
对于头部和尾部LSR位于同一IGP区域的区域间TE LSP，可能存在区域内和区域间可行路径。如果最短路径是区域间路径，则操作员可能希望尽可能避免跨越区域，因此可能倾向于选择次优的区域内路径，或者相反，可能倾向于使用最短路径，即使它跨越区域。因此，该解决方案应允许在每个LSP的基础上，为前端和后端位于同一IGP区域的TE LSP启用/禁用IGP区域交叉。
The solution MUST provide the ability to reoptimize in a minimally disruptive manner (make before break) an inter-area TE LSP, should a more optimal path appear in any traversed IGP area. The operator should be able to parameterize such a reoptimization according to a timer or event-driven basis. It should also be possible to trigger such a reoptimization manually.
该解决方案必须提供以最小中断方式（先通后断）重新优化区域间TE LSP的能力，前提是在任何经过的IGP区域中出现更优的路径。操作员应能够根据计时器或事件驱动的基础参数化此类重新优化。也可以手动触发这种重新优化。
The solution SHOULD provide the ability to reoptimize an inter-area TE LSP locally within an area; i.e., while retaining the same set of transit ABRs. The reoptimization process in that case MAY be controlled by the head-end LSR of the inter-area LSP, or by an ABR. The ABR should check for local optimality of the inter-area TE LSPs established through it on a timer or event driven basis. The option of a manual trigger to check for optimality should also be provided.
解决方案应提供在区域内局部重新优化区域间TE LSP的能力；i、 e.，同时保留同一组传输ABR。这种情况下的再优化过程可由区域间LSP的前端LSR或ABR控制。ABR应在定时器或事件驱动的基础上检查通过其建立的区域间TE LSP的局部最优性。还应提供手动触发器选项，以检查最佳性。
In some cases it is important to restrict the control of reoptimization to the Head-End LSR only. Thus, the solution MUST allow for activating/deactivating ABR control of reoptimization, via signaling on a per LSP-basis.
在某些情况下，重要的是将再优化控制仅限于前端LSR。因此，该解决方案必须允许通过基于每个LSP的信令来激活/停用对再优化的ABR控制。
The solution SHOULD also provide the ability to perform an end-to-end reoptimization, potentially resulting in a change on the set of transit ABRs. Such reoptimization can only be controlled by the Head-End LSR.
该解决方案还应提供执行端到端重新优化的能力，这可能导致传输ABR集发生变化。这种再优化只能由前端LSR控制。
In the case of head-end control of reoptimization, the solution SHOULD provide the ability for the inter-area head-end LSR to be informed of the existence of a more optimal path in a downstream area and keep a strict control over the reoptimization process. Thus, the inter-area head-end LSR, once informed of a more optimal path in some downstream IGP areas, could decide to perform a make-before-break reoptimization gracefully (or not to), according to the inter-area TE-LSP characteristics.
在首端控制再优化的情况下，该解决方案应能使区域间首端LSR了解下游区域存在更优路径，并严格控制再优化过程。因此，一旦通知区域间前端LSR一些下游IGP区域中的更优路径，区域间前端LSR可根据区域间TE-LSP特性决定优雅地（或不）执行先通后断再优化。
The solution MUST support rerouting of an inter-area TE LSP in case of SRLG/link/node failure or preemption. Such rerouting may be controlled by the Head-End LSR or by an ABR (see Section 7.6, on crankback).
解决方案必须支持在SRLG/链路/节点故障或抢占的情况下重新路由区域间TE LSP。这种重路由可由前端LSR或ABR控制（见第7.6节，关于回退）。
The solution MUST provide the ability to benefit from fast recovery, making use of the local protection techniques specified in [FAST-REROUTE] both in the case of an intra-area network element failure (link/SRLG/node) and in that of an ABR node failure. Note that different protection techniques SHOULD be usable in different parts of the network to protect an inter-area TE LSP. This is of the utmost importance, particularly in the case of an ABR node failure, as this node typically carries a great deal of inter-area traffic. Moreover, the solution SHOULD allow computing and setting up a backup tunnel following an optimal path that offers bandwidth guarantees
该解决方案必须提供从快速恢复中获益的能力，在区域内网元故障（链路/SRLG/节点）和ABR节点故障的情况下，利用[fast-REROUTE]中规定的本地保护技术。注意，不同的保护技术应可用于网络的不同部分，以保护区域间TE LSP。这是最重要的，尤其是在ABR节点故障的情况下，因为该节点通常承载大量的区域间通信量。此外，该解决方案应允许按照提供带宽保证的最佳路径计算和设置备份隧道
during failure, along with other potential constraints (such as bounded propagation delay increase along the backup path).
故障期间，以及其他潜在约束（如沿备份路径有界传播延迟增加）。
The solution SHOULD allow ABRs to be protected, while providing the same level of performances (recovery delay, bandwidth consumption) as provided today within an area.
该解决方案应允许ABR得到保护，同时在一个区域内提供与当前相同水平的性能（恢复延迟、带宽消耗）。
Note that some signaling approaches may have an impact on FRR performances (recovery delay, bandwidth consumption). Typically, when some intra-area LSPs (LSP-Segment, FA-LSPs) are used to support the inter-area TE LSP, the protection of ABR using [FAST-REROUTE] may lead to higher bandwidth consumption and higher recovery delays. The use of [FAST-REROUTE] to protect ABRs, although ensuring the same level of performances, currently requires a single end-to-end RSVP session (contiguous LSP) to be used, without any intra-area LSP. Thus, the solution MUST provide the ability, via signalling on a per-LSP basis, to allow or preclude the use of intra-area LSPs to support the inter-area LSPs.
注意，一些信令方法可能会对FRR性能（恢复延迟、带宽消耗）产生影响。通常，当一些区域内LSP（LSP段，FA LSP）用于支持区域间TE LSP时，使用[快速重路由]对ABR的保护可能导致更高的带宽消耗和更高的恢复延迟。使用[FAST-REROUTE]保护ABR，虽然确保相同的性能水平，但目前需要使用单个端到端RSVP会话（连续LSP），而不使用任何区域内LSP。因此，解决方案必须通过基于每个LSP的信令来提供允许或排除使用区域内LSP来支持区域间LSP的能力。
The proposed inter-area MPLS TE solution SHOULD also satisfy core requirements documented in [DSTE-REQ] and interoperate seamlessly with current intra-area MPLS DS-TE mechanism [DSTE-PROTO].
建议的区域间MPLS-TE解决方案还应满足[DSTE-REQ]中记录的核心要求，并与当前的区域内MPLS DS-TE机制[DSTE-PROTO]无缝互操作。
In the case of a large inter-area MPLS deployment, potentially involving a large number of LSRs, it may be desirable/necessary to introduce some level of hierarchy in order to reduce the number of states on LSRs (such a solution implies other challenges). Thus, the proposed solution SHOULD allow inter-area TE-LSP aggregation (also referred to as LSP nesting) so that individual TE LSPs can be carried onto one or more aggregating LSPs. One such mechanism, for example, is described in [LSP-HIER].
在可能涉及大量lsr的大型区域间MPLS部署的情况下，为了减少lsr上的状态数量，可能需要引入某种层次结构（这种解决方案意味着其他挑战）。因此，建议的解决方案应允许区域间TE-LSP聚合（也称为LSP嵌套），以便单个TE-LSP可以携带到一个或多个聚合LSP上。例如，[LSP-HIER]中描述了一种这样的机制。
As defined in [MPLS-PREEMPT], two preemption models are applicable to MPLS: Soft and Hard Preemption.
如[MPLS-PREEMPT]中所定义，两种抢占模型适用于MPLS：软抢占和硬抢占。
An inter-area MPLS-TE solution SHOULD support the two models.
区域间MPLS-TE解决方案应支持这两种模型。
In the case of hard preemption, the preempted inter-area TE LSP should be rerouted, following requirements defined in Section 7.10.1.
在硬抢占的情况下，抢占的区域间TE LSP应按照第7.10.1节中定义的要求重新路由。
In the case of soft preemption, the preempted inter-area TE LSP should be re-optimized, following requirements defined in Section 7.9.
在软抢占的情况下，应按照第7.9节中定义的要求重新优化抢占的区域间TE LSP。
A TE mesh is a set of LSRs that are fully interconnected by a full mesh of TE LSPs. Because the number of LSRs participating in some TE mesh might be quite large, it might be desirable to provide some discovery mechanisms allowing an LSR to discover automatically the LSRs members of the TE mesh(es) that it belongs to. The discovery mechanism SHOULD be applicable across multiple IGP areas, and SHOULD not impact the IGP scalability, provided that IGP extensions are used for such a discovery mechanism.
TE网格是由TE LSP的完整网格完全互连的一组LSR。由于参与某些TE网格的LSR的数量可能相当大，因此可能需要提供一些发现机制，以允许LSR自动发现其所属TE网格的LSR成员。发现机制应适用于多个IGP区域，且不应影响IGP可伸缩性，前提是IGP扩展用于此类发现机制。
The proposed solution SHOULD be able to interoperate with fault detection mechanisms of intra-area MPLS TE.
建议的解决方案应该能够与区域内MPLS TE的故障检测机制互操作。
The solution SHOULD support [LSP-PING] and [MPLS-TTL].
解决方案应支持[LSP-PING]和[MPLS-TTL]。
The solution SHOULD also support fault detection on backup LSPs, in case [FAST-REROUTE] is deployed.
该解决方案还应支持在部署[快速重路由]的情况下对备份LSP进行故障检测。
In the case of intra-area MPLS TE, there are currently several possibilities for routing traffic into an intra-area TE LSP. They are listed in Section 4.2.
在区域内MPLS-TE的情况下，当前存在将业务路由到区域内TE-LSP的几种可能性。它们在第4.2节中列出。
In the case of inter-area MPLS TE, the solution MUST support static routing into the LSP, and also BGP recursive routing with a static route to the BGP next-hop address.
在区域间MPLS TE的情况下，解决方案必须支持到LSP的静态路由，以及到BGP下一跳地址的静态路由的BGP递归路由。
ABRs propagate IP reachability information (summary LSA in OSPF and IP reachability TLV in ISIS), that MAY be used by the head-end LSR to route traffic to a destination beyond the TE-LSP tail-head LSR (e.g., to an ASBR).
ABR传播IP可达性信息（OSPF中的概要LSA和ISIS中的IP可达性TLV），该信息可由前端LSR用于将流量路由到TE-LSP尾部LSR之外的目的地（例如，到ASBR）。
The use of IGP shortcuts MUST be precluded when TE-LSP head-end and tail-end LSRs do not reside in the same IGP area. It MAY be used when they reside in the same area.
当TE-LSP前端和后端LSR不在同一IGP区域内时，必须禁止使用IGP快捷方式。当他们居住在同一地区时，可以使用它。
The advertisement of an inter-area TE LSP as a link into the IGP, in order to attract traffic to an LSP source, MUST be precluded when TE-LSP head-end and tail-end LSRs do not reside in the same IGP area. It MAY be used when they reside in the same area.
当TE-LSP前端和后端LSR不在同一IGP区域中时，为了吸引到LSP源的流量，必须排除将区域间TE LSP作为IGP链路的广告。当他们居住在同一地区时，可以使用它。
The solution will be evaluated with respect to the following criteria:
将根据以下标准对解决方案进行评估：
(1) Optimality of the computed inter-area TE-LSP primary and backup paths, in terms of path cost. (2) Capability to share bandwidth among inter-area backup LSPs protecting independent facilities. (3) Inter-area TE-LSP setup time (in msec). (4) RSVP-TE and IGP scalability (state impact, number of messages, message size).
(1) 就路径成本而言，计算出的区域间TE-LSP主路径和备份路径的最优性。（2） 能够在保护独立设施的区域间备份LSP之间共享带宽。（3） 区域间TE-LSP设置时间（毫秒）。（4） RSVP-TE和IGP可伸缩性（状态影响、消息数量、消息大小）。
The proposed solution SHOULD not introduce 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网络上部署此类解决方案的好处。
In order to allow for a smooth migration or co-existence, the deployment of inter-area MPLS TE SHOULD not affect existing MPLS TE mechanisms. In particular, the solution SHOULD allow the setup of an inter-area TE LSP among transit LSRs that do not support inter-area extensions, provided that these LSRs do not participate in the inter-area TE procedure. For illustration purposes, the solution MAY require inter-area extensions only on end-point LSRs, on ABRs, and, potentially, on Points of Local Repair (PLR) protecting an ABR.
为了允许平滑迁移或共存，区域间MPLS-TE的部署不应影响现有MPLS-TE机制。特别是，解决方案应允许在不支持区域间扩展的运输LSR之间建立区域间TE LSP，前提是这些LSR不参与区域间TE程序。出于说明目的，该解决方案可能仅要求在端点LSR、ABR上以及可能在保护ABR的局部修复点（PLR）上进行区域间扩展。
This document does not introduce new security issues beyond those inherent in MPLS TE [RSVP-TE] and an inter-area MPLS-TE solution may use the same mechanisms proposed for that technology. It is, however, specifically important that manipulation of administratively configurable parameters be executed in a secure manner by authorized entities.
除MPLS-TE[RSVP-TE]中固有的安全问题外，本文件不会引入新的安全问题，区域间MPLS-TE解决方案可能会使用针对该技术提出的相同机制。然而，特别重要的是，授权实体应以安全的方式执行管理可配置参数的操作。
We would like to thank Dimitri Papadimitriou, Adrian Farrel, Vishal Sharma, and Arthi Ayyangar for their useful comments and suggestions.
我们要感谢Dimitri Papadimitriou、Adrian Farrel、Vishal Sharma和Arthi Ayyangar提出的有用意见和建议。
This document was the collective work of several authors. The text and content of this document was contributed by the editors and the co-authors listed below (the contact information for the editors appears in Section 14 and is not repeated below):
这份文件是几位作者的集体作品。本文件的文本和内容由以下列出的编辑和合著者提供（编辑的联系信息见第14节，下文不再重复）：
Ting-Wo Chung Yuichi Ikejiri Bell Canada NTT Communications Corporation 181 Bay Street, Suite 350, 1-1-6, Uchisaiwai-cho, Toronto, Chiyoda-ku, Tokyo 100-8019 Ontario, Canada, M5J 2T3 JAPAN
Ting Wo Chung Yueichi Ikejiri Bell Canada NTT Communications Corporation多伦多千代田区内石湾町1-1-6号海湾街181号350室日本安大略省东京100-8019 M5J 2T3
EMail: ting_wo.chung@bell.ca EMail: y.ikejiri@ntt.com
EMail: ting_wo.chung@bell.ca EMail: y.ikejiri@ntt.com
Raymond Zhang Parantap Lahiri Infonet Services Corporation MCI 2160 E. Grand Ave. 22001 Loudoun Cty Pky El Segundo, CA 90025 Ashburn, VA 20147 USA USA
Raymond Zhang Parantap Lahiri信息网络服务公司MCI 2160 E.Grand Ave.22001 Loudoun Cty Pky El Segundo，加利福尼亚州阿什本90025，弗吉尼亚州20147
EMail: raymond_zhang@infonet.com EMail: parantap.lahiri@mci.com
EMail: raymond_zhang@infonet.com EMail: parantap.lahiri@mci.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN
日本东京千代田区三大坂市久木健二株式会社花园航空塔，102-8460
EMail: ke-kumaki@kddi.com
EMail: ke-kumaki@kddi.com
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[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月。
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DSTE-REQ]Le Faucheur，F.和W.Lai，“支持区分服务感知MPLS流量工程的要求”，RFC 3564，2003年7月。
[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月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[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月。
[FAST-REROUTE] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[FAST-REROUTE]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE的快速重路由扩展”，RFC 40902005年5月。
[LSP-PING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, G., Wadhwa, S., Bonica, R., "Detecting Data Plane Liveliness in MPLS", Work in Progress.
[LSP-PING]Kompella，K.，Pan，P.，Sheth，N.，Cooper，D.，Swallow，G.，Wadhwa，S.，Bonica，R.，“在MPLS中检测数据平面的活跃性”，工作正在进行中。
[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月。
[LSP-HIER] Kompella, K., and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", Work in Progress.
[LSP-HIER]Kompella，K.和Y.Rekhter，“具有广义MPLS TE的LSP层次结构”，正在进行中。
[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月。
[CRANKBACK] Farrel, A., Ed., "Crankback Signaling Extensions for MPLS Signaling", Work in Progress.
[CRANKBACK]Farrel，A.，Ed.，“MPLS信令的CRANKBACK信令扩展”，正在进行中。
[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月。
[DSTE-PROTO] Le Faucheur, F., et al., "Protocol Extensions for Support of Differentiated-Service-aware MPLS Traffic Engineering", Work in Progress.
[DSTE-PROTO]Le Faucheur，F.等人，“支持区分服务感知MPLS流量工程的协议扩展”，正在进行中。
[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-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption", Work in Progress.
[MPLS-PREEMPT]Farrel，A.，“关于MPLS先发制人的中期报告”，正在进行的工作。
[METRIC] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 2004.
[度量]Le Faucheur，F.，Uppili，R.，Vedrene，A.，Merckx，P.，和T.Telkamp，“内部网关协议（IGP）度量作为第二个MPLS流量工程（TE）度量的使用”，BCP 87，RFC 3785，2004年5月。
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
Jean-Louis Le Roux法国电信2号，Pierre Marzin大街22307兰尼昂塞德斯法国
EMail: jeanlouis.leroux@francetelecom.com
EMail: jeanlouis.leroux@francetelecom.com
Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA - 01719 USA
Jean-Philippe Vasseur Cisco Systems，Inc.美国马萨诸塞州Boxborough市比弗布鲁克路300号-01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Jim Boyle
吉姆·博伊尔
EMail: jboyle@pdnets.com
EMail: jboyle@pdnets.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编辑功能的资金目前由互联网协会提供。