Network Working Group F. Le Faucheur, Ed.
Request for Comments: 4804 Cisco Systems, Inc.
Category: Standards Track February 2007
Network Working Group F. Le Faucheur, Ed.
Request for Comments: 4804 Cisco Systems, Inc.
Category: Standards Track February 2007
Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels
MPLS TE/DS-TE隧道上资源预留协议（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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
RFC 3175 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations. This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels.
RFC 3175指定资源预留协议（RSVP）端到端预留的聚合，而不是聚合RSVP预留。本文档规定了通过MPLS流量工程（TE）隧道或MPLS区分服务感知MPLS流量工程（DS-TE）隧道聚合RSVP端到端保留。该方法基于RFC 3175，只是修改了MPLS TE隧道上操作的相应过程，而不是聚合RSVP保留。由于网络核心中的设备不知道端到端RSVP保留，并且只知道MPLS-TE隧道，因此该方法可用于以可伸缩的方式实现对大量流的接纳控制。
Table of Contents
目录
1. Introduction ....................................................3
2. Specification of Requirements ...................................7
3. Definitions .....................................................7
4. Operations of RSVP Aggregation over TE with
Pre-established Tunnels .........................................8
4.1. Reference Model ............................................9
4.2. Receipt of E2E Path Message by the Aggregator ..............9
4.3. Handling of E2E Path Message by Transit LSRs ..............11
4.4. Receipt of E2E Path Message by the Deaggregator ...........11
4.5. Handling of E2E Resv Message by the Deaggregator ..........12
4.6. Handling of E2E Resv Message by the Aggregator ............12
4.7. Forwarding of E2E Traffic by the Aggregator ...............14
4.8. Removal of E2E Reservations ...............................14
4.9. Removal of the TE Tunnel ..................................14
4.10. Example Signaling Flow ...................................15
5. IPv4 and IPv6 Applicability ....................................16
6. E2E Reservations Applicability .................................16
7. Example Deployment Scenarios ...................................16
7.1. Voice and Video Reservations Scenario .....................16
7.2. PSTN/3G Voice Trunking Scenario ...........................17
8. Security Considerations ........................................18
9. Acknowledgments ................................................20
10. Normative References ..........................................20
11. Informative References ........................................21
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator ........23
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels
for VoIP Call Admission Control (CAC) ................25
1. Introduction ....................................................3
2. Specification of Requirements ...................................7
3. Definitions .....................................................7
4. Operations of RSVP Aggregation over TE with
Pre-established Tunnels .........................................8
4.1. Reference Model ............................................9
4.2. Receipt of E2E Path Message by the Aggregator ..............9
4.3. Handling of E2E Path Message by Transit LSRs ..............11
4.4. Receipt of E2E Path Message by the Deaggregator ...........11
4.5. Handling of E2E Resv Message by the Deaggregator ..........12
4.6. Handling of E2E Resv Message by the Aggregator ............12
4.7. Forwarding of E2E Traffic by the Aggregator ...............14
4.8. Removal of E2E Reservations ...............................14
4.9. Removal of the TE Tunnel ..................................14
4.10. Example Signaling Flow ...................................15
5. IPv4 and IPv6 Applicability ....................................16
6. E2E Reservations Applicability .................................16
7. Example Deployment Scenarios ...................................16
7.1. Voice and Video Reservations Scenario .....................16
7.2. PSTN/3G Voice Trunking Scenario ...........................17
8. Security Considerations ........................................18
9. Acknowledgments ................................................20
10. Normative References ..........................................20
11. Informative References ........................................21
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator ........23
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels
for VoIP Call Admission Control (CAC) ................25
The Integrated Services (Intserv) [INT-SERV] architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks.
集成服务（integratedservices，Intserv）[INT-SERV]体系结构提供了一种通过异构网络向应用程序提供端到端服务质量（qualityofservice，QoS）的方法。
[RSVP] defines the Resource reSerVation Protocol that can be used by applications to request resources from the network. The network responds by explicitly admitting or rejecting these RSVP requests. Certain applications that have quantifiable resource requirements express these requirements using Intserv parameters as defined in the appropriate Intserv service specifications ([GUARANTEED], [CONTROLLED]).
[RSVP]定义应用程序可用于从网络请求资源的资源保留协议。网络通过明确承认或拒绝这些RSVP请求进行响应。某些具有可量化资源需求的应用程序使用适当的Intserv服务规范（[保证]、[控制]）中定义的Intserv参数来表达这些需求。
The Differentiated Services (DiffServ) architecture ([DIFFSERV]) was then developed to support the differentiated treatment of packets in very large scale environments. In contrast to the per-flow orientation of Intserv and RSVP, Diffserv networks classify packets into one of a small number of aggregated flows or "classes", based on the Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv router, packets are subjected to a "per-hop behavior" (PHB), which is invoked by the DSCP. The primary benefit of Diffserv is its scalability. Diffserv eliminates the need for per-flow state and per-flow processing, and therefore scales well to large networks.
然后开发了区分服务（DiffServ）体系结构（[DiffServ]），以支持在大规模环境中对数据包进行区分处理。与Intserv和RSVP的每流方向不同，Diffserv网络基于数据包IP报头中的Diffserv码点（DSCP）将数据包分类为少量聚合流或“类”之一。在每个Diffserv路由器上，数据包都受到“每跳行为”（PHB）的约束，该行为由DSCP调用。Diffserv的主要优点是其可扩展性。Diffserv消除了对每流状态和每流处理的需要，因此可以很好地扩展到大型网络。
However, DiffServ does not include any mechanism for communication between applications and the network. Thus, as detailed in [INT-DIFF], significant benefits can be achieved by using Intserv over Diffserv including resource-based admission control, policy-based admission control, assistance in traffic identification/classification, and traffic conditioning. As discussed in [INT-DIFF], Intserv can operate over Diffserv in multiple ways. For example, the Diffserv region may be statically provisioned or RSVP aware. When it is RSVP aware, several mechanisms may be used to support dynamic provisioning and topology-aware admission control, including aggregate RSVP reservations, per-flow RSVP, or a bandwidth broker. The advantage of using aggregate RSVP reservations is that it offers dynamic, topology-aware admission control over the Diffserv region without per-flow reservations and the associated level of RSVP signaling in the Diffserv core. In turn, this allows dynamic, topology-aware admission control of flows requiring QoS reservations over the Diffserv core even when the total number of such flows carried over the Diffserv core is extremely large.
但是，DiffServ不包括应用程序和网络之间通信的任何机制。因此，如[INT-DIFF]中所述，通过使用Intserv而不是Diffserv，可以实现显著的好处，包括基于资源的接纳控制、基于策略的接纳控制、流量识别/分类的帮助以及流量调节。正如[INT-DIFF]中所讨论的，Intserv可以以多种方式在Diffserv上运行。例如，区分服务区域可以是静态配置的或RSVP感知的。当它是RSVP感知的时，可以使用几种机制来支持动态资源调配和拓扑感知许可控制，包括聚合RSVP预留、每流RSVP或带宽代理。使用聚合RSVP预留的优点是，它在Diffserv区域上提供动态的、拓扑感知的接纳控制，而不需要每流预留和Diffserv核心中相关级别的RSVP信令。反过来，这允许动态地、拓扑感知地允许通过Diffserv核心对需要QoS保留的流进行控制，即使通过Diffserv核心承载的此类流的总数非常大。
[RSVP-AGG] and [RSVP-GEN-AGG] describe in detail how to perform such aggregation of end-to-end RSVP reservations over aggregate RSVP reservations in a Diffserv cloud. They establish an architecture
[RSVP-AGG]和[RSVP-GEN-AGG]详细描述了如何在Diffserv云中对聚合RSVP保留执行端到端RSVP保留的聚合。他们建立了一个架构
where multiple end-to-end RSVP reservations sharing the same ingress router (Aggregator) and egress router (Deaggregator) at the edges of an "aggregation region" can be mapped onto a single aggregate reservation within the aggregation region. This considerably reduces the amount of reservation state that needs to be maintained by routers within the aggregation region. Furthermore, traffic belonging to aggregate reservations is classified in the data path purely using Diffserv marking.
其中，在“聚合区域”的边缘共享相同入口路由器（聚合器）和出口路由器（解聚合器）的多个端到端RSVP保留可以映射到聚合区域内的单个聚合保留。这大大减少了聚合区域内路由器需要维护的保留状态量。此外，属于聚合保留的流量纯粹使用区分服务标记在数据路径中进行分类。
[MPLS-TE] describes how MPLS Traffic Engineering (TE) tunnels can be used to carry arbitrary aggregates of traffic for the purposes of traffic engineering. [RSVP-TE] specifies how such MPLS TE tunnels can be established using RSVP-TE signaling. MPLS TE uses Constraint-Based Routing to compute the path for a TE tunnel. Then, Admission Control is performed during the establishment of TE tunnels to ensure they are granted their requested resources.
[MPLS-TE]描述了如何使用MPLS流量工程（TE）隧道为流量工程目的承载任意流量聚合。[RSVP-TE]指定如何使用RSVP-TE信令建立此类MPLS TE隧道。MPLS TE使用基于约束的路由来计算TE隧道的路径。然后，在TE隧道的建立过程中执行准入控制，以确保它们获得所请求的资源。
[DSTE-REQ] presents the Service Providers requirements for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). With DS-TE, separate DS-TE tunnels can be used to carry different Diffserv classes of traffic, and different resource constraints can be enforced for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling extensions as well as OSPF and Intermediate System to Intermediate System (IS-IS) extensions for support of DS-TE.
[DSTE-REQ]介绍了服务提供商对支持区分服务的MPLS流量工程（DS-TE）的要求。使用DS-TE，可以使用单独的DS-TE隧道来承载不同的Diffserv流量类别，并且可以对这些不同类别实施不同的资源约束。[DSTE-PROTO]指定RSVP-TE信令扩展以及支持DS-TE的OSPF和中间系统到中间系统（IS-IS）扩展。
In the rest of this document we will refer to both TE tunnels and DS-TE tunnels simply as "TE tunnels".
在本文件的其余部分中，我们将TE隧道和DS-TE隧道简称为“TE隧道”。
TE tunnels have much in common with the aggregate RSVP reservations used in [RSVP-AGG] and [RSVP-GEN-AGG]:
TE隧道与[RSVP-AGG]和[RSVP-GEN-AGG]中使用的总RSVP保留有许多共同之处：
- A TE tunnel is subject to Admission Control and thus is effectively an aggregate bandwidth reservation.
- TE隧道受准入控制，因此有效地是聚合带宽预留。
- In the data plane, packet scheduling relies exclusively on Diffserv classification and PHBs.
- 在数据平面上，分组调度完全依赖于区分服务分类和PHB。
- Both TE tunnels and aggregate RSVP reservations are controlled by "intelligent" devices on the edge of the "aggregation core" (Head-end and Tail-end in the case of TE tunnels; Aggregator and Deaggregator in the case of aggregate RSVP reservations.
- TE隧道和聚合RSVP保留都由“聚合核心”边缘上的“智能”设备控制（TE隧道的前端和后端；聚合RSVP保留的聚合器和解聚合器）。
- Both TE tunnels and aggregate RSVP reservations are signaled using the RSVP protocol (with some extensions defined in [RSVP-TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE tunnels).
- TE隧道和聚合RSVP预留都使用RSVP协议发出信号（在[RSVP-TE]和[DSTE-PROTO]中分别为TE隧道和DS-TE隧道定义了一些扩展）。
This document provides a detailed specification for performing aggregation of end-to-end RSVP reservations over MPLS TE tunnels (which act as aggregate reservations in the core). This document builds on the RSVP Aggregation procedures defined in [RSVP-AGG] and [RSVP-GEN-AGG], and only changes those where necessary to operate over TE tunnels. With [RSVP-AGG] and [RSVP-GEN-AGG], a lot of responsibilities (such as mapping end-to-end reservations to Aggregate reservations and resizing the Aggregate reservations) are assigned to the Deaggregator (which is the equivalent of the tunnel Tail-end) while with TE, the tunnels are controlled by the tunnel Head-end. Hence, the main change over the RSVP Aggregations procedures defined in [RSVP-AGG] and [RSVP-GEN-AGG] is to modify these procedures to reassign responsibilities from the Deaggregator to the Aggregator (i.e., the tunnel Head-end).
本文档提供了在MPLS TE隧道（在核心中充当聚合保留）上执行端到端RSVP保留聚合的详细规范。本文件建立在[RSVP-AGG]和[RSVP-GEN-AGG]中定义的RSVP聚合程序的基础上，仅在必要时更改在TE隧道上运行的程序。使用[RSVP-AGG]和[RSVP-GEN-AGG]时，许多职责（如将端到端保留映射到聚合保留以及调整聚合保留的大小）分配给解聚集器（相当于隧道末端），而使用TE时，隧道由隧道前端控制。因此，[RSVP-AGG]和[RSVP-GEN-AGG]中定义的RSVP聚合程序的主要变化是修改这些程序，以将职责从解聚合器重新分配给聚合器（即隧道前端）。
[LSP-HIER] defines how to aggregate MPLS TE Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. This involves nesting of end-to-end LSPs into an aggregate LSP in the core (by using the label stack construct). Since end-to-end TE LSPs are themselves signaled with RSVP-TE and reserve resources at every hop, this can be looked at as a form of aggregation of RSVP(-TE) reservations over MPLS TE tunnels. This document capitalizes on the similarities between nesting of TE LSPs over TE tunnels and RSVP aggregation over TE tunnels, and reuses the procedures of [LSP-HIER] wherever possible.
[LSP-HIER]定义了如何通过创建此类LSP的层次结构来聚合MPLS TE标签交换路径（LSP）。这涉及到将端到端LSP嵌套到核心中的聚合LSP中（通过使用标签堆栈构造）。由于端到端TE LSP本身通过RSVP-TE发出信号，并在每个跃点保留资源，因此这可以看作是MPLS TE隧道上RSVP（-TE）保留的聚合形式。本文件利用了TE隧道上的TE LSP嵌套和TE隧道上的RSVP聚合之间的相似性，并尽可能重用[LSP-HIER]的程序。
This document also builds on the "RSVP over Tunnels" concepts of RFC 2746 [RSVP-TUN]. It differs from that specification in the following ways:
本文件还以RFC 2746[RSVP-TUN]的“隧道上方RSVP”概念为基础。它在以下方面与该规范不同：
- This document describes operation over MPLS tunnels, whereas RFC 2746 describes operation with IP tunnels. One consequence of this difference is the need to deal with penultimate hop popping (PHP).
- 本文档描述了通过MPLS隧道的操作，而RFC 2746描述了使用IP隧道的操作。这种差异的一个结果是需要处理倒数第二跳弹出（PHP）。
- MPLS-TE tunnels inherently reserve resources, whereas the tunnels in RFC 2746 do not have resource reservations by default. This leads to some simplifications in the current document.
- MPLS-TE隧道固有地保留资源，而RFC 2746中的隧道默认情况下没有资源保留。这导致了当前文档中的一些简化。
- This document builds on the fact that there is exactly one aggregate reservation per MPLS-TE tunnel, whereas RFC 2746 permits a model where one reservation is established on the tunnel path for each end-to-end flow.
- 本文档基于以下事实：每个MPLS-TE隧道只有一个聚合保留，而RFC 2746允许在隧道路径上为每个端到端流建立一个保留的模型。
- We have assumed in the current document that a given MPLS-TE tunnel will carry reserved traffic and nothing but reserved traffic, which negates the requirement of RFC 2746 to distinguish reserved and non-reserved traffic traversing the same tunnel by using distinct encapsulations.
- 我们在当前文档中假设，给定的MPLS-TE隧道将承载保留流量，而只承载保留流量，这否定了RFC 2746通过使用不同封装来区分穿越同一隧道的保留和非保留流量的要求。
- There may be several MPLS-TE tunnels that share common Head-end and Tail-end routers, with the Head-end policy determining which tunnel is appropriate for a particular flow. This scenario does not appear to be addressed in RFC 2746.
- 可能有几个MPLS-TE隧道共享公共的前端和后端路由器，前端策略确定哪个隧道适合于特定流。RFC 2746中似乎没有提到这种情况。
At the same time, this document does have many similarities with RFC 2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC 2746:
同时，本文件与RFC 2746有许多相似之处。MPLS-TE隧道是RFC 2746术语中的“2型隧道”：
"The (logical) link may be able to promise that some overall level of resources is available to carry traffic, but not to allocate resources specifically to individual data flows".
“该（逻辑）链路可能能够保证某些总体级别的资源可用于承载流量，但不能专门为单个数据流分配资源”。
Aggregation of end-to-end RSVP reservations over TE tunnels combines the benefits of [RSVP-AGG] and [RSVP-GEN-AGG] with the benefits of MPLS, including the following:
TE隧道上端到端RSVP保留的聚合将[RSVP-AGG]和[RSVP-GEN-AGG]的优点与MPLS的优点结合在一起，包括：
- Applications can benefit from dynamic, topology-aware, resource-based admission control over any segment of the end-to-end path, including the core.
- 应用程序可以受益于对端到端路径的任何段（包括核心）的动态、拓扑感知、基于资源的准入控制。
- As per regular RSVP behavior, RSVP does not impose any burden on routers where such admission control is not needed (for example, if the links upstream and downstream of the MPLS TE core are vastly over-engineered compared to the core capacity, admission control is not required on these over-engineered links and RSVP need not be processed on the corresponding router hops).
- 根据常规的RSVP行为，RSVP不会对不需要这种准入控制的路由器施加任何负担（例如，如果与核心容量相比，MPLS TE核心的上游和下游链路被过度设计，则在这些过度设计的链路上不需要接纳控制，并且RSVP不需要在相应的路由器跳上处理）。
- The core scalability is not affected (relative to the traditional MPLS TE deployment model) since the core remains unaware of end-to-end RSVP reservations and only has to maintain aggregate TE tunnels since the datapath classification and scheduling in the core relies purely on the Diffserv mechanism (or more precisely the MPLS Diffserv mechanisms, as specified in [DIFF-MPLS]).
- 核心可伸缩性不受影响（相对于传统的MPLS TE部署模型），因为核心仍然不知道端到端RSVP保留，并且只需要维护聚合TE隧道，因为核心中的数据路径分类和调度完全依赖于区分服务机制（或者更准确地说，是MPLS区分服务机制，如[DIFF-MPLS]中所述）。
- The aggregate reservation (and thus the traffic from the corresponding end to end reservations) can be network engineered via the use of Constraint based routing (e.g., affinity, optimization on different metrics) and when needed can take advantage of resources on other paths than the shortest path.
- 聚合预留（以及相应端到端预留的流量）可以通过使用基于约束的路由（例如，亲和力、不同度量的优化）进行网络工程，并且在需要时可以利用除最短路径之外的其他路径上的资源。
- The aggregate reservations (and thus the traffic from the corresponding end-to-end reservations) can be protected against failure through the use of MPLS Fast Reroute.
- 通过使用MPLS快速重路由，可以保护聚合保留（以及相应的端到端保留的流量）免受故障的影响。
This document, like [RSVP-AGG] and [RSVP-GEN-AGG], covers aggregation of unicast sessions. Aggregation of multicast sessions is for further study.
本文档与[RSVP-AGG]和[RSVP-GEN-AGG]一样，涵盖了单播会话的聚合。多播会话的聚合有待进一步研究。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
For readability, a number of definitions from [RSVP-AGG] as well as definitions for commonly used MPLS TE terms are provided here:
为便于阅读，此处提供了[RSVP-AGG]中的许多定义以及常用MPLS TE术语的定义：
Aggregator This is the process in (or associated with) the router at the ingress edge of the aggregation region (with respect to the end-to-end RSVP reservation) and behaving in accordance with [RSVP-AGG]. In this document, it is also the TE tunnel Head-end.
聚合器这是位于聚合区域入口边缘（关于端到端RSVP保留）的路由器中（或与之相关）的进程，其行为符合[RSVP-AGG]。在本文件中，它也是TE隧道前端。
Deaggregator This is the process in (or associated with) the router at the egress edge of the aggregation region (with respect to the end-to-end RSVP reservation) and behaving in accordance with [RSVP-AGG]. In this document, it is also the TE tunnel Tail-end
解聚集器这是聚集区域出口边缘路由器中（或与之相关）的进程（关于端到端RSVP保留），其行为符合[RSVP-AGG]。在本文件中，它也是TE隧道的尾端
E2E End to end
端到端
E2E Reservation This is an RSVP reservation such that:
E2E预订这是一个RSVP预订，以便：
(i) corresponding Path messages are initiated upstream of the Aggregator and terminated downstream of the Deaggregator, and
(i) 相应的路径消息在聚合器的上游发起，在解聚合器的下游终止，以及
(ii) corresponding Resv messages are initiated downstream of the Deaggregator and terminated upstream of the Aggregator, and
（ii）相应的Resv消息在解聚集器的下游启动，并在聚集器的上游终止，以及
(iii) this RSVP reservation is aggregated over an MPLS TE tunnel between the Aggregator and Deaggregator.
（iii）此RSVP保留通过聚合器和解聚合器之间的MPLS TE隧道聚合。
An E2E RSVP reservation may be a per-flow reservation. Alternatively, the E2E reservation may itself be an aggregate reservation of various types (e.g., Aggregate IP reservation, Aggregate IPsec reservation). See Section 5 and 6 for more details on the types of E2E RSVP reservations. As per regular RSVP operations, E2E RSVP reservations are unidirectional.
E2E RSVP预留可以是每流预留。或者，E2E保留本身可以是各种类型的聚合保留（例如，聚合IP保留、聚合IPsec保留）。有关E2E RSVP保留类型的更多详细信息，请参见第5节和第6节。根据常规RSVP操作，E2E RSVP保留是单向的。
Head-end This is the Label Switch Router responsible for establishing, maintaining, and tearing down a given TE tunnel.
前端这是负责建立、维护和拆除给定TE隧道的标签交换路由器。
Tail-end This is the Label Switch Router responsible for terminating a given TE tunnel.
尾端这是负责终止给定TE隧道的标签交换路由器。
Transit LSR This is a Label Switch Router that is on the path of a given TE tunnel and is neither the Head-end nor the Tail-end.
Transit LSR这是一个标签交换路由器，位于给定TE隧道的路径上，既不是前端也不是后端。
[RSVP-AGG] and [RSVP-GEN-AGG] support operations both in the case where aggregate RSVP reservations are pre-established and where Aggregators and Deaggregators have to dynamically discover each other and dynamically establish the necessary aggregate RSVP reservations.
[RSVP-AGG]和[RSVP-GEN-AGG]支持预先建立聚合RSVP保留以及聚合器和解聚合器必须动态发现彼此并动态建立必要的聚合RSVP保留的情况下的操作。
Similarly, RSVP Aggregation over TE tunnels could operate both in the case where the TE tunnels are pre-established and where the tunnels need to be dynamically established.
类似地，TE隧道上的RSVP聚合可以在预先建立TE隧道和需要动态建立隧道的情况下运行。
In this document we provide a detailed description of the procedures in the case where TE tunnels are already established. These procedures are based on those defined in [LSP-HIER]. The routing aspects discussed in Section 3 of [LSP-HIER] are not relevant here because those aim at allowing the constraint based routing of end-to-end TE LSPs to take into account the (aggregate) TE tunnels. In the present document, the end-to-end RSVP reservations to be aggregated over the TE tunnels rely on regular SPF routing. However, as already mentioned in [LSP-HIER], we note that a TE tunnel may be advertised into IS-IS or OSPF, to be used in normal SPF by nodes upstream of the Aggregator. This would affect SPF routing and thus routing of end-to-end RSVP reservations. The control of aggregation boundaries discussed in Section 6 of [LSP-HIER] is also not relevant here. This uses information exchanged in GMPLS protocols to dynamically discover the aggregation boundary. In this document, TE tunnels are pre-established, so that the aggregation boundary can be easily inferred. The signaling aspects discussed in Section 6.2 of
在本文件中，我们对已经建立TE隧道的情况下的程序进行了详细说明。这些程序基于[LSP-HIER]中定义的程序。[LSP-HIER]第3节中讨论的路由方面在此不相关，因为这些方面旨在允许端到端TE LSP基于约束的路由考虑（聚合）TE隧道。在本文件中，要在TE隧道上聚合的端到端RSVP保留依赖于常规SPF路由。然而，正如在[LSP-HIER]中已经提到的，我们注意到TE隧道可以发布到IS-IS或OSPF中，由聚合器上游的节点在正常SPF中使用。这将影响SPF路由，从而影响端到端RSVP预留的路由。[LSP-HIER]第6节中讨论的聚合边界控制在此也不相关。这使用GMPLS协议中交换的信息来动态发现聚合边界。在本文件中，预先建立了TE隧道，因此可以很容易地推断聚集边界。第6.2节中讨论的信号方面
[LSP-HIER] apply to the establishment/termination of the aggregate TE tunnels when this is triggered by GMPLS mechanisms (e.g., as a result of an end-to-end TE LSP establishment request received at the aggregation boundary). As this document assumes pre-established tunnels, those aspects are not relevant here. The signaling aspects discussed in Section 6.1 of [LSP-HIER] relate to the establishment/maintenance of the end-to-end TE LSPs over the aggregate TE tunnel. This document describes how to use the same procedures as those specified in Section 6.1 of [LSP-HIER], but for the establishment of end-to-end RSVP reservations (instead of end-to-end TE LSPs) over the TE tunnels. This is covered further in Section 4 of the present document.
[LSP-HIER]适用于由GMPLS机制触发的聚合TE隧道的建立/终止（例如，由于在聚合边界接收到端到端的TE LSP建立请求）。由于本文件假定预先修建的隧道，因此这些方面与本文件无关。[LSP-HIER]第6.1节中讨论的信令方面涉及在总TE隧道上建立/维护端到端TE LSP。本文件描述了如何使用与[LSP-HIER]第6.1节中规定的程序相同的程序，但用于在TE隧道上建立端到端RSVP预留（而不是端到端TE LSP）。本文件第4节进一步阐述了这一点。
Pre-establishment of the TE tunnels may be triggered by any mechanisms including; for example, manual configuration or automatic establishment of a TE tunnel mesh through dynamic discovery of TE Mesh membership as allowed in [AUTOMESH].
TE隧道的预建可能由任何机制触发，包括：；例如，根据[AUTOMESH]中的允许，通过动态发现TE网格成员身份手动配置或自动建立TE隧道网格。
Procedures in the case of dynamically established TE tunnels are for further studies.
动态建立TE隧道的程序有待进一步研究。
|----| |----|
H--| R |\ |-----| |------| /| R |--H
H--| |\\| | |---| | |//| |--H
|----| \| He/ | | T | | Te/ |/ |----|
| Agg |=======================| Deag |
/| | | | | |\
H--------//| | |---| | |\\--------H
H--------/ |-----| |------| \--------H
|----| |----|
H--| R |\ |-----| |------| /| R |--H
H--| |\\| | |---| | |//| |--H
|----| \| He/ | | T | | Te/ |/ |----|
| Agg |=======================| Deag |
/| | | | | |\
H--------//| | |---| | |\\--------H
H--------/ |-----| |------| \--------H
H = Host requesting end-to-end RSVP reservations
R = RSVP router
He/Agg = TE tunnel Head-end/Aggregator
Te/Deag = TE tunnel Tail-end/Deaggregator
T = Transit LSR
H = Host requesting end-to-end RSVP reservations
R = RSVP router
He/Agg = TE tunnel Head-end/Aggregator
Te/Deag = TE tunnel Tail-end/Deaggregator
T = Transit LSR
-- = E2E RSVP reservation
== = TE tunnel
-- = E2E RSVP reservation
== = TE tunnel
The first event is the arrival of the E2E Path message at the Aggregator. The Aggregator MUST follow traditional RSVP procedures for the processing of this E2E path message augmented with the extensions documented in this section.
第一个事件是E2E Path消息到达聚合器。聚合器必须遵循传统的RSVP程序来处理此E2E路径消息，并在本节中记录扩展。
The Aggregator MUST first attempt to map the E2E reservation onto a TE tunnel. This decision is made in accordance with routing information as well as any local policy information that may be available at the Aggregator. Examples of such policies appear in the following paragraphs. Just for illustration purposes, among many other criteria, such mapping policies might take into account the Intserv service type, the Application Identity [RSVP-APPID], and/or the signaled preemption [RSVP-PREEMP] of the E2E reservation (for example, the aggregator may take into account the E2E reservations RSVP preemption priority and the MPLS TE tunnel setup and/or hold priorities when mapping the E2E reservation onto an MPLS TE tunnel).
聚合器必须首先尝试将E2E保留映射到TE隧道。此决定是根据路由信息以及聚合器上可能提供的任何本地策略信息做出的。这些政策的例子见下文。仅出于说明目的，在许多其他标准中，此类映射策略可能考虑Intserv服务类型、应用程序标识[RSVP-APPID]和/或E2E保留的信号抢占[RSVP-PREEMEP]（例如，在将E2E保留映射到MPLS TE隧道时，聚合器可以考虑E2E保留RSVP抢占优先级和MPLS TE隧道设置和/或保持优先级）。
There are situations where the Aggregator is able to make a final mapping decision. That would be the case, for example, if there is a single TE tunnel toward the destination and if the policy is to map any E2E RSVP reservation onto TE tunnels.
在某些情况下，聚合器能够做出最终的映射决策。例如，如果有一个通向目的地的TE隧道，并且策略是将任何E2E RSVP保留映射到TE隧道，则情况就是如此。
There are situations where the Aggregator is not able to make a final determination. That would be the case, for example, if routing identifies two DS-TE tunnels toward the destination, one belonging to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel and Intserv Controlled Load reservations to a Class-Type 0 tunnel, and if the E2E RSVP Path message advertises both Guaranteed Service and Controlled Load.
在某些情况下，聚合器无法做出最终决定。例如，如果路由识别两个通向目的地的DS-TE隧道，一个属于DS-TE类类型1，另一个属于类类型0，如果策略是将Intserv保证的服务保留映射到类类型1隧道，将Intserv控制的负载保留映射到类类型0隧道，则情况就是如此，如果E2E RSVP Path消息同时播发保证服务和控制负载。
Whether final or tentative, the Aggregator makes a mapping decision and selects a TE tunnel. Before forwarding the E2E Path message toward the receiver, the Aggregator SHOULD update the ADSPEC inside the E2E Path message to reflect the impact of the MPLS TE cloud onto the QoS achievable by the E2E flow. This update is a local matter and may be based on configured information, on the information available in the MPLS TE topology database, on the current TE tunnel path, on information collected via RSVP-TE signaling, or a combination thereof. Updating the ADSPEC allows receivers that take into account the information collected in the ADSPEC within the network (such as delay and bandwidth estimates) to make more informed reservation decisions.
无论是最终还是暂定，聚合器都会做出映射决策并选择TE隧道。在将E2E路径消息转发给接收器之前，聚合器应更新E2E路径消息内的ADSPEC，以反映MPLS TE云对E2E流可实现的QoS的影响。该更新是本地事务，并且可以基于配置信息、MPLS TE拓扑数据库中可用的信息、当前TE隧道路径、通过RSVP-TE信令收集的信息或其组合。更新ADSPEC允许考虑网络内ADSPEC中收集的信息（例如延迟和带宽估计）的接收器做出更明智的预订决定。
The Aggregator MUST then forward the E2E Path message to the Deaggregator (which is the Tail-end of the selected TE tunnel). In accordance with [LSP-HIER], the Aggregator MUST send the E2E Path message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object. The data interface identification MUST identify the TE tunnel.
然后，聚合器必须将E2E Path消息转发给解聚合器（即所选TE隧道的末端）。根据[LSP-HIER]，聚合器必须使用IF_ID RSVP_HOP对象而不是RSVP_HOP对象发送E2E路径消息。数据接口标识必须标识TE隧道。
To send the E2E Path message, the Aggregator MUST address it directly to the Deaggregator by setting the destination address in the IP Header of the E2E Path message to the Deaggregator address. The Router Alert is not set in the E2E Path message.
要发送E2E Path消息，聚合器必须通过将E2E Path消息的IP头中的目标地址设置为解聚合器地址，将其直接寻址到解聚合器。E2E路径消息中未设置路由器警报。
Optionally, the Aggregator MAY also encapsulate the E2E Path message in an IP tunnel or in the TE tunnel itself.
可选地，聚合器还可以将E2E路径消息封装在IP隧道或TE隧道本身中。
Regardless of the encapsulation method, the Router Alert is not set. Thus, the E2E Path message will not be visible to routers along the path from the Aggregator to the Deaggregator. Therefore, in contrast to the procedures of [RSVP-AGG] and [RSVP-GEN-AGG], the IP Protocol number does not need to be modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating "RSVP") by the Aggregator.
无论采用何种封装方法，都不会设置路由器警报。因此，沿从聚合器到解聚合器的路径，路由器将看不到E2E路径消息。因此，与[RSVP-AGG]和[RSVP-GEN-AGG]的程序相反，IP协议号不需要修改为“RSVP-E2E-IGNORE”；聚合器必须保持原样（表示“RSVP”）。
In some environments, the Aggregator and Deaggregator MAY also act as IPsec Security Gateways in order to provide IPsec protection to E2E traffic when it transits between the Aggregator and the Deaggregator. In that case, to transmit the E2E Path message to the Deaggregator, the Aggregator MUST send the E2E Path message into the relevant IPsec tunnel terminating on the Deaggregator.
在某些环境中，聚合器和解聚合器还可以充当IPsec安全网关，以便在E2E流量在聚合器和解聚合器之间传输时为其提供IPsec保护。在这种情况下，要将E2E Path消息发送到解聚集器，聚合器必须将E2E Path消息发送到终止于解聚集器的相关IPsec隧道中。
E2E PathTear and ResvConf messages MUST be forwarded by the Aggregator to the Deaggregator exactly like Path messages.
E2E PathTear和ResvConf消息必须由聚合器转发到解聚合器，就像路径消息一样。
Since the E2E Path message is addressed directly to the Deaggregator and does not have Router Alert set, it is hidden from all transit LSRs.
由于E2E路径消息直接发送到解聚集器，并且没有路由器警报设置，因此它对所有传输LSR都是隐藏的。
Upon receipt of the E2E Path message addressed to it, the Deaggregator will notice that the IP Protocol number is set to "RSVP" and will thus perform RSVP processing of the E2E Path message.
在收到发往它的E2E路径消息后，解聚集器将注意到IP协议号被设置为“RSVP”，因此将执行E2E路径消息的RSVP处理。
As with [LSP-HIER], the IP TTL vs. RSVP TTL check MUST NOT be made. The Deaggregator is informed that this check is not to be made because of the presence of the IF_ID RSVP HOP object.
与[LSP-HIER]一样，不得进行IP TTL与RSVP TTL检查。解聚集器被告知，由于存在IF_ID RSVP HOP对象，因此不进行此检查。
The Deaggregator MAY support the option to perform the following checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID RSVP_HOP object:
解聚集器可以支持由IF_ID RSVP_HOP对象的接收器Y执行以下检查（在[LSP-HIER]中定义）的选项：
1. Make sure that the data interface identified in the IF_ID RSVP_HOP object actually terminates on Y.
1. 确保IF_ID RSVP_HOP对象中标识的数据接口实际上在Y上终止。
2. Find the "other end" of the above data interface, i.e., X. Make sure that the PHOP in the IF_ID RSVP_HOP object is a control channel address that belongs to the same node as X.
2. 找到上述数据接口的“另一端”，即X。确保IF_ID RSVP_HOP对象中的PHOP是属于与X相同节点的控制通道地址。
The information necessary to perform these checks may not always be available to the Deaggregator. Hence, the Deaggregator MUST support operations in such environments where the checks cannot be made.
执行这些检查所需的信息可能并不总是可供解集器使用。因此，解聚集器必须支持无法进行检查的环境中的操作。
The Deaggregator MUST forward the E2E Path downstream toward the receiver. In doing so, the Deaggregator sets the destination address in the IP header of the E2E Path message to the IP address found in the destination address field of the Session object. The Deaggregator also sets the Router Alert.
接收器E2E必须朝着下游路径前进。这样，解聚集器将E2E Path消息的IP报头中的目标地址设置为会话对象的目标地址字段中找到的IP地址。解聚集器还设置路由器警报。
An E2E PathErr sent by the Deaggregator in response to the E2E Path message (which contains an IF_ID RSVP_HOP object) SHOULD contain an IF_ID RSVP_HOP object.
解聚集器响应E2E Path消息（包含IF_ID RSVP_HOP对象）而发送的E2E路径错误应包含IF_ID RSVP_HOP对象。
As per regular RSVP operations, after receipt of the E2E Path, the receiver generates an E2E Resv message which travels upstream hop-by-hop towards the sender.
根据常规的RSVP操作，在接收到E2E路径之后，接收器生成一个E2E Resv消息，该消息向上游逐跳地向发送者移动。
Upon receipt of the E2E Resv, the Deaggregator MUST follow traditional RSVP procedures on receipt of the E2E Resv message. This includes performing admission control for the segment downstream of the Deaggregator and forwarding the E2E Resv message to the PHOP signaled earlier in the E2E Path message and which identifies the Aggregator. Since the E2E Resv message is directly addressed to the Aggregator and does not carry the Router Alert option (as per traditional RSVP Resv procedures), the E2E Resv message is hidden from the routers between the Deaggregator and the Aggregator which, therefore, handle the E2E Resv message as a regular IP packet.
收到E2E Resv后，解聚集器在收到E2E Resv消息时必须遵循传统的RSVP程序。这包括对解聚集器下游的段执行接纳控制，并将E2E Resv消息转发到E2E Path消息中先前发出信号并标识聚集器的PHOP。由于E2E Resv消息直接发送给聚合器，并且不携带路由器警报选项（根据传统的RSVP Resv程序），因此E2E Resv消息对解聚合器和聚合器之间的路由器隐藏，因此，聚合器将E2E Resv消息作为常规IP包处理。
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Deaggregator MUST send the E2E Resv message into the relevant IPsec tunnel terminating on the Aggregator.
如果聚合器和解聚合器同时充当IPsec安全网关，则解聚合器必须将E2E Resv消息发送到聚合器上终止的相关IPsec隧道中。
The Aggregator is responsible for ensuring that there is sufficient bandwidth available and reserved over the appropriate TE tunnel to the Deaggregator for the E2E reservation.
聚合器负责确保有足够的带宽可用，并通过适当的TE隧道为E2E预留到解聚合器。
On receipt of the E2E Resv message, the Aggregator MUST first perform the final mapping onto the final TE tunnel (if the previous mapping was only a tentative one).
收到E2E Resv消息后，聚合器必须首先执行到最终TE隧道的最终映射（如果之前的映射只是暂时的）。
If the tunnel did not change during the final mapping, the Aggregator continues the processing of the E2E Resv as described in the four following paragraphs.
如果通道在最终映射期间没有改变，聚合器将继续处理E2E Resv，如以下四段所述。
The aggregator calculates the size of the resource request using traditional RSVP procedures. That is, it follows the procedures in [RSVP] to determine the resource requirements from the Sender Tspec and the Flowspec contained in the Resv. Then it compares the resource request with the available resources of the selected TE tunnel.
聚合器使用传统的RSVP过程计算资源请求的大小。也就是说，它遵循[RSVP]中的程序来确定发送方Tspec和Resv中包含的流程规范的资源需求。然后将资源请求与所选TE隧道的可用资源进行比较。
If sufficient bandwidth is available on the final TE tunnel, the Aggregator MUST update its internal understanding of how much of the TE tunnel is in use and MUST forward the E2E Resv messages to the corresponding PHOP.
如果最终TE隧道上有足够的带宽可用，聚合器必须更新其内部对TE隧道使用量的了解，并且必须将E2E Resv消息转发给相应的PHOP。
As noted in [RSVP-AGG], a range of policies MAY be applied to the re-sizing of the aggregate reservation (in this case, the TE tunnel). For example, the policy may be that the reserved bandwidth of the tunnel can only be changed by configuration. More dynamic policies are also possible, whereby the aggregator may attempt to increase the reserved bandwidth of the tunnel in response to the amount of allocated bandwidth that has been used by E2E reservations. Furthermore, to avoid the delay associated with the increase of the tunnel size, the Aggregator may attempt to anticipate the increases in demand and adjust the TE tunnel size ahead of actual needs by E2E reservations. In order to reduce disruptions, the Aggregator SHOULD use "make-before-break" procedures as described in [RSVP-TE] to alter the TE tunnel bandwidth.
如[RSVP-AGG]中所述，一系列策略可应用于重新调整总保留的大小（在本例中为TE隧道）。例如，策略可以是隧道的保留带宽只能通过配置来改变。更动态的策略也是可能的，由此聚合器可以尝试增加隧道的保留带宽，以响应E2E保留所使用的分配带宽量。此外，为了避免与隧道尺寸增加相关的延迟，聚合器可尝试预测需求的增加，并通过E2E预订在实际需求之前调整TE隧道尺寸。为了减少中断，聚合器应使用[RSVP-TE]中所述的“先通后断”程序来改变TE隧道带宽。
If sufficient bandwidth is not available on the final TE tunnel, the Aggregator MUST follow the normal RSVP procedure for a reservation being placed with insufficient bandwidth to support it. That is, the reservation is not installed and a ResvError is sent back toward the receiver.
如果最终TE隧道上没有足够的带宽可用，则聚合器必须遵循正常的RSVP过程，以便在带宽不足的情况下进行预留。也就是说，未安装预订，并且会向接收方发回一个ResvError。
If the tunnel did change during the final mapping, the Aggregator MUST first resend to the Deaggregator an E2E Path message with the IF_ID RSVP_HOP data interface identification identifying the final TE tunnel. If needed, the ADSPEC information in this E2E Path message SHOULD be updated. Then the Aggregator MUST
如果隧道在最终映射期间确实发生了变化，则聚合器必须首先向解聚合器重新发送一条E2E路径消息，该消息带有识别最终TE隧道的If_ID RSVP_HOP数据接口标识。如果需要，应更新此E2E路径消息中的ADSPEC信息。那么聚合器必须
- either drop the E2E Resv message
- 或者删除E2E Resv消息
- or proceed with the processing of the E2E Resv in the same manner as in the case where the tunnel did not change (described above).
- 或者以与隧道未改变（如上所述）的情况相同的方式继续处理E2E Resv。
In the former case, admission control over the final TE tunnel (and forwarding of E2E Resv message upstream toward the sender) would only occur when the Aggregator received the subsequent E2E Resv message (that will be sent by the Deaggregator in response to the resent E2E Path). In the latter case, admission control over the final tunnel is carried out immediately by the Aggregator, and if successful the E2E Resv message is generated upstream toward the sender.
在前一种情况下，只有当聚合器接收到后续的E2E Resv消息（该消息将由解聚合器响应于重新发送的E2E路径而发送）时，才会发生对最终TE隧道的接纳控制（以及向发送者的E2E Resv消息的上游转发）。在后一种情况下，聚合器立即执行对最终隧道的接纳控制，如果成功，则向发送方上游生成E2E Resv消息。
Upon receipt of an E2E ResvConf from the Aggregator, the Deaggregator MUST forward the E2E ResvConf downstream toward the receiver. In doing so, the Deaggregator sets the destination address in the IP header of the E2E ResvConf message to the IP address found in the RESV_CONFIRM object of the corresponding Resv. The Deaggregator also sets the Router Alert.
从聚合器接收到E2E ResvConf后，解聚合器必须将E2E ResvConf转发至下游接收器。在此过程中，解聚集器将E2E ResvConf消息的IP报头中的目标地址设置为在相应RESV的RESV_确认对象中找到的IP地址。解聚集器还设置路由器警报。
When the Aggregator receives a data packet belonging to an E2E reservations currently mapped over a given TE tunnel, the Aggregator MUST encapsulate the packet into that TE tunnel.
当聚合器接收到属于当前映射到给定TE隧道上的E2E保留的数据包时，聚合器必须将该数据包封装到该TE隧道中。
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Aggregator MUST also encapsulate the data packet into the relevant IPsec tunnel terminating on the Deaggregator before transmission into the MPLS TE tunnel.
如果聚合器和解聚合器也充当IPsec安全网关，则聚合器还必须在传输到MPLS TE隧道之前将数据包封装到终止于解聚合器的相关IPsec隧道中。
E2E reservations are removed in the usual way via PathTear, ResvTear, timeout, or as the result of an error condition. When a reservation is removed, the Aggregator MUST update its local view of the resources available on the corresponding TE tunnel accordingly.
E2E保留是通过PathTear、ResvTear、timeout或作为错误条件的结果以通常的方式删除的。删除保留后，聚合器必须相应地更新相应TE隧道上可用资源的本地视图。
Should a TE tunnel go away (presumably due to a configuration change, route change, or policy event), the Aggregator behaves much like a conventional RSVP router in the face of a link failure. That is, it may try to forward the Path messages onto another tunnel, if routing and policy permit, or it may send Path_Error messages to the sender if a suitable tunnel does not exist. In case the Path messages are forwarded onto another tunnel, which terminates on a different Deaggregator, or the reservation is torn down via Path Error messages, the reservation state established on the router acting as the Deaggregator before the TE tunnel went away, will time out since it will no longer be refreshed.
如果TE隧道消失（可能是由于配置更改、路由更改或策略事件），聚合器的行为与传统RSVP路由器在面临链路故障时的行为非常相似。也就是说，如果路由和策略允许，它可以尝试将路径消息转发到另一个隧道，或者如果不存在合适的隧道，它可以向发送方发送路径错误消息。如果路径消息被转发到另一个隧道，该隧道在不同的解聚集器上终止，或者通过路径错误消息取消保留，则在TE隧道消失之前作为解聚集器的路由器上建立的保留状态将超时，因为它将不再被刷新。
Aggregator Deaggregator
聚合器-解聚器
(*)
RSVP-TE Path
=========================>
(*)
RSVP-TE Path
=========================>
RSVP-TE Resv
<=========================
(**)
RSVP-TE Resv
<=========================
(**)
E2E Path
-------------->
(1)
E2E Path
------------------------------->
(2)
E2E Path
----------->
E2E Path
-------------->
(1)
E2E Path
------------------------------->
(2)
E2E Path
----------->
E2E Resv
<-----------
(3)
E2E Resv
<-----------------------------
(4)
E2E Resv
<-------------
E2E Resv
<-----------
(3)
E2E Resv
<-----------------------------
(4)
E2E Resv
<-------------
(*) Aggregator is triggered to pre-establish the TE tunnel(s)
（*）聚合器被触发以预建立TE隧道
(**) TE tunnel(s) are pre-established
(**) TE tunnel(s) are pre-established
(1) Aggregator tentatively selects the TE tunnel and forwards E2E path to Deaggregator
(1) 聚合器暂时选择TE隧道并将E2E路径转发给解聚合器
(2) Deaggregator forwards the E2E Path toward the receiver
(2) 解聚集器将E2E路径转发至接收器
(3) Deaggregator forwards the E2E Resv to the Aggregator
(3) 解聚集器将E2E Resv转发给聚集器
(4) Aggregator selects final TE tunnel, checks that there is sufficient bandwidth on TE tunnel, and forwards E2E Resv to PHOP. If final tunnel is different from tunnel tentatively selected, the Aggregator re-sends an E2E Path with an updated IF_ID RSVP_HOP and possibly an updated ADSPEC.
(4) 聚合器选择最终的TE隧道，检查TE隧道上是否有足够的带宽，并将E2E Resv转发给PHOP。如果最终隧道与暂时选择的隧道不同，则聚合器重新发送E2E路径，其中包含更新的If_ID RSVP_HOP和可能更新的ADSPEC。
The procedures defined in this document are applicable to all the following cases:
本文件中定义的程序适用于以下所有情况：
(1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE tunnels.
(1) 通过IPv4 TE隧道聚合E2E IPv4 RSVP保留。
(2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE tunnels.
(2) 通过IPv6 TE隧道聚合E2E IPv6 RSVP保留。
(3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE tunnels, provided a mechanism such as [6PE] is used by the Aggregator and Deaggregator for routing of IPv6 traffic over an IPv4 MPLS core.
(3) 通过IPv4 TE隧道聚合E2E IPv6 RSVP保留，前提是聚合器和解聚合器使用[6PE]等机制在IPv4 MPLS核心上路由IPv6流量。
(4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE tunnels, provided a mechanism is used by the Aggregator and Deaggregator for routing IPv4 traffic over IPv6 MPLS.
(4) 通过IPv6 TE隧道聚合E2E IPv4 RSVP保留，前提是聚合器和解聚合器使用一种机制通过IPv6 MPLS路由IPv4流量。
The procedures defined in this document are applicable to many types of E2E RSVP reservations including the following cases:
本文件中定义的程序适用于多种类型的E2E RSVP保留，包括以下情况：
(1) The E2E RSVP reservation is a per-flow reservation where the flow is characterized by the usual 5-tuple
(1) E2E RSVP保留是每流保留，其中流以通常的5元组为特征
(2) The E2E reservation is an aggregate reservation for multiple flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the set of flows is characterized by the <source address, destination address, DSCP>
(2) E2E保留是[RSVP-AGG]或[RSVP-GEN-AGG]中所述的多个流的聚合保留，其中流集的特征是<source address，destination address，DSCP>
(3) The E2E reservation is a reservation for an IPsec protected flow. For example, where the flow is characterized by the <source address, destination address, SPI> as described in [RSVP-IPSEC].
(3) E2E保留是IPsec保护流的保留。例如，其中流以[RSVP-IPSEC]中所述的<source address，destination address，SPI>为特征。
An example application of the procedures specified in this document is admission control of voice and video in environments with a very high number of hosts. In the example illustrated below, hosts generate E2E per-flow reservations for each of their video streams associated with a video-conference, each of their audio streams associated with a video-conference and each of their voice calls.
本文件中规定程序的一个示例应用是在主机数量非常多的环境中对语音和视频进行准入控制。在下面所示的示例中，主机为其与视频会议相关联的每个视频流、其与视频会议相关联的每个音频流以及其每个语音呼叫生成E2E每流预约。
These reservations are aggregated over MPLS DS-TE tunnels over the packet core. The mapping policy defined by the user may be that all the reservations for audio and voice streams are mapped onto DS-TE tunnels of Class-Type 1, while reservations for video streams are mapped onto DS-TE tunnels of Class-Type 0.
这些保留通过包核心上的MPLS DS-TE隧道聚合。用户定义的映射策略可以是，音频和语音流的所有保留映射到类类型1的DS-TE隧道，而视频流的保留映射到类类型0的DS-TE隧道。
------ ------
| H |# ------- -------- #| H |
| |\#| | ----- | |#/| |
-----| \| Agg | | T | | Deag |/ ------
| |==========================| |
------ /| |::::::::::::::::::::::::::| |\ ------
| H |/#| | ----- | |#\| H |
| |# ------- -------- #| |
------ ------
------ ------
| H |# ------- -------- #| H |
| |\#| | ----- | |#/| |
-----| \| Agg | | T | | Deag |/ ------
| |==========================| |
------ /| |::::::::::::::::::::::::::| |\ ------
| H |/#| | ----- | |#\| H |
| |# ------- -------- #| |
------ ------
H = Host Agg = Aggregator (TE tunnel Head-end) Deagg = Deaggregator (TE tunnel Tail-end) T = Transit LSR
H=主机Agg=聚合器（TE隧道前端）Deagg=解聚器（TE隧道后端）T=运输LSR
/ = E2E RSVP reservation for a Voice flow
# = E2E RSVP reservation for a Video flow
== = DS-TE tunnel from Class-Type 1
:: = DS-TE tunnel from Class-Type 0
/ = E2E RSVP reservation for a Voice flow
# = E2E RSVP reservation for a Video flow
== = DS-TE tunnel from Class-Type 1
:: = DS-TE tunnel from Class-Type 0
An example application of the procedures specified in this document is voice call admission control in large-scale telephony trunking environments. A Trunk VoIP Gateway may generate one aggregate RSVP reservation for all the calls in place toward another given remote Trunk VoIP Gateway (with resizing of this aggregate reservation in a step function depending on the current number of calls). In turn, these reservations may be aggregated over MPLS TE tunnels over the packet core so that tunnel Head-ends act as Aggregators and perform admission control of Trunk Gateway reservations into MPLS TE tunnels. The MPLS TE tunnels may be protected by MPLS Fast Reroute. This scenario is illustrated below:
本文档中规定的程序的一个示例应用是大规模电话中继环境中的语音呼叫允许控制。中继VoIP网关可以为指向另一个给定远程中继VoIP网关的所有呼叫生成一个聚合RSVP预留（根据当前呼叫数在step函数中调整此聚合预留的大小）。反过来，这些保留可以在分组核心上的MPLS-TE隧道上聚合，以便隧道头端充当聚合器，并对MPLS-TE隧道中的中继网关保留执行接纳控制。MPLS TE隧道可以通过MPLS快速重路由进行保护。该场景如下图所示：
------ ------
| GW |\ ------- -------- /| GW |
| |\\| | ----- | |//| |
-----| \| Agg | | T | | Deag |/ ------
| |==========================| |
------ /| | | | | |\ ------
| GW |//| | ----- | |\\| GW |
| |/ ------- -------- \| |
------ ------
------ ------
| GW |\ ------- -------- /| GW |
| |\\| | ----- | |//| |
-----| \| Agg | | T | | Deag |/ ------
| |==========================| |
------ /| | | | | |\ ------
| GW |//| | ----- | |\\| GW |
| |/ ------- -------- \| |
------ ------
GW = VoIP Gateway Agg = Aggregator (TE tunnel Head-end) Deagg = Deaggregator (TE tunnel Tail-end) T = Transit LSR
GW=VoIP网关Agg=聚合器（TE隧道前端）Deagg=解聚器（TE隧道后端）T=传输LSR
/ = Aggregate Gateway to Gateway E2E RSVP reservation
== = TE tunnel
/ = Aggregate Gateway to Gateway E2E RSVP reservation
== = TE tunnel
In the environments concerned by this document, RSVP messages are used to control resource reservations for E2E flows outside the MPLS region as well as to control resource reservations for MPLS TE tunnels inside the MPLS region. To ensure the integrity of the associated reservation and admission control mechanisms, the mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] can be used. The mechanisms protect the integrity of RSVP messages hop-by-hop and provide node authentication, thereby protecting against corruption and spoofing of RSVP messages. These hop-by-hop integrity mechanisms can naturally be used to protect the RSVP messages used for E2E reservations outside the MPLS region, to protect RSVP messages used for MPLS TE tunnels inside the MPLS region, or for both. These hop-by-hop RSVP integrity mechanisms can also be used to protect RSVP messages used for E2E reservations when those transit through the MPLS region. This is because the Aggregator and Deaggregator behave as RSVP neighbors from the viewpoint of the E2E flows (even if they are not necessarily IP neighbors nor RSVP-TE neighbors). In that case, the Aggregator and Deaggregator need to use a pre-shared secret.
在本文档所涉及的环境中，RSVP消息用于控制MPLS区域外E2E流的资源预留，以及控制MPLS区域内MPLS TE隧道的资源预留。为了确保相关保留和接纳控制机制的完整性，可以使用[RSVP-CRYPTO1]和[RSVP-CRYPTO2]中定义的机制。这些机制逐跳保护RSVP消息的完整性，并提供节点身份验证，从而防止RSVP消息的损坏和欺骗。这些逐跳完整性机制自然可用于保护用于MPLS区域外E2E保留的RSVP消息，或用于保护用于MPLS区域内MPLS TE隧道的RSVP消息，或用于两者。这些逐跳RSVP完整性机制还可用于在E2E保留通过MPLS区域传输时保护用于E2E保留的RSVP消息。这是因为从E2E流的角度来看，聚合器和解聚合器的行为类似于RSVP邻居（即使它们不一定是IP邻居或RSVP-TE邻居）。在这种情况下，聚合器和解聚合器需要使用预先共享的秘密。
As discussed in Section 6 of [RSVP-TE], filtering of traffic associated with an MPLS TE tunnel can only be done on the basis of an MPLS label, instead of the 5-tuple of conventional RSVP reservation as per [RSVP]. Thus, as explained in [RSVP-TE], an administrator may wish to limit the domain over which TE tunnels (which are used for aggregation of RSVP E2E reservations as per this specification) can be established. See Section 6 of [RSVP-TE] for a description of how
如[RSVP-TE]第6节所述，与MPLS TE隧道相关联的流量过滤只能在MPLS标签的基础上进行，而不是根据[RSVP]进行的常规RSVP保留的5元组。因此，如[RSVP-TE]中所述，管理员可能希望限制可以建立TE隧道（根据本规范用于聚合RSVP E2E保留）的域。参见[RSVP-TE]第6节，了解如何
filtering of RSVP messages associated with MPLS TE tunnels can be deployed to that end.
与MPLS TE隧道相关联的RSVP消息的过滤可以部署到该端。
This document is based in part on [RSVP-AGG], which specifies aggregation of RSVP reservations. Section 5 of [RSVP-AGG] raises the point that because many E2E flows may share an aggregate reservation, if the security of an aggregate reservation is compromised, there is a multiplying effect in the sense that it can in turn compromise the security of many E2E reservations whose quality of service depends on the aggregate reservation. This concern applies also to RSVP Aggregation over TE tunnels as specified in the present document. However, the integrity of MPLS TE tunnels operation can be protected using the mechanisms discussed in the previous paragraphs. Also, while [RSVP-AGG] specifies RSVP Aggregation over dynamically established aggregate reservations, the present document restricts itself to RSVP Aggregation over pre-established TE tunnels. This further reduces the security risks.
本文档部分基于[RSVP-AGG]，其中规定了RSVP保留的汇总。[RSVP-AGG]的第5节提出了一个观点，即由于许多E2E流可能共享一个聚合保留，如果聚合保留的安全性受到损害，则会产生倍增效应，即它反过来会损害许多E2E保留的安全性，这些E2E保留的服务质量取决于聚合保留。该问题也适用于本文件中规定的TE隧道上的RSVP聚合。但是，可以使用前面段落中讨论的机制来保护MPLS TE隧道操作的完整性。此外，虽然[RSVP-AGG]在动态建立的聚合保留上指定RSVP聚合，但本文档仅限于在预先建立的TE隧道上进行RSVP聚合。这进一步降低了安全风险。
In the case where the Aggregators dynamically resize the TE tunnels based on the current level of reservation, there are risks that the TE tunnels used for RSVP aggregation hog resources in the core, which could prevent other TE tunnels from being established. There are also potential risks that such resizing results in significant computation and signaling as well as churn on tunnel paths. Such risks can be mitigated by configuration options allowing control of TE tunnel dynamic resizing (maximum TE tunnel size, maximum resizing frequency, etc.), and/or possibly by the use of TE preemption.
在聚合器根据当前保留级别动态调整TE隧道大小的情况下，TE隧道用于核心中的RSVP聚合hog资源存在风险，这可能会阻止建立其他TE隧道。同样存在这样的潜在风险，即这种调整会导致大量的计算和信令，以及隧道路径上的混乱。可通过允许控制TE隧道动态调整大小（最大TE隧道大小、最大调整频率等）的配置选项和/或可能通过使用TE抢占来缓解此类风险。
Section 5 of [RSVP-AGG] also discusses a security issue specific to RSVP aggregation related to the necessary modification of the IP Protocol number in RSVP E2E Path messages that traverses the aggregation region. This security issue does not apply to the present document since aggregation of RSVP reservation over TE tunnels does not use this approach of changing the protocol number in RSVP messages.
[RSVP-AGG]第5节还讨论了特定于RSVP聚合的安全问题，该问题与穿过聚合区域的RSVP E2E路径消息中IP协议号的必要修改有关。此安全问题不适用于本文档，因为TE隧道上的RSVP保留聚合没有使用这种方法来更改RSVP消息中的协议号。
Section 7 of [LSP-HIER] discusses security considerations stemming from the fact that the implicit assumption of a binding between data interface and the interface over which a control message is sent is no longer valid. These security considerations are equally applicable to the present document.
[LSP-HIER]的第7节讨论了由于数据接口和发送控制消息的接口之间绑定的隐式假设不再有效这一事实而产生的安全考虑。这些安全考虑同样适用于本文件。
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Security Considerations of [SEC-ARCH] apply.
如果聚合器和解聚合器也充当IPsec安全网关，则[SEC-ARCH]的安全注意事项适用。
This document builds on the [RSVP-AGG], [RSVP-TUN], and [LSP-HIER] specifications. We would like to thank Tom Phelan, John Drake, Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol Iturralde, and James Gibson for their input into this document.
本文件以[RSVP-AGG]、[RSVP-TUN]和[LSP-HIER]规范为基础。我们要感谢Tom Phelan、John Drake、Arthi Ayyangar、Fred Baker、Subha Dhesikan、Kwok Ho Chan、Carol Iturralde和James Gibson对本文件的投入。
[CONTROLLED] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[受控]Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[DIFFSERV]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务的架构”，RFC 24751998年12月。
[DSTE-PROTO] Le Faucheur, F., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[DSTE-PROTO]Le Faucheur，F.，“支持区分服务的MPLS流量工程的协议扩展”，RFC 41242005年6月。
[GUARANTEED] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[保证]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月。
[INT-DIFF] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[INT-DIFF]Bernet，Y.，Ford，P.，Yavatkar，R.，Baker，F.，Zhang，L.，Speer，M.，Braden，R.，Davie，B.，Wroclawski，J.，E.Felstaine，“区分服务网络上的综合服务运营框架”，RFC 29982000年11月。
[INT-SERV] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[INT-SERV]Braden，R.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 16331994年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[LSP-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[LSP-HIER]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[MPLS-TE] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[MPLS-TE]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[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月。
[RSVP-AGG] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RSVP-AGG]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 31752001年9月。
[RSVP-CRYPTO1] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RSVP-CRYPTO1]Baker，F.，Lindell，B.，和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RSVP-CRYPTO2] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RSVP-CRYPTO2]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[SEC-ARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[SEC-ARCH]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[6PE]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛”，RFC 4798，2007年2月。
[AUTOMESH] Vasseur and Leroux, "Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership", Work in Progress.
[AUTOMESH]Vasseur和Leroux，“用于发现多协议（MPLS）标签交换路由器（LSR）流量工程（TE）mesh成员资格的路由扩展”，正在进行中。
[DIFF-MPLS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[DIFF-MPLS]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DSTE-REQ]Le Faucheur，F.和W.Lai，“支持区分服务感知MPLS流量工程的要求”，RFC 3564，2003年7月。
[L-RSVP] Manner, et al., Localized RSVP for Controlling RSVP Proxies, Work in Progress.
[L-RSVP]Method等，用于控制RSVP代理的本地化RSVP，正在进行的工作。
[RSVP-APPID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RSVP-APPID]Yadav，S.，Yavatkar，R.，Pabbati，R.，Ford，P.，Moore，T.，Herzog，S.，和R.Hess，“RSVP的身份表示”，RFC 31822001年10月。
[RSVP-GEN-AGG] Le Faucheur, R., Davie, B., Bose, P., Martin, L., Christou, C., Davenport, M., and A. Hamilton, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", Work in Progress, January 2007.
[RSVP-GEN-AGG]Le Faucheur，R.，Davie，B.，Bose，P.，Martin，L.，Christou，C.，Davenport，M.，和A.Hamilton，“通用聚合资源预留协议（RSVP）预留”，正在进行中的工作，2007年1月。
[RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RSVP-IPSEC]Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2207，1997年9月。
[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RSVP-PREEMEP]Herzog，S.，“信号抢占优先权政策要素”，RFC 31812001年10月。
[RSVP-PROXY1] Gai, et al., RSVP Proxy, Work in Progress.
[RSVP-PROXY1]Gai等人，RSVP代理，正在进行的工作。
[RSVP-PROXY2] Le Faucheur, et al., RSVP Proxy Approaches, Work in Progress.
[RSVP-PROXY2]Le Faucheur等人，RSVP代理方法，正在进行中。
[RSVP-TUN] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RSVP-TUN]Terzis，A.，Krawczyk，J.，Wroclawski，J.，和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[SIP-RSVP] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[SIP-RSVP]Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator
附录A-在RSVP聚合器上可选使用RSVP代理
A number of approaches ([RSVP-PROXY1],[RSVP-PROXY2], [L-RSVP]) have been, or are being, discussed in the IETF in order to allow a network node to behave as an RSVP proxy which:
IETF中已经或正在讨论许多方法（[RSVP-PROXY1]、[RSVP-PROXY2]、[L-RSVP]），以允许网络节点作为RSVP代理，其：
- originates the Resv Message (in response to the Path message) on behalf of the destination node
- 代表目标节点发起Resv消息（响应路径消息）
- originates the Path message (in response to some trigger) on behalf of the source node.
- 代表源节点生成路径消息（响应某些触发器）。
We observe that such approaches may optionally be used in conjunction with the aggregation of RSVP reservations over MPLS TE tunnels as specified in this document. In particular, we consider the case where the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy.
我们观察到，此类方法可选择性地与本文件中规定的MPLS TE隧道上RSVP保留的聚合一起使用。特别地，我们考虑RSVP聚合器/解聚合器也表现为RSVP代理的情况。
The information in this Appendix is purely informational and illustrative.
本附录中的信息仅供参考和说明。
As discussed in [RSVP-PROXY1]:
如[RSVP-PROXY1]中所述：
"The proxy functionality does not imply merely generating a single Resv message. Proxying the Resv involves installing state in the node doing the proxy i.e. the proxying node should act as if it had received a Resv from the true endpoint. This involves reserving resources (if required), sending periodic refreshes of the Resv message and tearing down the reservation if the Path is torn down."
“代理功能并不意味着仅生成一条Resv消息。代理Resv涉及在执行代理的节点中安装状态，即代理节点的行为应与从真实端点接收到Resv的行为相同。这涉及保留资源（如果需要），发送Resv消息的定期刷新，如果路径被删除，则删除保留。“
Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may effectively perform resource reservation over the MPLS TE tunnel (and hence over the whole segment between the RSVP Aggregator and the RSVP Deaggregator) even if the RSVP signaling only takes place upstream of the MPLS TE tunnel (i.e., between the host and the RSVP aggregator).
因此，当充当RSVP代理时，即使RSVP信令仅发生在MPLS-TE隧道的上游（即主机和RSVP聚合器之间），RSVP聚合器也可以有效地在MPLS-TE隧道上执行资源预留（从而在RSVP聚合器和RSVP解聚器之间的整个段上）。
Also, the RSVP Proxy can generate the Path message on behalf of the remote source host in order to achieve reservation in the return direction (i.e., from RSVP aggregator/Deaggregator to host).
此外，RSVP代理可以代表远程源主机生成路径消息，以便在返回方向上实现保留（即，从RSVP聚合器/解聚合器到主机）。
The resulting Signaling Flow is illustrated below, covering reservations for both directions:
产生的信令流如下所示，包括两个方向的预留：
|----| |--------------| |------| |--------------| |----|
| | | Aggregator/ | | MPLS | | Aggregator/ | | |
|Host| | Deaggregator/| | cloud| | Deaggregator/| |Host|
| | | RSVP Proxy | | | | RSVP Proxy | | |
|----| |--------------| |------| |--------------| |----|
|----| |--------------| |------| |--------------| |----|
| | | Aggregator/ | | MPLS | | Aggregator/ | | |
|Host| | Deaggregator/| | cloud| | Deaggregator/| |Host|
| | | RSVP Proxy | | | | RSVP Proxy | | |
|----| |--------------| |------| |--------------| |----|
==========TE Tunnel==========>
<========= TE Tunnel==========
==========TE Tunnel==========>
<========= TE Tunnel==========
Path Path
------------> (1)-\ /-(i) <----------
Resv | | Resv
<------------ (2)-/ \-(ii) ------------>
Path Path
<------------ (3) (iii) ------------>
Resv Resv
------------> <------------
Path Path
------------> (1)-\ /-(i) <----------
Resv | | Resv
<------------ (2)-/ \-(ii) ------------>
Path Path
<------------ (3) (iii) ------------>
Resv Resv
------------> <------------
(1)(i) : Aggregator/Deaggregator/Proxy receives Path message, selects the TE tunnel, performs admission control over the TE tunnel. (1) and (i) happen independently of each other.
（1） （i）：聚合器/解聚合器/代理接收路径消息，选择TE隧道，对TE隧道执行准入控制。（1） 和（i）相互独立地发生。
(2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message toward Host. (2) is triggered by (1) and (ii) is triggered by (i). Before generating this Resv message, the Aggregator/Proxy performs admission control of the corresponding reservation over the TE tunnel that will eventually carry the corresponding traffic.
（2） （ii）：聚合器/解聚合器/代理向主机生成Resv消息。（2） 由（1）触发，且（ii）由（i）触发。在生成此Resv消息之前，聚合器/代理通过最终将承载相应流量的TE隧道执行相应保留的准入控制。
(3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message toward Host for reservation in return direction. The actual trigger for this depends on the actual RSVP proxy solution. As an example, (3) and (iii) may simply be triggered respectively by (1) and (i).
（3） （iii）：聚合器/解聚合器/代理在返回方向生成指向主机的路径消息以进行保留。此操作的实际触发器取决于实际的RSVP代理解决方案。例如，（3）和（iii）可以简单地分别由（1）和（i）触发。
Note that the details of the signaling flow may vary slightly depending on the actual approach used for RSVP Proxy. For example, if the [L-RSVP] approach was used instead of [RSVP-PROXY1], an additional PathRequest message would be needed from host to Aggregator/Deaggregator/Proxy in order to trigger the generation of the Path message for return direction.
请注意，信令流的细节可能略有不同，这取决于用于RSVP代理的实际方法。例如，如果使用[L-RSVP]方法而不是[RSVP-PROXY1]，则需要从主机到聚合器/解聚合器/代理的额外PathRequest消息，以便触发生成返回方向的路径消息。
But regardless of the details of the call flow and of the actual RSVP Proxy approach, RSVP proxy may optionally be deployed in combination with RSVP Aggregation over MPLS TE tunnels, in such a way that
但是，不管呼叫流和实际RSVP代理方法的细节如何，RSVP代理可以选择性地与MPLS TE隧道上的RSVP聚合一起部署，其方式如下：
ensures (when used on both the Host-Aggregator and Deaggregator-Host sides, and when both end systems support RSVP):
确保（在主机聚合器和解聚合器主机端使用时，以及在两个终端系统都支持RSVP时）：
(i) admission control and resource reservation is performed on every segment of the end-to-end path (i.e., between source host and Aggregator, over the TE tunnel between the Aggregator and Deaggregator that itself has been subject to admission control by MPLS TE, between Deaggregator and destination host).
(i) 在端到端路径的每个段上（即，在源主机和聚合器之间，在聚合器和解聚合器之间的TE隧道上，在解聚合器和目标主机之间，通过MPLS TE对其本身进行准入控制）执行准入控制和资源预留。
(ii) this is achieved in both directions.
（ii）这是在两个方向上实现的。
(iii) RSVP signaling is localized between hosts and Aggregator/Deaggregator, which may result in significant reduction in reservation establishment delays (and in turn in post-dial delay in the case where these reservations are pre-conditions for voice call establishment), particularly in the case where the MPLS TE tunnels span long distances with high propagation delays.
（iii）RSVP信令在主机和聚合器/解聚合器之间进行本地化，这可能会显著减少预约建立延迟（如果这些预约是语音呼叫建立的先决条件，则反过来减少拨号后延迟），特别是在MPLS-TE隧道跨越具有高传播延迟的长距离的情况下。
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for VoIP Call Admission Control (CAC)
附录B-用于VoIP呼叫允许控制（CAC）的DSTE隧道上RSVP聚合的示例使用
This Appendix presents an example scenario where the mechanisms described in this document are used, in combination with other mechanisms specified by the IETF, to achieve Call Admission Control (CAC) of Voice over IP (VoIP) traffic over the packet core.
本附录给出了一个示例场景，其中本文档中描述的机制与IETF指定的其他机制结合使用，以实现分组核心上IP语音（VoIP）流量的呼叫允许控制（CAC）。
The information in this Appendix is purely informational and illustrative.
本附录中的信息仅供参考和说明。
Consider the scenario depicted in Figure B1. VoIP Gateways GW1 and GW2 are both signaling and media gateways. They are connected to an MPLS network via edge routers PE1 and PE2, respectively. In each direction, a DSTE tunnel passes from the Head-end edge router, through core network P routers, to the Tail-end edge router. GW1 and GW2 are RSVP-enabled. The RSVP reservations established by GW1 and GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For reservations going from GW1 to GW2, PE1 serves as the Aggregator/Head-end and PE2 serves as the Deaggregator/Tail-end. For reservations going from GW2 to GW2, PE2 serves as the Aggregator/Head-end and PE1 serves as the Deaggregator/Tail-end.
考虑图B1中描述的场景。VoIP网关GW1和GW2都是信令网关和媒体网关。它们分别通过边缘路由器PE1和PE2连接到MPLS网络。在每个方向上，DSTE隧道从前端边缘路由器经过核心网络P路由器，到达后端边缘路由器。GW1和GW2已启用RSVP。GW1和GW2建立的RSVP保留由DS-TE隧道上的PE1和PE2汇总。对于从GW1到GW2的预订，PE1充当聚合器/前端，PE2充当解聚合器/后端。对于从GW2到GW2的预订，PE2充当聚合器/前端，PE1充当解聚合器/后端。
To determine whether there is sufficient bandwidth in the MPLS core to complete a connection, the originating and destination GWs each send for each connection a Resource Reservation Protocol (RSVP) bandwidth request to the network PE router to which it is connected. As part of its Aggregator role, the PE router effectively performs
为了确定MPLS核心中是否有足够的带宽来完成连接，发起和目标GWs分别为每个连接向其所连接的网络PE路由器发送资源预留协议（RSVP）带宽请求。作为聚合器角色的一部分，PE路由器有效地执行
admission control of the bandwidth request generated by the GW onto the resources of the corresponding DS-TE tunnel.
允许控制GW生成的带宽请求进入相应DS-TE隧道的资源。
In this example, in addition to behaving as Aggregator/Deaggregator, PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path message from a GW, it does not propagate the Path message any further. Rather, the PE performs admission control of the bandwidth signaled in the Path message over the DSTE tunnel toward the destination. Assuming there is enough bandwidth available on that tunnel, the PE adjusts its bookkeeping of remaining available bandwidth on the tunnel and generates a Resv message back toward the GW to confirm resources have been reserved over the DSTE tunnel.
在本例中，除了充当聚合器/解聚合器外，PE1和PE2还充当RSVP代理。因此，当PE从GW接收到Path消息时，它不会进一步传播Path消息。相反，PE通过DSTE隧道向目的地执行路径消息中发信号的带宽的接纳控制。假设该隧道上有足够的可用带宽，PE将调整其对隧道上剩余可用带宽的记账，并向GW生成一条Resv消息，以确认已通过DSTE隧道保留了资源。
,-. ,-.
_.---' `---' `-+
,-'' +------------+ :
( | | `.
\ ,' CCA `. :
\ ,' | | `. ;
;' +------------+ `._
,'+ ; `.
,' -+ Application Layer' `.
SIP,' `---+ | ; `.SIP
,' `------+---' `.
,' `.
,' `.
,' ,-. ,-. `.
,' ,--+ `--+--'- --'\ `._
+-`--+_____+------+ { +----+ +----+ `. +------+_____+----+
|GW1 | RSVP| |______| P |___| P |______| | RSVP|GW2 |
| |-----| PE1 | { +----+ +----+ /+| PE2 |-----| |
| | | |==========================>| | | |
+-:--+ RTP | |<==========================| | RTP +-:--+
_|..__ +------+ { DSTE Tunnels ; +------+ __----|--.
_,' \-| ./ -'._ / |
| Access \ / +----+ \, |_ Access |
| Network | \_ | P | | / Network |
| / `| +----+ / | '
`--. ,.__,| | IP/MPLS Network / '---'- ----'
'`' '' ' .._,,'`.__ _/ '---' |
| '`''' |
C1 C2
,-. ,-.
_.---' `---' `-+
,-'' +------------+ :
( | | `.
\ ,' CCA `. :
\ ,' | | `. ;
;' +------------+ `._
,'+ ; `.
,' -+ Application Layer' `.
SIP,' `---+ | ; `.SIP
,' `------+---' `.
,' `.
,' `.
,' ,-. ,-. `.
,' ,--+ `--+--'- --'\ `._
+-`--+_____+------+ { +----+ +----+ `. +------+_____+----+
|GW1 | RSVP| |______| P |___| P |______| | RSVP|GW2 |
| |-----| PE1 | { +----+ +----+ /+| PE2 |-----| |
| | | |==========================>| | | |
+-:--+ RTP | |<==========================| | RTP +-:--+
_|..__ +------+ { DSTE Tunnels ; +------+ __----|--.
_,' \-| ./ -'._ / |
| Access \ / +----+ \, |_ Access |
| Network | \_ | P | | / Network |
| / `| +----+ / | '
`--. ,.__,| | IP/MPLS Network / '---'- ----'
'`' '' ' .._,,'`.__ _/ '---' |
| '`''' |
C1 C2
Figure B1. Integration of SIP Resource Management and RSVP Aggregation over MPLS TE Tunnels
图B1。MPLS-TE隧道上SIP资源管理和RSVP聚合的集成
[SIP-RSVP] discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session
[SIP-RSVP]讨论了如何将网络服务质量作为建立由会话发起的会话的先决条件
Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. The reservation of network resources are performed through a signaling protocol such as RSVP.
启动协议（SIP）。这些先决条件要求参与者在继续会话之前保留网络资源。网络资源的预留通过诸如RSVP之类的信令协议来执行。
Through the collaboration between SIP resource management, RSVP signaling, RSVP Aggregation and DS-TE as described above, we see that:
通过上述SIP资源管理、RSVP信令、RSVP聚合和DS-TE之间的协作，我们看到：
a) the PE and GW collaborate to determine whether there is enough bandwidth on the tunnel between the calling and called GWs to accommodate the connection,
a) PE和GW协作确定主叫和被叫GWs之间的隧道上是否有足够的带宽来容纳连接，
b) the corresponding accept/reject decision is communicated to the GWs on a connection-by-connection basis, and
b) 相应的接受/拒绝决定将在逐个连接的基础上传达给GWs，并且
c) the PE can optimize network resources by dynamically adjusting the bandwidth of each tunnel according to the load over that tunnel. For example, if a tunnel is operating at near capacity, the network may dynamically adjust the tunnel size within a set of parameters.
c) PE可以通过根据隧道上的负载动态调整每个隧道的带宽来优化网络资源。例如，如果隧道以接近容量运行，则网络可在一组参数内动态调整隧道大小。
We note that admission Control of voice calls over the core network capacity is achieved in a hierarchical manner whereby:
我们注意到，通过核心网络容量的语音呼叫的准入控制是以分层方式实现的，其中：
- DSTE tunnels are subject to Admission Control over the resources of the MPLS TE core
- DSTE隧道受对MPLS TE核心资源的准入控制
- Voice calls are subject to CAC over the DSTE tunnel bandwidth
- 语音呼叫受DSTE隧道带宽上的CAC限制
This hierarchy is a key element in the scalability of this CAC solution for voice calls over an MPLS Core.
此层次结构是此CAC解决方案在MPLS核心上进行语音呼叫的可扩展性的关键要素。
It is also possible for the GWs to use aggregate RSVP reservations themselves instead of per-call RSVP reservations. For example, instead of setting one reservation for each call GW1 has in place toward GW2, GW1 may establish one (or a small number of) aggregate reservations as defined in [RSVP-AGG] or [RSVP-GEN-AGG], which is used for all (or a subset of all) the calls toward GW2. This effectively provides an additional level of hierarchy whereby:
GWs也可以使用聚合RSVP预留，而不是每次呼叫RSVP预留。例如，GW1可以建立[RSVP-AGG]或[RSVP-GEN-AGG]中定义的一个（或少量）聚合保留，而不是为GW1对GW2的每个呼叫设置一个保留，用于对GW2的所有呼叫（或所有呼叫的子集）。这有效地提供了额外的层次结构，从而：
- DSTE tunnels are subject to Admission Control over the resources of the MPLS TE core
- DSTE隧道受对MPLS TE核心资源的准入控制
- Aggregate RSVP reservations (for the calls from one GW to another GW) are subject to Admission Control over the DSTE tunnels (as per the "RSVP Aggregation over TE Tunnels" procedures defined in this document)
- 根据本文件，从一条隧道到另一条隧道的预订（RSVP）是指从一条隧道到另一条隧道的预订
- Voice calls are subject to CAC by the GW over the aggregate reservation toward the appropriate destination GW.
- 语音呼叫由GW通过向相应目的地GW的总预订进行CAC。
This pushes even further the scalability limits of this voice CAC architecture.
这进一步推动了这种语音CAC体系结构的可扩展性限制。
Contributing Authors
撰稿人
This document was the collective work of several authors. The text and content were contributed by the editor and the co-authors listed below.
这份文件是几位作者的集体作品。文本和内容由编辑和下面列出的合著者提供。
Michael DiBiasio Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: dibiasio@cisco.com
Michael DiBiasio Cisco Systems，Inc.地址：美国马萨诸塞州伯斯堡海弗布鲁克路300号邮编：01719电子邮件：dibiasio@cisco.com
Bruce Davie Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: bdavie@cisco.com
Bruce Davie Cisco Systems，Inc.美国马萨诸塞州Boxborough市比弗布鲁克路300号邮编01719电子邮件：bdavie@cisco.com
Christou Christou Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA EMail: christou_chris@bah.com
Christou Christou Booz Allen Hamilton美国弗吉尼亚州麦克林格林斯博罗大道8283号邮编：22102电子邮件：Christou_chris@bah.com
Michael Davenport Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA EMail: davenport_michael@bah.com
迈克尔·达文波特·布兹·艾伦·汉密尔顿8283格林斯波罗大道麦克林，弗吉尼亚州22102美国电子邮件：达文波特_michael@bah.com
Jerry Ash AT&T 200 Laurel Avenue Middletown, NJ 07748 USA EMail: gash@att.com
Jerry Ash AT&T美国新泽西州米德尔敦劳雷尔大道200号07748电子邮件：gash@att.com
Bur Goode AT&T 32 Old Orchard Drive Weston, CT 06883 USA EMail: bgoode@att.com
Bur Goode AT&T 32 Old Orchard Drive Weston，CT 06883美国电子邮件：bgoode@att.com
Editor's Address
编辑地址
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France
Francois Le Faucheur Cisco Systems，Inc.绿边企业村-法国索菲亚-安提波利斯大街T3400号巴蒂门特酒店
EMail: flefauch@cisco.com
EMail: flefauch@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。