Network Working Group F. Le Faucheur
Request for Comments: 4860 B. Davie
Category: Standards Track Cisco Systems, Inc.
P. Bose
Lockheed Martin
C. Christou
M. Davenport
Booz Allen Hamilton
May 2007
Network Working Group F. Le Faucheur
Request for Comments: 4860 B. Davie
Category: Standards Track Cisco Systems, Inc.
P. Bose
Lockheed Martin
C. Christou
M. Davenport
Booz Allen Hamilton
May 2007
Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations
聚合资源保留协议（RSVP）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network.
RFC3175定义了聚合资源预留协议（RSVP）预留，允许在区分服务网络中为给定的每跳行为（PHB）或给定的PHB集从给定的源到给定的目的地预留资源。RFC3175还定义了在通过Diffserv云传输时如何将端到端RSVP保留聚合到此类聚合保留上。在某些情况下，同一源IP地址、目标IP地址和PHB（或一组PHB）需要多个此类聚合保留。但是，RFC 3175中定义的总保留不支持这一点。为了支持这一点，本文件定义了一种更灵活的聚合RSVP保留类型，称为通用聚合保留。可以为从给定源IP地址到给定目标IP地址的给定PHB（或一组PHB）建立多个这样的通用聚合保留。通用聚合保留可用于聚合端到端RSVP保留。本文件还规定了此类汇总的程序。通用聚合预订也可由连接到Diffserv网络的端系统直接端到端使用。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Related IETF Documents .....................................6
1.2. Organization of This Document ..............................6
1.3. Requirements Language ......................................7
2. Object Definition ...............................................7
2.1. SESSION Class ..............................................8
2.2. SESSION-OF-INTEREST (SOI) Class ...........................11
3. Processing Rules for Handling Generic Aggregate RSVP
Reservations ...................................................13
3.1. Extensions to Path and Resv Processing ....................13
4. Procedures for Aggregation over Generic Aggregate RSVP
Reservations ...................................................14
5. Example Usage Of Multiple Generic Aggregate Reservations
per PHB from a Given Aggregator to a Given Deaggregator ........19
6. Security Considerations ........................................21
7. IANA Considerations ............................................24
8. Acknowledgments ................................................25
9. Normative References ...........................................26
10. Informative References ........................................26
Appendix A. Example Signaling Flow ................................28
1. Introduction ....................................................3
1.1. Related IETF Documents .....................................6
1.2. Organization of This Document ..............................6
1.3. Requirements Language ......................................7
2. Object Definition ...............................................7
2.1. SESSION Class ..............................................8
2.2. SESSION-OF-INTEREST (SOI) Class ...........................11
3. Processing Rules for Handling Generic Aggregate RSVP
Reservations ...................................................13
3.1. Extensions to Path and Resv Processing ....................13
4. Procedures for Aggregation over Generic Aggregate RSVP
Reservations ...................................................14
5. Example Usage Of Multiple Generic Aggregate Reservations
per PHB from a Given Aggregator to a Given Deaggregator ........19
6. Security Considerations ........................................21
7. IANA Considerations ............................................24
8. Acknowledgments ................................................25
9. Normative References ...........................................26
10. Informative References ........................................26
Appendix A. Example Signaling Flow ................................28
[RSVP-AGG] defines RSVP aggregate reservations that allow resources to be reserved in a Diffserv network for a flow characterized by its 3-tuple <source IP address, destination IP address, Diffserv Code Point>.
[RSVP-AGG]定义RSVP聚合保留，允许在区分服务网络中为以其三元组<源IP地址、目标IP地址、区分服务代码点>为特征的流保留资源。
[RSVP-AGG] also defines the procedures for aggregation of end-to-end (E2E) RSVP reservations onto such aggregate reservations when transiting through a Diffserv cloud. Such aggregation is illustrated in Figure 1. This document reuses the terminology defined in [RSVP-AGG].
[RSVP-AGG]还定义了在通过Diffserv云传输时将端到端（E2E）RSVP保留聚合到此类聚合保留上的过程。图1说明了这种聚合。本文件重复使用[RSVP-AGG]中定义的术语。
--------------------------
/ Aggregation \
|----| | Region | |----|
H--| R |\ |-----| |------| /| R |-->H
H--| |\\| | |---| |---| | |//| |-->H
|----| \| | | I | | I | | |/ |----|
| Agg |======================>| Deag |
/| | | | | | | |\
H--------//| | |---| |---| | |\\-------->H
H--------/ |-----| |------| \-------->H
| |
\ /
--------------------------
--------------------------
/ Aggregation \
|----| | Region | |----|
H--| R |\ |-----| |------| /| R |-->H
H--| |\\| | |---| |---| | |//| |-->H
|----| \| | | I | | I | | |/ |----|
| Agg |======================>| Deag |
/| | | | | | | |\
H--------//| | |---| |---| | |\\-------->H
H--------/ |-----| |------| \-------->H
| |
\ /
--------------------------
H = Host requesting end-to-end RSVP reservations R = RSVP router Agg = Aggregator Deag = Deaggregator I = Interior Router
H=请求端到端RSVP保留的主机R=RSVP路由器Agg=聚合器Deag=解聚器I=内部路由器
--> = E2E RSVP reservation
==> = Aggregate RSVP reservation
--> = E2E RSVP reservation
==> = Aggregate RSVP reservation
Figure 1 : Aggregation of E2E Reservations over Aggregate RSVP Reservations
图1:E2E预订与RSVP预订合计
These aggregate reservations use a SESSION type specified in [RSVP-AGG] that contains the receiver (or Deaggregator) IP address and the Diffserv Code Point (DSCP) of the Per Hop Behavior (PHB) from which Diffserv resources are to be reserved. For example, in the case of IPv4, the SESSION object is specified as:
这些聚合保留使用[RSVP-AGG]中指定的会话类型，该会话类型包含要从中保留区分服务资源的每跳行为（PHB）的接收器（或解聚集器）IP地址和区分服务代码点（DSCP）。例如，在IPv4的情况下，会话对象被指定为：
o Class = SESSION, C-Type = RSVP-AGGREGATE-IP4
o 类别=会话，C类型=RSVP-AGGRATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
These aggregate reservations use SENDER_TEMPLATE and FILTER_SPEC types, specified in [RSVP-AGG], that contain only the sender (or Aggregator) IP address. For example, in the case of IPv4, the SENDER_TEMPLATE object is specified as:
这些聚合保留使用[RSVP-AGG]中指定的发送方\模板和筛选器\规范类型，这些类型仅包含发送方（或聚合方）IP地址。例如，在IPv4的情况下，发送方\模板对象被指定为：
o Class = SENDER_TEMPLATE, C-Type = RSVP-AGGREGATE-IP4
o 类别=发送方\模板，C-Type=RSVP-AGGRATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
Thus, it is possible to establish, from a given source IP address to a given destination IP address, separate such aggregate reservations for different PHBs (or different sets of PHBs). However, from a given source IP address to a given IP destination address, only a single [RSVP-AGG] aggregate reservation can be established for a given PHB (or given set of PHBs).
因此，可以从给定的源IP地址到给定的目标IP地址，为不同的phb（或不同的phb集合）建立分离的这样的聚集保留。但是，从给定的源IP地址到给定的IP目标地址，只能为给定的PHB（或给定的PHB集）建立单个[RSVP-AGG]聚合保留。
Situations have since been identified where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). One example is where E2E reservations using different preemption priorities (as per [RSVP-PREEMP]) need to be aggregated through a Diffserv cloud using the same PHB. Using multiple aggregate reservations for the same PHB allows enforcement of the different preemption priorities within the aggregation region. In turn, this allows more efficient management of the Diffserv resources, and in periods of resource shortage, this allows sustainment of a larger number of E2E reservations with higher preemption priorities.
此后确定了需要为同一源IP地址、目标IP地址和PHB（或一组PHB）提供多个此类聚合保留的情况。一个例子是，使用不同抢占优先级（根据[RSVP-PREEMEP]）的E2E预订需要通过使用相同PHB的Diffserv云进行聚合。对同一PHB使用多个聚合保留允许在聚合区域内强制执行不同的抢占优先级。反过来，这允许更有效地管理区分服务资源，并且在资源短缺期间，这允许以更高的抢占优先级维持更多的E2E预订。
For example, [SIG-NESTED] discusses in detail how end-to-end RSVP reservations can be established in a nested VPN environment through RSVP aggregation. In particular, [SIG-NESTED] describes how multiple parallel generic aggregate reservations (for the same PHB), each with different preemption priorities, can be used to efficiently support the preemption priorities of end-to-end reservations.
例如，[SIG-NESTED]详细讨论了如何通过RSVP聚合在嵌套VPN环境中建立端到端RSVP保留。特别地，[SIG-NESTED]描述了如何使用多个并行通用聚合保留（针对同一PHB），每个保留具有不同的抢占优先级，以有效地支持端到端保留的抢占优先级。
This document addresses this requirement for multiple aggregate reservations for the same PHB (or same set of PHBs), by defining a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservations. This is achieved primarily by adding the notions of a Virtual Destination Port and of an Extended Virtual Destination Port in the RSVP SESSION object.
本文件通过定义更灵活的聚合RSVP保留类型（称为通用聚合保留），解决了同一PHB（或同一组PHB）的多个聚合保留的要求。这主要是通过在RSVP会话对象中添加虚拟目标端口和扩展虚拟目标端口的概念来实现的。
The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] to address a similar requirement (albeit in a different context) for identification and demultiplexing of sessions beyond the IP destination address. This document reuses this notion from [RSVP-IPSEC] for identification and demultiplexing of generic aggregate sessions beyond the IP destination address and PHB. This allows multiple generic aggregate reservations to be established for a given PHB (or set of PHBs), from a given source IP address to a given destination IP address.
[RSVP-IPSEC]中引入了虚拟目标端口的概念，以解决IP目标地址之外的会话识别和解复用的类似要求（尽管在不同的上下文中）。本文档重用[RSVP-IPSEC]中的这一概念，用于识别和解复用IP目标地址和PHB之外的通用聚合会话。这允许为给定PHB（或一组PHB）从给定源IP地址到给定目标IP地址建立多个通用聚合保留。
[RSVP-TE] introduced the concept of an Extended Tunnel ID (in addition to the tunnel egress address and the Tunnel ID) in the SESSION object used to establish MPLS Traffic Engineering tunnels with RSVP. The Extended Tunnel ID provides a very convenient mechanism for the tunnel ingress node to narrow the scope of the session to the ingress-egress pair. The ingress node can achieve this by using one of its own IP addresses as a globally unique identifier and including it in the Extended Tunnel ID and therefore within the SESSION object. This document reuses this notion of Extended Tunnel ID from [RSVP-TE], simply renaming it Extended Virtual Destination Port. This provides a convenient mechanism to narrow the scope of a generic aggregate session to an Aggregator-Deaggregator pair.
[RSVP-TE]在会话对象中引入了扩展隧道ID的概念（除了隧道出口地址和隧道ID之外），用于使用RSVP建立MPLS流量工程隧道。扩展隧道ID为隧道入口节点提供了一种非常方便的机制，以将会话范围缩小到入口-出口对。入口节点可以通过使用其自己的IP地址之一作为全局唯一标识符并将其包括在扩展隧道ID中从而包括在会话对象中来实现这一点。本文档重用了[RSVP-TE]中扩展隧道ID的概念，只是将其重命名为扩展虚拟目标端口。这提供了一种方便的机制，将通用聚合会话的范围缩小到聚合器-解聚合器对。
The RSVP SESSION object for generic aggregate reservations uses the PHB Identification Code (PHB-ID) defined in [PHB-ID] to identify the PHB, or set of PHBs, from which the Diffserv resources are to be reserved. This is instead of using the Diffserv Code Point (DSCP) as per [RSVP-AGG]. Using the PHB-ID instead of the DSCP allows explicit indication of whether the Diffserv resources belong to a single PHB or to a set of PHBs. It also facilitates handling of situations where a generic aggregate reservation spans two (or more) Diffserv domains that use different DSCP values for the same Diffserv PHB (or set of PHBs) from which resources are reserved. This is because the PHB-ID allows conveying of the PHB (or set of PHBs) independently of what DSCP value(s) are used locally for that PHB (or set of PHBs).
通用聚合保留的RSVP会话对象使用[PHB-ID]中定义的PHB标识码（PHB-ID）来标识要从中保留区分服务资源的PHB或PHB集。这不是按照[RSVP-AGG]使用区分服务代码点（DSCP）。使用PHB-ID而不是DSCP可以明确指示区分服务资源是属于单个PHB还是属于一组PHB。它还有助于处理通用聚合保留跨越两个（或多个）区分服务域的情况，这两个域对保留资源的同一区分服务PHB（或一组PHB）使用不同的DSCP值。这是因为PHB-ID允许PHB（或PHB集）的传输独立于该PHB（或PHB集）本地使用的DSCP值。
The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. These procedures are based on those of [RSVP-AGG], and this document only specifies the differences from those.
通用聚合保留可用于聚合端到端RSVP保留。本文件还规定了此类汇总的程序。这些程序基于[RSVP-AGG]的程序，本文件仅规定了与这些程序的区别。
The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network.
通用聚合预订也可由连接到Diffserv网络的端系统直接端到端使用。
This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG] wherever applicable and only specifies the necessary extensions beyond [RSVP-AGG].
本文件主要基于[RSVP-AGG]。它在适用的情况下重用[RSVP-AGG]，并且仅指定[RSVP-AGG]之外的必要扩展。
The mechanisms defined in [BW-REDUC] allow an existing reservation to be reduced in allocated bandwidth by RSVP routers in lieu of tearing that reservation down. These mechanisms are applicable to the generic aggregate reservations defined in the present document.
[BW-Reduce]中定义的机制允许RSVP路由器在分配的带宽中减少现有保留，而不是删除该保留。这些机制适用于本文件所界定的一般性总保留。
[RSVP-TUNNEL] describes a general approach to running RSVP over various types of tunnels. One of these types of tunnel, referred to as a "type 2 tunnel", has some similarity with the generic aggregate reservations described in this document. The similarity stems from the fact that a single, aggregate reservation is made for the tunnel while many individual flows are carried over that tunnel. However, [RSVP-TUNNEL] does not address the use of Diffserv-based classification and scheduling in the core of a network (between tunnel endpoints), but rather relies on a UDP/IP tunnel header for classification. This is why [RSVP-AGG] required additional objects and procedures beyond those of [RSVP-TUNNEL]. Like [RSVP-AGG], this document also assumes the use of Diffserv-based classification and scheduling in the aggregation region and, thus, requires additional objects and procedures beyond those of [RSVP-TUNNEL].
[RSVP-TUNNEL]描述了在各种类型的隧道上运行RSVP的一般方法。其中一种类型的隧道称为“第2类隧道”，与本文件中描述的通用总保留区有一些相似之处。这种相似性源于这样一个事实，即当许多单独的流量通过隧道时，为隧道预留了一个单一的、聚合的预留。但是，[RSVP-TUNNEL]并未解决在网络核心（隧道端点之间）使用基于区分服务的分类和调度问题，而是依赖UDP/IP隧道头进行分类。这就是为什么[RSVP-AGG]需要[RSVP-TUNNEL]之外的其他对象和过程。与[RSVP-AGG]一样，本文档也假设在聚合区域中使用基于区分服务的分类和调度，因此需要[RSVP-TUNNEL]之外的其他对象和过程。
As explained earlier, this document reuses the notion of Virtual Destination Port from [RSVP-IPSEC] and the notion of Extended Tunnel ID from [RSVP-TE].
如前所述，本文档重用了[RSVP-IPSEC]中的虚拟目标端口概念和[RSVP-TE]中的扩展隧道ID概念。
Section 2 defines the new RSVP objects related to generic aggregate reservations and to aggregation of E2E reservations onto those. Section 3 describes the processing rules for handling of generic aggregate reservations. Section 4 specifies the procedures for aggregation of end-to-end RSVP reservations over generic aggregate RSVP reservations. Section 5 provides example usage of how the generic aggregate reservations may be used.
第2节定义了新的RSVP对象，这些对象与通用聚合保留和E2E保留的聚合相关。第3节描述了处理通用聚合保留的处理规则。第4节规定了将端到端RSVP保留汇总到通用汇总RSVP保留的程序。第5节提供了如何使用通用聚合保留的示例。
The Security Considerations and the IANA Considerations are discussed in Sections 6 and 7, respectively.
第6节和第7节分别讨论了安全注意事项和IANA注意事项。
Finally, Appendix A provides an example signaling flow that illustrates aggregation of E2E RSVP reservations onto generic aggregate RSVP reservations.
最后，附录A提供了一个示例信令流，说明了E2E RSVP保留的聚合到通用聚合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 RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
This document reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP-AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE, and RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG].
本文档重用[RSVP-AGG]中定义的RSVP-AGGRATE-IP4过滤器规范、RSVP-AGGRATE-IP6过滤器规范、RSVP-AGGRATE-IP4发送者模板和RSVP-AGGRATE-IP6发送者模板对象。
This document defines:
本文件规定：
- two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION) under the existing SESSION Class, and
- 现有会话类下的两个新对象（GENERIC-AGGREGATE-IP4会话和GENERIC-AGGREGATE-IP6会话），以及
- two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI) under a new SESSION-OF-INTEREST Class.
- 新会话感兴趣类下的两个新对象（GENERIC-AGG-IP4-SOI和GENERIC-AGG-IP6-SOI）。
Detailed description of these objects is provided below in this section.
本节下文提供了这些对象的详细说明。
The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION objects are applicable to all types of RSVP messages.
GENERIC-AGGREGATE-IP4会话和GENERIC-AGGREGATE-IP6会话对象适用于所有类型的RSVP消息。
This specification defines the use of the GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI objects in two circumstances:
本规范规定了GENERIC-AGG-IP4-SOI和GENERIC-AGG-IP6-SOI对象在两种情况下的使用：
- inside an E2E PathErr message that contains an error code of NEW-AGGREGATE-NEEDED in order to convey the session of a new generic aggregate reservation that needs to be established.
- 在E2E PathErr消息中，包含错误代码NEW-AGGREGATE-NEEDED，以便传递需要建立的新通用聚合保留的会话。
- inside an E2E Resv message in order to convey the session of the generic aggregate reservation onto which this E2E reservation needs to be mapped.
- 在E2E Resv消息中，以传递需要映射此E2E保留的通用聚合保留的会话。
Details of the corresponding procedures can be found in Section 4.
有关相应程序的详细信息，请参见第4节。
However, it is envisioned that the ability to signal, inside RSVP messages, the Session of another reservation (which has some relationship with the current RSVP reservation) might have some other applicability in the future. Thus, those objects have been specified in a more generic manner under a flexible SESSION-OF-INTEREST class.
然而，可以预见，在RSVP消息内向另一个保留（与当前RSVP保留有某种关系）的会话发送信号的能力在将来可能还有一些其他的适用性。因此，这些对象已在灵活的感兴趣会话类下以更通用的方式指定。
All the new objects defined in this document are optional with respect to RSVP so that general RSVP implementations that are not concerned with generic aggregate reservations do not have to support these objects. RSVP routers supporting generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION object or the GENERIC-AGGREGATE-IP6 SESSION object, respectively. RSVP routers supporting RSVP aggregation over generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGG-IP4-SOI object or GENERIC-AGG-IP6-SOI object, respectively.
本文档中定义的所有新对象对于RSVP都是可选的，因此与通用聚合保留无关的通用RSVP实现不必支持这些对象。支持通用聚合IPv4或IPv6保留的RSVP路由器必须分别支持generic-aggregate-IP4会话对象或generic-aggregate-IP6会话对象。通过通用聚合IPv4或IPv6保留支持RSVP聚合的RSVP路由器必须分别支持generic-AGG-IP4-SOI对象或generic-AGG-IP6-SOI对象。
o GENERIC-AGGREGATE-IP4 SESSION object: Class = 1 (SESSION) C-Type = 17
o GENERIC-AGGREGATE-IP4会话对象：Class=1（会话）C-Type=17
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
IPv4 DestAddress (IPv4 Destination Address)
IPv4目的地址（IPv4目的地址）
IPv4 address of the receiver (or Deaggregator).
接收器（或解聚集器）的IPv4地址。
Reserved
含蓄的
An 8-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt.
8位字段。传输时，所有位必须设置为0。接收时必须忽略此字段。
Flags
旗帜
An 8-bit field. The content and processing of this field are the same as for the Flags field of the IPv4/UDP SESSION object (see [RSVP]).
8位字段。此字段的内容和处理与IPv4/UDP会话对象的Flags字段相同（请参见[RSVP]）。
PHB-ID (Per Hop Behavior Identification Code)
PHB-ID（每跳行为识别码）
A 16-bit field containing the Per Hop Behavior Identification Code of the PHB, or of the set of PHBs, from which Diffserv resources are to be reserved. This field MUST be encoded as specified in Section 2 of [PHB-ID].
一个16位字段，包含PHB或PHB集合的每跳行为标识码，从中保留区分服务资源。该字段必须按照[PHB-ID]第2节的规定进行编码。
Reserved
含蓄的
A 16-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt.
16位字段。传输时，所有位必须设置为0。接收时必须忽略此字段。
VDstPort (Virtual Destination Port)
VDstPort（虚拟目标端口）
A 16-bit identifier used in the SESSION that remains constant over the life of the generic aggregate reservation.
会话中使用的16位标识符，在通用聚合保留的生命周期内保持不变。
Extended vDstPort (Extended Virtual Destination Port)
扩展vDstPort（扩展虚拟目标端口）
A 32-bit identifier used in the SESSION that remains constant over the life of the generic aggregate reservation. A sender (or Aggregator) that wishes to narrow the scope of a SESSION to the sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD place its IPv4 address here as a network unique identifier. A sender (or Aggregator) that wishes to use a common session with other senders (or Aggregators) in order to use a shared reservation across senders (or Aggregators) MUST set this field to all zeros.
会话中使用的32位标识符，在通用聚合保留的生命周期内保持不变。希望将会话范围缩小到发送方-接收方对（或聚合方-解聚合方对）的发送方（或聚合方）应将其IPv4地址作为网络唯一标识符放在此处。希望与其他发件人（或聚合器）使用公共会话以跨发件人（或聚合器）使用共享保留的发件人（或聚合器）必须将此字段设置为全零。
o GENERIC-AGGREGATE-IP6 SESSION object: Class = 1 (SESSION) C-Type = 18
o GENERIC-AGGREGATE-IP6会话对象：Class=1（会话）C-Type=18
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| |
+ +
| Extended vDstPort |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 16 25 26 31
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| |
+ +
| Extended vDstPort |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 16 25 26 31
IPv6 DestAddress (IPv6 Destination Address)
IPv6目标地址（IPv6目标地址）
IPv6 address of the receiver (or Deaggregator).
接收器（或解聚集器）的IPv6地址。
Reserved
含蓄的
An 8-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt.
8位字段。传输时，所有位必须设置为0。接收时必须忽略此字段。
Flags
旗帜
An 8-bit field. The content and processing of this field are the same as for the Flags field of the IPv6/UDP SESSION object (see [RSVP]).
8位字段。此字段的内容和处理与IPv6/UDP会话对象的Flags字段相同（请参见[RSVP]）。
PHB-ID (Per Hop Behavior Identification Code)
PHB-ID（每跳行为识别码）
A 16-bit field containing the Per Hop Behavior Identification Code of the PHB, or of the set of PHBs, from which Diffserv resources are to be reserved. This field MUST be encoded as specified in Section 2 of [PHB-ID].
一个16位字段，包含PHB或PHB集合的每跳行为标识码，从中保留区分服务资源。该字段必须按照[PHB-ID]第2节的规定进行编码。
Reserved
含蓄的
A 16-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt.
16位字段。传输时，所有位必须设置为0。接收时必须忽略此字段。
VDstPort (Virtual Destination Port)
VDstPort（虚拟目标端口）
A 16-bit identifier used in the SESSION that remains constant over the life of the generic aggregate reservation.
会话中使用的16位标识符，在通用聚合保留的生命周期内保持不变。
Extended vDstPort (Extended Virtual Destination Port)
扩展vDstPort（扩展虚拟目标端口）
A 128-bit identifier used in the SESSION that remains constant over the life of the generic aggregate reservation. A sender (or Aggregator) that wishes to narrow the scope of a SESSION to the sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD place its IPv6 address here as a network unique identifier. A sender (or Aggregator) that wishes to use a common session with other senders (or Aggregators) in order to use a shared reservation across senders (or Aggregators) MUST set this field to all zeros.
会话中使用的128位标识符，在通用聚合保留的生命周期内保持不变。希望将会话范围缩小到发送方-接收方对（或聚合方-解聚合方对）的发送方（或聚合方）应将其IPv6地址作为网络唯一标识符放在此处。希望与其他发件人（或聚合器）使用公共会话以跨发件人（或聚合器）使用共享保留的发件人（或聚合器）必须将此字段设置为全零。
o GENERIC-AGG-IP4-SOI object: Class = 132 C-Type = 1
o GENERIC-AGG-IP4-SOI对象：类=132 C-Type=1
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP4 SESSION Object //
| |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP4 SESSION Object //
| |
+-------------+-------------+-------------+-------------+
Content of a GENERIC-AGGREGATE-IP4 SESSION Object:
GENERIC-AGGREGATE-IP4会话对象的内容：
This field contains a copy of the SESSION object of the session that is of interest for the reservation. In the case of a GENERIC-AGG-IP4-SOI, the session of interest conveyed in this field is a GENERIC-AGGREGATE-IP4 SESSION.
此字段包含保留感兴趣的会话的会话对象的副本。在GENERIC-AGG-IP4-SOI的情况下，本领域中传达的感兴趣的会话是GENERIC-AGGREGATE-IP4会话。
o GENERIC-AGG-IP6-SOI object: Class = 132 C-Type = 2
o GENERIC-AGG-IP6-SOI对象：类=132 C-Type=2
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP6- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP6 SESSION Object //
| |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP6- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP6 SESSION Object //
| |
+-------------+-------------+-------------+-------------+
Content of a GENERIC-AGGREGATE-IP6 SESSION Object:
GENERIC-AGGREGATE-IP6会话对象的内容：
This field contains a copy of the SESSION object of the session that is of interest for the reservation. In the case of a GENERIC-AGG-IP6-SOI, the session of interest conveyed in this field is a GENERIC-AGGREGATE-IP6 SESSION.
此字段包含保留感兴趣的会话的会话对象的副本。在GENERIC-AGG-IP6-SOI的情况下，本领域中传达的感兴趣的会话是GENERIC-AGGREGATE-IP6会话。
For example, if a SESSION-OF-INTEREST object is used inside an E2E Resv message (as per the procedures defined in Section 4) to indicate which generic aggregate IPv4 session the E2E reservation is to be mapped onto, then the GENERIC-AGG-IP4-SOI object will be used, and it will be encoded like this:
例如，如果在E2E Resv消息中使用感兴趣的会话对象（按照第4节中定义的过程）来指示E2E保留将映射到哪个通用聚合IPv4会话，则将使用generic-AGG-IP4-SOI对象，并将其编码如下：
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+--+----------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+--+----------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
Note that a SESSION-OF-INTEREST object is not a SESSION object in itself. It does not replace the SESSION object in RSVP messages. It does not modify the usage of the SESSION object in RSVP messages. It simply allows conveying the Session of another RSVP reservation inside RSVP signaling messages, for some particular purposes. In the context of this document, it is used to convey, inside an E2E RSVP
请注意，感兴趣的会话对象本身不是会话对象。它不会替换RSVP消息中的会话对象。它不会修改RSVP消息中会话对象的用法。它只允许在RSVP信令消息中传输另一个RSVP保留的会话，用于某些特定目的。在本文件的上下文中，它用于在E2E RSVP内传达
message pertaining to an end-to-end reservation, the Session of a generic aggregate reservation associated with the E2E reservation. Details for the corresponding procedures are specified in Section 4.
与端到端保留有关的消息，即与E2E保留关联的通用聚合保留会话。第4节规定了相应程序的详细信息。
This section presents extensions to the processing of RSVP messages required by [RSVP] and presented in [RSVP-PROCESS]. These extensions are required in order to properly process the GENERIC-AGGREGATE-IP4 or GENERIC-AGGREGATE-IP6 SESSION object and the RSVP-AGGREGATE-IP4 or RSVP-AGGREGATE-IP6 FILTER_SPEC object. Values for referenced error codes can be found in [RSVP]. As with the other RSVP documents, values for internally reported (API) errors are not defined.
本节介绍了[RSVP]所需并在[RSVP-PROCESS]中介绍的RSVP消息处理的扩展。为了正确处理GENERIC-AGGREGATE-IP4或GENERIC-AGGREGATE-IP6会话对象以及RSVP-AGGREGATE-IP4或RSVP-AGGREGATE-IP6筛选器_SPEC对象，需要这些扩展。参考错误代码的值可在[RSVP]中找到。与其他RSVP文档一样，未定义内部报告（API）错误的值。
When referring to the new GENERIC-AGGREGATE-IP4 and GENERIC-AGGREGATE-IP6 SESSION objects, IP version will not be included, and they will be referred to simply as GENERIC-AGGREGATE SESSION, unless a specific distinction between IPv4 and IPv6 is being made.
当提及新的GENERIC-AGGREGATE-IP4和GENERIC-AGGREGATE-IP6会话对象时，将不包括IP版本，它们将被简称为GENERIC-AGGREGATE会话，除非对IPv4和IPv6进行了具体区分。
When referring to the [RSVP-AGG] RSVP-AGGREGATE-IP4 and RSVP-AGGREGATE-IP6 SESSION, FILTER_SPEC, and SENDER_TEMPLATE objects, IP version will not be included, and they will be referred to simply as RSVP-AGGREGATE, unless a specific distinction between IPv4 and IPv6 is being made.
当提及[RSVP-AGG]RSVP-AGGRATE-IP4和RSVP-AGGRATE-IP6会话、筛选器规范和发送者模板对象时，将不包括IP版本，它们将被简称为RSVP-AGGRATE，除非IPv4和IPv6之间有具体区别。
The following PATH message processing changes are defined:
定义了以下路径消息处理更改：
o When a session is defined using the GENERIC-AGGREGATE SESSION object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may be used. When this condition is violated in a PATH message received by an RSVP end-station, the RSVP end-station SHOULD report a "Conflicting C-Type" API error to the application. When this condition is violated in a PATH message received by an RSVP router, the RSVP router MUST consider this as a message formatting error.
o 当使用GENERIC-AGGREGATE session对象定义会话时，只能使用[RSVP-AGG]RSVP-AGGREGATE SENDER_模板。当RSVP端站收到的PATH消息违反此条件时，RSVP端站应向应用程序报告“冲突的C-Type”API错误。当此条件在RSVP路由器接收到的路径消息中被违反时，RSVP路由器必须将其视为消息格式错误。
o For PATH messages that contain the GENERIC-AGGREGATE SESSION object, the VDstPort value, the Extended VDstPort value, and the PHB-ID value should be recorded (in addition to the destination/Deaggregator address and source/Aggregator address). These values form part of the recorded state of the session. The PHB-ID may need to be passed to traffic control; however the vDstPort and Extended VDstPort are not passed to traffic control since they do not appear inside the data packets of the corresponding reservation.
o 对于包含GENERIC-AGGREGATE会话对象的路径消息，应记录VDstPort值、扩展VDstPort值和PHB-ID值（以及目标/解聚集器地址和源/聚集器地址）。这些值构成会话记录状态的一部分。PHB-ID可能需要传递给交通管制部门；但是，vDstPort和扩展vDstPort不会传递给流量控制，因为它们不会出现在相应保留的数据包中。
The following changes to RESV message processing are defined:
定义了对RESV消息处理的以下更改：
o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE FILTER_SPEC, the session MUST be defined using either the RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the GENERIC-AGGREGATE SESSION object (as per this document). If this condition is not met, an RSVP router or end-station MUST consider that there is a message formatting error.
o 当RESV消息包含[RSVP-AGG]RSVP-AGGREGATE筛选器_SPEC时，必须使用RSVP-AGGREGATE会话对象（根据[RSVP-AGG]）或GENERIC-AGGREGATE会话对象（根据本文档）定义会话。如果不满足此条件，RSVP路由器或终端站必须考虑存在消息格式化错误。
o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION type is GENERIC-AGGREGATE, each node uses data classifiers as per the following:
o 当使用RSVP-AGGRATE FILTER_SPEC且会话类型为GENERIC-AGGRATE时，每个节点使用数据分类器，如下所示：
* to perform Diffserv classification the node MUST rely on the Diffserv data classifier based on the DSCP only. The relevant DSCP value(s) are those that are associated with the PHB-ID of the generic aggregate reservation.
* 要执行区分服务分类，节点必须仅依赖基于DSCP的区分服务数据分类器。相关DSCP值是与通用聚合保留的PHB-ID关联的值。
* If the node also needs to perform fine-grain classification (for example, to perform fine-grain input policing at a trust boundary) then the node MUST create a data classifier described by the 3-tuple <DestAddress, SrcAddress, DSCP>.
* 如果节点还需要执行细粒度分类（例如，在信任边界执行细粒度输入策略），则节点必须创建由3元组<DestAddress，SrcAddress，DSCP>描述的数据分类器。
The relevant DSCP value(s) are those that are associated with the PHB-ID of the generic aggregate reservation.
相关DSCP值是与通用聚合保留的PHB-ID关联的值。
Note that if multiple generic aggregate reservations are established with different Virtual Destination Ports (and/or different Extended Virtual Destination Ports) but with the same <DestAddress, SrcAddress, PHB-ID>, then those cannot be distinguished by the classifier. If the router is using the classifier for policing purposes, the router will therefore police those together and MUST program the policing rate to the sum of the reserved rate across all the corresponding reservations.
请注意，如果使用不同的虚拟目标端口（和/或不同的扩展虚拟目标端口）但使用相同的<DestAddress，SrcAddress，PHB-ID>建立多个通用聚合保留，则分类器无法区分这些保留。如果路由器使用分类器进行管理，那么路由器将同时管理这些分类器，并且必须将管理速率编程为所有相应保留的保留速率之和。
The procedures for aggregation of E2E reservations over generic aggregate RSVP reservations are the same as the procedures specified in [RSVP-AGG] with the exceptions of the procedure changes listed in this section.
除了本节中列出的程序变更外，E2E保留汇总至通用汇总RSVP保留的程序与[RSVP-AGG]中规定的程序相同。
As specified in [RSVP-AGG], the Deaggregator is responsible for mapping a given E2E reservation on a given aggregate reservation. The Deaggregator requests establishment of a new aggregate reservation by sending to the Aggregator an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the
如[RSVP-AGG]中所述，解聚集器负责将给定的E2E保留映射到给定的聚合保留。解聚集器通过向聚合器发送错误代码为new-aggregate-Required的E2E PathErr消息，请求建立新的聚合保留。在[RSVP-AGG]中
Deaggregator conveys the DSCP of the new requested aggregate reservation by including a DCLASS Object in the E2E PathErr and encoding the corresponding DSCP inside. This document modifies and extends this procedure. The Deaggregator MUST include in the E2E PathErr message a SESSION-OF-INTEREST object that contains the GENERIC-AGGREGATE SESSION to be used for establishment of the requested generic aggregate reservation. Since this GENERIC-AGGREGATE SESSION contains the PHB-ID, the DCLASS object need not be included in the PathErr message.
Deaggregator通过在E2E PathErr中包含DCLASS对象并在其中编码相应的DSCP来传递新请求的聚合保留的DSCP。本文档修改并扩展了此过程。解聚集器必须在E2E PathErr消息中包含一个SESSION-OF-INTEREST对象，该对象包含用于建立请求的通用聚合保留的通用聚合会话。由于此泛型聚合会话包含PHB-ID，因此无需在PathErr消息中包含DCLASS对象。
Note that the Deaggregator can easily ensure that different Aggregators use different sessions for their Aggregate Path towards a given Deaggregator. This is because the Deaggregator can easily select VDstPort and/or Extended VDstPort numbers which are different for each Aggregator (for example, by using the Aggregator address as the Extended VDstPort) and can communicate those inside the GENERIC-AGGREGATE SESSION included in the SESSION-OF-INTEREST object. This provides an easy solution to establish separate reservations from every Aggregator to a given Deaggregator. Conversely, if reservation sharing were needed across multiple Aggregators, the Deaggregator could facilitate this by allocating the same VDstPort and Extended VDstPort to the multiple Aggregators, and thus including the same GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST object in the E2E PathErr messages sent to these Aggregators. The Aggregators could then all establish an Aggregate Path with the same GENERIC-AGGREGATE SESSION.
注意，Deaggregator可以很容易地确保不同的聚合器使用不同的会话作为其指向给定Deaggregator的聚合路径。这是因为解聚集器可以很容易地选择VDstPort和/或扩展VDstPort编号，这些编号对于每个聚合器都是不同的（例如，通过使用聚合器地址作为扩展VDstPort），并且可以在会话相关对象中包含的通用聚合会话内进行通信。这提供了一个简单的解决方案，可以从每个聚合器到给定的解聚合器建立单独的保留。相反，如果需要跨多个聚合器共享保留，则解聚合器可以通过将相同的VDstPort和扩展的VDstPort分配给多个聚合器来促进这一点，从而在发送给这些聚合器的E2E PathErr消息中的感兴趣的会话对象内包含相同的通用聚合会话。然后，聚合器都可以使用相同的泛型聚合会话建立聚合路径。
Therefore, various sharing scenarios can easily be supported. Policies followed by the Deaggregator to determine which Aggregators need shared or separate reservations are beyond the scope of this document.
因此，可以轻松支持各种共享场景。解聚集器为确定哪些聚集器需要共享或单独保留而遵循的策略超出了本文档的范围。
The Deaggregator MAY also include in the E2E PathErr message (with an error code of NEW-AGGREGATE-NEEDED) additional RSVP objects which are to be used for establishment of the newly needed generic aggregate reservation. For example, the Deaggregator MAY include in the E2E PathErr an RSVP Signaled Preemption Priority Policy Element (as specified in [RSVP-PREEMP]).
解聚集器还可以在E2E PathErr消息（错误代码为NEW-AGGREGATE-Required）中包括用于建立新需要的通用聚集保留的额外RSVP对象。例如，解聚集器可在E2E路径中包括RSVP信号抢占优先级策略元素（如[RSVP-PREEMEP]中所指定）。
The [RSVP-AGG] procedures for processing of an E2E PathErr message received with an error code of NEW-AGGREGATE-NEEDED by the Aggregator are extended correspondingly. On receipt of such a message containing a SESSION-OF-INTEREST object, the Aggregator MUST trigger establishment of a generic aggregate reservation. In particular, it MUST start sending aggregate Path messages with the GENERIC-AGGREGATE SESSION found in the received SESSION-OF-INTEREST object. When an RSVP Signaled Preemption Priority Policy Element is contained in the received E2E PathErr message, the Aggregator MUST include this object
用于处理接收到的E2E PathErr消息的[RSVP-AGG]过程，以及聚合器所需的错误代码NEW-AGGREGATE-。在收到包含感兴趣会话对象的消息后，聚合器必须触发建立通用聚合保留。特别是，它必须开始发送聚合路径消息，其中包含在接收的感兴趣会话对象中找到的GENERIC-aggregate会话。当接收到的E2E PathErr消息中包含RSVP信号抢占优先级策略元素时，聚合器必须包含此对象
in the Aggregate Path for the corresponding generic aggregate reservation. When other additional objects are contained in the received E2E PathErr message and those can be unambiguously interpreted as related to the new needed generic aggregate reservation (as opposed to related to the E2E reservation), the Aggregator SHOULD include those in the Aggregate Path for the corresponding generic aggregate reservation. The Aggregator MUST use as the Source Address (i.e., as the Aggregator Address in the Sender-Template) for the generic aggregate reservation, the address it uses to identify itself as the PHOP (RSVP previous hop) when forwarding the E2E Path messages corresponding to the E2E PathErr message.
在相应的通用聚合保留的聚合路径中。当接收到的E2E PathErr消息中包含其他附加对象，并且这些对象可以明确地解释为与新需要的通用聚合保留相关（与E2E保留相关相反），聚合器应将这些对象包括在相应通用聚合保留的聚合路径中。聚合器必须用作通用聚合保留的源地址（即发送方模板中的聚合器地址），该地址用于在转发与E2E PathErr消息对应的E2E路径消息时将自身标识为PHOP（RSVP上一跳）的地址。
The Deaggregator follows the same procedures as described in [RSVP-AGG] for establishing, maintaining and clearing the aggregate Resv state. However, a Deaggregator behaving according to the present specification MUST use the generic aggregate reservations and hence use the GENERIC-AGGREGATE SESSION specified earlier in this document.
解集器遵循[RSVP-AGG]中所述的相同程序来建立、维护和清除聚合Resv状态。但是，根据本规范运行的解聚集器必须使用通用聚合保留，因此必须使用本文档前面指定的通用聚合会话。
This document also modifies the procedures of [RSVP-AGG] related to exchange of E2E Resv messages between Deaggregator and Aggregator. The Deaggregator MUST include the new SESSION-OF-INTEREST object in the E2E Resv message, in order to indicate to the Aggregator the generic aggregate session to map a given E2E reservation onto. Again, since the GENERIC-AGGREGATE SESSION (included in the SESSION-OF-INTEREST object) contains the PHB-ID, the DCLASS object need not be included in the E2E Resv message. The Aggregator MUST interpret the SESSION-OF-INTEREST object in the E2E Resv as indicating which generic aggregate reservation session the corresponding E2E reservation is mapped onto. The Aggregator MUST not include the SESSION-OF-INTEREST object when sending an E2E Resv upstream towards the sender.
本文件还修改了[RSVP-AGG]中与解聚集器和聚集器之间E2E Resv消息交换相关的程序。解聚合器必须在E2E Resv消息中包含新的感兴趣会话对象，以便向聚合器指示要将给定E2E保留映射到的通用聚合会话。同样，由于GENERIC-AGGREGATE会话（包括在SESSION-OF-INTEREST对象中）包含PHB-ID，因此无需将DCLASS对象包括在E2E Resv消息中。聚合器必须将E2E Resv中的感兴趣会话对象解释为指示对应E2E保留映射到哪个通用聚合保留会话。当向发送方向上游发送E2E Resv时，聚合器不得包含感兴趣的会话对象。
Based on relevant policy, the Deaggregator may decide at some point that an aggregate reservation is no longer needed and should be torn down. In that case, the Deaggregator MUST send an aggregate ResvTear. On receipt of the aggregate ResvTear, the Aggregator SHOULD send an aggregate PathTear (unless the relevant policy instructs the Aggregator to do otherwise or to wait for some time before doing so, for example in order to speed up potential re-establishment of the aggregate reservation in the future).
根据相关政策，解聚集器可能会在某个时候决定不再需要聚集保留，并应将其拆除。在这种情况下，解聚集器必须发送聚合ResvTear。收到聚合ResvTear后，聚合器应发送聚合PathTear（除非相关策略指示聚合器执行其他操作或在执行此操作之前等待一段时间，例如为了加快将来可能重新建立聚合保留）。
[RSVP-AGG] describes how the Aggregator and Deaggregator can communicate their respective identities to each other. For example, the Aggregator includes one of its IP addresses in the RSVP HOP object in the E2E Path that is transmitted downstream and received by the Deaggregator once it traversed the aggregation region. Similarly, the Deaggregator identifies itself to the Aggregator by
[RSVP-AGG]描述聚合器和解聚合器如何相互通信各自的身份。例如，在E2VP的聚合器中，该对象的下游地址一旦被重新聚合器接收，就会被重新聚合器的下游地址所覆盖。类似地，解聚集器通过
including one of its IP addresses in various fields, including the ERROR SPECIFICATION of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error Code) and in the RSVP HOP object of the E2E Resv message. However, [RSVP-AGG] does not discuss which IP addresses are to be selected by the Aggregator and Deaggregator for such purposes. Because these addresses are intended to identify the Aggregator and Deaggregator and not to identify any specific interface on these devices, this document RECOMMENDS that the Aggregator and Deaggregator SHOULD use interface-independent addresses (for example, a loopback address) whenever they communicate their respective identities to each other. This ensures that respective identification of the Aggregator and Deaggregator is not impacted by any interface state change on these devices. In turn, this results in more stable operations and considerably reduced RSVP signaling in the aggregation region. For example, if interface-independent addresses are used by the Aggregator and the Deaggregator, then a failure of an interface on these devices may simply result in the rerouting of a given generic aggregate reservation, but will not result in the generic aggregate reservation having to be torn down and another one established. Moreover, it will not result in a change of mapping of E2E reservations on generic aggregate reservations (assuming the Aggregator and Deaggregator still have reachability after the failure, and the Aggregator and Deaggregator are still on the shortest path to the destination).
在各个字段中包括其IP地址之一，包括E2E PathErr消息的错误规范（包含新的聚合所需错误代码）和E2E Resv消息的RSVP HOP对象。但是，[RSVP-AGG]没有讨论聚合器和解聚合器为此目的选择哪些IP地址。由于这些地址旨在识别聚合器和解聚合器，而不是识别这些设备上的任何特定接口，因此本文档建议聚合器和解聚合器应使用独立于接口的地址（例如，环回地址）无论何时，当他们相互交流各自的身份时。这确保聚合器和解聚合器的各自标识不受这些设备上任何接口状态更改的影响。反过来，这将导致更稳定的操作，并大大减少聚合区域中的RSVP信令。例如，如果聚合器和解聚合器使用与接口无关的地址，则这些设备上的接口故障可能只会导致重新路由给定的通用聚合保留，但不会导致必须拆除通用聚合保留并建立另一个通用聚合保留。此外，它不会导致E2E保留在通用聚合保留上的映射发生变化（假设聚合器和解聚合器在故障后仍然具有可达性，并且聚合器和解聚合器仍然位于到目的地的最短路径上）。
However, when identifying themselves to real RSVP neighbors (i.e., neighbors that are not on the other side of the aggregation region), the Aggregator and Deaggregator SHOULD continue using interface-dependent addresses as per regular [RSVP] procedures. This applies for example when the Aggregator identifies itself downstream as a PHOP for the generic aggregate reservation or identifies itself upstream as a NHOP (RSVP next hop) for an E2E reservation. This also applies when the Deaggregator identifies itself downstream as a PHOP for the E2E reservation or identifies itself upstream as a NHOP for the generic aggregate reservation. As part of the processing of generic aggregate reservations, interior routers (i.e., routers within the aggregation region) SHOULD continue using interface-dependent addresses as per regular [RSVP] procedures.
但是，当将自己标识为真实的RSVP邻居（即不在聚合区域另一侧的邻居）时，聚合器和解聚合器应按照常规[RSVP]过程继续使用依赖于接口的地址。例如，当聚合器将其自身下游标识为通用聚合保留的PHOP，或将其自身上游标识为E2E保留的NHOP（RSVP下一跳）时，这适用。当解聚集器将自身下游标识为E2E保留的PHOP或将自身上游标识为通用聚集保留的NHOP时，这也适用。作为通用聚合保留处理的一部分，内部路由器（即聚合区域内的路由器）应按照常规[RSVP]程序继续使用依赖于接口的地址。
More generally, within the aggregation region (i.e., between Aggregator and Deaggregator) the operation of RSVP should be modeled with the notion that E2E reservations are mapped to aggregate reservations and are no longer tied to physical interfaces (as was the case with regular RSVP). However, generic aggregate reservations (within the aggregation region) as well as E2E reservations (outside the aggregation region) retain the model of regular RVSP and remain tied to physical interfaces.
更一般地说，在聚合区域内（即聚合器和解聚合器之间），RSVP的操作应采用以下概念建模：E2E保留映射到聚合保留，并且不再绑定到物理接口（与常规RSVP的情况相同）。但是，通用聚合保留（聚合区域内）以及E2E保留（聚合区域外）保留了常规RVSP的模型，并与物理接口保持联系。
As discussed above, generic aggregate reservations may be established edge-to-edge as a result of the establishment of E2E reservations (from outside the aggregation region) that are to be aggregated over the aggregation region. However, generic aggregate reservations may also be used end-to-end by end-systems directly attached to a Diffserv domain, such as Public Switched Telephone Network (PSTN) gateways. In that case, the generic aggregate reservations may be established by the end-systems in response to application-level triggers such as voice call signaling. Alternatively, generic aggregate reservations may also be used edge-to-edge to manage bandwidth in a Diffserv cloud even if RSVP is not used end-to-end. A simple example of such a usage would be the static configuration of a generic aggregate reservation for a certain bandwidth for traffic from an ingress (Aggregator) router to an egress (Deaggregator) router.
如上所述，由于要在聚合区域上聚合的E2E保留（来自聚合区域之外）的建立，可以边到边地建立通用聚合保留。然而，通用聚合预约也可以用于直接连接到区分服务域的端到端系统，例如公共交换电话网（PSTN）网关。在这种情况下，终端系统可响应于诸如语音呼叫信令之类的应用级触发来建立通用聚合预约。或者，即使没有端到端使用RSVP，也可以使用通用聚合保留来管理区分服务云中的带宽。这种用法的一个简单示例是针对从入口（聚合器）路由器到出口（解聚合器）路由器的流量的特定带宽的通用聚合保留的静态配置。
In this case, the establishment of the generic aggregate reservations is controlled by configuration on the Aggregator and on the Deaggregator. Configuration on the Aggregator triggers generation of the aggregate Path message and provides sufficient information to the Aggregator to derive the content of the GENERIC-AGGREGATE SESSION object. This would typically include Deaggregator IP address, PHB-ID and possibly VDstPort. Configuration on the Deaggregator would instruct the Deaggregator to respond to a received generic aggregate Path message and would provide sufficient information to the Deaggregator to control the reservation. This may include bandwidth to be reserved by the Deaggregator (for a given <Deaggregator, PHB-ID, VDstPort> tuple).
在这种情况下，通用聚合保留的建立由聚合器和解聚合器上的配置控制。聚合器上的配置将触发聚合路径消息的生成，并向聚合器提供足够的信息以派生GENERIC-aggregate会话对象的内容。这通常包括解聚集器IP地址、PHB-ID以及可能的VDstPort。解聚集器上的配置将指示解聚集器响应接收到的通用聚合路径消息，并将向解聚集器提供足够的信息以控制保留。这可能包括解聚集器保留的带宽（对于给定的<Deaggregator，PHB-ID，VDstPort>tuple）。
In the absence of E2E microflow reservations, the Aggregator can use a variety of policies to set the DSCP of packets passing into the aggregation region and how they are mapped onto generic aggregate reservations, thus determining whether they gain access to the resources reserved by the aggregate reservation. These policies are a matter of local configuration, as is typical for a device at the edge of a Diffserv cloud.
在没有E2E微流保留的情况下，聚合器可以使用各种策略来设置传递到聚合区域的分组的DSCP以及它们如何映射到通用聚合保留，从而确定它们是否获得对聚合保留保留的资源的访问。这些策略是本地配置的问题，这是Diffserv云边缘设备的典型情况。
5. Example Usage Of Multiple Generic Aggregate Reservations per PHB from a Given Aggregator to a Given Deaggregator
5. 从给定聚合器到给定解聚合器的每个PHB多个通用聚合保留的示例使用
Let us consider the environment depicted in Figure 2 below. RSVP aggregation is used to support E2E reservations between Cloud-1, Cloud-2, and Cloud-3.
让我们考虑下面的图2所示的环境。RSVP聚合用于支持Cloud-1、Cloud-2和Cloud-3之间的E2E预订。
I----------I I----------I
I Cloud-1 I I Cloud-2 I
I----------I I----------I
| |
Agg-Deag-1------------ Agg-Deag-2
/ \
/ Aggregation |
| Region |
| |
| ---/
\ /
\Agg-Deag-3---------/
|
I----------I
I Cloud-3 I
I----------I
I----------I I----------I
I Cloud-1 I I Cloud-2 I
I----------I I----------I
| |
Agg-Deag-1------------ Agg-Deag-2
/ \
/ Aggregation |
| Region |
| |
| ---/
\ /
\Agg-Deag-3---------/
|
I----------I
I Cloud-3 I
I----------I
Figure 2 : Example Usage of Generic Aggregate IP Reservations
图2：通用聚合IP保留的示例用法
Let us assume that:
让我们假设：
o The E2E reservations from Cloud-1 to Cloud-3 have a preemption of either P1 or P2.
o 从Cloud-1到Cloud-3的E2E保留具有P1或P2的抢占权。
o The E2E reservations from Cloud-2 to Cloud-3 have a preemption of either P1 or P2.
o 从Cloud-2到Cloud-3的E2E预订具有P1或P2的抢占权。
o The E2E reservations are only for Voice (which needs to be treated in the aggregation region using the EF -Expedited Forwarding- PHB).
o E2E预订仅用于语音（需要使用EF-加速转发-PHB在聚合区域中进行处理）。
o Traffic from the E2E reservations is encapsulated in aggregate IP reservations from Aggregator to Deaggregator using Generic Routing Encapsulation [GRE] tunneling.
o 使用通用路由封装[GRE]隧道将来自E2E预留的流量封装在从聚合器到解聚合器的聚合IP预留中。
Then, the following generic aggregate RSVP reservations may be established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end-to-end RSVP reservations:
然后，可以从Agg-Deag-1到Agg-Deag-3建立以下通用聚合RSVP预留，以聚合端到端RSVP预留：
(1) A first generic aggregate reservation for aggregation of Voice reservations from Cloud-1 to Cloud-3 requiring use of P1:
(1) 第一个通用聚合保留，用于将需要使用P1的语音保留从Cloud-1聚合到Cloud-3：
* GENERIC-AGGREGATE-IP4 SESSION: IPv4 DestAddress = Agg-Deag-3 vDstPort = V1 PHB-ID = EF Extended VDstPort = Agg-Deag-1
* GENERIC-AGGREGATE-IP4会话：IPv4 DestAddress=Agg-Deag-3 vDstPort=V1 PHB-ID=EF Extended vDstPort=Agg-Deag-1
* STYLE = FF or SE
* 样式=FF或SE
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-1
* IPv4/GPI筛选器\u规范：IPv4 SrcAddress=Agg-Deag-1
* POLICY_DATA (PREEMPTION_PRI) = P1
* 策略数据（抢占优先级）=P1
(2) A second generic aggregate reservation for aggregation of Voice reservations from Cloud-1 to Cloud-3 requiring use of P2:
(2) 第二个通用聚合保留，用于将需要使用P2的语音保留从Cloud-1聚合到Cloud-3：
* GENERIC-AGGREGATE-IP4 SESSION: IPv4 DestAddress = Agg-Deag-3 vDstPort = V2 PHB-ID = EF Extended VDstPort = Agg-Deag-1
* GENERIC-AGGREGATE-IP4会话：IPv4 DestAddress=Agg-Deag-3 vDstPort=V2 PHB-ID=EF Extended vDstPort=Agg-Deag-1
* STYLE = FF or SE
* 样式=FF或SE
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-1
* IPv4/GPI筛选器\u规范：IPv4 SrcAddress=Agg-Deag-1
* POLICY_DATA (PREEMPTION_PRI) = P2
* 策略数据（抢占优先级）=P2
where V1 and V2 are arbitrary VDstPort values picked by Agg-Deag-3.
其中V1和V2是Agg-Deag-3拾取的任意VDstPort值。
The following generic aggregate RSVP reservations may be established from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-to-end RSVP reservations:
可以从Agg-Deag-2到Agg-Deag-3建立以下通用聚合RSVP预留，以聚合端到端RSVP预留：
(3) A third generic aggregate reservation for aggregation of Voice reservations from Cloud-2 to Cloud-3 requiring use of P1:
(3) 第三个通用聚合保留，用于将需要使用P1的语音保留从Cloud-2聚合到Cloud-3：
* GENERIC-AGGREGATE-IP4 SESSION: IPv4 DestAddress = Agg-Deag-3 vDstPort = V3 PHB-ID = EF Extended VDstPort = Agg-Deag-2
* GENERIC-AGGREGATE-IP4会话：IPv4 DestAddress=Agg-Deag-3 vDstPort=V3 PHB-ID=EF Extended vDstPort=Agg-Deag-2
* STYLE = FF or SE
* 样式=FF或SE
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-2
* IPv4/GPI筛选器\u规范：IPv4 SrcAddress=Agg-Deag-2
* POLICY_DATA (PREEMPTION_PRI) = P1
* 策略数据（抢占优先级）=P1
(4) A fourth generic aggregate reservation for aggregation of Voice reservations from Cloud-2 to Cloud-3 requiring use of P2:
(4) 第四个通用聚合保留，用于将需要使用P2的语音保留从Cloud-2聚合到Cloud-3：
* GENERIC-AGGREGATE-IP4 SESSION: IPv4 DestAddress = Agg-Deag-3 vDstPort = V4 PHB-ID = EF Extended VDstPort = Agg-Deag-2
* GENERIC-AGGREGATE-IP4会话：IPv4 DestAddress=Agg-Deag-3 vDstPort=V4 PHB-ID=EF Extended vDstPort=Agg-Deag-2
* STYLE = FF or SE
* 样式=FF或SE
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-2
* IPv4/GPI筛选器\u规范：IPv4 SrcAddress=Agg-Deag-2
* POLICY_DATA (PREEMPTION_PRI) = P2
* 策略数据（抢占优先级）=P2
where V3 and V4 are arbitrary VDstPort values picked by Agg-Deag-3.
其中V3和V4是Agg-Deag-3拾取的任意VDstPort值。
Note that V3 and V4 could be equal to V1 and V2 (respectively) since, in this example, the Extended VDstPort of the GENERIC-AGGREGATE Session contains the address of the Aggregator and, thus, ensures that different sessions are used from each Aggregator.
请注意，V3和V4可能分别等于V1和V2，因为在此示例中，GENERIC-AGGREGATE会话的扩展VDstPort包含聚合器的地址，从而确保每个聚合器使用不同的会话。
In the environments addressed by this document, RSVP messages are used to control resource reservations for generic aggregate reservations and may be used to control resource reservations for E2E reservations being aggregated over the generic aggregate reservations. To ensure the integrity of the associated reservation and admission control mechanisms, the RSVP Authentication mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be used. These 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 naturally used to protect the RSVP messages used for generic aggregate reservations and to protect RSVP messages used for E2E reservations outside the aggregation region. These hop-by-hop RSVP integrity mechanisms can also be used to protect RSVP messages used for E2E reservations when those transit through the aggregation region. This is because the Aggregator and
在本文档所述的环境中，RSVP消息用于控制通用聚合保留的资源保留，并可用于控制在通用聚合保留上聚合的E2E保留的资源保留。为确保相关保留和接纳控制机制的完整性，可使用[RSVP-CRYPTO1]和[RSVP-CRYPTO2]中定义的RSVP认证机制。它们逐跳保护RSVP消息完整性，并提供节点身份验证和重播保护，从而防止RSVP消息的损坏和欺骗。这些逐跳完整性机制自然可用于保护用于一般聚合保留的RSVP消息，以及保护用于聚合区域外E2E保留的RSVP消息。这些逐跳RSVP完整性机制还可用于在E2E保留通过聚合区域时保护用于这些保留的RSVP消息。这是因为聚合器和
Deaggregator behave as RSVP neighbors from the viewpoint of the E2E flows (even if they are not necessarily IP neighbors).
从E2E流的角度来看，解聚集器的行为就像RSVP邻居（即使它们不一定是IP邻居）。
[RSVP-CRYPTO1] discusses several approaches for key distribution. First, the RSVP Authentication shared keys can be distributed manually. This is the base option and its support is mandated for any implementation. However, in some environments, this approach may become a burden if keys frequently change over time. Alternatively, a standard key management protocol for secure key distribution can be used. However, existing key distribution protocols may not be appropriate in all environments because of the complexity or operational burden they involve.
[RSVP-CRYPTO1]讨论了几种密钥分发方法。首先，可以手动分发RSVP身份验证共享密钥。这是基本选项，任何实施都需要它的支持。但是，在某些环境中，如果密钥经常随时间变化，这种方法可能会成为一种负担。或者，可以使用用于安全密钥分发的标准密钥管理协议。然而，现有的密钥分发协议可能并不适用于所有环境，因为它们涉及复杂性或操作负担。
The use of RSVP Authentication in parts of the network where there may be one or more IP hops in between two RSVP neighbors raises an additional challenge. This is because, with some RSVP messages such as a Path message, an RSVP router does not know the RSVP next hop for that message at the time of forwarding it. In fact, part of the role of a Path message is precisely to discover the RSVP next hop (and to dynamically re-discover it when it changes, say because of a routing change). Hence, the RSVP router may not know which security association to use when forwarding such a message. This applies in particular to the case where RSVP Authentication mechanisms are to be used for protection of RSVP E2E messages (e.g., E2E Path) while they transit through an aggregation region and where the dynamic Deaggregator determination procedure defined in [RSVP-AGG] is used. This is because the Aggregator and the Deaggregator behave as RSVP neighbors for the E2E reservation, while there may be one or more IP hops in between them, and the Aggregator does not know ahead of time which router is going to act as the Deaggregator.
在两个RSVP邻居之间可能存在一个或多个IP跃点的网络部分中使用RSVP身份验证提出了另一个挑战。这是因为，对于某些RSVP消息（如Path消息），RSVP路由器在转发该消息时不知道该消息的RSVP下一跳。事实上，路径消息的一部分作用正是在下一跳发现RSVP（并在它发生变化时动态地重新发现它，比如因为路由变化）。因此，RSVP路由器可能不知道在转发这样的消息时使用哪个安全关联。这尤其适用于当RSVP E2E消息（例如，E2E路径）通过聚合区域传输时，使用RSVP认证机制保护RSVP E2E消息的情况，以及使用[RSVP-AGG]中定义的动态解聚合器确定程序的情况。这是因为聚合器和解聚合器作为E2E保留的RSVP邻居，而它们之间可能有一个或多个IP跃点，聚合器事先不知道哪个路由器将充当解聚合器。
In that situation, one approach is to share the same RSVP Authentication shared key across all the RSVP routers of a part of the network where there may be RSVP neighbors with IP hops in between. For example, all the Aggregators or Deaggregators of an aggregation region could share the same RSVP Authentication key, while different per-neighbor keys could be used between any RSVP router pair straddling the boundary between two administrative domains that have agreed to use RSVP signaling.
在这种情况下，一种方法是在网络的一部分的所有RSVP路由器上共享相同的RSVP认证共享密钥，其中可能存在RSVP邻居，其间存在IP跳。例如，聚合区域的所有聚合器或解聚合器可以共享相同的RSVP身份验证密钥，而在跨越已同意使用RSVP信令的两个管理域之间的边界的任何RSVP路由器对之间可以使用不同的每邻居密钥。
When the same RSVP Authentication shared key is to be shared among multiple RSVP neighbors, manual key distribution may be used. For situations where RSVP is being used for multicast flows, it might also be possible, in the future, to adapt a multicast key management method (e.g. from IETF Multicast Security Working Group) for key distribution with such multicast RSVP usage. For situations where RSVP is being used for unicast flows across domain boundaries, it is not currently clear how one might provide automated key management.
当同一个RSVP认证共享密钥要在多个RSVP邻居之间共享时，可以使用手动密钥分发。对于RSVP被用于多播流的情况，将来也可能采用多播密钥管理方法（例如，来自IETF多播安全工作组）进行密钥分配，以使用这种多播RSVP。对于RSVP用于跨域边界的单播流的情况，目前尚不清楚如何提供自动密钥管理。
Specification of a specific automated key management technique is outside the scope of this document. Operators should consider these key management issues when contemplating deployment of this specification.
特定自动密钥管理技术的规范不在本文档的范围内。在考虑部署本规范时，运营商应考虑这些关键管理问题。
The RSVP Authentication mechanisms do not provide confidentiality. If confidentiality is required, IPsec ESP [IPSEC-ESP] may be used, although it imposes the burden of key distribution. It also faces the additional issue discussed for key management above in the case where there can be IP hops in between RSVP hops. In the future, confidentiality solutions may be developed for the case where there can be IP hops in between RSVP hops, perhaps by adapting confidentiality solutions developed by the IETF MSEC Working Group. Such confidentiality solutions for RSVP are outside the scope of this document.
RSVP身份验证机制不提供机密性。如果需要保密，可以使用IPsec ESP[IPsec-ESP]，尽管它会增加密钥分发的负担。在RSVP跳之间可能存在IP跳的情况下，它还面临上面讨论的密钥管理的附加问题。将来，可能会通过调整IETF MSEC工作组开发的保密解决方案，为RSVP跳之间可能存在IP跳的情况开发保密解决方案。RSVP的此类保密解决方案不在本文件范围内。
Protection against traffic analysis is also not provided by RSVP Authentication. Since generic aggregate reservations are intended to reserve resources collectively for a whole set of users or hosts, malicious snooping of the corresponding RSVP messages could provide more traffic analysis information than snooping of an E2E reservation. When RSVP neighbors are directly attached, mechanisms such as bulk link encryption might be used when protection against traffic analysis is required. This approach could be used inside the aggregation region for protection of the generic aggregate reservations. It may also be used outside the aggregation region for protection of the E2E reservation. However, it is not applicable to the protection of E2E reservations while the corresponding E2E RSVP messages transit through the aggregation region.
RSVP身份验证也不提供流量分析保护。由于通用聚合保留旨在为一整套用户或主机集体保留资源，因此恶意监听相应的RSVP消息可能比监听E2E保留提供更多的流量分析信息。当RSVP邻居直接连接时，当需要针对流量分析进行保护时，可以使用诸如批量链路加密之类的机制。此方法可在聚合区域内用于保护通用聚合保留。它也可以在聚合区域之外用于保护E2E保留。然而，当相应的E2E RSVP消息通过聚合区域传输时，它不适用于E2E保留的保护。
When generic aggregate reservations are used for aggregation of E2E reservations, the security considerations discussed in [RSVP-AGG] apply and are revisited here.
当通用聚合保留用于E2E保留的聚合时，[RSVP-AGG]中讨论的安全注意事项适用，并在此处重新讨论。
First, the loss of an aggregate reservation to an aggressor causes E2E flows to operate unreserved, and the reservation of a great excess of bandwidth may result in a denial of service. These issues are not confined to the extensions defined in the present document: RSVP itself has them. However, they may be exacerbated here by the fact that each aggregate reservation typically facilitates communication for many sessions. Hence, compromising one such aggregate reservation can result in more damage than compromising a typical E2E reservation. Use of the RSVP Authentication mechanisms to protect against such attacks has been discussed above.
首先，向攻击者丢失聚合保留会导致E2E流无保留地运行，并且保留大量多余的带宽可能会导致拒绝服务。这些问题并不局限于本文件中定义的扩展：RSVP本身就有这些问题。然而，由于每个聚合保留通常有助于多个会话的通信，这一事实可能会加剧这种情况。因此，妥协一个这样的总体保留可能比妥协一个典型的E2E保留造成更大的损害。上面已经讨论了如何使用RSVP身份验证机制来防止此类攻击。
An additional security consideration specific to RSVP aggregation involves the modification of the IP protocol number in RSVP Path messages that traverse an aggregation region. Malicious modification
RSVP聚合特有的另一个安全注意事项涉及修改穿过聚合区域的RSVP路径消息中的IP协议号。恶意修改
of the IP protocol number in a Path message would cause the message to be ignored by all subsequent RSVP devices on its path, preventing reservations from being made. It could even be possible to correct the value before it reached the receiver, making it difficult to detect the attack. Note that, in theory, it might also be possible for a node to modify the IP protocol number for non-RSVP messages as well, thus interfering with the operation of other protocols. It is RECOMMENDED that implementations of this specification only support modification of the IP protocol number for RSVP Path, PathTear, and ResvConf messages. That is, a general facility for modification of the IP protocol number SHOULD NOT be made available.
路径消息中IP协议号的更改将导致该消息被其路径上的所有后续RSVP设备忽略，从而阻止进行保留。甚至可以在到达接收器之前纠正该值，从而使检测攻击变得困难。注意，理论上，节点也可能修改非RSVP消息的IP协议号，从而干扰其他协议的操作。建议本规范的实现仅支持修改RSVP Path、PATHTRARE和ResvConf消息的IP协议号。也就是说，不应提供修改IP协议编号的通用设施。
Network operators deploying routers with RSVP aggregation capability should be aware of the risks of inappropriate modification of the IP protocol number and should take appropriate steps (physical security, password protection, etc.) to reduce the risk that a router could be configured by an attacker to perform malicious modification of the protocol number.
部署具有RSVP聚合功能的路由器的网络运营商应意识到IP协议编号不适当修改的风险，并应采取适当措施（物理安全、密码保护等）降低攻击者配置路由器以恶意修改协议号的风险。
IANA modified the RSVP parameters registry, 'Class Names, Class Numbers, and Class Types' subregistry, and assigned two new C-Types under the existing SESSION Class (Class number 1), as described below:
IANA修改了RSVP参数注册表“类名称、类编号和类类型”子区域，并在现有会话类（类编号1）下分配了两个新的C类型，如下所述：
Class
Number Class Name Reference
------ ----------------------- ---------
Class
Number Class Name Reference
------ ----------------------- ---------
1 SESSION [RFC2205]
1次会议[RFC2205]
Class Types or C-Types:
类别类型或C类型：
17 GENERIC-AGGREGATE-IP4 [RFC4860] 18 GENERIC-AGGREGATE-IP6 [RFC4860]
17通用-聚合-IP4[RFC4860]18通用-聚合-IP6[RFC4860]
IANA also modified the RSVP parameters registry, 'Class Names, Class Numbers, and Class Types' subregistry, and assigned one new Class Number for the SESSION-OF-INTEREST class and two new C-Types for that class, according to the table below:
IANA还修改了RSVP参数注册表“类别名称、类别编号和类别类型”子区域，并根据下表为感兴趣的课程类别分配了一个新的类别编号和两个新的C类型：
Class
Number Class Name Reference
------ ----------------------- ---------
Class
Number Class Name Reference
------ ----------------------- ---------
132 SESSION-OF-INTEREST [RFC4860]
132感兴趣的会议[RFC4860]
Class Types or C-Types:
类别类型或C类型：
1 GENERIC-AGG-IP4-SOI [RFC4860] 2 GENERIC-AGG-IP6-SOI [RFC4860]
1通用-AGG-IP4-SOI[RFC4860]2通用-AGG-IP6-SOI[RFC4860]
These allocations are in accordance with [RSVP-MOD].
这些分配符合[RSVP-MOD]。
This document borrows heavily from [RSVP-AGG]. It also borrows the concepts of Virtual Destination Port and Extended Virtual Destination Port from [RSVP-IPSEC] and [RSVP-TE], respectively.
本文件大量借用[RSVP-AGG]。它还分别从[RSVP-IPSEC]和[RSVP-TE]借用了虚拟目标端口和扩展虚拟目标端口的概念。
Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel Voce, Anil Agarwal, Alexander Sayenko, and Anca Zamfir for their input into the content of this document. Thanks to Steve Kent for insightful comments on usage of RSVP reservations in IPsec environments.
此外，我们还感谢弗雷德·贝克、罗杰·莱维斯克、卡罗尔·伊图拉尔德、丹尼尔·沃奇、阿尼尔·阿加瓦尔、亚历山大·萨耶恩科和安卡·赞菲尔对本文件内容的投入。感谢Steve Kent对IPsec环境中RSVP保留的使用提出了深刻的评论。
Ran Atkinson, Fred Baker, Luc Billot, Pascal Delprat, and Eric Vyncke provided guidance and suggestions for the security considerations section.
Ran Atkinson、Fred Baker、Luc Billot、Pascal Delprat和Eric Vyncke为安全注意事项部分提供了指导和建议。
[IPSEC-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[IPSEC-ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[PHB-ID] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[PHB-ID]Black，D.，Brim，S.，Carpenter，B.，和F.Le Faucheur，“每跳行为识别码”，RFC 31402001年6月。
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RSVP-AGG] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RSVP-AGG]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 31752001年9月。
[RSVP-CRYPTO1] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RSVP-CRYPTO1]Baker，F.，Lindell，B.，和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RSVP-CRYPTO2] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RSVP-CRYPTO2]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RSVP-IPSEC]Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2207，1997年9月。
[RSVP-MOD] Kompella, K. and J. Lang, "Procedures for Modifying the Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, October 2004.
[RSVP-MOD]Kompella，K.和J.Lang，“修改资源预留协议（RSVP）的程序”，BCP 96，RFC 3936，2004年10月。
[BW-REDUC] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[BW-Reduce]Polk，J.和S.Dhesikan，“用于减少预留流带宽的资源预留协议（RSVP）扩展”，RFC 4495，2006年5月。
[GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[GRE]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Trana，“通用路由封装（GRE）”，RFC 27842000年3月。
[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RSVP-PREEMEP]Herzog，S.，“信号抢占优先权政策要素”，RFC 31812001年10月。
[RSVP-PROCESS] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[RSVP-PROCESS]Braden，R.和L.Zhang，“资源预留协议（RSVP）——第1版消息处理规则”，RFC 2209，1997年9月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RSVP-TUNNEL] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RSVP-TUNNEL]Terzis，A.，Krawczyk，J.，Wroclawski，J.，和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested Virtual Private Network", Work in Progress, February 2007.
[SIG-NESTED]Baker，F.和P.Bose，“嵌套虚拟专用网络中的QoS信令”，正在进行的工作，2007年2月。
This appendix does not provide additional specification. It only illustrates the specification detailed in Section 4 through a possible flow of RSVP signaling messages. This flow assumes an environment where E2E reservations are aggregated over generic aggregate RSVP reservations. It illustrates a possible RSVP message flow that could take place in the successful establishment of a unicast E2E reservation that is the first between a given pair of Aggregator/Deaggregator.
本附录不提供其他规范。它仅通过RSVP信令消息的可能流来说明第4节中详述的规范。此流假设环境中E2E保留是在通用聚合RSVP保留之上聚合的。它说明了在成功建立单播E2E预约时可能发生的RSVP消息流，该预约是给定的聚合器/解聚合器对之间的第一个预约。
Aggregator Deaggregator
聚合器-解聚器
E2E Path
----------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed,SOI=GAx)
<----------------------------------
E2E PathErr(New-agg-needed,SOI=GAy)
<----------------------------------
(3)
AggPath(Session=GAx)
------------------------------->
AggPath(Session=GAy)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (Session=GAx)
<-------------------------------
AggResv (Session=GAy)
<-------------------------------
(6)
AggResvConfirm (Session=GAx)
------------------------------>
AggResvConfirm (Session=GAy)
------------------------------>
(7)
E2E Resv
<---------
(8)
E2E Resv (SOI=GAx)
<-----------------------------
(9)
E2E Resv
<-----------
E2E Path
----------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed,SOI=GAx)
<----------------------------------
E2E PathErr(New-agg-needed,SOI=GAy)
<----------------------------------
(3)
AggPath(Session=GAx)
------------------------------->
AggPath(Session=GAy)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (Session=GAx)
<-------------------------------
AggResv (Session=GAy)
<-------------------------------
(6)
AggResvConfirm (Session=GAx)
------------------------------>
AggResvConfirm (Session=GAy)
------------------------------>
(7)
E2E Resv
<---------
(8)
E2E Resv (SOI=GAx)
<-----------------------------
(9)
E2E Resv
<-----------
(1) The Aggregator forwards E2E Path into the aggregation region after modifying its IP protocol number to RSVP-E2E-IGNORE
(1) 聚合器将其IP协议号修改为RSVP-E2E-IGNORE后，将E2E路径转发到聚合区域
(2) Let's assume no Aggregate Path exists. To be able to accurately update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC of Aggregate Path. In this example, the Deaggregator elects to instruct the Aggregator to set up Aggregate Path states for the two supported PHB-IDs. To do that, the Deaggregator
(2) 假设不存在聚合路径。为了能够准确地更新E2E路径的ADSPEC，解聚集器需要聚合路径的ADSPEC。在本例中，解聚合器选择指示聚合器为两个受支持的PHB ID设置聚合路径状态。要做到这一点，解聚集器
sends two E2E PathErr messages with a New-Agg-Needed PathErr code. Both PathErr messages also contain a SESSION-OF-INTEREST (SOI) object. In the first E2E PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAx) whose PHB-ID is set to x. In the second E2E PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAy) whose PHB-ID is set to y. In both messages the GENERIC-AGGREGATE SESSION contains an interface-independent Deaggregator address inside the DestAddress and appropriate values inside the vDstPort and Extended vDstPort fields.
发送两条E2E PathErr消息，其中包含新的Agg所需的PathErr代码。两条PathErr消息还包含感兴趣的会话（SOI）对象。在第一个E2E PathErr中，SOI包含一个通用聚合会话（GAx），其PHB-ID设置为x。在第二个E2E PathErr中，SOI包含一个通用聚合会话（GAy），其PHB-ID设置为y。在这两条消息中，GENERIC-AGGREGATE会话在DestAddress中包含一个独立于接口的解聚集器地址，在vDstPort和Extended vDstPort字段中包含相应的值。
(3) The Aggregator follows the request from the Deaggregator and signals an Aggregate Path for both GENERIC-AGGREGATE Sessions (GAx and GAy).
(3) 聚合器遵循从解聚合器发出的请求，并发出通用聚合会话（GAx和GAy）的聚合路径信号。
(4) The Deaggregator takes into account the information contained in the ADSPEC from both Aggregate Paths and updates the E2E Path ADSPEC accordingly. The Deaggregator also modifies the E2E Path IP protocol number to RSVP before forwarding it.
(4) 解聚集器考虑来自两个聚合路径的ADSPEC中包含的信息，并相应地更新E2E路径ADSPEC。在转发之前，解聚集器还将E2E路径IP协议号修改为RSVP。
(5) In this example, the Deaggregator elects to immediately proceed with establishment of generic aggregate reservations for both PHB-IDs. In effect, the Deaggregator can be seen as anticipating the actual demand of E2E reservations so that resources are available on the generic aggregate reservations when the E2E Resv requests arrive, in order to speed up establishment of E2E reservations. Assume also that the Deaggregator includes the optional Resv Confirm Request in these Aggregate Resv.
(5) 在本例中，解聚集器选择立即为两个PHB ID建立通用聚集保留。实际上，可以将解聚集器视为预测E2E预订的实际需求，以便在E2E Resv请求到达时，通用聚合预订上的资源可用，从而加快E2E预订的建立。还假设解聚集器在这些聚合Resv中包含可选的Resv确认请求。
(6) The Aggregator merely complies with the received ResvConfirm Request and returns the corresponding Aggregate ResvConfirm.
(6) 聚合器仅遵守收到的ResvConfig请求并返回相应的聚合ResvConfig。
(7) The Deaggregator has explicit confirmation that both Aggregate Resvs are established.
(7) 解聚集器已明确确认两个聚合RESV均已建立。
(8) On receipt of the E2E Resv, the Deaggregator applies the mapping policy defined by the network administrator to map the E2E Resv onto a generic aggregate reservation. Let's assume that this policy is such that the E2E reservation is to be mapped onto the generic aggregate reservation with PHB-ID=x. The Deaggregator knows that a generic aggregate reservation (GAx) is in place for the corresponding PHB-ID since (7). The Deaggregator performs admission control of the E2E Resv onto the generic aggregate reservation for PHB-ID=x (GAx). Assuming that the generic aggregate reservation for PHB-ID=x (GAx) had been established with sufficient bandwidth to support the E2E Resv, the Deaggregator adjusts its counter, tracking the unused bandwidth on the generic aggregate reservation. Then it forwards the E2E Resv to the Aggregator including a SESSION-OF-INTEREST object
(8) 收到E2E Resv后，解聚集器应用网络管理员定义的映射策略将E2E Resv映射到通用聚合保留上。让我们假设此策略使得E2E保留映射到PHB-ID=x的通用聚合保留。解聚集器知道，自（7）起，已为相应的PHB-ID设置了通用聚集保留（GAx）。解聚集器对PHB-ID=x（GAx）的通用聚集保留执行E2E Resv的接纳控制。假设PHB-ID=x（GAx）的通用聚合保留已建立，具有足够的带宽来支持E2E Resv，则解聚集器调整其计数器，跟踪通用聚合保留上未使用的带宽。然后，它将E2E Resv转发给包含感兴趣的会话对象的聚合器
conveying the selected mapping onto GAx (and hence onto PHB-ID=x).
将所选映射传送到GAx（从而传送到PHB-ID=x）。
(9) The Aggregator records the mapping of the E2E Resv onto GAx (and onto PHB-ID=x). The Aggregator removes the SOI object and forwards the E2E Resv towards the sender.
(9) 聚合器记录E2E Resv到GAx（和到PHB-ID=x）的映射。聚合器删除SOI对象并将E2E Resv转发给发送方。
Authors' Addresses
作者地址
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France EMail: flefauch@cisco.com
Francois Le Faucheur Cisco Systems，Inc.企业绿边村-法国鲁曼尼耶大道T3400号巴蒂门特06410 Biot Sophia Antipolis电子邮件：flefauch@cisco.com
Bruce Davie Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA EMail: bds@cisco.com
Bruce Davie Cisco Systems，Inc.美国马萨诸塞州伯斯堡马萨诸塞大道1414号邮编01719电子邮件：bds@cisco.com
Pratik Bose Lockheed Martin 700 North Frederick Ave. Gaithersburg, MD 20879 USA EMail: pratik.bose@lmco.com
Pratik Bose洛克希德马丁公司美国马里兰州盖瑟斯堡北弗雷德里克大道700号邮编：20879电子邮件：Pratik。bose@lmco.com
Chris Christou Booz Allen Hamilton 13200 Woodland Park Road Herndon, VA 20171 USA EMail: christou_chris@bah.com
Chris Christou Booz Allen Hamilton 13200伍德兰公园路Herndon，弗吉尼亚州20171美国电子邮件：Christou_chris@bah.com
Michael Davenport Booz Allen Hamilton Suite 390 5220 Pacific Concourse Drive Los Angeles, CA 90045 USA EMail: davenport_michael@bah.com
Michael Davenport Booz Allen Hamilton套房390 5220美国加利福尼亚州洛杉矶太平洋广场大道90045电子邮件：Davenport_michael@bah.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。