Network Working Group F. Baker
Request for Comments: 3175 C. Iturralde
Category: Standards Track F. Le Faucheur
B. Davie
Cisco Systems
September 2001
Network Working Group F. Baker
Request for Comments: 3175 C. Iturralde
Category: Standards Track F. Le Faucheur
B. Davie
Cisco Systems
September 2001
Aggregation of RSVP for IPv4 and IPv6 Reservations
IPv4和IPv6保留的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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes the use of a single RSVP (Resource ReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations.
本文档描述了使用单个RSVP（资源预留协议）预留来聚合跨传输路由区域的其他RSVP预留，其方式在概念上类似于在ATM（异步传输模式）网络中使用虚拟路径。它提出了一种动态创建聚合保留的方法，对聚合保留应用的流量进行分类，确定实现需求所需的带宽，并在不再需要子保留时恢复带宽。它还包含关于预测性保留的算法和策略的建议。
A key problem in the design of RSVP version 1 [RSVP] is, as noted in its applicability statement, that it lacks facilities for aggregation of individual reserved sessions into a common class. The use of such aggregation is recommended in [CSZ], and required for scalability.
RSVP版本1[RSVP]设计中的一个关键问题是，正如其适用性声明中所指出的，它缺乏将单个保留会话聚合到一个公共类中的功能。[CSZ]中建议使用这种聚合，这是可伸缩性所必需的。
The problem of aggregation may be addressed in a variety of ways. For example, it may sometimes be sufficient simply to mark reserved traffic with a suitable DSCP (e.g., EF), thus enabling aggregation of scheduling and classification state. It may also be desirable to install one or more aggregate reservations from ingress to egress of
聚合问题可以通过多种方式解决。例如，有时仅用合适的DSCP（例如EF）标记保留的通信量就足够了，从而能够聚合调度和分类状态。还可能需要从入口到出口安装一个或多个聚合预留
an "aggregation region" (defined below) where each aggregate reservation carries similarly marked packets from a large number of flows. This is to provide high levels of assurance that the end-to-end requirements of reserved flows will be met, while at the same time enabling reservation state to be aggregated.
一种“聚合区域”（定义如下），其中每个聚合保留携带来自大量流的类似标记的数据包。这是为了提供高水平的保证，以满足保留流的端到端需求，同时使保留状态能够聚合。
Throughout, we will talk about "Aggregator" and "Deaggregator", referring to the routers at the ingress and egress edges of an aggregation region. Exactly how a router determines whether it should perform the role of aggregator or deaggregator is described below.
自始至终，我们将讨论“聚合器”和“解聚合器”，指的是聚合区域入口和出口边缘的路由器。路由器如何确定它是否应该执行聚合器或解聚合器的角色，具体描述如下。
We will refer to the individual reserved sessions (the sessions we are attempting to aggregate) as "end-to-end" reservations ("E2E" for short), and to their respective Path/Resv messages as E2E Path/Resv messages. We refer to the the larger reservation (that which represents many E2E reservations) as an "aggregate" reservation, and its respective Path/Resv messages as "aggregate Path/Resv messages".
我们将单个保留会话（我们试图聚合的会话）称为“端到端”保留（“E2E”简称），并将其各自的Path/Resv消息称为E2E Path/Resv消息。我们将较大的保留（表示许多E2E保留）称为“聚合”保留，将其各自的Path/Resv消息称为“聚合Path/Resv消息”。
The problem of many small reservations has been extensively discussed, and may be summarized in the observation that each reservation requires a non-trivial amount of message exchange, computation, and memory resources in each router along the way. It would be nice to reduce this to a more manageable level where the load is heaviest and aggregation is possible.
许多小型保留的问题已经被广泛讨论，并且可以总结为每个保留都需要在每个路由器中进行大量的消息交换、计算和内存资源。最好将其降低到一个更易于管理的级别，在这个级别上，负载最重，并且可以进行聚合。
Aggregation, however, brings its own challenges. In particular, it reduces the level of isolation between individual flows, implying that one flow may suffer delay from the bursts of another. Synchronization of bursts from different flows may occur. However, there is evidence [CSZ] to suggest that aggregation of flows has no negative effect on the mean delay of the flows, and actually leads to a reduction of delay in the "tail" of the delay distribution (e.g., 99% percentile delay) for the flows. These benefits of aggregation to some extent offset the loss of strict isolation.
然而，聚合也带来了自身的挑战。特别是，它降低了单个流之间的隔离级别，这意味着一个流可能会因另一个流的突发而受到延迟。可能会发生来自不同流的突发同步。然而，有证据[CSZ]表明，流的聚集对流的平均延迟没有负面影响，实际上导致流延迟分布的“尾部”延迟减少（例如，99%的百分位延迟）。聚合的这些好处在一定程度上抵消了严格隔离的损失。
The solution we propose involves the aggregation of several E2E reservations that cross an "aggregation region" and share common ingress and egress routers into one larger reservation from ingress to egress. We define an "aggregation region" as a contiguous set of systems capable of performing RSVP aggregation (as defined following) along any possible route through this contiguous set.
我们提出的解决方案涉及将几个跨越“聚合区域”并共享公共入口和出口路由器的E2E保留聚合为一个从入口到出口的更大保留。我们将“聚合区域”定义为一组连续的系统，这些系统能够沿着通过该连续集合的任何可能路径执行RSVP聚合（定义如下）。
Communication interfaces fall into two categories with respect to an aggregation region; they are "exterior" to an aggregation region, or they are "interior" to it. Routers that have at least one interface in the region fall into one of three categories with respect to a given RSVP session; they aggregate, they deaggregate, or they are between an aggregator and a deaggregator.
就聚合区域而言，通信接口分为两类；它们是聚合区域的“外部”，或者是聚合区域的“内部”。对于给定的RSVP会话，在该区域中具有至少一个接口的路由器分为三类之一；它们聚合、反聚合，或者介于聚合器和反聚合器之间。
Aggregation depends on being able to hide E2E RSVP messages from RSVP-capable routers inside the aggregation region. To achieve this end, the IP Protocol Number in the E2E reservation's Path, PathTear, and ResvConf messages is changed from RSVP (46) to RSVP-E2E-IGNORE (134) upon entering the aggregation region, and restored to RSVP at the deaggregator point. These messages are ignored (no state is stored and the message is forwarded as a normal IP datagram) by each router within the aggregation region whenever they are forwarded to an interior interface. Since the deaggregating router perceives the previous RSVP hop on such messages to be the aggregating router, Resv and other messages do not require this modification; they are unicast from RSVP hop to RSVP hop anyway.
聚合取决于能否从聚合区域内支持RSVP的路由器隐藏E2E RSVP消息。为了达到这一目的，E2E保留的Path、PATHTRARE和ResvConf消息中的IP协议号在进入聚合区域时从RSVP（46）更改为RSVP-E2E-IGNORE（134），并在解聚合点恢复为RSVP。每当这些消息被转发到内部接口时，聚合区域内的每个路由器都会忽略这些消息（不存储任何状态，并且该消息作为正常IP数据报转发）。由于解聚集路由器感知到此类消息上的先前RSVP跳是聚集路由器，因此Resv和其他消息不需要此修改；无论如何，它们都是从RSVP跳到RSVP跳的单播。
The token buckets (SENDER_TSPECs and FLOWSPECS) of E2E reservations are summed into the corresponding information elements in aggregate Path and Resv messages. Aggregate Path messages are sent from the aggregator to the deaggregator(s) using RSVP's normal IP Protocol Number. Aggregate Resv messages are sent back from the deaggregator to the aggregator, thus establishing an aggregate reservation on behalf of the set of E2E flows that use this aggregator and deaggregator.
E2E保留的令牌桶（发送方_tspec和流规范）被汇总到聚合路径和Resv消息中的相应信息元素中。聚合路径消息使用RSVP的正常IP协议号从聚合器发送到解聚合器。聚合Resv消息从解聚合器发送回聚合器，从而代表使用此聚合器和解聚合器的E2E流集建立聚合保留。
Such establishment of a smaller number of aggregate reservations on behalf of a larger number of E2E reservations yields the corresponding reduction in the amount of state to be stored and amount of signalling messages exchanged in the aggregation region.
代表较大数量的E2E保留的较小数量的聚合保留的这种建立产生要存储的状态量和在聚合区域中交换的信令消息量的相应减少。
By using Differentiated Services mechanisms for classification and scheduling of traffic supported by aggregate reservations (rather than performing per aggregate reservation classification and scheduling), the amount of classification and scheduling state in the aggregation region is even further reduced. It is not only independent of the number of E2E reservations, it is also independent of the number of aggregate reservations in the aggregation region. One or more Diff-Serv DSCPs are used to identify traffic covered by aggregate reservations and one or more Diff-Serv PHBs are used to offer the required forwarding treatment to this traffic. There may be more than one aggregate reservation between the same pair of routers, each representing different classes of traffic and each using a different DSCP and a different PHB.
通过使用区分服务机制对聚合保留支持的流量进行分类和调度（而不是执行每个聚合保留分类和调度），聚合区域中的分类和调度状态量甚至进一步减少。它不仅与E2E保留的数量无关，还与聚合区域中的聚合保留的数量无关。一个或多个Diff-Serv DSCP用于识别聚合预订覆盖的流量，一个或多个Diff-Serv PHB用于为该流量提供所需的转发处理。同一对路由器之间可能存在多个聚合保留，每个路由器表示不同的流量类别，并且每个路由器使用不同的DSCP和不同的PHB。
We define an "aggregation region" as a set of RSVP-capable routers for which E2E RSVP messages arriving on an exterior interface of one router in the set would traverse one or more interior interfaces (of this and possibly of other routers in the set) before finally traversing an exterior interface.
我们将“聚合区域”定义为一组支持RSVP的路由器，对于这些路由器，到达集合中一个路由器的外部接口的E2E RSVP消息将在最终遍历外部接口之前遍历一个或多个内部接口（该路由器的内部接口，可能还有集合中的其他路由器的内部接口）。
Such an E2E RSVP message is said to have crossed the aggregation region.
据说这样的E2E RSVP消息已经跨越了聚合区域。
We define the "aggregating" router for this E2E flow as the first router that processes the E2E Path message as it enters the aggregation region (i.e., the one which forwards the message from an exterior interface to an interior interface).
我们将该E2E流的“聚合”路由器定义为在E2E路径消息进入聚合区域时处理该消息的第一个路由器（即，将消息从外部接口转发到内部接口的路由器）。
We define the "deaggregating" router for this E2E flow as the last router to process the E2E Path as it leaves the aggregation region (i.e., the one which forwards the message from an interior interface to an exterior interface).
我们将此E2E流的“解聚集”路由器定义为在E2E路径离开聚集区域时处理E2E路径的最后一个路由器（即，将消息从内部接口转发到外部接口的路由器）。
We define an "interior" router for this E2E flow as any router in the aggregation region which receives this message on an interior interface and forwards it to another interior interface. Interior routers perform neither aggregation nor deaggregation for this flow.
我们将此E2E流的“内部”路由器定义为聚合区域中的任何路由器，该路由器在内部接口上接收此消息并将其转发到另一个内部接口。内部路由器对此流既不执行聚合也不执行反聚合。
Note that by these definitions a single router with a mix of interior and exterior interfaces may have the capability to act as an aggregator on some E2E flows, a deaggregator on other E2E flows, and an interior router on yet other flows.
注意，根据这些定义，具有内部和外部接口混合的单个路由器可以在某些E2E流上充当聚合器，在其他E2E流上充当解聚合器，在其他流上充当内部路由器。
A number of issues jump to mind in considering this model.
在考虑这个模型时，人们会想到许多问题。
One of the reasons that RSVP Version 1 did not identify a way to aggregate sessions was that there was not a clear way to classify the aggregate. With the development of the Differentiated Services architecture, this is at least partially resolved; traffic of a particular class can be marked with a given DSCP and so classified. We presume this model.
RSVP版本1没有确定聚合会话的方法的原因之一是没有明确的方法对聚合进行分类。随着区分服务体系结构的发展，这至少部分得到了解决；特定类别的流量可以用给定的DSCP进行标记，并进行分类。我们假设这个模型。
We presume that on each link en route, a queue, WDM color, or similar management component is set aside for all aggregated traffic of the same class, and that sufficient bandwidth is made available to carry
我们假设，在路由的每个链路上，为同一类的所有聚合流量预留一个队列、WDM颜色或类似的管理组件，并提供足够的带宽进行传输
the traffic that has been assigned to it. This bandwidth may be adjusted based on the total amount of aggregated reservation traffic assigned to the same class.
已分配给它的通信量。该带宽可以基于分配给同一类的聚合预约业务总量进行调整。
There are numerous options for exactly which Diff-serv PHBs might be used for different classes of traffic as it crosses the aggregation region. This is the "service mapping" problem described in [RFC2998], and is applicable to situations broader than those described in this document. Arguments can be made for using either EF or one or more AF PHBs for aggregated traffic. For example, since controlled load requires non-TSpec-conformant (policed) traffic to be forwarded as best effort traffic rather than dropped, it may be appropriate to use an AF class for controlled load, using the higher drop preference for non-conformant packets.
在跨聚合区域时，有许多选项可用于不同类别的流量。这是[RFC2998]中描述的“服务映射”问题，适用于比本文档中描述的更广泛的情况。可以为聚合流量使用EF或一个或多个AF PHB提供参数。例如，由于受控负载要求将非TSpec一致（policed）通信作为尽力而为的通信转发，而不是丢弃，因此可能适合将AF类用于受控负载，对非一致性分组使用更高的丢弃偏好。
In conventional (unaggregated) RSVP operation, a session is identified by a destination address and optionally a protocol port. Since data belonging to an aggregated reservation is identified by a DSCP, the session is defined by the destination address and DSCP. For those cases where two DSCPs are used (for conformant and non-conformant packets, as noted above), the session is identified by the DSCP of conformant packets. In general we will talk about mapping aggregated traffic onto a DSCP (even if a second DSCP may be used for non-conformant traffic).
在传统的（未聚合的）RSVP操作中，会话由目标地址和可选的协议端口标识。由于属于聚合保留的数据由DSCP标识，因此会话由目标地址和DSCP定义。对于使用两个DSCP的情况（如上所述，对于一致和非一致数据包），会话由一致数据包的DSCP标识。一般来说，我们将讨论将聚合流量映射到DSCP（即使第二个DSCP可能用于不一致的流量）。
Whichever PHB or PHBs are used to carry aggregated reservations, care needs to be take in an environment where provisioned Diff-Serv and aggregated RSVP are used in the same network, to ensure that the total admitted load for a single PHB does not exceed the link capacity allocated to that PHB. One solution to this is to reserve one PHB (or more) strictly for the aggregated reservation traffic (e.g., AF1 Class) while using other PHBs for provisioned Diff-Serv (e.g., AF2, AF3 and AF4 Classes).
无论使用哪个PHB或PHB来承载聚合保留，在同一网络中使用已配置的区分服务和聚合RSVP的环境中都需要小心，以确保单个PHB的总允许负载不超过分配给该PHB的链路容量。一种解决方案是严格为聚合的保留流量（例如AF1类）保留一个PHB（或多个PHB），同时使用其他PHB来提供区分服务（例如AF2、AF3和AF4类）。
Inside the aggregation region, some RSVP reservation state is maintained per aggregate reservation, while classification and scheduling state (e.g., DSCPs used for classifying traffic) is maintained on a per aggregate reservation class basis (rather than per aggregate reservation). For example, if Guaranteed Service reservations are mapped to the EF DSCP throughout the aggregation region, there may be a reservation for each aggregator/deaggregator pair in each router, but only the EF DSCP needs to be inspected at each interior interface, and only a single queue is used for all EF traffic.
在聚合区域内，每个聚合保留维护一些RSVP保留状态，而分类和调度状态（例如，用于对流量进行分类的DSCP）基于每个聚合保留类（而不是每个聚合保留）进行维护。例如，如果保证服务保留映射到整个聚合区域中的EF DSCP，则每个路由器中的每个聚合器/解聚合器对可能都有保留，但每个内部接口只需要检查EF DSCP，并且所有EF流量只使用一个队列。
The first question is "How do we determine the Aggregator/Deaggregator pair that are responsible for aggregating a particular E2E flow through the aggregation region?"
第一个问题是“我们如何确定负责通过聚合区域聚合特定E2E流的聚合器/解聚器对？”
Determination of the aggregator is trivial: we know that an E2E flow has arrived at an aggregator when its Path message arrives at a router on an exterior interface and must be forwarded on an interior interface.
聚合器的确定很简单：我们知道当E2E流的路径消息到达外部接口上的路由器并且必须在内部接口上转发时，E2E流已经到达聚合器。
Determination of the deaggregator is more involved. If an SPF routing protocol, such as OSPF or IS-IS, is in use, and if it has been extended to advertise information on Deaggregation roles, it can tell us the set of routers from which the deaggregator will be chosen. In principle, if the aggregator and deaggregator are in the same area, then the identity of the deaggregator could be determined from the link state database. However, this approach would not work in multi-area environments or for distance vector protocols.
更为复杂的是去集聚器的确定。如果SPF路由协议（如OSPF或IS-IS）正在使用，并且如果它已被扩展以公布有关解聚集角色的信息，它可以告诉我们将从中选择解聚集器的路由器集。原则上，如果聚合器和解聚合器位于同一区域，则可以从链路状态数据库确定解聚合器的标识。然而，这种方法不适用于多区域环境或距离向量协议。
One method for Deaggregator determination is manual configuration. With this method the network operator would configure the Aggregator and the Deaggregator with the necessary information.
一种确定解集器的方法是手动配置。使用此方法，网络运营商将使用必要的信息配置聚合器和解聚合器。
Another method allows automatic Deaggregator determination and corresponding Aggregator notification. When the E2E RSVP Path message transits from an interior interface to an exterior interface, the deaggregating router must advise the aggregating router of the correlation between itself and the flow. This has the nice attribute of not being specific to the routing protocol. It also has the property of automatically adjusting to route changes. For instance, if because of a topology change, another Deaggregator is now on the shortest path, this method will automatically identify the new Deaggregator and swap to it.
另一种方法允许自动取消聚集器确定和相应的聚集器通知。当E2E RSVP Path消息从内部接口传输到外部接口时，解聚集路由器必须将自身与流量之间的相关性通知聚合路由器。这具有不特定于路由协议的良好属性。它还具有自动调整以适应管线更改的特性。例如，如果由于拓扑更改，另一个解聚集器现在位于最短路径上，此方法将自动识别新的解聚集器并与之交换。
As discussed above, there may be multiple Aggregate Reservations between the same Aggregator/Deaggregator pair. The rules for mapping E2E reservations onto aggregate reservations are policy decisions which depend on the network environment and network administrator's objectives. Such a policy is outside the scope of this specification and we simply assume that such a policy is defined by the network administrator. We also assume that such a policy is somehow accessible to the Aggregators/Deaggregators but the details of how this policy is made accessible to Aggregators/Deaggregators (Local Configuration, COPS, LDAP, etc.) is outside the scope of this specification.
如上所述，同一聚合器/解聚合器对之间可能存在多个聚合保留。将E2E保留映射到聚合保留的规则是策略决策，这取决于网络环境和网络管理员的目标。这样的策略不在本规范的范围内，我们只是假设这样的策略是由网络管理员定义的。我们还假设聚合器/解聚合器可以以某种方式访问此策略，但如何使此策略可供聚合器/解聚合器访问（本地配置、COP、LDAP等）的详细信息不在本规范的范围内。
An example of very simple policy would be that all the E2E reservations are mapped onto a single Aggregate Reservation (i.e., single DSCP) between a given pair of Aggregator/Deaggregator.
一个非常简单的策略示例是，所有E2E保留都映射到给定一对聚合器/解聚合器之间的单个聚合保留（即，单个DSCP）。
Another example of policy, which takes into account the Int-Serv service type requested by the receiver (and signalled in the E2E Resv), would be where Guaranteed Service E2E reservations are mapped onto one DSCP in the aggregation region and where Controlled Load E2E reservations are mapped onto another DSCP.
考虑到接收机请求的Int-Serv服务类型（并在E2E Resv中发出信号）的策略的另一个示例是，保证服务E2E保留映射到聚合区域中的一个DSCP，并且受控负载E2E保留映射到另一个DSCP。
A third example of policy would be one where the mapping of E2E reservations onto Aggregate Reservations take into account Policy Objects (such as information authenticating the end user) which may be included by the sender in the E2E path and/or by the receiver in the E2E Resv.
策略的第三个示例是其中E2E保留到聚合保留的映射考虑到策略对象（例如认证最终用户的信息），策略对象可由E2E路径中的发送方和/或E2E Resv中的接收方包括。
Regardless of the actual policy, a range of options are conceivable for where the decision to map an E2E reservation onto an aggregate reservation is taken and how this decision is communicated between Aggregator and Deaggregator. Both Aggregator and Deaggregator could be assumed to make such a decision independently. However, this would either require definition of additional procedures to solve inconsistent mapping decisions (i.e., Aggregator and Deaggregator decide to map a given E2E reservation onto different Aggregate Reservations) or would result in possible undetected misbehavior in the case of inconsistent decisions.
无论实际的政策如何，对于将E2E保留映射到聚合保留的决策是在何处做出的，以及该决策如何在聚合器和解聚合器之间进行沟通，都有一系列的选择。聚合器和解聚合器都可以独立地做出这样的决策。然而，这要么需要定义额外的程序来解决不一致的映射决策（即聚合器和解聚合器决定将给定的E2E保留映射到不同的聚合保留），要么在决策不一致的情况下导致可能未被发现的错误行为。
For simplicity and reliability, we assign the responsibility of the mapping decision entirely to the Deaggregator. The Aggregator is notified of the selected mapping by the Deaggregator and follows this decision. The Deaggregator was chosen rather than the Aggregator because the Deaggregator is the first to have access to all the information required to make such a decision (in particular receipt of the E2E Resv which indicates the requested Int-Serv service type and includes information signalled by the receiver). This allows faster operations such as set-up or size adjustment of an Aggregate Reservation in a number of situations resulting in faster E2E reservation establishment.
为了简单和可靠，我们将映射决策的责任完全分配给解聚集器。解聚集器会将所选映射通知聚合器，并遵循此决定。之所以选择解聚集器而不是聚合器，是因为解聚集器是第一个访问做出此类决策所需的所有信息的人（特别是接收到E2E Resv，其指示所请求的Int Serv服务类型，并包括由接收器发出信号的信息）。这允许更快的操作，例如在许多情况下设置或调整聚合保留的大小，从而加快E2E保留的建立。
A range of options exist for determining the size of the aggregate reservation, presenting a tradeoff between simplicity and scalability. Simplistically, the size of the aggregate reservation needs to be greater than or equal to the sum of the bandwidth of the E2E reservations it aggregates, and its burst capacity must be greater than or equal to the sum of their burst capacities. However, if followed religiously, this leads us to change the bandwidth of the
存在一系列用于确定聚合保留大小的选项，在简单性和可伸缩性之间进行权衡。简单地说，聚合保留的大小需要大于或等于其聚合的E2E保留的带宽之和，并且其突发容量必须大于或等于其突发容量之和。然而，如果按照宗教信仰，这将导致我们改变网络的带宽
aggregate reservation each time an underlying E2E reservation changes, which loses one of the key benefits of aggregation, the reduction of message processing cost in the aggregation region.
每次底层E2E保留更改时聚合保留，这将失去聚合的关键好处之一，即降低聚合区域中的消息处理成本。
We assume, therefore, that there is some policy, not defined in this specification (although sample policies are suggested which have the necessary characteristics). This policy maintains the amount of bandwidth required on a given aggregate reservation by taking account of the sum of the bandwidths of its underlying E2E reservations, while endeavoring to change it infrequently. This may require some level of trend analysis. If there is a significant probability that in the next interval of time the current aggregate reservation will be exhausted, the router must predict the necessary bandwidth and request it. If the router has a significant amount of bandwidth reserved but has very little probability of using it, the policy may be to predict the amount of bandwidth required and release the excess.
因此，我们假设存在一些本规范中未定义的策略（尽管建议使用具有必要特征的示例策略）。此策略通过考虑其基础E2E保留的带宽之和来维持给定聚合保留所需的带宽量，同时尽量不频繁地对其进行更改。这可能需要某种程度的趋势分析。如果在下一个时间间隔内，当前聚合保留将耗尽的可能性很大，路由器必须预测必要的带宽并请求它。如果路由器保留了大量带宽，但使用它的可能性很小，那么策略可能是预测所需的带宽量并释放多余的带宽。
This policy is likely to benefit from introduction of some hysteresis (i.e., ensure that the trigger condition for aggregate reservation size increase is sufficiently different from the trigger condition for aggregate reservation size decrease) to avoid oscillation in stable conditions.
该政策可能受益于引入一些滞后（即，确保总保留大小增加的触发条件与总保留大小减少的触发条件充分不同），以避免稳定条件下的振荡。
Clearly, the definition and operation of such policies are as much business issues as they are technical, and are out of the scope of this document.
显然，此类政策的定义和操作既属于技术问题，也属于业务问题，不在本文档的范围之内。
As described above, E2E RSVP messages are hidden from the Interior routers inside the aggregation region. Consequently, the ADSPECs of E2E Path messages are not updated as they travel through the aggregation region. Therefore, the Deaggregator for a flow is responsible for updating the ADSPEC in the corresponding E2E Path to reflect the impact of the aggregation region on the QoS that may be achieved end-to-end. The Deaggregator should update the ADSPEC of the E2E Path as accurately as possible.
如上所述，E2E RSVP消息对聚合区域内的内部路由器隐藏。因此，E2E路径消息的adspec在通过聚合区域时不会被更新。因此，流的解聚集器负责更新相应E2E路径中的ADSPEC，以反映聚集区域对可端到端实现的QoS的影响。解集器应尽可能准确地更新E2E路径的ADSPEC。
Since Aggregate Path messages are processed inside the aggregation region, their ADSPEC is updated by Interior routers to reflect the impact of the aggregation region on the QoS that may be achieved within the interior region. Consequently, the Deaggregator should make use of the information included in the ADSPEC from an Aggregate Path where available. The Deaggregator may elect to wait until such information is available before forwarding the E2E Path in order to accurately update its ADSPEC.
由于聚合路径消息在聚合区域内处理，因此内部路由器更新其ADSPEC以反映聚合区域对内部区域内可能实现的QoS的影响。因此，在可用的情况下，解聚集器应使用聚合路径中ADSPEC中包含的信息。解聚器可以选择在转发E2E路径之前等待直到该信息可用，以便准确地更新其ADSPEC。
To maximize the information made available to the Deaggregator, whenever the Aggregator signals an Aggregate Path, the Aggregator should include an ADSPEC with fragments for all service types supported in the aggregation region (even if the Aggregate Path corresponds to an Aggregate Reservation that only supports a subset of those service types). Providing this information to the Deaggregator for every possible service type facilitates accurate and timely update of the E2E ADSPEC by the Deaggregator.
为了最大限度地利用提供给解聚集器的信息，每当聚合器发出聚合路径信号时，聚合器应包括一个ADSPEC，其中包含聚合区域中支持的所有服务类型的片段（即使聚合路径对应于仅支持这些服务类型子集的聚合保留）。为每种可能的服务类型向解集器提供此信息有助于解集器准确及时地更新E2E ADSPEC。
Depending on the environment and on the policy for mapping E2E reservations onto Aggregate Reservations, to accurately update the E2E Path ADSPEC, the Deaggregator may for example:
根据环境和将E2E保留映射到聚合保留的策略，为了准确地更新E2E路径ADSPEC，解聚集器可以例如：
- update all the E2E Path ADSPEC segments (Default General Parameters Fragment, Guaranteed Service Fragment, Controlled-Load Service Fragment) based on the ADSPEC of a single Aggregate Path, or
- 基于单个聚合路径的ADSPEC更新所有E2E路径ADSPEC段（默认通用参数段、保证服务段、受控负载服务段），或
- update the E2E Path ADSPEC by taking into account the ADSPEC from multiple Aggregate Path messages (e.g.,. update the Default General Parameters Fragment using the "worst" value for each parameter across all the Aggregate Paths' ADSPECs, update the Guaranteed Service Fragment using the Guaranteed Service Fragment from the ADSPEC of the Aggregate Path for the reservation used for Guaranteed Services).
- 通过考虑来自多个聚合路径消息的ADSPEC来更新E2E路径ADSPEC（例如，使用“最差”更新默认通用参数片段）值对于所有聚合路径的ADSPEC中的每个参数，使用聚合路径的ADSPEC中的保证服务片段更新保证服务片段（用于保证服务的保留）。
By taking into account the information contained in the ADSPEC of Aggregate Path(s) as mentioned above, the Deaggregator should be able to accurately update the E2E Path ADSPEC in most situations.
通过考虑上述聚合路径的ADSPEC中包含的信息，解聚集器应能够在大多数情况下准确更新E2E路径ADSPEC。
However, we note that there may be particular situations where the E2E Path ADSPEC update cannot be made entirely accurately by the Deaggregator. This is most likely to happen when the path taken across the aggregation region depends on the service requested in the E2E Resv, which is yet to arrive. Such a situation could arise if, for example:
然而，我们注意到，在某些特定情况下，解聚集器无法完全准确地进行E2E路径ADSPEC更新。当通过聚合区域的路径取决于E2E Resv中请求的服务（该服务尚未到达）时，最有可能发生这种情况。例如，如果：
- The service mapping policy for the aggregation region is such that E2E reservations requesting Guaranteed Service are mapped to a different PHB that those requesting Controlled Load service.
- 聚合区域的服务映射策略使得请求保证服务的E2E保留映射到那些请求受控负载服务的不同PHB。
- Diff-Serv aware routing is used in the aggregation region, so that packets with different DSCPs follow different paths (sending them over different MPLS label switched paths, for example).
- 聚合区域中使用区分服务感知路由，因此具有不同DSCP的数据包遵循不同的路径（例如，通过不同的MPLS标签交换路径发送数据包）。
As a result, the ADSPEC for the aggregate reservation that supports guaranteed service may differ from the ADSPEC for the aggregate reservation that supports controlled load.
因此，支持保证服务的聚合保留的ADSPEC可能不同于支持受控负载的聚合保留的ADSPEC。
Assume that the sender sends an E2E Path with an ADSPEC containing segments for both Guaranteed Services and Controlled Load. Then, at the time of updating the E2E ADSPEC, the Deaggregator does not know which service type will actually be requested by the receiver and therefore cannot know which PHB will be used to transport this E2E flow and, in turn, cannot pick the right parameter values to factor in when updating the Default General Parameters Fragment. As mentioned above, in this particular case, a conservative approach would be to always take into account the worst value for every parameter. Regardless of whether this conservative approach is followed or some simpler approach such as taking into account one of the two Aggregate Path ADSPEC, the E2E Path ADSPEC will be inaccurate (over-optimistic or over-pessimistic) for at least one service type actually requested by the destination.
假设发送方发送一个E2E路径，其中包含一个ADSPEC，其中包含保证服务和控制负载的段。然后，在更新E2E ADSPEC时，解聚集器不知道接收器实际将请求哪种服务类型，因此不知道将使用哪种PHB来传输该E2E流，并且，反过来，在更新默认通用参数片段时，不能选择要考虑的正确参数值。如上所述，在这种特殊情况下，保守的方法是始终考虑每个参数的最坏值。无论是采用这种保守的方法，还是考虑两种聚合路径ADSPEC中的一种等更简单的方法，E2E路径ADSPEC对于目的地实际请求的至少一种服务类型都是不准确的（过于乐观或过于悲观）。
Recognizing that entirely accurate update of E2E Path ADSPEC may not be possible in all situations, we recommend that a conservative approach be taken in such situations (over-pessimistic rather than over-optimistic) and that the E2E Path ADSPEC be corrected as soon as possible. In the example described above, this would mean that as soon as the Deaggregator receives the E2E Resv from the receiver, the Deaggregator should generate another E2E Path with an accurately updated ADSPEC based on the knowledge of which aggregate reservation will actually carry the E2E flow.
认识到并非所有情况下都能完全准确地更新E2E路径ADSPEC，我们建议在这种情况下采取保守的方法（过于悲观而不是过于乐观），并尽快纠正E2E路径ADSPEC。在上面描述的示例中，这将意味着，一旦解集器从接收器接收到E2E Resv，解集器就应该基于哪个聚合保留将实际承载E2E流的知识生成具有准确更新的ADSPEC的另一个E2E路径。
RSVP directly handles route changes, in that reservations follow the routes that their data follow. This follows from the property that Path messages contain the same IP source and destination address as the data flow for which a reservation is to be established. However, since we are now making aggregate reservations by sending a Path message from an aggregating to a deaggregating router, the reserved (E2E) data packets no longer carry the same IP addresses as the relevant (aggregate) Path message. The issue becomes one of making sure that data packets for reserved flows follow the same path as the Path message that established Path state for the aggregate reservation. Several approaches are viable.
RSVP直接处理路由更改，因为预订遵循其数据遵循的路由。这源于Path消息包含与要为其建立保留的数据流相同的IP源和目标地址的属性。然而，由于我们现在通过从聚合路由器向解聚合路由器发送路径消息来进行聚合保留，因此保留（E2E）数据包不再携带与相关（聚合）路径消息相同的IP地址。问题在于确保保留流的数据包遵循与为聚合保留建立路径状态的路径消息相同的路径。有几种方法是可行的。
First, the data may be tunneled from aggregator to deaggregator, using technologies such as IP-in-IP tunnels, GRE tunnels, MPLS label-switched paths, and so on. These each have particular advantages, especially MPLS, which allows traffic engineering. They each also have some cost in link overhead and configuration complexity.
首先，可以使用诸如IP-in-IP隧道、GRE隧道、MPLS标签交换路径等技术将数据从聚合器隧道传输到解聚合器。每一种都有特定的优势，特别是MPLS，它允许流量工程。它们在链路开销和配置复杂性方面都有一定的成本。
If data is not tunneled, then we are depending on a characteristic of IP best metric routing , which is that if the route from A to Z includes the path from H to L, and the best metric route was chosen all along the way, then the best metric route was chosen from H to L. Therefore, an aggregate path message which crosses a given aggregator and deaggregator will of necessity use the best path between them.
如果数据没有隧道化，那么我们取决于IP最佳度量路由的一个特征，即如果从a到Z的路由包括从H到L的路径，并且始终选择最佳度量路由，那么最佳度量路由选择从H到L。因此，穿过给定聚合器和解聚合器的聚合路径消息必然会使用它们之间的最佳路径。
If this is a single path, the problem is solved. If it is a multi-path route, and the paths are of equal cost, then we are forced to determine, perhaps by measurement, what proportion of the traffic for a given E2E reservation is passing along each of the paths, and assure ourselves of sufficient bandwidth for the present use. A simple, though wasteful, way of doing this is to reserve the total capacity of the aggregate route down each path.
如果这是一条单独的路径，那么问题就解决了。如果它是多路径路由，并且路径具有相同的成本，那么我们被迫确定（可能通过测量）给定E2E预留的通信量在每个路径上所占的比例，并确保我们有足够的带宽用于当前使用。一种简单但浪费的方法是保留每条路径上聚合路由的总容量。
For this reason, we believe it is advantageous to use one of the above-mentioned tunneling mechanisms in cases where multiple equal-cost paths may exist.
因此，我们认为，在可能存在多条等成本路径的情况下，使用上述隧道机制之一是有利的。
The case of inter-domain routes differs somewhat from the intra-domain case just described. Specifically, best-path considerations do not apply, as routing is by a combination of routing policy and shortest AS path rather than simple best metric.
域间路由的情况与刚才描述的域内路由的情况有所不同。具体来说，最佳路径考虑不适用，因为路由是通过路由策略和最短路径的组合，而不是简单的最佳度量。
In the case of inter-domain routes, data traffic belonging to different E2E sessions (but the same aggregate session) may not enter an aggregation region via the same aggregator interface, and/or may not leave via the same deaggregator interface. It is possible that we could identify this occurrence in some central system which sees the reservation information for both of the apparent sessions, but it is not clear that we could determine a priori how much traffic went one way or the other apart from measurement.
在域间路由的情况下，属于不同E2E会话（但相同聚合会话）的数据流量可能不会通过相同的聚合器接口进入聚合区域，和/或可能不会通过相同的解聚合器接口离开。我们可能会在某些中央系统中发现这种情况，该系统会看到两个明显会话的保留信息，但不清楚我们是否可以先验地确定除了测量之外，有多少流量是单向的。
We simply note that this problem can occur and needs to be allowed for in the implementation. We recommend that each such E2E reservation be summed into its appropriate aggregate reservation, even though this involves over-reservation.
我们只是注意到这个问题可能会发生，并且需要在实现中考虑到这个问题。我们建议将每个E2E保留汇总为其适当的合计保留，即使这涉及超额保留。
Aggregating reservations for multicast sessions is significantly more complex than for unicast sessions. The first challenge is to construct a multicast tree for distribution of the aggregate Path messages which follows the same path as will be followed by the data packets for which the aggregate reservation is to be made. This is complicated by the fact that the path taken by a data packet may
聚合多播会话的保留要比单播会话复杂得多。第一个挑战是构造一个多播树来分发聚合路径消息，该消息遵循与要为其进行聚合保留的数据包所遵循的路径相同的路径。由于数据包所采用的路径可能会
depend on many factors such as its source address, the choice of shared trees or source-specific trees, and the location of a rendezvous point for the tree.
取决于许多因素，如源地址、共享树或源特定树的选择以及树的集合点位置。
Once the problem of distributing aggregate Path messages is solved, there are considerable problems in determining the correct amount of resources to reserve at each link along the multicast tree. Because of the amount of heterogeneity that may exist in an aggregate multicast reservation, it appears that it would be necessary to retain information about individual E2E reservations within the aggregation region to allocate resources correctly. Thus, we may end up with a complex set of procedures for forming aggregate reservations that do not actually reduce the amount of stored state significantly for multicast sessions.
一旦解决了分发聚合路径消息的问题，在确定沿多播树的每个链路上要保留的正确资源量方面就会有相当大的问题。由于聚合多播保留中可能存在大量的异构性，因此似乎有必要在聚合区域内保留关于单个E2E保留的信息以正确分配资源。因此，我们最终可能会遇到一组复杂的过程，用于形成聚合保留，但实际上不会显著减少多播会话的存储状态量。
As noted above, there are several aspects to RSVP state, and our approach for unicast aggregates all forms of state: classification, scheduling, and reservation state. One possible approach to multicast is to focus only on aggregation of classification and scheduling state, which are arguably the most important because of their impact on the forwarding path. That approach is the one described in the current draft.
如上所述，RSVP状态有几个方面，我们的单播方法聚合了所有形式的状态：分类、调度和保留状态。多播的一种可能方法是只关注分类和调度状态的聚合，因为它们对转发路径有影响，因此可以说是最重要的。这是目前草案中描述的方法。
Ideally, an aggregation scheme should be able to accommodate recursive aggregation, with aggregate reservations being themselves aggregated. Multi-level aggregation can be accomplished using the procedures described here and a simple extension to the protocol number swapping process.
理想情况下，聚合方案应该能够适应递归聚合，聚合保留本身就是聚合的。可以使用此处描述的过程和对协议号码交换过程的简单扩展来完成多级聚合。
We can consider E2E RSVP reservations to be at aggregation level 0. When we aggregate these reservations, we produce reservations at aggregation level 1. In general, level n reservations may be aggregated to form reservations at level n+1.
我们可以考虑E2E RSVP保留在聚合级别0。当我们聚合这些保留时，我们在聚合级别1生成保留。通常，n级保留可以聚合为n+1级保留。
When an aggregating router receives an E2E Path, it swaps the protocol number from RSVP to RSVP-E2E-IGNORE. In addition, it should write the aggregation level (1, in this case) in the 2 byte field that is present (and currently unused) in the router alert option. In general, a router which aggregates reservations at level n to create reservations at level n+1 will write the number n+1 in the router alert field. A router which deaggregates level n+1 reservations will examine all messages with IP protocol number RSVP-E2E-IGNORE but will process the message and swap the protocol number back to RSVP only in the case where the router alert field carries the number n+1. For any other value, the message is forwarded unchanged. Interior routers ignore all messages with IP protocol
当聚合路由器接收到E2E路径时，它将协议号从RSVP交换到RSVP-E2E-IGNORE。此外，它应该在路由器警报选项中存在（且当前未使用）的2字节字段中写入聚合级别（本例中为1）。通常，聚集n级保留以创建n+1级保留的路由器将在路由器警报字段中写入数字n+1。取消聚合n+1级保留的路由器将检查IP协议号为RSVP-E2E-IGNORE的所有消息，但仅在路由器警报字段包含n+1号的情况下，才会处理该消息并将协议号交换回RSVP。对于任何其他值，该消息将不加更改地转发。内部路由器使用IP协议忽略所有消息
number RSVP-E2E-IGNORE. Note that only a few bits of the 2 byte field in the option would be needed, given the likely number of levels of aggregation.
编号为RSVP-E2E-IGNORE。请注意，考虑到可能的聚合级别数，该选项中只需要2字节字段的几位。
For IPv6, certain values of the router alert "value" field are reserved. This specification requires IANA assignment of a small number of consecutive values for the purpose of recording the aggregation level.
对于IPv6，保留路由器警报“值”字段的某些值。本规范要求IANA分配少量连续值，以记录聚合级别。
There are a variety of issues that arise in the context of aggregation that would benefit from some form of explicit acknowledgment mechanism for RSVP messages. For example, it is possible to configure a set of routers such that an E2E Path of protocol type RSVP-E2E-IGNORE would be effectively "black-holed", if it never reached a router which was appropriately configured to act as a deaggregator. It could then travel all the way to its destination where it would probably be ignored due to its non-standard protocol number. This situation is not easy to detect. The aggregator can be sure this problem has not occurred if an aggregate PathErr message is received from the deaggregator (as described in detail below). It can also be sure there is no problem if an E2E Resv is received. However, the fact that neither of these events has happened may only mean that no receiver wishes to reserve resources for this session, or that an RSVP message loss occurred, or it may mean that the Path was black-holed. However, if a neighbor-to-neighbor acknowledgment mechanism existed, the aggregator would expect to receive an acknowledgment of the E2E Path from the deaggregator, and would interpret the lack of a response as an indication that a problem of configuration existed. It could then refrain from aggregating this particular session. We note that such a reliability mechanism has been proposed for RSVP in [RFC291] and propose that it be used here.
聚合环境中会出现各种问题，这些问题将受益于某种形式的RSVP消息的显式确认机制。例如，可以配置一组路由器，使得协议类型为RSVP-E2E-IGNORE的E2E路径如果从未到达适当配置为充当解聚器的路由器，则其将有效地“黑洞”。然后，它可以一直运行到它的目的地，在那里，由于它的非标准协议号，它可能会被忽略。这种情况不容易发现。如果从解聚集器接收到聚合PathErr消息（如下所述），则聚合器可以确保未发生此问题。如果收到E2E Resv，也可以确保没有问题。然而，这两个事件都没有发生这一事实可能只意味着没有接收者希望为此会话保留资源，或者发生了RSVP消息丢失，或者可能意味着路径被黑洞覆盖。然而，如果存在邻居到邻居确认机制，则聚合器将期望从解聚合器接收E2E路径的确认，并将缺少响应解释为存在配置问题的指示。然后，它可以避免聚合此特定会话。我们注意到[RFC291]中已经为RSVP提出了这种可靠性机制，并建议在此使用。
[RSVP] defines a hop-by-hop authentication and integrity check. The present specification allows use of this check on Aggregate RSVP messages and also preserves this check on E2E RSVP messages for E2E RSVP messages.
[RSVP]定义逐跳身份验证和完整性检查。本规范允许对聚合RSVP消息使用此检查，并且还为E2E RSVP消息保留对E2E RSVP消息的此检查。
Outside the Aggregation Region, any E2E RSVP message may contain an INTEGRITY object using a keyed cryptographic digest technique which assumes that RSVP neighbors share a secret. Because E2E RSVP messages are not processed by routers in the Aggregation Region, the Aggregator and Deaggregator appear as logical RSVP neighbors of each other. The Deaggregator is the Aggregator's Next Hop for E2E RSVP
在聚合区域之外，任何E2E RSVP消息都可能包含使用密钥加密摘要技术的完整性对象，该技术假定RSVP邻居共享一个秘密。由于E2E RSVP消息不由聚合区域中的路由器处理，因此聚合器和解聚合器显示为彼此的逻辑RSVP邻居。解聚集器是聚集器E2E RSVP的下一个跃点
messages while the Aggregator is the Deaggregator's Previous Hop. Consequently, INTEGRITY objects which may appear in E2E RSVP messages traversing the Aggregation Region are exchanged directly between the Aggregator and Deaggregator in a manner which is entirely transparent to the Interior routers. Thus, hop-by-hop integrity checking for E2E messages over the Aggregation Region requires that the Aggregator and Deaggregator share a secret. Techniques for establishing that secret are described in [INTEGRITY].
聚合器是解聚合器的上一个跃点时的消息。因此，以对内部路由器完全透明的方式在聚合器和解聚合器之间直接交换可能出现在穿过聚合区域的E2E RSVP消息中的完整性对象。因此，聚合区域上E2E消息的逐跳完整性检查要求聚合器和解聚合器共享一个秘密。[完整性]中描述了确定该秘密的技术。
Inside the Aggregation Region, any Aggregate RSVP message may contain an INTEGRITY object which assumes that the corresponding RSVP neighbors inside the Aggregation Region (e.g., Aggregator and Interior Router, two Interior Routers, Interior Router and Deaggregator) share a secret.
在聚合区域内，任何聚合RSVP消息可包含完整性对象，该对象假定聚合区域内的对应RSVP邻居（例如，聚合器和内部路由器、两个内部路由器、内部路由器和解聚合器）共享秘密。
Up to this point we have assumed that the aggregate reservation is established as a result of the establishment of E2E reservations from outside the aggregation region. It should be clear that alternative triggers are possible. As discussed in [RFC2998], an aggregate RSVP reservation can be used to manage bandwidth in a diff-serv cloud even if RSVP is not used end-to-end.
到目前为止，我们假设集合保留是由于集合区域之外的E2E保留的建立而建立的。应该清楚的是，替代触发器是可能的。如[RFC2998]中所述，即使未端到端使用RSVP，也可以使用聚合RSVP保留来管理区分服务云中的带宽。
The simplest example of an alternative configuration is the static configuration of an aggregated reservation for a certain amount for traffic from an ingress (aggregator) router to an egress (de-aggregator) router. This would have to be configured in at least the system originating the aggregate PATH message (the aggregator). The deaggregator could detect that the PATH message is directed to it, and could be configured to "turn around" such messages, i.e., it responds with a RESV back to the aggregator. Alternatively, configuration of the aggregate reservation could be performed at both the aggregator and the deaggregator. As before, an aggregate reservation is associated with a DSCP for the traffic that will use the reserved capacity.
替代配置的最简单示例是静态配置从入口（聚合器）路由器到出口（解聚合器）路由器的一定数量的流量的聚合保留。这必须至少在发起聚合路径消息的系统（聚合器）中配置。解聚集器可以检测到路径消息被定向到它，并且可以被配置为“扭转”此类消息，即，它用返回到聚集器的RESV进行响应。或者，可以在聚合器和解聚合器上执行聚合保留的配置。与前面一样，将使用保留容量的流量的聚合保留与DSCP相关联。
In the absence of E2E microflow reservations, the aggregator can use a variety of policies to set the DSCP of packets passing into the aggregation region, thus determining whether they gain access to the resources reserved by the aggregate reservation. These policies are a matter of local configuration, as usual for a device at the edge of a diffserv cloud.
在没有E2E微流保留的情况下，聚合器可以使用各种策略来设置传递到聚合区域的分组的DSCP，从而确定它们是否获得对由聚合保留保留的资源的访问。这些策略是本地配置的问题，就像diffserv云边缘的设备一样。
Note that the "aggregator" could even be a device such as a PSTN gateway which makes an aggregate reservation for the set of calls to another PSTN gateway (the deaggregator) across an intervening diff-serv region. In this case the reservation may be established in response to call signalling.
请注意，“聚合器”甚至可以是诸如PSTN网关之类的设备，其为跨越介入的区分服务区域到另一PSTN网关（解聚合器）的呼叫集进行聚合保留。在这种情况下，可以响应于呼叫信令来建立预约。
From the perspective of RSVP signalling and the handling of data packets in the aggregation region, these cases are equivalent to the case of aggregating E2E RSVP reservations. The only difference is that E2E RSVP signalling does not take place and cannot therefore be used as a trigger, so some additional knowledge is required in setting up the aggregate reservation.
从RSVP信令和聚合区域中数据分组的处理的角度来看，这些情况等同于聚合E2E RSVP保留的情况。唯一的区别是E2E RSVP信令不会发生，因此不能用作触发器，因此在设置聚合保留时需要一些额外的知识。
To implement aggregation, we define a number of elements of procedure.
为了实现聚合，我们定义了许多过程元素。
The very first event is the arrival of the E2E Path message at an exterior interface of an aggregator. Standard RSVP procedures [RSVP] are followed for this, including onto what set of interfaces the message should be forwarded. These interfaces comprise zero or more exterior interfaces and zero or more interior interfaces. (If the number of interior interfaces is zero, the router is not acting as an aggregator for this E2E flow.)
第一个事件是E2E Path消息到达聚合器的外部接口。为此，遵循标准RSVP程序[RSVP]，包括将消息转发到哪一组接口上。这些接口包括零个或多个外部接口和零个或多个内部接口。（如果内部接口的数量为零，则路由器不是此E2E流的聚合器。）
Service on exterior interfaces is handled as defined in [RSVP].
外部接口上的服务按照[RSVP]中的定义进行处理。
Service on interior interfaces is complicated by the fact that the message needs to be included in some aggregate reservation, but at this point it is not known which one, because the deaggregator is not known. Therefore, the E2E Path message is forwarded on the interior interface(s) using the IP Protocol number RSVP-E2E-IGNORE, but in every other respect identically to the way it would be sent by an RSVP router that was not performing aggregation.
内部接口上的服务很复杂，因为消息需要包含在一些聚合保留中，但此时不知道是哪一个，因为不知道解聚合器。因此，E2E路径消息使用IP协议号RSVP-E2E-IGNORE在内部接口上转发，但在所有其他方面与未执行聚合的RSVP路由器发送该消息的方式相同。
At this point, the E2E Path message traverses zero or more interior routers. Interior routers receive the E2E Path message on an interior interface and forward it on another interior interface. The Router Alert IP Option alerts interior routers to check internally, but they find that the IP Protocol is RSVP-E2E-IGNORE and the next hop interface is interior. As such, they simply forward it as a normal IP datagram.
此时，E2E Path消息将遍历零个或多个内部路由器。内部路由器在内部接口上接收E2E路径消息，并在另一个内部接口上转发该消息。路由器警报IP选项提醒内部路由器进行内部检查，但他们发现IP协议为RSVP-E2E-IGNORE，下一跳接口为内部。因此，它们只是将其作为普通IP数据报转发。
The E2E Path message finally arrives at a deaggregating router, which receives it on an interior interface and forwards it on an exterior interface. Again, the Router Alert IP Option alerts it to intercept the message, but this time the IP Protocol is RSVP-E2E-IGNORE and the next hop interface is an exterior interface.
E2E路径消息最终到达解聚集路由器，该路由器通过内部接口接收该消息，并通过外部接口转发该消息。同样，路由器警报IP选项提醒它拦截消息，但这次IP协议是RSVP-E2E-IGNORE，下一跳接口是外部接口。
Before forwarding the E2E Path towards the receiver, the Deaggregator should update its ADSPEC. This update is to reflect the impact of the aggregation region onto the QoS to be achieved E2E by the flow. Such information can be collected by the ADSPEC of Aggregate Path messages travelling from the Aggregator to the Deaggregator. Thus, to enable correct updating of the ADSPEC, a deaggregating router may wait as described below for the arrival of an aggregate Path before forwarding the E2E Path.
在向接收器转发E2E路径之前，解聚器应更新其ADSPEC。此更新是为了反映聚合区域对流要实现的QoS的影响。ADSPEC可以收集从聚合器到解聚合器的聚合路径消息。因此，为了能够正确更新ADSPEC，解聚集路由器可以如下所述在转发E2E路径之前等待聚集路径的到达。
When receiving the E2E Path, depending on the policy for mapping E2E reservation onto Aggregate Reservations, the Deaggregator may or may not be in a position to decide which DSCP the E2E flow for the processed E2E Path is going to be mapped onto, as described above. If the Deaggregator is in a position to know the mapping at this point, then the Deaggregator first checks that there is an Aggregate Path in place for the corresponding DSCP. If so, then the Deaggregator uses the ADSPEC of this Aggregate Path to update the ADSPEC of the E2E Path and then forwards the E2E Path towards the receiver. If not, then the Deaggregator requests establishment of the corresponding Aggregate Path by sending an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED and the desired DSCP encoded in the DCLASS Object. The Deaggregator may also at the same time request establishment of an aggregate reservation for other DSCPs. When receiving the Aggregate Path for the desired DSCP, the Deaggregator then uses the ADSPEC of this Aggregate Path to update the ADSPEC of the E2E Path.
当接收到E2E路径时，取决于用于将E2E保留映射到聚合保留的策略，解聚集器可能处于或可能不处于决定用于处理的E2E路径的E2E流将映射到哪个DSCP的位置，如上所述。如果解聚集器此时能够知道映射，则解聚集器首先检查是否存在相应DSCP的聚合路径。如果是，则解聚集器使用该聚合路径的ADSPEC来更新E2E路径的ADSPEC，然后将E2E路径转发给接收机。如果没有，则解聚集器通过发送E2E PathErr消息请求建立相应的聚合路径，该消息包含错误代码NEW-Aggregate-NEEDED和DCLASS对象中编码的所需DSCP。解聚集器还可以同时请求为其他DSCP建立聚集保留。当接收到所需DSCP的聚合路径时，解聚合器随后使用该聚合路径的ADSPEC来更新E2E路径的ADSPEC。
If the Deaggregator is not in a position to know the mapping at this point, then the Deaggregator uses the information contained in the ADSPEC of one Aggregate Path or of multiple Aggregate Paths to update the E2E Path ADSPEC. Similarly, if one or more of the necessary Aggregate Paths is not yet established, the Deaggregator requests establishment of the corresponding Aggregate Path by sending an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED and the desired DSCP encoded in the respective DCLASS Object. When receiving the Aggregate Path for the desired DSCP, the Deaggregator then uses the ADSPEC of this Aggregate Path to update the ADSPEC of the E2E Path.
如果解聚集器此时无法知道映射，则解聚集器使用一条聚合路径或多条聚合路径的ADSPEC中包含的信息来更新E2E路径ADSPEC。类似地，如果一个或多个必要的聚合路径尚未建立，则解聚合器通过发送带有错误代码NEW-Aggregate-NEEDED和在相应DCLASS对象中编码的期望DSCP的E2E PathErr消息来请求建立相应的聚合路径。当接收到所需DSCP的聚合路径时，解聚合器随后使用该聚合路径的ADSPEC来更新E2E路径的ADSPEC。
Generating a E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED should not result in any Path state being removed, but should result in the aggregating router initiating the necessary aggregate Path message, as described in the following section.
生成错误代码为NEW-AGGREGATE-NEEDED的E2E PathErr消息不应导致任何路径状态被删除，但应导致聚合路由器启动必要的聚合路径消息，如以下部分所述。
The deaggregating router changes the E2E Path message's IP Protocol from RSVP-E2E-IGNORE to RSVP and forwards the E2E Path message towards its intended destination.
解聚集路由器将E2E路径消息的IP协议从RSVP-E2E-IGNORE更改为RSVP，并将E2E路径消息转发到其预期目的地。
The aggregating Router is responsible for generating a new Aggregate Path for a DSCP when receiving a E2E PathErr message with the error code NEW-AGGREGATE-NEEDED from the deaggregator. The DSCP value to include in the Aggregate Path Session is found in the DCLASS Object of the received E2E PathErr message. The identity of the deaggregator itself is found in the ERROR SPECIFICATION of the E2E PathErr message. The destination address of the aggregate Path message is the address of the deaggregating router, and the message is sent with IP protocol number RSVP.
当从解聚集器接收到错误代码为new-Aggregate-Required的E2E PathErr消息时，聚合路由器负责为DSCP生成新的聚合路径。要包含在聚合路径会话中的DSCP值位于收到的E2E PathErr消息的DCLASS对象中。解聚集器本身的标识可在E2E PathErr消息的错误规范中找到。聚合路径消息的目标地址是解聚合路由器的地址，该消息使用IP协议号RSVP发送。
Existing RSVP procedures specify that the size of a reservation established for a flow is set to the minimum of the Path SENDER_TSPEC and the Resv FLOW_SPEC. Consequently, the size of an Aggregate Reservation cannot be larger than the SENDER_TSPEC included in the Aggregate Path by the Aggregator. To ensure that Aggregate Reservations can be sized by the Deaggregator without undesired limitations, the Aggregating router should always attempt to include in the Aggregate Path a SENDER_TSPEC which is at least as large as the size that would actually be required as determined by the Deaggregator. One method to achieve this is to use a SENDER_TSPEC which is obviously larger than the highest load of E2E reservations that may be supported onto this network. Another method is for the Aggregator to keep track of which flows are mapped onto a DSCP and always add their E2E Path SENDER_TSPEC into the Aggregate Path SENDER_TSPEC (and possibly also add some additional bandwidth in anticipation of future E2E reservations).
现有RSVP过程指定为流建立的保留的大小设置为路径发送方\u TSPEC和Resv流\u SPEC的最小值。因此，聚合保留的大小不能大于聚合器在聚合路径中包含的发送方\u TSPEC。为了确保解聚集器可以调整聚合保留的大小而不受不希望的限制，聚合路由器应始终尝试在聚合路径中包含至少与解聚集器确定的实际需要的大小一样大的发送者_TSPEC。实现这一点的一种方法是使用发送方_TSPEC，该发送方_TSPEC明显大于此网络上可能支持的E2E保留的最高负载。另一种方法是聚合器跟踪哪些流映射到DSCP，并始终将其E2E路径发送器_TSPEC添加到聚合路径发送器_TSPEC中（并且可能还添加一些额外带宽，以预期未来E2E保留）。
The aggregating router is notified of the mapping from an E2E flow to a DSCP in two ways. First, when the aggregating router receives a E2E PathErr with error code NEW-AGGREGATE-NEEDED, the Aggregator is notified that the corresponding E2E flow is (at least temporarily) mapped onto a given DSCP. Secondly, when the aggregating router receives an E2E Resv containing a DCLASS Object (as described further below), the Aggregating Router is notified that the corresponding E2E flow is mapped onto a given DSCP.
聚合路由器通过两种方式被通知从E2E流到DSCP的映射。首先，当聚合路由器接收到错误代码为NEW-AGGREGATE-NEEDED的E2E路径错误时，聚合器被通知相应的E2E流（至少暂时）映射到给定的DSCP上。其次，当聚合路由器接收到包含DCLASS对象的E2E Resv时（如下所述），聚合路由器被通知相应的E2E流映射到给定的DSCP。
Having sent the E2E Path message on toward the destination, the deaggregator must now expect to receive an E2E Resv for the session. On receipt, its responsibility is to ensure that there is sufficient bandwidth reserved within the aggregation region to support the new E2E reservation, and if there is, then to forward the E2E Resv to the aggregating router.
在向目的地发送E2E Path消息之后，解聚集器现在必须期望接收会话的E2E Resv。收到后，其责任是确保在聚合区域内保留足够的带宽以支持新的E2E保留，如果有，则将E2E Resv转发给聚合路由器。
The Deaggregating router first makes the final decision of which Aggregate Reservation (and thus which DSCP) this E2E reservation is to be mapped onto. This decision is made according to the policy selected by the network administrator as described above.
解聚集路由器首先决定将E2E保留映射到哪个聚集保留（以及哪个DSCP）。此决定是根据网络管理员如上所述选择的策略作出的。
If this final mapping decision is such that the Deaggregator can now make a more accurate update of the E2E Path ADSPEC than done when forwarding the initial E2E Path, the Deaggregator should do so and generate a new E2E Path immediately in order to provide the accurate ADSPEC information to the receiver as soon as possible. Otherwise, normal Refresh procedures should be followed for the E2E Path.
如果该最终映射决策使得解聚器现在可以比转发初始E2E路径时更准确地更新E2E路径ADSPEC，则解聚器应该这样做并立即生成新的E2E路径，以便尽快向接收机提供准确的ADSPEC信息。否则，E2E路径应遵循正常刷新程序。
If no Aggregate Reservation currently exists from the corresponding aggregating router with the corresponding DSCP, the Deaggregating router will establish a new Aggregate Reservation as described in the next section.
如果当前不存在来自具有相应DSCP的相应聚合路由器的聚合保留，则解聚合路由器将建立新的聚合保留，如下一节所述。
If the corresponding Aggregate Reservation exists but has insufficient bandwidth reserved to accommodate the new E2E reservation (in addition to all the existing E2E reservations currently mapped onto it), it should follow the normal RSVP procedures [RSVP] for a reservation being placed with insufficient bandwidth to support the reservation. It may also first attempt to increase the aggregate reservation that is supplying bandwidth by increasing the size of the FLOW_SPEC that it includes in the aggregate Resv that it sends upstream. As discussed in the previous section, the Aggregating Router should ensure that the SENDER_TSPEC it includes in the Aggregate Path is always in excess of the FLOW_SPEC that may be requested in the Aggregate Resv by the Deaggregator, so that the Deaggregator is not unnecessarily prevented from effectively increasing the Aggregate Reservation bandwidth as required.
如果存在相应的聚合保留，但保留的带宽不足，无法容纳新的E2E保留（除了当前映射到它的所有现有E2E保留之外），则对于带宽不足的保留，它应该遵循正常的RSVP过程[RSVP]。它还可以首先尝试通过增加它在向上游发送的聚合Resv中包括的流规格的大小来增加提供带宽的聚合保留。如前一节所述，聚合路由器应确保其包含在聚合路径中的发送方规格始终超过反聚合器在聚合Resv中可能请求的流量规格，这样就不会不必要地阻止解聚集器根据需要有效地增加聚合保留带宽。
When sufficient bandwidth is available on the corresponding aggregate reservation, the Deaggregating Router may simply send the E2E Resv message with IP Protocol RSVP to the aggregating router. This message should include the DCLASS object to indicate which DSCP the aggregator must use for this E2E flow. The deaggregator will also
当相应的聚合预留上有足够的带宽可用时，解聚合路由器可以简单地将具有IP协议RSVP的E2E Resv消息发送到聚合路由器。此消息应包括DCLASS对象，以指示聚合器必须为此E2E流使用哪个DSCP。解聚器也将
add the token bucket from the E2E Resv FLOWSPEC object into its internal understanding of how much of the Aggregate reservation is in use.
将E2E Resv FLOWSPEC对象中的令牌桶添加到其内部对使用了多少聚合保留的理解中。
As discussed above, in order to minimize the occurrence of situations where insufficient bandwidth is reserved on the corresponding Aggregate Reservation at the time of processing an E2E Resv, and in turn to avoid the delay associated with the increase of this aggregate bandwidth, the Deaggregator MAY anticipate the current demand and increase the Aggregate Reservations size ahead of actual requirements by E2E reservations.
如上所述，为了最小化在处理E2E Resv时在相应的聚合保留上保留的带宽不足的情况的发生，并进而避免与该聚合带宽的增加相关联的延迟，解集器可预测当前需求，并通过E2E预订提前实际需求增加总预订量。
Upon receiving an E2E Resv message on an exterior interface, and having determined the appropriate DSCP for the session according to the mapping policy, the Deaggregator looks for the corresponding path state for a session with the chosen DSCP. If aggregate Path state exists, but no aggregate Resv state exists, the Deaggregator creates a new aggregate Resv.
在外部接口上接收到E2E Resv消息并根据映射策略确定了会话的适当DSCP后，解聚集器将查找具有所选DSCP的会话的相应路径状态。如果存在聚合路径状态，但不存在聚合Resv状态，则解聚集器将创建新的聚合Resv。
If no aggregate Path state exists for the appropriate DSCP, this may be because the Deaggregator could not decide earlier the final mapping for this E2E flow and elected to not establish Aggregate Path state for all DSCPs. In that case, the Deaggregator should request establishment of the corresponding Aggregate Path by sending a E2E PathErr with error code of NEW-AGGREGATE-NEEDED and with a DCLASS containing the required DSCP. This will trigger the Aggregator to establish the corresponding Aggregate Path. Once the Deaggregator has determined that the aggregate Path state is established, it creates a new Aggregate Resv.
如果适当的DSCP不存在聚合路径状态，这可能是因为解聚合器无法提前决定此E2E流的最终映射，并选择不为所有DSCP建立聚合路径状态。在这种情况下，解聚集器应通过发送错误代码为NEW-Aggregate-NEEDED的E2E PathErr和包含所需DSCP的DCLASS，请求建立相应的聚合路径。这将触发聚合器建立相应的聚合路径。一旦解聚集器确定已建立聚合路径状态，它将创建新的聚合Resv。
The FLOW_SPEC of the new Aggregate Resv is set to a value not smaller than the requirement of the E2E reservation it is supporting. The Aggregate Resv is sent toward the aggregator (i.e., to the previous hop), using the AGGREGATED-RSVP session and filter specifications defined below. Since the DSCP is in the SESSION object, no DCLASS object is necessary. The message should be reliably delivered using the mechanisms in [RFC2961] or, alternatively, the CONFIRM object may be used, to assure that the aggregate Resv does indeed arrive and is granted. This enables the deaggregator to determine that the requested bandwidth is available to allocate to the E2E flows it supports.
新聚合Resv的流量规格设置为不小于其支持的E2E预留要求的值。使用下面定义的AGGREGATED-RSVP会话和筛选器规范，将聚合Resv发送到聚合器（即上一跳）。由于DSCP位于会话对象中，因此不需要DCLASS对象。应该使用[RFC2961]中的机制可靠地传递消息，或者可以使用确认对象，以确保聚合Resv确实到达并被授予。这使得解聚集器能够确定请求的带宽可用于分配给其支持的E2E流。
In order to minimize the occurrence of situations where no corresponding Aggregate Reservation is established at the time of processing an E2E Resv, and in turn to avoid the delay associated with the creation of this aggregate reservation, the Deaggregator MAY
为了最大限度地减少在处理E2E Resv时没有建立相应的聚集保留的情况的发生，并进而避免与创建该聚集保留相关联的延迟，解聚集器可以
anticipate the current demand and create the Aggregate Reservation before receiving E2E Resv messages requiring bandwidth on those aggregate reservations.
在接收E2E Resv消息之前，预测当前需求并创建聚合预订，这些消息需要这些聚合预订上的带宽。
The aggregate Resv message is handled in essentially the same way as defined in [RSVP]. The Session object contains the address of the deaggregating router (or the group address for the session in the case of multicast) and the DSCP that has been chosen for the session. The Filterspec object identifies the aggregating router. These routers perform admission control and resource allocation as usual and send the aggregate Resv on towards the aggregator.
聚合Resv消息的处理方式与[RSVP]中定义的方式基本相同。会话对象包含解聚集路由器的地址（或在多播情况下会话的组地址）和为会话选择的DSCP。Filterspec对象标识聚合路由器。这些路由器像往常一样执行准入控制和资源分配，并向聚合器发送聚合Resv。
The receipt of the E2E Resv message with a DCLASS Object is the final confirmation to the aggregating router of the mapping of the E2E reservation onto an Aggregate Reservation. Under normal circumstances, this is the only way it will be informed of this association. It should now forward the E2E Resv to its previous hop, following normal RSVP processing rules [RSVP].
接收带有DCLASS对象的E2E Resv消息是向聚合路由器确认E2E保留映射到聚合保留的最终确认。在正常情况下，这是唯一一种通知该协会的方式。它现在应该按照正常的RSVP处理规则[RSVP]，将E2E Resv转发到其上一个跃点。
E2E reservations are removed in the usual way via PathTear, ResvTear, timeout, or as the result of an error condition. When they are removed, their FLOWSPEC information must also be removed from the allocated portion of the aggregate reservation. This same bandwidth may be re-used for other traffic in the near future. When E2E Path messages are removed, their SENDER_TSPEC information must also be removed from the aggregate Path.
E2E保留是通过PathTear、ResvTear、timeout或作为错误条件的结果以通常的方式删除的。当它们被删除时，它们的FLOWSPEC信息也必须从聚合保留的分配部分中删除。在不久的将来，同样的带宽可能会被重新用于其他业务。删除E2E Path消息时，还必须从聚合路径中删除其发送者\u TSPEC信息。
Should an aggregate reservation go away (presumably due to a configuration change, route change, or policy event), the E2E reservations it supports are no longer active. They must be treated accordingly.
如果聚合保留消失（可能是由于配置更改、路由更改或策略事件），则其支持的E2E保留将不再处于活动状态。它们必须得到相应的对待。
Prior to establishment that a given E2E flow is part of a given aggregate, the flow's data should be treated as traffic without a reservation by whatever policies prevail for such. Generally, this will mean being given the same forwarding behavior as best effort traffic. However, upon establishing that the flow belongs to a given aggregate, the aggregating router is responsible for marking any
在确定给定的E2E流是给定聚合的一部分之前，该流的数据应被视为流量，而不受任何政策的限制。通常，这将意味着被赋予与尽力而为流量相同的转发行为。但是，一旦确定流属于给定的聚合，聚合路由器负责标记任何流
related traffic with the correct DSCP and forwarding it in the manner appropriate to traffic on that reservation. This may imply forwarding it to a given IP next hop, or piping it down a given link layer circuit, tunnel, or MPLS label switched path.
使用正确的DSCP关联流量，并以适合该保留上的流量的方式转发。这可能意味着将其转发到给定的IP下一跳，或沿给定的链路层电路、隧道或MPLS标签交换路径进行管道传输。
The aggregator is responsible for performing per-reservation policing on the E2E flows that it is aggregating. The aggregator performs metering of traffic belonging to each reservation to assess compliance to the token bucket for the corresponding E2E reservation. Packets which are assessed in compliance are forwarded as mentioned above. Packets which are assessed out of compliance must be either dropped, reshaped or marked to a different DSCP. The detailed policing behavior is an aspect of the service mapping described in [RFC2998].
聚合器负责对其正在聚合的E2E流执行每保留策略。聚合器对属于每个保留的流量进行计量，以评估对相应E2E保留的令牌桶的遵从性。如上文所述，对符合性进行评估的数据包进行转发。被评估为不合规的数据包必须丢弃、重塑或标记到不同的DSCP。详细的策略行为是[RFC2998]中描述的服务映射的一个方面。
Because of the difficulties of aggregating multicast sessions described above, we focus on the aggregation of scheduling and classification state in the multicast case. The main difference between the multicast and unicast cases is that rather than sending an aggregate Path message to the unicast address of a single deaggregating router, in the multicast case we send the "aggregate" Path message to the same group address as the E2E session. This ensures that the aggregate Path message follows the same route as the E2E Path. This difference between unicast and multicast is reflected in the Session objects defined below. A consequence of this approach is that we continue to have reservation state per multicast session inside the aggregation region.
由于上述聚合多播会话的困难，我们重点研究了多播情况下调度和分类状态的聚合。多播和单播情况之间的主要区别在于，在多播情况下，我们将“聚合”路径消息发送到与E2E会话相同的组地址，而不是将聚合路径消息发送到单个解聚合路由器的单播地址。这确保聚合路径消息遵循与E2E路径相同的路由。单播和多播之间的这种差异反映在下面定义的会话对象中。这种方法的一个结果是，我们在聚合区域内的每个多播会话中继续保持保留状态。
A further challenge arises in multicast sessions with heterogeneous receivers. Consider an interior router which must forward packets for a multicast session on two interfaces, but has only received a reservation request on one of those interfaces. It receives packets marked with the DSCP chosen for the aggregate reservation. When sending them out the interface which has no installed reservation, it has the following options:
另一个挑战出现在具有异构接收器的多播会话中。考虑内部路由器，它必须在两个接口上转发多播会话的分组，但仅在这些接口中的一个接收到保留请求。它接收标记有为聚合保留选择的DSCP的数据包。当将它们发送到没有安装保留的接口时，它有以下选项：
a) remark those packets to best effort before sending them out the interface;
a) 在将数据包发送到接口之前，尽最大努力标注这些数据包；
b) send the packets out the interface with the DSCP chosen for the aggregate reservation.
b) 使用为聚合保留选择的DSCP将数据包发送出接口。
The first approach suffers from the drawback that it requires nMF classification at an interior router in order to recognize the flows whose packets must be demoted. The second approach requires over-reservation of resources on the interface on which no reservation was
第一种方法的缺点是需要在内部路由器上进行nMF分类，以便识别其数据包必须降级的流。第二种方法要求在没有保留的接口上过度保留资源
received. In the absence of such over-reservation, the packets sent with the "wrong" DSCP would be able to degrade the service experienced by packets using that DSCP legitimately.
收到。在没有这种过度保留的情况下，使用“错误”DSCP发送的数据包将能够降低合法使用该DSCP的数据包所经历的服务。
To make MF classification acceptable in an interior router, it may be possible to treat the case of heterogeneous flows as an exception. That is, an interior router only needs to be able to recognize those individual microflows that have heterogeneous resource needs on the outbound interfaces of this router.
为了使MF分类在内部路由器中可接受，可以将异构流的情况视为例外。也就是说，内部路由器只需要能够识别在该路由器的出站接口上具有异构资源需求的单个微流。
This specification requires the assignment of a protocol type RSVP-E2E-IGNORE, whose number is at this point 134. This is used only on E2E messages which require a router alert (Path, PathTear, and ResvConf), and signifies that the message must be treated one way when destined to an interior interface, and another way when destined to an exterior interface. The protocol type is swapped by the Aggregator from RSVP to RSVP-E2E-IGNORE in E2E Path, PathTear, and ResvConf messages when they enter the Aggregation Region. The protocol type is swapped back by the Deaggregator from RSVP-E2E-IGNORE to RSVP in such E2E messages when they exit the Aggregation Region.
本规范要求分配协议类型RSVP-E2E-IGNORE，其编号为134。这仅用于需要路由器警报（Path、PATHTRARE和ResvConf）的E2E消息，表示消息在发送到内部接口时必须以一种方式处理，在发送到外部接口时必须以另一种方式处理。当E2E Path、PATHTRARE和ResvConf消息进入聚合区域时，聚合器将协议类型从RSVP交换到E2E Path、PATHTRARE和ResvConf消息中的RSVP-E2E-IGNORE。当退出聚合区域时，协议类型由解聚合器在此类E2E消息中从RSVP-E2E-IGNORE交换回RSVP。
A PathErr code NEW-AGGREGATE-NEEDED is required. This value does not signify that a fatal error has occurred, but that an action is required of the aggregating router to avoid an error condition in the near future.
需要一个PathErr代码NEW-AGGREGATE-NEEDED。此值并不表示发生了致命错误，但需要聚合路由器采取措施以避免在不久的将来出现错误情况。
The SESSION object contains two values: the IP Address of the aggregate session destination, and the DSCP that it will use on the E2E data the reservation contains. For unicast sessions, the session destination address is the address of the deaggregating router. For multicast sessions, the session destination is the multicast address of the E2E session (or sessions) being aggregated. The inclusion of the DSCP in the session allows for multiple sessions toward the same address to be distinguished by their DSCP and queued separately. It also provides the means for aggregating scheduling and classification state. In the case where a session uses a pair of PHBs (e.g., AF11 and AF12), the DSCP used should represent the numerically smallest PHB (e.g., AF11). This follows the same naming convention described in [BRIM].
会话对象包含两个值：聚合会话目标的IP地址，以及它将在保留包含的E2E数据上使用的DSCP。对于单播会话，会话目标地址是解聚集路由器的地址。对于多播会话，会话目的地是正在聚合的E2E会话的多播地址。会话中包含DSCP允许通过其DSCP区分朝向同一地址的多个会话，并单独排队。它还提供了聚合调度和分类状态的方法。在会话使用一对PHB（例如AF11和AF12）的情况下，使用的DSCP应表示数值上最小的PHB（例如AF11）。这与[BRIM]中描述的命名约定相同。
Session types are defined for IPv4 and IPv6 addresses.
为IPv4和IPv6地址定义了会话类型。
o IP4 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP4
o IP4会话对象：Class=SESSION，C-Type=RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
o IP6 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP6
o IP6会话对象：Class=SESSION，C-Type=RSVP-AGGREGATE-IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Session Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Session Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
The SENDER_TEMPLATE object identifies the aggregating router for the aggregate reservation.
SENDER_TEMPLATE对象标识聚合保留的聚合路由器。
o IP4 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE, C-Type = RSVP-AGGREGATE-IP4
o IP4发送方\模板对象：类=发送方\模板，C-Type=RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
o IP6 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE, C-Type = RSVP-AGGREGATE-IP6
o IP6发送方\模板对象：类=发送方\模板，C-Type=RSVP-AGGREGATE-IP6
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Aggregator Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 Aggregator Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
The FILTER_SPEC object identifies the aggregating router for the aggregate reservation, and is syntactically identical to the SENDER_TEMPLATE object.
FILTER_SPEC对象标识聚合保留的聚合路由器，在语法上与SENDER_TEMPLATE对象相同。
4. Policies and Algorithms For Predictive Management Of Blocks Of Bandwidth
4. 带宽块预测管理的策略和算法
The exact policies used in determining how much bandwidth should be allocated to an aggregate reservation at any given time are beyond the scope of this document, and may be proprietary to the service provider in question. However, here we explore some of the issues and suggest approaches.
用于确定在任何给定时间应为聚合预订分配多少带宽的确切策略超出了本文档的范围，可能是相关服务提供商的专有策略。然而，在这里，我们将探讨一些问题并提出解决方法。
In short, the ideal condition is that the aggregate reservation always has enough resources to allocate to any E2E reservation that requires its support, and never takes too much. Simply stated, but more difficult to achieve. Factors that come into account include significant times in the diurnal cycle: one may find that a large number of people start placing calls at 8:00 AM, even though the hour from 7:00 to 8:00 is dead calm. They also include recent history: if more people have been placing calls recently than have been finishing them, a prediction of the necessary bandwidth a few moments hence may call for more bandwidth than is currently allocated. Likewise, at the end of a busy period, we may find that the trend calls for declining reservation amounts.
简言之，理想的条件是聚合保留始终有足够的资源分配给任何需要其支持的E2E保留，并且不会占用太多资源。简单地说，但更难实现。考虑到的因素包括白天周期中的重要时间：人们可能会发现，许多人从早上8点开始打电话，即使从7:00到8:00的时间非常平静。它们还包括最近的历史记录：如果最近打电话的人比完成电话的人多，那么对必要带宽的预测可能需要比当前分配的带宽更多的带宽。同样，在繁忙时期结束时，我们可能会发现趋势要求减少预订量。
We recommend a policy something along this line. At any given time, one should expect that the amount of bandwidth required for the aggregate reservation is the larger of the following:
我们建议采取类似的政策。在任何给定时间，人们都应该期望聚合预订所需的带宽量为以下两者中的较大值：
(a) a requirement known a priori, such as from history of the diurnal cycle at a particular week day and time of day, and
(a) 事先已知的要求，例如从特定星期日和一天中某个时间的日循环历史中，以及
(b) the trend line over recent history, with 90 or 99% statistical confidence.
(b) 最近历史的趋势线，具有90%或99%的统计置信度。
We further expect that changes to that aggregate reservation would be made no more often than every few minutes, and ideally perhaps on larger granularity such as fifteen minute intervals or hourly. The finer the granularity, the greater the level of signaling required, while the coarser the granularity, the greater the chance for error, and the need to recover from that error.
我们进一步预计，对该总预订的更改不会超过每几分钟一次，理想情况下可能是在更大的粒度上进行更改，如每15分钟一次或每小时一次。粒度越细，所需的信令级别就越高，而粒度越粗，出错的机会就越大，并且需要从错误中恢复。
In general, we expect that the aggregate reservation will not ever add up to exactly the sum of the reservations it supports, but rather will be an integer multiple of some block reservation size, which exceeds that value.
通常，我们期望聚合保留的总和永远不会精确到它所支持的保留的总和，而是某个块保留大小的整数倍，超过该值。
Numerous security issues pertain to this document; for example, the loss of an aggregate reservation to an aggressor causes many calls to operate unreserved, and the reservation of a great excess of bandwidth may result in a denial of service. However, these issues are not confined to this extension: RSVP itself has them. We believe that the security mechanisms in RSVP address these issues as well.
与本文件有关的许多安全问题；例如，丢失对攻击者的聚合保留会导致许多呼叫在无保留的情况下运行，而保留过多的带宽可能会导致拒绝服务。然而，这些问题并不局限于这个扩展：RSVP本身就有这些问题。我们认为，RSVP中的安全机制也解决了这些问题。
One security issue specific to RSVP aggregation involves the modification of the IP protocol number in RSVP Path messages that traverse an aggregation region. If that field were maliciously modified in a Path message, it would cause the message to be ignored by all subsequent devices on its path, preventing reservations from being made. It could even be possible to correct the value before it reached the receiver, making it difficult to detect the attack. In theory, it might also be possible for a node to modify the IP protocol number for non-RSVP messages as well, thus interfering with the operation of other protocols.
RSVP聚合特有的一个安全问题涉及修改穿过聚合区域的RSVP Path消息中的IP协议号。如果该字段在路径消息中被恶意修改，将导致该消息被其路径上的所有后续设备忽略，从而阻止进行保留。甚至可以在到达接收器之前纠正该值，从而使检测攻击变得困难。理论上，节点也可能修改非RSVP消息的IP协议号，从而干扰其他协议的操作。
One way to mitigate the risks of malicious modification of the IP protocol number is to use an IPSEC authentication header, which would ensure that malicious modification of the IP header is detected. This is a desirable approach but imposes some administrative burden in the form of key management for authentication purposes.
减轻恶意修改IP协议编号风险的一种方法是使用IPSEC身份验证标头，这将确保检测到对IP标头的恶意修改。这是一种理想的方法，但出于身份验证目的，以密钥管理的形式增加了一些管理负担。
It is RECOMMENDED that implementations of this specification only support modification of the IP protocol number for RSVP Path, PathTear, and ResvConf messages. That is, a general facility for modification of the IP protocol number SHOULD NOT be made available.
建议本规范的实现仅支持修改RSVP Path、PATHTRARE和ResvConf消息的IP协议号。也就是说，不应提供修改IP协议编号的通用设施。
Network operators deploying routers with RSVP aggregation capability should be aware of the risks of inappropriate modification of the IP protocol number and should take appropriate steps (physical security, password protection, etc.) to reduce the risk that a router could be configured by an attacker to perform malicious modification of the protocol number.
部署具有RSVP聚合功能的路由器的网络运营商应意识到IP协议编号不适当修改的风险，并应采取适当措施（物理安全、密码保护等）降低攻击者配置路由器以恶意修改协议号的风险。
Section 1.2 proposes a new protocol type, RSVP-E2E-IGNORE, which is used to identify a message that routers in the network core will see; further processing of such messages may or may not be required, depending on the egress interface type, as described in Section 1.2. The IANA assigned IP protocol number 134, in accordance with [RFC2780], meeting the Standards Track publication criterion.
第1.2节提出了一种新的协议类型RSVP-E2E-IGNORE，用于识别网络核心路由器将看到的消息；如第1.2节所述，根据出口接口类型，可能需要也可能不需要进一步处理此类消息。IANA根据[RFC2780]分配IP协议编号134，符合标准轨道发布标准。
Section 1.4.9 describes the manner in which the Router Alert is used in the context of this specification, which is essentially a simple counter of the depth of nesting of aggregation. The IPv4 Router Alert [RFC2113] has the option simply to ask the router to look at the protocol type of the intercepted datagram and decide what to do with it; the parameter is additional information to that decision. The IPv6 Router Alert [RFC2711] turns the parameter into an option sub-type. As a result, the IPv6 router alert option may not be used algorithmically in the context of the protocol in question. The IANA assigned a block of 32 values (3-35, "Aggregated Reservation Nesting Level") which we may map to nesting depths 0..31, hoping that 32 levels is enough.
第1.4.9节描述了路由器警报在本规范上下文中的使用方式，它本质上是聚合嵌套深度的简单计数器。IPv4路由器警报[RFC2113]可以简单地要求路由器查看被截获数据报的协议类型，并决定如何处理它；该参数是该决策的附加信息。IPv6路由器警报[RFC2711]将参数转换为选项子类型。因此，IPv6路由器警报选项可能不会在相关协议的上下文中以算法方式使用。IANA分配了32个值的块（3-35，“聚合保留嵌套级别”），我们可以将其映射到嵌套深度0..31，希望32个级别就足够了。
Section 3.2 discusses a new, required path error code. The IANA has assigned RSVP Parameters Error Code 26 to NEW-AGGREGATE-NEEDED.
第3.2节讨论了一个新的、必需的路径错误代码。IANA已将RSVP参数错误代码26分配给NEW-AGGREGATE-NEEDED。
Sections 3.3, 3.4, and 3.5 describe extensions to three object classes: Session, Filter Specification, and Sender Template. The IANA has assigned two new common C-Types to be specified for the aggregator's address. RSVP-AGGREGATE-IP4 is C-Type 9 and RSVP-AGGREGATE-IP6 is C-Type 10. In adding these C-types to IANA RSVP Class Names, Class Numbers and Class Types registry, the same numbering for them is used in all three Classes, as is done for IPv4 and IPv6 address tuples in [RSVP].
第3.3、3.4和3.5节描述了对三个对象类的扩展：会话、筛选器规范和发送方模板。IANA已经为聚合器的地址指定了两个新的通用C类型。RSVP-AGGREGATE-IP4为C型9，RSVP-AGGREGATE-IP6为C型10。在将这些C类型添加到IANA RSVP类名、类号和类类型注册表时，所有三个类都使用相同的编号，就像[RSVP]中的IPv4和IPv6地址元组一样。
The authors acknowledge that published documents and discussion with several people, notably John Wroclawski, Steve Berson, and Andreas Terzis materially contributed to this document. The design is influenced by the RSVP tunnels document [TERZIS].
作者承认，发表的文件和与几个人的讨论，特别是约翰·沃克罗夫斯基、史蒂夫·贝尔森和安德烈亚斯·特齐斯，对本文件作出了重大贡献。设计受RSVP隧道文件[TERZIS]的影响。
APPENDIX 1: Example Signalling Flow For First E2E Flow
附录1：第一个E2E流的信号流示例
This Appendix does not provide additional specification. It only illustrates the specification detailed above through a possible flow of RSVP signalling messages involved in the successful establishment of a unicast E2E reservation which is the first between a given pair of Aggregator/Deaggregator.
本附录不提供其他规范。它仅通过成功建立单播E2E预约所涉及的RSVP信令消息的可能流来说明上面详述的规范，单播E2E预约是给定一对聚合器/解聚合器之间的第一个预约。
Aggregator Deaggregator
聚合器-解聚器
E2E Path
---------------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed, DCLASS=x)
<-------------------------------
E2E PathErr(New-agg-needed, DCLASS=y)
<-------------------------------
(3)
AggPath(DSCP=x)
------------------------------->
AggPath(DSCP=y)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (DSCP=x)
<-------------------------------
AggResv (DSCP=y)
<-------------------------------
(6)
AggResvConfirm (DSCP=x)
------------------------------>
AggResvConfirm (DSCP=y)
------------------------------>
(7)
E2E Resv
<----------
(8)
E2E Resv (DCLASS=x)
<-----------------------------
(9)
E2E Resv
<---------------
E2E Path
---------------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed, DCLASS=x)
<-------------------------------
E2E PathErr(New-agg-needed, DCLASS=y)
<-------------------------------
(3)
AggPath(DSCP=x)
------------------------------->
AggPath(DSCP=y)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (DSCP=x)
<-------------------------------
AggResv (DSCP=y)
<-------------------------------
(6)
AggResvConfirm (DSCP=x)
------------------------------>
AggResvConfirm (DSCP=y)
------------------------------>
(7)
E2E Resv
<----------
(8)
E2E Resv (DCLASS=x)
<-----------------------------
(9)
E2E Resv
<---------------
(1) Aggregator forwards E2E Path into aggregation region after modifying its IP Protocol Number to RSVP-E2E-IGNORE
(1) 聚合器将其IP协议号修改为RSVP-E2E-IGNORE后，将E2E路径转发到聚合区域
(2) Let's assume no Aggregate Path exists. To be able to accurately update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC of Aggregate PATH. In this example the Deaggregator elects to instruct the Aggregator to set up Aggregate Path states for the two supported DSCPs by sending a New-Agg-Needed PathErr code for each DSCP.
(2) 假设不存在聚合路径。为了能够准确地更新E2E路径的ADSPEC，解聚集器需要聚合路径的ADSPEC。在此示例中，解聚合器选择指示聚合器为两个受支持的DSCP设置聚合路径状态，方法是为每个DSCP发送新的Agg所需的PathErr代码。
(3) The Aggregator follows the request from the Deaggregator and signals an Aggregate Path for both DSCPs.
(3) 聚合器跟踪来自解聚合器的请求，并向两个DSCP发送聚合路径信号。
(4) The Deaggregator takes into account the information contained in the ADSPEC from both Aggregate Path and updates the E2E Path ADSPEC accordingly. The Deaggregator also modifies the E2E Path IP Protocol Number to RSVP before forwarding it.
(4) 解聚集器考虑来自聚合路径的ADSPEC中包含的信息，并相应地更新E2E路径ADSPEC。在转发之前，解聚集器还将E2E路径IP协议号修改为RSVP。
(5) In this example, the Deaggregator elects to immediately proceed with establishment of Aggregate Reservations for both DSCPs. In effect, the Deaggregator can be seen as anticipating the actual demand of E2E reservations so that resources are available on Aggregate Reservations when the E2E Resv requests arrive in order to speed up establishment of E2E reservations. Assume also that the Deaggregator includes the optional Resv Confirm Request in these Aggregate Resv.
(5) 在此示例中，解聚集器选择立即为两个DSCP建立聚集保留。实际上，可以将解聚集器视为预测E2E预订的实际需求，以便在E2E Resv请求到达时，可以在聚合预订上使用资源，以加快E2E预订的建立。还假设解聚集器在这些聚合Resv中包含可选的Resv确认请求。
(6) The Aggregator merely complies with the received ResvConfirm Request and returns the corresponding Aggregate ResvConfirm.
(6) 聚合器仅遵守收到的ResvConfig请求并返回相应的聚合ResvConfig。
(7) The Deaggregator has explicit confirmation that both Aggregate Resv are established.
(7) 解聚集器已明确确认两个聚合Resv均已建立。
(8) On receipt of the E2E Resv, the Deaggregator applies the mapping policy defined by the network administrator to map the E2E Resv onto an Aggregate Reservation. Let's assume that this policy is such that the E2E reservation is to be mapped onto the Aggregate Reservation with DSCP=x. The Deaggregator knows that an Aggregate Reservation is in place for the corresponding DSCP since (7). The Deaggregator performs admission control of the E2E Resv onto the Aggregate Resv for DSCP=x. Assuming that the Aggregate Resv for DSCP=x had been established with sufficient bandwidth to support the E2E Resv, the Deaggregator adjusts its counter tracking the unused bandwidth on the Aggregate Reservation and forwards the E2E Resv to the Aggregator including a DCLASS object conveying the selected mapping onto DSCP=x.
(8) 收到E2E Resv后，解聚集器应用网络管理员定义的映射策略将E2E Resv映射到聚合保留上。让我们假设此策略使得E2E保留映射到DSCP=x的聚合保留。解聚集器知道，自（7）起，已为相应的DSCP设置了聚集保留。解聚集器对DSCP=x的聚合Resv执行E2E Resv的接纳控制。假设DSCP=x的聚合Resv已建立，具有足够的带宽来支持E2E Resv，则解聚集器调整其计数器，跟踪聚合保留上未使用的带宽，并将E2E Resv转发给聚合器，包括将所选映射传送到DSCP=x的DCLASS对象。
(9) The Aggregator records the mapping of the E2E Resv onto DSCP=x. The Aggregator removes the DCLASS object and forwards the E2E Resv towards the sender.
(9) 聚合器记录E2E Resv到DSCP=x的映射。聚合器删除DCLASS对象并将E2E Resv转发给发送方。
APPENDIX 2: Example Signalling Flow For Subsequent E2E Flow Without Reservation Resizing
附录2：后续E2E流的信令流示例，无需调整预留大小
This Appendix does not provide additional specification. It only illustrates the specification detailed above through a possible flow of RSVP signalling messages involved in the successful establishment of a unicast E2E reservation which follows other E2E reservations between a given pair of Aggregator/Deaggregator. This flow could be imagined as following the flow of messages illustrated in Appendix 1.
本附录不提供其他规范。它仅通过RSVP信令消息的可能流来说明上面详述的规范，RSVP信令消息涉及单播E2E预留的成功建立，该单播E2E预留遵循给定的一对聚合器/解聚合器之间的其他E2E预留。该流程可以想象为遵循附录1中所示的消息流程。
Aggregator Deaggregator
聚合器-解聚器
E2E Path
---------------->
(10)
E2E Path
------------------------------->
(11)
E2E Path
----------->
E2E Resv
<-----------
(12)
E2E Resv (DCLASS=x)
<-----------------------------
(13)
E2E Resv
<---------------
E2E Path
---------------->
(10)
E2E Path
------------------------------->
(11)
E2E Path
----------->
E2E Resv
<-----------
(12)
E2E Resv (DCLASS=x)
<-----------------------------
(13)
E2E Resv
<---------------
(10) Aggregator forwards E2E Path into aggregation region after modifying its IP Protocol Number to RSVP-E2E-IGNORE
（10） 聚合器将其IP协议号修改为RSVP-E2E-IGNORE后，将E2E路径转发到聚合区域
(11) Because previous E2E reservations have been established, let's assume that Aggregate Path exists for all supported DSCPs. The Deaggregator takes into account the information contained in the ADSPEC from the Aggregate Paths and updates the E2E Path ADSPEC accordingly. The Deaggregator also modifies the E2E Path IP Protocol Number to RSVP before forwarding it.
（11） 因为之前的E2E保留已经建立，所以让我们假设所有受支持的DSCP都存在聚合路径。解聚集器考虑来自聚合路径的ADSPEC中包含的信息，并相应地更新E2E路径ADSPEC。在转发之前，解聚集器还将E2E路径IP协议号修改为RSVP。
(12) On receipt of the E2E Resv, the Deaggregator applies the mapping policy defined by the network administrator to map the E2E Resv onto an Aggregate Reservation. Let's assume that this policy is such that the E2E reservation is to be mapped onto the Aggregate Reservation with DSCP=x. Because previous E2E reservations have
（12） 收到E2E Resv后，解聚集器应用网络管理员定义的映射策略将E2E Resv映射到聚合保留上。让我们假设此策略使得E2E保留映射到DSCP=x的聚合保留。因为之前的E2E预订
been established, let's assume that an Aggregate Reservation is in place for DSCP=x. The Deaggregator performs admission control of the E2E Resv onto the Aggregate Resv for DSCP=x. Assuming that the Aggregate Resv for DSCP=x has sufficient unused bandwidth to support the new E2E Resv, the Deaggregator then adjusts its counter tracking the unused bandwidth on the Aggregate Reservation and forwards the E2E Resv to the Aggregator including a DCLASS object conveying the selected mapping onto DSCP=x.
如果已建立，则假设已为DSCP=x设置了聚合保留。解聚集器对DSCP=x的聚合Resv执行E2E Resv的接纳控制。假设DSCP=x的聚合Resv具有足够的未使用带宽来支持新的E2E Resv，则解聚合器随后调整其计数器，跟踪聚合保留上的未使用带宽，并将E2E Resv转发给聚合器，该聚合器包括将所选映射传送到DSCP=x的DCLASS对象。
(13) The Aggregator records the mapping of the E2E Resv onto DSCP=x. The Aggregator removes the DCLASS object and forwards the E2E Resv towards the sender.
（13） 聚合器记录E2E Resv到DSCP=x的映射。聚合器删除DCLASS对象并将E2E Resv转发给发送方。
APPENDIX 3: Example Signalling Flow For Subsequent E2E Flow With Reservation Resizing
附录3：后续E2E流的信令流示例（带保留大小调整）
This Appendix does not provide additional specification. It only illustrates the specification detailed above through a possible flow of RSVP signalling messages involved in the successful establishment of a unicast E2E reservation which follows other E2E reservations between a given pair of Aggregator/Deaggregator. This flow could be imagined as following the flow of messages illustrated in Appendix 2.
本附录不提供其他规范。它仅通过RSVP信令消息的可能流来说明上面详述的规范，RSVP信令消息涉及单播E2E预留的成功建立，该单播E2E预留遵循给定的一对聚合器/解聚合器之间的其他E2E预留。该流程可以想象为遵循附录2中所示的消息流程。
Aggregator Deaggregator
聚合器-解聚器
E2E Path
---------------->
(14)
E2E Path
------------------------------->
(15)
E2E Path
----------->
E2E Path
---------------->
(14)
E2E Path
------------------------------->
(15)
E2E Path
----------->
E2E Resv
<-----------
E2E Resv
<-----------
(16)
AggResv (DSCP=x, increased Bw)
<-------------------------------
(17)
AggResvConfirm (DSCP=x, increased Bw)
------------------------------>
(18)
E2E Resv (DCLASS=x)
<-----------------------------
(19)
E2E Resv
<---------------
(16)
AggResv (DSCP=x, increased Bw)
<-------------------------------
(17)
AggResvConfirm (DSCP=x, increased Bw)
------------------------------>
(18)
E2E Resv (DCLASS=x)
<-----------------------------
(19)
E2E Resv
<---------------
(14) Aggregator forwards E2E Path into aggregation region after modifying its IP Protocol Number to RSVP-E2E-IGNORE
（14） 聚合器将其IP协议号修改为RSVP-E2E-IGNORE后，将E2E路径转发到聚合区域
(15) Because previous E2E reservations have been established, let's assume that Aggregate Path exists for all supported DSCPs. The Deaggregator takes into account the information contained in the ADSPEC from the Aggregate Paths and updates the E2E Path ADSPEC accordingly. The Deaggregator also modifies the E2E Path IP Protocol Number to RSVP before forwarding it.
（15） 因为之前的E2E保留已经建立，所以让我们假设所有受支持的DSCP都存在聚合路径。解聚集器考虑来自聚合路径的ADSPEC中包含的信息，并相应地更新E2E路径ADSPEC。在转发之前，解聚集器还将E2E路径IP协议号修改为RSVP。
(16) On receipt of the E2E Resv, the Deaggregator applies the mapping policy defined by the network administrator to map the E2E Resv onto an Aggregate Reservation. Let's assume that this policy is such that the E2E reservation is to be mapped onto the Aggregate Reservation with DSCP=x. Because previous E2E reservations have been established, let's assume that an Aggregate Reservation is in place for DSCP=x. The Deaggregator performs admission control of the E2E Resv onto the Agg Resv for DSCP=x. Let's assume that the Aggregate Resv for DSCP=x does NOT have sufficient unused bandwidth to support the new E2E Resv. The
（16） 收到E2E Resv后，解聚集器应用网络管理员定义的映射策略将E2E Resv映射到聚合保留上。让我们假设此策略使得E2E保留映射到DSCP=x的聚合保留。因为之前的E2E保留已经建立，所以让我们假设DSCP=x有一个聚合保留。对于DSCP=x，解聚集器将E2E Resv的接纳控制执行到Agg Resv上。假设DSCP=x的聚合Resv没有足够的未使用带宽来支持新的E2E Resv。这个
Deaggregator then attempts to increase the Aggregate Reservation bandwidth for DSCP=x by sending a new Aggregate Resv with an increased bandwidth sufficient to accommodate all the E2E reservations already mapped onto that Aggregate reservation plus the new E2E reservation plus possibly some additional spare bandwidth in anticipation of additional E2E reservations to come. Assume also that the Deaggregator includes the optional Resv Confirm Request in these Aggregate Resv.
然后，解聚集器尝试通过发送一个新的聚合Resv来增加DSCP=x的聚合保留带宽，该聚合Resv的增加带宽足以容纳已映射到该聚合保留上的所有E2E保留加上新的E2E保留，再加上可能的一些额外的备用带宽，以预期额外的带宽E2E预定。还假设解聚集器在这些聚合Resv中包含可选的Resv确认请求。
(17) The Aggregator merely complies with the received ResvConfirm Request and returns the corresponding Aggregate ResvConfirm.
（17） 聚合器仅遵守收到的ResvConfig请求并返回相应的聚合ResvConfig。
(18) The Deaggregator has explicit confirmation that the Aggregate Resv has been successfully increased. The Deaggregator performs again admission control of the E2E Resv onto the increased Aggregate Reservation for DSCP=x. Assuming that the increased Aggregate Reservation for DSCP=x now has sufficient unused bandwidth and resources to support the new E2E Resv, the Deaggregator then adjusts its counter tracking the unused bandwidth on the Aggregate Reservation and forwards the E2E Resv to the Aggregator including a DCLASS object conveying the selected mapping onto DSCP=x.
（18） 解聚集器已明确确认聚合Resv已成功增加。解聚集器再次对DSCP=x的增加的聚集保留执行E2E Resv的接纳控制。假设DSCP=x增加的聚合保留现在有足够的未使用带宽和资源来支持新的E2E Resv，然后，解聚集器调整其跟踪聚合保留上未使用带宽的计数器，并将E2E Resv转发给聚合器，该聚合器包括一个将所选映射传送到DSCP=x的DCLASS对象。
(19) The Aggregator records the mapping of the E2E Resv onto DSCP=x. The Aggregator removes the DCLASS object and forwards the E2E Resv towards the sender.
（19） 聚合器记录E2E Resv到DSCP=x的映射。聚合器删除DCLASS对象并将E2E Resv转发给发送方。
References
工具书类
[CSZ] Clark, D., S. Shenker, and L. Zhang, "Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism," in Proc. SIGCOMM'92, September 1992.
[CSZ]Clark，D.，S.Shenker和L.Zhang，“支持综合业务分组网络中的实时应用：体系结构和机制”，在Proc。SIGCOMM'921992年9月。
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IP]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[HOSTREQ] Braden, R., "Requirements for Internet hosts - communication layers", STD 3, RFC 1122, October 1989.
[HOSTREQ]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[DSFIELD]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 24741998年12月。
[PRINCIPLES] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[原则]Carpenter，B.，“互联网的建筑原则”，RFC 19581996年6月。
[ASSURED] Heinanen, J, Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[保证]Heinanen，J，Baker，F.，Weiss，W.和J.Wroclawski，“保证货运PHB集团”，RFC 25971999年6月。
[BROKER] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, June 1999.
[BROKER]Jacobson，V.，Nichols K.和L.Zhang，“互联网的两位差异化服务架构”，RFC 2638，1999年6月。
[BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
[BRIM]BRIM，S.，Carpenter，B.和F.LeFaucheur，“每跳行为识别码”，RFC 28362000年5月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）第1版功能规范”，RFC 22052997年9月。
[TERZIS] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[TERZIS]TERZIS，A.，Krawczyk，J.，Wroclawski，J.和L.Zhang，“IP隧道上的RSVP操作”，RFC 27462000年1月。
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[DCLASS]Bernet，Y.，“RSVP DCLASS对象的格式”，RFC 2996，2000年11月。
[INTEGRITY] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[完整性]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC2998] Bernet Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "Integrated Services Operation Over Diffserv Networks", RFC 2998, November 2000.
[RFC2998]Bernet Y.，Ford，P.，Yavatkar，R.，Baker，F.，Zhang，L.，Speer，M.，Braden，R.，Davie，B.，Wroclawski，J.和E.Felstaine，“区分服务网络上的综合服务运营”，RFC 29982000年11月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P. and F. Tommasi, "RSVP Refresh Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.和F.Tommasi，“RSVP刷新减少扩展”，RFC 29612001年4月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", RFC 2780, March 2000.
[RFC2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，RFC 27802000年3月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[RFC2113] Katz, D. "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.“IP路由器警报选项”，RFC21131997年2月。
Authors' Addresses
作者地址
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA, 93117 USA
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara，加利福尼亚州，美国
Phone: (408) 526-4257 EMail: fred@cisco.com
电话：（408）526-4257电子邮件：fred@cisco.com
Carol Iturralde Cisco Systems 250 Apollo Drive Chelmsford MA, 01824 USA
卡罗尔·伊图拉尔德思科系统公司美国马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
Phone: 978-244-8532 EMail: cei@cisco.com
电话：978-244-8532电子邮件：cei@cisco.com
Francois Le Faucheur Cisco Systems Domaine Green Side 400, Avenue de Roumanille 06410 Biot - Sophia Antipolis France
弗朗索瓦·勒·福彻思科系统公司绿边庄园400号，卢曼尼大道06410号，比奥-索菲亚·安提波利斯法国
Phone: +33.4.97.23.26.19
EMail: flefauch@cisco.com
Phone: +33.4.97.23.26.19
EMail: flefauch@cisco.com
Bruce Davie Cisco Systems 250 Apollo Drive Chelmsford MA,01824 USA
Bruce Davie Cisco Systems美国马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
Phone: 978-244-8921 EMail: bdavie@cisco.com
电话：978-244-8921电子邮件：bdavie@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。