Network Working Group J. Polk
Request for Comments: 4495 S. Dhesikan
Updates: 2205 Cisco Systems
Category: Standards Track May 2006
Network Working Group J. Polk
Request for Comments: 4495 S. Dhesikan
Updates: 2205 Cisco Systems
Category: Standards Track May 2006
A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
一种用于减少预留流带宽的资源预留协议（RSVP）扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations, or other forms of RSVP tunnels. This specification is an extension of RFC 2205.
本文档建议对资源预留协议（RSVPv1）进行扩展，以减少分配给现有预留的保证带宽。此机制可用于影响单个保留、聚合保留或其他形式的RSVP隧道。本规范是RFC 2205的扩展。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. Individual Reservation Reduction Scenario .......................4
3. RSVP Aggregation Overview .......................................6
3.1. RSVP Aggregation Reduction Scenario ........................8
4. Requirements for Reservation Reduction ..........................9
5. RSVP Bandwidth Reduction Solution ..............................10
5.1. Partial Preemption Error Code .............................11
5.2. Error Flow Descriptor .....................................11
5.3. Individual Reservation Flow Reduction .....................11
5.4. Aggregation Reduction of Individual Flows .................12
5.5. RSVP Flow Reduction Involving IPsec Tunnels ...............12
5.6. Reduction of Multiple Flows at Once .......................13
6. Backwards Compatibility ........................................13
7. Security Considerations ........................................14
8. IANA Considerations ............................................15
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................16
Appendix A. Walking through the Solution ..........................17
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. Individual Reservation Reduction Scenario .......................4
3. RSVP Aggregation Overview .......................................6
3.1. RSVP Aggregation Reduction Scenario ........................8
4. Requirements for Reservation Reduction ..........................9
5. RSVP Bandwidth Reduction Solution ..............................10
5.1. Partial Preemption Error Code .............................11
5.2. Error Flow Descriptor .....................................11
5.3. Individual Reservation Flow Reduction .....................11
5.4. Aggregation Reduction of Individual Flows .................12
5.5. RSVP Flow Reduction Involving IPsec Tunnels ...............12
5.6. Reduction of Multiple Flows at Once .......................13
6. Backwards Compatibility ........................................13
7. Security Considerations ........................................14
8. IANA Considerations ............................................15
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................16
Appendix A. Walking through the Solution ..........................17
This document proposes an extension to the Resource Reservation Protocol (RSVP) [1] to allow an existing reservation to be reduced in allocated bandwidth in lieu of tearing that reservation down when some of that reservation's bandwidth is needed for other purposes. Several examples exist in which this mechanism may be utilized.
本文件建议对资源预留协议（RSVP）[1]进行扩展，以允许在分配的带宽中减少现有预留，而不是在出于其他目的需要保留的部分带宽时取消该预留。有几个例子可以利用这种机制。
The bandwidth allotted to an individual reservation may be reduced due to a variety of reasons such as preemption, etc. In such cases, when the entire bandwidth allocated to a reservation is not required, the reservation need not be torn down. The solution described in this document allows endpoints to negotiate a new (lower) bandwidth that falls at or below the specified new bandwidth maximum allocated by the network. Using a voice session as an example, this indication in RSVP could lead endpoints, using another protocol such as Session Initiation Protocol (SIP) [9], to signal for a lower-bandwidth codec and retain the reservation.
由于抢占等多种原因，分配给单个预约的带宽可能会减少。在这种情况下，当不需要分配给预约的整个带宽时，不需要取消预约。本文档中描述的解决方案允许端点协商新的（较低的）带宽，该带宽等于或低于网络分配的指定新带宽最大值。以语音会话为例，RSVP中的此指示可能导致端点使用另一协议（如会话启动协议（SIP）[9]）向较低带宽编解码器发送信号并保留保留保留。
With RSVP aggregation [2], two aggregate flows with differing priority levels may traverse the same router interface. If that router interface reaches bandwidth capacity and is then asked to establish a new reservation or increase an existing reservation, the
使用RSVP聚合[2]，具有不同优先级的两个聚合流可以穿过同一路由器接口。如果路由器接口达到带宽容量，然后被要求建立新的预留或增加现有预留，则
router has to make a choice: deny the new request (because all resources have been utilized) or preempt an existing lower-priority reservation to make room for the new or expanded reservation.
路由器必须做出选择：拒绝新的请求（因为所有资源都已被利用）或抢占现有的低优先级预订，为新的或扩展的预订腾出空间。
If the flow being preempted is an aggregate of many individual flows, this has greater consequences. While [2] clearly does not terminate all the individual flows if an aggregate is torn down, this event will cause packets to be discarded during aggregate reservation reestablishment. This document describes a method where only the minimum required bandwidth is taken away from the lower-priority aggregated reservation and the entire reservation is not preempted. This has the advantage that only some of the microflows making up the aggregate are affected. Without this extension, all individual flows are affected and the deaggregator will have to attempt the reservation request with a reduced bandwidth.
如果被抢占的流是多个单独流的集合，则会产生更大的后果。虽然[2]显然不会在聚合被拆除时终止所有单个流，但此事件将导致在聚合保留重新建立期间丢弃数据包。本文档描述了一种方法，其中仅从较低优先级的聚合保留中移除所需的最小带宽，并且不抢占整个保留。这样做的好处是，只有构成骨料的一些微流受到影响。如果没有此扩展，所有单独的流都会受到影响，并且解聚集器将不得不在带宽减少的情况下尝试预订请求。
RSVP tunnels utilizing IPsec [8] also require an indication that the reservation must be reduced to a certain amount (or less). RSVP aggregation with IPsec tunnels is being defined in [11], which should be able to take advantage of the mechanism created here in this specification.
使用IPsec[8]的RSVP隧道还需要指示必须将保留减少到一定数量（或更少）。[11]中定义了带有IPsec隧道的RSVP聚合，它应该能够利用本规范中创建的机制。
Note that when this document refers to a router interface being "full" or "at capacity", this does not imply that all of the bandwidth has been used, but rather that all of the bandwidth available for reservation(s) via RSVP under the applicable policy has been used. Policies for real-time traffic routinely reserve capacity for routing and inelastic applications, and may distinguish between voice, video, and other real-time applications.
请注意，当本文件提及路由器接口为“满”或“满容量”时，这并不意味着所有带宽都已使用，而是意味着根据适用的策略，所有可通过RSVP进行预留的带宽都已使用。实时流量策略通常为路由和非弹性应用程序保留容量，并可能区分语音、视频和其他实时应用程序。
Explicit Congestion Notification (ECN) [10] is an indication that the transmitting endpoint must reduce its transmission. It does not provide sufficient indication to tell the endpoint by how much the reduction should be. Hence the application may have to attempt multiple times before it is able to drop its bandwidth utilization below the available limit. Therefore, while we consider ECN to be very useful for elastic applications, it is not sufficient for the purpose of inelastic application where an indication of bandwidth availability is useful for codec selection.
显式拥塞通知（ECN）[10]表示传输端点必须减少其传输。它没有提供足够的指示来告诉终点应该减少多少。因此，应用程序可能需要多次尝试才能将其带宽利用率降至可用限制以下。因此，虽然我们认为ECN对弹性应用非常有用，但对于非弹性应用而言，带宽可用性的指示对于编解码器选择是有用的，这是不够的。
Section 2 discusses the individual reservation flow problem, while Section 3 discusses the aggregate reservation flow problem space. Section 4 lists the requirements for this extension. Section 5 details the protocol changes necessary in RSVP to create a reservation reduction indication. And finally, the appendix provides a walk-through example of how this extension modifies RSVP functionality in an aggregate scenario.
第2节讨论单个预订流问题，而第3节讨论聚合预订流问题。第4节列出了此扩展的要求。第5节详细说明了RSVP中创建预订减少指示所需的协议更改。最后，附录提供了一个演练示例，说明此扩展如何在聚合场景中修改RSVP功能。
This document updates RFC 2205 [1], as this mechanism affects the behaviors of the ResvErr and ResvTear indications defined in that document.
本文件更新了RFC 2205[1]，因为该机制会影响该文件中定义的ResvErr和ResvTear指示的行为。
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 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[4]中所述进行解释。
Figure 1 is a network topology that is used to describe the benefit of bandwidth reduction in an individual reservation.
图1是一个网络拓扑，用于描述单个预订中带宽减少的好处。
+------------+ +------------+
| |Int 1 | |Int 7 | |
Flow 1===> | +----- | |------+ | Flow 1===>
| R1 |Int 2 |===========>|Int 8 | R2 |
| | |:::::::::::>| | |
Flow 2:::> | +----- | |------+ | Flow 2:::>
| |Int 3 | |Int 9 | |
+------------+ +------------+
+------------+ +------------+
| |Int 1 | |Int 7 | |
Flow 1===> | +----- | |------+ | Flow 1===>
| R1 |Int 2 |===========>|Int 8 | R2 |
| | |:::::::::::>| | |
Flow 2:::> | +----- | |------+ | Flow 2:::>
| |Int 3 | |Int 9 | |
+------------+ +------------+
Figure 1. Simple Reservation Flows
图1。简单预订流
Legend/Rules:
图例/规则：
- Flow 1 priority = 300 - Flow 2 priority = 100 - Both flows are shown in the same direction (left to right). Corresponding flows in the reverse direction are not shown for diagram simplicity
- 流量1优先级=300-流量2优先级=100-两个流量显示在同一方向（从左到右）。为简化图表，未显示反向的相应流
RSVP is a reservation establishment protocol in one direction only. This split-path philosophy is because the routed path from one device to the other in one direction might not be the routed path for communicating between the same two endpoints in the reverse direction. End-systems must request 2 one-way reservations if that is what is needed for a particular application (like voice calls). Please refer to [1] for the details on how this functions. This example only describes the reservation scenario in one direction for simplicity's sake.
RSVP是仅在一个方向上的预约建立协议。这种分割路径原理是因为在一个方向上从一个设备到另一个设备的路由路径可能不是反向相同两个端点之间通信的路由路径。如果特定应用（如语音呼叫）需要2个单向预订，则终端系统必须请求2个单向预订。有关此功能的详细信息，请参阅[1]。为了简单起见，本例仅从一个方向描述了预订场景。
Figure 1 depicts 2 routers (R1 and R2) initially with only one flow (Flow 1). The flows are forwarded from R1 to R2 via Int 2. For this example, let us say that Flow 1 and Flow 2 each require 80 units of bandwidth (such as for the codec G.711 with no silence suppression).
图1描述了最初只有一个流（流1）的两个路由器（R1和R2）。流通过Int 2从R1转发到R2。对于这个示例，让我们假设流1和流2各自需要80个带宽单位（例如对于没有静音抑制的编解码器G.711）。
Let us also say that the RSVP bandwidth limit for Int 2 of R1 is 100 units.
我们也可以说R1的Int 2的RSVP带宽限制是100个单位。
As described in [3], a priority indication is established for each flow. In fact, there are two priority indications:
如[3]所述，为每个流建立优先级指示。事实上，有两个优先指示：
1) one to establish the reservation, and
1) 一个用于建立保留，以及
2) one to defend the reservation.
2) 一个是为保留辩护。
In this example, Flow 1 and Flow 2 have an 'establishing' and a 'defending' priority of 300 and 100, respectively. Flow 2 will have a higher establishing priority than Flow 1 has for its defending priority. This means that when Flow 2 is signaled, and if no bandwidth is available at the interface, Flow 1 will have to relinquish bandwidth in favor of the higher-priority request of Flow 2. The priorities assigned to a reservation are always end-to-end, and not altered by any routers in transit.
在此示例中，流1和流2的“建立”和“防御”优先级分别为300和100。流2的建立优先级高于流1的防御优先级。这意味着，当向流2发送信号时，如果接口处没有可用带宽，流1将不得不放弃带宽，以支持流2的更高优先级请求。分配给预订的优先级始终是端到端的，并且不会被传输中的任何路由器更改。
Without the benefit of this specification, Flow 1 will be preempted. This specification makes it possible for the ResvErr message to indicate that 20 units are still available for a reservation to remain up (the interface's 100 units maximum minus Flow 2's 80 units). The reservation initiating node (router or end-system) for Flow 1 has the opportunity to renegotiate (via call signaling) for acceptable parameters within the existing and available bandwidth for the flow (for example, it may decide to change to using a codec such as G.729)
如果没有本规范的好处，流1将被抢占。此规范使得ResvErr消息可以指示20个单元仍可用于保留，以保持保留（接口的最大100个单元减去流2的80个单元）。流1的预约发起节点（路由器或终端系统）有机会（通过呼叫信令）在流的现有和可用带宽内重新协商可接受的参数（例如，它可能决定改为使用编解码器，例如G.729）
The problems avoided with the partial failure of the flow are:
流量部分故障可避免的问题有：
- Reduced packet loss, which results as Flow 1 attempts to reestablish the reservation for a lower bandwidth.
- 减少了数据包丢失，这导致流1尝试重新建立较低带宽的保留。
- Inefficiency caused by multiple attempts until Flow 1 is able to request bandwidth equal to or lower than what is available. If Flow 1 is established with much less than what is available then it leads to inefficient use of available bandwidth.
- 多次尝试导致的低效，直到流1能够请求等于或低于可用带宽的带宽。如果流1的可用带宽远小于可用带宽，则会导致可用带宽的低效使用。
The following network overview is to help visualize the concerns that this specification addresses in RSVP aggregates. Figure 2 consists of 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9, A, B, C, D, and E). Initially, there will be 5 flows per aggregate (Flow 9 will be introduced to cause the problem we are addressing in this document), with 2 aggregates (X and Y); Flows 1 through 5 in aggregate X and Flows A through E in aggregate Y. These 2 aggregates will cross one router interface utilizing all available capacity (in this example).
以下网络概述有助于将本规范在RSVP聚合中解决的问题可视化。图2由10个路由器（方框）和11个流（1、2、3、4、5、9、A、B、C、D和E）组成。最初，每个聚合将有5个流（将引入流9以导致我们在本文档中解决的问题），其中有2个聚合（X和Y）；聚合X中的流1到5，聚合Y中的流A到E。这两个聚合将利用所有可用容量（在本例中）跨越一个路由器接口。
RSVP aggregation (per [2]) is no different from an individual reservation with respect to being unidirectional.
就单向性而言，RSVP聚合（per[2]）与单个预订没有区别。
Aggregator of X Deaggregator of X
| |
V V
+------+ +------+ +------+ +------+
Flow 1-->| | | | | | | |-->Flow 1
Flow 2-->| | | | | | | |-->Flow 2
Flow 3-->| |==>| | | |==>| |-->Flow 3
Flow 4-->| | ^ | | | | ^ | |-->Flow 4
Flow 5-->| | | | | | | | | |-->Flow 5
Flow 9 | R1 | | | R2 | | R3 | | | R4 | Flow 9
+------+ | +------+ +------+ | +------+
| || || |
Aggregate X-->|| Aggregate X ||<--Aggregate X
|| | ||
+--------------+ | +--------------+
| |Int 7 | | |Int 1 | |
| +----- | V |------+ |
| R10 |Int 8 |===========>|Int 2 | R11 |
| | |:::::::::::>| | |
| +----- | ^ |------+ |
| |Int 9 | | |Int 3 | |
+--------------+ | +--------------+
.. | ..
Aggregate Y--->.. Aggregate Y ..<---Aggregate Y
| .. .. |
+------+ | +------+ +------+ | +------+
Flow A-->| | | | | | | | | |-->Flow A
Flow B-->| | V | | | | V | |-->Flow B
Flow C-->| |::>| | | |::>| |-->Flow C
Flow D-->| | | | | | | |-->Flow D
Flow E-->| R5 | | R6 | | R7 | | R8 |-->Flow E
+------+ +------+ +------+ +------+
^ ^
| |
Aggregator of Y Deaggregator of Y
Aggregator of X Deaggregator of X
| |
V V
+------+ +------+ +------+ +------+
Flow 1-->| | | | | | | |-->Flow 1
Flow 2-->| | | | | | | |-->Flow 2
Flow 3-->| |==>| | | |==>| |-->Flow 3
Flow 4-->| | ^ | | | | ^ | |-->Flow 4
Flow 5-->| | | | | | | | | |-->Flow 5
Flow 9 | R1 | | | R2 | | R3 | | | R4 | Flow 9
+------+ | +------+ +------+ | +------+
| || || |
Aggregate X-->|| Aggregate X ||<--Aggregate X
|| | ||
+--------------+ | +--------------+
| |Int 7 | | |Int 1 | |
| +----- | V |------+ |
| R10 |Int 8 |===========>|Int 2 | R11 |
| | |:::::::::::>| | |
| +----- | ^ |------+ |
| |Int 9 | | |Int 3 | |
+--------------+ | +--------------+
.. | ..
Aggregate Y--->.. Aggregate Y ..<---Aggregate Y
| .. .. |
+------+ | +------+ +------+ | +------+
Flow A-->| | | | | | | | | |-->Flow A
Flow B-->| | V | | | | V | |-->Flow B
Flow C-->| |::>| | | |::>| |-->Flow C
Flow D-->| | | | | | | |-->Flow D
Flow E-->| R5 | | R6 | | R7 | | R8 |-->Flow E
+------+ +------+ +------+ +------+
^ ^
| |
Aggregator of Y Deaggregator of Y
Figure 2. Generic RSVP Aggregate Topology
图2。通用RSVP聚合拓扑
Legend/Rules:
图例/规则：
- Aggregate X priority = 100 - Aggregate Y priority = 200 - All boxes are routers - Both aggregates are shown in the same direction (left to right). Corresponding aggregates in the reverse direction are not shown for diagram simplicity.
- 聚合X优先级=100-聚合Y优先级=200-所有框都是路由器-两个聚合显示在同一方向（从左到右）。为简化图表，未显示反向的相应聚合。
The path for aggregate X is:
聚合X的路径为：
R1 => R2 => R10 => R11 => R3 => R4
R1 => R2 => R10 => R11 => R3 => R4
where aggregate X starts in R1, and deaggregates in R4.
其中，聚合X在R1中开始，在R4中取消聚合。
Flows 1, 2, 3, 4, 5, and 9 communicate through aggregate A.
流1、2、3、4、5和9通过聚合A进行通信。
The path for aggregate Y is:
聚合Y的路径为：
R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
where aggregate Y starts in R5, and deaggregates in R8.
其中，聚合Y在R5中开始，在R8中取消聚合。
Flows A, B, C, D, and E communicate through aggregate B.
流A、B、C、D和E通过聚合B进行通信。
Both aggregates share one leg or physical link: between R10 and R11, thus they share one outbound interface: Int 8 of R10, where contention of resources may exist. That link has an RSVP capacity of 800 kbps. RSVP signaling (messages) is outside the 800 kbps in this example, as is any session signaling protocol like SIP.
两个聚合共享一个分支或物理链路：R10和R11之间，因此它们共享一个出站接口：R10的Int 8，其中可能存在资源争用。该链路的RSVP容量为800 kbps。在本例中，RSVP信令（消息）在800 kbps之外，任何会话信令协议（如SIP）也是如此。
Figure 2 shows an established aggregated reservation (aggregate X) between the routers R1 and R4. This aggregated reservation consists of 5 microflows (Flows 1, 2, 3, 4, and 5). For the sake of this discussion, let us assume that each flow represents a voice call and requires 80 kb (such as for the codec G.711 with no silence suppression). Aggregate X request is for 400 kbps (80 kbps * 5 flows). The priority of the aggregate is derived from the individual microflows that it is made up of. In the simple case, all flows of a single priority are bundled as a single aggregate (another priority level would be in another aggregate, even if traversing the same path through the network). There may be other ways in which the priority of the aggregate is derived, but for this discussion it is sufficient to note that each aggregate contains a priority (both hold and defending priority). The means of deriving the priority is out of scope for this discussion.
图2显示了路由器R1和R4之间建立的聚合保留（聚合X）。此聚合保留由5个微流（流1、2、3、4和5）组成。为了便于讨论，让我们假设每个流代表一个语音呼叫，需要80KB（例如对于没有静音抑制的编解码器G.711）。聚合X请求用于400 kbps（80 kbps*5个流）。聚合的优先级源自其组成的单个微流。在简单的情况下，单个优先级的所有流都捆绑为单个聚合（另一个优先级将位于另一个聚合中，即使在网络中通过相同的路径）。可以通过其他方式导出聚合的优先级，但在本讨论中，注意每个聚合都包含一个优先级（保留优先级和保护优先级）。得出优先权的方法超出了本次讨论的范围。
Aggregate Y, in Figure 2, consists of Flows A, B, C, D, and E and requires 400 kbps (80 kbps * 5 flows), and starts at R5 and ends R8. This means there are two aggregates occupying all 800 kbps of the RSVP capacity.
图2中的聚合Y由流A、B、C、D和E组成，需要400 kbps（80 kbps*5个流），从R5开始，到R8结束。这意味着有两个聚合占据了所有800 kbps的RSVP容量。
When Flow 9 is added into aggregate X, this will occupy 80 kbps more than Int 8 on R10 has available (880k offered load vs. 800k capacity) [1] and [2] create a behavior in RSVP to deny the entire aggregate Y
当将流9添加到聚合X中时，这将比R10上的Int 8的可用容量多占用80 kbps（880k提供的负载与800k容量）[1]和[2]在RSVP中创建一个行为来拒绝整个聚合Y
and all its individual flows because aggregate X has a higher priority. This situation is where this document focuses its requirements and calls for a solution. There should be some means to signal to all affected routers of aggregate Y that only 80 kbps is needed to accommodate another (higher priority) aggregate. A solution that accomplishes this reduction instead of a failure could:
和所有单独的流，因为聚合X具有更高的优先级。在这种情况下，本文档重点关注其需求并要求解决方案。应该有一些方法向聚合Y的所有受影响路由器发出信号，即只需要80 kbps来容纳另一个（更高优先级）聚合。实现这一减少而不是失败的解决方案可以：
- reduce significant packet loss of all flows within aggregate Y
- 减少聚合Y中所有流的显著数据包丢失
During the re-reservation request period of time no packets will traverse the aggregate until it is reestablished.
在重新保留请求的时间段内，在重新建立之前，不会有数据包穿过聚合。
- reduces the chances that the reestablishment of the aggregate will reserve an inefficient amount of bandwidth, causing the likely preemption of more individual flows at the aggregator than would be necessary had the aggregator had more information (that RSVP does not provide at this time)
- 减少重新建立聚合将保留低效带宽的可能性，从而导致聚合器中可能抢占的单个流比聚合器拥有更多信息（RSVP目前未提供）所需的更多
During reestablishment of the aggregation in Figure 2 (without any modification to RSVP), R8 would guess at how much bandwidth to ask for in the new RESV message. It could request too much bandwidth, and have to wait for the error that not that much bandwidth was available; it could request too little bandwidth and have that aggregation accepted, but this would mean that more individual flows would need to be preempted outside the aggregate than were necessary, leading to inefficiencies in the opposite direction.
在图2中重新建立聚合的过程中（没有对RSVP进行任何修改），R8将猜测在新的RESV消息中需要多少带宽。它可能会请求太多的带宽，并且必须等待没有那么多带宽可用的错误；它可能会要求太少的带宽并接受聚合，但这将意味着需要在聚合之外抢占比需要更多的单个流，从而导致相反方向的低效率。
The following are the requirements to reduce the bandwidth of a reservation. This applies to both individual and aggregate reservations:
以下是减少预订带宽的要求。这适用于个人和合计预订：
Req#1 - MUST have the ability to differentiate one reservation from another. In the case of aggregates, it MUST distinguish one aggregate from other flows.
要求#1-必须能够区分不同的预订。对于骨料，必须将一种骨料与其他流量区分开来。
Req#2 - MUST have the ability to indicate within an RSVP error message (generated at the router with the congested interface) that a specific reservation (individual or aggregate) is to be reduced in bandwidth.
Req#2-必须能够在RSVP错误消息（在拥挤接口的路由器上生成）中指示特定保留（单个或聚合）将减少带宽。
Req#3 - MUST have the ability to indicate within the same error message the new maximum amount of bandwidth that is available to be utilized within the existing reservation, but no more.
Req#3-必须能够在同一错误消息中指示现有保留中可用的新最大带宽量，但不能超过。
Req#4 - MUST NOT produce a case in which retransmitted reduction indications further reduce the bandwidth of a reservation. Any additional reduction in bandwidth for a specified reservation MUST be signaled in a new message.
Req#4-不得产生重传减少指示进一步减少保留带宽的情况。指定保留的带宽的任何额外减少必须在新消息中发出信号。
RSVP messages are unreliable and can get lost. This specification should not compound any error in the network. If a reduction message were lost, another one needs to be sent. If the receiver ends up receiving two copies to reduce the bandwidth of a reservation by some amount, it is likely the router will reduce the bandwidth by twice the amount that was actually called for. This will be in error.
RSVP消息不可靠，可能会丢失。本规范不应加剧网络中的任何错误。如果减少消息丢失，则需要发送另一条消息。如果接收者最终接收到两个副本，从而将保留的带宽减少了一部分，那么路由器很可能会将带宽减少两倍于实际需要的带宽。这将是错误的。
When a reservation is partially failed, a ResvErr (Reservation Error) message is generated just as it is done currently with preemptions. The ERROR_SPEC object and the PREEMPTION_PRI object are included as well. Very few additions/changes are needed to the ResvErr message to support partial preemptions. A new error subcode is required and is defined in Section 5.1. The ERROR_SPEC object contained in the ResvErr message indicates the flowspec that is reserved. The bandwidth indication in this flowspec SHOULD be less than the original reservation request. This is defined in Section 5.2.
当保留部分失败时，将生成一条ResvErr（reservation Error）消息，与当前使用抢占时一样。还包括ERROR_SPEC对象和PREEMPTION_PRI对象。只需对ResvErr消息进行很少的添加/更改即可支持部分抢占。需要一个新的错误子代码，并在第5.1节中定义。ResvErr消息中包含的ERROR_SPEC对象表示保留的流程规范。此flowspec中的带宽指示应小于原始预订请求。第5.2节对此进行了定义。
A comment about RESV messages that do not use reliable transport: This document RECOMMENDS that ResvErr messages be made reliable by implementing mechanisms in [6].
关于不使用可靠传输的RESV消息的评论：本文档建议通过实现[6]中的机制使ResvErr消息可靠。
The current behavior in RSVP requires a ResvTear message to be transmitted upstream when the ResvErr message is transmitted downstream (per [1]). This ResvTear message terminates the reservation in all routers upstream of the router where the failure occurred. This document requires that the ResvTear is only generated when the reservation is to be completely removed. In cases where the reservation is only to be reduced, routers compliant with this specification require that the ResvTear message MUST NOT be sent.
RSVP中的当前行为要求在ResvErr消息向下游传输时向上游传输ResvTear消息（根据[1]）。此ResvTear消息终止发生故障的路由器上游所有路由器中的保留。本文档要求仅在完全删除保留时生成ResvTear。在仅减少保留的情况下，符合此规范的路由器要求不得发送ResvTear消息。
The appendix has been written to walk through the overall solution to the problems presented in Sections 2 and 3. There is mention of this ResvTear transmission behavior in the appendix.
编写本附录是为了全面了解第2节和第3节中提出的问题的解决方案。附录中提到了这种ResvTear传输行为。
The ResvErr message generated due to preemption includes the ERROR_SPEC object as well as the PREEMPTION_PRI object. The format of ERROR_SPEC objects is defined in [1]. The error code listed in the ERROR_SPEC object for preemption [5] currently is as follows:
由于抢占而生成的ResvErr消息包括ERROR\u SPEC对象以及抢占\u PRI对象。错误规格对象的格式在[1]中定义。当前，抢占[5]的错误规范对象中列出的错误代码如下：
Errcode = 2 (Policy Control Failure) and ErrSubCode = 5 (ERR_PREEMPT)
Errcode=2（策略控制失败）和ErrSubCode=5（ERR_抢占）
The following error code is suggested in the ERROR_SPEC object for partial preemption:
对于部分抢占，建议在error_SPEC对象中使用以下错误代码：
Errcode = 2 (Policy Control Failure) and ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)
Errcode=2（策略控制失败）和ErrSubCode=102（ERR\u PARTIAL\u PREEMPT）
There is also an error code in the PREEMPTION-PRI object. This error code takes a value of 1 to indicate that the admitted flow was preempted [3]. The same error value of 1 may be used for the partial preemption case as well.
PREEMPTION-PRI对象中还有一个错误代码。此错误代码的值为1，表示允许的流被抢占[3]。同样的错误值1也可用于部分抢占情况。
The error flow descriptor is defined in [1] and [7]. In the case of partial failure, the flowspec contained in the error flow descriptor indicates the highest average and peak rates that the preempting system can accept in the next RESV message. The deaggregator must reduce its reservation to a number less than or equal to that, whether by changing codecs, dropping reservations, or some other mechanism.
错误流描述符在[1]和[7]中定义。在部分故障的情况下，错误流描述符中包含的flowspec指示抢占系统在下一条RESV消息中可以接受的最高平均速率和峰值速率。解聚集器必须将其保留减少到小于或等于该值的数量，无论是通过更改编解码器、删除保留还是其他机制。
When a router requires part of the bandwidth that has been allocated to a reservation be used for another flow, the router engages in the partial reduction of bandwidth as described in this document. The router sends a ResvErr downstream to indicate the partial error with the error code and subcode as described in section 5.1. The flowspec contained in the ResvErr message will be used to indicate the bandwidth that is currently allocated.
当路由器要求将分配给预留的部分带宽用于另一个流时，路由器将按照本文档中的说明部分减少带宽。路由器向下游发送一个ResvErr，用错误代码和子代码指示部分错误，如第5.1节所述。ResvErr消息中包含的flowspec将用于指示当前分配的带宽。
The requesting endpoint that receives the ResvErr can then negotiate with the transmitting endpoint to lower the bandwidth requirement (by selecting another lower bandwidth codec, for example). After the negotiations, both endpoints will issue the RSVP PATH and RESV message with the new, lowered bandwidth.
然后，接收ResvErr的请求端点可以与发送端点协商以降低带宽需求（例如，通过选择另一个较低带宽的编解码器）。协商之后，两个端点都将发出具有新的、较低带宽的RSVP路径和RESV消息。
When a partial failure occurs in an aggregation scenario, the deaggregator receives the ResvErr message with the reduction indication from a router in the path of the aggregate. It then decides whether one or more individual flows from the aggregate are to be affected by this ResvErr message. The following choices are possible:
当聚合场景中发生部分故障时，解聚合器从聚合路径中的路由器接收带有缩减指示的ResvErr消息。然后，它决定来自聚合的一个或多个单独流是否受此ResvErr消息的影响。以下选项是可能的：
o If that (deaggregator) router determines that one or more individual flow(s) are to partially failed, then it sends a ResvErr message with a reduced bandwidth indication to those individual flow(s). This is as per the descriptions in the previous section (5.3).
o 如果该（解聚集器）路由器确定一个或多个单独的流将部分失败，那么它将向这些单独的流发送带有带宽减少指示的ResvErr消息。这与前一节（5.3）中的描述一致。
o If that (deaggregator) router determines that one individual flow is to be preempted to satisfy the aggregate ResvErr, it determines which flow is affected. That router transmits a new ResvErr message downstream per [3]. That same router transmits a ResvTear message upstream. This ResvTear message of an individual flow does not tear down the aggregate. Only the individual flow is affected.
o 如果该（解聚集器）路由器确定一个单独的流将被抢占以满足聚合ResvErr，它将确定哪个流受到影响。该路由器根据[3]向下游传输新的ResvErr消息。同一路由器向上游传输ResvTear消息。单个流的此ResvTear消息不会破坏聚合。只有单个流受到影响。
o If that (deaggregator) router determines that multiple individual flows are to be preempted to satisfy the aggregate ResvErr, it chooses which flows are affected. That router transmits a new ResvErr message downstream as per [3] to each individual flow. The router also transmits ResvTear messages upstream for the same individual flows. These ResvTear messages of an individual flow do not tear down the aggregate. Only the individual flows are affected.
o 如果该（解聚集器）路由器确定要抢占多个单独的流以满足聚合重新覆盖，它将选择受影响的流。该路由器根据[3]向每个单独的流下游发送一条新的ResvErr消息。路由器还为相同的单个流向上游传输ResvTear消息。单个流的这些ResvTear消息不会破坏聚合。只有个别流量受到影响。
In all cases, the deaggregator lowers the bandwidth requested in the Aggregate Resv message to reflect the change.
在所有情况下，解聚集器都会降低聚合Resv消息中请求的带宽，以反映更改。
Which particular flow or series of flows within an aggregate are picked by the deaggregator for bandwidth reduction or preemption is outside the scope of this document.
解聚集器为带宽减少或抢占选择聚合中的哪个特定流或一系列流超出了本文档的范围。
RFC 2207 (per [8]) specifies how RSVP reservations function in IPsec data flows. The nodes initiating the IPsec flow can be an end-system like a computer, or it can router between two end-systems, or it can be an in-line bulk encryption device immediately adjacent to a router interface; [11] directly addresses this later scenario.
RFC 2207（per[8]）指定了RSVP保留在IPsec数据流中的作用。发起IPsec流的节点可以是像计算机一样的终端系统，或者可以是两个终端系统之间的路由器，或者可以是紧邻路由器接口的在线批量加密设备；[11] 直接解决后一种情况。
The methods of identification of an IPsec with reservation flow are different from non-encrypted flows, but how the reduction mechanism specified within this document functions is not.
使用保留流标识IPsec的方法不同于非加密流，但本文档中指定的缩减机制的工作方式并不相同。
An IPsec with reservation flow is, for all intents and purposes, considered an individual flow with regard to how to reduce the bandwidth of the flow. Obviously, an IPsec with reservation flow can be a series of individual flows or disjointed best-effort packets between two systems. But to this specification, this tunnel is an individual RSVP reservation.
就如何减少流的带宽而言，带保留流的IPsec被视为一个单独的流。显然，带有保留流的IPsec可以是一系列单独的流，也可以是两个系统之间不相连的尽力而为数据包。但根据本规范，该隧道为单独的RSVP保留区。
Anywhere within this specification that mentions an individual reservation flow, the same rules of bandwidth reduction and preemption MUST apply.
在本规范中提及单个预订流的任何地方，必须应用相同的带宽减少和抢占规则。
As a cautionary note, bandwidth SHOULD NOT be reduced across multiple reservations at the same time, in reaction to the same reduction event. A router not knowing the impact of reservation bandwidth reduction on more than one flow may cause more widespread ill effects than is necessary.
作为警告，带宽不应同时跨多个预订减少，以响应相同的减少事件。路由器不知道保留带宽减少对多个流的影响可能会造成比必要的更广泛的不良影响。
This says nothing to a policy where preemption should or should not occur across multiple flows.
这对于在多个流中应该或不应该发生抢占的策略来说毫无意义。
Backwards compatibility with this extension will result in RSVP operating as it does without this extension, and no worse. The two routers involved in this extension are the router that had the congested interface and the furthest downstream router that determines what to do with the reduction indication.
与此扩展的向后兼容性将导致RSVP像没有此扩展时一样运行，并且不会更糟。此扩展中涉及的两个路由器是具有拥塞接口的路由器和确定如何处理减少指示的最远下游路由器。
In the case of the router that experiences congestion or otherwise needs to reduce the bandwidth of an existing reservation:
对于遇到拥塞或需要减少现有预留带宽的路由器：
- If that router supports this extension:
- 如果该路由器支持此扩展：
#1 - it generates the ResvErr message with the error code indicating the reduction in bandwidth.
#1-它生成ResvErr消息，错误代码指示带宽减少。
#2 - it does not generate the ResvTear message.
#2-它不会生成ResvTear消息。
- If that router does not support this extension, it generates both ResvErr and ResvTear messages according to [1].
- 如果该路由器不支持此扩展，它将根据[1]生成ResvErr和ResvTear消息。
In the case of the router at the extreme downstream of a reservation that receives the ResvErr message with the reduction indication:
如果路由器位于保留的最下游，接收带有减少指示的ResvErr消息：
- If that router does support this extension:
- 如果该路由器支持此扩展：
#1 - it processes this error message and applies whatever local policy it is configured to do to determine how to reduce the bandwidth of this designated flow.
#1-它处理此错误消息，并应用其配置为执行的任何本地策略，以确定如何减少此指定流的带宽。
- If the router does not support this extension:
- 如果路由器不支持此扩展：
#1 - it processes the ResvErr message according to [1] and all extensions it is able to understand, but not this extension from this document.
#1-它根据[1]和它能够理解的所有扩展来处理ResvErr消息，但不是本文档中的此扩展。
Thus, this extension does not cause ill effects within RSVP if one or more routers support this extension, and one or more routers do not support this extension.
因此，如果一个或多个路由器支持此扩展，并且一个或多个路由器不支持此扩展，则此扩展不会在RSVP内造成不良影响。
This document does not lessen the overall security of RSVP or of reservation flows through an aggregate.
本文档不会降低RSVP或通过聚合的预订流的总体安全性。
If this specification is implemented poorly - which is never intended, but is a consideration - the following issues may arise:
如果本规范实施不善——这并非有意，而是考虑因素——可能会出现以下问题：
1) If the ResvTear messages are transmitted initially (at the same time as the ResvErr messages indicating a reduction in bandwidth is necessary), all upstream routers will tear down the entire reservation. This will free up the total amount of bandwidth of this reservation inadvertently. This may cause the re-establishment of an otherwise good reservation to fail. This has the most severe affects on an aggregate that has many individual flows that would have remained operational.
1) 如果最初发送ResvTear消息（与指示带宽减少的ResvErr消息同时发送），则所有上游路由器将取消整个保留。这将无意中释放此保留的带宽总量。这可能会导致重新建立一项原本良好的保留失败。这对一个拥有许多本可以继续运行的单独流量的集合产生了最严重的影响。
2) Just as RSVP has the vulnerability of premature termination of valid reservations by rogue flows without authentication [12, 13], this mechanism will have the same vulnerability. Usage of RSVP authentication mechanisms is encouraged.
2) 正如RSVP存在未经身份验证的流氓流提前终止有效保留的漏洞一样[12,13]，该机制也会存在同样的漏洞。鼓励使用RSVP身份验证机制。
The IANA has assigned the following from RFC 4495 (i.e., this document):
IANA已从RFC 4495（即本文件）中分配了以下内容：
The following error code has been defined in the ERROR_SPEC object for partial reservation failure under "Errcode = 2 (Policy Control Failure)":
在“Errcode=2（策略控制失败）”下的部分保留失败的error_SPEC对象中定义了以下错误代码：
ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)
ErrSubCode=102（ERR_PARTIAL_PREEMPT）
The behavior of this ErrSubCode is defined in this document.
此子代码的行为在此文档中定义。
The authors would like to thank Fred Baker for contributing text and guidance in this effort and to Roger Levesque and Francois Le Faucheur for helpful comments.
作者要感谢Fred Baker在这项工作中提供的文本和指导，并感谢Roger Levesque和Francois Le Faucheur提供的有用意见。
[1] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[1] Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[2] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[2] Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 31752001年9月。
[3] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[3] Herzog，S.，“信号抢占优先权政策要素”，RFC 31812001年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[5] Herzog，S.，“政策控制的RSVP扩展”，RFC 2750，2000年1月。
[6] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[6] Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[7] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[7] Wroclawski，J.，“RSVP与IETF综合服务的使用”，RFC 2210，1997年9月。
[8] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[8] Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2207，1997年9月。
[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[9] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[10] Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[11] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate RSVP Reservations", Work in Progress, October 2005.
[11] Le Faucheur，F.，Davie，B.，Bose，P.，Christou，C.，和M.Davenport，“通用总RSVP保留”，正在进行的工作，2005年10月。
[12] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[12] Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[13] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[13] Braden，R.和L.Zhang，“RSVP加密认证——更新的消息类型值”，RFC 3097，2001年4月。
Here is a concise explanation of roughly how RSVP behaves with the solution to the problems presented in Sections 2 and 3 of this document. There is no normative text in this appendix.
以下简要说明了RSVP在解决本文件第2节和第3节中提出的问题时的行为。本附录中没有规范性文本。
Here is a duplicate of Figure 2 from section 3 of the document body (to bring it closer to the detailed description of the solution).
这里是文档正文第3节中图2的副本（使其更接近解决方案的详细描述）。
Aggregator of X Deaggregator of X
| |
V V
+------+ +------+ +------+ +------+
Flow 1-->| | | | | | | |-->Flow 1
Flow 2-->| | | | | | | |-->Flow 2
Flow 3-->| |==>| | | |==>| |-->Flow 3
Flow 4-->| | ^ | | | | ^ | |-->Flow 4
Flow 5-->| | | | | | | | | |-->Flow 5
Flow 9-->| R1 | | | R2 | | R3 | | | R4 |-->Flow 9
+------+ | +------+ +------+ | +------+
| || || |
Aggregate X--->|| Aggregate X ||<--Aggregate X
|| | ||
+--------------+ | +--------------+
| |Int 7 | | |Int 1 | |
| +----- | V |------+ |
| R10 |Int 8 |===========>|Int 2 | R11 |
| | |:::::::::::>| | |
| +----- | ^ |------+ |
| |Int 9 | | |Int 3 | |
+--------------+ | +--------------+
.. | ..
Aggregate Y--->.. Aggregate Y ..<---Aggregate Y
| .. .. |
+------+ | +------+ +------+ | +------+
Flow A-->| | | | | | | | | |-->Flow A
Flow B-->| | V | | | | V | |-->Flow B
Flow C-->| |::>| | | |::>| |-->Flow C
Flow D-->| | | | | | | |-->Flow D
Flow E-->| R5 | | R6 | | R7 | | R8 |-->Flow E
+------+ +------+ +------+ +------+
^ ^
| |
Aggregator of Y Deaggregator of Y
Aggregator of X Deaggregator of X
| |
V V
+------+ +------+ +------+ +------+
Flow 1-->| | | | | | | |-->Flow 1
Flow 2-->| | | | | | | |-->Flow 2
Flow 3-->| |==>| | | |==>| |-->Flow 3
Flow 4-->| | ^ | | | | ^ | |-->Flow 4
Flow 5-->| | | | | | | | | |-->Flow 5
Flow 9-->| R1 | | | R2 | | R3 | | | R4 |-->Flow 9
+------+ | +------+ +------+ | +------+
| || || |
Aggregate X--->|| Aggregate X ||<--Aggregate X
|| | ||
+--------------+ | +--------------+
| |Int 7 | | |Int 1 | |
| +----- | V |------+ |
| R10 |Int 8 |===========>|Int 2 | R11 |
| | |:::::::::::>| | |
| +----- | ^ |------+ |
| |Int 9 | | |Int 3 | |
+--------------+ | +--------------+
.. | ..
Aggregate Y--->.. Aggregate Y ..<---Aggregate Y
| .. .. |
+------+ | +------+ +------+ | +------+
Flow A-->| | | | | | | | | |-->Flow A
Flow B-->| | V | | | | V | |-->Flow B
Flow C-->| |::>| | | |::>| |-->Flow C
Flow D-->| | | | | | | |-->Flow D
Flow E-->| R5 | | R6 | | R7 | | R8 |-->Flow E
+------+ +------+ +------+ +------+
^ ^
| |
Aggregator of Y Deaggregator of Y
Duplicate of Figure 2. Generic RSVP Aggregate Topology
图2的副本。通用RSVP聚合拓扑
Looking at Figure 2, aggregate X (with five 80 kbps flows) traverses:
查看图2，聚合X（具有五个80 kbps流）遍历：
R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4
R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4
And aggregate Y (with five 80 kbps flows) traverses:
和聚合Y（具有五个80 kbps流）遍历：
R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
Both aggregates are 400 kbps. This totals 800 kbps at Int 7 in R10, which is the maximum bandwidth that RSVP has access to at this interface. Signaling messages still traverse the interface without problem. Aggregate X is at a higher relative priority than aggregate Y. Local policy in this example is for higher relative priority flows to preempt lower-priority flows during times of congestion. The following points describe the flow when aggregate A is increased to include Flow 9.
两个聚合都是400kbps。R10中Int 7的总带宽为800 kbps，这是RSVP在此接口上可以访问的最大带宽。信令消息仍然毫无问题地穿过接口。聚合X的相对优先级高于聚合Y。在本例中，本地策略用于在拥塞期间抢占较高相对优先级的流，以抢占较低优先级的流。以下几点描述了当骨料A增加到包括流量9时的流量。
o When Flow 9 (at 80 kbps) is added to aggregate X, R1 will initiate the PATH message towards the destination endpoint of the flow. This hop-by-hop message will take it through R2, R10, R11, R3, and R4, which is the aggregate X path (that was built per [2] from the aggregate's initial setup) to the endpoint node.
o 将流9（80 kbps）添加到聚合X时，R1将向流的目标端点发起路径消息。此逐跳消息将通过R2、R10、R11、R3和R4，这是到端点节点的聚合X路径（根据[2]从聚合的初始设置构建）。
o In response, R4 will generate the RESV (reservation) message (defined behavior per [1]). This RESV from the deaggregator indicates an increase bandwidth sufficient to accommodate the existing 5 flows (1, 2, 3, 4, and 5) and the new flow (9), as stated in [2].
o 作为响应，R4将生成RESV（保留）消息（根据[1]定义的行为）。如[2]所述，来自解聚器的该RESV表示带宽的增加足以容纳现有的5个流（1、2、3、4和5）和新的流（9）。
o As mentioned before, in this example, Int 8 in R10 can only accommodate 800 kbps, and aggregates X and Y have each already established 400 kbps flows comprised of five 80 kbps individual flows. Therefore, R10 (the interface that detects a congestion event in this example) must make a decision about this new congestion generating condition in regard to the RESV message received at Int 8.
o 如前所述，在本例中，R10中的Int 8只能容纳800 kbps，聚合X和Y已经分别建立了400 kbps流，其中包括五个80 kbps的单独流。因此，R10（本例中检测拥塞事件的接口）必须针对在Int 8接收到的RESV消息，决定新的拥塞生成条件。
o Local policy in this scenario is to preempt lower-priority reservations to place higher-priority reservations. This would normally cause all of aggregate Y to be preempted just to accommodate aggregate X's request for an additional 80 kbps.
o 在这种情况下，本地策略是抢占较低优先级的预订，以放置较高优先级的预订。通常情况下，对于一个80 kbps的聚合，该聚合只会导致一个80 kbps的聚合。
o This document defines how aggregate Y is not completely preempted, but reduced in bandwidth by 80 kbps. This is contained in the ResvErr message that R10 generates (downstream) towards R11, R7, and R8. See section 5 for the details of the error message.
o 本文档定义了聚合Y如何不被完全抢占，而是将带宽减少80 kbps。这包含在R10向R11、R7和R8生成（下游）的ResvErr消息中。有关错误消息的详细信息，请参见第5节。
o Normal operation of RSVP is to have the router that generates a ResvErr message downstream to also generate a ResvTear message upstream (in the opposite direction, i.e., towards R5). The ResvTear message terminates an individual flow or aggregate flow. This document calls for that message not to be sent on any partial failure of reservation.
o RSVP的正常操作是让下游生成ResvErr消息的路由器也在上游生成ResvTear消息（在相反方向，即朝向R5）。ResvTear消息终止单个流或聚合流。本文件要求在预订部分失败时不要发送该消息。
o R8 is the deaggregator of aggregate Y. The deaggregator controls all the parameters of an aggregate reservation. This will be the node that reduces the necessary bandwidth of the aggregate as a response to the reception of an ResvErr message (from R10) indicating such an action is called for. In this example, bandwidth reduction is accomplished by preempting an individual flow within the aggregate (perhaps picking on Flow D for individual preemption by generating a ResvErr downstream on that individual flow).
o R8是聚合Y的解聚集器。该解聚集器控制聚合保留的所有参数。这将是减少聚合的必要带宽的节点，作为对接收到（来自R10）指示调用此类操作的ResvErr消息的响应。在此示例中，带宽减少是通过抢占聚合中的单个流来实现的（可能通过在该单个流的下游生成ResvErr来选择流D进行单独抢占）。
o At the same time, a ResvTear message is transmitted upstream on that individual flow (Flow D) by R8. This will not affect the aggregate directly, but is an indication to the routers (and the source end-system) which individual flow is to be preempted.
o 同时，ResvTear消息由R8在单个流（流D）上向上游传输。这不会直接影响聚合，但会向路由器（和源端系统）指示哪个单独的流将被抢占。
o Once R8 preempts whichever individual flow (or 'bandwidth' at the aggregate ingress), it transmits a new RESV message for that aggregate (Y), not for a new aggregate. This RESV from the deaggregator indicates a decrease in bandwidth sufficient to accommodate the remaining 4 flows (A, B, C, and E), which is now 320 kbps (in this example).
o 一旦R8抢占任何单个流（或聚合入口的“带宽”），它将为该聚合（Y）而不是新聚合发送新的RESV消息。来自解聚集器的这个RESV表示带宽的减少足以容纳剩余的4个流（a、B、C和E），现在是320 kbps（在本例中）。
o This RESV message travels the entire path of the reservation, resetting all routers to this new aggregate bandwidth value. This should be what is necessary to prevent a ResvTear message from being generated by R10 towards R6 and R5.
o 此RESV消息在保留的整个路径上传播，将所有路由器重置为此新的聚合带宽值。这应该是防止R10向R6和R5生成ResvTear消息所必需的。
R5 will not know through this RESV message which individual flow was preempted. If in this example, R8 was given more bandwidth to keep, it might have transmitted a bandwidth reduction ResvErr indication towards the end-system of Flow D. In that case, a voice signaling protocol (such as SIP) could have attempted a renegotiation of that individual flow to a reduced bandwidth (say, but changing the voice codec from G.711 to G. 729). This could have saved Flow D from preemption.
R5不会通过此RESV消息知道哪个单独的流被抢占。如果在该示例中，R8被给予更多的带宽以保持，则它可能已经向流D的终端系统发送了带宽减少ResvErr指示。在这种情况下，语音信令协议（例如SIP）可能已经尝试将该单个流重新协商到减少的带宽（比如，但将语音编解码器从G.711更改为G.729）。这可以避免流D被抢占。
Authors' Addresses
作者地址
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
詹姆斯·M·波尔克思科系统2200美国德克萨斯州东总统乔治·布什收费公路理查森75082
EMail: jmpolk@cisco.com
EMail: jmpolk@cisco.com
Subha Dhesikan Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道西170号Subha Dhesikan Cisco Systems，邮编95134
EMail: sdhesika@cisco.com
EMail: sdhesika@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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 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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。