Internet Engineering Task Force (IETF) M. Meyer, Ed.
Request for Comments: 5712 British Telecom
Category: Standards Track JP. Vasseur, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
January 2010
Internet Engineering Task Force (IETF) M. Meyer, Ed.
Request for Comments: 5712 British Telecom
Category: Standards Track JP. Vasseur, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
January 2010
MPLS Traffic Engineering Soft Preemption
MPLS流量工程软抢占
Abstract
摘要
This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities.
本文件规定了多协议标签交换（MPLS）流量工程软抢占，这是一套扩展抢占概念的协议修改，旨在减少或消除抢占流量工程标签交换路径（TE LSP）的流量中断。最初，MPLS RSVP-TE的定义仅支持抢占时立即TE LSP置换。利用重路由请求通知有助于更优雅地缓解抢占TE LSP的重路由过程。在激活软抢占的短时间内，保留（尽管不一定是流量级别）有效地处于供应不足状态，直到TE LSP可以被重新路由。出于这个原因，该功能主要（但不是唯一）对具有区分服务和流量工程功能的支持MPLS的IP网络感兴趣。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5712.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5712.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Acronyms and Abbreviations .................................3
2.2. Nomenclature ...............................................4
2.3. Requirements Language ......................................4
3. Motivations .....................................................4
4. RSVP Extensions .................................................5
4.1. SESSION-ATTRIBUTE Flags ....................................5
4.2. Path Error - "Reroute Request Soft Preemption"
Error Value ................................................5
5. Mode of Operation ...............................................6
6. Elements Of Procedures ..........................................7
6.1. On a Soft Preempting LSR ...................................7
6.2. On Head-end LSR of a Soft Preempted TE LSP .................9
7. Interoperability ...............................................10
8. Management .....................................................10
9. IANA Considerations ............................................11
9.1. New Session Attribute Object Flag .........................11
9.2. New Error Sub-Code Value ..................................11
10. Security Considerations .......................................11
11. Acknowledgements ..............................................12
12. Contributors ..................................................12
13. References ....................................................12
13.1. Normative References .....................................12
13.2. Informative References ...................................13
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Acronyms and Abbreviations .................................3
2.2. Nomenclature ...............................................4
2.3. Requirements Language ......................................4
3. Motivations .....................................................4
4. RSVP Extensions .................................................5
4.1. SESSION-ATTRIBUTE Flags ....................................5
4.2. Path Error - "Reroute Request Soft Preemption"
Error Value ................................................5
5. Mode of Operation ...............................................6
6. Elements Of Procedures ..........................................7
6.1. On a Soft Preempting LSR ...................................7
6.2. On Head-end LSR of a Soft Preempted TE LSP .................9
7. Interoperability ...............................................10
8. Management .....................................................10
9. IANA Considerations ............................................11
9.1. New Session Attribute Object Flag .........................11
9.2. New Error Sub-Code Value ..................................11
10. Security Considerations .......................................11
11. Acknowledgements ..............................................12
12. Contributors ..................................................12
13. References ....................................................12
13.1. Normative References .....................................12
13.2. Informative References ...................................13
In a Multiprotocol Label Switching (MPLS) Resource Reservation Protocol Traffic Engineering (RSVP-TE) (see [RFC3209]) enabled IP network, hard preemption is the default behavior. Hard preemption provides no mechanism to allow preempted Traffic Engineering Label Switched Paths (TE LSPs) to be handled in a make-before-break fashion: the hard preemption scheme instead utilizes a very intrusive method that can cause traffic disruption for a potentially large amount of TE LSPs. Without an alternative, network operators either accept this limitation, or remove functionality by using only one preemption priority or using invalid bandwidth reservation values. Understandably desirable features like TE reservation adjustments that are automated by the ingress Label Edge Router (LER) are less palatable when preemption is intrusive and maintaining high levels of network stability levels is a concern.
在支持多协议标签交换（MPLS）的资源预留协议流量工程（RSVP-TE）（请参阅[RFC3209]）的IP网络中，硬抢占是默认行为。硬抢占不提供任何机制来允许抢占的流量工程标签交换路径（TE LSP）以先通后断的方式进行处理：硬抢占方案使用了一种非常侵入性的方法，这种方法可能导致大量TE LSP的流量中断。在没有其他选择的情况下，网络运营商要么接受此限制，要么仅使用一个抢占优先级或使用无效的带宽保留值来删除功能。可以理解的是，当抢占具有侵入性时，入口标签边缘路由器（LER）自动进行的TE保留调整等理想功能不太受欢迎，并且需要保持高水平的网络稳定性。
This document defines the use of additional signaling and maintenance mechanisms to alert the ingress LER of the preemption that is pending and allow for temporary control-plane under-provisioning while the preempted tunnel is rerouted in a non-disruptive fashion (make-before-break) by the ingress LER. During the period that the tunnel is being rerouted, link capacity is under-provisioned on the midpoint where preemption initiated and potentially one or more links upstream along the path where other soft preemptions may have occurred.
本文件定义了使用额外的信令和维护机制来警告入口LER未决的抢占，并允许在入口LER以无中断方式（先通后断）重新路由抢占隧道时提供临时控制平面。在隧道被重新路由的期间，链路容量在抢占开始的中点和可能发生其他软抢占的路径上游的一个或多个链路上供应不足。
This document follows the nomenclature of the MPLS Architecture defined in [RFC3031].
本文件遵循[RFC3031]中定义的MPLS体系结构术语。
CSPF: Constrained Shortest Path First.
CSPF：约束最短路径优先。
DS: Differentiated Services.
DS：差异化服务。
LER: Label Edge Router.
标签边缘路由器。
LSR: Label Switching Router.
标签交换路由器。
LSP: Label Switched Path.
标签交换路径。
MPLS: MultiProtocol Label Switching.
MPLS：多协议标签交换。
RSVP: Resource ReSerVation Protocol.
资源预留协议。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：流量工程标签交换路径。
Point of Preemption - the midpoint or ingress LSR which due to RSVP provisioning levels is forced to either hard preempt or under-provision and signal soft preemption.
抢占点-由于RSVP配置级别，中点或入口LSR被强制为硬抢占或不足配置，并发出软抢占信号。
Hard Preemption - The (typically default) preemption process in which higher numeric priority TE LSPs are intrusively displaced at the point of preemption by lower numeric priority TE LSPs. In hard preemption, the TE LSP is torn down before reestablishment.
硬抢占-一种（通常为默认）抢占过程，其中较高数值优先级的TE LSP在抢占点被较低数值优先级的TE LSP侵入性替换。在硬抢占中，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]中所述进行解释。
Initially, MPLS RSVP-TE [RFC3209] was defined with support for only one method of TE LSP preemption, which immediately tears down TE LSPs, disregarding the preempted in-transit traffic. This simple but abrupt process nearly guarantees preempted traffic will be discarded, if only briefly, until the RSVP Path Error message reaches and is processed by the ingress LER and a new data path can be established. The Error Code and Error Values carried within the RSVP Path Error message to report a preemption action are documented in [RFC5711]. Note that such preemption is also referred to as a fatal error in [RFC5711]. In cases of actual resource contention this might be helpful; however, preemption may be triggered by mere reservation contention, and reservations may not reflect data-plane contention up to the moment. The result is that when conditions that promote preemption exist and hard preemption is the default behavior, inferior priority preempted traffic may be needlessly discarded when sufficient bandwidth exists for both the preempted TE LSP and the preempting TE LSP(s).
最初，定义MPLS RSVP-TE[RFC3209]时只支持一种TE LSP抢占方法，该方法会立即拆除TE LSP，而不考虑抢占的在途流量。这个简单但突然的过程几乎保证了抢占的通信量将被丢弃，即使只是短暂地丢弃，直到RSVP路径错误消息到达并由入口LER处理，并且可以建立新的数据路径。[RFC5711]中记录了RSVP路径错误消息中用于报告抢占操作的错误代码和错误值。注意，这种抢占在[RFC5711]中也被称为致命错误。在实际资源争用的情况下，这可能会有所帮助；然而，抢占可能仅仅由保留争用触发，并且保留到目前为止可能并不反映数据平面争用。结果是，当存在促进抢占的条件并且硬抢占是默认行为时，当抢占的TE-LSP和抢占的TE-LSP都有足够的带宽时，可能会不必要地丢弃低优先级抢占流量。
Hard preemption may be a requirement to protect numerically lower preemption priority traffic in a non-Diffserv-enabled architecture, but in a Diffserv-enabled-architecture, one need not rely exclusively upon preemption to enforce a preference for the most valued traffic since the marking and queuing disciplines should already be aligned for those purposes. Moreover, even in non-Diffserv-aware networks, depending on the TE LSP sizing rules (imagine all LSPs are sized at double their observed traffic level), reservation contention may not accurately reflect the potential for data-plane congestion.
硬抢占可能是在非Diffserv启用的体系结构中保护数字较低抢占优先级流量的要求，但在Diffserv启用的体系结构中，人们不必完全依靠抢占来实施对最有价值的流量的偏好，因为标记和排队规程已经针对这些目的进行了调整。此外，即使在非区分服务感知网络中，根据TE LSP大小调整规则（假设所有LSP的大小都是其观察到的流量水平的两倍），保留争用也可能无法准确反映数据平面拥塞的可能性。
To explicitly signal the desire for a TE LSP to benefit from the soft preemption mechanism (and thus not to be hard preempted if the soft preemption mechanism is available), the following flag of the SESSION-ATTRIBUTE object (for both the C-Type 1 and 7) is defined:
为了明确表示TE LSP希望从软抢占机制中获益（因此，如果软抢占机制可用，则不会硬抢占），定义了会话属性对象（对于C类型1和7）的以下标志：
Soft Preemption Desired bit
软抢占期望位
Bit Flag Name Flag 0x40 Soft Preemption Desired
需要位标志名称标志0x40软抢占
[RFC5710] specifies defines a new reroute-specific error code that allows a midpoint to report a TE LSP reroute request (Error Code=34 - Reroute). This document specifies a new Error Value sub-code for the case of soft preemption.
[RFC5710]指定定义新的特定于重路由的错误代码，该错误代码允许中点报告TE LSP重路由请求（错误代码=34-重路由）。本文档指定了软抢占情况下的新错误值子代码。
Error-value Meaning Reference 1 Reroute Request Soft Preemption This document
错误值表示参考1重新路由请求软抢占本文档
Upon (soft) preemption, the preempting node MUST issue a PathErr message with the Error Code=34 ("Reroute") and a value=1 ("Reroute Request Soft Preemption").
在（软）抢占时，抢占节点必须发出错误代码为34（“重路由”）且值为1（“重路由请求软抢占”）的PathErr消息。
Let's consider the following example:
让我们考虑下面的例子：
R0--1G--R1---155----R2
| \ |
| \ 155
| \ |
155 1G R3
| \ |
| \ 155
| \|
R4----1G----R5
R0--1G--R1---155----R2
| \ |
| \ 155
| \ |
155 1G R3
| \ |
| \ 155
| \|
R4----1G----R5
LSP1: LSP2:
LSP1:LSP2:
R0-->R1 R1<--R2
\ |
V V
R5 R4
R0-->R1 R1<--R2
\ |
V V
R5 R4
Figure 1: Example of Soft Preemption Operation
图1：软抢占操作示例
In the network depicted above in Figure 1, consider the following conditions:
在图1所示的网络中，考虑以下条件：
o Reservable BW on R0-R1, R1-R5, and R4-R5 is 1 Gbit/s.
o R0-R1、R1-R5和R4-R5上的可保留带宽为1 Gbit/s。
o Reservable BW on R1-R2, R1-R4, R2-R3, and R3-R5 is 155 Mbit/s.
o R1-R2、R1-R4、R2-R3和R3-R5上的可保留带宽为155 Mbit/s。
o Bandwidths and costs are identical in both directions.
o 带宽和成本在两个方向上都是相同的。
o Each circuit has an IGP metric of 10, and the IGP metric is used by CSPF.
o 每个电路的IGP度量为10，CSPF使用IGP度量。
o Two TE tunnels are defined:
o 定义了两个TE隧道：
* LSP1: 155 Mbit/s, setup/hold priority 0 tunnel, path R0-R1-R5.
* LSP1:155Mbit/s，设置/保持优先级0通道，路径R0-R1-R5。
* LSP2: 155 Mbit/s, setup/hold priority 7 tunnel, path R2-R1-R4.
* LSP2:155Mbit/s，设置/保持优先级7隧道，路径R2-R1-R4。
Both TE LSPs are signaled with the "Soft Preemption Desired" bit of their SESSION-ATTRIBUTE object set.
两个TE LSP都用其会话属性对象集的“所需软抢占”位发出信号。
o Circuit R1-R5 fails.
o 电路R1-R5出现故障。
o Soft Preemption is functional.
o 软抢占是功能性的。
When the circuit R1-R5 fails, R1 detects the failure and sends an updated IGP LSA/LSP and Path Error message to all the head-end LSRs that have a TE LSP traversing the failed link (R0 in the example above). Either form of notification may arrive at the head-end LSRs first. Upon receiving the link failure notification, R0 triggers a TE LSP reroute of LSP1, and re-signals LSP1 along shortest path available satisfying the TE LSP constraints: R0-R1-R4-R5 path. The Resv messages for LSP1 travel in the upstream direction (from the destination to the head-end LSR -- R5 to R0 in this example). LSP2 is soft preempted at R1 as it has a numerically lower priority value, and both bandwidth reservations cannot be satisfied on the R1-R4 link.
当电路R1-R5发生故障时，R1检测到故障，并向所有前端LSR发送更新的IGP LSA/LSP和路径错误消息，这些前端LSR具有穿过故障链路的TE LSP（上例中的R0）。任何一种形式的通知都可能首先到达前端LSR。在接收到链路故障通知后，R0触发LSP1的TE LSP重路由，并沿满足TE LSP约束的可用最短路径重新发送LSP1信号：R0-R1-R4-R5路径。LSP1的Resv消息沿上游方向移动（本例中从目的地到前端LSR--R5到R0）。LSP2在R1处被软抢占，因为它的优先级数值较低，并且在R1-R4链路上无法满足带宽预留。
Instead of sending a PathTear message for LSP2 upon preemption as with hard preemption (which would result in an immediate traffic disruption for LSP2), R1's local bandwidth accounting for LSP2 is zeroed, and a PathErr message with error code "Reroute" and a value "Reroute Request Soft Preemption" for LSP2 is issued.
与硬抢占（这将导致LSP2的即时通信中断）不同，在抢占时为LSP2发送Path催泪消息，R1占用LSP2的本地带宽为零，并为LSP2发出错误代码为“Reroute”且值为“Reroute Request Soft preemption”的PathErr消息。
Upon reception of the PathErr message for LSP2, R2 may update the working copy of the TE-DB before calculating a new path for the new LSP. In the case that Diffserv [RFC3270] and TE [RFC3209] are deployed, receiving a "preemption pending" notification may imply to a head-end LSR that the available bandwidth for the affected priority level and numerically greater priority levels has been exhausted for the indicated node interface. R2 may choose to reduce or zero the available bandwidth for the implied priority range until more accurate information is available (i.e., a new IGP TE update is received). It follows that R2 re-computes a new path and performs a non-traffic-disruptive rerouting of the new TE LSP T2 by means of the make-before-break procedure. The old path is then torn down.
在接收到LSP2的PathErr消息后，R2可以在计算新LSP的新路径之前更新TE-DB的工作副本。在部署Diffserv[RFC3270]和TE[RFC3209]的情况下，接收到“抢占未决”通知可能向前端LSR暗示，对于所指示的节点接口，受影响的优先级和数字上更高的优先级的可用带宽已经耗尽。R2可选择减少或归零隐含优先级范围的可用带宽，直到获得更准确的信息（即，收到新的IGP TE更新）。因此，R2通过先通后断过程重新计算新路径并执行新TE LSP T2的无流量中断重路由。这条老路随后被拆除。
When a new TE LSP is signaled that requires a set of TE LSP(s) to be preempted because not all TE LSPs can be accommodated on a specific interface, a node triggers a preemption action that consists of selecting the set of TE LSPs that must be preempted so as to free up some bandwidth in order to satisfy the newly signaled numerically lower preemption TE LSP.
当发出新的TE LSP信号，要求抢占一组TE LSP，因为并非所有TE LSP都可以容纳在特定接口上时，节点触发抢占动作，该抢占动作包括选择必须被抢占的TE-LSP集合，以便释放一些带宽以满足新发信号的数字较低的抢占TE-LSP。
With hard preemption, when a TE LSP is preempted, the preempting node sends an RSVP PathErr message that serves as notification of a fatal action as documented in [RFC5711]. Upon receiving the RSVP PathErr message, the head-end LSR sends an RSVP PathTear message, that would result in an immediate traffic disruption for the preempted TE LSP.
对于硬抢占，当TE LSP被抢占时，抢占节点发送一条RSVP PathErr消息，作为致命操作的通知，如[RFC5711]中所述。在接收到RSVP PathErr消息后，前端LSR发送一条RSVP PathTear消息，这将立即导致抢占的TE LSP的通信中断。
By contrast, the mode of operation with soft preemption is as follows: the preempting node's local bandwidth accounting for the preempted TE LSP is zeroed and a PathErr with error code "Reroute", and a error value "Reroute Request Soft Preemption" for that TE LSP is issued upstream toward the head-end LSR.
相比之下，具有软抢占的操作模式如下：抢占节点的用于抢占的TE-LSP的本地带宽被置零，并且具有错误代码“Reroute”的路径错误，并且针对该TE-LSP的错误值“Reroute Request soft preemption”向前端LSR向上游发出。
If more than one soft preempted TE LSP has the same head-end LSR, these soft preemption PathErr notification messages may be bundled together.
如果多个软抢占TE LSP具有相同的前端LSR，则这些软抢占PathErr通知消息可以捆绑在一起。
The preempting node MUST immediately send a PathErr with error code "Reroute" and a error value "Reroute Request Soft Preemption" for each soft preempted TE LSP. The node MAY use the occurrence of soft preemption to trigger an immediate IGP update or influence the scheduling of an IGP update.
对于每个软抢占的TE LSP，抢占节点必须立即发送带有错误代码“Reroute”和错误值“Reroute Request Soft Preemption”的PathErr。节点可以使用软抢占的发生来触发立即IGP更新或影响IGP更新的调度。
To guard against a situation where bandwidth under-provisioning will last forever, a local timer (named the "Soft preemption timer") MUST be started on the preemption node upon soft preemption. If this timer expires, the preempting node SHOULD send an RSVP PathTear and either a ResvTear message or a PathErr with the 'Path_State_Removed' flag set.
为了防止资源调配下的带宽将永远持续的情况，必须在软抢占时在抢占节点上启动本地计时器（称为“软抢占计时器”）。如果此计时器过期，抢占节点应发送RSVP PATHTRARE和ResvTear消息或设置了“Path\u State\u Removed”标志的PathErr。
Should a refresh event for a soft preempted TE LSP arrive before the soft preemption timer expires, the soft preempting node MUST continue to refresh the TE LSP.
如果软抢占TE LSP的刷新事件在软抢占计时器到期之前到达，则软抢占节点必须继续刷新TE LSP。
When the MESSAGE-ID extensions defined in [RFC2961] are available and enabled, PathErr messages with the error code "Reroute" and error value "Reroute Request Soft Preemption" SHOULD be sent in reliable mode.
当[RFC2961]中定义的消息ID扩展可用并启用时，应以可靠模式发送带有错误代码“Reroute”和错误值“Reroute Request Soft Preemption”的PathErr消息。
The preempting node MAY preempt TE LSPs that have a numerically higher Holding priority than the Setup priority of the newly admitted LSP. Within the same priority, first it SHOULD attempt to preempt LSPs with the "Soft Preemption Desired" bit of the SESSION ATTRIBUTE object cleared, i.e., the TE LSPs that are considered as Hard Preemptable.
抢占节点可以抢占持有优先级高于新接纳的LSP的设置优先级的TE LSP。在相同的优先级内，首先它应尝试在清除会话属性对象的“软抢占所需”位的情况下抢占LSP，即被视为硬抢占的TE LSP。
Selection of the preempted TE LSP at a preempting midpoint: when a numerically lower priority TE LSP is signaled that requires the preemption of a set of numerically higher priority LSPs, the node where preemption is to occur has to make a decision on the set of TE LSP(s) that are candidates for preemption. This decision is a local decision and various algorithms can be used, depending on the objective (e.g, see [RFC4829]). As already mentioned, soft preemption causes a temporary link under-provisioning condition while the soft preempted TE LSPs are rerouted by their respective head-end
在抢占中点选择抢占的TE-LSP：当发送信号通知数字低优先级TE-LSP需要抢占一组数字高优先级的TE-LSP时，将发生抢占的节点必须对作为抢占候选的TE-LSP集做出决定。该决策是一个局部决策，可根据目标使用各种算法（例如，参见[RFC4829]）。如前所述，软抢占导致在供应条件下的临时链路，而软抢占的TE lsp由其各自的头端重新路由
LSRs. In order to reduce this under-provisioning exposure, a soft preempting LSR MAY check first if there exists soft preemptable TE LSP bandwidth that is flagged by another node but still available for soft preemption locally. If sufficient overlap bandwidth exists, the LSR MAY attempt to soft preempt the same TE LSP. This would help reduce the temporarily elevated under-provisioning ratio on the links where soft preemption occurs and reduce the number of preempted TE LSPs. Optionally, a midpoint LSR upstream or downstream from a soft preempting node MAY choose to flag the TE LSPs in soft preempted state. In the event a local preemption is needed, the LSPs that are in the cache and of the relevant priority level are soft preempted first, followed by the normal soft and hard preemption selection process for the given priority.
LSR。为了减少这种供应不足的暴露，软抢占LSR可以首先检查是否存在由另一个节点标记但仍可用于本地软抢占的软抢占TE LSP带宽。如果存在足够的重叠带宽，LSR可以尝试软抢占相同的TE-LSP。这将有助于减少发生软抢占的链路上临时升高的资源调配不足率，并减少抢占的TE LSP的数量。可选地，来自软抢占节点的中点LSR上游或下游可以选择将TE lsp标记为软抢占状态。如果需要本地抢占，则首先软抢占缓存中具有相关优先级的LSP，然后针对给定优先级执行正常的软抢占和硬抢占选择过程。
Under specific circumstances such as unacceptable link congestion, a node MAY decide to hard preempt a TE LSP (by sending a fatal Path Error message, a PathTear, and either a ResvTear or a Path Error message with the 'Path_State_Removed' flag set) even if its head-end LSR explicitly requested soft preemption (by setting the "Soft Preemption Desired" flag of the corresponding SESSION-ATTRIBUTE object). Note that such a decision MAY also be made for TE LSPs under soft preemption state.
在诸如不可接受的链路拥塞等特定情况下，即使其前端LSR明确请求软抢占（通过设置对应会话属性对象的“需要软抢占”标志）。注意，在软抢占状态下，也可以为TE LSP做出这样的决定。
Upon reception of a PathErr message with error code "Reroute" and an error value "Reroute request soft preemption", the head-end LSR MAY first update the working copy of the TE-DB before computing a new path (e.g., by running CSPF) for the new LSP. In the case that Diffserv [RFC3270] and MPLS Traffic Engineering [RFC3209] are deployed, receiving "preemption pending" may imply to a head-end LSR that the available bandwidth for the affected priority level and numerically greater priority levels has been exhausted for the indicated node interface. A head-end LSR MAY choose to reduce or zero the available bandwidth for the implied priority range until more accurate information is available (i.e., a new IGP TE update is received).
在接收到错误代码为“Reroute”且错误值为“Reroute request soft preemption”的PathErr消息时，前端LSR可在为新LSP计算新路径（例如，通过运行CSPF）之前首先更新TE-DB的工作副本。在部署Diffserv[RFC3270]和MPLS流量工程[RFC3209]的情况下，接收“抢占未决”可能向前端LSR暗示，对于所指示的节点接口，受影响的优先级和数字上更高的优先级的可用带宽已经耗尽。前端LSR可以选择减少或归零隐含优先级范围的可用带宽，直到获得更准确的信息（即，接收到新的IGP TE更新）。
Once a new path has been computed, the soft preempted TE LSP is rerouted using the non-traffic-disruptive make-before-break procedure. The amount of time the head-end node avoids using the node interface identified by the IP address contained in the PathErr is based on a local decision at the head-end node.
一旦计算出新路径，软抢占的TE LSP将使用无流量中断先通后断过程重新路由。前端节点避免使用PathErr中包含的IP地址标识的节点接口的时间量基于前端节点的本地决定。
As a result of soft preemption, no traffic will be needlessly black-holed due to mere reservation contention. If loss is to occur, it will be due only to an actual traffic congestion scenario and according to the operator's Diffserv (if Diffserv is deployed) and queuing scheme.
作为软抢占的结果，不会因为仅仅是保留争用而造成不必要的流量黑洞。如果发生丢失，则仅是由于实际的交通拥堵情况，并根据运营商的Diffserv（如果部署了Diffserv）和排队方案。
Backward compatibility should be assured as long as the implementation followed the recommendations set forth in [RFC3209].
只要实现遵循[RFC3209]中提出的建议，就应确保向后兼容性。
As mentioned previously, to guard against a situation where bandwidth under-provisioning will last forever, a local timer (soft preemption timer) MUST be started on the preemption node upon soft preemption. When this timer expires, the soft preempted TE LSP SHOULD be hard preempted by sending a fatal Path Error message, a PathTear message, and either a ResvTear message or a PathErr message with the 'Path_State_Removed' flag set. This timer SHOULD be configurable, and a default value of 30 seconds is RECOMMENDED.
如前所述，为了防止资源调配下的带宽将永远持续的情况，必须在软抢占时在抢占节点上启动本地计时器（软抢占计时器）。当此计时器过期时，软抢占的TE LSP应通过发送致命路径错误消息、PathTear消息以及设置了“Path_State_Removed”标志的ResvTear消息或PathErr消息来硬抢占。此计时器应可配置，建议默认值为30秒。
It is RECOMMENDED that configuring the default preemption timer to 0 will cause the implementation to use hard-preemption.
建议将默认抢占计时器配置为0将导致实现使用硬抢占。
Soft preemption as defined in this document is designed for use in MPLS RSVP-TE enabled IP networks and may not functionally translate to some GMPLS technologies. As with backward compatibility, if a device does not recognize a flag, it should pass the subobject transparently.
本文档中定义的软抢占设计用于支持MPLS RSVP-TE的IP网络，在功能上可能不会转化为某些GMPLS技术。与向后兼容性一样，如果设备无法识别标志，则应透明地传递子对象。
Both the point of preemption and the ingress LER SHOULD provide some form of accounting internally and to the network operator interface with regard to which TE LSPs and how much capacity is under-provisioned due to soft preemption. Displays of under-provisioning are recommended for the following midpoint, ingress, and egress views:
抢占点和入口LER都应在内部和网络运营商接口上提供某种形式的计费，其中涉及哪个TE LSP以及由于软抢占而未充分配置多少容量。建议在以下中点、入口和出口视图中显示未充分配置：
o Sum of current bandwidth per preemption priority per local interface
o 每个本地接口每个抢占优先级的当前带宽之和
o Sum of current bandwidth total per local interface
o 每个本地接口的当前带宽总和
o Sum of current bandwidth per local router (ingress, egress, midpoint)
o 每个本地路由器的当前带宽总和（入口、出口、中点）
o List of current LSPs and bandwidth in PPend (preemption pending) status
o 处于PPend（抢占挂起）状态的当前LSP和带宽列表
o List of current sum bandwidth and session count in PPend status per observed Explicit Route Object (ERO) hops (ingress and egress views only).
o 每个观察到的显式路由对象（ERO）跳数的PPend状态下的当前总带宽和会话计数列表（仅限入口和出口视图）。
o Cumulative PPend events per observed ERO hop.
o 每个观察到的ERO跃点的累积PPend事件。
A new flag of the Session Attribute Object has been registered by IANA.
IANA已注册会话属性对象的新标志。
Soft Preemption Desired bit
软抢占期望位
Bit Flag Name Reference 0x40 Soft Preemption Desired This document
本文档所需的位标志名称参考0x40软抢占
[RFC5710] defines a new reroute-specific error code that allows a midpoint to report a TE LSP reroute request. This document specifies a new error sub-code value for the case of Soft Preemption.
[RFC5710]定义新的特定于重路由的错误代码，允许中点报告TE LSP重路由请求。本文档指定了软抢占情况下的新错误子代码值。
Error-value Meaning Reference 1 Reroute Request Soft Preemption This document
错误值表示参考1重新路由请求软抢占本文档
This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC3209] remain relevant. Further details about MPLS security considerations can be found in [SEC_FMWK].
本文档不会引入新的安全问题。与原始RSVP协议[RFC3209]相关的安全注意事项仍然相关。有关MPLS安全注意事项的更多详细信息，请参见[SEC_FMWK]。
As noted in Section 6.1, soft preemption may result in temporary link under provisioning condition while the soft preempted TE LSPs are rerouted by their respective head-end LSRs. Although this is a less serious condition than false hard preemption, and despite the mitigation procedures described in Section 6.1, network operators should be aware of the risk to their network in the case that the soft preemption processes are subverted, and should apply the relevant MPLS control plane security techniques to protect against attacks.
如第6.1节所述，软抢占可能导致在供应条件下的临时链路，而软抢占的TE LSP由其各自的头端LSR重新路由。尽管这种情况不如虚假硬抢占严重，且尽管有第6.1节所述的缓解程序，但网络运营商应意识到在软抢占过程被破坏的情况下对其网络的风险，并且应该应用相关的MPLS控制平面安全技术来防止攻击。
The authors would like to thank Carol Iturralde, Dave Cooper, Loa Andersson, Arthi Ayyangar, Ina Minei, George Swallow, Adrian Farrel, and Mustapha Aissaoui for their valuable comments.
作者要感谢Carol Iturralde、Dave Cooper、Loa Andersson、Arthi Ayangar、Ina Minei、George Swallow、Adrian Farrel和Mustapha Aissaoui的宝贵评论。
Denver Maddux Limelight Networks USA EMail: denver@nitrous.net
丹佛马杜克斯聚光灯网络美国电子邮件：denver@nitrous.net
Curtis Villamizar AVICI EMail:curtis@faster-light.net
Curtis Villamizar AVICI电子邮件：curtis@faster-light.net
Amir Birjandi Juniper Networks 2251 Corporate Park Dr., Ste. 100 Herndon, VA 20171 USA EMail: abirjandi@juniper.net
埃米尔·比扬迪·朱尼珀网络公司公园2251号。100弗吉尼亚州赫恩登20171美国电子邮件：abirjandi@juniper.net
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[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月。
[RFC5710] Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr Message Triggered MPLS and GMPLS LSP Reroutes", RFC 5710, January 2010.
[RFC5710]伯杰，L.，帕帕迪米特里奥，D.，和JP。Vasseur，“PathErr消息触发MPLS和GMPLS LSP重路由”，RFC 5710，2010年1月。
[RFC5711] Vasseur, JP., Swallow, G., and I. Minei, "Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages", RFC 5711, January 2010.
[RFC5711]Vasseur，JP.，Swallow，G.，和I.Minei，“发起和接收资源预留协议（RSVP）路径错误消息时的节点行为”，RFC 5711，2010年1月。
[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月。
[RFC3270] 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.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC4829] de Oliveira, J., Vasseur, JP., Chen, L., and C. Scoglio, "Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering", RFC 4829, April 2007.
[RFC4829]de Oliveira，J.，Vasseur，JP.，Chen，L.，和C.Scoglio，“MPLS流量工程的标签交换路径（LSP）抢占策略”，RFC 48292007年4月。
[SEC_FMWK] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, October 2009.
[SEC_FMWK]Fang，L.，Ed.，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2009年10月。
Authors' Addresses
作者地址
Matthew R. Meyer (editor) British Telecom
Matthew R.Meyer（编辑）英国电信
EMail: matthew.meyer@bt.com
EMail: matthew.meyer@bt.com
JP Vasseur (editor) Cisco Systems, Inc. 11, Rue Camille Desmoulins Issy Les Moulineaux, 92782 France
JP Vasseur（编辑）Cisco Systems，Inc.11，Camille Desmoulins Rue Issy Les Moulineaux，92782法国
EMail: jpv@cisco.com
EMail: jpv@cisco.com