Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 5946 Cisco
Updates: 2205 J. Manner
Category: Standards Track Aalto University
ISSN: 2070-1721 A. Narayanan
Cisco
A. Guillou
SFR
H. Malik
Airtel
October 2010
Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 5946 Cisco
Updates: 2205 J. Manner
Category: Standards Track Aalto University
ISSN: 2070-1721 A. Narayanan
Cisco
A. Guillou
SFR
H. Malik
Airtel
October 2010
Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy
路径触发RSVP接收器代理的资源保留协议（RSVP）扩展
Abstract
摘要
Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to-end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions.
资源预留协议（RSVP）信令可用于在IP网络中进行端到端资源预留，以保证特定流所需的服务质量（QoS）。对于传统的RSVP，给定流的数据发送方和接收方都参与RSVP信令。然而，在许多用例中，需要保留资源，但接收方、发送方或两者都不支持RSVP。在接收机不支持RSVP的情况下，RSVP路由器可以充当RSVP接收机代理，从而代表接收机执行RSVP信令。这允许在从发送方到RSVP接收方代理的端到端路径段上建立资源保留。然而，如配套文件“RSVP代理方法”中所述，需要RSVP扩展来促进RSVP接收器代理的操作，其信令是通过从发送方接收RSVP路径消息触发的。本文档指定了这些扩展。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5946.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5946.
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 ....................................................4
1.1. Conventions Used in This Document ..........................7
2. Terminology .....................................................7
3. RSVP Extensions for Sender Notification .........................8
3.1. Sender Notification via PathErr Message ...................11
3.1.1. Composition of SESSION and Sender Descriptor .......14
3.1.2. Composition of ERROR_SPEC ..........................14
3.1.3. Use of Path_State_Removed Flag .....................15
3.1.4. Use of PathErr by Regular Receivers ................16
3.2. Sender Notification via Notify Message ....................17
4. Mechanisms for Maximizing the Reservation Span .................23
4.1. Dynamic Discovery of Downstream RSVP Functionality ........24
4.2. Receiver Proxy Control Policy Element .....................26
4.2.1. Default Handling ...................................29
5. Security Considerations ........................................29
5.1. Security Considerations for the Sender
Notification via Notify Message ...........................30
5.2. Security Considerations for the Receiver Proxy
Control Policy Element ....................................31
6. IANA Considerations ............................................32
6.1. RSVP Error Codes ..........................................32
6.2. Policy Element ............................................32
7. Acknowledgments ................................................33
8. References .....................................................33
8.1. Normative References ......................................33
8.2. Informative References ....................................34
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................7
2. Terminology .....................................................7
3. RSVP Extensions for Sender Notification .........................8
3.1. Sender Notification via PathErr Message ...................11
3.1.1. Composition of SESSION and Sender Descriptor .......14
3.1.2. Composition of ERROR_SPEC ..........................14
3.1.3. Use of Path_State_Removed Flag .....................15
3.1.4. Use of PathErr by Regular Receivers ................16
3.2. Sender Notification via Notify Message ....................17
4. Mechanisms for Maximizing the Reservation Span .................23
4.1. Dynamic Discovery of Downstream RSVP Functionality ........24
4.2. Receiver Proxy Control Policy Element .....................26
4.2.1. Default Handling ...................................29
5. Security Considerations ........................................29
5.1. Security Considerations for the Sender
Notification via Notify Message ...........................30
5.2. Security Considerations for the Receiver Proxy
Control Policy Element ....................................31
6. IANA Considerations ............................................32
6.1. RSVP Error Codes ..........................................32
6.2. Policy Element ............................................32
7. Acknowledgments ................................................33
8. References .....................................................33
8.1. Normative References ......................................33
8.2. Informative References ....................................34
Guaranteed Quality of Service (QoS) for some applications with tight QoS requirements 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, but it assumes that both the sender and the receiver of the data flow support RSVP. However, there are environments where it would be useful to be able to reserve resources for a flow (at least a subset of the flow path) even when the sender or the receiver (or both) is not RSVP-capable.
对于某些具有严格QoS要求的应用程序，可以通过在端到端路径上的每个节点中保留资源来实现有保证的服务质量（QoS）。这些资源预留的主要IETF协议是[RFC2205]中规定的资源预留协议（RSVP）。RSVP不要求所有中间节点都支持RSVP，但它假定数据流的发送方和接收方都支持RSVP。然而，在某些环境中，即使发送方或接收方（或两者）不支持RSVP，也可以为流（至少流路径的子集）保留资源。
Since both the data sender and receiver may be unaware of RSVP, there are two types of RSVP Proxies. In the first case, an entity in the network needs to invoke RSVP on behalf of the data sender and thus generate RSVP Path messages, and eventually receive, process, and sink Resv messages. We refer to this entity as the RSVP Sender Proxy. In the second case, an entity in the network needs to operate RSVP on behalf of the receiver and thus receive Path messages sent by a data sender (or by an RSVP Sender Proxy), and reply to those with Resv messages generated on behalf of the data receiver(s). We refer to this entity as the RSVP Receiver Proxy.
由于数据发送方和接收方都可能不知道RSVP，因此有两种类型的RSVP代理。在第一种情况下，网络中的实体需要代表数据发送方调用RSVP，从而生成RSVP路径消息，并最终接收、处理和接收Resv消息。我们将此实体称为RSVP发送方代理。在第二种情况下，网络中的实体需要代表接收方操作RSVP，从而接收数据发送方（或RSVP发送方代理）发送的路径消息，并使用代表数据接收方生成的Resv消息回复这些消息。我们将此实体称为RSVP接收方代理。
RSVP Proxy approaches are presented in [RFC5945]. That document also discusses, for each approach, how the reservations controlled by the RSVP Proxy can be synchronized with the application requirements (e.g., when to establish, maintain, and tear down the RSVP reservation to satisfy application requirements).
[RFC5945]中介绍了RSVP代理方法。对于每种方法，该文件还讨论了RSVP代理控制的保留如何与应用程序需求同步（例如，何时建立、维护和撤销RSVP保留以满足应用程序需求）。
One RSVP Proxy approach is referred to as the Path-Triggered RSVP Receiver Proxy approach. With this approach, the RSVP Receiver Proxy uses the RSVP Path messages generated by the sender (or RSVP Sender Proxy) as the cue for establishing the RSVP reservation on behalf of the non-RSVP-capable receiver(s). The RSVP Receiver Proxy is effectively acting as an intermediary making reservations (on behalf of the receiver) under the sender's control (or RSVP Sender Proxy's control). This somewhat changes 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 (or RSVP Sender Proxy).
一种RSVP代理方法称为路径触发RSVP接收器代理方法。通过这种方法，RSVP接收方代理使用发送方（或RSVP发送方代理）生成的RSVP路径消息作为代表不支持RSVP的接收方建立RSVP保留的提示。RSVP接收方代理实际上是在发送方（或RSVP发送方代理）的控制下（代表接收方）进行保留的中间人。这在一定程度上改变了通常的RSVP保留模型，其中保留通常由接收者控制。这样的改变极大地促进了这里所关注的场景中的操作，即接收机不支持RSVP的场景。实际上，它允许RSVP接收方代理通过利用发送方（或RSVP发送方代理）的应用程序感知和RSVP感知保持应用程序不知道。
Since the synchronization between an RSVP reservation and an application is now effectively performed by the sender (or RSVP Sender Proxy), it is important that the sender (or RSVP Sender Proxy)
由于RSVP保留和应用程序之间的同步现在由发送方（或RSVP发送方代理）有效执行，因此发送方（或RSVP发送方代理）必须
is aware of the reservation state. However, as conventional RSVP assumes that the reservation is to be controlled by the receiver, some notifications about reservation state (notably the error message sent in the case of admission control rejection of the reservation) are only sent towards the receiver and therefore, in our case, sunk by the RSVP Receiver Proxy. Section 3 of this document specifies extensions to RSVP procedures allowing such notifications to be also conveyed towards the sender. This facilitates synchronization by the sender (or RSVP Sender Proxy) between the RSVP reservation and the application requirements, and it facilitates sender-driven control of reservation in scenarios involving a Path-Triggered RSVP Receiver Proxy.
知道保留状态。然而，由于传统的RSVP假设保留将由接收器控制，因此关于保留状态的一些通知（特别是在允许控制拒绝保留的情况下发送的错误消息）仅向接收器发送，因此，在我们的情况下，RSVP接收器代理接收。本文件第3节规定了RSVP程序的扩展，允许此类通知也传达给发送方。这有助于发送方（或RSVP发送方代理）在RSVP保留和应用程序需求之间进行同步，并有助于在涉及路径触发的RSVP接收方代理的场景中由发送方驱动的保留控制。
With unicast applications in the presence of RSVP Receiver Proxies, if the sender is notified about the state of the reservation towards the receiver (as enabled by this document), the sender is generally in a good position to synchronize the reservation with the application and to perform efficient sender-driven reservation: the sender can control the establishment or removal of the reservation towards the receiver by sending Path or PathTear messages, respectively. For example, if the sender is notified that the reservation for a point-to-point audio session towards the receiver is rejected, the sender may trigger rejection of the session at the application layer and may issue a PathTear message to remove any corresponding RSVP state (e.g., Path states) previously established.
对于存在RSVP接收器代理的单播应用程序，如果发送方被告知对接收器的保留状态（如本文档所启用），发送方通常能够将保留与应用程序同步，并执行有效的发送方驱动的保留：发送方可以通过分别发送Path或PATHTRAL消息来控制对接收方保留的建立或删除。例如，如果发送方被通知拒绝对接收器的点对点音频会话的保留，则发送方可在应用层触发对会话的拒绝，并可发出pathtreal消息以移除先前建立的任何对应RSVP状态（例如，路径状态）。
However, we note that multicast applications do not always coexist well with RSVP Receiver Proxies, since sender notification about reservation state towards each RSVP Receiver Proxy may not be sufficient to achieve tight application-level synchronization by multicast senders. These limitations stem from the fact that multicast operation is receiver driven and, while end-to-end RSVP is also receiver driven (precisely to deal with multicast efficiently), the use of RSVP Receiver Proxies only allows sender-driven reservation. For example, a sender generally is not aware of which receivers have joined downstream of a given RSVP Receiver Proxy, or even which RSVP Receiver Proxies have joined downstream of a given failure point. Therefore, it may not be possible to support a mode of operation whereby a given receiver only joins a group if that receiver benefits from a reservation. Additionally, a sender may have no recourse if only a subset of RSVP Receiver Proxies return successful reservations (even if application-level signaling runs between the sender and receivers), since the sender may not be able to correctly identify the set of receivers who do not have reservations. However, it is possible to support a mode of operation whereby multicast traffic is transmitted if and only if all receivers benefit from a reservation (from sender to their respective RSVP Receiver Proxy): the sender can ensure this by sending a PathTear
然而，我们注意到，多播应用程序并不总是与RSVP接收方代理很好地共存，因为发送方向每个RSVP接收方代理发出的关于保留状态的通知可能不足以通过多播发送方实现紧密的应用程序级同步。这些限制源于这样一个事实，即多播操作是接收器驱动的，而端到端RSVP也是接收器驱动的（准确地说是为了有效地处理多播），使用RSVP接收器代理只允许发送者驱动的保留。例如，发送方通常不知道哪些接收方已加入给定RSVP接收方代理的下游，甚至不知道哪些RSVP接收方代理已加入给定故障点的下游。因此，可能不可能支持这样一种操作模式，即给定接收方仅在其受益于保留的情况下加入组。此外，如果只有RSVP接收器代理的子集返回成功的保留（即使在发送方和接收方之间运行应用级信令），则发送方可能没有追索权，因为发送方可能无法正确识别没有保留的接收器集。但是，可以支持这样一种操作模式，即当且仅当所有接收器都从保留中受益（从发送方到各自的RSVP接收器代理）时，才会传输多播通信量：发送方可以通过发送路径来确保这一点
message and stopping transmission whenever it gets a notification for reservation reject for one or more RSVP Receiver Proxies. It is also possible to support a mode of operation whereby receivers join independently of whether or not they can benefit from a reservation (to their respective RSVP Receiver Proxy), but do benefit from a reservation whenever the corresponding resources are reservable on the relevant path.
消息，并在收到一个或多个RSVP接收器代理的保留拒绝通知时停止传输。还可以支持这样一种操作模式，即接收机独立于它们是否能够从保留中受益（到它们各自的RSVP接收机代理）而加入，但是只要相应的资源在相关路径上是可保留的，就确实能够从保留中受益。
This document discusses extensions to facilitate operations in the presence of a Path-Triggered RSVP Receiver Proxy. As pointed out previously, those apply equally whether RSVP signaling is initiated by a regular RSVP sender or by an RSVP Sender Proxy (with some means to synchronize reservation state with application-level requirements that are outside the scope of this document). For readability, the rest of this document discusses operations assuming a regular RSVP sender; however, such an operation is equally applicable where an RSVP Sender Proxy is used to initiated RSVP signaling on behalf of a non-RSVP-capable sender.
本文档讨论了在存在路径触发RSVP接收器代理的情况下方便操作的扩展。如前所述，无论RSVP信令是由常规RSVP发送方还是由RSVP发送方代理发起（通过某种方式将保留状态与本文档范围之外的应用程序级要求同步），这些都同样适用。为了便于阅读，本文档的其余部分讨论了假定常规RSVP发送方的操作；然而，当RSVP发送方代理用于代表不支持RSVP的发送方发起RSVP信令时，这样的操作同样适用。
As discussed in [RFC5945], 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. Thus, the purpose of this document 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.
正如[RFC5945]中所讨论的，重要的是要记住，强烈推荐的RSVP部署模型仍然是[RFC2205]中假设的端到端，发送方和接收方都支持RSVP。端到端模型允许在预订和应用程序需求之间进行最有效的同步。此外，与端到端RSVP模型相比，RSVP代理的使用涉及额外的操作负担和/或施加一些拓扑约束。因此，本文档的目的只是为了允许在特殊环境中部署RSVP，因为特定环境的原因，RSVP无法在某些发送方和/或某些接收方上使用。
Section 4.1.1 of [RFC5945] discusses mechanisms allowing the RSVP reservation for a given flow to be dynamically extended downstream of an RSVP Proxy whenever possible (i.e., when the receiver is RSVP-capable or when there is another RSVP Receiver Proxy downstream). This can considerably alleviate the operational burden and the topological constraints associated with Path-Triggered RSVP Receiver Proxies. This allows (without corresponding manual configuration) an RSVP reservation to dynamically span as much of the corresponding flow path as possible, with any arbitrary number of RSVP Receiver Proxies on the flow path and whether or not the receiver is RSVP-capable. In turn, this facilitates migration from an RSVP deployment model based on Path-Triggered Receiver Proxies to an end-to-end RSVP model, since receivers can gradually and independently be upgraded to support RSVP and then instantaneously benefit from end-to-end reservations. Section 4 of this document specifies these mechanisms and associated RSVP extensions.
[RFC5945]第4.1.1节讨论了允许给定流的RSVP保留在RSVP代理的下游尽可能动态扩展的机制（即，当接收器具有RSVP能力或下游有另一个RSVP接收器代理时）。这可以大大减轻与路径触发RSVP接收器代理相关的操作负担和拓扑约束。这允许（没有相应的手动配置）RSVP保留动态地跨越尽可能多的相应流路径，流路径上有任意数量的RSVP接收器代理，无论接收器是否具有RSVP能力。反过来，这有助于从基于路径触发的接收器代理的RSVP部署模型迁移到端到端RSVP模型，因为接收器可以逐渐独立升级以支持RSVP，然后立即从端到端保留中获益。本文件第4节规定了这些机制和相关的RSVP扩展。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following terminology is borrowed from [RFC5945] and is used extensively in this document:
以下术语借用自[RFC5945]，并在本文件中广泛使用：
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 normally would 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 nor as an RSVP Sender Proxy.
o 常规RSVP路由器：支持RSVP的路由器，既不作为RSVP接收方代理，也不作为RSVP发送方代理。
Note that the roles of the RSVP Receiver Proxy, RSVP Sender Proxy, and regular RSVP Router are all relative to one 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路由器。
The following terminology is also used in this document:
本文件中还使用了以下术语：
o Regular RSVP sender: an RSVP-capable host behaving as the sender for the considered flow and participating in RSVP signaling in accordance with the sender behavior specified in [RFC2205].
o 常规RSVP发送方：具有RSVP功能的主机，作为所考虑的流的发送方，并根据[RFC2205]中规定的发送方行为参与RSVP信令。
o Regular RSVP receiver: an RSVP-capable host behaving as the receiver for the considered flow and participating in RSVP signaling in accordance with the receiver behavior specified in [RFC2205].
o 常规RSVP接收器：具有RSVP功能的主机，作为所考虑流的接收器，并根据[RFC2205]中规定的接收器行为参与RSVP信令。
This section defines extensions to RSVP procedures allowing sender notification of reservation failure. This facilitates synchronization by the sender between RSVP reservation and application requirements in scenarios involving a Path-Triggered RSVP Receiver Proxy.
本节定义了RSVP过程的扩展，允许发送方通知保留失败。在涉及路径触发的RSVP接收方代理的场景中，这有助于发送方在RSVP保留和应用程序需求之间进行同步。
As discussed in [RFC5945], 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. On receipt of the RSVP Path message, the RSVP Receiver Proxy:
如[RFC5945]中所述，通过路径触发的RSVP接收器代理方法，RSVP路由器可配置为使用常规RSVP路径消息的接收作为RSVP接收器代理行为的触发器。收到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 corresponding Resv message (on its way upstream from the receiver) was received on the downstream interface. This includes performing admission control on the downstream interface, establishing a Resv state (in the case of successful admission 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.
4. 其行为就像在下游接口上接收到相应的Resv消息（从接收器上行）。这包括在下游接口上执行接纳控制、建立Resv状态（在接纳控制成功的情况下）、向上游转发Resv消息、发送Resv消息的定期刷新以及在路径状态被撤销时撤销保留。
Operation of the Path-Triggered Receiver Proxy in the case of a successful reservation is illustrated in Figure 1.
图1说明了成功预订情况下路径触发的接收方代理的操作。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path---> --Path---> --Path---> --Path--->
--Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv-- <---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 benefiting from an RSVP reservation
==> segment of flow path benefiting from an RSVP reservation
Figure 1: Successful Reservation
图1：成功预订
We observe that, in the case of successful reservation, conventional RSVP procedures ensure that the sender is notified of the successful reservation establishment. Thus, no extensions are required in the presence of a Path-Triggered RSVP Receiver Proxy in the case of successful reservation establishment.
我们注意到，在成功预订的情况下，传统的RSVP程序确保发送人收到成功预订建立的通知。因此，在成功建立预约的情况下，在存在路径触发的RSVP接收器代理的情况下不需要扩展。
However, in the case of reservation failure, conventional RSVP procedures ensure only that the receiver (or the RSVP Receiver Proxy) is notified of the reservation failure. Specifically, in the case of an admission control rejection on a regular RSVP router, a ResvErr message is sent downstream towards the receiver. In the presence of an RSVP Receiver Proxy, if we simply follow conventional RSVP procedures, this means that the RSVP Receiver Proxy is notified of the reservation failure, but the sender is not. Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, assuming conventional RSVP procedures, is illustrated in Figure 2.
然而，在预订失败的情况下，传统的RSVP程序仅确保接收方（或RSVP接收方代理）收到预订失败的通知。具体地说，在常规RSVP路由器上的接纳控制拒绝的情况下，ResvErr消息向下游发送到接收机。在存在RSVP接收方代理的情况下，如果我们只是遵循传统的RSVP过程，这意味着RSVP接收方代理会收到预订失败的通知，但发送方不会。假设传统的RSVP程序，在准入控制失败的情况下，路径触发的RSVP接收器代理的操作如图2所示。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path---> --Path---> --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 benefiting from an RSVP reservation
==> segment of flow path benefiting from an RSVP reservation
Figure 2: Reservation Failure with Conventional RSVP
图2：使用传统RSVP的预订失败
While the sender could infer reservation failure from the fact that it has not received a Resv message after a certain time, there are clear benefits to ensuring that the sender gets a prompt, explicit notification in the case of reservation failure. This includes faster end-user notification at the application layer (e.g., busy signal) and faster application-level reaction (e.g., application-level rerouting), as well as faster release of application-level resources.
虽然发送方可以从一段时间后未收到Resv消息这一事实推断出保留失败，但确保发送方在保留失败的情况下得到及时、明确的通知显然有好处。这包括在应用层更快的最终用户通知（例如，忙信号）和更快的应用层反应（例如，应用层重新路由），以及更快的应用层资源释放。
Section 3.1 defines a method that can be used to achieve sender notification of reservation failure. A router implementation claiming compliance with this document MUST support the method defined in Section 3.1.
第3.1节定义了一种可用于实现发送方预订失败通知的方法。声称符合本文件的路由器实现必须支持第3.1节中定义的方法。
Section 3.2 defines another method that can be used to achieve sender notification of reservation failure. A router implementation claiming compliance with this document MAY support the method defined in Section 3.2.
第3.2节定义了另一种方法，可用于实现预订失败的发送方通知。声称符合本文件要求的路由器实现可能支持第3.2节中定义的方法。
In a given network environment, a network administrator may elect to use the method defined in Section 3.1, the method defined in Section 3.2, or possibly combine the two.
在给定的网络环境中，网络管理员可以选择使用第3.1节中定义的方法、第3.2节中定义的方法，或者可能将两者结合使用。
With this method, the RSVP Receiver Proxy MUST generate a PathErr message whenever the two following conditions are met:
使用此方法，只要满足以下两个条件，RSVP接收器代理就必须生成PathErr消息：
1. The reservation establishment has failed (or the previously established reservation has been torn down).
1. 预订建立失败（或先前建立的预订已被拆除）。
2. The RSVP Receiver Proxy determines that it cannot re-establish the reservation (e.g., by adapting its reservation request in reaction to the error code provided in the received ResvErr in accordance with local policy).
2. RSVP接收方代理确定其无法重新建立保留（例如，通过根据本地策略调整其保留请求以响应接收到的ResvErr中提供的错误代码）。
Note that this notion of generating a PathErr message upstream in order to notify the sender about a reservation failure is not completely new. It is borrowed from [RFC3209] where it was introduced in order to satisfy a similar requirement, which is to allow an MPLS Traffic Engineering (TE) Label Switching Router to notify the TE Tunnel head-end (i.e., the sender) of a failure to establish (or maintain) a TE Tunnel Label Switch Path.
请注意，这种在上游生成PathErr消息以通知发送方保留失败的概念并不完全是新的。它是从[RFC3209]借用而来的，在[RFC3209]中引入它是为了满足类似的要求，即允许MPLS流量工程（TE）标签交换路由器通知TE隧道头端（即发送方）建立（或维护）TE隧道标签交换路径失败。
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, using sender notification via a PathErr message, is illustrated in Figure 3.
在准入控制失败的情况下，通过PathErr消息使用发送方通知，路径触发的RSVP接收方代理的操作如图3所示。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path---> --Path---> --Path---> --Path--->
--Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv--
<---Resv-- <---Resv--
-ResvErr-> -ResvErr->
-ResvErr-> -ResvErr->
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================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 benefiting from RSVP (but not benefiting from a reservation in this case)
==>受益于RSVP的流路段（但在这种情况下不受益于保留）
Figure 3: Reservation Failure with Sender Notification via PathErr
图3：通过PathErr发送通知的预订失败
The role of this PathErr is to notify the sender that the reservation was not established or was torn down. This may be in the case of receipt of a ResvErr, or because of local failure on the Receiver Proxy. On receipt of a ResvErr, in all situations where the reservation cannot be installed, the Receiver Proxy MUST generate a PathErr towards the sender. For local failures on the Receiver Proxy node, if a similar failure on an RSVP midpoint would cause the generation of a ResvErr (for example, admission control failure), the Receiver Proxy MUST generate a PathErr towards the sender. The Receiver Proxy MAY additionally generate a PathErr upon local failures that would not ordinarily cause generation of a ResvErr message, such as those described in Appendix B of [RFC2205].
此PathErr的作用是通知发件人保留未建立或已取消。这可能是在收到ResvErr的情况下，或者是由于接收方代理上的本地故障。在收到ResvErr后，在无法安装保留的所有情况下，接收方代理必须生成指向发送方的PathErr。对于接收方代理节点上的本地故障，如果RSVP中点上的类似故障将导致生成ResvErr（例如，准入控制故障），则接收方代理必须生成指向发送方的PathErr。接收方代理还可以在通常不会导致生成ResvErr消息的本地故障时生成PathErr，如[RFC2205]附录B中所述。
The PathErr generated by the Receiver Proxy corresponds to the sender(s) that triggered generation of Resv messages that failed. For FF-style (Fixed-Filter) reservations, the Receiver Proxy MUST send a PathErr towards the (single) sender matching the failed reservation. For SE-style (Shared-Explicit) reservations, the
接收方代理生成的路径错误对应于触发生成失败的Resv消息的发送方。对于FF样式（固定筛选器）保留，接收方代理必须向匹配失败保留的（单个）发送方发送路径错误。对于SE样式（共享显式）保留
Receiver Proxy MUST send the PathErr(s) towards the set of senders that triggered reservations that failed. This may be a subset of senders sharing the same reservation, in which case the remaining senders would have their reservation intact and would not receive a PathErr. In both cases, the rules described in Section 3.1.8 of [RFC2205] for generating flow descriptors in ResvErr messages also apply when generating sender descriptors in PathErr messages.
接收方代理必须向触发保留失败的发送方集发送路径错误。这可能是共享相同保留的发件人的子集，在这种情况下，其余发件人的保留将保持不变，不会收到PathErr。在这两种情况下，[RFC2205]第3.1.8节中描述的用于在ResvErr消息中生成流描述符的规则在PathErr消息中生成发送方描述符时也适用。
For WF-style (Wildcard-Filter) reservations, it is not always possible for the Receiver Proxy to reliably know which sender caused the reservation failure. Therefore, the Receiver Proxy SHOULD send a PathErr towards each sender. This means that all the senders will receive a notification that the reservation is not established, including senders that did not cause the reservation failure. Therefore, the method of sender notification via a PathErr message is somewhat overly conservative (i.e., in some cases, rejecting reservations from some senders when those could have actually been established) when used in combination with the Wildcard-Filter style (and when there is more than one sender).
对于WF样式（通配符筛选器）保留，接收方代理并不总是能够可靠地知道是哪个发送方导致了保留失败。因此，接收方代理应该向每个发送方发送一个PathErr。这意味着所有发送方都将收到一个未建立预订的通知，包括未导致预订失败的发送方。因此，当与通配符过滤器样式结合使用时（以及当存在多个发送者时），通过PathErr消息通知发送者的方法有点过于保守（即，在某些情况下，拒绝来自某些发送者的保留，如果这些保留实际上已经建立）。
The sender notification via the PathErr method applies to both unicast and multicast sessions. However, for a multicast session, it is possible that reservation failure (e.g., admission control failure) in a node close to a sender may cause ResvErr messages to be sent to a large group of Receiver Proxies. These Receiver Proxies would, in turn, all send PathErr messages back to the same sender, which could cause a scalability issue in some environments.
通过PathErr方法发出的发送方通知同时适用于单播和多播会话。然而，对于多播会话，靠近发送方的节点中的保留失败（例如，接纳控制失败）可能导致将ResvErr消息发送到大量接收方代理。反过来，这些接收方代理都会将PathErr消息发送回同一发送方，这在某些环境中可能会导致可伸缩性问题。
From the perspective of the sender, errors that prevent a reservation from being set up can be classified in two ways:
从发件人的角度来看，阻止设置预订的错误可分为两类：
1. Errors that the sender can attempt to correct. The error code for these errors should explicitly be communicated back to the sender. An example of this is "Code 1: Admission Control Failure", because the sender could potentially resend a Path message with smaller traffic parameters.
1. 发件人可以尝试更正的错误。这些错误的错误代码应该明确地传回发送方。这方面的一个例子是“代码1：准入控制失败”，因为发送方可能会使用较小的流量参数重新发送路径消息。
2. Errors over which the sender has no control. For these errors, it is sufficient to notify the sender that the reservation was not set up successfully. An example of this is "Code 13: Unknown Object", because the sender has no control over the objects inserted into the reservation by the Receiver Proxy.
2. 发件人无法控制的错误。对于这些错误，通知发件人预订未成功设置就足够了。例如“代码13：未知对象”，因为发送方无法控制接收方代理插入保留中的对象。
The PathErr message generated by the Receiver Proxy has the same format as regular PathErr messages defined in [RFC2205]. The SESSION, ERROR_SPEC, and sender descriptor are composed by the
接收方代理生成的PathErr消息的格式与[RFC2205]中定义的常规PathErr消息的格式相同。会话、错误规范和发送方描述符由
Receiver Proxy as specified in the following subsections. The Receiver Proxy MAY reflect back towards the sender in the PathErr any POLICY_DATA objects received in the ResvErr.
以下小节中规定的接收方代理。接收方代理可以向PathErr中的发送方反射在ResvErr中接收到的任何策略数据对象。
The Receiver Proxy MUST insert the SESSION object corresponding to the failed reservation into the PathErr. For FF-style reservations, the Receiver Proxy MUST insert a sender descriptor corresponding to the failed reservation into the PathErr. This is equal to the error flow descriptor in the ResvErr received by the Receiver Proxy. For SE-style reservations, the Receiver Proxy MUST insert a sender descriptor corresponding to the sender triggering the failed reservation into the PathErr. This is equal to the error flow descriptor in the ResvErr received by the Receiver Proxy. If multiple flow descriptors could not be admitted at a midpoint node, that node would generate multiple ResvErr messages towards the receiver as per Section 3.1.8 of [RFC2205]. Each ResvErr would contain an error flow descriptor that matches a specific sender. The Receiver Proxy MUST generate a PathErr for each ResvErr received towards the corresponding sender. As specified earlier, for WF-style reservations, the Receiver Proxy SHOULD send a PathErr to each sender.
接收方代理必须将与失败保留相对应的会话对象插入PathErr。对于FF样式的保留，接收方代理必须将与失败的保留相对应的发送方描述符插入PathErr。这等于接收方代理接收的ResvErr中的错误流描述符。对于SE样式的保留，接收方代理必须将与触发失败保留的发送方对应的发送方描述符插入PathErr。这等于接收方代理接收的ResvErr中的错误流描述符。如果一个中点节点不能接纳多个流描述符，则该节点将根据[RFC2205]第3.1.8节的规定，向接收方生成多个ResvErr消息。每个ResvErr将包含一个与特定发送方匹配的错误流描述符。接收方代理必须为向相应的发送方接收的每个ResvErr生成一个PathErr。如前所述，对于WF样式的保留，接收方代理应该向每个发送方发送一个PathErr。
The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into the PathErr as follows:
接收方代理必须按如下方式组成要插入到PathErr中的错误规范：
1. If the Receiver Proxy receives a ResvErr with either of these error codes -- "Code 1: Admission Control Failure" or "Code 2: Policy Control Failure" -- then the Receiver Proxy copies the error code and value from the ERROR_SPEC in the ResvErr into the ERROR_SPEC of the PathErr message. The error node in the PathErr MUST be set to the address of the Receiver Proxy. This procedure MUST also be followed for a local error on the Receiver Proxy that would ordinarily cause a midpoint to generate a ResvErr with one of the above codes.
1. 如果接收方代理接收到带有以下错误代码之一的ResvErr——“代码1：许可控制失败”或“代码2：策略控制失败”——则接收方代理会将错误代码和值从ResvErr中的error_SPEC复制到PathErr消息的error_SPEC中。PathErr中的错误节点必须设置为接收方代理的地址。对于接收器代理上的本地错误，也必须遵循此过程，该错误通常会导致中点使用上述代码之一生成ResvErr。
2. If the Receiver Proxy receives a ResvErr with any error code except the ones listed in item 1 above, it composes a new ERROR_SPEC with error code "36: Unrecoverable Receiver Proxy Error". The error node address in the PathErr MUST be set to the address of the Receiver Proxy. This procedure MUST also be followed for a local error on the Receiver Proxy that would ordinarily cause a midpoint to generate a ResvErr with any error code other than those listed in item 1 above, or if the Receiver Proxy generates a PathErr for a local error that ordinarily would
2. 如果接收方代理接收到带有任何错误代码（上述第1项中列出的错误代码除外）的ResvErr，它将构成一个新的错误规范，错误代码为“36：不可恢复的接收方代理错误”。PathErr中的错误节点地址必须设置为接收方代理的地址。对于接收器代理上的本地错误，也必须遵循此过程，该错误通常会导致中点生成带有除上面第1项中列出的错误代码以外的任何错误代码的ResvErr，或者如果接收器代理为通常会出现的本地错误生成路径错误，则必须遵循此过程
not cause generation of a ResvErr. In some cases, it may be predetermined that the PathErr will not reach the sender. For example, a node receiving a ResvErr with "Code 3: No Path for Resv", knows a priori that the PathErr message it generates cannot be forwarded by the same node that could not process the Resv. Nevertheless, the procedures above MUST be followed. For the error code "36: Unrecoverable Receiver Proxy Error", the 16 bits of the Error Value field are:
不会导致重新扫描的生成。在某些情况下，可以预先确定PathErr不会到达发送方。例如，接收到带有“代码3：没有Resv路径”的ResvErr的节点事先知道它生成的PathErr消息不能由无法处理Resv的同一节点转发。然而，必须遵循上述程序。对于错误代码“36：不可恢复的接收器代理错误”，错误值字段的16位为：
* hhhh hhhh llll llll
* 哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
where the bits are:
其中位为：
* hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored by the sender.
* hhh hhh=0000 0000:那么接收方代理必须将低位8位（llll llll）设置为0000 0000，并且发送方必须忽略它。
* hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) MUST be set by the Receiver Proxy to the value of the error code received in the ResvErr ERROR_SPEC (or, in case the Receiver Proxy generated the PathErr without having received a ResvErr, to the error code value that would have been included by the Receiver Proxy in the ERROR_SPEC in similar conditions if it was to generate a ResvErr). This error value MAY be used by the sender to further interpret the reason for the reservation failure.
* hhh hhh=0000 0001:那么接收器代理必须将低阶8位（llll llll）设置为ResvErr error_SPEC中接收到的错误代码的值（或者，如果接收方代理在未收到ResvErr的情况下生成了PathErr，则为接收方代理在类似条件下（如果要生成ResvErr）将包含在错误规范中的错误代码值）。发送方可以使用此错误值进一步解释保留失败的原因。
* hhhh hhhh = any other value: reserved.
* hhhhhh=任何其他值：保留。
3. If the Receiver Proxy receives a ResvErr with the InPlace flag set in the ERROR_SPEC, it MUST also set the InPlace flag in the ERROR_SPEC of the PathErr.
3. 如果接收方代理接收到错误规范中设置了InPlace标志的ResvErr，则它还必须在PathErr的错误规范中设置InPlace标志。
[RFC3473] defines an optional behavior whereby a node forwarding a PathErr message can remove the Path state associated with the PathErr message and indicate so by including the Path_State_Removed flag in the ERROR_SPEC object of the PathErr message. This can be used in some situations to expedite release of resources and minimize signaling load.
[RFC3473]定义了一种可选行为，转发PathErr消息的节点可以通过在PathErr消息的ERROR_SPEC对象中包含Path_state_Removed标志来移除与PathErr消息相关联的路径状态，并指示移除路径状态。在某些情况下，这可以用于加快资源释放并最小化信令负载。
This section discusses aspects of the use of the Path_State_Removed flag that are specific to the RSVP Receiver Proxy. In any other aspects, the Path_State_Removed flag operates as per [RFC3473].
本节讨论了特定于RSVP接收器代理的Path_State_Removed标志的使用方面。在任何其他方面中，路径状态移除标志按照[RFC3473]操作。
By default, the RSVP Receiver Proxy MUST NOT include the Path_State_Removed flag in the ERROR_SPEC of the PathErr message. This ensures predictable operations in all environments including those where some RSVP routers do not understand the Path_State_Removed flag.
默认情况下，RSVP接收方代理不得在PathErr消息的错误规范中包含Path_State_Removed标志。这确保了在所有环境中的可预测操作，包括某些RSVP路由器不理解Path_State_Removed标志的环境。
The RSVP Receiver Proxy MAY support an OPTIONAL mode (to be activated by configuration) whereby the RSVP Receiver Proxy includes the Path_State_Removed flag in the ERROR_SPEC of the PathErr message and removes its local Path state. When all routers on the path of a reservation support the Path_State_Removed flag, its use will indeed result in expedited resource release and reduced signaling. However, if there are one or more RSVP routers on the path of the reservation that do not support the Path_State_Removed flag (we refer to such routers as "old RSVP routers"), the use of the Path_State_Removed flag will actually result in slower resource release and increased signaling. This is because the Path_State_Removed flag will be propagated upstream by an old RSVP router (even if it does not understand it and does not tear its Path state). Thus, the sender will not send a Path Tear, and the old RSVP router will release its Path state only through refresh time-out. A network administrator needs to keep these considerations in mind when deciding whether to activate the use of the Path_State_Removed flag on the RSVP Receiver Proxy. In a controlled environment where all routers are known to support the Path_State_Removed flag, its use can be safely activated on the RSVP Receiver Proxy. In other environments, the network administrator needs to assess whether the improvement achieved with some reservations outweighs the degradation experienced by other reservations.
RSVP接收器代理可支持可选模式（通过配置激活），其中RSVP接收器代理在PathErr消息的错误规范中包括路径状态移除标志，并移除其本地路径状态。当保留路径上的所有路由器都支持path_State_Removed标志时，它的使用确实会加快资源释放并减少信令。但是，如果保留路径上有一个或多个RSVP路由器不支持path_State_Removed标志（我们将此类路由器称为“旧RSVP路由器”），则使用path_State_Removed标志实际上会导致资源释放变慢和信令增加。这是因为Path_State_Removed标志将由旧的RSVP路由器向上游传播（即使它不理解它，也不会破坏它的路径状态）。因此，发送方不会发送路径撕裂，旧的RSVP路由器将仅通过刷新超时释放其路径状态。网络管理员在决定是否在RSVP接收器代理上激活Path_State_Removed标志时，需要牢记这些注意事项。在一个受控环境中，已知所有路由器都支持Path_State_Removed标志，可以在RSVP接收器代理上安全地激活该标志的使用。在其他环境中，网络管理员需要评估使用某些保留所实现的改进是否超过其他保留所经历的降级。
Note that while this document specifies that an RSVP Receiver Proxy generates a PathErr upstream in the case of reservation failure, this document does NOT propose that the same be done by regular receivers. In other words, this document does NOT propose modifying the behavior of regular receivers as currently specified in [RFC2205]. The rationale for this includes the following:
请注意，虽然本文档指定在预订失败的情况下，RSVP接收方代理会生成一个PathErr上游，但本文档不建议常规接收方也这样做。换句话说，本文件不建议修改[RFC2205]中当前规定的常规接收者的行为。其理由包括：
o When the receiver is RSVP-capable, the current receiver-driven model of [RFC2205] is fully applicable because the receiver can synchronize RSVP reservation state and application state (since it participates in both). The sender(s) need not be aware of the RSVP reservation state. Thus, we can retain the benefits of receiver-driven operations that were explicitly sought by [RFC2205], which states, "In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a
o 当接收器支持RSVP时，[RFC2205]的当前接收器驱动模型完全适用，因为接收器可以同步RSVP保留状态和应用程序状态（因为它同时参与这两种状态）。发送方不需要知道RSVP保留状态。因此，我们可以保留[RFC2205]明确寻求的接收器驱动操作的优点，其中指出，“为了有效地适应大型组、动态组成员和异构接收器需求，RSVP使接收器负责请求
specific QoS". But even for the simplest single_sender/ single_receiver reservations, the current receiver-driven model reduces signaling load and per-hop RSVP processing by not sending any error message to the sender in case of admission control reject.
但即使对于最简单的单_发送方/单_接收方保留，当前的接收方驱动模型也通过在接纳控制拒绝的情况下不向发送方发送任何错误消息来减少信令负载和每跳RSVP处理。
o The motivation for adding sender error notification in the case of an RSVP Receiver Proxy lies in the fact that the actual receiver can no longer synchronize the RSVP reservation with application state (since the receiver does not participate in RSVP signaling), while the sender can. This motivation does not apply in the case of a regular receiver.
o 在RSVP接收方代理的情况下添加发送方错误通知的动机在于，实际接收方无法再将RSVP保留与应用程序状态同步（因为接收方不参与RSVP信令），而发送方可以。这种动机不适用于常规接受者。
o There is a lot of existing code and deployed systems successfully working under the current [RFC2205] model in the absence of proxy today. The current behavior of existing deployed systems should not be changed unless there were a very strong motivation.
o 在目前没有代理的情况下，有许多现有代码和部署的系统在当前[RFC2205]模型下成功工作。除非有非常强烈的动机，否则不应改变现有部署系统的当前行为。
The OPTIONAL method for sender notification of reservation failure defined in this section aims to provide a more efficient method than the one defined in Section 3.1. Its objectives include:
本节中定义的发送方预订失败通知的可选方法旨在提供比第3.1节中定义的方法更有效的方法。其目标包括：
o allowing the failure notification to be sent directly upstream to the sender by the router where the failure occurs (as opposed to first traveling downstream towards the Receiver Proxy and then traveling upstream from the Receiver Proxy to the sender, as effectively happens with the method defined in Section 3.1).
o 允许发生故障的路由器将故障通知直接向上游发送到发送方（而不是先向下游发送到接收方代理，然后从接收方代理向上游发送到发送方，如第3.1节中定义的方法所述）。
o allowing the failure notification to travel without hop-by-hop RSVP processing.
o 允许故障通知在没有逐跳RSVP处理的情况下传播。
o ensuring that such a notification is sent to senders that are capable and willing to process it (i.e., to synchronize reservation status with application).
o 确保将此类通知发送给有能力并愿意处理该通知的发件人（即，将保留状态与应用程序同步）。
o ensuring that such a notification is only sent in case the receiver is not itself capable and willing to do the synchronization with the application (i.e., because we are in the presence of a Receiver Proxy so that RSVP signaling is not visible to the receiver).
o 确保仅在接收方自身无法且不愿意与应用程序进行同步的情况下发送此类通知（即，因为我们存在接收方代理，因此RSVP信令对接收方不可见）。
Note, however, that such benefits come at the cost of:
然而，请注意，这些好处的代价是：
o a requirement for RSVP routers and senders to support the Notify messages and procedures defined in [RFC3473].
o 要求RSVP路由器和发送器支持[RFC3473]中定义的通知消息和程序。
o a requirement for senders to process Notify messages traveling upstream but conveying a downstream notification.
o 要求发送方处理上游发送但传递下游通知的通知消息。
[RFC3473] defines (in Section 4.3, "Notify Messages") the Notify message that provides a mechanism to inform non-adjacent nodes of events related to the RSVP reservation. The Notify message differs from the error messages defined in [RFC2205] (i.e., PathErr and ResvErr messages) in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor and that it is a generalized notification mechanism. Notify messages are normally generated only after a Notify Request object has been received.
[RFC3473]定义了（第4.3节“通知消息”）通知消息，该消息提供了一种机制，用于通知非相邻节点与RSVP保留相关的事件。Notify消息与[RFC2205]中定义的错误消息（即PathErr和ResvErr消息）的不同之处在于，它可以“定向”到除直接上游或下游邻居之外的节点，并且它是一种通用通知机制。通知消息通常仅在收到通知请求对象后生成。
This section discusses aspects of the use of the Notify message that are specific to the RSVP Receiver Proxy. In any other aspects, the Notify message operates as per [RFC3473].
本节讨论特定于RSVP接收方代理的Notify消息的使用方面。在任何其他方面，通知消息按照[RFC3473]操作。
In order to achieve sender notification of reservation failure in the context of this document:
为了在本文档中实现预订失败的发送方通知：
o An RSVP sender interested in being notified of reservation failure MUST include a Notify Request object (containing the sender's IP address) in the Path messages it generates.
o 有意收到预订失败通知的RSVP发送方必须在其生成的路径消息中包含Notify请求对象（包含发送方的IP地址）。
o Upon receiving a Path message with a Notify Request object, the RSVP Receiver Proxy MUST include a Notify Request object in the Resv messages it generates. This Notify Request object MUST contain either:
o 接收到带有Notify Request对象的Path消息后，RSVP接收方代理必须在其生成的Resv消息中包含Notify Request对象。此通知请求对象必须包含以下内容之一：
* the address that was included in the Notify Request of the received Path message, a.k.a. the sender's address. We refer to this approach as the "Direct Notify" approach, or
* 包含在接收到的路径消息的通知请求中的地址，也称为发件人地址。我们将此方法称为“直接通知”方法，或
* an address of the Receiver Proxy. We refer to this approach as the "Indirect Notify" approach.
* 接收方代理的地址。我们将此方法称为“间接通知”方法。
o Upon receiving a downstream error notification (whether in the form of a Notify, ResvErr, or both), the RSVP Receiver Proxy:
o 收到下游错误通知（无论是以Notify、ResvErr或两者的形式）后，RSVP接收方代理：
* MUST generate a Notify message with upstream notification to the corresponding sender, if the sender included a Notify Request object in its Path messages and if Indirect Notification is used.
* 如果发送方在其路径消息中包含Notify Request对象，并且使用了间接通知，则必须生成一条向相应发送方发出上游通知的Notify消息。
* SHOULD generate a Notify message with upstream notification to the corresponding sender, if the sender included a Notify Request object in its Path messages and if Direct Notification is used. The reason for this recommendation is that the failure node may not support Notify, so that even if Direct
* 如果发送方在其路径消息中包含Notify请求对象，并且使用了直接通知，则应生成一条通知消息，并向相应的发送方发送上游通知。此建议的原因是故障节点可能不支持Notify，因此即使直接
Notification was requested by the RSVP Receiver Proxy, the sender may not actually have received a Notify from the failure node: generating a Notify from the Receiver Proxy will accelerate sender notification, as compared to simply relying on PathErr, in this situation. In controlled environments where all the nodes are known to support Notify, the Receiver Proxy MAY be configured to not generate the Notify with upstream notification when Direct Notification is used, in order to avoid duplication of Notify messages (i.e., the sender receiving both a Notify from the failure node and from the Receiver Proxy).
通知是由RSVP接收方代理请求的，发送方可能实际上没有收到来自故障节点的通知：在这种情况下，与仅依赖PathErr相比，从接收方代理生成通知将加快发送方通知的速度。在已知所有节点都支持Notify的受控环境中，接收方代理可配置为在使用直接通知时不生成带有上游通知的Notify，以避免重复通知消息（即，发送方从故障节点和接收方代理接收通知）。
As a result of these sender and Receiver Proxy behaviors, as per existing Notify procedures, if an RSVP router detects an error relating to a Resv state (e.g., admission control rejection after IP reroute), the RSVP router will send a Notify message (conveying the downstream notification with the ResvErr error code) to the IP address contained in the Resv Notify Request object. If this address has been set by the RSVP Receiver Proxy to the sender's address (Direct Notify), the Notify message is sent directly to the sender. If this address has been set by the RSVP Receiver Proxy to one of its own addresses (Indirect Notify), the Notify message is sent to the RSVP Receiver Proxy that, in turn, will generate a Notify message directly addressed to the sender.
由于这些发送方和接收方代理行为，根据现有的通知程序，如果RSVP路由器检测到与Resv状态相关的错误（例如，IP重新路由后的准入控制拒绝），RSVP路由器将发送通知消息（用ResvErr错误代码传递下游通知）发送到Resv Notify请求对象中包含的IP地址。如果RSVP接收方代理已将此地址设置为发送方地址（直接通知），则通知消息将直接发送给发送方。如果RSVP接收方代理已将此地址设置为其自己的一个地址（间接通知），则通知消息将发送至RSVP接收方代理，该代理将生成直接发送至发送方的通知消息。
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, using sender notification via Direct Notify, is illustrated in Figure 4.
在准入控制失败的情况下，通过直接通知使用发送方通知，路径触发的RSVP接收方代理的操作如图4所示。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path*--> --Path*--> --Path*--> --Path*-->
--Path*--> --Path*--> --Path*--> --Path*-->
<--Resv*-- <--Resv*--
<--Resv*-- <--Resv*--
<------NotifyD--------
<------NotifyD--------
-ResvErr-> -ResvErr->
-ResvErr-> -ResvErr->
<------------------NotifyU------------------
<------------------NotifyU------------------
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================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 benefiting from RSVP (but not benefiting from a reservation in this case)
==>受益于RSVP的流路段（但在这种情况下不受益于保留）
Path* = Path message containing a Notify Request object with sender IP Address
Path*=包含具有发件人IP地址的Notify请求对象的路径消息
Resv* = Resv message containing a Notify Request object with sender IP address
Resv*=包含具有发件人IP地址的Notify请求对象的Resv消息
NotifyD = Notify message containing a downstream notification
NotifyD=包含下游通知的Notify消息
NotifyU = Notify message containing an upstream notification
NotifyU=包含上游通知的Notify消息
Figure 4: Reservation Failure with Sender Notification via Direct Notify
图4：通过Direct Notify发送通知的预订失败
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, using sender notification via Indirect Notify, is illustrated in Figure 5.
在准入控制失败的情况下，通过间接通知使用发送方通知，路径触发的RSVP接收方代理的操作如图5所示。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path*--> --Path*--> --Path*--> --Path*-->
--Path*--> --Path*--> --Path*--> --Path*-->
<--Resv*-- <--Resv*--
<--Resv*-- <--Resv*--
-------NotifyD------->
-------NotifyD------->
<------------------NotifyU------------------
<------------------NotifyU------------------
-ResvErr-> -ResvErr->
-ResvErr-> -ResvErr->
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================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 benefiting from RSVP (but not benefiting from a reservation in this case)
==>受益于RSVP的流路段（但在这种情况下不受益于保留）
Path* = Path message containing a Notify Request object with sender IP Address
Path*=包含具有发件人IP地址的Notify请求对象的路径消息
Resv* = Resv message containing a Notify Request object with RSVP Receiver Proxy IP address
Resv*=包含具有RSVP接收方代理IP地址的Notify请求对象的Resv消息
NotifyD = Notify message containing a downstream notification
NotifyD=包含下游通知的Notify消息
NotifyU = Notify message containing an upstream notification
NotifyU=包含上游通知的Notify消息
Figure 5: Reservation Failure with Sender Notification via Indirect Notify
图5：通过间接通知发送人通知的预订失败
For local failures on the Receiver Proxy node, if a similar failure on an RSVP midpoint would cause the generation of a ResvErr (for example, admission control failure), the Receiver Proxy MUST generate
对于接收方代理节点上的本地故障，如果RSVP中点上的类似故障将导致生成ResvErr（例如，准入控制故障），则接收方代理必须生成
a Notify towards the sender. The Receiver Proxy MAY additionally generate a Notify upon local failures that would not ordinarily cause generation of a ResvErr message, such as those described in Appendix B of [RFC2205].
对发送者的通知。接收方代理还可以在通常不会导致生成ResvErr消息的本地故障时生成通知，如[RFC2205]附录B中所述。
When the method of sender notification via a Notify message is used, it is RECOMMENDED that the RSVP Receiver Proxy also issue a sender notification via a PathErr message. This maximizes the chances that the notification will reach the sender in all situations (e.g., even if some RSVP routers do not support the Notify procedure, or if a Notify message gets dropped). However, for controlled environments (e.g., where all RSVP routers are known to support Notify procedures) and where it is desirable to minimize the volume of signaling, the RSVP Receiver Proxy MAY rely exclusively on sender notification via a Notify message and thus not issue sender notification via a PathErr message.
使用通过Notify消息通知发件人的方法时，建议RSVP接收方代理也通过PathErr消息发出发件人通知。这将最大限度地提高通知在所有情况下到达发送方的机会（例如，即使某些RSVP路由器不支持通知过程，或者如果通知消息被丢弃）。然而，对于受控环境（例如，已知所有RSVP路由器都支持通知过程）和希望最小化信令量的环境，RSVP接收器代理可以完全依赖于通过通知消息的发送方通知，因此不通过PathErr消息发出发送方通知。
In environments where there are both RSVP-capable receivers and RSVP Receiver Proxies acting on behalf of non-RSVP-capable receivers, a sender does not know whether a given reservation is established with an RSVP-capable receiver or with an RSVP Receiver Proxy. Thus, a sender that supports the procedures defined in this section may include a Notify Request object in Path messages for a reservation that happens to be controlled by an RSVP-capable receiver. This document does not define, nor expect, any change in existing receiver behavior. As a result, in this case, the sender will not receive Notify messages conveying downstream notifications. However, this is perfectly fine because the synchronization between the RSVP reservation state and the application requirement can be performed by the actual receiver in this case as per the regular end-to-end RSVP model, so that in this case, the sender need not care about downstream notifications.
在同时存在支持RSVP的接收器和代表不支持RSVP的接收器的RSVP接收器代理的环境中，发送方不知道是使用支持RSVP的接收器还是使用RSVP接收器代理建立了给定的保留。因此，支持本节中定义的过程的发送方可以在路径消息中包含Notify Request对象，用于恰好由支持RSVP的接收方控制的保留。本文档不定义也不期望现有接收方行为发生任何变化。因此，在这种情况下，发送方将不会收到传递下游通知的通知消息。然而，这是非常好的，因为在这种情况下，实际接收方可以按照常规的端到端RSVP模型执行RSVP保留状态和应用程序需求之间的同步，因此在这种情况下，发送方不需要关心下游通知。
A sender that does not support the procedures defined in this section might include a Notify Request object in Path messages for a reservation simply because it is interested in getting upstream notifications faster. If the reservation is controlled by an RSVP Receiver Proxy supporting the procedures defined in this section, the sender will also receive unexpected Notify messages containing downstream notifications. It is expected that such a sender will simply naturally drop such downstream notifications as invalid. Because it is RECOMMENDED above that the RSVP Receiver Proxy also issue a sender notification via a PathErr message even when sender notification is effected via a Notify message, the sender will still be notified of a reservation failure in accordance with the "sender notification via PathErr" method. In summary, activating the OPTIONAL "sender notification via Notify" method on a Receiver Proxy does not prevent a sender that does not support this method from
不支持本节中定义的过程的发送方可能会在保留的路径消息中包含Notify Request对象，因为它希望更快地获取上游通知。如果保留由支持本节中定义的过程的RSVP接收方代理控制，则发送方还将收到包含下游通知的意外通知消息。可以预期，这样的发送者会自然地将这样的下游通知丢弃为无效。因为上面建议RSVP接收方代理也通过PathErr消息发出发送方通知，即使发送方通知通过Notify消息生效，发送方仍将根据“发送方通过PathErr通知”方法收到预订失败的通知。总之，在接收方代理上激活可选的“发件人通知通过通知”方法不会阻止不支持此方法的发件人发送邮件
relying on the MANDATORY "sender notification via PathErr" method. It would, however, allow a sender supporting the "sender notification via Notify" method to take advantage of this OPTIONAL method.
依赖于强制的“通过PathErr发送通知”方法。但是，它将允许支持“发件人通知通过通知”方法的发件人利用此可选方法。
With Direct Notification, the downstream notification generated by the RSVP router where the failure occurs is sent to the IP address contained in the Notification Request Object of the corresponding Resv message. In the presence of multiple senders towards the same session, it cannot be generally assumed that a separate Resv message is used for each sender (in fact, with WF and SE there is a single Resv message for all senders, and with FF the downstream router has the choice of generating separate Resv messages or a single one). Hence, in the presence of multiple senders, Direct Notification cannot guarantee notification of all affected senders. Therefore, Direct Notification is better suited to single-sender applications.
对于直接通知，由发生故障的RSVP路由器生成的下游通知被发送到相应Resv消息的通知请求对象中包含的IP地址。在同一会话中存在多个发送方的情况下，通常不能假定每个发送方使用单独的Resv消息（事实上，对于WF和SE，所有发送方都有一个单独的Resv消息，对于FF，下游路由器可以选择生成单独的Resv消息或一个单独的Resv消息）。因此，在存在多个发件人的情况下，直接通知不能保证通知所有受影响的发件人。因此，直接通知更适合于单发送方应用程序。
With Indirect Notification, the RSVP Receiver Proxy can generate Notify messages with the same logic that is used to generate PathErr messages in the "Sender Notification via PathErr" method (in fact, those are conveying the same error information, only the Notify is directly addressed to the sender while the PathErr travels hop-by-hop). Therefore, operations of the Indirect Notify method in the presence of multiple senders is similar to that of the PathErr method as discussed in Section 3.1: with FF or SE, a Notify MUST be sent to the sender or the set of affected senders, respectively. With WF, the RSVP Receiver Proxy SHOULD send a Notify to each sender, again resulting in a somewhat overly conservative behavior in the presence of multiple senders.
通过间接通知，RSVP接收方代理可以生成通知消息，其逻辑与“通过PathErr发送发件人通知”方法中生成PathErr消息的逻辑相同（事实上，这些消息传递的是相同的错误信息，只有通知直接发送给发件人，而PathErr则逐跳发送）。因此，存在多个发送者时间接通知方法的操作类似于第3.1节中讨论的PathErr方法：对于FF或SE，必须分别向发送者或受影响的发送者集发送通知。对于WF，RSVP接收方代理应该向每个发送方发送通知，这同样会导致在多个发送方存在的情况下出现过于保守的行为。
This section defines extensions to RSVP procedures allowing an RSVP reservation to span as much of the flow path as possible, with any arbitrary number of RSVP Receiver Proxies on the flow path and whether or not the receiver is RSVP-capable. This facilitates deployment and operations of Path-Triggered RSVP Receiver Proxies since it alleviates the topological constraints and/or configuration load otherwise associated with Receiver Proxies (e.g., make sure there is no RSVP Receiver Proxy for a flow upstream of a given Receiver Proxy, ensure there is no Receiver Proxy for a flow if the receiver is RSVP-capable). This also facilitates migration from an RSVP deployment model based on Path-Triggered Receiver Proxies to an end-to-end RSVP model, since receivers can gradually and independently be upgraded to support RSVP and then instantaneously benefit from end-to-end reservations.
本节定义了RSVP程序的扩展，允许RSVP保留尽可能跨越流路径，流路径上有任意数量的RSVP接收器代理，以及接收器是否具有RSVP功能。这有助于路径触发RSVP接收器代理的部署和操作，因为它减轻了拓扑约束和/或与接收器代理相关的配置负载（例如，确保给定接收器代理上游的流没有RSVP接收器代理，如果接收器具有RSVP能力，则确保流没有接收器代理）。这也有助于从基于路径触发的接收器代理的RSVP部署模型迁移到端到端RSVP模型，因为接收器可以逐渐独立升级以支持RSVP，然后立即从端到端保留中获益。
Section 4.1 defines a method that allows a Path-Triggered Receiver Proxy function to discover whether there is another Receiver Proxy or an RSVP-capable receiver downstream and then dynamically extend the span of the RSVP reservation downstream. A router implementation claiming compliance with this document SHOULD support the method defined in Section 4.1.
第4.1节定义了一种方法，该方法允许路径触发的接收器代理功能发现下游是否存在另一个接收器代理或支持RSVP的接收器，然后动态扩展下游RSVP保留的范围。声称符合本文件要求的路由器实现应支持第4.1节中定义的方法。
Section 4.2 defines a method that allows a sender to control whether or not an RSVP router supporting the Path-Triggered Receiver Proxy function is to behave as a Receiver Proxy for a given flow. A router implementation claiming compliance with this document MAY support the method defined in Section 4.2.
第4.2节定义了一种方法，允许发送方控制支持路径触发接收器代理功能的RSVP路由器是否作为给定流的接收器代理。声称符合本文件要求的路由器实现可能支持第4.2节中定义的方法。
In a given network environment, a network administrator may elect to use the method defined in Section 4.1, or the method defined in Section 4.2, or possibly combine the two.
在给定的网络环境中，网络管理员可选择使用第4.1节中定义的方法或第4.2节中定义的方法，或可能将两者结合使用。
When generating a proxy Resv message upstream, a Receiver Proxy supporting dynamic discovery of downstream RSVP functionality MUST forward the Path message downstream instead of terminating it (unless dynamic discovery of downstream RSVP functionality is explicitly disabled). If the destination endpoint supports RSVP (or there is another Receiver Proxy downstream), it will receive the Path and generate a Resv upstream. When this Resv message reaches the Receiver Proxy, it recognizes the presence of an RSVP-capable receiver (or of another RSVP Receiver Proxy) downstream and MUST internally convert its state from a proxied reservation to a regular midpoint RSVP behavior. From then on, the RSVP router MUST behave as a regular RSVP router for that reservation (i.e., as if the RSVP router never behaved as an RSVP Receiver Proxy for that flow). This method is illustrated in Figure 6.
在上游生成代理Resv消息时，支持下游RSVP功能动态发现的接收方代理必须将路径消息转发到下游，而不是终止它（除非明确禁用下游RSVP功能的动态发现）。如果目标端点支持RSVP（或者下游有另一个接收方代理），它将接收路径并在上游生成Resv。当此Resv消息到达接收方代理时，它会识别下游是否存在支持RSVP的接收方（或另一个RSVP接收方代理），并且必须在内部将其状态从代理保留转换为常规中点RSVP行为。从那时起，RSVP路由器必须作为该预留的常规RSVP路由器（即，好像RSVP路由器从未作为该流的RSVP接收器代理）。此方法如图6所示。
|****| *** |**********| |----|
| 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 6: Dynamic Discovery of Downstream RSVP Functionality
图6：下游RSVP功能的动态发现
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; however, to mitigate this, the Receiver Proxy MAY tear down any unanswered downstream Path state after a predetermined time (that SHOULD be greater or equal to the Path refresh interval), and MAY stop sending Path messages for the flow (or MAY only send them at much lower frequency).
如果接收方代理下游没有支持RSVP的接收方（或其他接收方代理），则接收方代理在每个RSVP刷新间隔（例如，默认情况下为30秒）发送的路径消息将永远不会得到响应。但是，这些消息会消耗少量带宽，此外，还会在第一个接收器代理下游的支持RSVP的中点节点上安装一些RSVP状态。这被视为一个非常小的次优；然而，为了减轻这一点，接收器代理可以在预定时间（应该大于或等于路径刷新间隔）之后解除任何未应答的下游路径状态，并且可以停止发送流的路径消息（或者可以仅以更低的频率发送它们）。
This approach only requires support of the behavior described in the previous paragraph and does not require any new RSVP extensions.
这种方法只需要支持上一段中描述的行为，不需要任何新的RSVP扩展。
[RFC2750] defines extensions for supporting generic policy-based admission control in RSVP. These extensions include the standard format of POLICY_DATA objects and a description of RSVP handling of policy events.
[RFC2750]定义了支持RSVP中基于通用策略的准入控制的扩展。这些扩展包括POLICY_数据对象的标准格式和对策略事件的RSVP处理的描述。
The POLICY_DATA object contains one or more policy elements, each representing a different (and perhaps orthogonal) policy. As an example, [RFC3181] specifies the preemption priority policy element.
POLICY_数据对象包含一个或多个POLICY元素，每个元素表示不同的（可能是正交的）策略。例如，[RFC3181]指定抢占优先级策略元素。
This document defines a new policy element called the Receiver Proxy Control policy element. This document only defines the use of this policy element in Path messages and for unicast reservations. Other usage is outside the scope of this document.
本文档定义了一个新的策略元素，称为接收方代理控制策略元素。本文档仅定义在路径消息和单播保留中使用此策略元素。其他用途不在本文档范围内。
The format of the Receiver Proxy Control policy element is as shown in Figure 7:
Receiver Proxy Control policy元素的格式如图7所示：
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type=REC_PROXY_CONTROL |
+-------------+-------------+-------------+-------------+
| Reserved |Control-Value|
+---------------------------+---------------------------+
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type=REC_PROXY_CONTROL |
+-------------+-------------+-------------+-------------+
| Reserved |Control-Value|
+---------------------------+---------------------------+
Figure 7: Receiver Proxy Control Policy Element
图7：接收方代理控制策略元素
where:
哪里：
o Length: 16 bits
o 长度：16位
* Always 8. The overall length of the policy element, in bytes.
* 总是8。策略元素的总长度，以字节为单位。
o P-Type: 16 bits
o P型：16位
* REC_PROXY_CONTROL = 0x07 (see the "IANA Considerations" section).
* REC_PROXY_CONTROL=0x07（请参阅“IANA注意事项”部分）。
o Reserved: 24 bits
o 保留：24位
* SHALL be set to zero on transmit and SHALL be ignored on reception.
* 传输时应设置为零，接收时应忽略。
o Control-Value: 8 bits (unsigned)
o 控制值：8位（无符号）
* 0 (Reserved): An RSVP Receiver Proxy that understands this policy element MUST ignore the policy element if its Control-Value is set to that value.
* 0（保留）：如果策略元素的控制值设置为该值，则理解该策略元素的RSVP接收方代理必须忽略该策略元素。
* 1 (Receiver-Proxy-Needed): An RSVP Receiver Proxy that understands this policy element MUST attempt to insert itself as a Receiver Proxy for that flow if the corresponding Path message contains this Control-Value. If the Receiver Proxy also supports dynamic discovery of downstream RSVP functionality as specified in Section 4.1, it MUST still send the Path message downstream and attempt to extend the reservation downstream so that the reservation can be extended to the last Receiver Proxy). An RSVP sender MAY insert the Receiver Proxy Control policy element with this Control-Value when it knows (say, by other means, such as application-level signaling) that the receiver is not RSVP-capable.
* 1（需要接收方代理）：如果相应的路径消息包含此控制值，则理解此策略元素的RSVP接收方代理必须尝试将自身插入为该流的接收方代理。如果接收方代理还支持第4.1节中规定的下游RSVP功能的动态发现，则它仍必须向下游发送路径消息，并尝试向下游扩展保留，以便将保留扩展到最后一个接收方代理）。当RSVP发送方知道（例如，通过其他方式，例如应用级信令）接收机不具备RSVP能力时，可以使用该控制值插入接收机代理控制策略元素。
* 2 (Receiver-Proxy-Not-Needed): An RSVP Receiver Proxy that understands this policy element MUST NOT attempt to insert itself as a Receiver Proxy for that flow if the corresponding Path message contains this Control-Value. An RSVP sender MAY insert the Receiver Proxy Control policy element with this Control-Value when it knows (say, by other means, such as application-level signaling) that the receiver is RSVP-capable.
* 2（不需要接收方代理）：如果相应的路径消息包含此控制值，则理解此策略元素的RSVP接收方代理不得尝试将自身插入为该流的接收方代理。当RSVP发送方知道（例如，通过其他方式，例如应用级信令）接收机具有RSVP能力时，可以使用该控制值插入接收机代理控制策略元素。
Figure 8 illustrates the method based on the Receiver Proxy Control policy element that allows a sender to control whether or not an RSVP router supporting the Path-Triggered Receiver Proxy function is to behave as a Receiver Proxy for a given flow.
图8说明了基于接收方代理控制策略元素的方法，该策略元素允许发送方控制支持路径触发的接收方代理功能的RSVP路由器是否作为给定流的接收方代理。
|****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----|
| Proxy |
| |
| | |****|
| |------------| R2 |
|**********| |****|
|****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----|
| Proxy |
| |
| | |****|
| |------------| R2 |
|**********| |****|
---Path---> --Path--->
(R1/N) (R1/N)
---Path---> --Path--->
(R1/N) (R1/N)
<--Resv--- <---Resv---
<--Resv--- <---Resv---
================RSVP===>
================RSVP===>
**************************************>
**************************************>
---Path---> --Path---> ----Path---->
(R2/NN) (R2/NN) (R2/NN)
---Path---> --Path---> ----Path---->
(R2/NN) (R2/NN) (R2/NN)
<--Resv--- <---Resv--- <----Resv----
<--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
(R1) = Path message contains a Session object whose destination is R1
***
*r* regular RSVP
*** router
(R1) = Path message contains a Session object whose destination is R1
(N) = Path message contains a Receiver Proxy Control policy element whose Control-Value is set to Receiver-Proxy-Needed
（N） =路径消息包含一个接收方代理控制策略元素，该元素的控制值设置为所需的接收方代理
(NN) = Path message contains a Receiver Proxy Control policy element whose Control-Value is set to Receiver-Proxy-Not-Needed
（NN）=路径消息包含一个接收方代理控制策略元素，其控制值设置为“接收方代理不需要”
***> media flow
==> segment of flow path protected by RSVP reservation
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 8: Receiver Proxy Control by Sender
图8：按发送方列出的接收方代理控制
As specified in Section 4.2 of [RFC2750], Policy-Ignorant Nodes (PINs) implement a default handling of POLICY_DATA objects ensuring that those objects can traverse PINs in transit from one Policy Enforcement Point (PEP) to another. This applies to the situations in which POLICY_DATA objects contain the Receiver Proxy Control policy element specified in this document, so that those objects can traverse PINs.
如[RFC2750]第4.2节所述，策略无关节点（PIN）实现策略_数据对象的默认处理，确保这些对象可以在从一个策略实施点（PEP）到另一个策略实施点（PEP）的传输过程中遍历PIN。这适用于POLICY_数据对象包含本文档中指定的Receiver Proxy Control POLICY元素的情况，以便这些对象可以遍历管脚。
Section 4.2 of [RFC2750] also defines a similar default behavior for policy-capable nodes that do not recognize a particular policy element. This applies to the Receiver Proxy Control policy element specified in this document, so that messages carrying the element can traverse policy-capable nodes that do not support the extensions described in this document.
[RFC2750]的第4.2节还为不识别特定策略元素的支持策略的节点定义了类似的默认行为。这适用于本文档中指定的接收方代理控制策略元素，因此携带该元素的消息可以遍历不支持本文档中描述的扩展的支持策略的节点。
As this document defines extensions to RSVP, the security considerations of RSVP apply, which are discussed in [RFC2205], [RFC4230], and [SEC-GRP-KEY]. Approaches for addressing those concerns are discussed further below.
由于本文档定义了对RSVP的扩展，RSVP的安全注意事项适用于[RFC2205]、[RFC4230]和[SEC-GRP-KEY]中讨论的内容。下文将进一步讨论解决这些问题的方法。
The RSVP authentication mechanisms defined in [RFC2747] and [RFC3097] protect RSVP message integrity hop-by-hop and provide node authentication as well as replay protection, thereby protecting against corruption and spoofing of RSVP messages. These hop-by-hop integrity mechanisms can be used to protect RSVP reservations established using an RSVP Receiver Proxy in accordance with this document. [SEC-GRP-KEY] discusses key types and key provisioning methods as well as their respective applicability to RSVP authentication. RSVP authentication (defined in [RFC2747] and [RFC3097]) SHOULD be supported by an implementation of this document.
[RFC2747]和[RFC3097]中定义的RSVP身份验证机制逐跳保护RSVP消息完整性，并提供节点身份验证和重播保护，从而防止RSVP消息的损坏和欺骗。这些逐跳完整性机制可用于保护根据本文件使用RSVP接收器代理建立的RSVP保留。[SEC-GRP-KEY]讨论密钥类型和密钥提供方法，以及它们各自对RSVP身份验证的适用性。本文件的实施应支持RSVP认证（定义见[RFC2747]和[RFC3097]）。
[SEC-GRP-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 Path-Triggered RSVP Receiver Proxies as defined in this document.
[SEC-GRP-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
RSVP消息的子集通过IP路由器警报选项（[RFC2113]、[RFC2711]）发出信号。基于与使用IP路由器警报选项相关的当前安全问题，RSVP（以及本文档中讨论的RSVP代理方法）的适用性仅限于受控环境
(i.e., 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].
（即，了解并防范与使用IP路由器警报选项相关的安全风险）。[RTR-alert]详细讨论了使用当前IP路由器警报选项的安全方面和常见做法，以及应用程序（如RSVP）使用IP路由器警报选项的后果。
When an RSVP Receiver Proxy is used, the RSVP reservation is no longer controlled by the receiver, but rather is controlled by the Receiver Proxy (using hints received from the sender in the Path message) on behalf of the sender. Thus, the Receiver Proxy ought to be trusted by the end-systems to control the RSVP reservation appropriately. However, basic RSVP operation already assumes a trust model where end-systems trust RSVP nodes to appropriately perform RSVP reservations. So the use of an RSVP Receiver Proxy is not seen as introducing any significant additional security threat or as modifying the RSVP trust model.
使用RSVP接收方代理时，RSVP保留不再由接收方控制，而是由接收方代理（使用Path消息中从发送方收到的提示）代表发送方控制。因此，终端系统应该信任接收方代理来适当地控制RSVP预留。然而，基本的RSVP操作已经假设了一个信任模型，其中终端系统信任RSVP节点以适当地执行RSVP保留。因此，使用RSVP接收方代理不被视为引入任何重大的额外安全威胁或修改RSVP信任模型。
In fact, there are situations in which the use of an RSVP Receiver Proxy reduces the security risks. One example is where a network operator relies on RSVP to perform resource reservation and admission control within a network and where RSVP senders and RSVP routers are located in the operator's premises, while the many RSVP receivers are located in the operator's customers' premises. Such an environment is further illustrated in Appendix A.1, "RSVP-Based VoD Admission Control in Broadband Aggregation Networks", of [RFC5945]. From the operator's perspective, the RSVP routers and RSVP senders are in physically secured locations and therefore exposed to a lower risk of being tampered with, while the receivers are in locations that are physically unsecured and therefore subject to a higher risk of being tampered with. The use of an RSVP Receiver Proxy function effectively increases the security of the operator's reservation and admission control solution by completely excluding receivers from its operation. Filters can be placed at the edge of the operator network, discarding any RSVP message received from end-users. This provides a very simple and effective protection of the RSVP reservation and admission control solution operating inside the operator's network.
事实上，在某些情况下，使用RSVP接收方代理可以降低安全风险。一个示例是，网络运营商依赖RSVP在网络内执行资源预留和接纳控制，并且RSVP发送方和RSVP路由器位于运营商的场所，而许多RSVP接收方位于运营商的客户场所。[RFC5945]的附录A.1“宽带聚合网络中基于RSVP的VoD接入控制”进一步说明了这种环境。从运营商的角度来看，RSVP路由器和RSVP发送方位于物理安全位置，因此受到篡改的风险较低，而接收方位于物理安全位置，因此受到篡改的风险较高。RSVP接收器代理功能的使用通过将接收器完全排除在其操作之外，有效地提高了运营商预约和准入控制解决方案的安全性。过滤器可以放置在运营商网络的边缘，丢弃从最终用户收到的任何RSVP消息。这为运营商网络内运行的RSVP保留和许可控制解决方案提供了非常简单有效的保护。
5.1. Security Considerations for the Sender Notification via Notify Message
5.1. 通过Notify消息发送发件人通知的安全注意事项
This document defines, in Section 3.2, an optional method relying on the use of the Notify message specified in [RFC3473]. The Notify message can be sent in a non-hop-by-hop fashion that precludes the use of the RSVP hop-by-hop integrity and authentication model. The approaches and considerations for addressing this issue presented in the Security Considerations section of [RFC3473] apply. In
本文件在第3.2节中定义了一种可选方法，该方法依赖于[RFC3473]中规定的通知消息的使用。Notify消息可以以非逐跳方式发送，从而避免使用RSVP逐跳完整性和身份验证模型。[RFC3473]的安全注意事项部分中介绍的解决此问题的方法和注意事项适用。在里面
particular, where the Notify messages are transmitted non-hop-by-hop and the same level of security provided by [RFC2747] is desired, IPsec-based integrity and authentication can be used ([RFC4302] or [RFC4303]). Alternatively, the sending of non-hop-by-hop Notify messages can be disabled. Finally, [SEC-GRP-KEY] discusses the applicability of group keying for non-hop-by-hop Notify messages.
特别是，如果通知消息是逐跳传输的，并且需要[RFC2747]提供的相同安全级别，则可以使用基于IPsec的完整性和身份验证（[RFC4302]或[RFC4303]）。或者，可以禁用发送非逐跳通知消息。最后，[SEC-GRP-KEY]讨论了组键控对非逐跳通知消息的适用性。
5.2. Security Considerations for the Receiver Proxy Control Policy Element
5.2. 接收方代理控制策略元素的安全注意事项
This document also defines, in Section 4.2, the optional Receiver Proxy Control policy element. Policy elements are signaled by RSVP through encapsulation in a Policy Data object as defined in [RFC2750]. Therefore, like any other policy elements, the integrity of the Receiver Proxy Control policy element can be protected as discussed in Section 6 of [RFC2750] by two optional security mechanisms.
本文件还在第4.2节中定义了可选的接收方代理控制策略元素。策略元素由RSVP通过封装在[RFC2750]中定义的策略数据对象中发出信号。因此，与任何其他策略元素一样，接收方代理控制策略元素的完整性可以通过两种可选的安全机制进行保护，如[RFC2750]第6节所述。
The first mechanism relies on the RSVP authentication discussed above that provides a chain of trust when all RSVP nodes are policy capable. With this mechanism, the INTEGRITY object is carried inside RSVP messages.
第一种机制依赖于上面讨论的RSVP身份验证，该身份验证在所有RSVP节点都支持策略时提供信任链。通过这种机制，完整性对象被携带在RSVP消息中。
The second mechanism relies on the INTEGRITY object within the POLICY_DATA object to guarantee integrity between RSVP Policy Enforcement Points (PEPs) that are not RSVP neighbors. This is useful only when some RSVP nodes are Policy-Ignorant Nodes (PINs). The INTEGRITY object within the POLICY_DATA object MAY be supported by an implementation of this document.
第二种机制依赖于POLICY_数据对象中的INTEGRITY对象来保证不是RSVP邻居的RSVP策略实施点（pep）之间的完整性。这仅在某些RSVP节点是策略无关节点（PIN）时有用。本文档的实现可能支持POLICY_数据对象中的INTEGRITY对象。
Details for the computation of the content of the INTEGRITY object can be found in Appendix B of [RFC2750]. This states that the Policy Decision Point (PDP), at its discretion, and based on destination PEP/PDP or other criteria, selects an Authentication Key and the hash algorithm to be used. Keys to be used between PDPs can be distributed manually or via a standard key management protocol for secure key distribution.
完整性对象内容的计算详情见[RFC2750]附录B。这表明策略决策点（PDP）根据其判断，并基于目的地PEP/PDP或其他标准，选择要使用的认证密钥和散列算法。PDP之间使用的密钥可以手动分发，也可以通过标准密钥管理协议进行安全密钥分发。
Note that where non-RSVP hops may exist in between RSVP hops, as well as where RSVP-capable Policy-Ignorant Nodes (PINs) may exist in between PEPs, it may be difficult for the PDP to determine what the destination PDP is for a POLICY_DATA object contained in some RSVP messages (such as a Path message). This is because in those cases, the next PEP is not known at the time of forwarding the message. In this situation, a key shared across multiple PDPs may be used. This is conceptually similar to the use of a key shared across multiple RSVP neighbors, as discussed in [SEC-GRP-KEY]. We also observe that this issue may not exist in some deployment scenarios where a single
注意，如果在RSVP跳之间可能存在非RSVP跳，以及在PEP之间可能存在支持RSVP的策略无知节点（PIN），PDP可能难以确定目标PDP对于某些RSVP消息（例如路径消息）中包含的策略_数据对象是什么。这是因为在这些情况下，转发消息时不知道下一个政治公众人物。在这种情况下，可以使用跨多个PDP共享的密钥。这在概念上类似于使用多个RSVP邻居共享的密钥，如[SEC-GRP-key]中所述。我们还注意到，在某些部署场景中，如果单个
PDP (or a low number of PDPs) is used to control all the PEPs of a region (such as an administrative domain). In such scenarios, it may be easy for a PDP to determine what the next-hop PDP is, even when the next-hop PEP is not known, simply by determining what the next region is that will be traversed (say, based on the destination address).
PDP（或少量PDP）用于控制一个区域（如管理域）的所有政治公众人物。在这种情况下，PDP可能很容易确定下一跳PDP是什么，即使在下一跳PEP未知的情况下，也可以简单地通过确定将要穿越的下一个区域是什么（例如，基于目的地地址）。
Since, as discussed in Section 3.1.2, this document allows two error codes to be used in PathErr messages while [RFC2205] only specified their use in ResvErr messages, IANA has updated the existing entries for these two error codes under the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. Each entry refers to this document, in addition to referring to [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 read:
由于如第3.1.2节所述，本文件允许在PathErr消息中使用两个错误代码，而[RFC2205]仅指定了它们在ResvErr消息中的使用，因此IANA更新了“错误代码和全局定义的错误值子代码”注册表中这两个错误代码的现有条目。除参考[RFC2205]外，每个条目均参考本文件。具体而言，错误代码1和错误代码2的条目为：
1 Admission Control Failure [RFC2205] [RFC5946]
1准入控制失败[RFC2205][RFC5946]
2 Policy Control Failure [RFC2205] [RFC5946]
2策略控制失败[RFC2205][RFC5946]
IANA has also allocated a new RSVP Error Code "36;: Unrecoverable Receiver Proxy Error", as discussed in Section 3.1.2. This error code has been allocated under the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. The entry for this error code reads:
IANA还分配了一个新的RSVP错误代码“36；：不可恢复的接收器代理错误”，如第3.1.2节所述。此错误代码已在“错误代码和全局定义的错误值子代码”注册表下分配。此错误代码的条目如下所示：
36 Unrecoverable Receiver Proxy Error [RFC5946]
36不可恢复的接收器代理错误[RFC5946]
The sixteen bits of the Error Value field are defined in [RFC5946]
错误值字段的16位在[RFC5946]中定义
This document defines, in Section 4.2, a new policy element called the Receiver Proxy Control policy element. As specified in [RFC2750], standard RSVP policy elements (P-Type values) are to be assigned by IANA as per "IETF Consensus" policy following the policies outlined in [RFC2434] (this policy is now called "IETF Review" as per [RFC5226]).
本文件在第4.2节中定义了一个新的策略元素，称为接收方代理控制策略元素。按照[RFC2750]中的规定，IANA将按照[RFC2434]中概述的政策，按照“IETF共识”政策分配标准RSVP政策元素（P型值）（根据[RFC5226]，该政策现在称为“IETF审查”）。
Thus, IANA has allocated one P-Type to the Receiver Proxy Control policy element from the standard RSVP policy element range.
因此，IANA已从标准RSVP策略元素范围向接收方代理控制策略元素分配了一个P-Type。
In Section 4.2, this document defines a Control-Value field inside the Receiver Proxy Control policy element. IANA has created the "Receiver Proxy Control Policy Element (P-Type 0x07) Control-Value field" registry and allocated the following values:
在第4.2节中，本文件在接收方代理控制策略元素内定义了一个控制值字段。IANA已创建“接收方代理控制策略元素（P-Type 0x07）控制值字段”注册表，并分配了以下值：
o 0 : Reserved
o 0:保留
o 1 : Receiver-Proxy-Needed
o 1：需要接收方代理
o 2 : Receiver-Proxy-Not-Needed
o 2：不需要接收方代理
Following the policies outlined in [RFC5226], numbers in the range 3-127 are allocated according to the "IETF Review" policy, numbers in the range 128-240 are assigned on a "First Come First Served" basis, and numbers in the range 241-255 are reserved for "Private Use".
按照[RFC5226]中概述的政策，3-127范围内的数字根据“IETF审查”政策分配，128-240范围内的数字根据“先到先得”原则分配，241-255范围内的数字保留供“私人使用”。
This document benefited from discussions with Carol Iturralde and Anca Zamfir. Lou Berger, Adrian Farrel, and John Drake provided review and guidance, in particular on the usage of the Path_State_Removed flag and of the Notify message, both borrowed from [RFC3473]. We also thank Stephen Kent, Ken Carlberg, and Tim Polk for their valuable input and proposed enhancements. Finally, we thank Cullen Jennings, Magnus Westerlund, and Robert Sparks for stimulating the work on extensions maximizing the reservation span and facilitating migration from the Proxy model to the end-to-end RSVP model.
本文件得益于与卡罗尔·伊图拉尔德和安卡·赞菲尔的讨论。Lou Berger、Adrian Farrel和John Drake提供了审查和指导，特别是关于Path_State_Removed标志和Notify消息的使用，这两个文件均来自[RFC3473]。我们还感谢Stephen Kent、Ken Carlberg和Tim Polk的宝贵意见和改进建议。最后，我们感谢Cullen Jennings、Magnus Westerlund和Robert Sparks在扩展方面的工作，最大限度地扩大了保留范围，并促进了从代理模型到端到端RSVP模型的迁移。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[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月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]Herzog，S.，“策略控制的RSVP扩展”，RFC 2750，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月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181]Herzog，S.，“信号抢占优先权政策要素”，RFC 31812001年10月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230]Tschofenig，H.和R.Graveman，“RSVP安全属性”，RFC 4230，2005年12月。
[RFC5945] Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, "Resource Reservation Protocol (RSVP) Proxy Approaches", RFC 5945, October 2010.
[RFC5945]Le Faucheur，F.，Way，J.，Wing，D.，和A.Guillou，“资源预留协议（RSVP）代理方法”，RFC 59452010年10月。
[RTR-ALERT] Le Faucheur, F., "IP Router Alert Considerations and Usage", Work in Progress, October 2009.
[RTR-ALERT]Le Faucheur，F.，“IP路由器警报注意事项和使用”，正在进行的工作，2009年10月。
[SEC-GRP-KEY] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, June 2010.
[SEC-GRP-KEY]Behringer，M.和F.Le Faucheur，“RSVP安全的键控方法的适用性”，正在进行的工作，2010年6月。
Authors' Addresses
作者地址
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
Francois Le Faucheur Cisco Systems Greenside，400 Avenue de Roumanille Sophia Antipolis 06410法国电话：+33 4 97 23 26 19电子邮件：flefauch@cisco.com
Jukka Manner
Aalto University
Department of Communications and Networking (Comnet)
P.O. Box 13000
FIN-00076 Aalto
Finland
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Jukka Manner
Aalto University
Department of Communications and Networking (Comnet)
P.O. Box 13000
FIN-00076 Aalto
Finland
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Ashok Narayanan Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 United States EMail: ashokn@cisco.com
Ashok Narayanan Cisco Systems美国马萨诸塞州Boxborough市比弗布鲁克路300号邮编01719电子邮件：ashokn@cisco.com
Allan Guillou SFR 40-42 Quai du Point du Jour Boulogne-Billancourt 92659 France EMail: allan.guillou@sfr.com
Allan Guillou SFR 40-42法国布洛涅比兰古码头92659电子邮件：Allan。guillou@sfr.com
Hemant Malik Bharti Airtel, Ltd. 4th Floor, Plot No. 16 Udyog Vihar, Phase IV Gurgaon, 122015 India EMail: Hemant.Malik@airtel.in
Hemant Malik Bharti Airtel，Ltd.印度古尔冈四期Udyog Vihar 16号地块4楼邮编：122015电子邮件：Hemant。Malik@airtel.in