Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 5945 Cisco
Category: Informational J. Manner
ISSN: 2070-1721 Aalto University
D. Wing
Cisco
A. Guillou
SFR
October 2010
Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 5945 Cisco
Category: Informational J. Manner
ISSN: 2070-1721 Aalto University
D. Wing
Cisco
A. Guillou
SFR
October 2010
Resource Reservation Protocol (RSVP) Proxy Approaches
资源预留协议（RSVP）代理方法
Abstract
摘要
The Resource Reservation Protocol (RSVP) can be used to make end-to-end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described.
资源预留协议（RSVP）可用于在IP网络中进行端到端资源预留，以保证特定流所需的服务质量。RSVP假设给定流的数据发送方和接收方都参与RSVP信令。然而，在某些用例中，需要保留资源，但接收方、发送方或两者都不支持RSVP。本文档介绍了RSVP代理行为，允许RSVP路由器代表不支持RSVP的接收方或发送方启动或终止RSVP信令。这允许在端到端路径的关键子集上建立资源保留。本文档回顾了部署RSVP代理的概念性方法，并讨论了如何在发送方、接收方或两者均未参与RSVP的情况下，使RSVP保留与应用程序需求同步。本文档还指出了在部署给定的RSVP代理方法时可能需要对RSVP（或其他协议）进行扩展的地方。但是，此类扩展超出了本文件的范围。最后，描述了RSVP代理的实际用例。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5945.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5945.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. RSVP Proxy Behaviors ............................................6
2.1. RSVP Receiver Proxy ........................................6
2.2. RSVP Sender Proxy ..........................................7
3. Terminology .....................................................7
4. RSVP Proxy Approaches ...........................................9
4.1. Path-Triggered Receiver Proxy ..............................9
4.1.1. Mechanisms for Maximizing the Reservation Span .....11
4.2. Path-Triggered Sender Proxy for Reverse Direction .........15
4.3. Inspection-Triggered Proxy ................................18
4.4. STUN-Triggered Proxy ......................................21
4.5. Application_Entity-Controlled Proxy .......................23
4.5.1. Application_Entity-Controlled Sender Proxy
Using "RSVP over GRE" ..............................26
4.5.2. Application_Entity-Controlled Proxy via Co-Location 28
4.6. Policy_Server-Controlled Proxy ............................29
4.7. RSVP-Signaling-Triggered Proxy ............................32
4.8. Reachability Considerations ...............................33
5. Security Considerations ........................................34
6. Acknowledgments ................................................36
7. References .....................................................36
7.1. Normative References ......................................36
7.2. Informative References ....................................37
Appendix A. Use Cases for RSVP Proxies ...........................40
A.1. RSVP-Based VoD Admission Control in Broadband
Aggregation Networks ......................................40
A.2. RSVP-Based Voice/Video Connection Admission Control
(CAC) in Enterprise WAN ...................................43
A.3. RSVP Proxies for Mobile Access Networks ...................44
A.4. RSVP Proxies for Reservations in the Presence of IPsec
Gateways ..................................................46
1. Introduction ....................................................3
2. RSVP Proxy Behaviors ............................................6
2.1. RSVP Receiver Proxy ........................................6
2.2. RSVP Sender Proxy ..........................................7
3. Terminology .....................................................7
4. RSVP Proxy Approaches ...........................................9
4.1. Path-Triggered Receiver Proxy ..............................9
4.1.1. Mechanisms for Maximizing the Reservation Span .....11
4.2. Path-Triggered Sender Proxy for Reverse Direction .........15
4.3. Inspection-Triggered Proxy ................................18
4.4. STUN-Triggered Proxy ......................................21
4.5. Application_Entity-Controlled Proxy .......................23
4.5.1. Application_Entity-Controlled Sender Proxy
Using "RSVP over GRE" ..............................26
4.5.2. Application_Entity-Controlled Proxy via Co-Location 28
4.6. Policy_Server-Controlled Proxy ............................29
4.7. RSVP-Signaling-Triggered Proxy ............................32
4.8. Reachability Considerations ...............................33
5. Security Considerations ........................................34
6. Acknowledgments ................................................36
7. References .....................................................36
7.1. Normative References ......................................36
7.2. Informative References ....................................37
Appendix A. Use Cases for RSVP Proxies ...........................40
A.1. RSVP-Based VoD Admission Control in Broadband
Aggregation Networks ......................................40
A.2. RSVP-Based Voice/Video Connection Admission Control
(CAC) in Enterprise WAN ...................................43
A.3. RSVP Proxies for Mobile Access Networks ...................44
A.4. RSVP Proxies for Reservations in the Presence of IPsec
Gateways ..................................................46
Guaranteed Quality of Service (QoS) for some applications with tight requirements (such as voice or video) may be achieved by reserving resources in each node on the end-to-end path. The main IETF protocol for these resource reservations is the Resource Reservation Protocol (RSVP), as specified in [RFC2205]. RSVP does not require that all intermediate nodes support RSVP; however, it assumes that both the sender and the receiver of the data flow support RSVP. There are environments where it would be useful to be able to reserve resources for a flow on at least a subset of the flow path even when the sender or the receiver (or both) is not RSVP-capable (for example, from the sender to the network edge, or from edge to edge, or from the network edge to the receiver).
通过在端到端路径上的每个节点中保留资源，可以实现对一些要求严格的应用程序（如语音或视频）的有保证的服务质量（QoS）。这些资源预留的主要IETF协议是[RFC2205]中规定的资源预留协议（RSVP）。RSVP不要求所有中间节点都支持RSVP；但是，它假设数据流的发送方和接收方都支持RSVP。在某些环境中，即使发送方或接收方（或两者）不支持RSVP（例如，从发送方到网络边缘，或从边缘到边缘，或从网络边缘到接收方），能够在流路径的至少一个子集上为流保留资源也是有用的。
Since the data sender or receiver may be unaware of RSVP, there are two types of RSVP proxies. When the sender is not using RSVP, an entity in the network must operate on behalf of the data sender, and in particular, generate RSVP Path messages, and eventually receive, process, and sink Resv messages. We refer to this entity as the RSVP Sender Proxy. When the receiver is not using RSVP, an entity in the network must receive Path messages sent by a data sender (or by an RSVP Sender Proxy), sink those, and return Resv messages on behalf of the data receiver(s). We refer to this entity as the RSVP Receiver Proxy. The RSVP proxies need to be on the data path in order to establish the RSVP reservation; note, however, that some of the approaches described in this document allow the RSVP proxies to be controlled/triggered by an off-path entity.
由于数据发送方或接收方可能不知道RSVP，因此有两种类型的RSVP代理。当发送方未使用RSVP时，网络中的实体必须代表数据发送方运行，尤其是生成RSVP路径消息，并最终接收、处理和接收Resv消息。我们将此实体称为RSVP发送方代理。当接收方未使用RSVP时，网络中的实体必须接收数据发送方（或RSVP发送方代理）发送的路径消息，接收这些消息，并代表数据接收方返回Resv消息。我们将此实体称为RSVP接收方代理。RSVP代理需要位于数据路径上，以便建立RSVP保留；然而，请注意，本文档中描述的一些方法允许RSVP代理由非路径实体控制/触发。
The flow sender and receiver generally have at least some (if not full) awareness of the application producing or consuming that flow. Hence, the sender and receiver are in a natural position to synchronize the establishment, maintenance, and teardown of the RSVP reservation with the application requirements. Similarly, they are in a natural position to determine the characteristics of the reservation (bandwidth, QoS service, etc.) that best match the application requirements. For example, before completing the establishment of a multimedia session, the endpoints may decide to establish RSVP reservations for the corresponding flows. Similarly, when the multimedia session is torn down, the endpoints may decide to tear down the corresponding RSVP reservations. For instance, [RFC3312] discusses how RSVP reservations can be very tightly synchronized by endpoints that uses the Session Initiation Protocol (SIP) ([RFC3261]) for session control.
流发送方和接收方通常至少对产生或使用该流的应用程序有一些（如果不是完全的话）感知。因此，发送方和接收方自然能够将RSVP保留的建立、维护和拆除与应用程序需求同步。类似地，它们自然能够确定最符合应用程序需求的预订特征（带宽、QoS服务等）。例如，在完成多媒体会话的建立之前，端点可以决定为相应流建立RSVP预留。类似地，当多媒体会话被拆除时，端点可以决定拆除相应的RSVP保留。例如，[RFC3312]讨论了使用会话启动协议（SIP）（[RFC3261]）进行会话控制的端点如何非常紧密地同步RSVP保留。
When RSVP reservation establishment, maintenance, and teardown are to be handled by RSVP proxies on behalf of an RSVP sender or receiver, a key challenge for the RSVP proxy is to determine when the RSVP reservations need to be established, maintained, and torn down, and to determine what the characteristics are (bandwidth, QoS, etc.) of the required RSVP reservations matching the application requirements. We refer to this problem as the synchronization of RSVP reservations with application-level requirements.
当RSVP保留的建立、维护和拆除由RSVP代理代表RSVP发送方或接收方处理时，RSVP代理面临的一个关键挑战是确定何时需要建立、维护和拆除RSVP保留，并确定其特征（带宽、QoS等）符合应用要求的所需RSVP预订数量。我们将此问题称为RSVP保留与应用程序级需求的同步。
The IETF Next Steps in Signaling (NSIS) working group has specified a new QoS signaling protocol: the QoS NSIS Signaling Layer Protocol (NSLP) ([RFC5974]). This protocol also includes the notion of proxy operation, and terminating QoS signaling on nodes that are not the actual data senders or receivers (see Section 4.8, "Proxy Mode", of [RFC5974]. This is the same concept as the proxy operation for RSVP discussed in this document. One difference, though, is that the NSIS framework does not consider multicast resource reservations, which RSVP provides today.
IETF信令下一步（NSIS）工作组指定了一种新的QoS信令协议：QoS NSIS信令层协议（NSLP）（[RFC5974]）。该协议还包括代理操作的概念，以及在非实际数据发送方或接收方的节点上终止QoS信令（参见[RFC5974]第4.8节“代理模式”）这是与本文中讨论的RSVP代理操作相同的概念。然而，一个区别是NSIS框架不考虑RSVP今天提供的多播资源保留。
Section 2 introduces the notion of RSVP Sender Proxy and RSVP Receiver Proxy. Section 3 defines useful terminology. Section 4 then presents several fundamental RSVP proxy approaches, discussing how they achieve the necessary synchronization of RSVP reservations with application-level requirements. Appendix A includes more detailed use cases for the proxies in various real-life deployment environments.
第2节介绍了RSVP发送方代理和RSVP接收方代理的概念。第3节定义了有用的术语。第4节介绍了几种基本的RSVP代理方法，讨论了它们如何实现RSVP保留与应用程序级需求的必要同步。附录A包括各种实际部署环境中代理的更详细用例。
It is important to keep in mind that the strongly recommended RSVP deployment model remains end-to-end as assumed in [RFC2205] with RSVP support on the sender and the receiver. The end-to-end model allows the most effective synchronization between the reservation and application requirements. Also, when compared to the end-to-end RSVP model, the use of RSVP proxies involves additional operational burden and/or imposes some topological constraints. The additional operational burden comes in particular from additional configuration needed to activate the RSVP proxies and to help them identify for which senders/receivers a proxy behavior is required and for which senders/receivers it is not (so that an RSVP proxy does not perform establishment of reservations on behalf of devices that are capable of doing so themselves but would then be prevented -- without notification -- from doing so by the RSVP proxy). The additional topological constraints come in particular from the requirement to have one RSVP Receiver Proxy on the path from any sender to every non-RSVP-capable device (so that a non-RSVP-capable device is always taken care of by an RSVP proxy) and the objective to have only one such Receiver Proxy on the path from any sender to every non-RSVP-capable device (so that an RSVP Receiver Proxy does not short-circuit another RSVP Receiver Proxy closer to the non-RSVP-capable device, thereby reducing the span of the RSVP reservation and the associated benefits). In the case of the Path-Triggered Receiver Proxy approach, the operational burden and topological constraints can be significantly alleviated using the mechanisms discussed in Section 4.1.1.
重要的是要记住，强烈推荐的RSVP部署模型仍然是[RFC2205]中假设的端到端，发送方和接收方都支持RSVP。端到端模型允许在预订和应用程序需求之间进行最有效的同步。此外，与端到端RSVP模型相比，RSVP代理的使用涉及额外的操作负担和/或施加一些拓扑约束。额外的操作负担尤其来自激活RSVP代理所需的额外配置，并帮助他们识别哪些发送方/接收方需要代理行为，哪些发送方/接收方不需要代理行为（因此，RSVP代理不会代表能够自己执行保留的设备执行保留的建立，但是RSVP代理会在没有通知的情况下阻止这些设备执行保留的建立）。额外的拓扑约束尤其来自于在从任何发送方到每个不支持RSVP的设备的路径上有一个RSVP接收器代理的要求（因此不支持RSVP的设备总是由RSVP代理处理）以及目标是在从任何发送方到每个不支持RSVP的设备的路径上仅具有一个这样的接收器代理（使得RSVP接收器代理不会使靠近不支持RSVP的设备的另一个RSVP接收器代理短路，从而减少RSVP保留的范围和相关的好处）.在路径触发接收器代理方法的情况下，使用第4.1.1节中讨论的机制可以显著减轻操作负担和拓扑约束。
It is also worth noting that RSVP operations on end-systems are considerably simpler than on a router, and consequently that RSVP implementations on end-systems are very lightweight (particularly considering modern end-systems' capabilities, including mobile and portable devices). For example, end-system RSVP implementations are reported to only consume low tens of kilobytes of code space. Hence, this document should not be seen as an encouragement to depart from the end-to-end RSVP model. Its purpose is only to allow RSVP deployment in special environments where RSVP just cannot be used on some senders and/or some receivers for reasons specific to the environment.
还值得注意的是，终端系统上的RSVP操作比路由器上简单得多，因此终端系统上的RSVP实现非常轻量级（特别是考虑到现代终端系统的功能，包括移动和便携式设备）。例如，据报告，终端系统RSVP实现只消耗几十KB的代码空间。因此，本文件不应被视为鼓励背离端到端RSVP模型。其目的只是允许在特殊环境中部署RSVP，因为特定环境的原因，RSVP无法在某些发送方和/或某些接收方上使用。
This section discusses the two types of proxies: the RSVP Sender Proxy operating on behalf of data senders, and the RSVP Receiver Proxy operating for data receivers. The concepts presented in this document are not meant to deprecate the traditional [RFC2205] RSVP end-to-end model: end-to-end RSVP reservations are still expected to be used whenever possible. However, RSVP proxies are intended to facilitate RSVP deployment where end-to-end RSVP signaling is not possible.
本节讨论两种类型的代理：代表数据发送方操作的RSVP发送方代理和代表数据接收方操作的RSVP接收方代理。本文档中提出的概念并非要否定传统的[RFC2205]RSVP端到端模型：只要可能，仍将使用端到端RSVP保留。然而，RSVP代理用于在不可能端到端RSVP信令的情况下促进RSVP部署。
With conventional end-to-end RSVP operations, RSVP reservations are controlled by receivers of data. After a data sender has sent an RSVP Path message towards the intended recipient(s), each recipient that requires a reservation generates a Resv message. If, however, a data receiver is not running the RSVP protocol, the last-hop RSVP router will still send the Path message to the data receiver, which will silently drop this message as an IP packet with an unknown protocol number.
对于传统的端到端RSVP操作，RSVP保留由数据接收器控制。数据发送方向目标收件人发送RSVP Path消息后，需要保留的每个收件人都会生成一条Resv消息。但是，如果数据接收器未运行RSVP协议，则最后一跳RSVP路由器仍将向数据接收器发送路径消息，数据接收器将以协议号未知的IP数据包的形式静默丢弃该消息。
In order for reservations to be made in such a scenario, one of the RSVP routers on the data path determines that the data receiver will not be participating in the resource reservation signaling and performs RSVP Receiver Proxy functionality on behalf of the data receiver. This is illustrated in Figure 1. Various mechanisms by which the RSVP proxy router can gain the required information are discussed later in the document.
为了在这种情况下进行预留，数据路径上的RSVP路由器之一确定数据接收器将不参与资源预留信令，并代表数据接收器执行RSVP接收器代理功能。这如图1所示。RSVP代理路由器获得所需信息的各种机制将在本文档后面讨论。
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
===================RSVP==============>
===================RSVP==============>
***********************************************************>
***********************************************************>
|****| RSVP-capable |----| non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
|****| RSVP-capable |----| non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> unidirectional media flow
==> segment of flow path protected by RSVP reservation
***> unidirectional media flow
==> segment of flow path protected by RSVP reservation
Figure 1: RSVP Receiver Proxy
图1:RSVP接收器代理
With conventional end-to-end RSVP operations, if a data sender is not running the RSVP protocol, a resource reservation cannot be set up; a data receiver alone cannot reserve resources without Path messages first being received. Thus, even if the data receiver is running RSVP, it still needs some node on the data path to send a Path message towards the data receiver.
对于传统的端到端RSVP操作，如果数据发送方未运行RSVP协议，则无法设置资源预留；如果不首先接收路径消息，数据接收器就无法单独保留资源。因此，即使数据接收器正在运行RSVP，它仍然需要数据路径上的某个节点向数据接收器发送路径消息。
In that case, an RSVP node on the data path determines that it should generate Path messages to allow the receiver to set up the resource reservation. This node is referred to as the RSVP Sender Proxy and is illustrated in Figure 2. This case presents additional challenges over the Receiver Proxy case, since the RSVP Sender Proxy must be able to generate all the information in the Path message (such as the SENDER_TSPEC object) without the benefit of having previously received any RSVP message. An RSVP Receiver Proxy, by contrast, only needs to formulate an appropriate Resv message in response to an incoming Path message. Mechanisms to operate an RSVP Sender Proxy are discussed later in this document.
在这种情况下，数据路径上的RSVP节点确定它应该生成路径消息，以允许接收方设置资源保留。该节点称为RSVP发送方代理，如图2所示。与接收方代理相比，这种情况带来了额外的挑战，因为RSVP发送方代理必须能够生成Path消息中的所有信息（例如发送方_TSPEC对象），而无需事先收到任何RSVP消息。相反，RSVP接收方代理只需要制定适当的Resv消息来响应传入的Path消息。操作RSVP发送方代理的机制将在本文档后面讨论。
|----| |**********| *** *** |****|
| S |---------| RSVP |---------*r*----------*r*----------| R |
|----| | Sender | *** *** |****|
| Proxy |
|**********|
|----| |**********| *** *** |****|
| S |---------| RSVP |---------*r*----------*r*----------| R |
|----| | Sender | *** *** |****|
| Proxy |
|**********|
================RSVP==================>
================RSVP==================>
***********************************************************>
***********************************************************>
|----| non-RSVP-capable |****| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |****| *** router
|----| non-RSVP-capable |****| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |****| *** router
***> unidirectional media flow
***> unidirectional media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
Figure 2: RSVP Sender Proxy
图2:RSVP发送方代理
o On-Path: located on the data path of the actual flow of application data (regardless of where it is located with respect to the application-level signaling path).
o On Path：位于实际应用程序数据流的数据路径上（无论相对于应用程序级信令路径位于何处）。
o Off-Path: not On-Path.
o 非路径：不在路径上。
o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per [RFC2205].
o 支持RSVP（或支持RSVP）：根据[RFC2205]支持RSVP协议。
o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf of a receiver, the RSVP operations that would normally be performed by an RSVP-capable receiver if end-to-end RSVP signaling were used. Note that while RSVP is used upstream of the RSVP Receiver Proxy, RSVP is not used downstream of the RSVP Receiver Proxy.
o RSVP接收器代理：支持RSVP的路由器，代表接收器执行RSVP操作，如果使用端到端RSVP信令，通常由支持RSVP的接收器执行RSVP操作。请注意，虽然RSVP用于RSVP接收器代理的上游，但RSVP不用于RSVP接收器代理的下游。
o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of a sender, the RSVP operations that would normally be performed by an RSVP-capable sender if end-to-end RSVP signaling were used. Note that while RSVP is used downstream of the RSVP Sender Proxy, RSVP is not used upstream of the RSVP Sender Proxy.
o RSVP发送方代理：支持RSVP的路由器，代表发送方执行RSVP操作，如果使用端到端RSVP信令，通常由支持RSVP的发送方执行。请注意，虽然RSVP用于RSVP发送方代理的下游，但RSVP不用于RSVP发送方代理的上游。
o Regular RSVP Router: an RSVP-capable router that is not behaving as an RSVP Receiver Proxy or as an RSVP Sender Proxy.
o 常规RSVP路由器：支持RSVP的路由器，不作为RSVP接收方代理或RSVP发送方代理。
o Application-level signaling: signaling between entities operating above the IP layer and that are aware of the QoS requirements for actual media flows. SIP ([RFC3261]) and the Real Time Streaming Protocol (RTSP) ([RFC2326]) are examples of application-level signaling protocols. The Session Description Protocol (SDP) ([RFC4566]) is an example of a protocol that can be used by the application-level signaling protocol and from which some of the RSVP reservation parameters (addresses, ports, and bandwidth) might be derived. RSVP is clearly not an application-level signaling protocol.
o 应用层信令：在IP层之上运行的实体之间的信令，这些实体知道实际媒体流的QoS要求。SIP（[RFC3261]）和实时流协议（RTSP）（[RFC2326]）是应用级信令协议的示例。会话描述协议（SDP）（[RFC4566]）是可由应用级信令协议使用的协议的示例，并且可从中导出一些RSVP保留参数（地址、端口和带宽）。RSVP显然不是应用层信令协议。
The roles of the RSVP Receiver Proxy, RSVP Sender Proxy, and regular RSVP router are all relative to a given unidirectional flow. A given router may act as the RSVP Receiver Proxy for a flow, as the RSVP Sender Proxy for another flow, and as a regular RSVP router for yet another flow.
RSVP接收方代理、RSVP发送方代理和常规RSVP路由器的角色都与给定的单向流相关。给定的路由器可以充当一个流的RSVP接收方代理、另一个流的RSVP发送方代理以及另一个流的常规RSVP路由器。
Some application-level signaling protocols support negotiation of QoS reservations for a media stream. For example, with [RFC3312], resource reservation requirements are explicitly signaled during session establishment using SIP and SDP. Also, [RFC5432] defines a mechanism to negotiate which resource reservation mechanism is to be used for a particular media stream. Clearly, these reservation negotiation mechanisms can be invoked and operate effectively when both ends support RSVP (and obviously RSVP proxies are not used). When both ends do not support RSVP (and RSVP proxies are used at both ends), these mechanisms will simply not be invoked. In the case
一些应用级信令协议支持对媒体流的QoS保留进行协商。例如，对于[RFC3312]，在使用SIP和SDP的会话建立期间，资源保留需求被显式地通知。此外，[RFC5432]定义了一种机制，用于协商特定媒体流将使用哪种资源保留机制。显然，当两端都支持RSVP时（显然不使用RSVP代理），这些保留协商机制可以被调用并有效运行。当两端都不支持RSVP（并且两端都使用RSVP代理）时，这些机制将不会被调用。在这种情况下
where one end supports RSVP and the other does not (and is helped by an RSVP proxy), the application-level signaling entity supporting the non-RSVP-capable end might use the reservation negotiation mechanisms in such a way that the non-RSVP-capable end (helped by an RSVP proxy) appears to the remote end as an RSVP-capable device. This will ensure that the RSVP-capable end is not discouraged from using RSVP because the remote end is not RSVP-capable. In the case of SIP, the application-level entity may achieve this by taking advantage of the "segmented" status type of [RFC3312] and/or by taking advantage of a SIP [RFC3261] Back-to-Back User Agent (B2BUA).
在一端支持RSVP而另一端不支持RSVP的情况下（并且得到RSVP代理的帮助），支持不支持RSVP的端的应用级信令实体可以使用保留协商机制，使得不支持RSVP的端（由RSVP代理的帮助）在远程端看来是支持RSVP的设备。这将确保支持RSVP的端不会因为远程端不支持RSVP而不鼓励使用RSVP。在SIP的情况下，应用级实体可以通过利用[RFC3312]的“分段”状态类型和/或通过利用SIP[rfc326]背靠背用户代理（B2BUA）来实现这一点。
This section discusses fundamental RSVP proxy approaches.
本节讨论基本的RSVP代理方法。
In this approach, it is assumed that the sender is RSVP-capable and takes full care of the synchronization between application requirements and RSVP reservations. With this approach, the RSVP Receiver Proxy uses the RSVP Path messages generated by the sender as the cue for establishing the RSVP reservation on behalf of the receiver. The RSVP Receiver Proxy is effectively acting as a slave making reservations (on behalf of the receiver) under the sender's control. This changes somewhat the usual RSVP reservation model where reservations are normally controlled by receivers. Such a change greatly facilitates operations in the scenario of interest here, which is where the receiver is not RSVP-capable. Indeed, it allows the RSVP Receiver Proxy to remain application-unaware by taking advantage of the application awareness and RSVP awareness of the sender.
在这种方法中，假设发送方具有RSVP能力，并且完全负责应用程序需求和RSVP保留之间的同步。通过这种方法，RSVP接收方代理使用发送方生成的RSVP路径消息作为代表接收方建立RSVP保留的提示。RSVP接收方代理实际上是在发送方的控制下（代表接收方）进行预订的从属服务器。这在一定程度上改变了通常的RSVP保留模型，其中保留通常由接收者控制。这样的改变极大地促进了这里所关注的场景中的操作，即接收机不支持RSVP的场景。实际上，它允许RSVP接收方代理通过利用发送方的应用程序感知和RSVP感知保持应用程序不知道。
With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be configured to use receipt of a regular RSVP Path message as the trigger for RSVP Receiver Proxy behavior.
通过路径触发的RSVP接收器代理方法，RSVP路由器可被配置为使用常规RSVP路径消息的接收作为RSVP接收器代理行为的触发器。
On receipt of the RSVP Path message, the RSVP Receiver Proxy:
收到RSVP Path消息后，RSVP接收方代理：
1. establishes the RSVP Path state as per regular RSVP processing.
1. 根据常规RSVP处理建立RSVP路径状态。
2. identifies the downstream interface towards the receiver.
2. 识别面向接收器的下游接口。
3. sinks the Path message.
3. 接收路径消息。
4. behaves as if a Resv message (whose details are discussed below) was received on the downstream interface. This includes performing admission control on the downstream interface, establishing a Resv state (in case of successful admission
4. 其行为就像在下游接口上接收到Resv消息（其详细信息如下所述）。这包括在下游接口上执行准入控制，建立Resv状态（在成功准入的情况下）
control), and forwarding the Resv message upstream, sending periodic refreshes of the Resv message and tearing down the reservation if the Path state is torn down.
控件），并向上游转发Resv消息，发送Resv消息的定期刷新，如果路径状态被删除，则删除保留。
In order to build the Resv message, the RSVP Receiver Proxy can take into account information received in the Path message. For example, the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv message that mirrors the SENDER_TSPEC object in the received Path message (as an RSVP-capable receiver would typically do).
为了构建Resv消息，RSVP接收方代理可以考虑Path消息中接收到的信息。例如，RSVP接收方代理可以为Resv消息组成一个FLOWSPEC对象，该对象在接收到的路径消息中镜像发送方_TSPEC对象（具有RSVP能力的接收方通常会这样做）。
Operation of the Path-Triggered Receiver Proxy in the case of a successful reservation is illustrated in Figure 3.
图3说明了成功预订情况下路径触发的接收方代理的操作。
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
---Path---> ----Path----> ---Path---->
---Path---> ----Path----> ---Path---->
<--Resv---> <---Resv----- <--Resv----
<--Resv---> <---Resv----- <--Resv----
==================RSVP===============>
==================RSVP===============>
**********************************************************>
**********************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
Figure 3: Path-Triggered RSVP Receiver Proxy
图3：路径触发的RSVP接收器代理
In case the reservation establishment is rejected (for example, because of an admission control failure on a regular RSVP router on the path between the RSVP-capable sender and the RSVP Receiver Proxy), a ResvErr message will be generated as per conventional RSVP operations and will travel downstream towards the RSVP Receiver Proxy. While this ensures that the RSVP Receiver Proxy is aware of the reservation failure, conventional RSVP procedures do not cater to the notification of the sender of the reservation failure. Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure is illustrated in Figure 4.
如果保留建立被拒绝（例如，由于具有RSVP能力的发送方和RSVP接收方代理之间的路径上的常规RSVP路由器上的准入控制故障），将根据常规RSVP操作生成ResvErr消息，并向下游RSVP接收方代理移动。虽然这确保了RSVP接收方代理知道保留失败，但传统的RSVP程序不满足发送方关于保留失败的通知。在准入控制失败的情况下，路径触发的RSVP接收器代理的操作如图4所示。
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
---Path---> ----Path----> ---Path---->
---Path---> ----Path----> ---Path---->
<---Resv----- <--Resv------
<---Resv----- <--Resv------
---ResvErr---> --ResvErr--->
---ResvErr---> --ResvErr--->
===================RSVP===============>
===================RSVP===============>
**********************************************************>
**********************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
Figure 4: Path-Triggered RSVP Receiver Proxy with Failure
图4：路径触发的RSVP接收器代理出现故障
Since, as explained above, in this scenario involving the RSVP Receiver Proxy, synchronization between an application and an RSVP reservation is generally performed by the sender, notifying the sender of reservation failure is needed. [RFC5946] specifies RSVP extensions allowing such sender notification in the case of reservation failure in the presence of a Path-Triggered RSVP Receiver Proxy.
如上所述，在涉及RSVP接收器代理的场景中，应用程序和RSVP保留之间的同步通常由发送方执行，因此需要通知发送方保留失败。[RFC5946]指定RSVP扩展，允许在存在路径触发的RSVP接收方代理的情况下，在保留失败的情况下发出此类发送方通知。
The presence in the flow path of a Path-Triggered RSVP Receiver Proxy (for a given flow) that strictly behaves as described previously would cause the Path message to be terminated and a Resv message to be generated towards the sender. When the receiver is indeed not RSVP-capable and there is no other RSVP Receiver Proxy downstream on the flow path, this achieves the best achievable result of establishing an RSVP reservation as far downstream as the RSVP Receiver Proxy.
在流路径中存在路径触发的RSVP接收方代理（对于给定流），该代理严格按照前面描述的方式运行，将导致路径消息终止，并向发送方生成Resv消息。当接收器确实不具备RSVP能力且流路径上下游没有其他RSVP接收器代理时，这实现了在尽可能远的下游RSVP接收器代理建立RSVP保留的最佳可实现结果。
However, if the eventual receiver was in fact RSVP-capable, it would be prevented from participating in RSVP signaling, since it does not receive any Path message. As a result, the RSVP reservation would only span a subset of the path it could actually span. A similar sub-optimality would exist with multiple Receiver Proxies in the path of the flow: the first Receiver Proxy may prevent the Path message from reaching the second one and therefore prevent the reservation from extending down to the second Receiver Proxy.
然而，如果最终的接收器实际上具有RSVP能力，则将阻止其参与RSVP信令，因为它不接收任何路径消息。因此，RSVP保留只会跨越它实际可以跨越的路径的一个子集。流路径中的多个接收方代理也会存在类似的次优情况：第一个接收方代理可能会阻止路径消息到达第二个接收方代理，从而阻止保留向下延伸到第二个接收方代理。
It is desirable that, in the presence of Path-Triggered RSVP Receiver Proxies and of a mix of RSVP-capable and non-RSVP-capable receivers, the RSVP reservation spans as much of the flow path as possible. This can be achieved dynamically (avoiding tedious specific configuration), using the mechanisms described in Sections 4.1.1.1 and 4.1.1.2.
理想的是，在存在路径触发的RSVP接收器代理以及具有RSVP能力和不具有RSVP能力的接收器的混合的情况下，RSVP保留尽可能跨越流路径。这可以使用第4.1.1.1节和第4.1.1.2节中描述的机制动态实现（避免繁琐的特定配置）。
When generating a proxy Resv message upstream, a Receiver Proxy may be configured to perform dynamic discovery of downstream RSVP functionality. To that end, when generating the proxy Resv message upstream, the Receiver Proxy forwards the Path message downstream instead of terminating it. This allows an RSVP-capable receiver (or a downstream Receiver Proxy) to respond to the Path with an upstream Resv message. On receipt of a Resv message, the Receiver Proxy internally converts its state from a proxied reservation to a regular midpoint RSVP behavior. From then on, everything proceeds as if the RSVP router had behaved as a regular RSVP router at reservation establishment (as opposed to having behaved as an RSVP Receiver Proxy for that flow).
当在上游生成代理Resv消息时，接收机代理可被配置为执行下游RSVP功能的动态发现。为此，在上游生成代理Resv消息时，接收方代理将路径消息转发到下游，而不是终止它。这允许支持RSVP的接收器（或下游接收器代理）使用上游Resv消息响应路径。接收到Resv消息后，接收方代理在内部将其状态从代理保留转换为常规中点RSVP行为。从那时起，一切都在进行，就好像RSVP路由器在预订建立时作为常规RSVP路由器一样（而不是作为该流的RSVP接收方代理）。
The RSVP Receiver Proxy behavior for dynamic discovery of downstream RSVP functionality is illustrated in Figure 5 and is also discussed in Section 4.1 of [RFC5946].
图5说明了动态发现下游RSVP功能的RSVP接收器代理行为，并在[RFC5946]的第4.1节中进行了讨论。
|****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----|
| Proxy |
| |
| | |****|
| |------------| R2 |
|**********| |****|
|****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----|
| Proxy |
| |
| | |****|
| |------------| R2 |
|**********| |****|
---Path---> --Path--->
(R1) (R1) \-------Path-->
/ (R1)
<--Resv--- <---Resv---
---Path---> --Path--->
(R1) (R1) \-------Path-->
/ (R1)
<--Resv--- <---Resv---
================RSVP===>
================RSVP===>
**************************************>
**************************************>
---Path---> --Path--->
(R2) (R2) \-------------Path---->
/ (R2)
<--Resv--- <---Resv---
<----Resv---
---Path---> --Path--->
(R2) (R2) \-------------Path---->
/ (R2)
<--Resv--- <---Resv---
<----Resv---
================RSVP===========================>
================RSVP===========================>
***********************************************>
***********************************************>
|****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable
| S | Sender | R | Receiver | R | Receiver
|****| |----| |****|
|****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable
| S | Sender | R | Receiver | R | Receiver
|****| |----| |****|
***
*r* regular RSVP
*** router
***
*r* regular RSVP
*** router
(R1) = Path message contains a Session object whose destination is R1
（R1）=路径消息包含目标为R1的会话对象
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
Figure 5: Dynamic Discovery of Downstream RSVP Functionality
Figure 5: Dynamic Discovery of Downstream RSVP Functionalitytranslate error, please retry
This dynamic discovery mechanism has the benefit that new (or upgraded) RSVP endpoints will automatically and seamlessly be able to take advantage of end-to-end reservations, without impacting the
这种动态发现机制的好处是，新的（或升级的）RSVP端点将自动、无缝地利用端到端保留，而不会影响服务质量
ability of a Receiver Proxy to proxy RSVP for other, non-RSVP-capable endpoints. This mechanism also achieves the goal of automatically discovering the longest possible RSVP-supporting segment in a network with multiple Receiver Proxies along the path. This mechanism dynamically adjusts to any topology and routing change. Also, this mechanism dynamically handles the situation in which a receiver was RSVP-capable and for some reason (e.g., software downgrade) no longer is. Finally, this approach requires no new RSVP protocol extensions and no configuration changes to the Receiver Proxy as new RSVP-capable endpoints come and go.
接收器代理为其他不支持RSVP的端点代理RSVP的能力。该机制还实现了在路径上具有多个接收器代理的网络中自动发现尽可能长的RSVP支持段的目标。此机制动态调整以适应任何拓扑和路由更改。此外，该机制动态处理接收器具有RSVP能力且由于某些原因（例如，软件降级）不再具有RSVP能力的情况。最后，这种方法不需要新的RSVP协议扩展，也不需要对接收器代理进行配置更改，因为新的支持RSVP的端点来来去去。
The only identified drawbacks to this approach are:
这种方法唯一确定的缺点是：
o If admission control fails on the segment between the Receiver Proxy and the RSVP-capable receiver, the receiver will get a ResvErr and can take application-level signaling steps to terminate the call. However, the Receiver Proxy has already sent a Resv upstream for this flow, so the sender will see a "false" reservation that is not truly end-to-end. The actual admission control status will resolve itself in a short while, but the sender will need to roll back any permanent action (such as billing) that may have been taken on receipt of the phantom Resv. Note that if the second receiver is also a Receiver Proxy that is not participating in application signaling, it will convert the received ResvErr into a PathErr that will be received by the sender.
o 如果在接收器代理和支持RSVP的接收器之间的段上的准入控制失败，接收器将获得一个ResvErr，并且可以采取应用层信令步骤来终止呼叫。但是，接收方代理已经为此流向上游发送了一个Resv，因此发送方将看到一个不是真正端到端的“假”保留。实际的准入控制状态将在短时间内自行解决，但发送方将需要回滚收到虚拟Resv时可能采取的任何永久性操作（如计费）。请注意，如果第二个接收器也是不参与应用程序信令的接收器代理，则它会将接收到的ResvErr转换为将由发送方接收的PathErr。
o If there is no RSVP-capable receiver (or other Receiver Proxy) downstream of the Receiver Proxy, then the Path messages sent by the Receiver Proxy every RSVP refresh interval (e.g., 30 seconds by default) will never be responded to. However, these messages consume a small amount of bandwidth, and in addition would install some RSVP state on RSVP-capable midpoint nodes downstream of the first Receiver Proxy. This is seen as a very minor sub-optimality. We also observe that such resources would be consumed anyways if the receiver was RSVP-capable. Still, if deemed necessary, to mitigate this, the Receiver Proxy can tear down any unanswered downstream Path state and stop sending Path messages for the flow (or only send them at much lower frequency) as further discussed in [RFC5946].
o 如果接收方代理下游没有支持RSVP的接收方（或其他接收方代理），则接收方代理在每个RSVP刷新间隔（例如，默认情况下为30秒）发送的路径消息将永远不会得到响应。但是，这些消息会消耗少量带宽，此外，还会在第一个接收器代理下游的支持RSVP的中点节点上安装一些RSVP状态。这被视为一个非常小的次优。我们还观察到，如果接收器具有RSVP能力，则无论如何都会消耗此类资源。然而，如果认为有必要，为了缓解这种情况，接收方代理可以中断任何未应答的下游路径状态，并停止发送流的路径消息（或仅以更低的频率发送），如[RFC5946]中进一步讨论的。
An RSVP Receiver Proxy can be selective about the sessions that it terminates, based on local policy decision. For example, an edge router functioning as a Receiver Proxy may behave as a proxy only for Path messages that are actually going to exit the domain in question, and not for Path messages that are transiting through it but stay
RSVP接收方代理可以根据本地策略决定选择其终止的会话。例如，用作接收器代理的边缘路由器可能仅作为实际将要退出相关域的路径消息的代理，而不作为正在通过该域传输但保留的路径消息的代理
within the domain. As another example, the Receiver Proxy may be configurable to only proxy for flows addressed to a given destination address or destination address ranges (for which end devices are known to not be RSVP-capable).
在域内。作为另一示例，接收器代理可配置为仅代理寻址到给定目的地地址或目的地地址范围（已知终端设备不支持RSVP）的流。
The decision to proxy a Resv for a Path may also be based on information signaled from the sender in the Path message. For example, the sender may identify the type of application or flow in the Application Identity policy element ([RFC2872]) in the Path, and the Receiver Proxy may be configured to proxy for only certain types of flows. Or, if the sender knows (for example, through application signaling) that the receiver is RSVP-capable, the sender can include an indication in a policy element to any Receiver Proxy that it ought not to terminate the Path (or conversely, if the receiver is known not to support RSVP, the sender could include an indication to Receiver Proxies that they ought to generate a proxy Resv message). The Receiver Proxy Control policy element specified in Section 4.2 of [RFC5946] can be used for that purpose.
为路径代理Resv的决定也可以基于在路径消息中从发送者发信号的信息。例如，发送方可以在路径中的应用程序标识策略元素（[RFC2872]）中标识应用程序或流的类型，并且接收方代理可以被配置为仅代理特定类型的流。或者，如果发送方知道（例如，通过应用信令）接收方具有RSVP能力，则发送方可以在策略元素中向任何接收方代理包括其不应该终止路径的指示（或者相反，如果已知接收方不支持RSVP，则发送方可向接收方代理发出指示，说明其应生成代理Resv消息。）[RFC5946]第4.2节中规定的接收方代理控制策略元素可用于此目的。
In this approach, it is assumed that one endpoint is RSVP-capable and takes full care of the synchronization between application requirements and RSVP reservations. This endpoint is the sender for one flow direction (which we refer to as the "forward" direction) and is the receiver for the flow in the opposite direction (which we refer to as the "reverse" direction).
在这种方法中，假设一个端点具有RSVP能力，并且完全负责应用程序需求和RSVP保留之间的同步。该端点是一个流方向（我们称之为“前进”方向）的发送方，也是相反方向（我们称之为“反向”方向）流的接收方。
With the Path-Triggered Sender Proxy for Reverse Direction approach, the RSVP proxy uses the RSVP signaling generated by the receiver (for the reverse direction) as the cue for initiating RSVP signaling for the reservation in the reverse direction. More precisely, the RSVP proxy can take the creation (or maintenance or teardown) of a Path state by the receiver as the cue to create (or maintain or tear down, respectively) a Path state towards the receiver. Thus, the RSVP proxy is effectively acting as a Sender Proxy for the reverse direction under the control of the receiver (for the reverse direction). Note that this assumes a degree of symmetry, for example, in terms of bandwidth for the two directions of the flow (as is currently typical for IP telephony).
对于反向路径触发的发送方代理，RSVP代理使用接收方（反向）生成的RSVP信令作为在反向方向上启动预留RSVP信令的提示。更准确地说，RSVP代理可以将接收方创建（或维护或拆除）路径状态作为向接收方创建（或分别维护或拆除）路径状态的提示。因此，RSVP代理在接收方的控制下（对于反向）有效地充当反向的发送方代理。注意，这假设了一定程度的对称性，例如，在两个流方向的带宽方面（目前是典型的IP电话）。
The signaling flow for the Path-Triggered Sender Proxy for Reverse Direction is illustrated in Figure 6.
反向路径触发发送方代理的信令流如图6所示。
Path messages generated by the receiver need to transit via the RSVP Sender Proxy that is on the path from the sender to the receiver. In some topologies, this will always be the case: for example, where the sender is on a stub network hanging off the RSVP Sender Proxy or
接收方生成的路径消息需要通过从发送方到接收方的路径上的RSVP发送方代理进行传输。在某些拓扑中，始终会出现这种情况：例如，发送方位于挂起RSVP发送方代理的存根网络上，或者
where there is no asymmetric routing (such that if an RSVP Sender Proxy is on the path from receiver to sender, then it is also on the path from sender to receiver). In some topologies (such as those involving asymmetric routing), this may not always happen naturally. Measures to ensure this does happen in these topologies are outside the scope of this document.
不存在非对称路由的情况下（例如，如果RSVP发送方代理位于从接收方到发送方的路径上，那么它也位于从发送方到接收方的路径上）。在某些拓扑中（例如涉及非对称路由的拓扑），这可能并不总是自然发生的。确保在这些拓扑中发生这种情况的措施不在本文件的范围内。
|****| *** *** |**********| |----|
| R |---------*r*----------*r*---------| RSVP |----------| S |
|****| *** *** | Sender | |----|
| Proxy |
|**********|
|****| *** *** |**********| |----|
| R |---------*r*----------*r*---------| RSVP |----------| S |
|****| *** *** | Sender | |----|
| Proxy |
|**********|
---Path---> ----Path----> ---Path---->
---Path---> ----Path----> ---Path---->
<--Path---> <---Path----- <--Path----
<--Path---> <---Path----- <--Path----
---Resv---> ----Resv----> ---Resv---->
---Resv---> ----Resv----> ---Resv---->
<================RSVP==================
<================RSVP==================
<**********************************************************
<**********************************************************
|****| RSVP-capable |----| Non-RSVP-capable ***
| R | Receiver for | S | Sender for *r* regular RSVP
|****| reverse direction |----| reverse direction *** router
|****| RSVP-capable |----| Non-RSVP-capable ***
| R | Receiver for | S | Sender for *r* regular RSVP
|****| reverse direction |----| reverse direction *** router
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation in reverse direction
==>反向RSVP预留保护的流路段
Figure 6: Path-Triggered Sender Proxy for Reverse Direction
图6：反向路径触发的发送方代理
Of course, the RSVP proxy may simultaneously (and typically will) also act as the Path-Triggered Receiver Proxy for the forward direction, as defined in Section 4.1. Such an approach is most useful in situations involving RSVP reservations in both directions for symmetric flows. This is illustrated in Figure 7.
当然，如第4.1节所定义，RSVP代理可以同时（并且通常将）充当前向的路径触发接收器代理。这种方法在涉及对称流双向RSVP保留的情况下最有用。这如图7所示。
|****| *** *** |----------| |----|
|S/R |---------*r*----------*r*---------| RSVP |----------|S/R |
|****| *** *** | Receiver | |----|
| & Sender |
| Proxy |
|----------|
|****| *** *** |----------| |----|
|S/R |---------*r*----------*r*---------| RSVP |----------|S/R |
|****| *** *** | Receiver | |----|
| & Sender |
| Proxy |
|----------|
---Path---> ----Path----> ---Path---->
---Path---> ----Path----> ---Path---->
<--Resv---> <---Resv----- <--Resv----
<--Resv---> <---Resv----- <--Resv----
<--Path---> <---Path----- <--Path----
<--Path---> <---Path----- <--Path----
---Resv---> ----Resv----> ---Resv---->
---Resv---> ----Resv----> ---Resv---->
================RSVP==================>
<================RSVP==================
================RSVP==================>
<================RSVP==================
**********************************************************>
<**********************************************************
**********************************************************>
<**********************************************************
|****| RSVP-capable |----| Non-RSVP-capable ***
|S/R | Sender and |S/R | Sender and *r* regular RSVP
|****| Receiver |----| Receiver *** router
|****| RSVP-capable |----| Non-RSVP-capable ***
|S/R | Sender and |S/R | Sender and *r* regular RSVP
|****| Receiver |----| Receiver *** router
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation in forward and in reverse direction
==>正向和反向受RSVP预留保护的流路段
Figure 7: Path Triggered Receiver and Sender Proxy
图7：路径触发的接收方和发送方代理
With the Path-Triggered Sender Proxy for Reverse Direction approach, the RSVP router may be configurable to use receipt of a regular RSVP Path message as the trigger for Sender Proxy for Reverse Direction behavior.
使用路径触发的反向发送方代理方法，RSVP路由器可配置为使用常规RSVP路径消息的接收作为反向行为发送方代理的触发器。
On receipt of the RSVP Path message for the forward direction, the RSVP Sender Receiver Proxy:
收到转发方向的RSVP路径消息后，RSVP发送方-接收方代理：
1. sinks the Path message.
1. 接收路径消息。
2. behaves as if a Path message for the reverse direction (whose details are discussed below) had been received by the Sender Proxy. This includes establishing the corresponding Path state, forwarding the Path message downstream, sending periodic
2. 其行为就像发送方代理已收到反向路径消息（其详细信息将在下面讨论）。这包括建立相应的路径状态、向下游转发路径消息、定期发送消息
refreshes of the Path message, and tearing down the Path in the reverse direction when the Path state in the forward direction is torn down.
刷新路径消息，并在正向路径状态被删除时反向删除路径。
In order to build the Path message for the reverse direction, the RSVP Sender Proxy can take into account information in the received Path message for the forward direction. For example, the RSVP Sender Proxy may mirror the SENDER_TSPEC object in the received Path message.
为了构建反向路径消息，RSVP发送方代理可以考虑接收到的正向路径消息中的信息。例如，RSVP发送方代理可以在接收到的路径消息中镜像发送方_TSPEC对象。
We observe that this approach does not require any extensions to the existing RSVP protocol.
我们观察到，这种方法不需要对现有RSVP协议进行任何扩展。
In the case where reservations are required in both directions (as shown in Figure 7), the RSVP-capable device simply needs to behave as a regular RSVP sender and RSVP receiver. It need not be aware that an RSVP proxy happens to be used, and the Path message it sent for the forward reservation also acts as the trigger for establishment of the reverse reservation. However, in the case where a reservation is only required in the reverse direction (as shown in Figure 6), the RSVP-capable device has to generate Path messages in order to trigger the reverse-direction reservation even if no reservation is required in the forward direction. Although this is not in violation of [RFC2205], it may not be the default behavior of an RSVP-capable device and therefore may need a behavioral change specifically to facilitate operation of the Path-Triggered Sender Proxy for Reverse Direction.
在两个方向都需要保留的情况下（如图7所示），支持RSVP的设备只需充当常规的RSVP发送方和RSVP接收方。它不需要知道碰巧使用了RSVP代理，它为前向保留发送的路径消息也充当建立反向保留的触发器。然而，在仅在反向需要保留的情况下（如图6所示），支持RSVP的设备必须生成路径消息以触发反向保留，即使在正向不需要保留。尽管这并不违反[RFC2205]，但这可能不是支持RSVP的设备的默认行为，因此可能需要专门的行为更改，以便于反向路径触发发送方代理的操作。
In this approach, it is assumed that the RSVP proxy is on the data path of "packets of interest", that it can inspect such packets on the fly as they transit through it, and that it can infer information from these packets of interest to determine what RSVP reservations need to be established, as well as when and with what characteristics (possibly also using some configured information).
在这种方法中，假设RSVP代理位于“感兴趣的包”的数据路径上，它可以在这些包通过它时动态地检查这些包，并且它可以从这些感兴趣的包中推断信息，以确定需要建立什么RSVP保留，以及何时以及具有什么特征（也可能使用一些配置信息）。
One example of "packets of interest" could be application-level signaling. An RSVP proxy capable of inspecting SIP signaling for a multimedia session or RTSP signaling for video streaming can obtain from such signaling information about when a multimedia session is up or when a video is going to be streamed. It can also identify the addresses and ports of senders and receivers and can determine the bandwidth of the corresponding flows. It can also determine when the reservation is no longer needed and tear it down. Thus, such an RSVP proxy can determine all necessary information to synchronize RSVP reservations to application requirements. This is illustrated in Figure 8.
“感兴趣的包”的一个示例可以是应用程序级信令。能够检查用于多媒体会话的SIP信令或用于视频流的RTSP信令的RSVP代理可以从此类信令获取关于多媒体会话何时开始或视频何时将被流化的信息。它还可以识别发送方和接收方的地址和端口，并可以确定相应流的带宽。它还可以确定何时不再需要保留并将其删除。因此，这样的RSVP代理可以确定将RSVP保留与应用程序需求同步的所有必要信息。如图8所示。
|-------------|
| Application |
| Signaling |
| Entity |
|-------------|
/ \
/ \
/ \
</////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\>
|-------------|
| Application |
| Signaling |
| Entity |
|-------------|
/ \
/ \
/ \
</////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\>
|----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----|
|********| |********|
|----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----|
|********| |********|
=======RSVP=======>
=======RSVP=======>
********************************************************>
********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
</\> application-level signaling
</\> application-level signaling
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
Figure 8: Inspection-Triggered RSVP Proxy
图8：检查触发的RSVP代理
Another example of "packets of interest" could be transport control messages (e.g., the Real-time Transport Control Protocol (RTCP) [RFC3550]) traveling alongside the application flow itself (i.e., media packets). An RSVP proxy capable of detecting the transit of packets from a particular flow can attempt to establish a reservation corresponding to that flow. Characteristics of the reservation may be derived by various methods such as from configuration, flow measurement, or a combination of those. However, these methods usually come with their respective operational drawbacks: configuration involves an operational cost and may hinder introduction of new applications, and measurement is reactive so that accurate reservation may lag actual traffic.
“感兴趣的分组”的另一个示例可以是沿着应用程序流本身（即，媒体分组）移动的传输控制消息（例如，实时传输控制协议（RTCP）[RFC3550]）。能够检测来自特定流的数据包传输的RSVP代理可以尝试建立与该流对应的保留。可通过各种方法（如配置、流量测量或这些方法的组合）得出保留区的特征。然而，这些方法通常都有各自的操作缺点：配置涉及操作成本，可能会阻碍新应用的引入，并且测量是被动的，因此准确的预订可能会滞后于实际流量。
In the case of reservation failure, the Inspection-Triggered RSVP Proxy does not have a direct mechanism for notifying the application (since it is not participating itself actively in application
在保留失败的情况下，检查触发的RSVP代理没有通知应用程序的直接机制（因为它没有积极参与应用程序）
signaling) so that the application is not in a position to take appropriate action (for example, terminate the corresponding session). To mitigate this problem, the Inspection-Triggered RSVP Proxy may differently mark the Differentiated Services codepoint (DSCP) ([RFC2474]) of flows for which an RSVP reservation has been successfully proxied from the flows for which a reservation is not in place. In some situations, the Inspection-Triggered Proxy might be able to modify the "packets of interest" (e.g., application signaling messages) to convey some hint to applications that the corresponding flows cannot be guaranteed by RSVP reservations.
信令）以使应用程序无法采取适当的操作（例如，终止相应的会话）。为了缓解此问题，检查触发的RSVP代理可能会以不同的方式标记RSVP保留已成功代理的流的差异化服务代码点（DSCP）（[RFC2474]），而不是保留未到位的流。在某些情况下，检查触发的代理可能能够修改“感兴趣的包”（例如，应用程序信令消息），以向应用程序传达一些提示，即RSVP保留不能保证相应的流。
With the Inspection-Triggered Proxy approach, the RSVP proxy is effectively required to attempt to build application awareness by traffic inspection and then is somewhat limited in the actions it can take in case of reservation failure. Depending on the "packets of interest" used by the RSVP proxy to trigger the reservation, there is a risk that the RSVP proxy will end up establishing a reservation for a media flow that actually never starts. However, this can be mitigated by the timing out and tearing down of an unnecessary reservation by the RSVP proxy when no corresponding media flow is observed. This flow observation and timeout approach can also be used to tear down reservations that were rightfully established for a flow but are no longer needed because the flow stopped.
使用检查触发的代理方法，RSVP代理有效地被要求通过流量检查来尝试建立应用程序感知，然后在预订失败的情况下，它可以采取的行动受到一定的限制。根据RSVP代理用来触发保留的“感兴趣的数据包”，存在RSVP代理最终为实际上从未启动的媒体流建立保留的风险。然而，当没有观察到相应的媒体流时，RSVP代理可以通过超时和取消不必要的保留来缓解这一问题。此流观察和超时方法还可用于删除为流正确建立但由于流停止而不再需要的保留。
The Inspection-Triggered approach is also subject to the general limitations associated with data inspection. This includes being impeded by encryption or tunneling, or being dependent on some topology constraints such as relying on the fact that both the packets of interest and the corresponding flow packets always transit through the same RSVP proxy.
检查触发方法也受到与数据检查相关的一般限制。这包括受到加密或隧道的阻碍，或依赖于某些拓扑约束，例如依赖于感兴趣的数据包和相应的流数据包始终通过相同的RSVP代理传输这一事实。
Nonetheless, this may be a useful approach in specific environments. Note also that this approach does not require any change to the RSVP protocol.
尽管如此，在特定环境中，这可能是一种有用的方法。还要注意，这种方法不需要对RSVP协议进行任何更改。
With the Inspection-Triggered RSVP Proxy approach, the RSVP router may be configurable to use and interpret some specific packets of interest as the trigger for RSVP Receiver Proxy behavior.
通过检查触发的RSVP代理方法，RSVP路由器可以配置为使用和解释一些感兴趣的特定分组作为RSVP接收器代理行为的触发器。
When operating off signaling traffic, the Inspection-Triggered RSVP Proxy may be able to detect from the signaling that the endpoint is capable of establishing an RSVP reservation (e.g., in the case of SIP, via the inspection of the [RFC3312]/[RFC4032] precondition), in which case it would not behave as a proxy for that endpoint. Also, the Inspection-Triggered RSVP Proxy may inspect RSVP signaling, and if it sees RSVP signaling for the flow of interest, it can disable its Sender Proxy behavior for that flow (or that sender). Optionally, through RSVP signaling inspection, the Sender Proxy might
当操作关闭信令业务时，检查触发的RSVP代理可以从信令中检测到端点能够建立RSVP保留（例如，在SIP的情况下，通过检查[RFC3312]/[RFC4032]先决条件），在这种情况下，它将不作为该端点的代理。此外，检查触发的RSVP代理可以检查RSVP信令，如果它看到感兴趣的流的RSVP信令，它可以禁用该流（或该发送方）的发送方代理行为。或者，通过RSVP信令检查，发送方代理可能
also gradually "learn" (possibly with some timeout) which sender is RSVP-capable and which is not. These mechanisms can facilitate gradual and dynamic migration from the proxy model towards the end-to-end RSVP model as more and more endpoints become RSVP-capable.
也逐渐“了解”（可能有一些超时）哪一个发送方有RSVP能力，哪一个没有。随着越来越多的端点支持RSVP，这些机制可以促进从代理模型到端到端RSVP模型的渐进和动态迁移。
In this approach, the RSVP proxy takes advantage of the application awareness provided by the Session Traversal Utilities for NAT (STUN) ([RFC5389]) signaling to synchronize RSVP reservations with application requirements. The STUN signaling is sent from endpoint to endpoint. This is illustrated in Figure 9. In this approach, a STUN message triggers the RSVP proxy.
在这种方法中，RSVP代理利用会话遍历实用程序为NAT（STUN）（[RFC5389]）信令提供的应用程序感知来同步RSVP预留与应用程序需求。STUN信令从一个端点发送到另一个端点。如图9所示。在这种方法中，STUN消息触发RSVP代理。
|----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----|
|********| |********|
|----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----|
|********| |********|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
=======RSVP=======>
=======RSVP=======>
********************************************************>
********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
^^^> STUN message flow (over same UDP ports as media flow)
^^^> STUN message flow (over same UDP ports as media flow)
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
***> RTP media flow
***> RTP media flow
Figure 9: STUN-Triggered Proxy
图9：眩晕触发代理
For unicast flows, [RFC5245] is a widely adopted approach for Network Address Translator (NAT) traversal. For our purposes of triggering RSVP proxy behavior, we rely on the Interactive Connectivity Establishment (ICE) protocol's connectivity check, which is based on the exchange of STUN Binding Request messages between hosts to verify connectivity (see Section 2.2 of [RFC5245]). The STUN message could also include (yet to be specified) STUN attributes to indicate information such as the bandwidth and application requesting the flow, which would allow the RSVP proxy agent to create an
对于单播流，[RFC5245]是广泛采用的网络地址转换器（NAT）遍历方法。为了触发RSVP代理行为，我们依赖于交互式连接建立（ICE）协议的连接检查，该检查基于主机之间交换STUN绑定请求消息来验证连接（参见[RFC5245]第2.2节）。STUN消息还可以包括（尚未指定）STUN属性，以指示带宽和请求流的应用程序等信息，这将允许RSVP代理创建
appropriately sized reservation for each flow. Including such new STUN attributes in the ICE connectivity check messages would facilitate operation of the RSVP proxy. To ensure RSVP reservations are only established when needed, the RSVP proxy needs to distinguish, among all the STUN messages, the ones that reflect (with high likelihood) an actual upcoming media flow. This can be achieved by identifying the STUN messages associated with an ICE connectivity check. In turn, this can be achieved through (some combination of) the following checks:
每个流的适当大小的预留。在ICE连接检查消息中包含此类新的STUN属性将有助于RSVP代理的操作。为确保仅在需要时建立RSVP保留，RSVP代理需要在所有STUN消息中区分（极有可能）反映实际即将到来的媒体流的消息。这可以通过识别与ICE连接检查相关的STUN消息来实现。反过来，这可以通过以下检查（某些组合）实现：
o if, as discussed above, new STUN attributes (e.g., conveying the flow bandwidth) are indeed defined in the future in view of facilitating STUN-Triggered reservations, then the presence of these attributes would reveal that the STUN message is part of an ICE connectivity check.
o 如上文所述，如果将来确实定义了新的STUN属性（例如，传输流量带宽），以促进STUN触发的预订，则这些属性的存在将表明STUN消息是ICE连接检查的一部分。
o the presence of the PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, or ICE-CONTROLLING attributes reveals that the STUN message is part of an ICE connectivity check.
o 优先级、使用候选、ICE控制或ICE控制属性的存在表明STUN消息是ICE连接检查的一部分。
o the RSVP proxy may wait for a STUN message containing the USE-CANDIDATE attribute indicating the selected ICE "path" to trigger reservation only for the selected "path". This allows the RSVP proxy to only trigger a reservation for the "path" actually selected and therefore for the media flow that will actually be established (for example, when ICE is being used for IPv4/v6 path selection).
o RSVP代理可能会等待包含指示所选ICE“路径”的USE-CANDIDATE属性的STUN消息来触发仅对所选“路径”的保留。这允许RSVP代理仅为实际选择的“路径”触发保留，从而为实际建立的媒体流触发保留（例如，当ICE用于IPv4/v6路径选择时）。
o the RSVP proxy configuration could contain some information facilitating determination of when to perform RSVP proxy reservation and when not to. For example, the RSVP proxy configuration could contain the IP addresses of the STUN servers such that STUN messages to/from those addresses are known to not be part of an ICE connectivity check. As another example, the RSVP proxy configuration could contain information identifying the set of Differentiated Services codepoint (DSCP) values that the media flows requiring reservation use, so that STUN messages not using one of these DSCP values are known to not be part of an ICE connectivity check.
o RSVP代理配置可能包含一些有助于确定何时执行RSVP代理保留以及何时不执行RSVP代理保留的信息。例如，RSVP代理配置可能包含STUN服务器的IP地址，因此发送到/来自这些地址的STUN消息不属于ICE连接检查的一部分。作为另一个示例，RSVP代理配置可以包含标识需要保留使用的媒体流的差异化服务代码点（DSCP）值集的信息，以便不使用这些DSCP值之一的STUN消息被认为不是ICE连接检查的一部分。
Despite these checks, there is always a potential risk that the RSVP proxy will end up establishing a reservation for a media flow that actually never starts. However, this is limited to situations in which the end-systems are interested enough in establishing connectivity for a flow but never transmit. Also, this can be mitigated by timing out and tear down of an unnecessary reservation by the RSVP proxy when no corresponding media flow is observed.
尽管进行了这些检查，RSVP代理始终存在一个潜在的风险，即RSVP代理最终将为实际上从未启动的媒体流建立预订。然而，这仅限于终端系统对建立流的连接感兴趣但从不传输的情况。此外，当没有观察到相应的媒体流时，RSVP代理可以通过超时和取消不必要的保留来缓解这一问题。
The RSVP proxy agent can inform endpoints of an RSVP reservation failure implicitly by dropping the ICE connectivity check message or explicitly by sending ICMP messages back to the endpoint. This allows reasonably effective synchronization between RSVP reservations handled by the RSVP proxies and the application running on non-RSVP-capable endpoints. It also has the benefits of operating through NATs.
RSVP代理可以通过删除ICE连接检查消息隐式通知端点RSVP保留失败，或通过将ICMP消息发送回端点显式通知端点。这允许RSVP代理处理的RSVP保留与在不支持RSVP的端点上运行的应用程序之间进行合理有效的同步。它还具有通过NAT运行的好处。
For multicast flows (or certain kinds of unicast flows that don't or can't use ICE), a STUN Indication message [RFC5389] could be used to carry the (yet to be defined) STUN attributes mentioned earlier to indicate the flow bandwidth, thereby providing a benefit similar to the ICE connectivity check. STUN Indication messages are not acknowledged by the receiver and have the same scalability as the underlying multicast flow.
对于多播流（或不使用或不能使用ICE的某些类型的单播流），可以使用STUN指示消息[RFC5389]来携带前面提到的（尚未定义）STUN属性，以指示流带宽，从而提供类似于ICE连接检查的好处。STUN指示消息不被接收方确认，并且具有与基础多播流相同的可伸缩性。
The corresponding extensions to ICE and STUN for such a STUN-Triggered RSVP Proxy approach are beyond the scope of this document. They may be defined in the future in a separate document. As the STUN-Triggered RSVP Proxy approach uses STUN in a way (i.e., to trigger reservations) that is beyond its initial intended purpose, the potential security implications need to be considered by the operator.
对于这种STUN触发的RSVP代理方法，ICE和STUN的相应扩展超出了本文档的范围。将来可在单独的文件中对其进行定义。由于STUN触发的RSVP代理方法使用STUN的方式（即触发预订）超出了其最初的预期目的，因此运营商需要考虑潜在的安全影响。
ICE connectivity checks are not always used for all flows. When the STUN-Triggered RSVP Proxy approach is used, it can establish RSVP reservations for flows for which ICE connectivity is performed. However, the STUN-Triggered RSVP Proxy will not establish a reservation for flows for which an ICE connectivity check is not performed. Those flows either will not benefit from an RSVP reservation or can benefit from an RSVP reservation established through other means (end-to-end RSVP, other forms of RSVP proxy).
ICE连通性检查并不总是用于所有流。当使用STUN触发的RSVP代理方法时，它可以为执行ICE连接的流建立RSVP保留。但是，STUN触发的RSVP代理不会为未执行ICE连接检查的流建立保留。这些流要么不会受益于RSVP保留，要么可以受益于通过其他方式（端到端RSVP、其他形式的RSVP代理）建立的RSVP保留。
The STUN-Triggered approach relies on interception and inspection of STUN messages. Thus, this approach may be impeded by encryption or tunneling.
眩晕触发方法依赖于对眩晕信息的拦截和检查。因此，这种方法可能会受到加密或隧道的阻碍。
In this approach, it is assumed that an entity involved in the application-level signaling controls an RSVP proxy that is located in the data path of the application flows (i.e., "on-path"). With this approach, the RSVP proxy does not itself attempt to determine the application reservation requirements. Instead, the RSVP proxy is instructed by the entity participating in application-level signaling to establish, maintain, and tear down reservations as needed by the application flows. In other words, with this approach, the solution for synchronizing RSVP signaling with application-level requirements
在该方法中，假设应用级信令中涉及的实体控制位于应用流的数据路径（即，“路径上”）中的RSVP代理。使用这种方法，RSVP代理本身不会试图确定应用程序保留要求。相反，参与应用程序级信令的实体指示RSVP代理根据应用程序流的需要建立、维护和撤销保留。换句话说，通过这种方法，将RSVP信令与应用程序级需求同步的解决方案
is to rely on an application-level signaling entity that controls an RSVP proxy function that sits in the flow data path. This approach allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy, or both.
依赖于控制位于流数据路径中的RSVP代理功能的应用程序级信令实体。此方法允许控制RSVP发送方代理、RSVP接收方代理或两者。
Operation of the Application_Entity-Controlled Proxy is illustrated in Figure 10.
图10说明了应用程序\实体控制代理的操作。
|---------| |---------|
/////////| App |////\\\\| App |\\\\\\\\
/ | Entity | | Entity | \
/ |---------| |---------| \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
|----| |********| *** |*********| |----|
| S |----------| |------*r*-------| |---------| R |
|----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver|
| Proxy | | Proxy |
|********| |*********|
|---------| |---------|
/////////| App |////\\\\| App |\\\\\\\\
/ | Entity | | Entity | \
/ |---------| |---------| \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
|----| |********| *** |*********| |----|
| S |----------| |------*r*-------| |---------| R |
|----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver|
| Proxy | | Proxy |
|********| |*********|
=======RSVP=======>
=======RSVP=======>
********************************************************>
********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
/\ Application signaling (e.g., SIP)
/\应用信令（如SIP）
// RSVP proxy control interface
//RSVP代理控制接口
Figure 10: Application_Entity-Controlled Proxy
图10：实体控制代理的应用程序
As an example, the Application_Entity-Controlled Proxy may be used in the context of SIP servers ([RFC3261]) or Session Border Controllers (SBCs) (see [RFC5853] for a description of SBCs) to establish RSVP reservations for multimedia sessions. In that case, the application entity may be the signaling component of the SBC.
例如，应用程序实体控制的代理可在SIP服务器（[RFC3261]）或会话边界控制器（SBC）的上下文中使用（参见[RFC5853]了解SBC的描述），以建立多媒体会话的RSVP预留。在这种情况下，应用实体可以是SBC的信令组件。
This RSVP proxy approach does not require any extension to the RSVP protocol. However, it relies on an RSVP proxy control interface allowing control of the RSVP proxy by an application signaling entity. This RSVP proxy control interface is beyond the scope of this document. Candidate protocols for realizing such an interface include the IETF Network Configuration (NETCONF) Protocol ([RFC4741], [RFC5277]), the Web Services protocol ([W3C]), the QoS Policy Information Model (QPIM) ([RFC3644]), and Diameter ([RFC3588]). This interface can rely on soft states or hard states. Clearly, when hard states are used, those need to be converted appropriately by the RSVP proxy entities into the corresponding RSVP soft states. As an example, [RFC5866] is intended to allow control of RSVP proxy via Diameter.
这种RSVP代理方法不需要对RSVP协议进行任何扩展。然而，它依赖于RSVP代理控制接口，允许应用程序信令实体控制RSVP代理。此RSVP代理控制接口超出了本文档的范围。用于实现这种接口的候选协议包括IETF网络配置（NETCONF）协议（[RFC4741]、[RFC5277]）、Web服务协议（[W3C]）、QoS策略信息模型（QPIM）（[RFC3644]）和Diameter（[RFC3588]）。此接口可以依赖于软状态或硬状态。显然，当使用硬状态时，这些状态需要由RSVP代理实体适当地转换为相应的RSVP软状态。例如，[RFC5866]旨在通过直径控制RSVP代理。
In general, the application entity is not expected to maintain awareness of which RSVP Receiver Proxy is on the path to which destination. However, in the particular cases where it does so reliably, we observe that the application entity could control the RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP reservations are used between those, instead of one reservation per flow. For example, these aggregate reservations could be of the RSVP-AGGREGATE type, as specified in [RFC3175], or of the GENERIC-AGGREGATE type, as specified in [RFC4860]. Such aggregate reservations could be used so that a single reservation can be used for multiple (possibly all) application flows transiting via the same RSVP Sender Proxy and the same RSVP Receiver Proxy.
通常，应用程序实体不需要保持对哪个RSVP接收方代理位于哪个目的地的路径上的感知。然而，在这种情况下是可靠的，我们观察到应用实体可以控制RSVP发送方代理和接收方代理，以便在它们之间使用聚合RSVP保留，而不是每个流使用一个保留。例如，这些聚合保留可以是[RFC3175]中指定的RSVP-AGGRATE类型，也可以是[RFC4860]中指定的GENERIC-AGGRATE类型。可以使用这种聚合保留，以便单个保留可以用于通过同一RSVP发送方代理和同一RSVP接收方代理传输的多个（可能全部）应用程序流。
For situations in which only the RSVP Sender Proxy has to be controlled by this interface, the interface may be realized through the simple use of RSVP itself, over a Generic Routing Encapsulation (GRE) tunnel from the application entity to the RSVP Sender Proxy. This particular case is further discussed in Section 4.5.1. Another particular case of interest is where the application signaling entity resides on the same device as the RSVP proxy. In that case, this interface may be trivially realized as an internal API. An example environment based on this particular case is illustrated in Section 4.5.2.
对于只有RSVP发送方代理必须由该接口控制的情况，可以通过简单使用RSVP本身，通过从应用实体到RSVP发送方代理的通用路由封装（GRE）隧道来实现该接口。第4.5.1节进一步讨论了这种特殊情况。另一种特殊情况是，应用程序信令实体与RSVP代理驻留在同一设备上。在这种情况下，这个接口可以简单地实现为一个内部API。第4.5.2节说明了基于此特定情况的示例环境。
The application entity controlling the RSVP proxy (e.g., a SIP Call Agent) would often be aware of a number of endpoint capabilities, and it has to be aware of which endpoint can be best "served" by which RSVP proxy anyways. So it is reasonable to assume that such an application is aware of whether a given endpoint is RSVP-capable or not. The application may also consider the QoS preconditions and QoS mechanisms signaled by an endpoint as per [RFC3312]/[RFC4032] and [RFC5432]. The information about endpoint RSVP capability can then be used by the application to decide whether to trigger proxy behavior or not for a given endpoint. This can facilitate gradual
控制RSVP代理的应用实体（例如，SIP呼叫代理）通常会知道许多端点功能，并且它必须知道哪一个端点可以通过哪一个RSVP代理获得最佳“服务”。因此，有理由假设这样的应用程序知道给定端点是否支持RSVP。该应用还可以考虑由[FRC312]／[RFC4032 ]和[RCFC32 32 ]由端点发送的QoS前提条件和QoS机制。然后，应用程序可以使用有关端点RSVP功能的信息来决定是否触发给定端点的代理行为。这有助于逐步提高效率
and dynamic migration from the proxy model towards the end-to-end RSVP model as more and more endpoints become RSVP-capable.
随着越来越多的端点支持RSVP，从代理模型向端到端RSVP模型进行动态迁移。
In some environments, the application entities (e.g., SIP back-to-back user agents) that need to control the RSVP proxies would already be deployed independently of the use, or not, of the Application_Entity-Controlled Proxy approach. In this case, the activation of the RSVP proxy approach should not introduce significant disruption in the application signaling path. In some environments, additional application entities may need to be deployed to control the RSVP proxies. In this case, the network operator needs to consider the associated risks of disruption to the application signaling path.
在某些环境中，需要控制RSVP代理的应用程序实体（例如，SIP背对背用户代理）已经独立于应用程序实体控制的代理方法的使用或不使用而部署。在这种情况下，RSVP代理方法的激活不应在应用程序信令路径中引入重大中断。在某些环境中，可能需要部署其他应用程序实体来控制RSVP代理。在这种情况下，网络运营商需要考虑中断对应用信令路径的相关风险。
This approach is simply a particular case of the more general Application_Entity-Controlled Proxy, but where only RSVP Sender Proxies need to be controlled by the application, and where RSVP is effectively used as the control protocol between the application-signaling entity and the RSVP Sender Proxy.
这种方法只是更一般的应用程序实体控制代理的一种特殊情况，但应用程序只需要控制RSVP发送方代理，并且RSVP被有效地用作应用程序信令实体和RSVP发送方代理之间的控制协议。
In this approach, the RSVP messages (e.g., RSVP Path message) are effectively generated by the application entity and logically "tunneled" to the RSVP Sender Proxy via GRE tunneling. This is to ensure that the RSVP messages follow the exact same path as the flow they protect (as required by RSVP operations) on the segment of the end-to-end path that is to be subject to RSVP reservations.
在这种方法中，RSVP消息（例如，RSVP路径消息）由应用实体有效地生成，并通过GRE隧道从逻辑上“隧道”到RSVP发送方代理。这是为了确保RSVP消息在端到端路径段上遵循与其保护的流完全相同的路径（根据RSVP操作的要求），该段路径将受RSVP保留的约束。
Figure 11 illustrates such an environment.
图11说明了这种环境。
|-------------|
////////////| Application |\\\\\\\\\
/ | Entity | \
/ |-------------| \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
|----| |********| *** |****|
| S |-----------| RSVP |-----------*r*-----------------| R |
|----| | Sender | *** |****|
| Proxy |
|********|
|-------------|
////////////| Application |\\\\\\\\\
/ | Entity | \
/ |-------------| \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
|----| |********| *** |****|
| S |-----------| RSVP |-----------*r*-----------------| R |
|----| | Sender | *** |****|
| Proxy |
|********|
=========RSVP====================>
=========RSVP====================>
*****************************************************>
*****************************************************>
|----| non-RSVP-capable |----| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
|----| non-RSVP-capable |----| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
/\ Application-level signaling
/\应用层信令
/=/ GRE-tunneled RSVP (Path messages)
/=/ GRE-tunneled RSVP (Path messages)
Figure 11: Application_Entity-Controlled Sender Proxy via "RSVP over GRE"
图11：通过“GRE上的RSVP”应用程序\实体控制的发送方代理
With the Application_Entity-Controlled Sender Proxy using "RSVP Over GRE", the application entity:
使用“RSVP Over GRE”的应用程序实体控制的发送方代理，应用程序实体：
o generates a Path message on behalf of the sender, corresponding to the reservation needed by the application, and maintains the corresponding Path state. The Path message built by the application entity is exactly the same as would be built by the actual sender (if it was RSVP-capable), with one single exception, which is that the application entity puts its own IP address as the RSVP previous hop. In particular, it is recommended that the
o 代表发送方生成与应用程序所需的保留相对应的路径消息，并维护相应的路径状态。应用程序实体生成的路径消息与实际发送方生成的路径消息完全相同（如果它支持RSVP），只有一个例外，即应用程序实体将其自己的IP地址作为RSVP上一跳。特别是，建议
source address of the Path message built by the application entity be set to the IP address of the sender (not of the application entity). This helps ensure that, in the presence of non-RSVP routers and of load-balancing in the network where the load-balancing algorithm takes into account the source IP address, the Path message generated by the application entity follows the exact same path as the actual stream sourced by the sender.
应用程序实体生成的路径消息的源地址必须设置为发送方（而不是应用程序实体）的IP地址。这有助于确保，在网络中存在非RSVP路由器和负载平衡（其中负载平衡算法考虑源IP地址）的情况下，应用实体生成的路径消息遵循与发送方来源的实际流完全相同的路径。
o encapsulates the Path message into a GRE tunnel whose destination address is the RSVP Sender Proxy, i.e., an RSVP router sitting on the data path for the flow (and upstream of the segment that requires QoS guarantees via RSVP reservation).
o 将路径消息封装到GRE隧道中，该隧道的目标地址为RSVP发送方代理，即位于流数据路径上的RSVP路由器（以及需要通过RSVP保留提供QoS保证的段上游）。
o processes the corresponding received RSVP messages (including Resv messages) as per regular RSVP.
o 按照常规RSVP处理相应的接收RSVP消息（包括Resv消息）。
o synchronizes the RSVP reservation state with application-level requirements and signaling.
o 将RSVP保留状态与应用程序级需求和信令同步。
Note that since the application entity encodes its own IP address as the previous RSVP hop inside the [RFC2205] RSVP_HOP object of the Path message, the RSVP router terminating the GRE tunnel naturally addresses all the RSVP messages traveling upstream hop-by-hop (such as Resv messages) to the application entity (without having to encapsulate those in a reverse-direction GRE tunnel towards the application entity).
注意，由于应用实体将其自己的IP地址编码为路径消息的[RFC2205]RSVP_-hop对象内的前一个RSVP跃点，因此终止GRE隧道的RSVP路由器自然地将上行逐跳移动的所有RSVP消息（例如Resv消息）寻址到应用实体（无需将它们封装在朝向应用程序实体的反向GRE通道中）。
This approach is simply a particular case of the more general Application_Entity-Controlled Proxy, but where the application entity is co-located with the RSVP proxy. As an example, Session Border Controllers (SBCs) with on-board SIP agents could implement RSVP proxy functions and make use of such an approach to achieve session admission control over the SBC-to-SBC segment using RSVP signaling.
这种方法只是更一般的应用程序实体控制代理的一种特殊情况，但应用程序实体与RSVP代理位于同一位置。例如，具有板载SIP代理的会话边界控制器（SBC）可以实现RSVP代理功能，并利用这种方法通过RSVP信令实现SBC到SBC段的会话接纳控制。
Figure 12 illustrates operations of the Application_Entity-Controlled RSVP Proxy via co-location.
图12说明了应用程序实体控制的RSVP代理通过同一位置的操作。
|---------| |---------|
////////| App |////////\\\\\\\| App |\\\\\\\\\
/ | Entity | | Entity | \
/ | | | | \
|----| |*********| *** |*********| |----|
| S |--------| RSVP |------*r*------| RSVP |---------| R |
|----| | Sender | *** | Receiver| |----|
| Proxy | | Proxy |
|*********| |*********|
|---------| |---------|
////////| App |////////\\\\\\\| App |\\\\\\\\\
/ | Entity | | Entity | \
/ | | | | \
|----| |*********| *** |*********| |----|
| S |--------| RSVP |------*r*------| RSVP |---------| R |
|----| | Sender | *** | Receiver| |----|
| Proxy | | Proxy |
|*********| |*********|
=======RSVP======>
=======RSVP======>
*******************************************************>
*******************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
/\ Application-level signaling
/\应用层信令
Figure 12: Application_Entity-Controlled Proxy via Co-Location
图12：通过同一地点的应用程序/实体控制代理
This RSVP proxy approach does not require any protocol extensions. We also observe that when multiple sessions are to be established on paths sharing the same RSVP Sender Proxy and the same RSVP Receiver Proxy, the RSVP proxies have the option to establish aggregate RSVP reservations (as defined in ([RFC3175] or [RFC4860]) for a group of sessions, instead of establishing one RSVP reservation per session.
这种RSVP代理方法不需要任何协议扩展。我们还观察到，当在共享相同RSVP发送方代理和相同RSVP接收方代理的路径上建立多个会话时，RSVP代理可以选择为一组会话建立聚合RSVP保留（如（[RFC3175]或[RFC4860]中所定义），而不是为每个会话建立一个RSVP保留。
In this approach, it is assumed that a policy server, which is located in the control plane of the network, controls an RSVP proxy that is located in the data path of the application flows (i.e., "on-path"). In turn, the policy server is triggered by an entity involved in the application-level signaling. With this approach, the RSVP proxy does not itself attempt to determine the application reservation requirements, but instead is instructed by the policy server to establish, maintain, and tear down reservations as needed by the application flows. Moreover, the entity participating in application-level signaling does not attempt to understand the specific reservation mechanism (i.e., RSVP) or the topology of the network layer, but instead it simply asks the policy server to
在该方法中，假设位于网络控制平面中的策略服务器控制位于应用程序流的数据路径（即“on path”）中的RSVP代理。反过来，策略服务器由应用程序级信令中涉及的实体触发。使用这种方法，RSVP代理本身不会尝试确定应用程序保留要求，而是由策略服务器指示根据应用程序流的需要建立、维护和删除保留。此外，参与应用层信令的实体并不试图理解特定的保留机制（即RSVP）或网络层的拓扑，而是简单地要求策略服务器
perform (or tear down) a reservation. In other words, with this approach, the solution for synchronizing RSVP signaling with application-level requirements is to rely on an application-level entity that controls a policy server that, in turn, controls an RSVP proxy function that sits in the flow data path. This approach allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy, or both.
执行（或取消）预订。换句话说，使用这种方法，将RSVP信令与应用程序级需求同步的解决方案是依赖于控制策略服务器的应用程序级实体，该策略服务器反过来控制位于流数据路径中的RSVP代理功能。此方法允许控制RSVP发送方代理、RSVP接收方代理或两者。
Operation of the Policy_Server-Controlled proxy is illustrated in Figure 13.
图13说明了策略_服务器控制的代理的操作。
|---------|
/////////////| App |\\\\\\\\\\\\\\
/ | Entity | \
/ |---------| \
/ I \
/ I \
/ |----------| \
/ | Policy | \
/ | Server | \
/ |----------| \
/ // \\ \
/ // \\ \
/ // \\ \
|----| |********| *** |*********| |----|
| S |-----------| |------*r*-----| |----------| R |
|----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver|
| Proxy | | Proxy |
|********| |*********|
|---------|
/////////////| App |\\\\\\\\\\\\\\
/ | Entity | \
/ |---------| \
/ I \
/ I \
/ |----------| \
/ | Policy | \
/ | Server | \
/ |----------| \
/ // \\ \
/ // \\ \
/ // \\ \
|----| |********| *** |*********| |----|
| S |-----------| |------*r*-----| |----------| R |
|----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver|
| Proxy | | Proxy |
|********| |*********|
=====RSVP========>
=====RSVP========>
**********************************************************>
**********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
/\ Application signaling (e.g., SIP)
/\应用信令（如SIP）
// RSVP proxy control interface
//RSVP代理控制接口
I Interface between application entity and policy server
I应用程序实体和策略服务器之间的接口
Figure 13: Policy_Server-Controlled Proxy
图13：策略_服务器控制的代理
This RSVP proxy approach does not require any extension to the RSVP protocol. However, as with the Application_Entity-Controlled Proxy approach presented in Figure 10, this approach relies on an RSVP proxy control interface allowing control of the RSVP proxy (by the policy server in this case). This RSVP proxy control interface is beyond the scope of this document. Considerations about candidate protocols for realizing such an interface can be found in
这种RSVP代理方法不需要对RSVP协议进行任何扩展。然而，与图10所示的应用程序实体控制代理方法一样，这种方法依赖于RSVP代理控制接口，允许控制RSVP代理（在这种情况下由策略服务器控制）。此RSVP代理控制接口超出了本文档的范围。关于实现这种接口的候选协议的考虑可以在中找到
Section 4.5. Again, for situations in which only the RSVP Sender Proxy has to be controlled by this interface, the interface may be realized through the simple use of RSVP itself, over a GRE tunnel from the policy server to the RSVP Sender Proxy. This is similar to what is presented in Section 4.5.1, except that the "RSVP over GRE" interface is used in this case by the policy server (instead of the application entity).
第4.5节。同样，对于只有RSVP发送方代理必须由该接口控制的情况，可以通过简单使用RSVP本身，通过从策略服务器到RSVP发送方代理的GRE隧道来实现该接口。这与第4.5.1节中的内容类似，只是在这种情况下，策略服务器（而不是应用程序实体）使用了“RSVP over GRE”接口。
The interface between the application entity and the policy server is beyond the scope of this document.
应用程序实体和策略服务器之间的接口超出了本文档的范围。
An RSVP proxy can also be triggered and controlled through extended RSVP signaling from the remote end that is RSVP-capable (and supports these RSVP extensions for proxy control). For example, an RSVP-capable sender could send a new or extended RSVP message explicitly requesting an RSVP proxy on the path towards the receiver to behave as an RSVP Receiver Proxy and also to trigger a reverse-direction reservation, thus also behaving as an RSVP Sender Proxy. The new or extended RSVP message sent by the sender could also include attributes (e.g., bandwidth) for the reservations to be signaled by the RSVP proxy.
RSVP代理也可以通过远程端的扩展RSVP信令触发和控制，远程端具有RSVP功能（并支持这些用于代理控制的RSVP扩展）。例如，具有RSVP功能的发送方可以发送新的或扩展的RSVP消息，明确请求通向接收方的路径上的RSVP代理充当RSVP接收方代理，并触发反向保留，从而也充当RSVP发送方代理。发送方发送的新的或扩展的RSVP消息还可以包括RSVP代理发送的预留的属性（例如，带宽）。
The challenges in these explicit signaling schemes include the following:
这些显式信令方案中的挑战包括：
o How can the nodes determine when a reservation request ought to be proxied and when it should not, and accordingly invoke appropriate signaling procedures?
o 节点如何确定何时应该代理保留请求以及何时不应该代理保留请求，并相应地调用适当的信令过程？
o How does the node sending the messages explicitly triggering the proxy know where the proxy is located, e.g., determine an IP address of the proxy that should reply to the signaling?
o 发送显式触发代理的消息的节点如何知道代理的位置，例如，确定应该回复信令的代理的IP地址？
o How is all the information needed by a Sender Proxy to generate a Path message actually communicated to the proxy?
o 发送方代理如何将生成路径消息所需的所有信息实际传递给代理？
An example of such a mechanism is presented in [QOS-MOBILE]. This scheme is primarily targeted to local access network reservations whereby an end host can request resource reservations for both incoming and outgoing flows only over the access network. This may be useful in environments where the access network is typically the bottleneck while the core is comparatively over-provisioned, as may be the case with a number of radio access technologies. In this proposal, messages targeted to the proxy are flagged with one bit in all RSVP messages. Similarly, all RSVP messages sent back by the proxy are also flagged. The use of such a flag allows
[QOS-MOBILE]中给出了此类机制的一个示例。此方案主要针对本地接入网络预留，因此终端主机只能通过接入网络请求传入和传出流的资源预留。这在接入网络通常是瓶颈而核心相对过度供应的环境中可能是有用的，如许多无线接入技术的情况。在该方案中，所有RSVP消息中以代理为目标的消息都标记一位。同样，代理发送回的所有RSVP消息也会被标记。使用这样的标志允许
differentiating between proxied and end-to-end reservations. For triggering an RSVP Receiver Proxy, the sender of the data sends a Path message that is marked with the mentioned flag. The Receiver Proxy is located on the signaling and data path, eventually gets the Path message, and replies back with a Resv message. A node triggers an RSVP Sender Proxy with a newly defined Path_Request message, which instructs the proxy to send Path messages towards the triggering node. The node then replies back with a Resv. More details can be found in [QOS-MOBILE].
区分代理预订和端到端预订。为了触发RSVP接收方代理，数据发送方发送一条标有上述标志的路径消息。接收方代理位于信令和数据路径上，最终获取路径消息，并用Resv消息回复。节点使用新定义的Path_请求消息触发RSVP发送方代理，该消息指示代理向触发节点发送Path消息。然后节点用Resv回复。更多详细信息请参见[QOS-MOBILE]。
Such an RSVP-Signaling-Triggered Proxy approach would require RSVP signaling extensions (that are outside the scope of this document). However, it could provide more flexibility in the control of the proxy behavior (e.g., control of reverse reservation parameters) than would the Path-Triggered approaches defined in Section 4.1 and Section 4.2.
这种RSVP信令触发的代理方法需要RSVP信令扩展（不在本文档范围内）。然而，与第4.1节和第4.2节中定义的路径触发方法相比，它可以在代理行为的控制（例如，反向保留参数的控制）方面提供更大的灵活性。
Through potential corresponding protocol extensions, an RSVP-Signaling-Triggered Proxy approach could facilitate operation (e.g., reduce or avoid the need for associated configuration) in hybrid environments involving both reservations established end-to-end and reservations established via RSVP proxies. For example, [QOS-MOBILE] proposed a mechanism allowing an end-system to control whether a reservation can be handled by an RSVP proxy on the path, or is to be established end-to-end.
通过潜在的相应协议扩展，RSVP信令触发的代理方法可以促进混合环境中的操作（例如，减少或避免相关配置的需要），包括端到端建立的预留和通过RSVP代理建立的预留。例如，[QOS-MOBILE]提出了一种机制，允许终端系统控制保留是可以由路径上的RSVP代理处理，还是要端到端建立。
There may be situations in which the RSVP Receiver Proxy is reachable by the sender, while the receiver itself is not. In such situations, it is possible that the RSVP Receiver Proxy is not always aware that the receiver is unreachable, and consequently may accept to establish an RSVP reservation on behalf of that receiver. This would result in unnecessary reservation establishment and unnecessary network resource consumption.
可能存在这样的情况：发送方可以访问RSVP接收方代理，而接收方本身无法访问。在这种情况下，RSVP接收器代理可能并不总是知道接收器是不可访问的，因此可能接受代表该接收器建立RSVP保留。这将导致不必要的预约建立和不必要的网络资源消耗。
This is not considered a significant practical concern for a number of reasons. First, in many cases, if the receiver is not reachable from the sender, it will not be reachable for application signaling either, and so application-level session establishment will not be possible in the first place. Secondly, where the receiver is unreachable from the sender but is reachable for application-level signaling (say, because session establishment is performed through an off-path SIP agent that uses a different logical topology to communicate with the receiver), then the sender may detect that the receiver is unreachable before attempting reservation establishment. This may be achieved through mechanisms such as ICE's connectivity check ([RFC5245]). Finally, even if the sender does not detect that
由于许多原因，这不被认为是一个重大的实际问题。首先，在许多情况下，如果发送方无法到达接收方，那么应用程序信令也无法到达接收方，因此首先不可能建立应用程序级会话。第二，其中接收机无法从发送方到达，但可通过应用级信令到达（例如，因为会话建立是通过使用不同逻辑拓扑与接收机通信的非路径SIP代理执行的），然后，发送方可以在尝试建立预约之前检测到接收方不可到达。这可以通过ICE的连接检查（[RFC5245]）等机制实现。最后，即使发送方没有检测到
the receiver is unreachable before triggering the RSVP reservation establishment, it is very likely that the application will quickly realize this lack of connectivity (e.g., the human accepting the phone call on the receiver side will not hear the human's voice on the sender side) and therefore tear down the session (e.g., hang up the phone), which in turn will trigger RSVP reservation release.
在触发RSVP预约建立之前无法联系到接收方，应用程序很可能会很快意识到这种连接的缺乏（例如，在接收方接受电话的人将听不到发送方的人的声音），因此中断会话（例如，挂断电话），这反过来将触发RSVP保留释放。
Nonetheless, it is recommended that network administrators consider the above in light of their particular environment when deploying RSVP proxies.
然而，建议网络管理员根据部署RSVP代理时的特定环境考虑上述情况。
The mirror considerations apply for situations involving an RSVP Sender Proxy and where the sender cannot reach the destination while the RSVP Sender Proxy can.
镜像注意事项适用于涉及RSVP发送方代理以及发送方无法到达目标而RSVP发送方代理可以到达的情况。
In the environments of concern for this document, RSVP messages are used to control resource reservations on a segment of the end-to-end path of flows. The general security considerations associated with [RFC2205] apply. To ensure the integrity of the associated reservation and admission control mechanisms, the RSVP cryptographic authentication mechanisms defined in [RFC2747] and [RFC3097] can be used. Those protect RSVP messages integrity hop-by-hop and provide node authentication, thereby protecting against corruption, spoofing of RSVP messages, and replay. [RSVP-SEC-KEY] discusses key types and key provisioning methods, as well as their respective applicability to RSVP authentication.
在本文档关注的环境中，RSVP消息用于控制流的端到端路径段上的资源保留。与[RFC2205]相关的一般安全注意事项适用。为了确保相关保留和许可控制机制的完整性，可以使用[RFC2747]和[RFC3097]中定义的RSVP加密身份验证机制。它们逐跳保护RSVP消息的完整性，并提供节点身份验证，从而防止RSVP消息的损坏、欺骗和重播。[RSVP-SEC-KEY]讨论密钥类型和密钥提供方法，以及它们各自对RSVP身份验证的适用性。
[RSVP-SEC-KEY] also discusses applicability of IPsec mechanisms ([RFC4302][RFC4303]) and associated key provisioning methods for security protection of RSVP. This discussion applies to the protection of RSVP in the presence of RSVP proxies as defined in this document.
[RSVP-SEC-KEY]还讨论了IPsec机制（[RFC4302][RFC4303]）的适用性以及用于RSVP安全保护的相关密钥设置方法。本讨论适用于本文件中定义的RSVP代理存在时的RSVP保护。
A subset of RSVP messages are signaled with the IP router alert option ([RFC2113], [RFC2711]). Based on the current security concerns associated with the use of the IP router alert option, the applicability of RSVP (and therefore of the RSVP proxy approaches discussed in this document) is limited to controlled environments (i.e., environments where the security risks associated with the use of the IP router alert option are understood and protected against). The security aspects and common practices around the use of the current IP router alert option, and consequences of using the IP router alert option by applications such as RSVP, are discussed in detail in [RTR-ALERT].
RSVP消息的子集通过IP路由器警报选项（[RFC2113]、[RFC2711]）发出信号。基于与使用IP路由器警报选项相关的当前安全问题，RSVP（以及本文档中讨论的RSVP代理方法）的适用性仅限于受控环境（即，了解并防范与使用IP路由器警报选项相关的安全风险的环境）。有关使用当前IP路由器警报选项的安全方面和常见做法，以及应用程序（如RSVP）使用IP路由器警报选项的后果，将在中详细讨论[RTR-ALERT]。
A number of additional security considerations apply to the use of RSVP proxies and are discussed below.
RSVP代理的使用还需要考虑一些额外的安全因素，下文将对此进行讨论。
With some RSVP proxy approaches, the RSVP proxy operates autonomously inside an RSVP router. This is the case for the Path-Triggered Proxy approaches defined in Section 4.1 and in Section 4.2, for the Inspection-Triggered Proxy approach defined in Section 4.3, for the STUN-Triggered Proxy approach defined in Section 4.4, and for the RSVP-Signaling-Triggered approach defined in Section 4.7. Proper reservation operation assumes that the RSVP proxy can be trusted to behave correctly in order to control the RSVP reservation as required and expected by the end-systems. Since the basic RSVP operation already assumes a trust model where end-systems trust RSVP nodes to appropriately perform RSVP reservations, the use of an RSVP proxy that behaves autonomously within an RSVP router is not seen as introducing any significant additional security threat or as fundamentally modifying the RSVP trust model.
使用某些RSVP代理方法，RSVP代理在RSVP路由器内自动运行。第4.1节和第4.2节中定义的路径触发代理进近、第4.3节中定义的检查触发代理进近、第4.4节中定义的STUN触发代理进近以及第4.7节中定义的RSVP信令触发进近就是这种情况。正确的保留操作假定可以信任RSVP代理正常工作，以便按照终端系统的要求和预期控制RSVP保留。由于基本RSVP操作已经假设了一个信任模型，其中终端系统信任RSVP节点以适当地执行RSVP保留，因此使用在RSVP路由器内自主行为的RSVP代理不被视为引入任何显著的额外安全威胁或从根本上修改RSVP信任模型。
With some RSVP proxy approaches, the RSVP proxy operates under the control of another entity. This is the case for the Application_Entity-Controlled Proxy approach defined in Section 4.5 and for the Policy_Server-Controlled Proxy approach defined in Section 4.6. This introduces additional security risks since the entity controlling the RSVP proxy needs to be trusted for proper reservation operation and also introduces additional authentication and confidentiality requirements. The exact mechanisms to establish such trust, authentication, and confidentiality are beyond the scope of this document, but they may include security mechanisms inside the protocol used as the control interface between the RSVP proxy and the entity controlling it, as well as security mechanisms for all the interfaces involved in the reservation control chain (e.g., inside the application signaling protocol between the end-systems and the application entity, and, in the case of the Policy_Server-Controlled Proxy approach, in the protocol between the application entity and the policy server).
通过一些RSVP代理方法，RSVP代理在另一个实体的控制下运行。第4.5节中定义的应用程序实体控制代理方法和第4.6节中定义的策略服务器控制代理方法就是这种情况。这会带来额外的安全风险，因为控制RSVP代理的实体需要被信任才能进行正确的保留操作，并且还会带来额外的身份验证和保密要求。建立此类信任、认证和保密性的确切机制不在本文件范围内，但它们可能包括协议内的安全机制，该协议用作RSVP代理和控制它的实体之间的控制接口，以及保留控制链中涉及的所有接口的安全机制（例如，在终端系统和应用实体之间的应用信令协议内，以及在策略服务器控制的代理方法的情况下，在应用实体和策略服务器之间的协议内）。
In some situations, the use of RSVP proxy to control reservations on behalf of end-systems may actually reduce the security risk (at least from the network operator viewpoint). This could be the case, for example, because the routers where the RSVP proxy functionality runs are less exposed to tampering than end-systems. Such a case is further discussed in Section 4 of [RFC5946]. This could also be the case because the use of RSVP proxy allows localization of RSVP operation within the boundaries of a given administrative domain (thus easily operating as a controlled environment) while the end-to-end flow path spans multiple administrative domains.
在某些情况下，使用RSVP代理代表终端系统控制保留实际上可能会降低安全风险（至少从网络运营商的角度来看）。例如，这可能是因为运行RSVP代理功能的路由器比终端系统更容易受到篡改。[RFC5946]第4节进一步讨论了这种情况。这种情况也可能发生，因为使用RSVP代理可以在给定管理域的边界内定位RSVP操作（因此可以轻松地作为受控环境操作），而端到端流路径跨越多个管理域。
This document benefited from earlier work on the concept of RSVP proxy including the one documented by Silvano Gai, Dinesh Dutt, Nitsan Elfassy, and Yoram Bernet. It also benefited from discussions with Pratik Bose, Chris Christou, and Michael Davenport. Tullio Loffredo and Massimo Sassi provided the base material for Section 4.6. Thanks to James Polk, Magnus Westerlund, Dan Romascanu, Ross Callon, Cullen Jennings, and Jari Arkko for their thorough review and comments.
本文件得益于之前关于RSVP代理概念的工作，包括Silvano Gai、Dinesh Dutt、Nitsan Elfasse和Yoram Bernet记录的文件。它还受益于与普拉蒂克·Bose、克里斯·克里斯托和迈克尔·达文波特的讨论。Tullio Loffredo和Massimo Sassi为第4.6节提供了基础材料。感谢詹姆斯·波尔克、马格努斯·韦斯特隆德、丹·罗马斯卡努、罗斯·卡隆、卡伦·詹宁斯和贾里·阿尔科的全面回顾和评论。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[QOS-MOBILE] Manner, J., "Provision of Quality of Service in IP-based Mobile Access Networks", Doctoral dissertation, University of Helsinki, 2003, <http://ethesis.helsinki.fi>.
[QOS- Mobile ]方式，J.，“基于IP的移动接入网的服务质量提供”，博士论文，赫尔辛基大学，2003，<http://ethesis.helsinki.fi>.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，B.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC163331994年6月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[RFC2474] 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.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000.
[RFC2872]Bernet，Y.和R.Pabbati，“与RSVP一起使用的应用程序和子应用程序标识策略元素”，RFC 2872，2000年6月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003.
[RFC3644]Snir，Y.，Ramberg，Y.，Strassner，J.，Cohen，R.，和B.Moore，“政策服务质量（QoS）信息模型”，RFC 36442003年11月。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032]Camarillo，G.和P.Kyzivat，“会话启动协议（SIP）先决条件框架的更新”，RFC 4032，2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]Enns，R.，“网络配置协议”，RFC 47412006年12月。
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4860]Le Faucheur，F.，Davie，B.，Bose，P.，Christou，C.，和M.Davenport，“通用聚合资源预留协议（RSVP）预留”，RFC 48602007年5月。
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling in a Nested Virtual Private Network", RFC 4923, August 2007.
[RFC4923]Baker，F.和P.Bose，“嵌套虚拟专用网络中的服务质量（QoS）信令”，RFC 49232007年8月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277]Chisholm，S.和H.Trevino，“NETCONF事件通知”，RFC 5277，2008年7月。
[RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", RFC 5432, March 2009.
[RFC5432]Polk，J.，Dhesikan，S.，和G.Camarillo，“会话描述协议（SDP）中的服务质量（QoS）机制选择”，RFC 5432，2009年3月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853]Hautakorpi，J.，Camarillo，G.，Penfield，R.，Hawrylyshen，A.，和M.Bhatia，“会话启动协议（SIP）会话边界控制（SBC）部署的要求”，RFC 58532010年4月。
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010.
[RFC5866]Sun，D.，McCann，P.，Tschofenig，H.，Tsou，T.，Doria，A.，和G.Zorn，“直径服务质量应用”，RFC 5866，2010年5月。
[RFC5946] Le Faucheur, F., Manner, J., Narayanan, A., Guillou, A., and H. Malik, "Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy", RFC 5946, October 2010.
[RFC5946]Le Faucheur，F.，Way，J.，Narayanan，A.，Guillou，A.，和H.Malik，“路径触发RSVP接收器代理的资源预留协议（RSVP）扩展”，RFC 59462010年10月。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]Way，J.，Karagiannis，G.，和A.McDonald，“用于服务质量信令的NSIS信令层协议（NSLP）”，RFC 5974，2010年10月。
[RSVP-SEC-KEY] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, June 2009.
[RSVP-SEC-KEY]Behringer，M.和F.Le Faucheur，“RSVP安全的键控方法的适用性”，正在进行的工作，2009年6月。
[RTR-ALERT] Le Faucheur, F., "IP Router Alert Considerations and Usage", Work in Progress, October 2009.
[RTR-ALERT]Le Faucheur，F.，“IP路由器警报注意事项和使用”，正在进行的工作，2009年10月。
[W3C] "World Wide Web Consortium (W3C) - Web Services Architecture", <http://www.w3.org/TR/ws-arch/>.
[W3C]“万维网联盟（W3C）-Web服务体系结构”<http://www.w3.org/TR/ws-arch/>.
As broadband services for residential customers are becoming more and more prevalent, next-generation aggregation networks are being deployed in order to aggregate traffic from broadband users (whether attached via Digital Subscriber Line technology, aka DSL; Fiber To The Home/Curb, aka FTTx; Cable; or other broadband access technology). Video on Demand (VoD) services, which may be offered to broadband users, present significant capacity planning challenges for the aggregation network for a number of reasons. First, each VoD stream requires significant dedicated sustained bandwidth (typically 2-4 Mb/s in Standard Definition TV and 6-12 Mb/s in High Definition TV). Secondly, the VoD codec algorithms are very sensitive to packet loss. Finally, the load resulting from such services is very hard to predict (e.g., it can vary quite suddenly with blockbuster titles made available as well as with promotional offerings). As a result, transport of VoD streams on the aggregation network usually translate into a strong requirement for admission control. The admission control solution protects the quality of established VoD sessions by rejecting the additional excessive session attempts during unpredictable peaks, during link or node failures, or a combination of those factors.
随着针对住宅用户的宽带服务越来越普遍，正在部署下一代聚合网络，以聚合宽带用户的流量（无论是通过数字用户线技术（也称DSL）、光纤到家庭/路边（也称FTTx）、电缆或其他宽带接入技术连接）。可能向宽带用户提供的视频点播（VoD）服务对聚合网络的容量规划提出了重大挑战，原因有很多。首先，每个VoD流都需要大量的专用持续带宽（在标准清晰度电视中通常为2-4 Mb/s，在高清晰度电视中为6-12 Mb/s）。其次，视频点播编解码算法对丢包非常敏感。最后，此类服务产生的负载很难预测（例如，随着大片以及促销产品的推出，负载可能会突然发生变化）。因此，聚合网络上VoD流的传输通常转化为对接纳控制的强烈要求。接纳控制解决方案通过在不可预测的峰值期间、链路或节点故障期间或这些因素的组合期间拒绝额外的过度会话尝试来保护已建立的VoD会话的质量。
RSVP can be used in the aggregation network for admission control of the VoD sessions. However, since customer premises equipment such as Set Top Boxes (STBs) (which behave as the receiver for VoD streams) often do not support RSVP, the last IP hop in the aggregation network can behave as an RSVP Receiver Proxy. This way, RSVP can be used between VoD pumps and the last IP hop in the aggregation network to perform accurate admission control of VoD streams over the resources set aside for VoD in the aggregation network (typically a certain percentage of the bandwidth of any link). As VoD streams are unidirectional, a simple Path-Triggered RSVP Receiver Proxy (as described in Section 4.1) is all that is required in this use case.
RSVP可以在聚合网络中用于VoD会话的准入控制。然而，由于诸如机顶盒（机顶盒）（充当VoD流的接收器）之类的客户场所设备通常不支持RSVP，因此聚合网络中的最后一个IP跃点可以充当RSVP接收器代理。这样，可以在VoD泵和聚合网络中的最后一个IP跃点之间使用RSVP，以便对聚合网络中为VoD预留的资源（通常是任何链路带宽的某个百分比）上的VoD流执行准确的接纳控制。由于VoD流是单向的，所以在本用例中只需要一个简单的路径触发RSVP接收器代理（如第4.1节所述）。
Figure 14 illustrates operation of RSVP-based admission control of VoD sessions in an aggregation network involving RSVP support on the VoD pump (the senders) and the RSVP Receiver proxy on the last IP hop of the aggregation network. All the customer premises equipment remains RSVP-unaware.
图14说明了聚合网络中基于RSVP的VoD会话准入控制的操作，该聚合网络涉及VoD泵（发送方）上的RSVP支持和聚合网络最后一个IP跃点上的RSVP接收方代理。所有的客户场所设备仍不知道RSVP。
|-------------|
| VoD SRM |
| |
////////| |\\\\\\\\\\\\\\
/ |-------------| \
/ \
/ \
/ \
/ \
/ \
|****| *** *** *** |********| |-----| |---|
|VoD |---*r*---*r*---*r*---|RSVP |---|DSLAM|~~~~|STB|--TV
|Pump| *** *** *** |Receiver| |-----| |---|
|****| |Proxy |
|********|
|-------------|
| VoD SRM |
| |
////////| |\\\\\\\\\\\\\\
/ |-------------| \
/ \
/ \
/ \
/ \
/ \
|****| *** *** *** |********| |-----| |---|
|VoD |---*r*---*r*---*r*---|RSVP |---|DSLAM|~~~~|STB|--TV
|Pump| *** *** *** |Receiver| |-----| |---|
|****| |Proxy |
|********|
<---Aggregation Net----------->
<---Aggregation Net----------->
************************************************>
************************************************>
==============RSVP================>
==============RSVP================>
SRM Session Resource Manager
SRM会话资源管理器
*** |---|
*r* regular RSVP |STB| Set Top Box
*** router |---|
*** |---|
*r* regular RSVP |STB| Set Top Box
*** router |---|
***> VoD media flow
***> VoD media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
/\ VoD Application-level signaling (e.g., RTSP)
/\VoD应用级信令（如RTSP）
Figure 14: VoD Use Case with Receiver Proxy
图14：带有接收器代理的VoD用例
In the case where the VoD pumps are not RSVP-capable, an Application_Entity-Controlled Sender Proxy via the "RSVP over GRE" approach (as described in Section 4.5.1) can also be implemented on the VoD Controller or Session Resource Manager (SRM) devices typically involved in VoD deployments. Figure 15 illustrates operation of RSVP-based admission control of VoD sessions in an aggregation network involving such an Application_Entity-Controlled Source Proxy combined with an RSVP Receiver Proxy on the last IP hop of the aggregation network. All the customer premises equipment, as well as the VoD pumps, remain RSVP-unaware.
如果VoD泵不支持RSVP，也可以在VoD部署中通常涉及的VoD控制器或会话资源管理器（SRM）设备上通过“RSVP over GRE”方法（如第4.5.1节所述）实现应用程序实体控制的发送方代理。图15说明了聚合网络中VoD会话的基于RSVP的准入控制的操作，该聚合网络包括应用程序实体控制的源代理和聚合网络最后一个IP跃点上的RSVP接收器代理。所有客户场所的设备以及视频点播泵仍不知道RSVP。
|-------------|
////| VoD SRM |\\\\\\\\\\\
/ | | \
/ | + | \
/ | RSVP Sender | \
/ |Proxy Control| \
/ |-------------| \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
|----| |******| *** *** |********| |-----| |---|
| VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV
|Pump| |Sender| *** *** |Receiver| |-----| |---|
|----| |Proxy | |Proxy |
|******| |********|
|-------------|
////| VoD SRM |\\\\\\\\\\\
/ | | \
/ | + | \
/ | RSVP Sender | \
/ |Proxy Control| \
/ |-------------| \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
|----| |******| *** *** |********| |-----| |---|
| VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV
|Pump| |Sender| *** *** |Receiver| |-----| |---|
|----| |Proxy | |Proxy |
|******| |********|
<---Aggregation Net------------->
<---Aggregation Net------------->
************************************************>
************************************************>
=========RSVP==============>
=========RSVP==============>
SRM Systems Resource Manager
SRM系统资源管理器
*** |---|
*r* regular RSVP |STB| Set Top Box
*** router |---|
*** |---|
*r* regular RSVP |STB| Set Top Box
*** router |---|
***> VoD media flow
***> VoD media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
/ VoD Application-level signaling (e.g., RTSP)
/VoD应用级信令（如RTSP）
/=/ GRE-tunneled RSVP (Path messages)
/=/ GRE-tunneled RSVP (Path messages)
Figure 15: VoD Use Case with Receiver Proxy and SRM-Based Sender Proxy
图15：具有接收方代理和基于SRM的发送方代理的VoD用例
The RSVP proxy entities specified in this document play a significant role here since they allow immediate deployment of an RSVP-based admission control solution for VoD without requiring any upgrade to the huge installed base of non-RSVP-capable customer premises equipment. In one mode described above, they also avoid upgrade of non-RSVP-capable VoD pumps. In turn, this means that the benefits of
本文件中指定的RSVP代理实体在这里发挥着重要作用，因为它们允许立即部署基于RSVP的VoD准入控制解决方案，而无需升级到大量不支持RSVP的客户场所设备。在上述一种模式中，它们还避免升级不支持RSVP的VoD泵。反过来，这意味着
on-path admission control can be offered to VoD services over broadband aggregation networks without network or VoD pump upgrade. Those include accurate bandwidth accounting regardless of topology (hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic adjustment to any change in topology (such as failure, routing change, additional links, etc.).
无需网络升级或VoD泵升级，即可通过宽带聚合网络向VoD服务提供路径许可控制。这些包括准确的带宽计算，而不考虑拓扑（集线器和辐条、环形、网状、星形、任意组合），以及动态调整拓扑中的任何变化（如故障、路由变化、附加链路等）。
A.2. RSVP-Based Voice/Video Connection Admission Control (CAC) in Enterprise WAN
A.2. 企业广域网中基于RSVP的语音/视频连接许可控制（CAC）
More and more enterprises are migrating their telephony and videoconferencing applications onto IP. When doing so, there is a need for retaining admission control capabilities of existing TDM-based (Time-Division Multiplexing) systems to ensure the QoS of these applications is maintained even when transiting through the enterprise's Wide Area Network (WAN). Since many of the endpoints already deployed (such as IP phones or videoconferencing terminals) are not RSVP-capable, RSVP proxy approaches are very useful: they allow deployment of an RSVP-based admission control solution over the WAN without requiring upgrade of the existing terminals.
越来越多的企业正在将其电话和视频会议应用程序迁移到IP上。这样做时，需要保留现有基于TDM（时分多路复用）系统的准入控制能力，以确保即使在通过企业广域网（WAN）传输时也能保持这些应用程序的QoS。由于许多已经部署的端点（如IP电话或视频会议终端）不支持RSVP，RSVP代理方法非常有用：它们允许在WAN上部署基于RSVP的准入控制解决方案，而无需升级现有终端。
A common deployment architecture for such environments relies on the Application_Entity-Controlled Proxy approach as defined in Section 4.5. Routers sitting at the edges of the WAN are naturally "on-path" for all inter-campus calls (or sessions) and behave as RSVP proxies. The RSVP proxies establish, maintain, and tear down RSVP reservations over the WAN segment for the calls (or sessions) under the control of the SIP server/proxy. The SIP server/proxy synchronizes the RSVP reservation status with the status of end-to-end calls. For example, the called IP phone will only be instructed to play a ring tone if the RSVP reservation over the corresponding WAN segment has been successfully established.
此类环境的通用部署体系结构依赖于第4.5节中定义的应用程序实体控制代理方法。位于广域网边缘的路由器对于所有校园间呼叫（或会话）来说自然是“在路径上”，并充当RSVP代理。RSVP代理为SIP服务器/代理控制下的呼叫（或会话）在WAN段上建立、维护和撤销RSVP保留。SIP服务器/代理将RSVP保留状态与端到端呼叫状态同步。例如，仅当通过相应WAN段成功建立RSVP预约时，被叫IP电话才会被指示播放铃声。
This architecture allowing RSVP-based admission control of voice and video on the enterprise WAN is illustrated in Figure 16.
图16说明了这种允许在企业WAN上对语音和视频进行基于RSVP的准入控制的体系结构。
|---------|
//////////////| SIP |\\\\\\\\\\\\
/ | Server/ | \
/ | Proxy | \
/ |---------| \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
|-----| |********| *** *** |********| |-----|
| IP |------| Media |---*r*---*r*---| Media |-------|IP |
|Phone| | Relay | *** *** | Relay | |Phone|
|-----| | + | | + | |-----|
| RSVP | | RSVP |
| Proxy | | Proxy |
|********| |********|
|---------|
//////////////| SIP |\\\\\\\\\\\\
/ | Server/ | \
/ | Proxy | \
/ |---------| \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
|-----| |********| *** *** |********| |-----|
| IP |------| Media |---*r*---*r*---| Media |-------|IP |
|Phone| | Relay | *** *** | Relay | |Phone|
|-----| | + | | + | |-----|
| RSVP | | RSVP |
| Proxy | | Proxy |
|********| |********|
<--campus--> <--campus-->
network network
<--campus--> <--campus-->
network network
<---------WAN----------->
<---------WAN----------->
<*************> <***********************> <**************>
<*************> <***********************> <**************>
<=========RSVP===========>
<=========RSVP===========>
***
*r* Regular RSVP router
***
***
*r* Regular RSVP router
***
<***> media flow
<***> media flow
<==> segment of flow path protected by RSVP reservation
<==> segment of flow path protected by RSVP reservation
/\ SIP signaling
/\SIP信令
// control interface between the SIP server/proxy and RSVP proxy
//SIP服务器/代理和RSVP代理之间的控制接口
Figure 16: CAC on Enterprise WAN Use Case
图16：企业广域网CAC用例
Mobile access networks are increasingly based on IP technology. This implies that, on the network layer, all traffic, both traditional data and streamed data like audio or video, is transmitted as
移动接入网络越来越多地基于IP技术。这意味着，在网络层上，所有流量，包括传统数据和流式数据（如音频或视频）都以相同的方式传输
packets. Increasingly popular multimedia applications would benefit from better than best-effort service from the network, a forwarding service with strict Quality of Service (QoS) with guaranteed minimum bandwidth and bounded delay. Other applications, such as electronic commerce, network control and management, and remote-login applications, would also benefit from a differentiated treatment.
小包。越来越流行的多媒体应用将受益于网络提供的优于尽力而为的服务，这是一种具有严格服务质量（QoS）的转发服务，具有保证的最小带宽和有限延迟。其他应用程序，如电子商务、网络控制和管理以及远程登录应用程序，也将受益于区别对待。
The IETF has two main models for providing differentiated treatment of packets in routers. The Integrated Services (IntServ) model [RFC1633], together with the Resource Reservation Protocol (RSVP) [RFC2205], [RFC2210], [RFC2961] provides per-flow guaranteed end-to-end transmission service. The Differentiated Services (Diffserv) framework [RFC2475] provides non-signaled flow differentiation that usually provides, but does not guarantee, proper transmission service.
IETF有两个主要模型，用于对路由器中的数据包进行区分处理。集成服务（IntServ）模型[RFC1633]与资源预留协议（RSVP）[RFC2205]、[RFC2210]、[RFC2961]一起提供每流保证的端到端传输服务。区分服务（Diffserv）框架[RFC2475]提供无信号流区分，通常提供但不保证正确的传输服务。
However, these architectures have potential weaknesses for deployment in Mobile Access Networks. For example, RSVP requires support from both communication endpoints, and the protocol may have potential performance issues in mobile environments. Diffserv can only provide statistical guarantees and is not well suited for dynamic environments.
然而，这些体系结构对于在移动接入网络中部署具有潜在的弱点。例如，RSVP需要来自两个通信端点的支持，并且该协议在移动环境中可能存在潜在的性能问题。Diffserv只能提供统计保证，不适合动态环境。
Let us consider a scenario, where a fixed network correspondent node (CN) would be sending a multimedia stream to an end host behind a wireless link. If the correspondent node does not support RSVP, it cannot signal its traffic characteristics to the network and request specific forwarding services. Likewise, if the correspondent node is not able to mark its traffic with a proper Differentiated Services codepoint (DSCP) to trigger service differentiation, the multimedia stream will get only best-effort service, which may result in poor visual and audio quality in the receiving application. Even if the connecting wired network is over-provisioned, an end host would still benefit from local resource reservations, especially in wireless access networks, where the bottleneck resource is most probably the wireless link.
让我们考虑一种场景，其中固定网络通信节点（CN）将将多媒体流发送到无线链路后面的终端主机。如果对应节点不支持RSVP，则无法向网络发送其流量特性的信号，并请求特定的转发服务。类似地，如果对应节点不能用适当的区分服务码点（DSCP）标记其流量以触发服务区分，则多媒体流将仅获得尽力而为的服务，这可能导致接收应用中的视觉和音频质量差。即使连接的有线网络被过度配置，终端主机仍将受益于本地资源预留，特别是在无线接入网络中，其中瓶颈资源很可能是无线链路。
RSVP proxies would be a very beneficial solution to this problem. It would allow distinguishing local network reservations from the end-to-end reservations. The end host does not need to know the access network topology or the nodes that will reserve the local resources. The access network would do resource reservations for both incoming and outgoing flows based on certain criteria, e.g., filters based on application protocols. Another option is that the mobile end host makes an explicit reservation that identifies the intention, and the access network will find the correct local access network node(s) to respond to the reservation. RSVP proxies would, thus, allow resource reservation over the segment that is the most likely bottleneck, the
RSVP代理将是解决此问题的非常有益的解决方案。它将允许区分本地网络预订和端到端预订。终端主机不需要知道接入网络拓扑或将保留本地资源的节点。接入网络将根据某些标准（例如，基于应用协议的过滤器）为传入和传出流进行资源预留。另一种选择是，移动终端主机做出明确的保留，以识别意图，并且接入网络将找到正确的本地接入网络节点来响应该保留。因此，RSVP代理将允许在最有可能成为瓶颈的段上保留资源，即
wireless link. If the wireless access network uses a local mobility management mechanism, where the IP address of the mobile node does not change during handover, RSVP reservations would follow the mobile node movement.
无线连接。如果无线接入网络使用本地移动性管理机制，其中移动节点的IP地址在切换期间不改变，则RSVP保留将跟随移动节点的移动。
[RFC4923] discusses how resource reservation can be supported end-to-end in a nested VPN environment. At each VPN level, VPN routers behave as [RFC4301] security gateways between a plaintext domain and a ciphertext domain. To achieve end-to-end resource reservation, the VPN routers process RSVP signaling on the plaintext side, perform aggregation of plaintext reservations, and maintain the corresponding aggregate RSVP reservations on the ciphertext side. Each aggregate reservation is established on behalf of multiple encrypted end-to-end sessions sharing the same ingress and egress VPN routers. These aggregate reservations can be as specified in [RFC3175] or [RFC4860].
[RFC4923]讨论如何在嵌套VPN环境中端到端支持资源保留。在每个VPN级别，VPN路由器充当明文域和密文域之间的[RFC4301]安全网关。为了实现端到端资源预留，VPN路由器在明文侧处理RSVP信令，执行明文预留的聚合，并在密文侧维护相应的聚合RSVP预留。每个聚合保留代表共享相同入口和出口VPN路由器的多个加密端到端会话建立。这些合计保留可以如[RFC3175]或[RFC4860]中所述。
Section 3 of [RFC4923] discusses the necessary data flows within a VPN router to achieve the behavior described in the previous paragraph. Two mechanisms are described to achieve such data flows. Section 3.1 presents the case where the VPN router carries data across the cryptographic boundary. Section 3.2 discusses the case where the VPN router uses a Network Guard.
[RFC4923]的第3节讨论了VPN路由器内实现上一段所述行为所需的数据流。描述了实现这种数据流的两种机制。第3.1节介绍了VPN路由器跨加密边界传输数据的情况。第3.2节讨论VPN路由器使用网络防护的情况。
Where such mechanisms are not supported by the VPN routers, the approach for end-to-end reservations presented in [RFC4923] cannot be deployed. An alternative approach to support resource reservations within the ciphertext core is to use the Application_Entity-Controlled Proxy approach (as defined in Section 4.5) in the following way:
如果VPN路由器不支持此类机制，则无法部署[RFC4923]中介绍的端到端预留方法。支持密文核心内资源保留的另一种方法是以以下方式使用应用程序实体控制的代理方法（如第4.5节所定义）：
o the RSVP proxies are located inside the ciphertext domain and use aggregate RSVP reservations.
o RSVP代理位于密文域内，并使用聚合RSVP保留。
o the application entity exchange application-level signaling with the end-systems in the plaintext domain.
o 应用实体与明文域中的终端系统交换应用级信令。
o the application entity controls the RSVP proxies in the ciphertext domain via an RSVP proxy control interface.
o 应用实体通过RSVP代理控制接口控制密文域中的RSVP代理。
This is illustrated in Figure 17 in the case where the application is SIP-based multimedia communications.
在应用程序是基于SIP的多媒体通信的情况下，如图17所示。
|-------| |-------|
|SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP |
/|Server/| |Server/|\
/ |Proxy | |Proxy | \
/ |-------| |-------| \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
|***| |------| |********| *** *** |********| |------| |***|
| S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R |
|***| | GW | | Sender | *** *** |Receiver| | GW | |***|
|------| | Proxy | | Proxy | |------|
|********| |********|
|-------| |-------|
|SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP |
/|Server/| |Server/|\
/ |Proxy | |Proxy | \
/ |-------| |-------| \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
|***| |------| |********| *** *** |********| |------| |***|
| S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R |
|***| | GW | | Sender | *** *** |Receiver| | GW | |***|
|------| | Proxy | | Proxy | |------|
|********| |********|
***PT*****> **********************CT****************> ****PT***>
***PT*****> **********************CT****************> ****PT***>
=====> =====>
=====ARSVP======>
=====> =====>
=====ARSVP======>
|****| RSVP-capable |****| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |****| *** router
|****| RSVP-capable |****| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |****| *** router
|------|
|IPsec | IPsec security gateway
| GW |
|------|
|------|
|IPsec | IPsec security gateway
| GW |
|------|
ARSVP Aggregate RSVP
聚合RSVP
***> media flow
***> media flow
==> segment of flow path protected by RSVP reservation
==> segment of flow path protected by RSVP reservation
/ \ SIP signaling
/ \ SIP signaling
^ Network management interface between SIP server/proxy and IPsec security gateway
^SIP服务器/代理与IPsec安全网关之间的网络管理接口
// control interface between SIP server/proxy and ARSVP proxy
// control interface between SIP server/proxy and ARSVP proxy
PT Plaintext network
PT明文网络
CT Ciphertext network
密文网
Figure 17: RSVP Proxies for Reservations in the Presence of IPsec Gateways
图17:IPsec网关存在时保留的RSVP代理
Where the sender and receiver are RSVP-capable, they may also use RSVP signaling. This achieves resource reservation on the plaintext segments of the end-to-end, i.e.,
如果发送方和接收方具有RSVP能力，它们也可以使用RSVP信令。这在端到端的明文段上实现了资源保留，即。，
o from the sender to the ingress IPsec gateway, and
o 从发送方到入口IPsec网关，以及
o from the egress IPsec gateway to the receiver.
o 从出口IPsec网关到接收器。
In this use case, because the VPN routers do not support any RSVP-specific mechanism, the end-to-end RSVP signaling is effectively hidden by the IPsec gateways on the ciphertext segment of the end-to-end path.
在这种情况下，由于VPN路由器不支持任何特定于RSVP的机制，因此端到端RSVP信令被端到端路径的密文段上的IPsec网关有效隐藏。
As with the Application_Entity-Controlled Proxy approach (defined in Section 4.5), the solution here for synchronizing RSVP signaling with application-level signaling is to rely on an application-level signaling device that controls an on-path RSVP proxy function. However, in this use case, the RSVP proxies are a component of a ciphertext network where all user (bearer) traffic is IPsec encrypted. This has a number of implications, including the following:
与应用实体控制的代理方法（定义见第4.5节）一样，此处用于将RSVP信令与应用级信令同步的解决方案依赖于控制路径上RSVP代理功能的应用级信令设备。然而，在此用例中，RSVP代理是密文网络的一个组件，其中所有用户（承载）通信都是IPsec加密的。这有许多影响，包括：
1. encrypted flows cannot be identified in the ciphertext domain so that network nodes can only classify traffic based on IP address and Differentiated Services codepoints (DSCPs). As a result, only aggregate RSVP reservations (such as those specified in [RFC3175] or [RFC4860]) can be used. This is similar to [RFC4923].
1. 加密流无法在密文域中识别，因此网络节点只能根据IP地址和区分服务代码点（DSCP）对流量进行分类。因此，只能使用聚合RSVP保留（如[RFC3175]或[RFC4860]中指定的保留）。这类似于[RFC4923]。
2. Determining the RSVP Sender Proxy and RSVP Receiver Proxy to be used for aggregation of a given flow from sender to receiver creates a number of challenges. Details on how this may be achieved are beyond the scope of this document. We observe that, as illustrated in Figure 17, this may be facilitated by a network management interface between the application entity and the IPsec gateways. For example, this interface may be used by the application entity to obtain information about which IPsec gateway is on the path of a given end-to-end flow. Then, the application entity may maintain awareness of which RSVP proxy is on the ciphertext path between a given pair of IPsec gateways. How such awareness is achieved is beyond the scope of this document. We simply observe that such awareness can be easily achieved through simple configuration in the particular case where a single (physical or logical) RSVP proxy is fronting a given IPsec gateway. We also observe that when awareness of the RSVP Receiver Proxy for a particular egress IPsec gateway (or
2. 确定用于从发送方到接收方聚合给定流的RSVP发送方代理和RSVP接收方代理会带来许多挑战。关于如何实现这一点的详细信息超出了本文件的范围。我们注意到，如图17所示，应用程序实体和IPsec网关之间的网络管理接口可能有助于实现这一点。例如，应用实体可以使用该接口来获取关于给定端到端流路径上的IPsec网关的信息。然后，应用实体可以保持对给定的一对IPsec网关之间的密文路径上的哪个RSVP代理的感知。如何实现这种意识超出了本文件的范围。我们只是观察到，在单个（物理或逻辑）RSVP代理面对给定IPsec网关的特定情况下，通过简单的配置可以轻松实现这种感知。我们还观察到，当意识到特定出口IPsec网关（或
end-to-end flow) is not available, the aggregate reservation may be signaled by the RSVP Sender Proxy to the destination address of the egress IPsec gateway and then proxied by the RSVP Receiver Proxy.
端到端流）不可用，聚合保留可由RSVP发送方代理发送信号至出口IPsec网关的目标地址，然后由RSVP接收方代理发送。
Different flavors of operations are possible in terms of aggregate reservation sizing. For example, the application entity can initiate an aggregate reservation of fixed size a priori and then simply keep count of the bandwidth used by sessions and reject sessions that would result in excess usage of an aggregate reservation. The application entity could also re-size the aggregate reservations on a session-by-session basis. Alternatively, the application entity could re-size the aggregate reservations in step increments typically corresponding to the bandwidth requirement of multiple sessions.
就总预订规模而言，可能有不同风格的操作。例如，应用实体可以预先启动固定大小的聚合保留，然后简单地统计会话使用的带宽，并拒绝会导致聚合保留过度使用的会话。应用程序实体还可以逐个会话重新调整总保留的大小。或者，应用实体可以以通常对应于多个会话的带宽需求的步长增量重新调整聚合保留的大小。
Authors' Addresses
作者地址
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 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
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland
阿尔托大学通信与网络系（Comnet）邮政信箱13000 FIN-00076阿尔托芬兰
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States
Dan Wing Cisco Systems美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Allan Guillou SFR 40-42 Quai du Point du Jour Boulogne-Billancourt 92659 France
Allan Guillou SFR 40-42法国布洛涅比兰古码头92659
EMail: allan.guillou@sfr.com
EMail: allan.guillou@sfr.com