Network Working Group JP. Vasseur, Ed.
Request for Comments: 4736 Cisco Systems, Inc.
Category: Informational Y. Ikejiri
NTT Communications Corporation
R. Zhang
BT Infonet
November 2006
Network Working Group JP. Vasseur, Ed.
Request for Comments: 4736 Cisco Systems, Inc.
Category: Informational Y. Ikejiri
NTT Communications Corporation
R. Zhang
BT Infonet
November 2006
Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)
多协议标签交换（MPLS）流量工程（TE）松路由标签交换路径（LSP）的再优化
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 IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path.
本文档定义了一种用于重新优化松散路由MPLS和GMPLS（通用多协议标签交换）流量工程（TE）的机制，该流量工程（TE）是通过资源预留协议流量工程（RSVP-TE）发出信号的标签交换路径（LSP）。本文件提出了一种机制，允许TE LSP前端标签交换路由器（LSR）在具有定义为松散或抽象跳的下一跳和中点LSR的每个跳上触发新路径重新评估，以向前端LSR发送信号，表明存在更好的路径（与当前路径相比），或TE LSP必须重新优化（由于TE LSP路径上需要维护）。建议的机制适用于域内和域间（内部网关协议区域（IGP区域）或自治系统）分组和非分组TE LSP遵循松散路由路径的情况。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. Establishment of a Loosely Routed TE LSP ........................4
4. Reoptimization of a Loosely Routed TE LSP Path ..................6
5. Signaling Extensions ............................................7
5.1. Path Re-Evaluation Request .................................7
5.2. New Error Value Sub-Codes ..................................7
6. Mode of Operation ...............................................7
6.1. Head-End Reoptimization Control ............................7
6.2. Reoptimization Triggers ....................................8
6.3. Head-End Request versus Mid-Point Explicit
Notification Functions .....................................8
6.3.1. Head-End Request Function ...........................8
6.3.2. Mid-Point Explicit Notification ....................10
6.3.3. ERO Caching ........................................10
7. Applicability and Interoperability .............................11
8. IANA Considerations ............................................11
9. Security Considerations ........................................11
10. Acknowledgements ..............................................12
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................12
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Requirements Language ......................................4
3. Establishment of a Loosely Routed TE LSP ........................4
4. Reoptimization of a Loosely Routed TE LSP Path ..................6
5. Signaling Extensions ............................................7
5.1. Path Re-Evaluation Request .................................7
5.2. New Error Value Sub-Codes ..................................7
6. Mode of Operation ...............................................7
6.1. Head-End Reoptimization Control ............................7
6.2. Reoptimization Triggers ....................................8
6.3. Head-End Request versus Mid-Point Explicit
Notification Functions .....................................8
6.3.1. Head-End Request Function ...........................8
6.3.2. Mid-Point Explicit Notification ....................10
6.3.3. ERO Caching ........................................10
7. Applicability and Interoperability .............................11
8. IANA Considerations ............................................11
9. Security Considerations ........................................11
10. Acknowledgements ..............................................12
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................12
This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering LSPs signaled with RSVP-TE (see [RFC3209] and [RFC3473]). A loosely routed LSP is defined as one that does not contain a full, explicit route identifying each LSR along the path of the LSP at the time it is signaled by the ingress LSR. Such an LSP is signaled with no Explicit Route Object (ERO), with an ERO that contains at least one loose hop, or with an ERO that contains an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR).
本文件定义了用RSVP-TE（参见[RFC3209]和[RFC3473]）发送信号的松路由MPLS和GMPLS（通用多协议标签交换）流量工程LSP的再优化机制。松散路由LSP被定义为在入口LSR发出信号时不包含沿LSP路径标识每个LSR的完整、显式路由的LSP。这样的LSP不使用显式路由对象（ERO）、包含至少一个松散跃点的ERO或包含不是简单抽象节点的抽象节点（即，标识多个LSR的抽象节点）的ERO来发送信号。
The Traffic Engineering Working Group (TE WG) has specified a set of requirements for inter-area and inter-AS MPLS Traffic Engineering (see [RFC4105] and [RFC4216]). Both requirements documents specify the need for some mechanism providing an option for the head-end LSR to control the reoptimization process should a more optimal path exist in a downstream domain (IGP area or Autonomous System). This document defines a solution to meet this requirement and proposes two mechanisms:
流量工程工作组（TE WG）规定了区域间和AS间MPLS流量工程的一组要求（见[RFC4105]和[RFC4216]）。这两个需求文件都规定了需要某种机制，如果下游域（IGP区域或自治系统）中存在更优的路径，则为前端LSR提供控制再优化过程的选项。本文件定义了满足此要求的解决方案，并提出了两种机制：
(1) The first mechanism allows a head-end LSR to trigger a new path re-evaluation on every hop that has a next hop defined as a loose hop or abstract node and get a notification from the mid-point as to whether a better path exists.
(1) 第一种机制允许前端LSR在具有定义为松散跳或抽象节点的下一跳的每个跳上触发新路径重新评估，并从中点获得关于是否存在更好路径的通知。
(2) The second mechanism allows a mid-point LSR to explicitly signal to the head-end LSR either that a better path exists to reach a loose/abstract hop (compared to the current path) or that the TE LSP must be reoptimized because of some maintenance required along the TE LSP path. In this case, the notification is sent by the mid-point LSR without being polled by the head-end LSR.
(2) 第二种机制允许中点LSR显式地向前端LSR发送信号，表明存在更好的路径以达到松散/抽象跃点（与当前路径相比），或者TE LSP必须重新优化，因为TE LSP路径上需要一些维护。在这种情况下，通知由中点LSR发送，而不由前端LSR轮询。
A better path is defined as a lower cost path, where the cost is determined by the metric used to compute the path.
更好的路径定义为成本较低的路径，其中成本由用于计算路径的度量确定。
ABR: Area Border Router.
区域边界路由器。
ERO: Explicit Route Object.
ERO：显式路由对象。
LSR: Label Switching Router.
标签交换路由器。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：流量工程标签交换路径。
TE LSP head-end: head/source of the TE LSP.
TE LSP头端：TE LSP的头/源。
TE LSP tail-end: tail/destination of the TE LSP.
TE LSP尾部：TE LSP的尾部/目的地。
Interior Gateway Protocol Area (IGP Area): OSPF Area or IS-IS level.
内部网关协议区（IGP区）：OSPF区或IS-IS级。
Intra-area TE LSP: A TE LSP whose path does not transit across areas.
区域内TE LSP：路径不跨区域的TE LSP。
Inter-area TE LSP: A TE LSP whose path transits across at least two different IGP areas.
区域间TE LSP：其路径穿过至少两个不同IGP区域的TE LSP。
Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least two different Autonomous Systems (ASes) or sub-ASes (BGP confederations).
Inter-AS-MPLS-TE-LSP：一种TE-LSP，其路径至少跨越两个不同的自治系统（ase）或子ase（BGP联盟）。
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]中所述进行解释。
The aim of this section is purely to summarize the mechanisms involved in the establishment of a loosely routed TE LSP, as specified in [RFC3209]. The reader should see RFC 3209 for a more detailed description of these mechanisms.
本节的目的纯粹是总结[RFC3209]中规定的建立松散路由TE LSP所涉及的机制。读者应参阅RFC3209了解这些机制的更详细描述。
In the context of this document, a loosely routed LSP is defined as one that does not contain a full, explicit route identifying each LSR along the path of the LSP at the time it is signaled by the ingress LSR. Such an LSP is signaled with no ERO, with an ERO that contains at least one loose hop, or with an ERO that contains an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR). As specified in [RFC3209], loose hops are listed in the ERO object of the RSVP Path message with the L flag of the IPv4 or the IPv6 prefix sub-object set.
在本文档的上下文中，松散路由LSP被定义为不包含完整的显式路由的LSP，该路由在入口LSR发出信号时沿LSP路径标识每个LSR。这样的LSP以无ERO、包含至少一个松散跃点的ERO或包含不是简单抽象节点的抽象节点（即，标识多个LSR的抽象节点）的ERO为信号。如[RFC3209]所述，松散跃点在RSVP Path消息的ERO对象中列出，带有IPv4或IPv6前缀子对象集的L标志。
Each LSR along the path whose next hop is specified as a loose hop or a non-specific abstract node triggers a path computation (also referred to as an ERO expansion), before forwarding the RSVP Path message downstream. The computed path may be either partial (up to the next loose hop) or complete (set of strict hops up to the TE LSP destination).
在向下游转发RSVP path消息之前，沿其下一跳被指定为松散跳或非特定抽象节点的路径的每个LSR触发路径计算（也称为ERO扩展）。计算出的路径可以是部分的（直到下一个松散跳）或完整的（直到TE LSP目的地的一组严格跳）。
Note that although the examples in the rest of this document are provided in the context of MPLS inter-area TE, the proposed mechanism applies equally to loosely routed paths within a single routing
请注意，尽管本文档其余部分中的示例是在MPLS区域间TE的上下文中提供的，但建议的机制同样适用于单个路由中的松散路由路径
domain and across multiple Autonomous Systems. The examples below are provided with OSPF as the IGP, but the described set of mechanisms similarly apply to IS-IS.
域和跨多个自治系统。以下示例以OSPF作为IGP提供，但所述机制集同样适用于IS-IS。
An example of an explicit loosely routed TE LSP signaling follows.
下面是显式松散路由TE LSP信令的示例。
<---area 1--><-area 0--><-area 2->
<---area 1--><-area 0--><-area 2->
R1---R2----R3---R6 R8---R10
| | | / | \ |
| | | / | \ |
| | | / | \|
R4---------R5---R7----R9---R11
R1---R2----R3---R6 R8---R10
| | | / | \ |
| | | / | \ |
| | | / | \|
R4---------R5---R7----R9---R11
Assumptions
假设
- R3, R5, R8, and R9 are ABRs.
- R3、R5、R8和R9是ABR。
- The path of an inter-area TE LSP T1 from R1 (head-end LSR) to R11 (tail-end LSR) is defined on R1 as the following loosely routed path: R1-R3(loose)-R8(loose)-R11(loose). R3, R8, and R11 are defined as loose hops.
- 区域间TE LSP T1从R1（前端LSR）到R11（后端LSR）的路径在R1上定义为以下松散路由路径：R1-R3（松散）-R8（松散）-R11（松散）。R3、R8和R11被定义为松散跃点。
Step 1: R1 determines that the next hop (R3) is a loose hop (not directly connected to R1) and then performs an ERO expansion operation to reach the next loose hops R3. The new ERO becomes: R2(S)-R3(S)-R8(L)-R11(L), where S is a strict hop (L=0) and L is a loose hop (L=1).
步骤1:R1确定下一个跃点（R3）是松散跃点（未直接连接到R1），然后执行ERO扩展操作以到达下一个松散跃点R3。新的ERO变为：R2（S）-R3（S）-R8（L）-R11（L），其中S是严格跃点（L=0），L是松散跃点（L=1）。
The R1-R2-R3 path satisfies T1's set of constraints.
R1-R2-R3路径满足T1的约束集。
Step 2: The RSVP Path message is then forwarded by R1 following the path specified in the ERO object and reaches R3 with the following content: R8(L)-R11(L).
步骤2：RSVP Path消息随后由R1按照ERO对象中指定的路径转发，并到达R3，内容如下：R8（L）-R11（L）。
Step 3: R3 determines that the next hop (R8) is a loose hop (not directly connected to R3) and then performs an ERO expansion operation to reach the next loose hops R8. The new ERO becomes: R6(S)-R7(S)-R8(S)-R11(L).
步骤3:R3确定下一个跃点（R8）是松散跃点（未直接连接到R3），然后执行ERO扩展操作以到达下一个松散跃点R8。新能源监管局成为：R6（S）-R7（S）-R8（S）-R11（L）。
Note: In this example, the assumption is made that the path is computed on a per-loose-hop basis, also referred to as a partial route computation. Note that other path computation techniques may result in complete paths (set of strict hops up to the final destination).
注意：在本例中，假设路径是基于每松散跳计算的，也称为部分路由计算。请注意，其他路径计算技术可能导致完整路径（到最终目的地的严格跳集）。
Step 4: The same procedure is repeated by R8 to reach T1's destination (R11).
步骤4：R8重复相同的过程以到达T1的目的地（R11）。
Once a loosely routed, explicit TE LSP is set up, it is maintained through normal RSVP procedures. During the TE LSP lifetime, a more optimal path might appear between an LSR and its next loose hop (for the sake of illustration, suppose that in the example above a link between R6 and R8 is added or restored that provides a preferable path between R3 and R8 (R3-R6-R8) than the existing R3-R6-R7-R8 path). Since a preferable (e.g., shorter) path might not be visible from the head-end LSR by means of the IGP if the head-end LSR does not belong to the same IGP area where the associated topology change occurred, the head-end cannot make use of this shorter path (and reroute the LSP using a make-before-break technique as described in [RFC3209]) when appropriate. Thus, a new mechanism specified in this document is required to detect the existence of such a preferable path and to notify the head-end LSR accordingly.
一旦建立了一个松散路由的显式TE LSP，它将通过正常的RSVP过程进行维护。在TE LSP寿命期间，在LSR与其下一个松散跃点之间可能出现更优化的路径（为了说明，假设在上述示例中，添加或恢复了R6和R8之间的链路，该链路在R3和R8之间提供了比现有R3-R6-R7-R8路径更好的路径（R3-R6-R8）。由于如果前端LSR不属于发生相关拓扑变化的同一IGP区域，则通过IGP从前端LSR可能看不到优选（例如，较短）路径，因此前端无法使用该较短路径（并使用[RFC3209]中所述的先通后断技术重新路由LSP）在适当的时候。因此，需要本文件中指定的新机制来检测这种优选路径的存在并相应地通知前端LSR。
This document defines a mechanism that allows
本文档定义了一种允许
- a head-end LSR to trigger on every LSR whose next hop is a loose hop or an abstract node the re-evaluation of the current path in order to detect a potentially more optimal path; and
- 前端LSR，用于在其下一跳为松散跳或抽象节点的每个LSR上触发对当前路径的重新评估，以便检测潜在的更优路径；和
- a mid-point LSR whose next hop is a loose-hop or an abstract node to signal (using a new Error Value sub-code carried in a RSVP PathErr message) to the head-end LSR that a preferable path exists (a path with a lower cost, where the cost definition is determined by some metric).
- 一种中点LSR，其下一跳为松散跳或抽象节点，以（使用RSVP PathErr消息中携带的新错误值子码）向前端LSR发送信号，表明存在优选路径（成本较低的路径，其中成本定义由某个度量确定）。
Once the head-end LSR has been notified of the existence of such a preferable path, it can decide (depending on the TE LSP characteristics) whether to perform a TE LSP graceful reoptimization such as the "make-before-break" procedure.
一旦头部LSR被通知存在这样的优选路径，它就可以决定（取决于TE-LSP特性）是否执行TE-LSP优雅的再优化，例如“先通后断”过程。
There is another scenario whereby notifying the head-end LSR of the existence of a better path is desirable: if the current path is about to fail due to some (link or node) required maintenance.
还有另一种情况，需要通知前端LSR存在更好的路径：如果当前路径由于某些（链路或节点）需要维护而即将失败。
This mechanism allows the head-end LSR to reoptimize a TE LSP by making use of the non-disruptive make-before-break procedure if and only if a preferable path exists and if such a reoptimization is desired.
当且仅当存在优选路径且需要这种再优化时，该机制允许前端LSR通过使用无中断先通后断程序来重新优化TE LSP。
A new flag in the SESSION ATTRIBUTE object and new Error Value sub-codes in the ERROR SPEC object are proposed in this document.
本文提出了会话属性对象中的新标志和错误规范对象中的新错误值子代码。
The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and 7) is defined:
定义了会话_属性对象（C类型1和7）的以下新标志：
Path re-evaluation request: 0x20
路径重新评估请求：0x20
This flag indicates that a path re-evaluation (of the current path in use) is requested. Note that this does not trigger any LSP Reroute but instead just signals a request to evaluate whether a preferable path exists.
此标志表示请求（正在使用的当前路径的）路径重新评估。请注意，这不会触发任何LSP重新路由，而只是向请求发出信号，以评估是否存在更好的路径。
Note: In case of link bundling, for instance, although the resulting ERO might be identical, this might give the opportunity for a mid-point LSR to locally select another link within a bundle. However, strictly speaking, the ERO has not changed.
注意：例如，在链接绑定的情况下，虽然生成的ERO可能相同，但这可能使中点LSR有机会在绑定中本地选择另一个链接。然而，严格来说，能源监管局并未改变。
As defined in [RFC3209], the Error Code 25 in the ERROR SPEC object corresponds to a Notify Error.
如[RFC3209]中所定义，Error SPEC对象中的错误代码25对应于Notify错误。
This document adds three new Error Value sub-codes:
本文档添加了三个新的错误值子代码：
6 Preferable path exists
6.存在更好的路径
7 Local link maintenance required
7需要本地链路维护
8 Local node maintenance required
8需要本地节点维护
The details about the local maintenance required modes are in Section 6.3.2.
有关本地维护所需模式的详细信息，请参见第6.3.2节。
The notification process of a preferable path (shorter path or new path due to some maintenance required on the current path) is by nature de-correlated from the reoptimization operation. In other words, the location where a potentially preferable path is discovered does not have to be where the TE LSP is actually reoptimized. This document applies to the context of a head-end LSR reoptimization.
优选路径（较短路径或由于当前路径上需要一些维护而产生的新路径）的通知过程本质上与重新优化操作无关。换句话说，发现潜在优选路径的位置不必是TE LSP实际被重新优化的位置。本文件适用于前端LSR再优化的环境。
There are several possible reoptimization triggers:
有几种可能的重新优化触发器：
- Timer-based: A reoptimization is triggered (process evaluating whether a more optimal path can be found) when a configurable timer expires.
- 基于计时器：当可配置计时器过期时，会触发重新优化（评估是否可以找到更优化路径的过程）。
- Event-driven: A reoptimization is triggered when a particular network event occurs (such as a "Link-UP" event).
- 事件驱动：当发生特定网络事件（如“连接”事件）时，会触发重新优化。
- Operator-driven: A reoptimization is manually triggered by the Operator.
- 操作员驱动：操作员手动触发重新优化。
It is RECOMMENDED that an implementation supporting the extensions proposed in this document support the aforementioned modes as path re-evaluation triggers.
建议支持本文档中提出的扩展的实现支持上述模式作为路径重新评估触发器。
This document defines two functions:
本文件定义了两个功能：
1) "Head-end requesting function": The request for a new path evaluation of a loosely routed TE LSP is requested by the head-end LSR.
1) “前端请求功能”：对松散路由TE LSP的新路径评估请求由前端LSR请求。
2) "Mid-point explicit notification function": Having determined that a preferable path (other than the current path) exists or having the need to perform a link/node local maintenance, a mid-point LSR explicitly notifies the head-end LSR, which will in turn decide whether to perform a reoptimization.
2) “中点显式通知功能”：确定存在首选路径（当前路径除外）或需要执行链路/节点本地维护后，中点LSR显式通知前端LSR，而前端LSR将决定是否执行重新优化。
When a timer-based reoptimization is triggered on the head-end LSR or the operator manually requests a reoptimization, the head-end LSR immediately sends an RSVP Path message with the "Path re-evaluation request" bit of the SESSION-ATTRIBUTE object set. This bit is then cleared in subsequent RSVP path messages sent downstream. In order to handle the case of a lost Path message, the solution consists of relying on the reliable messaging mechanism described in [RFC2961].
当在前端LSR上触发基于计时器的重新优化或操作员手动请求重新优化时，前端LSR立即发送RSVP Path消息，其中包含会话属性对象集的“路径重新评估请求”位。然后，在随后发送到下游的RSVP path消息中清除该位。为了处理丢失路径消息的情况，解决方案包括依赖[RFC2961]中描述的可靠消息机制。
Upon receiving a Path message with the "Path re-evaluation request" bit set, every LSR for which the next abstract node contained in the ERO is defined as a loose hop/abstract node performs the following set of actions:
在接收到带有“路径重新评估请求”位集的路径消息时，ERO中包含的下一个抽象节点被定义为松散跃点/抽象节点的每个LSR执行以下一组操作：
A path re-evaluation is triggered, and the newly computed path is compared to the existing path:
触发路径重新评估，并将新计算的路径与现有路径进行比较：
- If a preferable path can be found, the LSR performing the path re-evaluation MUST immediately send an RSVP PathErr to the head-end LSR (Error code 25 (Notify), Error sub-code=6 (better path exists)). At this point, the LSR MAY decide not to propagate this bit in subsequent RSVP Path messages sent downstream for the re-evaluated TE LSP; this mode is the RECOMMENDED mode for the reasons described below.
- 如果可以找到更好的路径，则执行路径重新评估的LSR必须立即向前端LSR发送RSVP路径错误（错误代码25（通知），错误子代码=6（存在更好的路径））。此时，LSR可以决定不在为重新评估的TE LSP向下游发送的后续RSVP路径消息中传播该比特；此模式是推荐的模式，原因如下所述。
The sending of an RSVP PathErr Notify message "Preferable path exists" to the head-end LSR will notify the head-end LSR of the existence of a preferable path (e.g., in a downstream area/AS or in another location within a single domain). Therefore, triggering additional path re-evaluations on downstream nodes is unnecessary. The only motivation to forward subsequent RSVP Path messages with the "Path re-evaluation request" bit of the SESSION-ATTRIBUTE object set would be to trigger path re-evaluation on downstream nodes that could in turn cache some potentially better paths downstream, with the objective to reduce the signaling setup delay, should a reoptimization be performed by the head-end LSR.
向头端LSR发送RSVP PathErr Notify消息“优选路径存在”将通知头端LSR优选路径的存在（例如，在下游区域/AS中或在单个域内的另一位置）。因此，在下游节点上重新触发额外的路径计算是不必要的。使用会话属性对象集的“路径重新评估请求”位转发后续RSVP路径消息的唯一动机是触发下游节点上的路径重新评估，从而缓存一些可能更好的下游路径，目的是减少信令设置延迟，是否由前端LSR执行重新优化。
- If no preferable path can be found, the recommended mode is for an LSR to relay the request (by setting the "Path re-evaluation" bit of the SESSION-ATTRIBUTE object in RSVP path message sent downstream).
- 如果找不到更好的路径，建议的模式是LSR中继请求（通过在发送到下游的RSVP path消息中设置会话属性对象的“路径重新评估”位）。
Note that, by preferable path, we mean a path with a lower cost.
请注意，我们所说的首选路径是指成本较低的路径。
If the RSVP Path message with the "Path re-evaluation request" bit set is lost, then the next request will be sent when the next reoptimization trigger will occur on the head-end LSR. The solution to handle RSVP reliable messaging has been defined in [RFC2961].
如果设置了“路径重新评估请求”位的RSVP Path消息丢失，则在前端LSR上发生下一次重新优化触发时，将发送下一个请求。[RFC2961]中定义了处理RSVP可靠消息的解决方案。
The network administrator may decide to establish some local policy specifying to ignore such request or not to consider those requests more frequently than at a certain rate.
网络管理员可以决定建立一些本地策略来指定忽略这样的请求，或者不以比某个速率更频繁地考虑这些请求。
The proposed mechanism does not make any assumption of the path computation method performed by the ERO expansion process.
提出的机制没有对ERO展开过程执行的路径计算方法进行任何假设。
By contrast with the head-end request function, in this case, a mid-point LSR whose next hop is a loose hop or an abstract node can locally trigger a path re-evaluation when a configurable timer expires, some specific events occur (e.g., link-up event), or the user explicitly requests it. If a preferable path is found, the LSR sends an RSVP PathErr to the head-end LSR (Error code 25 (Notify), Error sub-code=6 ("preferable path exists").
与前端请求功能相反，在这种情况下，当可配置计时器过期、发生某些特定事件（例如，链接事件）或用户明确请求时，其下一跳为松散跳或抽象节点的中点LSR可以在本地触发路径重新评估。如果找到优选路径，则LSR向前端LSR发送RSVP路径错误（错误代码25（通知），错误子代码=6（“优选路径存在”）。
There is another circumstance whereby any mid-point LSR MAY send an RSVP PathErr message with the objective for the TE LSP to be rerouted by its head-end LSR: when a link or a node will go down for local maintenance reasons. In this case, the LSR where a local maintenance must be performed is responsible for sending an RSVP PathErr message with Error code 25 and Error sub-code=7 or 8, depending on the affected network element (link or node). Then the first upstream node that has performed the ERO expansion MUST perform the following set of actions:
还有另一种情况，任何中点LSR都可以发送RSVP PathErr消息，目的是使TE LSP通过其前端LSR重新路由：当链路或节点因本地维护原因停机时。在这种情况下，必须执行本地维护的LSR负责发送错误代码为25且错误子代码=7或8的RSVP PathErr消息，具体取决于受影响的网元（链路或节点）。然后，执行ERO扩展的第一个上游节点必须执行以下一组操作：
- The link (sub-code=7) or the node (sub-code=8) MUST be locally registered for further reference (the TE database must be updated).
- 链接（子代码=7）或节点（子代码=8）必须在本地注册以供进一步参考（TE数据库必须更新）。
- The RSVP PathErr message MUST be immediately forwarded upstream to the head-end LSR. Note that in the case of TE LSP spanning multiple administrative domains, it may be desirable for the boundary LSR to modify the RSVP PathErr message and insert its own address for confidentiality.
- RSVP PathErr消息必须立即向上游转发到前端LSR。注意，在TE LSP跨越多个管理域的情况下，可能需要边界LSR修改RSVP PathErr消息并插入其自己的地址以保密。
Upon receiving an RSVP PathErr message with Error code 25 and Error sub-code 7 or 8, the head-end LSR SHOULD perform a TE LSP reoptimization.
接收到错误代码为25且错误子代码为7或8的RSVP PathErr消息后，前端LSR应执行TE LSP重新优化。
Note that the two functions (head-end and mid-point driven) are not exclusive of each other: both the timer and event-driven reoptimization triggers can be implemented on the head-end or on any mid-point LSR with a potentially different timer value for the timer-driven reoptimization case.
请注意，这两个功能（前端和中点驱动）并非相互排斥：计时器和事件驱动的再优化触发器都可以在前端或任何中点LSR上实现，对于计时器驱动的再优化情况，计时器值可能不同。
A head-end LSR MAY decide upon receiving an explicit mid-point notification to delay its next path re-evaluation request.
前端LSR可在接收到显式中点通知时决定延迟其下一路径重新评估请求。
Once a mid-point LSR has determined that a preferable path exists (after a reoptimization request has been received by the head-end LSR or the reoptimization timer on the mid-point has expired), the more optimal path MAY be cached on the mid-point LSR for a limited amount
一旦中点LSR已经确定存在优选路径（在前端LSR已经接收到重新优化请求或者中点上的重新优化定时器已经过期之后），可以在中点LSR上有限量地缓存更优路径
of time to avoid having to recompute a path once the head-LSR performs a make-before-break. This mode is optional. A default value of 5 seconds for the caching timer is suggested.
避免在磁头LSR执行先通后断时重新计算路径所需的时间。此模式是可选的。建议缓存计时器的默认值为5秒。
The procedures described in this document are entirely optional within an MPLS or GMPLS network. Implementations that do not support the procedures described in this document will interoperate seamlessly with those that do. Further, an implementation that does not support the procedures described in this document will not be impacted or implicated by a neighboring implementation that does implement the procedures.
本文档中描述的过程在MPLS或GMPLS网络中是完全可选的。不支持本文档中描述的过程的实现将与支持这些过程的实现无缝地互操作。此外，不支持本文件所述程序的实施不会受到实施程序的相邻实施的影响或牵连。
An ingress implementation that chooses not to support the procedures described in this document may still achieve re-optimization by periodically issuing a speculative make-before-break replacement of an LSP without trying to discovery whether a more optimal path is available in a downstream domain. Such a procedure would not be in conflict with any mechanisms already documented in [RFC3209] and [RFC3473].
选择不支持本文档中描述的过程的入口实现仍然可以通过周期性地发出LSP的推测性先通后断替换来实现重新优化，而不尝试发现下游域中是否存在更优化的路径。该程序不会与[RFC3209]和[RFC3473]中已记录的任何机制发生冲突。
An LSR not supporting the "Path re-evaluation request" bit of the SESSION-ATTRIBUTE object SHALL forward it unmodified.
不支持会话属性对象的“路径重新评估请求”位的LSR应不经修改地转发它。
A head-end LSR not supporting an RSVP PathErr with Error code 25 message and Error sub-code = 6, 7, or 8 MUST just silently ignore such an RSVP PathErr message.
不支持错误代码为25消息且错误子代码为6、7或8的RSVP PathErr的前端LSR必须静默忽略此类RSVP PathErr消息。
IANA assigned three new error sub-code values for the RSVP PathErr Notify message (Error code=25):
IANA为RSVP PathErr Notify消息分配了三个新的错误子代码值（错误代码=25）：
6 Preferable path exists
6.存在更好的路径
7 Local link maintenance required
7需要本地链路维护
8 Local node maintenance required
8需要本地节点维护
This document defines a mechanism for a mid-point LSR to notify the head-end LSR of the existence of a preferable path or the need to reroute the TE LSP for maintenance purposes. Hence, in the case of a TE LSP spanning multiple administrative domains, it may be desirable for a boundary LSR to modify the RSVP PathErr message (Code 25, Error sub-code = 6, 7, or 8) so as to preserve confidentiality across
本文件定义了中点LSR的机制，用于通知前端LSR存在优选路径或需要为维护目的重新路由TE LSP。因此，在跨越多个管理域的TE LSP的情况下，边界LSR可能希望修改RSVP PathErr消息（代码25，错误子代码＝6、7或8），以便跨多个管理域保持机密性
domains. Furthermore, a head-end LSR may decide to ignore explicit notification coming from a mid-point residing in another domain. Similarly, an LSR may decide to ignore (or to accept up to a pre-defined rate) path re-evaluation requests originated by a head-end LSR of another domain.
域名。此外，前端LSR可以决定忽略来自驻留在另一域中的中点的显式通知。类似地，LSR可以决定忽略（或接受高达预定义速率的）由另一域的前端LSR发起的路径重新评估请求。
The authors would like to thank Carol Iturralde, Miya Kohno, Francois Le Faucheur, Philip Matthews, Jim Gibson, Jean-Louis Le Roux, Kenji Kumaki, Anca Zafir, and Dimitri Papadimitriou for their useful comments. A special thanks to Adrian Farrel for his very valuable inputs.
作者要感谢Carol Iturralde、Miya Kohno、Francois Le Faucheur、Philip Matthews、Jim Gibson、Jean-Louis Le Roux、Kenji Kumaki、Anca Zafir和Dimitri Papadimitriou的有用评论。特别感谢阿德里安·法雷尔的宝贵意见。
[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月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[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., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]Le Roux，J.-L.，Vasseur，J.-P.，和J.Boyle，“区域间MPLS流量工程的要求”，RFC 4105，2005年6月。
[RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.和J.-P.Vasseur，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年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
Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-8019 Japan
Yuichi Ikejiri NTT通信公司1-1-6，日本东京千代田区内石湾町，100-8019
EMail: y.ikejiri@ntt.com
EMail: y.ikejiri@ntt.com
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA
美国加利福尼亚州埃尔塞贡多大道东2160号雷蒙德·张BT信息网，邮编90025
EMail: raymond_zhang@bt.infonet.com
EMail: raymond_zhang@bt.infonet.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。