Internet Engineering Task Force (IETF) G. Karagiannis
Request for Comments: 7417 Huawei Technologies
Category: Experimental A. Bhargava
ISSN: 2070-1721 Cisco Systems, Inc.
December 2014
Internet Engineering Task Force (IETF) G. Karagiannis
Request for Comments: 7417 Huawei Technologies
Category: Experimental A. Bhargava
ISSN: 2070-1721 Cisco Systems, Inc.
December 2014
Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains
对拥塞前通知（PCN）域上IPv4和IPv6保留的通用聚合RSVP的扩展
Abstract
摘要
This document specifies extensions to Generic Aggregate RSVP (RFC 4860) for support of the Pre-Congestion Notification (PCN) Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN.
本文档指定了通用聚合RSVP（RFC 4860）的扩展，以支持使用PCN的区分服务云上的预拥塞通知（PCN）控制负载（CL）和单标记（SM）边缘行为。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7417.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7417.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Objective ..................................................4
1.2. Overview and Motivation ....................................5
1.3. Requirements Language and Terminology ......................8
1.4. Organization of This Document .............................12
2. Overview of RSVP Extensions and Operations .....................12
2.1. Overview of RSVP Aggregation Procedures in PCN-Domains ....12
2.2. PCN-Marking, Encoding, and Transport of
Pre-congestion Information ................................14
2.3. Traffic Classification within the Aggregation Region ......14
2.4. Deaggregator (PCN-Egress-Node) Determination ..............15
2.5. Mapping E2E Reservations onto Aggregate Reservations ......15
2.6. Size of Aggregate Reservations ............................16
2.7. E2E Path ADSPEC Update ....................................16
2.8. Intra-domain Routes .......................................16
2.9. Inter-domain Routes .......................................16
2.10. Reservations for Multicast Sessions ......................16
2.11. Multi-level Aggregation ..................................16
2.12. Reliability Issues .......................................17
3. Elements of Procedures .........................................17
3.1. Receipt of E2E Path Message by PCN-Ingress-Node
(Aggregating Router) ......................................17
3.2. Handling of E2E Path Message by Interior Routers ..........17
3.3. Receipt of E2E Path Message by PCN-Egress-Node
(Deaggregating Router) ....................................18
3.4. Initiation of New Aggregate Path Message by
PCN-Ingress-Node (Aggregating Router) .....................18
3.5. Handling of Aggregate Path Message by Interior Routers ....18
3.6. Handling of Aggregate Path Message by
Deaggregating Router ......................................18
3.7. Handling of E2E Resv Message by Deaggregating Router ......19
3.8. Handling of E2E Resv Message by Interior Routers ..........19
3.9. Initiation of New Aggregate Resv Message by
Deaggregating Router ......................................20
3.10. Handling of Aggregate Resv Message by Interior Routers ...20
3.11. Handling of E2E Resv Message by Aggregating Router .......21
3.12. Handling of Aggregate Resv Message by
Aggregating Router .......................................21
3.13. Removal of E2E Reservation ...............................21
3.14. Removal of Aggregate Reservation .........................22
3.15. Handling of Data on Reserved E2E Flow by
Aggregating Router .......................................22
3.16. Procedures for Multicast Sessions ........................22
3.17. Misconfiguration of PCN-Node .............................22
3.18. PCN-Based Flow Termination ...............................22
1. Introduction ....................................................4
1.1. Objective ..................................................4
1.2. Overview and Motivation ....................................5
1.3. Requirements Language and Terminology ......................8
1.4. Organization of This Document .............................12
2. Overview of RSVP Extensions and Operations .....................12
2.1. Overview of RSVP Aggregation Procedures in PCN-Domains ....12
2.2. PCN-Marking, Encoding, and Transport of
Pre-congestion Information ................................14
2.3. Traffic Classification within the Aggregation Region ......14
2.4. Deaggregator (PCN-Egress-Node) Determination ..............15
2.5. Mapping E2E Reservations onto Aggregate Reservations ......15
2.6. Size of Aggregate Reservations ............................16
2.7. E2E Path ADSPEC Update ....................................16
2.8. Intra-domain Routes .......................................16
2.9. Inter-domain Routes .......................................16
2.10. Reservations for Multicast Sessions ......................16
2.11. Multi-level Aggregation ..................................16
2.12. Reliability Issues .......................................17
3. Elements of Procedures .........................................17
3.1. Receipt of E2E Path Message by PCN-Ingress-Node
(Aggregating Router) ......................................17
3.2. Handling of E2E Path Message by Interior Routers ..........17
3.3. Receipt of E2E Path Message by PCN-Egress-Node
(Deaggregating Router) ....................................18
3.4. Initiation of New Aggregate Path Message by
PCN-Ingress-Node (Aggregating Router) .....................18
3.5. Handling of Aggregate Path Message by Interior Routers ....18
3.6. Handling of Aggregate Path Message by
Deaggregating Router ......................................18
3.7. Handling of E2E Resv Message by Deaggregating Router ......19
3.8. Handling of E2E Resv Message by Interior Routers ..........19
3.9. Initiation of New Aggregate Resv Message by
Deaggregating Router ......................................20
3.10. Handling of Aggregate Resv Message by Interior Routers ...20
3.11. Handling of E2E Resv Message by Aggregating Router .......21
3.12. Handling of Aggregate Resv Message by
Aggregating Router .......................................21
3.13. Removal of E2E Reservation ...............................21
3.14. Removal of Aggregate Reservation .........................22
3.15. Handling of Data on Reserved E2E Flow by
Aggregating Router .......................................22
3.16. Procedures for Multicast Sessions ........................22
3.17. Misconfiguration of PCN-Node .............................22
3.18. PCN-Based Flow Termination ...............................22
4. Protocol Elements ..............................................23
4.1. PCN Objects ...............................................24
5. Security Considerations ........................................28
6. IANA Considerations ............................................29
7. References .....................................................29
7.1. Normative References ......................................29
7.2. Informative References ....................................30
Appendix A. Example Signaling Flow ................................33
Acknowledgments ...................................................35
Authors' Addresses ................................................36
4. Protocol Elements ..............................................23
4.1. PCN Objects ...............................................24
5. Security Considerations ........................................28
6. IANA Considerations ............................................29
7. References .....................................................29
7.1. Normative References ......................................29
7.2. Informative References ....................................30
Appendix A. Example Signaling Flow ................................33
Acknowledgments ...................................................35
Authors' Addresses ................................................36
Pre-Congestion Notification (PCN) can support the Quality of Service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. Two mechanisms are used: admission control and flow termination. Admission control is used to decide whether to admit or block a new flow request, while flow termination is used in abnormal circumstances to decide whether to terminate some of the existing flows. To support these two features, the overall rate of PCN-traffic is metered on every link in the domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. These configured rates are below the rate of the link, thus providing notification to boundary nodes about overloads before any congestion occurs (hence "pre-congestion" notification). The PCN-egress-nodes measure the rates of differently marked PCN-traffic in periodic intervals and report these rates to the Decision Points for admission control and flow termination; the Decision Points use these rates to make decisions. The Decision Points may be collocated with the PCN-ingress-nodes, or their function may be implemented in another node. For more details, see [RFC5559], [RFC6661], and [RFC6662].
预拥塞通知（PCN）可以以简单、可扩展和健壮的方式支持Diffserv域内非弹性流的服务质量（QoS）。使用两种机制：接纳控制和流终止。接纳控制用于决定是否接纳或阻止新的流请求，而流终止用于在异常情况下决定是否终止某些现有流。为了支持这两个功能，在域中的每个链路上测量PCN流量的总速率，并且当超过某些配置速率时，适当地标记PCN数据包。这些配置的速率低于链路速率，因此在发生任何拥塞之前向边界节点提供有关过载的通知（因此为“拥塞前”通知）。PCN出口节点以周期性间隔测量不同标记的PCN流量的速率，并将这些速率报告给决策点以进行准入控制和流量终止；决策点使用这些比率来做出决策。决策点可以与PCN入口节点并置，或者它们的功能可以在另一个节点中实现。有关更多详细信息，请参阅[RFC5559]、[RFC6661]和[RFC6662]。
The main objective of this document is to specify the signaling protocol that can be used within a PCN-domain to carry reports from a PCN-ingress-node to a PCN Decision Point, considering that the PCN Decision Point and PCN-egress-node are collocated.
本文档的主要目的是指定可在PCN域内用于将报告从PCN入口节点传送到PCN决策点的信令协议，考虑到PCN决策点和PCN出口节点是并置的。
If the PCN Decision Point is not collocated with the PCN-egress-node, then additional signaling procedures are required that are out of scope for this document. Moreover, as mentioned above, this architecture conforms with Policy-Based Admission Control (PBAC), where the Decision Point is located in a node other than the PCN-ingress-node [RFC2753].
如果PCN决策点未与PCN出口节点并置，则需要额外的信令程序，这超出了本文件的范围。此外，如上所述，该架构符合基于策略的接纳控制（PBAC），其中决策点位于除PCN入口节点[RFC2753]之外的节点中。
Several signaling protocols can be used to carry information between PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node). However, since (1) both the PCN-egress-node and PCN-ingress-node are located on the data path and (2) the admission control procedure needs to be done at the PCN-egress-node, a signaling protocol that follows the same path as the data path, like RSVP, is more suited for this purpose. In particular, this document specifies extensions to Generic Aggregate RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-Congestion Notification.
可以使用多种信令协议在PCN边界节点（PCN入口节点和PCN出口节点）之间传送信息。然而，由于（1）PCN出口节点和PCN入口节点都位于数据路径上，并且（2）需要在PCN出口节点处执行接纳控制过程，因此遵循与数据路径相同路径的信令协议（如RSVP）更适合于此目的。特别是，本文档指定了通用聚合RSVP[RFC4860]的扩展，以支持使用拥塞前通知的区分服务云上的PCN控制负载（CL）和单标记（SM）边缘行为。
This document is published as an Experimental document in order to:
本文件作为实验性文件发布，目的是：
o validate industry interest by allowing implementation and deployment
o 通过允许实施和部署来验证业界的兴趣
o gather operational experience, particularly related to dynamic interactions of RSVP signaling and PCN, and corresponding levels of performance
o 收集运营经验，特别是与RSVP信令和PCN的动态交互相关的经验，以及相应的性能水平
Support for the techniques specified in this document involves RSVP functionality in boundary nodes of a PCN-domain whose interior nodes forward RSVP traffic without performing RSVP functionality.
对本文档中指定技术的支持涉及PCN域边界节点中的RSVP功能，其内部节点转发RSVP流量而不执行RSVP功能。
Two main QoS architectures have been specified by the IETF: the Integrated Services (Intserv) [RFC1633] architecture and the Differentiated Services (Diffserv) architecture ([RFC2475]).
IETF规定了两种主要的QoS体系结构：集成服务（Intserv）[RFC1633]体系结构和区分服务（Diffserv）体系结构（[RFC2475]）。
Intserv provides methods for the delivery of end-to-end QoS to applications over heterogeneous networks. One of the QoS signaling protocols used by the Intserv architecture is RSVP [RFC2205], which can be used by applications to request per-flow resources from the network. These RSVP requests can be admitted or rejected by the network. Applications can express their quantifiable resource requirements using Intserv parameters as defined in [RFC2211] and [RFC2212]. The Controlled Load (CL) service [RFC2211] is a form of QoS that closely approximates the QoS that the same flow would receive from a lightly loaded network element. The CL service is useful for inelastic flows such as those used for real-time media.
Intserv提供了通过异构网络向应用程序提供端到端QoS的方法。Intserv体系结构使用的QoS信令协议之一是RSVP[RFC2205]，应用程序可以使用该协议从网络请求每流资源。网络可以接纳或拒绝这些RSVP请求。应用程序可以使用[RFC2211]和[RFC2212]中定义的Intserv参数来表示其可量化的资源需求。受控负载（CL）服务[RFC2211]是一种QoS形式，它非常接近于同一流从轻负载网元接收的QoS。CL服务对于非弹性流（如用于实时介质的流）非常有用。
The Diffserv architecture can support the differentiated treatment of packets in very large-scale environments. While Intserv and RSVP classify packets per flow, Diffserv networks classify packets into one of a small number of aggregated flows or "classes", based on the Diffserv Codepoint (DSCP) in the packet IP header. At each Diffserv router, packets are subjected to a "Per Hop Behavior" (PHB), which is
Diffserv体系结构可以支持在大规模环境中对数据包进行差异化处理。当Intserv和RSVP对每个流的数据包进行分类时，Diffserv网络根据数据包IP报头中的Diffserv码点（DSCP）将数据包分类为少数聚合流或“类”之一。在每个Diffserv路由器上，数据包都会受到“每跳行为”（PHB）的影响，即
invoked by the DSCP. The primary benefit of Diffserv is its scalability, since the need for per-flow state and per-flow processing is eliminated.
由DSCP调用。Diffserv的主要好处是它的可伸缩性，因为不需要每个流状态和每个流处理。
However, Diffserv does not include any mechanism for communication between applications and the network. Several solutions have been specified to solve this issue. One of these solutions is Intserv over Diffserv [RFC2998], including Resource-Based Admission Control (RBAC), PBAC, assistance in traffic identification/classification, and traffic conditioning. Intserv over Diffserv can operate over a statically provisioned or an RSVP-aware Diffserv region. When it is RSVP aware, several mechanisms may be used to support dynamic provisioning and topology-aware admission control, including aggregate RSVP reservations, per-flow RSVP, or a bandwidth broker. [RFC3175] specifies aggregation of RSVP end-to-end reservations over aggregate RSVP reservations. In [RFC3175], the RSVP generic aggregate reservation is characterized by an RSVP SESSION object using the 3-tuple <source IP address, destination IP address, Diffserv Codepoint>.
但是，Diffserv不包括应用程序和网络之间通信的任何机制。已经指定了几种解决方案来解决此问题。其中一个解决方案是区分服务上的Intserv[RFC2998]，包括基于资源的准入控制（RBAC）、PBAC、流量识别/分类协助和流量调节。区分服务上的Intserv可以在静态配置或RSVP感知的区分服务区域上运行。当它是RSVP感知的时，可以使用几种机制来支持动态资源调配和拓扑感知许可控制，包括聚合RSVP预留、每流RSVP或带宽代理。[RFC3175]指定RSVP端到端保留相对于聚合RSVP保留的聚合。在[RFC3175]中，RSVP通用聚合保留的特征是RSVP会话对象使用三元组<源IP地址、目标IP地址、区分服务代码点>。
Several scenarios require the use of multiple generic aggregate reservations that are established for a given PHB from a given source IP address to a given destination IP address; see [RFC4923] and [RFC4860]. For example, multiple generic aggregate reservations can be applied in situations where multiple end-to-end (E2E) reservations using different preemption priorities need to be aggregated through a PCN-domain using the same PHB. Using multiple aggregate reservations for the same PHB allows
几个场景需要使用多个通用聚合保留，这些保留是为给定PHB从给定源IP地址到给定目标IP地址建立的；参见[RFC4923]和[RFC4860]。例如，在需要使用相同PHB通过PCN域聚合使用不同抢占优先级的多个端到端（E2E）保留的情况下，可以应用多个通用聚合保留。对同一PHB使用多个聚合保留允许
o enforcement of the different preemption priorities within the aggregation region
o 在聚合区域内强制执行不同的抢占优先级
o more efficient management of Diffserv resources
o 更高效地管理Diffserv资源
o sustainment of a larger number of E2E reservations with higher preemption priorities during periods of resource shortage
o 在资源短缺期间，以更高的优先权维持更多的E2E保留区
In particular, [RFC4923] discusses in detail how end-to-end RSVP reservations can be established in a nested VPN environment through RSVP aggregation.
特别是，[RFC4923]详细讨论了如何通过RSVP聚合在嵌套VPN环境中建立端到端RSVP保留。
[RFC4860] provides generic aggregate reservations by extending [RFC3175] to support multiple aggregate reservations for the same source IP address, destination IP address, and PHB (or set of PHBs). In particular, multiple such generic aggregate reservations can be established for a given PHB from a given source IP address to a given destination IP address. This is achieved by adding the concept of a Virtual Destination Port and an Extended Virtual Destination Port in
[RFC4860]通过扩展[RFC3175]来支持同一源IP地址、目标IP地址和PHB（或一组PHB）的多个聚合保留，从而提供通用聚合保留。特别地，可以为给定PHB从给定源IP地址到给定目的IP地址建立多个这样的通用聚合保留。这是通过在中添加虚拟目标端口和扩展虚拟目标端口的概念来实现的
the RSVP SESSION object. In addition to this, the RSVP SESSION object for generic aggregate reservations uses the PHB Identification Code (PHB-ID) defined in [RFC3140] instead of using the Diffserv Codepoint (DSCP) used in [RFC3175]. The PHB-ID is used to identify the PHB, or set of PHBs, from which the Diffserv resources are to be reserved.
RSVP会话对象。除此之外，通用聚合保留的RSVP会话对象使用[RFC3140]中定义的PHB标识码（PHB-ID），而不是[RFC3175]中使用的区分服务代码点（DSCP）。PHB-ID用于标识要从中保留区分服务资源的PHB或PHB集。
The RSVP-like signaling protocol required to carry (1) requests from a PCN-egress-node to a PCN-ingress-node and (2) reports from a PCN-ingress-node to a PCN-egress-node needs to follow the PCN signaling requirements defined in [RFC6663]. In addition to that, the signaling protocol functionality supported by the PCN-ingress-nodes and PCN-egress-nodes needs to maintain logical aggregate constructs (i.e., ingress-egress-aggregate state) and be able to map E2E reservations to these aggregate constructs. Moreover, no actual reservation state is needed to be maintained inside the PCN-domain, i.e., the PCN-interior-nodes are not maintaining any reservation state.
传送（1）从PCN出口节点到PCN入口节点的请求和（2）从PCN入口节点到PCN出口节点的报告所需的类似RSVP的信令协议需要遵循[RFC6663]中定义的PCN信令要求。除此之外，由PCN入口节点和PCN出口节点支持的信令协议功能需要维护逻辑聚合结构（即，入口-出口聚合状态），并且能够将E2E保留映射到这些聚合结构。此外，在PCN域内不需要维护实际的保留状态，即PCN内部节点不维护任何保留状态。
This can be accomplished by two possible approaches:
这可以通过两种可能的方法实现：
Approach (1):
方法（1）：
o adapting the aggregation procedures of RFC 4860 to fit the PCN requirements with as little change as possible over the functionality provided in RFC 4860.
o 调整RFC 4860的聚合程序，以满足PCN要求，同时对RFC 4860中提供的功能进行尽可能小的更改。
o hence, performing aggregate RSVP signaling (even if it is to be ignored by PCN-interior-nodes).
o 因此，执行聚合RSVP信令（即使PCN内部节点将忽略它）。
o using the aggregate RSVP signaling procedures to carry PCN information between the PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node).
o 使用聚合RSVP信令过程在PCN边界节点（PCN入口节点和PCN出口节点）之间传输PCN信息。
Approach (2):
方法（2）：
o adapting the aggregation procedures of RFC 4860 to fit the PCN requirements with significant changes over RFC 4860 (i.e., the aspect of the procedures that have to do with maintaining aggregate states and mapping the E2E reservations to aggregate constructs are kept, but the procedures that are specific to aggregate RSVP signaling and aggregate reservation establishment/maintenance are dropped).
o 调整RFC 4860的聚合程序，以适应PCN要求，与RFC 4860相比有重大变化（即，保留与维护聚合状态和将E2E保留映射到聚合构造有关的程序方面，但放弃特定于聚合RSVP信令和聚合保留建立/维护的程序）。
o hence not performing aggregate RSVP signaling.
o 因此，不执行聚合RSVP信令。
o piggybacking the PCN information inside the E2E RSVP signaling.
o 在E2E RSVP信令中承载PCN信息。
Both approaches are probably viable; however, since the operations of RFC 4860 have been thoroughly studied and implemented, it can be considered that the solution from RFC 4860 can better deal with the more challenging situations (rerouting in the PCN-domain, failure of a PCN-ingress-node, failure of a PCN-egress-node, rerouting towards a different edge, etc.). This is the reason for choosing Approach (1) for the specification of the signaling protocol used to carry PCN information between the PCN-boundary-nodes (PCN-ingress-node and PCN-egress-node).
这两种方法可能都是可行的；然而，由于RFC 4860的操作已被彻底研究和实施，因此可以认为RFC 4860的解决方案可以更好地处理更具挑战性的情况（PCN域中的重新路由、PCN入口节点故障、PCN出口节点故障、朝向不同边缘的重新路由等）。这就是选择方法（1）来指定用于在PCN边界节点（PCN入口节点和PCN出口节点）之间传输PCN信息的信令协议的原因。
As noted earlier, this document specifies extensions to Generic Aggregate RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-Congestion Notification.
如前所述，本文档指定了通用聚合RSVP[RFC4860]的扩展，以支持使用拥塞前通知的区分服务云上的PCN控制负载（CL）和单标记（SM）边缘行为。
This document follows the PCN signaling requirements defined in [RFC6663] and specifies extensions to Generic Aggregate RSVP [RFC4860] for support of PCN edge behaviors as specified in [RFC6661] and [RFC6662]. Moreover, this document specifies how RSVP aggregation can be used to set up and maintain (1) Ingress-Egress-Aggregate (IEA) states at Ingress and Egress nodes and (2) generic aggregation of end-to-end RSVP reservations over PCN (Congestion and Pre-Congestion Notification) domains.
本文件遵循[RFC6663]中定义的PCN信令要求，并规定了通用聚合RSVP[RFC4860]的扩展，以支持[RFC6661]和[RFC6662]中规定的PCN边缘行为。此外，本文件规定了如何使用RSVP聚合来设置和维护（1）入口和出口节点的入口-出口聚合（IEA）状态，以及（2）PCN（拥塞和拥塞前通知）域上端到端RSVP保留的通用聚合。
To comply with this specification, PCN-nodes MUST be able to support the functionality specified in [RFC5670], [RFC5559], [RFC6660], [RFC6661], and [RFC6662]. Furthermore, the PCN-boundary-nodes MUST support the RSVP generic aggregate reservation procedures specified in [RFC4860], which are augmented with procedures specified in this document.
为了符合本规范，PCN节点必须能够支持[RFC5670]、[RFC5559]、[RFC6660]、[RFC6661]和[RFC6662]中指定的功能。此外，PCN边界节点必须支持[RFC4860]中规定的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]中所述进行解释。
This document uses terms defined in [RFC4860], [RFC3175], [RFC5559], [RFC5670], [RFC6661], and [RFC6662].
本文件使用[RFC4860]、[RFC3175]、[RFC5559]、[RFC5670]、[RFC6661]和[RFC6662]中定义的术语。
For readability, a number of definitions from [RFC3175] as well as definitions for terms used in [RFC5559], [RFC6661], and [RFC6662] are provided here, where some of them are augmented with new meanings:
为了便于阅读，此处提供了[RFC3175]中的一些定义以及[RFC5559]、[RFC6661]和[RFC6662]中使用的术语的定义，其中一些定义增加了新的含义：
Aggregator The process in (or associated with) the router at the ingress edge of the aggregation region (with respect to the end-to-end RSVP reservation) and behaving in accordance with [RFC4860]. In this
聚合器聚合区域入口边缘路由器中（或与之相关）的进程（关于端到端RSVP保留），其行为符合[RFC4860]。在这个
document, it is also the PCN-ingress-node. It is important to notice that in the context of this document the Aggregator must be able to determine the Deaggregator using the procedures specified in Section 4 of [RFC4860] and Section 1.4.2 of [RFC3175].
文档，它也是PCN入口节点。需要注意的是，在本文件中，聚合器必须能够使用[RFC4860]第4节和[RFC3175]第1.4.2节中规定的程序确定解聚合器。
Congestion Level Estimate (CLE) The ratio of PCN-marked to total PCN-traffic (measured in octets) received for a given ingress-egress-aggregate during a given measurement period. The CLE is used to derive the PCN-admission-state and is also used by the report suppression procedure if report suppression is activated.
拥塞水平估计（CLE）：在给定的测量周期内，对于给定的入口-出口聚合，标记的PCN与接收的PCN总流量（以八位字节为单位）的比率。CLE用于导出PCN允许状态，如果激活了报告抑制，则报告抑制程序也将使用CLE。
Deaggregator The process in (or associated with) the router at the egress edge of the aggregation region (with respect to the end-to-end RSVP reservation) and behaving in accordance with [RFC4860]. In this document, it is also the PCN-egress-node and Decision Point.
解聚集器聚集区域出口边缘路由器中（或与之相关）的进程（关于端到端RSVP保留），其行为符合[RFC4860]。在本文档中，它也是PCN出口节点和决策点。
E2E End to end
端到端
E2E Microflow A microflow where its associated packets are being forwarded on an E2E path.
E2E微流在E2E路径上转发其相关数据包的微流。
E2E Reservation An RSVP reservation such that:
E2E预订RSVP预订，以便：
(1) corresponding RSVP Path messages are initiated upstream of the Aggregator and terminated downstream of the Deaggregator, and
(1) 相应的RSVP路径消息在聚合器的上游发起，在解聚合器的下游终止，以及
(2) corresponding RSVP Resv messages are initiated downstream of the Deaggregator and terminated upstream of the Aggregator, and
(2) 相应的RSVP Resv消息在解聚集器的下游启动，并在聚集器的上游终止，以及
(3) this RSVP reservation is aggregated over an Ingress-Egress-Aggregate (IEA) between the Aggregator and Deaggregator.
(3) 此RSVP保留通过聚合器和解聚合器之间的入口-出口聚合（IEA）进行聚合。
An E2E RSVP reservation may be a per-flow reservation, which in this document is only maintained at the PCN-ingress-node and PCN-egress-node. Alternatively, the E2E reservation may itself be an aggregate reservation of various types (e.g., Aggregate IP reservation, Aggregate IPsec reservation [RFC4860]). As per regular RSVP operations, E2E RSVP reservations are unidirectional.
E2E RSVP预留可以是每流预留，在本文档中，该预留仅在PCN入口节点和PCN出口节点维护。或者，E2E保留本身可以是各种类型的聚合保留（例如，聚合IP保留、聚合IPsec保留[RFC4860]）。根据常规RSVP操作，E2E RSVP保留是单向的。
ETM-Rate The rate of excess-traffic-marked (ETM) PCN-traffic received at a PCN-egress-node for a given ingress-egress-aggregate in octets per second.
ETM速率给定进出口聚合在PCN出口节点处接收的标记为（ETM）的PCN通信量的过量速率（以八位字节/秒为单位）。
Extended vDstPort (Extended Virtual Destination Port) An identifier used in the SESSION that remains constant over the life of the generic aggregate reservation. The length of this identifier is 32 bits when IPv4 addresses are used and 128 bits when IPv6 addresses are used.
扩展vDstPort（扩展虚拟目标端口）会话中使用的标识符，在通用聚合保留的生命周期内保持不变。当使用IPv4地址时，此标识符的长度为32位，当使用IPv6地址时，此标识符的长度为128位。
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 or 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. In this document, the Extended vDstPort should contain the IPv4 or IPv6 address of the Aggregator.
希望将会话范围缩小到发送方-接收方对（或聚合方-解聚合方对）的发送方（或聚合方）应将其IPv4或IPv6地址放在此处作为网络唯一标识符。希望与其他发件人（或聚合器）使用公共会话以跨发件人（或聚合器）使用共享保留的发件人（或聚合器）必须将此字段设置为全零。在本文档中，扩展vDstPort应包含聚合器的IPv4或IPv6地址。
Ingress-Egress-Aggregate (IEA) The collection of PCN-packets from all PCN-flows that travel in one direction between a specific pair of PCN-boundary-nodes. In this document, one RSVP generic aggregate reservation is mapped to only one ingress-egress-aggregate, while one ingress-egress-aggregate is mapped to one or more RSVP generic aggregate reservations. PCN-flows and their PCN-traffic that are mapped into a specific RSVP generic aggregate reservation can also be easily mapped into their corresponding ingress-egress-aggregate.
入口-出口聚合（IEA）从在一对特定PCN边界节点之间沿一个方向移动的所有PCN流中收集PCN数据包。在本文档中，一个RSVP通用聚合保留仅映射到一个入口-出口聚合，而一个入口-出口聚合映射到一个或多个RSVP通用聚合保留。映射到特定RSVP通用聚合保留中的PCN流及其PCN流量也可以轻松映射到其相应的入口-出口聚合中。
Microflow (from [RFC2474]) A single instance of an application-to-application flow of packets, which is identified by <source address, destination address, protocol id> and (where applicable) <source port, destination port>.
微流（来自[RFC2474]）应用程序到应用程序的数据包流的单个实例，由<source address，destination address，protocol id>和（如适用）<source port，destination port>标识。
PCN-Admission-State The state ("admit" or "block") derived by the Decision Point for a given ingress-egress-aggregate based on statistics about PCN-packet marking. The Decision Point decides to admit or block new flows offered to the aggregate based on the current value of the PCN-admission-state.
PCN接纳状态根据PCN数据包标记的统计信息，由给定入口-出口聚合的决策点导出的状态（“接纳”或“块”）。决策点根据PCN允许状态的当前值决定允许或阻止提供给聚合的新流。
PCN-Boundary-Node A PCN-node that connects one PCN-domain to a node in either another PCN-domain or a non-PCN-domain.
PCN边界节点将一个PCN域连接到另一个PCN域或非PCN域中的节点的PCN节点。
PCN-Domain A PCN-capable domain; a contiguous set of PCN-enabled nodes that perform Diffserv scheduling [RFC2474]; the complete set of PCN-nodes that in principle can, through PCN-marking packets, influence decisions about flow admission and termination within the domain; includes the PCN-egress-nodes, which measure these PCN-marks, and the PCN-ingress-nodes.
PCN结构域一个具有PCN功能的结构域；一组连续的启用PCN的节点，执行区分服务调度[RFC2474]；原则上可以通过PCN标记数据包影响域内流量接纳和终止决策的完整PCN节点集；包括测量这些PCN标记的PCN出口节点和PCN入口节点。
PCN-Egress-Node A PCN-boundary-node in its role in handling traffic as it leaves a PCN-domain. In this document, the PCN-egress-node also operates as a Decision Point and Deaggregator.
PCN出口节点PCN边界节点，在其离开PCN域时处理流量。在本文档中，PCN出口节点还作为决策点和解聚集器运行。
PCN-Flow The unit of PCN-traffic that the PCN-boundary-node admits (or terminates); the unit could be a single E2E microflow (as defined in [RFC2474]) or some identifiable collection of microflows.
PCN流量PCN边界节点允许（或终止）的PCN流量单位；该单元可以是单个E2E微流（定义见[RFC2474]）或一些可识别的微流集合。
PCN-Ingress-Node A PCN-boundary-node in its role in handling traffic as it enters a PCN-domain. In this document, the PCN-ingress-node also operates as an Aggregator.
PCN入口节点PCN边界节点，其作用是在流量进入PCN域时处理流量。在本文档中，PCN入口节点还作为聚合器运行。
PCN-Interior-Node A node in a PCN-domain that is not a PCN-boundary-node.
PCN内部节点PCN域中不是PCN边界节点的节点。
PCN-Node A PCN-boundary-node or a PCN-interior-node.
PCN节点PCN边界节点或PCN内部节点。
PCN-Sent-Rate The rate of PCN-traffic received at a PCN-ingress-node and destined for a given ingress-egress-aggregate in octets per second.
PCN Sent Rate在PCN入口节点处接收到并发送到给定入口-出口聚合的PCN通信量的速率（以八位字节/秒为单位）。
PCN-Traffic, PCN-Packets, PCN-BA A PCN-domain carries traffic of different Diffserv Behavior Aggregates (BAs) [RFC2474]. The PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the corresponding packets are PCN-packets. The same network will carry traffic of other Diffserv BAs. The PCN-BA is distinguished by a combination of the Diffserv Codepoint (DSCP) and Explicit Congestion Notification (ECN) fields.
PCN流量，PCN数据包，PCN-BA PCN域承载不同区分服务行为聚合（BAs）的流量[RFC2474]。PCN-BA使用PCN机制承载PCN流量，相应的数据包为PCN数据包。同一网络将承载其他Diffserv BAs的流量。PCN-BA通过区分服务代码点（DSCP）和显式拥塞通知（ECN）字段的组合来区分。
PHB-ID (Per Hop Behavior Identification Code) 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 [RFC3140].
PHB-ID（每跳行为标识码）一个16位字段，包含PHB或PHB集合的每跳行为标识码，从中保留区分服务资源。该字段必须按照[RFC3140]第2节的规定进行编码。
RSVP Generic Aggregate Reservation An RSVP reservation that is identified by using the RSVP SESSION object for generic RSVP aggregate reservation. This RSVP SESSION object is based on the RSVP SESSION object specified in [RFC4860], augmented with the following information:
RSVP通用聚合保留通过将RSVP会话对象用于通用RSVP聚合保留来标识的RSVP保留。此RSVP会话对象基于[RFC4860]中指定的RSVP会话对象，并添加了以下信息：
o The IPv4 DestAddress, IPv6 DestAddress should be set to the IPv4 or IPv6 destination addresses, respectively, of the Deaggregator (PCN-egress-node).
o IPv4 DestAddress、IPv6 DestAddress应分别设置为解聚集器（PCN出口节点）的IPv4或IPv6目标地址。
o The PHB-ID should be set equal to PCN-compatible Diffserv Codepoint(s).
o PHB-ID应设置为与PCN兼容的区分服务码点。
o The Extended vDstPort should be set to the IPv4 or IPv6 destination addresses, of the Aggregator (PCN-ingress-node).
o 扩展vDstPort应设置为聚合器（PCN入口节点）的IPv4或IPv6目标地址。
VDstPort (Virtual Destination Port) A 16-bit identifier used in the SESSION that remains constant over the life of the generic aggregate reservation.
VDstPort（虚拟目标端口）会话中使用的16位标识符，在通用聚合保留的生命周期内保持不变。
This document is organized as follows. Section 2 gives an overview of RSVP extensions and operations. The elements of the procedures that are used in this document are specified in Section 3. Section 4 describes the protocol elements. The security considerations are given in Section 5, and the IANA considerations are provided in Section 6.
本文件的组织结构如下。第2节概述了RSVP扩展和操作。第3节规定了本文件中使用的程序要素。第4节描述了协议元素。第5节给出了安全注意事项，第6节提供了IANA注意事项。
The PCN-boundary-nodes (see Figure 1) can support RSVP SESSIONS for generic aggregate reservations [RFC4860], which depend on ingress-egress-aggregates. In particular, one RSVP generic aggregate reservation matches to only one ingress-egress-aggregate.
PCN边界节点（见图1）可以支持通用聚合保留[RFC4860]的RSVP会话，这取决于入口-出口聚合。特别是，一个RSVP通用聚合保留仅与一个入口-出口聚合匹配。
However, one ingress-egress-aggregate matches to one or more RSVP generic aggregate reservations. In addition, to comply with this specification, the PCN-boundary-nodes need to distinguish and process (1) RSVP SESSIONS for generic aggregate sessions and their messages according to [RFC4860] and (2) E2E RSVP SESSIONS and messages according to [RFC2205].
但是，一个入口-出口聚合与一个或多个RSVP通用聚合保留相匹配。此外，为了遵守本规范，PCN边界节点需要根据[RFC4860]区分和处理（1）通用聚合会话的RSVP会话及其消息，（2）根据[RFC2205]区分和处理E2E RSVP会话和消息。
This document locates all RSVP processing for a PCN-domain at PCN-boundary-nodes. PCN-interior-nodes do not perform any RSVP functionality or maintain RSVP-related state information. Rather,
本文档在PCN边界节点定位PCN域的所有RSVP处理。PCN内部节点不执行任何RSVP功能或维护RSVP相关的状态信息。相当地
PCN-interior-nodes forward all RSVP messages (for both generic aggregate reservations [RFC4860] and E2E reservations [RFC2205]) as if they were ordinary network traffic.
PCN内部节点转发所有RSVP消息（对于通用聚合保留[RFC4860]和E2E保留[RFC2205]），就像它们是普通网络流量一样。
Moreover, each Aggregator and Deaggregator (i.e., PCN-boundary-nodes) needs to support policies to initiate and maintain, for each pair of PCN-boundary-nodes of the same PCN-domain, one ingress-egress-aggregate.
此外，每个聚合器和解聚合器（即PCN边界节点）需要支持策略，以便为同一PCN域的每对PCN边界节点启动和维护一个入口-出口聚合。
--------------------------
/ PCN-domain \
|----| | | |----|
H--| R |\ |-----| |------| /| R |-->H
H--| |\\| | |---| |---| | |//| |-->H
|----| \| | | I | | I | | |/ |----|
| Agg |======================>| Deag |
/| | | | | | | |\
H--------//| | |---| |---| | |\\-------->H
H--------/ |-----| |------| \-------->H
| |
\ /
--------------------------
--------------------------
/ PCN-domain \
|----| | | |----|
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 (PCN-ingress-node)
Deag = Deaggregator (PCN-egress-node)
I = Interior Router (PCN-interior-node)
--> = E2E RSVP reservation
==> = Aggregate RSVP reservation
H = Host requesting end-to-end RSVP reservations
R = RSVP router
Agg = Aggregator (PCN-ingress-node)
Deag = Deaggregator (PCN-egress-node)
I = Interior Router (PCN-interior-node)
--> = E2E RSVP reservation
==> = Aggregate RSVP reservation
Figure 1: Aggregation of E2E Reservations over Generic Aggregate RSVP Reservations in PCN-Domains, Based on [RFC4860]
图1：基于[RFC4860]的PCN域中E2E保留与通用聚合RSVP保留的聚合
Both the Aggregator and Deaggregator can maintain one or more RSVP generic aggregate reservations, but the Deaggregator is the entity that initiates these RSVP generic aggregate reservations. Note that one RSVP generic aggregate reservation matches to only one ingress-egress-aggregate, while one ingress-egress-aggregate matches to one or more RSVP generic aggregate reservations. This can be accomplished by using for the different RSVP generic aggregate reservations the same combinations of ingress and egress identifiers, but with a different PHB-ID value (see [RFC4860]). The procedures for aggregation of E2E reservations over generic aggregate RSVP reservations are the same as the procedures specified in Section 4 of [RFC4860], augmented with the ones specified in Section 2.5.
聚合器和解聚合器都可以维护一个或多个RSVP通用聚合保留，但解聚合器是发起这些RSVP通用聚合保留的实体。请注意，一个RSVP通用聚合保留仅与一个入口-出口聚合匹配，而一个入口-出口聚合与一个或多个RSVP通用聚合保留匹配。这可以通过为不同的RSVP通用聚合保留使用相同的入口和出口标识符组合来实现，但使用不同的PHB-ID值（参见[RFC4860]）。将E2E保留汇总到通用汇总RSVP保留的程序与[RFC4860]第4节中规定的程序相同，并增加了第2.5节中规定的程序。
One significant difference between this document and [RFC4860] is the fact that in this document the admission control of E2E RSVP reservations over the PCN-core is performed according to the PCN procedures, while in [RFC4860] this is achieved via first admitting aggregate RSVP reservations over the aggregation region and then admitting the E2E reservations over the aggregate RSVP reservations. Therefore, in this document, the RSVP generic aggregate RSVP reservations are not subject to admission control in the PCN-core, and the E2E RSVP reservations are not subject to admission control over the aggregate reservations. In turn, this means that several procedures described in [RFC4860] are significantly simplified in this document:
本文件与[RFC4860]之间的一个显著差异是，在本文件中，PCN核心上E2E RSVP保留的准入控制是根据PCN程序执行的，而在[RFC4860]中这是通过首先允许聚合区域上的聚合RSVP保留，然后允许聚合RSVP保留上的E2E保留来实现的。因此，在本文件中，RSVP通用聚合RSVP保留不受PCN核心中的准入控制，E2E RSVP保留不受聚合保留的准入控制。反过来，这意味着[RFC4860]中描述的几个程序在本文件中大大简化：
o Unlike [RFC4860], the generic aggregate RSVP reservations need not be admitted in the PCN-core.
o 与[RFC4860]不同，PCN核心中不需要接受通用聚合RSVP保留。
o Unlike [RFC4860], the RSVP aggregated traffic does not need to be tunneled between Aggregator and Deaggregator; see Section 2.3.
o 与[RFC4860]不同，RSVP聚合流量不需要在聚合器和解聚合器之间进行隧道传输；见第2.3节。
o Unlike [RFC4860], the Deaggregator need not perform admission control of E2E reservations over the aggregate RSVP reservations.
o 与[RFC4860]不同，解聚集器不需要对聚合RSVP保留执行E2E保留的接纳控制。
o Unlike [RFC4860], there is no need for dynamic adjustment of the RSVP generic aggregate reservation size; see Section 2.6.
o 与[RFC4860]不同，不需要动态调整RSVP通用聚合保留大小；见第2.6节。
The method of PCN-marking within the PCN-domain is specified in [RFC5670]. In addition, the method of encoding and transport of pre-congestion information is specified in [RFC6660]. The PHB-ID (Per Hop Behavior Identification Code) used SHOULD be set equal to PCN-compatible Diffserv Codepoint(s).
[RFC5670]中规定了PCN域内的PCN标记方法。此外，[RFC6660]中规定了预拥塞信息的编码和传输方法。使用的PHB-ID（每跳行为标识码）应设置为与PCN兼容的区分服务码点。
The PCN-ingress marks a PCN-BA using PCN-marking (i.e., a combination of the DSCP and ECN fields), which interior nodes use to classify PCN-traffic. The PCN-traffic (e.g., E2E microflows) belonging to an RSVP generic aggregate reservation can be classified only at the PCN-boundary-nodes (i.e., Aggregator and Deaggregator) by using the RSVP SESSION object for RSVP generic aggregate reservations; see Section 2.1 of [RFC4860]. Note that the DSCP value included in the SESSION object SHOULD be set equal to a PCN-compatible Diffserv Codepoint. Since no admission control procedures over the RSVP generic aggregate reservations in the PCN-core are required, unlike [RFC4860], the RSVP aggregated traffic need not be tunneled between Aggregator and Deaggregator. In this document, one RSVP generic aggregate reservation is mapped to only one ingress-egress-aggregate,
PCN入口使用PCN标记（即DSCP和ECN字段的组合）标记PCN-BA，内部节点使用该标记对PCN流量进行分类。通过使用RSVP会话对象进行RSVP通用聚合保留，属于RSVP通用聚合保留的PCN通信量（例如E2E微流）只能在PCN边界节点（即聚合器和解聚合器）进行分类；参见[RFC4860]第2.1节。请注意，会话对象中包含的DSCP值应设置为与PCN兼容的Diffserv代码点。由于与[RFC4860]不同，PCN核心中不需要对RSVP通用聚合保留进行准入控制程序，因此RSVP聚合流量不需要在聚合器和解聚合器之间进行隧道传输。在本文档中，一个RSVP通用聚合保留仅映射到一个入口-出口聚合，
while one ingress-egress-aggregate is mapped to one or more RSVP generic aggregate reservations. PCN-flows and their PCN-traffic that are mapped into a specific RSVP generic aggregate reservation can also easily be classified into their corresponding ingress-egress-aggregate. The method of traffic conditioning of PCN-traffic and non-PCN-traffic, as well as the method of PHB configuration, are described in [RFC6661] and [RFC6662].
而一个入口-出口聚合映射到一个或多个RSVP通用聚合保留。映射到特定RSVP通用聚合保留中的PCN流及其PCN通信量也可以轻松地划分为其相应的入口-出口聚合。[RFC6661]和[RFC6662]中描述了PCN流量和非PCN流量的流量调节方法以及PHB配置方法。
This document assumes the same dynamic Deaggregator determination method as that used in [RFC4860].
本文件采用与[RFC4860]中使用的动态解集器测定方法相同的方法。
To comply with this specification, for the mapping of E2E reservations onto aggregate reservations, the same methods MUST be used as the ones described in Section 4 of [RFC4860], augmented by the following rules:
为了遵守本规范，为了将E2E保留映射到聚合保留，必须使用与[RFC4860]第4节所述相同的方法，并通过以下规则进行补充：
o An Aggregator (PCN-ingress-node) or Deaggregator (PCN-egress-node and Decision Point) MUST use one or more policies to determine whether an RSVP generic aggregate reservation can be mapped into an ingress-egress-aggregate. This can be accomplished by using for the different RSVP generic aggregate reservations the same combinations of ingress and egress identifiers, but with a different PHB-ID value (see [RFC4860]) corresponding to the PCN specifications -- in particular, the RSVP SESSION object specified in [RFC4860], augmented with the following information:
o 聚合器（PCN入口节点）或解聚合器（PCN出口节点和决策点）必须使用一个或多个策略来确定RSVP通用聚合保留是否可以映射到入口-出口聚合。这可以通过为不同的RSVP通用聚合保留使用相同的入口和出口标识符组合来实现，但具有与PCN规范相对应的不同PHB-ID值（参见[RFC4860]），特别是[RFC4860]中指定的RSVP会话对象，并添加以下信息：
o The IPv4 DestAddress, IPv6 DestAddress MUST be set to the IPv4 or IPv6 destination addresses, respectively, of the Deaggregator (PCN-egress-node); see [RFC4860]. Note that the PCN-domain is considered as being only one RSVP hop (for generic aggregate RSVP or E2E RSVP). This means that the next RSVP hop for the Aggregator in the downstream direction is the Deaggregator and the next RSVP hop for the Deaggregator in the upstream direction is the Aggregator.
o IPv4 DestAddress、IPv6 DestAddress必须分别设置为解聚集器（PCN出口节点）的IPv4或IPv6目标地址；参见[RFC4860]。请注意，PCN域仅被视为一个RSVP跳（对于通用聚合RSVP或E2E RSVP）。这意味着下游方向的聚合器的下一个RSVP跳是解聚合器，上游方向的解聚合器的下一个RSVP跳是聚合器。
o The PHB-ID (Per Hop Behavior Identification Code) SHOULD be set equal to PCN-compatible Diffserv Codepoint(s).
o PHB-ID（每跳行为标识码）应设置为与PCN兼容的区分服务码点。
o The Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination addresses of the Aggregator (PCN-ingress-node); see [RFC4860].
o 扩展vDstPort应设置为聚合器（PCN入口节点）的IPv4或IPv6目标地址；参见[RFC4860]。
Since (1) no admission control of E2E reservations over the RSVP aggregate reservations is required and (2) no admission control of the RSVP aggregate reservation over the PCN-core is required, the size of the generic aggregate reservation is irrelevant and can be set to any arbitrary value by the Deaggregator. The Deaggregator SHOULD set the value of a generic aggregate reservation to a null bandwidth. We also observe that there is no need for dynamic adjustment of the RSVP aggregate reservation size.
由于（1）不需要对RSVP聚合保留进行E2E保留的许可控制，（2）不需要对PCN核心进行RSVP聚合保留的许可控制，因此通用聚合保留的大小是无关的，可以由解聚集器设置为任意值。解聚集器应将一般聚集保留的值设置为空带宽。我们还观察到，无需动态调整RSVP总保留大小。
To comply with this specification, for the update of the E2E Path ADSPEC, the same methods can be used as the ones described in [RFC4860].
为了符合本规范，对于E2E路径ADSPEC的更新，可以使用与[RFC4860]中所述相同的方法。
The PCN-interior-nodes maintain neither E2E RSVP nor RSVP generic aggregation states and reservations. Therefore, intra-domain route changes will not affect intra-domain reservations, since such reservations are not maintained by the PCN-interior-nodes.
PCN内部节点既不维护E2E RSVP，也不维护RSVP通用聚合状态和保留。因此，域内路由更改不会影响域内预留，因为这样的预留不由PCN内部节点维护。
Furthermore, it is considered that by configuration the PCN-interior-nodes can distinguish neither RSVP generic aggregate sessions and their associated messages [RFC4860] nor E2E RSVP SESSIONS and their associated messages [RFC2205].
此外，认为通过配置，PCN内部节点既不能区分RSVP通用聚合会话及其关联消息[RFC4860]，也不能区分E2E RSVP会话及其关联消息[RFC2205]。
The PCN-charter scope precludes inter-domain considerations. However, for solving inter-domain route changes associated with the operation of the RSVP messages, the same methods SHOULD be used as the ones described in [RFC4860] and in Section 1.4.7 of [RFC3175].
PCN章程范围排除了域间考虑。但是，为了解决与RSVP消息操作相关的域间路由更改，应使用与[RFC4860]和[RFC3175]第1.4.7节所述相同的方法。
PCN does not consider reservations for multicast sessions.
PCN不考虑多播会话的保留。
PCN does not consider multi-level aggregations within the PCN-domain. Therefore, the PCN-interior-nodes do not support multi-level aggregation procedures. However, the Aggregator and Deaggregator SHOULD support the multi-level aggregation procedures specified in [RFC4860] and in Section 1.4.9 of [RFC3175].
PCN不考虑PCN域内的多层次聚合。因此，PCN内部节点不支持多级聚合过程。但是，聚合器和解聚合器应支持[RFC4860]和[RFC3175]第1.4.9节中规定的多级聚合程序。
To comply with this specification, for solving possible reliability issues, the same methods MUST be used as the ones described in Section 4 of [RFC4860].
为符合本规范，为解决可能的可靠性问题，必须使用与[RFC4860]第4节所述相同的方法。
This section describes the procedures used to implement the aggregate RSVP procedure over PCN. It is considered that the procedures for aggregation of E2E reservations over generic aggregate RSVP reservations are the same as the procedures specified in Section 4 of [RFC4860], except where a departure from these procedures is explicitly described in this section. Please refer to Appendix B of [RFC2205] and Section 3 of [RFC4860] for the processing rules and error handling for the error cases listed below:
本节描述了用于在PCN上实施聚合RSVP程序的程序。一般认为，E2E保留汇总至通用汇总RSVP保留的程序与[RFC4860]第4节中规定的程序相同，除非本节中明确说明了偏离这些程序的情况。下面列出的错误案例的处理规则和错误处理请参考[RFC2205]的附录B和[RFC4860]的第3节：
o Message formatting errors, e.g., incomplete message
o 消息格式错误，例如消息不完整
o Unknown objects
o 未知物体
3.1. Receipt of E2E Path Message by PCN-Ingress-Node (Aggregating Router)
3.1. PCN入口节点（聚合路由器）接收E2E路径消息
When the E2E Path message arrives at the exterior interface of the Aggregator (PCN-ingress-node), then standard RSVP generic aggregation [RFC4860] procedures are used.
当E2E Path消息到达聚合器（PCN入口节点）的外部接口时，使用标准RSVP通用聚合[RFC4860]过程。
The E2E Path messages traverse zero or more PCN-interior-nodes. The PCN-interior-nodes receive the E2E Path message on an interior interface and forward it on another interior interface. It is considered that, by configuration, the PCN-interior-nodes ignore the E2E RSVP signaling messages [RFC2205]. Therefore, the E2E Path messages are simply forwarded as normal IP datagrams.
E2E路径消息穿过零个或多个PCN内部节点。PCN内部节点在内部接口上接收E2E路径消息，并在另一个内部接口上转发该消息。据认为，通过配置，PCN内部节点忽略E2E RSVP信令消息[RFC2205]。因此，E2E路径消息只是作为普通IP数据报转发。
3.3. Receipt of E2E Path Message by PCN-Egress-Node (Deaggregating Router)
3.3. PCN出口节点（解聚集路由器）接收E2E路径消息
When receiving the E2E Path message, the Deaggregator (PCN-egress-node and Decision Point) performs the regular procedures of [RFC4860], augmented with the following rules:
当接收到E2E Path消息时，解聚集器（PCN出口节点和决策点）执行[RFC4860]的常规程序，并增加以下规则：
o The Deaggregator MUST NOT perform the RSVP-TTL vs. IP TTL-check (TTL = Time To Live) and MUST NOT update the ADSPEC Break bit. This is because the whole PCN-domain is effectively handled by E2E RSVP as a virtual link on which integrated service is indeed supported (and admission control performed) so that the Break bit MUST NOT be set; see also [RSVP-PCN-CL].
o 解集器不得执行RSVP-TTL vs.IP TTL检查（TTL=生存时间），也不得更新ADSPEC中断位。这是因为E2E RSVP将整个PCN域有效地处理为一个虚拟链路，在该链路上确实支持集成服务（并执行准入控制），因此不能设置中断位；另见[RSVP-PCN-CL]。
The Deaggregator forwards the E2E Path message towards the receiver.
解聚集器将E2E路径消息转发给接收器。
3.4. Initiation of New Aggregate Path Message by PCN-Ingress-Node (Aggregating Router)
3.4. PCN入口节点（聚合路由器）发起新聚合路径消息
To comply with this specification, for the initiation of the new RSVP generic aggregate Path message by the Aggregator (PCN-ingress-node), the same methods MUST be used as the ones described in [RFC4860].
为了遵守本规范，对于聚合器（PCN入口节点）发起新的RSVP通用聚合路径消息，必须使用与[RFC4860]中所述相同的方法。
The Aggregate Path messages traverse zero or more PCN-interior-nodes. The PCN-interior-nodes receive the Aggregate Path message on an interior interface and forward it on another interior interface. It is considered that, by configuration, the PCN-interior-nodes ignore the Aggregate Path signaling messages. Therefore, the Aggregate Path messages are simply forwarded as normal IP datagrams.
聚合路径消息穿过零个或多个PCN内部节点。PCN内部节点在内部接口上接收聚合路径消息，并在另一个内部接口上转发该消息。据认为，通过配置，PCN内部节点忽略聚合路径信令消息。因此，聚合路径消息只是作为普通IP数据报转发。
When receiving the Aggregate Path message, the Deaggregator (PCN-egress-node and Decision Point) performs the regular procedures of [RFC4860], augmented with the following rules:
当接收到聚合路径消息时，解聚集器（PCN出口节点和决策点）执行[RFC4860]的常规过程，并增加以下规则：
o When the received Aggregate Path message by the Deaggregator contains the RSVP-AGGREGATE-IPv4-PCN-response or RSVP-AGGREGATE-IPv6-PCN-response PCN objects, which carry the PCN-sent-rate, then the procedures specified in Section 3.18 of this document MUST be followed.
o 当解聚集器接收到的聚合路径消息包含带有PCN发送速率的RSVP-AGGRATE-IPv4-PCN-response或RSVP-AGGRATE-IPv6-PCN-response PCN对象时，必须遵循本文档第3.18节中规定的过程。
When the E2E Resv message arrives at the exterior interface of the Deaggregator (PCN-egress-node and Decision Point), then standard RSVP aggregation procedures of [RFC4860] are used, augmented with the following rules:
当E2E Resv消息到达解聚集器的外部接口（PCN出口节点和决策点）时，使用[RFC4860]的标准RSVP聚合程序，并添加以下规则：
o The E2E RSVP SESSION associated with an E2E Resv message that arrives at the external interface of the Deaggregator is mapped/matched with an RSVP generic aggregate and with a PCN ingress-egress-aggregate.
o 与到达解聚集器外部接口的E2E Resv消息相关联的E2E RSVP会话与RSVP通用聚合和PCN出入聚合映射/匹配。
o Depending on the type of the PCN edge behavior supported by the Deaggregator, the PCN admission control procedures specified in Section 3.3.1 of [RFC6661] or [RFC6662] MUST be followed. Since no admission control procedures over the RSVP aggregate reservations in the PCN-core are required, unlike [RFC4860], the Deaggregator does not perform any admission control of the E2E reservation over the mapped generic aggregate RSVP reservation. If the PCN-based admission control procedure is successful, then the Deaggregator MUST allow the new flow to be admitted onto the associated RSVP generic aggregation reservation and onto the PCN ingress-egress-aggregate; see [RFC6661] and [RFC6662]. If the PCN-based admission control procedure is not successful, then the E2E Resv MUST NOT be admitted onto the associated RSVP generic aggregate reservation and onto the PCN ingress-egress-aggregation. The E2E Resv message is further processed according to [RFC4860].
o 根据解集器支持的PCN边缘行为类型，必须遵守[RFC6661]或[RFC6662]第3.3.1节中规定的PCN准入控制程序。由于与[RFC4860]不同，PCN核心中不需要对RSVP聚合保留进行准入控制程序，因此解聚集器不对映射的通用聚合RSVP保留执行E2E保留的任何准入控制。如果基于PCN的准入控制程序成功，则解聚集器必须允许新流量进入相关RSVP通用聚集保留区和PCN出入口聚集区；参见[RFC6661]和[RFC6662]。如果基于PCN的接纳控制程序未成功，则E2E Resv不得接纳到相关RSVP通用聚合保留和PCN出入口聚合中。E2E Resv消息根据[RFC4860]进一步处理。
How the PCN-admission-state is maintained is specified in [RFC6661] and [RFC6662].
[RFC6661]和[RFC6662]中规定了如何维护PCN准入状态。
The E2E Resv messages traversing the PCN-core are IP addressed to the Aggregating router and are not marked with Router Alert; therefore, the E2E Resv messages are simply forwarded as normal IP datagrams.
通过PCN核心的E2E Resv消息是IP地址到聚合路由器的，并且没有标记路由器警报；因此，E2E Resv消息只是作为普通IP数据报转发。
To comply with this specification, for the initiation of the new RSVP generic aggregate Resv message by the Deaggregator (PCN-egress-node and Decision Point), the same methods MUST be used as the ones described in Section 4 of [RFC4860], augmented with the following rules:
为了遵守本规范，对于解聚集器（PCN出口节点和决策点）发起新的RSVP通用聚合Resv消息，必须使用与[RFC4860]第4节所述相同的方法，并增加以下规则：
o The size of the generic aggregate reservation is irrelevant (see Section 2.6) and can be set to any arbitrary value by the PCN-egress-node. The Deaggregator SHOULD set the value of an RSVP generic aggregate reservation to a null bandwidth. We also observe that there is no need for dynamic adjustment of the RSVP generic aggregate reservation size.
o 通用聚合保留的大小无关（见第2.6节），可由PCN出口节点设置为任意值。解聚集器应将RSVP通用聚集保留的值设置为空带宽。我们还观察到，无需动态调整RSVP通用总保留大小。
o When [RFC6661] is used and the ETM-rate measured by the Deaggregator contains a non-zero value for some ingress-egress-aggregate (see [RFC6661] and [RFC6662]), the Deaggregator MUST request the PCN-ingress-node to provide an estimate of the rate (PCN-sent-rate) at which the Aggregator (PCN-ingress-node) is receiving PCN-traffic that is destined for the given ingress-egress-aggregate.
o 当使用[RFC6661]且解集器测量的ETM速率包含某些入口-出口聚合的非零值（请参见[RFC6661]和[RFC6662]）时，解集器必须请求PCN入口节点提供聚合器（PCN入口节点）的速率（PCN发送速率）估计值正在接收目的地为给定入口-出口聚合的PCN流量。
o When [RFC6662] is used and the PCN-admission-state computed by the Deaggregator on the basis of the CLE is "block" for the given ingress-egress-aggregate, the Deaggregator MUST request the PCN-ingress-node to provide an estimate of the rate (PCN-sent-rate) at which the Aggregator is receiving PCN-traffic that is destined for the given ingress-egress-aggregate.
o 当使用[RFC6662]且解集器根据CLE计算的PCN接纳状态为给定入口-出口聚合的“阻塞”时，解集器必须请求PCN入口节点提供速率估计值（PCN发送速率）此时聚合器正在接收目的地为给定入口-出口聚合的PCN流量。
o In the above two cases and when the PCN-sent-rate needs to be requested from the Aggregator, the Deaggregator MUST generate and send to the Aggregator a (refresh) Aggregate Resv message that MUST carry one of the following PCN objects (see Section 4.1), depending on whether IPv4 or IPv6 is supported:
o 在上述两种情况下，当需要从聚合器请求PCN发送速率时，解聚合器必须生成（刷新）聚合Resv消息并发送给聚合器，该消息必须携带以下PCN对象之一（参见第4.1节），具体取决于是否支持IPv4或IPv6：
o RSVP-AGGREGATE-IPv4-PCN-request
o RSVP-AGGREGATE-IPv4-PCN-request
o RSVP-AGGREGATE-IPv6-PCN-request
o RSVP-AGGREGATE-IPv6-PCN-request
The Aggregate Resv messages traversing the PCN-core are IP addressed to the Aggregating router and are not marked with Router Alert; therefore, the Aggregate Resv messages are simply forwarded as normal IP datagrams.
通过PCN核心的聚合Resv消息是IP地址到聚合路由器的，并且没有标记路由器警报；因此，聚合的Resv消息只是作为普通IP数据报转发。
When the E2E Resv message arrives at the interior interface of the Aggregator (PCN-ingress-node), then standard RSVP aggregation procedures of [RFC4860] are used.
当E2E Resv消息到达聚合器的内部接口（PCN入口节点）时，使用[RFC4860]的标准RSVP聚合程序。
When the Aggregate Resv message arrives at the interior interface of the Aggregator (PCN-ingress-node), then standard RSVP aggregation procedures of [RFC4860] are used, augmented with the following rules:
当聚合Resv消息到达聚合器（PCN入口节点）的内部接口时，使用[RFC4860]的标准RSVP聚合过程，并使用以下规则进行补充：
o The Aggregator SHOULD use the information carried by the PCN objects (see Section 4) and follow the steps specified in Section 3.4 of [RFC6661] and [RFC6662]. If the "R" flag carried by the RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-request PCN objects is set to ON (see Section 4.1), then the Aggregator follows the steps described in Section 3.4 of [RFC6661] and [RFC6662] on calculating the PCN-sent-rate. In particular, the Aggregator MUST provide the estimated current rate of PCN-traffic received at that node and destined for a given ingress-egress-aggregate in octets per second (the PCN-sent-rate). The way this rate estimate is derived is a matter of implementation; see [RFC6661] or [RFC6662].
o 聚合器应使用PCN对象携带的信息（见第4节），并遵循[RFC6661]和[RFC6662]第3.4节中规定的步骤。如果RSVP-AGGRATE-IPv4-PCN-request或RSVP-AGGRATE-IPv6-PCN-request PCN对象携带的“R”标志设置为ON（参见第4.1节），则聚合器在计算PCN发送速率时遵循[RFC6661]和[RFC6662]第3.4节中所述的步骤。特别是，聚合器必须提供在该节点接收并发送到给定入口-出口聚合的PCN流量的估计当前速率（以每秒八位字节为单位）（PCN发送速率）。得出该费率估算值的方式是一个实施问题；参见[RFC6661]或[RFC6662]。
o The Aggregator initiates an Aggregate Path message. In particular, when the Aggregator receives an Aggregate Resv message that carries one of the following PCN objects -- RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-request -- with the "R" flag set to ON (see Section 4.1), the Aggregator initiates an Aggregate Path message and includes the calculated PCN-sent-rate in the RSVP-AGGREGATE-IPv4-PCN-response or RSVP-AGGREGATE-IPv6-PCN-response PCN objects (see Section 4.1), which MUST be carried by the Aggregate Path message. This Aggregate Path message is sent towards the Deaggregator (PCN-egress-node and Decision Point) that requested the calculation of the PCN-sent-rate.
o 聚合器启动聚合路径消息。特别是，当聚合器接收到包含以下PCN对象之一的聚合Resv消息时——RSVP-AGGRATE-IPv4-PCN-request或RSVP-AGGRATE-IPv6-PCN-request——且“R”标志设置为ON（参见第4.1节），聚合器启动聚合路径消息，并将计算出的PCN发送速率包含在RSVP-AGGRATE-IPv4-PCN-response或RSVP-AGGRATE-IPv6-PCN-response PCN对象（参见第4.1节）中，聚合路径消息必须携带该PCN发送速率。该聚合路径消息被发送到请求计算PCN发送速率的解聚集器（PCN出口节点和决策点）。
To comply with this specification, for the removal of E2E reservations, the same methods MUST be used as the ones described in Section 4 of [RFC4860] and Section 5 of [RFC4495].
为了符合本规范，对于E2E保留的删除，必须使用与[RFC4860]第4节和[RFC4495]第5节所述相同的方法。
To comply with this specification, for the removal of RSVP generic aggregate reservations, the same methods MUST be used as the ones described in Section 4 of [RFC4860] and Section 2.10 of [RFC3175]. In particular, should an aggregate reservation go away (presumably due to a configuration change, route change, or policy event), the E2E reservations it supports are no longer active. They MUST be treated accordingly.
为符合本规范，为移除RSVP通用聚合保留，必须使用与[RFC4860]第4节和[RFC3175]第2.10节所述方法相同的方法。特别是，如果聚合保留消失（可能是由于配置更改、路由更改或策略事件），则其支持的E2E保留将不再活动。它们必须得到相应的对待。
The handling of data on the reserved E2E flow by the Aggregator (PCN-ingress-node) uses the procedures described in [RFC4860], augmented with the following:
聚合器（PCN入口节点）处理保留E2E流上的数据时，使用了[RFC4860]中描述的程序，并增加了以下内容：
o Regarding PCN-marking and traffic classification, the procedures defined in Sections 2.2 and 2.3 of this document are used.
o 关于PCN标记和交通分类，使用本文件第2.2节和第2.3节中规定的程序。
No multicast sessions are considered in this document.
本文档中不考虑多播会话。
In an event where a PCN-node is misconfigured within a PCN-domain, the desired behavior is the same as that described in Section 3.10.
如果PCN节点在PCN域内配置错误，则所需行为与第3.10节所述相同。
When the Deaggregator (PCN-egress-node and Decision Point) needs to terminate an amount of traffic associated with one ingress-egress-aggregate (see Section 3.3.2 of [RFC6661] and [RFC6662]), then several procedures for terminating E2E microflows can be deployed. The default procedure for terminating E2E microflows (i.e., PCN-flows) is as follows; see, for example, [RFC6661] and [RFC6662].
当解聚器（PCN出口节点和决策点）需要终止与一个入口出口聚合相关的流量时（参见[RFC6661]和[RFC6662]第3.3.2节），则可以部署终止E2E微流的多个程序。终止E2E微流（即PCN流）的默认程序如下：；例如，参见[RFC6661]和[RFC6662]。
For the same ingress-egress-aggregate, select a number of E2E microflows to be terminated in order to decrease the total incoming amount of bandwidth associated with one ingress-egress-aggregate by the amount of traffic to be terminated. In this situation, the same mechanisms for terminating an E2E microflow can be followed as the mechanisms specified in [RFC2205]. However, based on a local policy, the Deaggregator could use other ways of selecting which microflows should be terminated. For example, for the same ingress-egress-aggregate, select a number of E2E microflows to be terminated or to reduce their reserved bandwidth in order to decrease the total
对于相同的入口-出口聚合，选择要终止的多个E2E微流，以便将与一个入口-出口聚合相关联的总传入带宽量减少要终止的流量量。在这种情况下，终止E2E微流的机制与[RFC2205]中规定的机制相同。然而，根据当地政策，解聚集器可以使用其他方式选择应终止哪些微流。例如，对于相同的入口-出口聚合，选择要终止的许多E2E微流或减少其保留带宽以减少总带宽
incoming amount of bandwidth associated with one ingress-egress-aggregate by the amount of traffic to be terminated. In this situation, the same mechanisms for terminating an E2E microflow or reducing bandwidth associated with an E2E microflow can be followed as the mechanisms specified in Section 5 of [RFC4495].
与一个入口-出口聚合相关联的传入带宽量乘以要终止的通信量。在这种情况下，终止E2E微流或减少与E2E微流相关的带宽的机制与[RFC4495]第5节中规定的机制相同。
The protocol elements in this document are using the elements defined in Section 4 of [RFC4860] and Section 3 of [RFC3175], augmented with the following rules:
本文件中的协议元素使用了[RFC4860]第4节和[RFC3175]第3节中定义的元素，并增加了以下规则：
o The DSCP value included in the SESSION object SHOULD be set equal to a PCN-compatible Diffserv Codepoint.
o 会话对象中包含的DSCP值应设置为与PCN兼容的Diffserv代码点。
o The Extended vDstPort SHOULD be set to the IPv4 or IPv6 destination addresses of the Aggregator (PCN-ingress-node); see [RFC4860].
o 扩展vDstPort应设置为聚合器（PCN入口节点）的IPv4或IPv6目标地址；参见[RFC4860]。
o When the Deaggregator (PCN-egress-node and Decision Point) needs to request the PCN-sent-rate from the PCN-ingress-node (see Section 3.9 of this document), the Deaggregator MUST generate and send a (refresh) Aggregate Resv message to the Aggregator that MUST carry one of the following PCN objects (see Section 4.1), depending on whether IPv4 or IPv6 is supported:
o 当解聚集器（PCN出口节点和决策点）需要从PCN入口节点请求PCN发送速率时（见本文件第3.9节），解聚集器必须生成（刷新）聚合Resv消息并发送给聚合器，该聚合器必须携带以下PCN对象之一（见第4.1节），根据是否支持IPv4或IPv6：
o RSVP-AGGREGATE-IPv4-PCN-request
o RSVP-AGGREGATE-IPv4-PCN-request
o RSVP-AGGREGATE-IPv6-PCN-request
o RSVP-AGGREGATE-IPv6-PCN-request
o When the Aggregator receives an Aggregate Resv message that carries one of the following PCN objects -- RSVP-AGGREGATE-IPv4-PCN-request or RSVP-AGGREGATE-IPv6-PCN-request, with the "R" flag set to ON (see Section 4.1) -- then the Aggregator MUST generate and send to the Deaggregator an Aggregate Path message that carries one of the following PCN objects (see Section 4.1), depending on whether IPv4 or IPv6 is supported:
o 聚合器接收到包含以下PCN对象之一的聚合Resv消息时——RSVP-AGGRATE-IPv4-PCN-request或RSVP-AGGRATE-IPv6-PCN-request，且“R”标志设置为ON（参见第4.1节）--然后，聚合器必须生成并向解聚合器发送一条聚合路径消息，该消息包含以下PCN对象之一（参见第4.1节），具体取决于是否支持IPv4或IPv6：
o RSVP-AGGREGATE-IPv4-PCN-response
o RSVP-AGGREGATE-IPv4-PCN-response
o RSVP-AGGREGATE-IPv6-PCN-response
o RSVP-AGGREGATE-IPv6-PCN-response
This section describes four types of PCN objects that can be carried by the (refresh) Aggregate Path or the (refresh) Aggregate Resv messages specified in [RFC4860].
本节描述了[RFC4860]中指定的（刷新）聚合路径或（刷新）聚合Resv消息可携带的四种PCN对象。
These objects are as follows:
这些对象如下：
o RSVP-AGGREGATE-IPv4-PCN-request
o RSVP-AGGREGATE-IPv4-PCN-request
o RSVP-AGGREGATE-IPv6-PCN-request
o RSVP-AGGREGATE-IPv6-PCN-request
o RSVP-AGGREGATE-IPv4-PCN-response
o RSVP-AGGREGATE-IPv4-PCN-response
o RSVP-AGGREGATE-IPv6-PCN-response
o RSVP-AGGREGATE-IPv6-PCN-response
o RSVP-AGGREGATE-IPv4-PCN-request: PCN request object, when IPv4 addresses are used:
o RSVP-AGGREGATE-IPv4-PCN-request:PCN请求对象，使用IPv4地址时：
Class = 248 (PCN) C-Type = 1 (RSVP-AGGREGATE-IPv4-PCN-request)
Class=248（PCN）C-Type=1（RSVP-AGGREGATE-IPv4-PCN-request）
+-------------+-------------+-------------+-------------+
| IPv4 PCN-ingress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 PCN-egress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 Decision Point Address (4 bytes) |
+-------------+-------------+-------------+-------------+
|R| Reserved |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| IPv4 PCN-ingress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 PCN-egress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 Decision Point Address (4 bytes) |
+-------------+-------------+-------------+-------------+
|R| Reserved |
+-------------+-------------+-------------+-------------+
o RSVP-AGGREGATE-IPv6-PCN-request: PCN object, when IPv6 addresses are used:
o RSVP-AGGREGATE-IPv6-PCN-request:PCN对象，使用IPv6地址时：
Class = 248 (PCN) C-Type = 2 (RSVP-AGGREGATE-IPv6-PCN-request)
Class=248（PCN）C-Type=2（RSVP-AGGREGATE-IPv6-PCN-request）
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-ingress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-egress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Decision Point Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
|R| Reserved |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-ingress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-egress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Decision Point Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
|R| Reserved |
+-------------+-------------+-------------+-------------+
o RSVP-AGGREGATE-IPv4-PCN-response: PCN object, IPv4 addresses are used:
o RSVP-AGGRATE-IPv4-PCN-response:PCN对象，使用IPv4地址：
Class = 248 (PCN) C-Type = 3 (RSVP-AGGREGATE-IPv4-PCN-response)
Class=248（PCN）C-Type=3（RSVP-AGGREGATE-IPv4-PCN-response）
+-------------+-------------+-------------+-------------+
| IPv4 PCN-ingress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 PCN-egress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 Decision Point Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| PCN-sent-rate |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| IPv4 PCN-ingress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 PCN-egress-node Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| IPv4 Decision Point Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| PCN-sent-rate |
+-------------+-------------+-------------+-------------+
o RSVP-AGGREGATE-IPv6-PCN-response: PCN object, IPv6 addresses are used:
o RSVP-AGGREGATE-IPv6-PCN-response:PCN对象，使用IPv6地址：
Class = 248 (PCN) C-Type = 4 (RSVP-AGGREGATE-IPv6-PCN-response)
Class=248（PCN）C-Type=4（RSVP-AGGREGATE-IPv6-PCN-response）
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-ingress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-egress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Decision Point Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| PCN-sent-rate |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-ingress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 PCN-egress-node Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Decision Point Address (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| PCN-sent-rate |
+-------------+-------------+-------------+-------------+
The fields carried by the PCN object are specified in [RFC6663], [RFC6661], and [RFC6662]:
PCN对象携带的字段在[RFC6663]、[RFC6661]和[RFC6662]中指定：
o The IPv4 or IPv6 address of the PCN-ingress-node (Aggregator) and the IPv4 or IPv6 address of the PCN-egress-node (Deaggregator): together, they specify the ingress-egress-aggregate to which the report refers. According to [RFC6663], the report should carry the identifier of the PCN-ingress-node (Aggregator) and the identifier of the PCN-egress-node (Deaggregator) (typically their IP addresses).
o PCN入口节点（聚合器）的IPv4或IPv6地址和PCN出口节点（解聚合器）的IPv4或IPv6地址：它们一起指定报告引用的入口-出口聚合。根据[RFC6663]，报告应包含PCN入口节点（聚合器）的标识符和PCN出口节点（解聚合器）的标识符（通常是它们的IP地址）。
o Decision Point Address: specifies the IPv4 or IPv6 address of the Decision Point. In this document, this field MUST contain the IP address of the Deaggregator.
o 决策点地址：指定决策点的IPv4或IPv6地址。在此文档中，此字段必须包含解聚集器的IP地址。
o "R": 1-bit flag that, when set to ON, signifies, according to [RFC6661] and [RFC6662], that the PCN-ingress-node (Aggregator) MUST provide an estimate of the rate (PCN-sent-rate) at which the PCN-ingress-node (Aggregator) is receiving PCN-traffic that is destined for the given ingress-egress-aggregate.
o “R”：当设置为ON时，根据[RFC6661]和[RFC6662]，表示PCN入口节点（聚合器）必须提供PCN入口节点（聚合器）接收指定入口-出口聚合的PCN流量的速率（PCN发送速率）估计值的1位标志。
o "Reserved": 31 bits that are currently not used by this document and are reserved. These SHALL be set to 0 and SHALL be ignored on reception.
o “保留”：本文档当前未使用且保留的31位。这些应设置为0，并在接收时忽略。
o PCN-sent-rate: the estimate of the rate at which the PCN-ingress-node (Aggregator) is receiving PCN-traffic that is destined for the given ingress-egress-aggregate. It is expressed in octets/second; its format is a 32-bit IEEE floating-point number. The PCN-sent-rate is specified in [RFC6661] and [RFC6662].
o PCN发送速率：PCN入口节点（聚合器）接收指定入口-出口聚合的PCN流量的速率估计值。以八位字节/秒表示；其格式为32位IEEE浮点数。PCN发送速率在[RFC6661]和[RFC6662]中指定。
The security considerations specified in [RFC2205], [RFC4860], and [RFC5559] apply to this document. In addition, [RFC4230] and [RFC6411] provide useful guidance on RSVP security mechanisms.
[RFC2205]、[RFC4860]和[RFC5559]中规定的安全注意事项适用于本文件。此外，[RFC4230]和[RFC6411]为RSVP安全机制提供了有用的指导。
Security within a PCN-domain is fundamentally based on the controlled environment trust assumption stated in Section 6.3.1 of [RFC5559] -- in particular, that all PCN-nodes are PCN-enabled and are trusted to perform accurate PCN-metering and PCN-marking.
PCN域内的安全性基本上基于[RFC5559]第6.3.1节中所述的受控环境信任假设，特别是，所有PCN节点都启用了PCN，并且被信任能够执行准确的PCN计量和PCN标记。
In the PCN-domain environments addressed by this document, Generic Aggregate RSVP messages specified in [RFC4860] are used for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-Congestion Notification. Hence, the security mechanisms discussed in [RFC4860] are applicable. Specifically, the INTEGRITY object [RFC2747] [RFC3097] can be used to provide hop-by-hop RSVP message integrity, node authentication, and replay protection, thereby protecting against corruption and spoofing of RSVP messages and PCN feedback conveyed by RSVP messages.
在本文档所述的PCN域环境中，[RFC4860]中指定的通用聚合RSVP消息用于通过预拥塞通知支持区分服务云上的PCN控制负载（CL）和单标记（SM）边缘行为。因此，[RFC4860]中讨论的安全机制是适用的。具体而言，完整性对象[RFC2747][RFC3097]可用于提供逐跳RSVP消息完整性、节点身份验证和重播保护，从而防止RSVP消息和RSVP消息传递的PCN反馈的损坏和欺骗。
For these reasons, this document does not introduce significant additional security considerations beyond those discussed in [RFC5559] and [RFC4860].
出于这些原因，除了[RFC5559]和[RFC4860]中讨论的安全注意事项外，本文件没有引入其他重要的安全注意事项。
IANA has modified the "Class Names, Class Numbers, and Class Types" subregistry of the "Resource Reservation Protocol (RSVP) Parameters" registry, to add a new Class Number and assign four new C-Types under this new Class Number, as described below; see Section 4.1:
IANA已修改了“资源保留协议（RSVP）参数”注册表的“类名、类号和类类型”子区，以添加新的类号，并在此新类号下分配四个新的C类型，如下所述；见第4.1节：
Class
Number Class Name Reference
------- ---------------------- -------------
248 PCN RFC 7417
Class
Number Class Name Reference
------- ---------------------- -------------
248 PCN RFC 7417
Class Types or C-Types - 248 PCN
类别类型或C类型-248 PCN
Value Description Reference
------ ------------------------------ ------------
1 RSVP-AGGREGATE-IPv4-PCN-request RFC 7417
2 RSVP-AGGREGATE-IPv6-PCN-request RFC 7417
3 RSVP-AGGREGATE-IPv4-PCN-response RFC 7417
4 RSVP-AGGREGATE-IPv6-PCN-response RFC 7417
Value Description Reference
------ ------------------------------ ------------
1 RSVP-AGGREGATE-IPv4-PCN-request RFC 7417
2 RSVP-AGGREGATE-IPv6-PCN-request RFC 7417
3 RSVP-AGGREGATE-IPv4-PCN-response RFC 7417
4 RSVP-AGGREGATE-IPv6-PCN-response RFC 7417
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997, <http://www.rfc-editor.org/info/rfc2205>.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月<http://www.rfc-editor.org/info/rfc2205>.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001, <http://www.rfc-editor.org/info/rfc3140>.
[RFC3140]Black，D.，Brim，S.，Carpenter，B.，和F.Le Faucheur，“每跳行为识别码”，RFC 31402001年6月<http://www.rfc-editor.org/info/rfc3140>.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001, <http://www.rfc-editor.org/info/rfc3175>.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 31752001年9月<http://www.rfc-editor.org/info/rfc3175>.
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006, <http://www.rfc-editor.org/info/rfc4495>.
[RFC4495]Polk，J.和S.Dhesikan，“减少预留流带宽的资源预留协议（RSVP）扩展”，RFC 4495，2006年5月<http://www.rfc-editor.org/info/rfc4495>.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007, <http://www.rfc-editor.org/info/rfc4860>.
[RFC4860]Le Faucheur，F.，Davie，B.，Bose，P.，Christou，C.，和M.Davenport，“通用聚合资源预留协议（RSVP）预留”，RFC 48602007年5月<http://www.rfc-editor.org/info/rfc4860>.
[RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009, <http://www.rfc-editor.org/info/rfc5670>.
[RFC5670]Eardley，P.，Ed.“PCN节点的计量和标记行为”，RFC 56702009年11月<http://www.rfc-editor.org/info/rfc5670>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, July 2012, <http://www.rfc-editor.org/info/rfc6660>.
[RFC6660]Briscoe，B.，Moncaster，T.，和M.Menth，“使用单个区分服务码点（DSCP）在IP报头中编码三种拥塞前通知（PCN）状态”，RFC 66602012年7月<http://www.rfc-editor.org/info/rfc6660>.
[RFC6661] Charny, A., Huang, F., Karagiannis, G., Menth, M., and T. Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation", RFC 6661, July 2012, <http://www.rfc-editor.org/info/rfc6661>.
[RFC6661]Charny，A.，Huang，F.，Karagiannis，G.，Minth，M.，和T.Taylor，Ed.，“受控负荷（CL）运行模式下的拥塞前通知（PCN）边界节点行为”，RFC 66612012年7月<http://www.rfc-editor.org/info/rfc6661>.
[RFC6662] Charny, A., Zhang, J., Karagiannis, G., Menth, M., and T. Taylor, Ed., "Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation", RFC 6662, July 2012, <http://www.rfc-editor.org/info/rfc6662>.
[RFC6662]Charny，A.，Zhang，J.，Karagiannis，G.，Minth，M.，和T.Taylor，Ed.，“单标记（SM）运行模式下的拥塞前通知（PCN）边界节点行为”，RFC 6662，2012年7月<http://www.rfc-editor.org/info/rfc6662>.
[RFC6663] Karagiannis, G., Taylor, T., Chan, K., Menth, M., and P. Eardley, "Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain", RFC 6663, July 2012, <http://www.rfc-editor.org/info/rfc6663>.
[RFC6663]Karagiannis，G.，Taylor，T.，Chan，K.，Minth，M.，和P.Eardley，“区分服务域中拥塞前信息的信令要求”，RFC 66632012年7月<http://www.rfc-editor.org/info/rfc6663>.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994, <http://www.rfc-editor.org/info/rfc1633>.
[RFC1633]Braden，R.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 16331994年6月<http://www.rfc-editor.org/info/rfc1633>.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997, <http://www.rfc-editor.org/info/rfc2211>.
[RFC2211]Wroclawski，J.“受控负荷网元服务规范”，RFC 22111997年9月<http://www.rfc-editor.org/info/rfc2211>.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997, <http://www.rfc-editor.org/info/rfc2212>.
[RFC2212]Shenker，S.，Partridge，C.和R.Guerin，“保证服务质量规范”，RFC 2212，1997年9月<http://www.rfc-editor.org/info/rfc2212>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 24741998年12月<http://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月<http://www.rfc-editor.org/info/rfc2475>.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000, <http://www.rfc-editor.org/info/rfc2747>.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月<http://www.rfc-editor.org/info/rfc2747>.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000, <http://www.rfc-editor.org/info/rfc2753>.
[RFC2753]Yavatkar，R.，Pendarakis，D.，和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月<http://www.rfc-editor.org/info/rfc2753>.
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000, <http://www.rfc-editor.org/info/rfc2998>.
[RFC2998]Bernet，Y.，Ford，P.，Yavatkar，R.，Baker，F.，Zhang，L.，Speer，M.，Braden，R.，Davie，B.，Wroclawski，J.，和E.Felstaine，“区分服务网络上的综合服务运营框架”，RFC 29982000年11月<http://www.rfc-editor.org/info/rfc2998>.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001, <http://www.rfc-editor.org/info/rfc3097>.
[RFC3097]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月<http://www.rfc-editor.org/info/rfc3097>.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005, <http://www.rfc-editor.org/info/rfc4230>.
[RFC4230]Tschofenig，H.和R.Graveman，“RSVP安全属性”，RFC 4230，2005年12月<http://www.rfc-editor.org/info/rfc4230>.
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling in a Nested Virtual Private Network", RFC 4923, August 2007, <http://www.rfc-editor.org/info/rfc4923>.
[RFC4923]Baker，F.和P.Bose，“嵌套虚拟专用网络中的服务质量（QoS）信令”，RFC 49232007年8月<http://www.rfc-editor.org/info/rfc4923>.
[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009, <http://www.rfc-editor.org/info/rfc5559>.
[RFC5559]Eardley，P.，Ed.“拥塞前通知（PCN）体系结构”，RFC555592009年6月<http://www.rfc-editor.org/info/rfc5559>.
[RFC6411] Behringer, M., Le Faucheur, F., and B. Weis, "Applicability of Keying Methods for RSVP Security", RFC 6411, October 2011, <http://www.rfc-editor.org/info/rfc6411>.
[RFC6411]Behringer，M.，Le Faucheur，F.和B.Weis，“RSVP安全的键控方法的适用性”，RFC 64112011年10月<http://www.rfc-editor.org/info/rfc6411>.
[RSVP-PCN-CL] Le Faucheur, F., Charny, A., Briscoe, B., Eardley, P., Babiarz, J., and K. Chan, "RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN)", Work in Progress, draft-lefaucheur-rsvp-ecn-01, June 2006.
[RSVP-PCN-CL]Le Faucheur，F.，Charny，A.，Briscoe，B.，Eardley，P.，Babiarz，J.，和K.Chan，“使用拥塞前通知（PCN）对区分服务进行准入控制的RSVP扩展”，正在进行的工作，草案-lefaucheur-RSVP-ecn-01，2006年6月。
This appendix is based on Appendix A of [RFC4860]. In particular, it provides an example signaling flow of the specifications detailed in Sections 3 and 4.
本附录基于[RFC4860]的附录A。具体而言，它提供了第3节和第4节中详述的规范的示例信令流。
This signaling flow assumes an environment where E2E reservations are aggregated over generic aggregate RSVP reservations and applied over a PCN-domain. In particular, the Aggregator (PCN-ingress-node) and Deaggregator (PCN-egress-node) are located at the boundaries of the PCN-domain. The PCN-interior-nodes are located within the PCN-domain, between the PCN-boundary-nodes, but are not shown in the diagram below. 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 Aggregator-Deaggregator pair.
该信令流假设一个环境，其中E2E保留在通用聚合RSVP保留上聚合，并在PCN域上应用。具体而言，聚合器（PCN入口节点）和解聚合器（PCN出口节点）位于PCN域的边界处。PCN内部节点位于PCN域内，位于PCN边界节点之间，但未在下图中显示。它说明了在成功建立单播E2E保留时可能发生的RSVP消息流，该保留是给定聚合器-解聚合器对之间的第一个保留。
Aggregator (PCN-ingress-node) Deaggregator (PCN-egress-node)
聚合器（PCN入口节点）解聚合器（PCN出口节点）
E2E Path
----------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(NEW-AGGREGATE-NEEDED,SOI=GApcn)
<----------------------------------------
(3)
AggPath(Session=GApcn)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (Session=GApcn) (PCN object)
<-------------------------------
(6)
AggResvConfirm (Session=GApcn)
------------------------------>
(7)
E2E Resv
<---------
(8)
E2E Resv (SOI=GApcn)
<-----------------------------
(9)
E2E Resv
<-----------
E2E Path
----------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(NEW-AGGREGATE-NEEDED,SOI=GApcn)
<----------------------------------------
(3)
AggPath(Session=GApcn)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (Session=GApcn) (PCN object)
<-------------------------------
(6)
AggResvConfirm (Session=GApcn)
------------------------------>
(7)
E2E Resv
<---------
(8)
E2E Resv (SOI=GApcn)
<-----------------------------
(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 that 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 an Aggregate Path state for the PCN PHB-ID. To do that, the Deaggregator sends an E2E PathErr message with a NEW-AGGREGATE-NEEDED PathErr code.
(2) 假设不存在聚合路径。为了能够准确地更新E2E路径的ADSPEC，解聚集器需要聚合路径的ADSPEC。在此示例中，解聚集器选择指示聚合器为PCN PHB-ID设置聚合路径状态。为此，解聚集器发送一条E2E PathErr消息，其中包含新的聚合所需的PathErr代码。
The PathErr message also contains a SESSION-OF-INTEREST (SOI) object. The SOI contains a GENERIC-AGGREGATE SESSION (GApcn) whose PHB-ID is set to the PCN PHB-ID. The GENERIC-AGGREGATE SESSION contains an interface-independent Deaggregator address inside the DestAddress and appropriate values inside the vDstPort and Extended vDstPort fields. In this document, the Extended vDstPort SHOULD contain the IPv4 or IPv6 address of the Aggregator.
PathErr消息还包含感兴趣的会话（SOI）对象。SOI包含一个通用聚合会话（GApcn），其PHB-ID设置为PCN PHB-ID。通用聚合会话在DestAddress中包含一个独立于接口的解聚合器地址，在vDstPort和扩展vDstPort字段中包含适当的值。在本文档中，扩展vDstPort应包含聚合器的IPv4或IPv6地址。
(3) The Aggregator follows the request from the Deaggregator and signals an Aggregate Path for the GENERIC-AGGREGATE SESSION (GApcn).
(3) 聚合器跟踪来自解聚合器的请求，并发出通用聚合会话（GApcn）的聚合路径信号。
(4) The Deaggregator takes into account the information contained in the ADSPEC from both Aggregate Paths and updates the E2E Path ADSPEC accordingly. The PCN-egress-node MUST NOT perform the RSVP-TTL vs. IP TTL-check and MUST NOT update the ADSPEC Break bit. This is because the whole PCN-domain is effectively handled by E2E RSVP as a virtual link on which integrated service is indeed supported (and admission control performed) so that the Break bit MUST NOT be set; see also [RSVP-PCN-CL]. The Deaggregator also modifies the E2E Path IP protocol number to RSVP before forwarding it.
(4) 解聚集器考虑来自两个聚合路径的ADSPEC中包含的信息，并相应地更新E2E路径ADSPEC。PCN出口节点不得执行RSVP-TTL vs.IP TTL检查，且不得更新ADSPEC中断位。这是因为E2E RSVP将整个PCN域有效地处理为一个虚拟链路，在该链路上确实支持集成服务（并执行准入控制），因此不能设置中断位；另见[RSVP-PCN-CL]。在转发之前，解聚集器还将E2E路径IP协议号修改为RSVP。
(5) In this example, the Deaggregator elects to immediately proceed with establishment of the generic aggregate reservation. In effect, the Deaggregator can be seen as anticipating the actual demand of E2E reservations so that the generic aggregate reservation is in place when the E2E Resv request arrives, in order to speed up establishment of E2E reservations. Here it is also assumed that the Deaggregator includes the optional ResvConfirm Request in the Aggregate Resv message.
(5) 在此示例中，解聚集器选择立即开始建立通用聚集保留。实际上，解聚集器可被视为预测E2E预订的实际需求，以便在E2E Resv请求到达时，通用聚合预订到位，以加快E2E预订的建立。这里还假设解聚集器在聚合Resv消息中包含可选的ResvConfig请求。
(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 the generic aggregate reservation is established.
(7) 解聚集器已明确确认已建立通用聚集保留。
(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 the PCN PHB-ID=x. After the previous step (7), the Deaggregator knows that a generic aggregate reservation (GApcn) is in place for the corresponding PHB-ID. At this step, the Deaggregator maps the generic aggregate reservation onto one ingress-egress-aggregate maintained by the Deaggregator (as a PCN-egress-node); see Section 3.7. The Deaggregator performs admission control of the E2E Resv onto the generic aggregate reservation for the PCN PHB-ID (GApcn). The Deaggregator also takes into account the PCN admission control procedure as specified in [RFC6661] and [RFC6662]; see Section 3.7. If one or both of the admission control procedures (the PCN-based admission control procedure described in Section 3.3.1 of [RFC6661] or [RFC6662], and the admission control procedure specified in [RFC4860]) are not successful, then the E2E Resv is not admitted onto the associated RSVP generic aggregate reservation for the PCN PHB-ID (GApcn). Otherwise, assuming that the generic aggregate reservation for the PCN (GApcn) 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 conveying the selected mapping onto GApcn (and hence onto the PCN PHB-ID).
(8) 收到E2E Resv后，解聚集器应用网络管理员定义的映射策略将E2E Resv映射到通用聚合保留上。让我们假设此策略使得E2E保留映射到PCN PHB-ID=x的通用聚合保留。在上一步骤（7）之后，解聚集器知道对应PHB-ID的通用聚集保留（GApcn）已就位。在该步骤中，解聚集器将通用聚集保留映射到由解聚集器维护的一个入口-出口聚集上（作为PCN出口节点）；见第3.7节。解聚集器对PCN PHB-ID（GApcn）的通用聚合预订执行E2E Resv的准入控制。解集器还考虑了[RFC6661]和[RFC6662]中规定的PCN准入控制程序；见第3.7节。如果一个或两个准入控制程序（第[RFC6661]或[RFC6662]第3.3.1节中描述的基于PCN的准入控制程序，以及第[RFC4860]节中指定的准入控制程序）未成功，则E2E Resv不会被接纳到PCN PHB-ID（GApcn）的相关RSVP通用聚合保留中。否则，假设PCN的通用聚合保留（GApcn）已建立，具有足够的带宽来支持E2E Resv，则解聚集器调整其计数器，跟踪通用聚合保留上未使用的带宽。然后，它将E2E Resv转发给聚合器，包括一个感兴趣的会话对象，该对象将所选映射传递到GApcn（从而传递到PCN PHB-ID）。
(9) The Aggregator records the mapping of the E2E Resv onto GApcn (and onto the PCN PHB-ID). The Aggregator removes the SOI object and forwards the E2E Resv towards the sender.
(9) 聚合器记录E2E Resv到GApcn（和PCN PHB-ID）的映射。聚合器删除SOI对象并将E2E Resv转发给发送方。
Acknowledgments
致谢
We would like to thank the authors of [RSVP-PCN-CL], since some ideas used in this document are based on the work initiated in [RSVP-PCN-CL]. Moreover, we would like to thank Bob Briscoe, David Black, Ken Carlberg, Tom Taylor, Philip Eardley, Michael Menth, Toby Moncaster, James Polk, Scott Bradner, Lixia Zhang, and Robert Sparks for the provided comments. In particular, we would like to thank Francois Le Faucheur for contributing a significant amount of text, in addition to his comments.
我们要感谢[RSVP-PCN-CL]的作者，因为本文件中使用的一些想法是基于[RSVP-PCN-CL]中发起的工作。此外，我们还要感谢鲍勃·布里斯科、大卫·布莱克、肯·卡尔伯格、汤姆·泰勒、菲利普·埃尔德利、迈克尔·门特、托比·蒙卡斯特、詹姆斯·波尔克、斯科特·布拉德纳、张丽霞和罗伯特·斯帕克斯提供的评论。特别是，我们要感谢弗朗索瓦·勒·福彻除了他的评论之外，还提供了大量的文本。
Authors' Addresses
作者地址
Georgios Karagiannis Huawei Technologies Hansaallee 205 40549 Dusseldorf Germany
格奥尔吉奥斯·卡拉吉安尼斯华为技术有限公司汉萨勒205 40549德国杜塞尔多夫
EMail: Georgios.Karagiannis@huawei.com
EMail: Georgios.Karagiannis@huawei.com
Anurag Bhargava Cisco Systems, Inc. 7100-9 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709-4987 United States
美国北卡罗来纳州三角研究园14987号吉特克里克路7100-9号邮箱Anurag Bhargava Cisco Systems，Inc.邮编：27709-4987
EMail: anuragb@cisco.com
EMail: anuragb@cisco.com