[要約] RFC 7417は、IPv4およびIPv6の予約に対するPre-Congestion Notification（PCN）ドメイン上の汎用集約RSVPの拡張に関するものです。このRFCの目的は、PCNドメインでの予約の効率的な管理と制御を可能にするための拡張を提供することです。
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.
このドキュメントでは、PCNを使用したDiffservクラウドでの輻輳前通知（PCN）制御負荷（CL）およびシングルマーキング（SM）エッジの動作をサポートするためのGeneric Aggregate RSVP（RFC 4860）の拡張について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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）を、シンプルでスケーラブルで堅牢な方法でサポートできます。アドミッションコントロールとフロー終了の2つのメカニズムが使用されます。アドミッション制御は、新しいフロー要求を許可するかブロックするかを決定するために使用され、フロー終了は、異常な状況で、既存のフローの一部を終了するかどうかを決定するために使用されます。これら2つの機能をサポートするために、PCNトラフィックの全体的なレートはドメイン内のすべてのリンクで計測され、特定の構成されたレートを超えるとPCNパケットが適切にマークされます。これらの構成されたレートはリンクのレートを下回るため、輻輳が発生する前に過負荷について境界ノードに通知されます（したがって「輻輳前」通知）。 PCN-egress-nodeは、異なる間隔でマークされたPCNトラフィックのレートを定期的な間隔で測定し、アドミッション制御とフロー終了のためにこれらのレートをディシジョンポイントに報告します。ディシジョンポイントは、これらのレートを使用して決定を下します。ディシジョンポイントは、PCN-ingress-nodeと同じ場所に配置することも、その機能を別のノードに実装することもできます。詳細については、[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 Decision PointがPCN-egress-nodeと併置されていない場合は、このドキュメントの範囲外の追加のシグナリング手順が必要です。さらに、前述のように、このアーキテクチャはポリシーベースのアドミッションコントロール（PBAC）に準拠しており、決定ポイントはPCN-ingress-node以外のノードに配置されます[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-ingress-nodeとPCN-egress-node）の間で情報を伝送できます。ただし、（1）PCN-egress-nodeとPCN-ingress-nodeの両方がデータパス上にあり、（2）アドミッション制御手順はPCN-egress-nodeで行う必要があるため、以下のシグナリングプロトコルRSVPのように、データパスと同じパスがこの目的により適しています。特に、このドキュメントでは、事前輻輳通知を使用したDiffservクラウド上でのPCN制御負荷（CL）およびシングルマーキング（SM）エッジの動作をサポートするためのGeneric Aggregate RSVP [RFC4860]の拡張について説明します。
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.
このドキュメントで指定されている手法のサポートには、内部ノードがRSVP機能を実行せずにRSVPトラフィックを転送するPCNドメインの境界ノードの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によって2つの主要な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シグナリングプロトコルの1つはRSVP [RFC2205]で、アプリケーションがネットワークからフローごとのリソースを要求するために使用できます。これらのRSVP要求は、ネットワークで許可または拒否できます。アプリケーションは、[RFC2211]および[RFC2212]で定義されているIntservパラメータを使用して、定量化可能なリソース要件を表現できます。 Controlled Load（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 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.
Diffservアーキテクチャは、非常に大規模な環境でのパケットの差別化された処理をサポートできます。 IntservおよびRSVPはフローごとにパケットを分類しますが、Diffservネットワークは、パケットIPヘッダーのDiffservコードポイント（DSCP）に基づいて、パケットを少数の集約フローまたは「クラス」のいずれかに分類します。各Diffservルーターでは、パケットはDSCPによって呼び出される「ホップごとの動作」（PHB）の影響を受けます。 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には、アプリケーションとネットワーク間の通信のメカニズムは含まれていません。この問題を解決するためにいくつかのソリューションが指定されています。これらのソリューションの1つは、Intserv over Diffserv [RFC2998]です。これには、リソースベースのアドミッションコントロール（RBAC）、PBAC、トラフィックの識別/分類の支援、およびトラフィックの調整が含まれます。 Intserv over Diffservは、静的にプロビジョニングされた、またはRSVP対応のDiffservリージョン上で動作できます。 RSVPに対応している場合、動的なプロビジョニングとトポロジー対応のアドミッション制御をサポートするために、集約RSVP予約、フローごとのRSVP、または帯域幅ブローカーなど、いくつかのメカニズムを使用できます。 [RFC3175]は、RSVPの予約全体に対するRSVPのエンドツーエンドの予約の集計を指定します。 [RFC3175]では、RSVP汎用集約予約は、3つのタプル<送信元IPアドレス、宛先IPアドレス、Diffservコードポイント>を使用するRSVP SESSIONオブジェクトによって特徴付けられます。
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
いくつかのシナリオでは、特定の送信元IPアドレスから特定の宛先IPアドレスへの特定のPHBに対して確立された複数の汎用集計予約を使用する必要があります。 [RFC4923]と[RFC4860]を参照してください。たとえば、複数の汎用集約予約は、異なるプリエンプション優先度を使用する複数のエンドツーエンド（E2E）予約を、同じPHBを使用するPCNドメインを通じて集約する必要がある場合に適用できます。同じ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]では、ネストされたVPN環境でRSVP集約を介してエンドツーエンドの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 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.
[RFC4860]は、[RFC3175]を拡張して、同じ送信元IPアドレス、宛先IPアドレス、およびPHB（またはPHBのセット）に対する複数の集約予約をサポートすることにより、汎用的な集約予約を提供します。特に、特定の送信元IPアドレスから特定の宛先IPアドレスへの特定のPHBに対して、複数のこのような汎用集計予約を確立できます。これは、RSVP SESSIONオブジェクトに仮想宛先ポートと拡張仮想宛先ポートの概念を追加することで実現されます。これに加えて、一般的な集合予約のRSVP SESSIONオブジェクトは、[RFC3175]で使用されるDiffservコードポイント（DSCP）を使用する代わりに、[RFC3140]で定義されるPHB識別コード（PHB-ID）を使用します。 PHB-IDは、Diffservリソースが予約される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-egress-nodeからPCN-ingress-nodeへのリクエスト、および（2）PCN-ingress-nodeからPCN-egress-nodeへのレポートを伝送するために必要なRSVPのようなシグナリングプロトコルは、 [RFC6663]で定義されているPCNシグナリング要件。それに加えて、PCN-ingress-nodesとPCN-egress-nodesでサポートされるシグナリングプロトコル機能は、論理的な集約構造（つまり、ingress-egress-aggregate状態）を維持し、E2E予約をこれらの集約構造にマッピングできる必要があります。 。さらに、実際の予約状態をPCNドメイン内で維持する必要はありません。つまり、PCN内部ノードは予約状態を維持していません。
This can be accomplished by two possible approaches:
これは、次の2つの方法で実現できます。
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-ingress-nodeとPCN-egress-node）間で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の集約手順を適合させ、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-egress-nodeの障害、別のエッジへの再ルーティングなど）。これが、PCN境界ノード（PCN-ingress-nodeとPCN-egress-node）間でPCN情報を伝達するために使用されるシグナリングプロトコルの仕様にアプローチ（1）を選択する理由です。
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.
前述のように、このドキュメントでは、輻輳前通知を使用したDiffservクラウドでのPCN制御負荷（CL）およびシングルマーキング（SM）エッジの動作をサポートするためのGeneric Aggregate RSVP [RFC4860]の拡張を指定します。
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エッジ動作をサポートするために、[RFC6663]で定義されているPCNシグナリング要件に従い、Generic Aggregate RSVP [RFC4860]への拡張を指定します。さらに、このドキュメントでは、RSVP集約を使用して（1）Ingress-Egress-Aggregate（IEA）状態をIngressノードとEgressノードで設定し、維持する方法と、（2）エンドツーエンドのRSVP予約の一般的な集約（PCN経由）（輻輳および輻輳前通知）ドメイン。
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-boundary-nodesは、[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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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 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].
Aggregator（エンドツーエンドRSVP予約に関して）集約領域の入口エッジにあるルーター内の（またはルーターに関連付けられた）プロセスであり、[RFC4860]に従って動作します。このドキュメントでは、これは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.
Congestion Level Estimate（CLE）特定の測定期間中に特定のingress-egress-aggregateで受信されたPCNトラフィックの合計（オクテットで測定）に対するPCNマークの比率。 CLEはPCN-admission-stateを導出するために使用され、レポート抑制がアクティブ化されている場合はレポート抑制手順でも使用されます。
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.
Deaggregator（エンドツーエンドのRSVP予約に関して）集約領域の出口エッジにあるルーター内の（または関連付けられた）プロセスであり、[RFC4860]に従って動作します。このドキュメントでは、PCN-egress-nodeおよびDecision Pointでもあります。
E2E End to end
E2Eエンドツーエンド
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予約は、AggregatorとDeaggregatorの間のIngress-Egress-Aggregate（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-ingress-nodeとPCN-egress-nodeでのみ維持されます。あるいは、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-Rate特定のingress-egress-aggregateのPCN-egress-nodeで受信された超過トラフィックマーク（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（拡張仮想宛先ポート）SESSIONで使用される識別子であり、一般的な集約予約の存続期間を通じて一定です。この識別子の長さは、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.
SESSIONのスコープを送信者と受信者のペア（またはAggregator-Deaggregatorのペア）に限定したい送信者（または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.
Ingress-Egress-Aggregate（IEA）特定のPCN境界ノードのペア間を一方向に移動するすべてのPCNフローからのPCNパケットのコレクション。このドキュメントでは、1つのRSVP汎用集約予約が1つのingress-egress-aggregateにのみマッピングされ、1つのingress-egress-aggregateが1つ以上の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>.
Microflow（[RFC2474]から）アプリケーション間のパケットフローの単一インスタンス。これは、<送信元アドレス、宛先アドレス、プロトコルID>および（該当する場合）<送信元ポート、宛先ポート>によって識別されます。
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-Admission-State PCNパケットマーキングに関する統計に基づいて、特定の入力-出力-集約の決定ポイントによって導出された状態（「許可」または「ブロック」）。ディシジョンポイントは、PCN-admission-stateの現在の値に基づいて、集約に提供される新しいフローを許可するかブロックするかを決定します。
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境界ノード1つの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対応ドメイン。 Diffservスケジューリング[RFC2474]を実行するPCN対応ノードの連続セット。原則として、PCNマーキングパケットを通じて、ドメイン内のフローアドミッションとターミネーションに関する決定に影響を与えるPCNノードの完全なセット。これらのPCNマークを測定するPCN-egress-nodeと、PCN-ingress-nodeが含まれます。
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-Egress-Node PCNドメインを離れるときにトラフィックを処理する役割を持つPCN境界ノード。このドキュメントでは、PCN-egress-nodeはDecision PointおよびDeaggregatorとしても機能します。
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-Ingress-Node PCNドメインに入るときにトラフィックを処理する役割を持つPCN境界ノード。このドキュメントでは、PCN-ingress-nodeもAggregatorとして動作します。
PCN-Interior-Node A node in a PCN-domain that is not a PCN-boundary-node.
PCN-Interior-Node 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-ingress-nodeで受信され、特定のingress-egress-aggregateを宛先とする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ドメインは、さまざまなDiffserv Behavior Aggregates（BA）のトラフィックを伝送します[RFC2474]。 PCN-BAはPCNメカニズムを使用してPCNトラフィックを伝送し、対応するパケットはPCNパケットです。同じネットワークが他のDiffserv BAのトラフィックを伝送します。 PCN-BAは、Diffserv Codepoint（DSCP）フィールドとExplicit Congestion Notification（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（ホップごとの動作識別コード）Diffservリソースが予約されるPHBまたはPHBのセットのホップごとの動作識別コードを含む16ビットのフィールド。このフィールドは、[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 Generic Aggregate Reservation汎用RSVP集約予約のRSVP SESSIONオブジェクトを使用して識別されるRSVP予約。このRSVP SESSIONオブジェクトは、[RFC4860]で指定されているRSVP SESSIONオブジェクトに基づいており、次の情報が追加されています。
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-egress-node）のIPv4またはIPv6宛先アドレスに設定する必要があります。
o The PHB-ID should be set equal to PCN-compatible Diffserv Codepoint(s).
o PHB-IDは、PCN互換のDiffservコードポイントと同じに設定する必要があります。
o The Extended vDstPort should be set to the IPv4 or IPv6 destination addresses, of the Aggregator (PCN-ingress-node).
o 拡張vDstPortは、アグリゲーター（PCN-ingress-node）の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（仮想宛先ポート）SESSIONで使用される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に記載されており、IANAに関する考慮事項はセクション6に記載されています。
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-boundary-nodes（図1を参照）は、ingress-egress-aggregatesに依存する汎用集約予約[RFC4860]のRSVP SESSIONSをサポートできます。特に、1つのRSVP汎用集約予約は、1つのingress-egress-aggregateにのみ一致します。
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].
ただし、1つのingress-egress-aggregateは、1つ以上のRSVP汎用集約予約と一致します。さらに、この仕様に準拠するために、PCN境界ノードは、（1）[RFC4860]による汎用集約セッションのRSVP SESSIONSとそのメッセージ、および（2）E2E RSVP SESSIONSおよび[RFC2205によるメッセージを区別して処理する必要があります。 ]。
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-interior-nodes forward all RSVP messages (for both generic aggregate reservations [RFC4860] and E2E reservations [RFC2205]) as if they were ordinary network traffic.
このドキュメントでは、PCN-boundary-nodesでPCNドメインのすべてのRSVP処理を見つけます。 PCN-interior-nodeは、RSVP機能を実行したり、RSVP関連の状態情報を維持したりしません。むしろ、PCN-interior-nodesは、通常のネットワークトラフィックであるかのように、すべての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境界ノードのペアごとに、1つのingress-egress-aggregateを開始および維持するポリシーをサポートする必要があります。
--------------------------
/ 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
Figure 1: Aggregation of E2E Reservations over Generic Aggregate RSVP Reservations in PCN-Domains, Based on [RFC4860]
図1：[RFC4860]に基づく、PCNドメインでの汎用的な集約RSVP予約を介したE2E予約の集約
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.
AggregatorとDeaggregatorはどちらも1つ以上のRSVP汎用集約予約を維持できますが、DeaggregatorはこれらのRSVP汎用集約予約を開始するエンティティです。 1つのRSVPジェネリック集約予約は1つのingress-egress-aggregateにのみ一致し、1つのingress-egress-aggregateは1つ以上のRSVPジェネリック集約予約に一致することに注意してください。これは、異なるRSVP汎用集約予約に対して、入力IDと出力IDの同じ組み合わせを使用して、ただしPHB-ID値を変更することで実現できます（[RFC4860]を参照）。一般的な集約RSVP予約を介したE2E予約の集約手順は、[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]の1つの重要な違いは、このドキュメントでは、PCNコアを介したE2E RSVP予約のアドミッションコントロールがPCN手順に従って実行されるという事実です。集約領域を介した予約、および集約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]とは異なり、汎用の集約RSVP予約はPCNコアで許可される必要はありません。
o Unlike [RFC4860], the RSVP aggregated traffic does not need to be tunneled between Aggregator and Deaggregator; see Section 2.3.
o [RFC4860]とは異なり、RSVPで集約されたトラフィックは、AggregatorとDeaggregatorの間でトンネリングする必要はありません。セクション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).
PCNドメイン内でのPCNマーキングの方法は、[RFC5670]で指定されています。また、輻輳前情報の符号化と転送の方法は、[RFC6660]で指定されています。使用するPHB-ID（ホップごとの動作識別コード）は、PCN互換のDiffservコードポイントに設定する必要があります（SHOULD）。
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, 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].
PCN入力は、内部ノードがPCNトラフィックを分類するために使用するPCNマーキング（つまり、DSCPフィールドとECNフィールドの組み合わせ）を使用してPCN-BAをマークします。 RSVPジェネリック集約予約に属するPCNトラフィック（E2Eマイクロフローなど）は、RSVPジェネリック集約予約のRSVP SESSIONオブジェクトを使用して、PCN境界ノード（つまり、アグリゲーターとデアグリゲーター）でのみ分類できます。 [RFC4860]のセクション2.1を参照してください。 SESSIONオブジェクトに含まれるDSCP値は、PCN互換のDiffservコードポイントと等しく設定する必要があることに注意してください。 [RFC4860]とは異なり、PCNコアでのRSVP汎用集約予約に対するアドミッション制御手順は必要ないため、RSVP集約トラフィックはAggregatorとDeaggregatorの間でトンネリングする必要はありません。このドキュメントでは、1つのRSVP汎用集約予約が1つのingress-egress-aggregateにのみマッピングされ、1つのingress-egress-aggregateが1つ以上のRSVP汎用集約予約にマッピングされています。特定のRSVP総集約予約にマッピングされるPCNフローとそれらのPCNトラフィックも、対応する入力-出力-集約に簡単に分類できます。 PCNトラフィックと非PCNトラフィックのトラフィック調整の方法、およびPHB設定の方法については、[RFC6661]と[RFC6662]で説明されています。
This document assumes the same dynamic Deaggregator determination method as that used in [RFC4860].
このドキュメントは、[RFC4860]で使用されるものと同じ動的Deaggregator決定方法を想定しています。
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 Aggregator（PCN-ingress-node）またはDeaggregator（PCN-egress-nodeおよびDecision Point）は、1つ以上のポリシーを使用して、RSVP汎用集約予約をingress-egress-aggregateにマッピングできるかどうかを決定する必要があります。これは、異なるRSVPジェネリック集約予約に対して、入力IDと出力IDの同じ組み合わせを使用して、PCN仕様（特にRSVP SESSIONオブジェクト）に対応するPHB-ID値（[RFC4860]を参照）が異なることで実現できます。 [RFC4860]で指定されており、次の情報が追加されています。
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-egress-node）のIPv4またはIPv6宛先アドレスに設定する必要があります。 [RFC4860]を参照してください。 PCNドメインは、1つの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互換のDiffservコードポイントに設定する必要があります（SHOULD）。
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-ingress-node）のIPv4またはIPv6宛先アドレスに設定する必要があります（SHOULD）。 [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集約予約のアドミッション制御は不要であるため、汎用集約予約のサイズは無関係であり、設定できますDeaggregatorによって任意の値に。 Deaggregatorは、一般的な集約予約の値をnull帯域幅に設定する必要があります（SHOULD）。また、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-interior-nodeは、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-interior-nodeは、構成によって、RSVP汎用集約セッションとそれらに関連するメッセージ[RFC4860]もE2E RSVP SESSIONSおよびそれらに関連するメッセージ[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で説明されている方法と同じ方法を使用する必要があります（SHOULD）。
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-interior-nodeはマルチレベルの集計手順をサポートしていません。ただし、アグリゲーターとデアグリゲーターは、[RFC4860]および[RFC3175]のセクション1.4.9で指定されているマルチレベルの集計手順をサポートする必要があります（SHOULD）。
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手順を実装するために使用される手順について説明します。一般的な集約RSVP予約に対するE2E予約の集約手順は、[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-Ingress-Node（集約ルーター）による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パスメッセージがアグリゲータの外部インターフェイス（PCN-ingress-node）に到着すると、標準の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パスメッセージは、0個以上のPCN内部ノードを通過します。 PCN-interior-nodeは、内部インターフェイスでE2Eパスメッセージを受信し、別の内部インターフェイスで転送します。構成により、PCN-interior-nodeはE2E RSVPシグナリングメッセージ[RFC2205]を無視すると見なされます。したがって、E2Eパスメッセージは通常のIPデータグラムとして転送されるだけです。
3.3. Receipt of E2E Path Message by PCN-Egress-Node (Deaggregating Router)
3.3. PCN-Egress-Node（Deaggregating Router）による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パスメッセージを受信すると、デアグリゲーター（PCN-egress-nodeおよびDecision Point）は、[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対IP TTLチェック（TTL =存続時間）を実行してはならず（MUST NOT）、ADSPECブレークビットを更新してはなりません（MUST NOT）。これは、PC2ドメイン全体がE2E RSVPによって統合サービスが実際にサポートされている（そしてアドミッションコントロールが実行されている）仮想リンクとして効果的に処理されるため、Breakビットを設定してはならないためです。 [RSVP-PCN-CL]も参照してください。
The Deaggregator forwards the E2E Path message towards the receiver.
DeaggregatorはE2E Pathメッセージを受信者に転送します。
3.4. Initiation of New Aggregate Path Message by PCN-Ingress-Node (Aggregating Router)
3.4. PCN-Ingress-Node（集約ルーター）による新しい集約パスメッセージの開始
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-ingress-node）による新しい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.
集約パスメッセージは、0個以上のPCN内部ノードを通過します。 PCN-interior-nodeは、内部インターフェイスで集約パスメッセージを受信し、別の内部インターフェイスで転送します。構成により、PCN-interior-nodeは集約パスシグナリングメッセージを無視すると見なされます。したがって、Aggregate Pathメッセージは通常の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-egress-nodeおよびDecision Point）は、[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 Deaggregatorによって受信されたAggregate Pathメッセージに、PCN-sent-rateを伝送するRSVP-AGGREGATE-IPv4-PCN-responseまたはRSVP-AGGREGATE-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メッセージがDeaggregatorの外部インターフェイス（PCN-egress-nodeおよびDecision Point）に到着すると、[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 Deaggregatorの外部インターフェイスに到着するE2E Resvメッセージに関連付けられたE2E RSVP SESSIONは、RSVPジェネリックアグリゲートおよびPCN ingress-egress-aggregateとマッピング/照合されます。
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 DeaggregatorでサポートされるPCNエッジ動作のタイプに応じて、[RFC6661]または[RFC6662]のセクション3.3.1で指定されているPCNアドミッション制御手順に従う必要があります。 [RFC4860]とは異なり、PCNコアのRSVP集約予約に対するアドミッション制御手順は必要ないため、デアグリゲーターは、マッピングされた汎用集約RSVP予約に対するE2E予約のアドミッション制御を実行しません。 PCNベースのアドミッション制御手順が成功した場合、デアグリゲーターは、関連付けられたRSVPジェネリックアグリゲーション予約およびPCN ingress-egress-aggregateに新しいフローを許可する必要があります。 [RFC6661]と[RFC6662]を参照してください。 PCNベースのアドミッション制御手順が成功しない場合、E2E Resvは、関連付けられたRSVPジェネリック集約予約およびPCN ingress-egress-aggregationに許可されてはなりません（MUST NOT）。 E2E Resvメッセージは、[RFC4860]に従ってさらに処理されます。
How the PCN-admission-state is maintained is specified in [RFC6661] and [RFC6662].
PCN-admission-stateの維持方法は、[RFC6661]と[RFC6662]で指定されています。
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-egress-nodeおよびDecision Point）による新しい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-egress-nodeによって任意の値に設定できます。 Deaggregatorは、RSVP汎用集約予約の値をnull帯域幅に設定する必要があります（SHOULD）。 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]が使用され、Deaggregatorによって測定されたETMレートにingress-egress-aggregateのゼロ以外の値が含まれている場合（[RFC6661]および[RFC6662]を参照）、DeaggregatorはPCN-ingress-nodeにアグリゲーター（PCN-ingress-node）が特定のingress-egress-aggregate宛てのPCNトラフィックを受信しているレート（PCN-sent-rate）の推定値を提供します。
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に基づいてDeaggregatorによって計算されたPCN-admission-stateが特定のingress-egress-aggregateに対して「ブロック」されている場合、DeaggregatorはPCN-ingress-nodeに見積もりを要求する必要があります特定のingress-egress-aggregate宛てのアグリゲーターがPCNトラフィックを受信するレート（PCN-sent-rate）
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 上記の2つのケースで、PCN-sent-rateがAggregatorから要求される必要がある場合、Deaggregatorは、次のPCNオブジェクトのいずれかを運ぶ必要がある（リフレッシュ）Aggregate Resvメッセージを生成してAggregatorに送信する必要があります（セクション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コアを通過するAggregate Resvメッセージは、集約ルーターにIPアドレスが割り当てられ、ルーターアラートでマークされていません。したがって、Aggregate 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-ingress-node）の内部インターフェースに到着すると、[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:
Aggregate ResvメッセージがAggregator（PCN-ingress-node）の内部インターフェースに到着すると、[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 Aggregatorは、PCNオブジェクト（セクション4を参照）によって伝達される情報を使用して（SHOULD）、[RFC6661]および[RFC6662]のセクション3.4で指定された手順に従う必要があります。 RSVP-AGGREGATE-IPv4-PCN-requestまたはRSVP-AGGREGATE-IPv6-PCN-request PCNオブジェクトによって運ばれる「R」フラグがオンに設定されている場合（セクション4.1を参照）、アグリゲーターはセクション3.4で説明されている手順に従います。 [RFC6661]と[RFC6662]がPCN送信率の計算に及ぼす影響。特に、Aggregatorは、そのノードで受信され、1秒あたりのオクテット（PCN-sent-rate）で指定されたingress-egress-aggregate宛の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 AggregatorはAggregate Pathメッセージを開始します。特に、Aggregatorが次のPCNオブジェクトのいずれかを運ぶAggregate Resvメッセージを受信した場合-RSVP-AGGREGATE-IPv4-PCN-requestまたはRSVP-AGGREGATE-IPv6-PCN-request-"R"フラグがオン（セクション4.1を参照）、アグリゲーターは集約パスメッセージを開始し、RSVP-AGGREGATE-IPv4-PCN-responseまたはRSVP-AGGREGATE-IPv6-PCN-response PCNオブジェクト（セクション4.1を参照）に計算されたPCN-sent-rateを含めます）、これはAggregate Pathメッセージによって運ばれる必要があります。このAggregate Pathメッセージは、PCN-sent-rateの計算を要求したDeaggregator（PCN-egress-nodeおよびDecision Point）に送信されます。
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-ingress-node）による予約済み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].
Deaggregator（PCN-egress-nodeおよびDecision Point）が1つのingress-egress-aggregate（[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 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].
同じingress-egress-aggregateの場合、1つのingress-egress-aggregateに関連付けられた着信帯域幅の合計を、終了するトラフィックの量だけ減らすために、終了するE2Eマイクロフローの数を選択します。この状況では、E2Eマイクロフローを終了するための同じメカニズムを、[RFC2205]で指定されているメカニズムと同じように実行できます。ただし、ローカルポリシーに基づいて、デアグリゲーターは他の方法を使用して、終了するマイクロフローを選択できます。たとえば、同じingress-egress-aggregateの場合は、1つのingress-egress-aggregateに関連付けられている受信帯域幅の合計をトラフィックの量だけ減らすために、終了する、または予約済みの帯域幅を減らすE2Eマイクロフローの数を選択します終了します。この状況では、[RFC4495]のセクション5で指定されたメカニズムとして、E2Eマイクロフローを終了したり、E2Eマイクロフローに関連付けられた帯域幅を削減したりするための同じメカニズムを使用できます。
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 SESSIONオブジェクトに含まれるDSCP値は、PCN互換のDiffservコードポイントと等しく設定する必要があります（SHOULD）。
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-ingress-node）のIPv4またはIPv6宛先アドレスに設定する必要があります（SHOULD）。 [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 Deaggregator（PCN-egress-nodeおよびDecision Point）がPCN-ingress-nodeからPCN-sent-rateを要求する必要がある場合（このドキュメントのセクション3.9を参照）、Deaggregatorは（refresh）Aggregate Resvを生成して送信する必要があります。 IPv4またはIPv6がサポートされているかどうかに応じて、次のPCNオブジェクト（セクション4.1を参照）のいずれかを運ぶ必要があるアグリゲーターへのメッセージ：
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 Aggregatorが、次のPCNオブジェクトのいずれかを伝えるAggregate Resvメッセージを受信したとき-RSVP-AGGREGATE-IPv4-PCN-requestまたはRSVP-AGGREGATE-IPv6-PCN-request、 "R"フラグをONに設定（セクションを参照） 4.1）-次に、アグリゲーターは、IPv4とIPv6のどちらがサポートされているかに応じて、次のPCNオブジェクト（セクション4.1を参照）のいずれかを運ぶAggregate Pathメッセージを生成してDeaggregatorに送信する必要があります（MUST）。
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メッセージによって伝送できる4種類の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：IPv4アドレスが使用される場合のPCN要求オブジェクト：
Class = 248 (PCN) C-Type = 1 (RSVP-AGGREGATE-IPv4-PCN-request)
クラス= 248（PCN）Cタイプ= 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 |
+-------------+-------------+-------------+-------------+
o RSVP-AGGREGATE-IPv6-PCN-request: PCN object, when IPv6 addresses are used:
o RSVP-AGGREGATE-IPv6-PCN-request：IPv6アドレスが使用される場合のPCNオブジェクト：
Class = 248 (PCN) C-Type = 2 (RSVP-AGGREGATE-IPv6-PCN-request)
クラス= 248（PCN）Cタイプ= 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 |
+-------------+-------------+-------------+-------------+
o RSVP-AGGREGATE-IPv4-PCN-response: PCN object, IPv4 addresses are used:
o RSVP-AGGREGATE-IPv4-PCN-response：PCNオブジェクト、IPv4アドレスが使用されます：
Class = 248 (PCN) C-Type = 3 (RSVP-AGGREGATE-IPv4-PCN-response)
クラス= 248（PCN）Cタイプ= 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 |
+-------------+-------------+-------------+-------------+
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)
クラス= 248（PCN）Cタイプ= 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 |
+-------------+-------------+-------------+-------------+
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-ingress-node（Aggregator）のIPv4またはIPv6アドレスとPCN-egress-node（Deaggregator）のIPv4またはIPv6アドレス：一緒に、レポートが参照するingress-egress-aggregateを指定します。 [RFC6663]によると、レポートにはPCN-ingress-node（アグリゲーター）の識別子とPCN-egress-node（デアグリゲーター）の識別子（通常は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アドレスを指定します。このドキュメントでは、このフィールドにはDeaggregatorの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-ingress-node（Aggregator）がレート（PCN-sent-rate）の推定値を提供する必要があることを示す1ビットのフラグ）PCN-ingress-node（Aggregator）が、指定されたingress-egress-aggregate宛てのPCNトラフィックを受信している場所。
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-sent-rate：PCN-ingress-node（Aggregator）が指定されたingress-egress-aggregate宛てのPCNトラフィックを受信しているレートの推定。オクテット/秒で表されます。その形式は、32ビットのIEEE浮動小数点数です。 PCN-sent-rateは[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]で指定されているGeneric Aggregate RSVPメッセージが、事前輻輳通知を使用したDiffservクラウドでのPCN制御負荷（CL）およびシングルマーキング（SM）エッジ動作のサポートに使用されます。したがって、[RFC4860]で説明されているセキュリティメカニズムが適用されます。具体的には、INTEGRITYオブジェクト[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）パラメータ」レジストリの「クラス名、クラス番号、およびクラスタイプ」サブレジストリを変更して、新しいクラス番号を追加し、この新しいクラス番号の下に4つの新しいCタイプを割り当てます。未満;セクション4.1を参照してください。
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
[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.、and S. Jamin、 "Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification"、RFC 2205、September 1997、<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、「Per Hop Behavior Identification Codes」、RFC 3140、2001年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]ベイカー、F。、イトゥラルデ、C。、ルフォシェール、F。、およびB.デイビー、「IPv4およびIPv6予約用のRSVPの集約」、RFC 3175、2001年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、「Generic Aggregate Resource ReSerVation Protocol（RSVP）Reservations」、RFC 4860、2007年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。、編、「PCNノードの測定およびマーキング動作」、RFC 5670、2009年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、「単一のDiffservコードポイント（DSCP）を使用したIPヘッダーでの3つの事前輻輳通知（PCN）状態のエンコード」、RFC 6660、2012年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.、Meth、M。、およびT. Taylor、編、「制御負荷（CL）の事前輻輳通知（PCN）境界ノードの動作動作モード」、RFC 6661、2012年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.、Meth、M。、およびT. Taylor、編、「シングルマーキング（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.、Menth、M。、およびP. Eardley、「Diffservドメインでの輻輳前情報のシグナリングの要件」、RFC 6663、2012年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、「Integrated Services in the Internet Architecture：a Overview」、RFC 1633、1994年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。、「Specified of the Controlled-Load Network Element Service」、RFC 2211、1997年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]シェンカー、S。、パートリッジ、C。、およびR.ゲリン、「保証されたサービス品質の仕様」、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、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、RFC 2474、1998年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、「An Architecture for Differentiated Services」、RFC 2475、1998年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]ベイカー、F。、リンデル、B。、およびM.タルワー、「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、「A Framework for Policy-based Admission Control」、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]バーネット、Y。、フォード、P。、ヤヴァトカール、R。、ベイカー、F。、張、L。、シュペーアー、M。、ブレーデン、R。、デイビー、B。、ブロツラフ、J。、およびE 。Felstaine、 "A Framework for Integrated Services Operation over Diffserv Networks"、RFC 2998、November 2000、<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 Cryptographic Authentication-Updated Message Type Value」、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 Security Properties」、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]ベイカー、F。およびP.ボーズ、「ネストされた仮想プライベートネットワークにおけるサービスの品質（QoS）シグナリング」、RFC 4923、2007年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。、編、「Pre-Congestion Notification（PCN）Architecture」、RFC 5559、June 2009、<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 6411、2011年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、「事前輻輳を使用したDiffserv上のアドミッションコントロールのRSVP拡張機能通知（PCN）」、作業中、draft-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-ingress-node）とデアグリゲーター（PCN-egress-node）は、PCNドメインの境界にあります。 PCN-interior-nodeは、PCN-boundary-node間のPCN-domain内にありますが、以下の図には示されていません。これは、特定のAggregator-Deaggregatorペア間の最初のユニキャスト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
<-----------
(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を必要とします。この例では、Deaggregatorは、PCN PHB-IDのAggregate Path状態を設定するようにAggregatorに指示することを選択します。そのために、デアグリゲーターはNEW-AGGREGATE-NEEDED PathErrコードを含むE2E 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メッセージには、SESSION-OF-INTEREST（SOI）オブジェクトも含まれています。 SOIには、PHB-IDがPCN PHB-IDに設定されているGENERIC-AGGREGATE SESSION（GApcn）が含まれています。 GENERIC-AGGREGATE SESSIONには、DestAddress内にインターフェイスに依存しないDeaggregatorアドレスが含まれ、vDstPortフィールドとExtended vDstPortフィールド内に適切な値が含まれています。このドキュメントでは、拡張vDstPortには、アグリゲーターのIPv4またはIPv6アドレスが含まれている必要があります（SHOULD）。
(3) The Aggregator follows the request from the Deaggregator and signals an Aggregate Path for the GENERIC-AGGREGATE SESSION (GApcn).
（3）AggregatorはDeaggregatorからの要求に従い、GENERIC-AGGREGATE SESSION（GApcn）のAggregate Pathに信号を送ります。
(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）Deaggregatorは、両方の集約パスからADSPECに含まれる情報を考慮し、それに応じてE2EパスADSPECを更新します。 PCN-egress-nodeは、RSVP-TTL対IP TTLチェックを実行してはならず（MUST NOT）、ADSPECブレークビットを更新してはなりません（MUST NOT）。これは、PC2ドメイン全体がE2E RSVPによって統合サービスが実際にサポートされている（そしてアドミッションコントロールが実行されている）仮想リンクとして効果的に処理されるため、Breakビットを設定してはならないためです。 [RSVP-PCN-CL]も参照してください。 Deaggregatorは、転送する前に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予約の確立を高速化するために、E2E Resv要求が到着したときに汎用の集約予約が行われます。ここでは、DeaggregatorがオプションのResvConfirm要求をAggregate Resvメッセージに含めることも想定されています。
(6) The Aggregator merely complies with the received ResvConfirm Request and returns the corresponding Aggregate ResvConfirm.
（6）Aggregatorは、受信したResvConfirm要求に準拠し、対応するAggregate ResvConfirmを返すだけです。
(7) The Deaggregator has explicit confirmation that the generic aggregate reservation is established.
（7）Deaggregatorは、一般的な集約予約が確立されていることを明示的に確認します。
(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）の後、Deaggregatorは、対応するPHB-IDの汎用集約予約（GApcn）が設定されていることを認識します。このステップで、Deaggregatorは、総集約予約を、Deaggregatorが（PCN-egress-nodeとして）維持する1つのingress-egress-aggregateにマップします。セクション3.7を参照してください。 Deaggregatorは、PCN PHB-ID（GApcn）の汎用集約予約に対するE2E Resvのアドミッション制御を実行します。 Deaggregatorは、[RFC6661]および[RFC6662]で指定されているPCNアドミッションコントロール手順も考慮します。セクション3.7を参照してください。アドミッション制御手順（[RFC6661]または[RFC6662]のセクション3.3.1で説明されているPCNベースのアドミッション制御手順、および[RFC4860]で指定されているアドミッション制御手順）のいずれかまたは両方が成功しない場合、E2E Resvは、PCN PHB-ID（GApcn）に関連付けられたRSVP総称予約に許可されていません。それ以外の場合、PCN（GApcn）の汎用集約予約がE2E Resvをサポートするのに十分な帯域幅で確立されていると仮定すると、デアグリゲーターはカウンターを調整して、汎用集約予約の未使用帯域幅を追跡します。次に、選択したマッピングをGApcn（したがってPCN PHB-ID）に伝達するSESSION-OF-INTERESTオブジェクトを含め、E2E Resvをアグリゲーターに転送します。
(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）に記録します。 Aggregatorは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]の作成者に感謝します。さらに、コメントを提供してくれたボブ・ブリスコ、デビッド・ブラック、ケン・カールバーグ、トム・テイラー、フィリップ・アードリー、マイケル・メンス、トビー・モンキャスター、ジェームス・ポーク、スコット・ブラドナー、リクシア・チャン、ロバート・スパークスに感謝します。特に、彼のコメントに加えて、かなりの量のテキストを提供してくれたFrancois Le Faucheurに感謝します。
Authors' Addresses
著者のアドレス
Georgios Karagiannis Huawei Technologies Hansaallee 205 40549 Dusseldorf Germany
Georgios Karagiannis Huawei Technologies Hansaallee 205 40549デュッセルドルフドイツ
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
Anurag Bhargava Cisco Systems、Inc. 7100-9 Kit Creek Road PO Box 14987 Research Triangle Park、NC 27709-4987 United States
EMail: anuragb@cisco.com