Network Working Group F. Le Faucheur
Request for Comments: 4860 B. Davie
Category: Standards Track Cisco Systems, Inc.
P. Bose
Lockheed Martin
C. Christou
M. Davenport
Booz Allen Hamilton
May 2007
Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations
一般的な集約リソース予約プロトコル（RSVP）予約
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network.
RFC 3175は、所与のソースから所与の宛先への集計リソース予約プロトコル（RSVP）リソースが所与当たりホップの動作（PHB）のためのDiffservネットワークに確保できるように予約、またはのPHBの所与のセットを定義します。 RFC 3175はまた、Diffservのクラウドを介して遷移するときに、エンドツーエンドのRSVPの予約は、予約集計に集約することができる方法を定義します。複数のそのような集計予約が同じ送信元IPアドレス、宛先IPアドレス、およびPHBのために必要な（またはのPHBのセット）されている状況があります。しかし、これはこれをサポートするためにRFC 3175.に定義された集約の予約によってサポートされていない、本文書は、一般的な集約の予約と呼ばれる、集約RSVP予約のより柔軟なタイプを定義します。複数のそのような一般的な集約の予約は、与えられたPHBのために確立された（またはのPHBのセット）所与の宛先IPアドレスに指定されたソースIPアドレスとすることができます。一般的な集約の予約は、エンドツーエンドのRSVP予約を集約するために使用することができます。この文書はまた、このような凝集のための手順を定義します。一般的な集約の予約はまた、Diffservのネットワークに接続されたエンド・システムによって直接エンドツーエンドを使用することができます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Related IETF Documents .....................................6
1.2. Organization of This Document ..............................6
1.3. Requirements Language ......................................7
2. Object Definition ...............................................7
2.1. SESSION Class ..............................................8
2.2. SESSION-OF-INTEREST (SOI) Class ...........................11
3. Processing Rules for Handling Generic Aggregate RSVP
Reservations ...................................................13
3.1. Extensions to Path and Resv Processing ....................13
4. Procedures for Aggregation over Generic Aggregate RSVP
Reservations ...................................................14
5. Example Usage Of Multiple Generic Aggregate Reservations
per PHB from a Given Aggregator to a Given Deaggregator ........19
6. Security Considerations ........................................21
7. IANA Considerations ............................................24
8. Acknowledgments ................................................25
9. Normative References ...........................................26
10. Informative References ........................................26
Appendix A. Example Signaling Flow ................................28
[RSVP-AGG] defines RSVP aggregate reservations that allow resources to be reserved in a Diffserv network for a flow characterized by its 3-tuple <source IP address, destination IP address, Diffserv Code Point>.
[RSVP-AGG]はリソースがその3タプル<送信元IPアドレス、宛先IPアドレス、Diffservのコードポイント>によって特徴付けフローのためのDiffservネットワークに確保されることを可能にするRSVP集約の予約を定義します。
[RSVP-AGG] also defines the procedures for aggregation of end-to-end (E2E) RSVP reservations onto such aggregate reservations when transiting through a Diffserv cloud. Such aggregation is illustrated in Figure 1. This document reuses the terminology defined in [RSVP-AGG].
Diffservのクラウドを介して通過するときに[RSVP-AGG]も、このような凝集予約にエンド・ツー・エンド（E2E）RSVP予約の集合のための手順を定義します。そのような凝集は、この文書では、[RSVP-AGG]で定義された用語を再利用し、図1に示されています。
--------------------------
/ Aggregation \
|----| | Region | |----|
H--| R |\ |-----| |------| /| R |-->H
H--| |\\| | |---| |---| | |//| |-->H
|----| \| | | I | | I | | |/ |----|
| Agg |======================>| Deag |
/| | | | | | | |\
H--------//| | |---| |---| | |\\-------->H
H--------/ |-----| |------| \-------->H
| |
\ /
--------------------------
H = Host requesting end-to-end RSVP reservations R = RSVP router Agg = Aggregator Deag = Deaggregator I = Interior Router
H =ホスト要求するエンド・ツー・エンドのRSVP予約のR = RSVPルータAGG =アグリゲータDeag =デアグリゲータI =インテリアルータ
--> = E2E RSVP reservation ==> = Aggregate RSVP reservation
- > = E2EのRSVP予約==> =集約RSVP予約
Figure 1 : Aggregation of E2E Reservations
over Aggregate RSVP Reservations
These aggregate reservations use a SESSION type specified in [RSVP-AGG] that contains the receiver (or Deaggregator) IP address and the Diffserv Code Point (DSCP) of the Per Hop Behavior (PHB) from which Diffserv resources are to be reserved. For example, in the case of IPv4, the SESSION object is specified as:
これらの凝集体の予約は、Diffservのリソースが予約されるべきであるから当たりホップの動作（PHB）の受信機（又はデアグリゲーター）IPアドレスとDiffservコードポイント（DSCP）を含有する[RSVP-AGG]で指定されたセッションのタイプを使用します。例えば、IPv4の場合に、セッションオブジェクトは次のように指定されています。
o Class = SESSION, C-Type = RSVP-AGGREGATE-IP4
Oクラス= SESSION、C型= RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Session Address (4 bytes) |
+-------------+-------------+-------------+-------------+
| /////////// | Flags | ///////// | DSCP |
+-------------+-------------+-------------+-------------+
These aggregate reservations use SENDER_TEMPLATE and FILTER_SPEC types, specified in [RSVP-AGG], that contain only the sender (or Aggregator) IP address. For example, in the case of IPv4, the SENDER_TEMPLATE object is specified as:
これらの集計予約は唯一の送信者（またはアグリゲータ）IPアドレスが含まれている[RSVP-AGG]で指定SENDER_TEMPLATEとFILTER_SPEC種類を、使用しています。例えば、IPv4の場合に、SENDER_TEMPLATEオブジェクトは次のように指定されています。
o Class = SENDER_TEMPLATE, C-Type = RSVP-AGGREGATE-IP4
Oクラス= SENDER_TEMPLATE、C型= RSVP-AGGREGATE-IP4
+-------------+-------------+-------------+-------------+
| IPv4 Aggregator Address (4 bytes) |
+-------------+-------------+-------------+-------------+
Thus, it is possible to establish, from a given source IP address to a given destination IP address, separate such aggregate reservations for different PHBs (or different sets of PHBs). However, from a given source IP address to a given IP destination address, only a single [RSVP-AGG] aggregate reservation can be established for a given PHB (or given set of PHBs).
したがって、所与の宛先IPアドレスに指定されたソースIPアドレスから、確立することが可能である、別のPHB（又はのPHBの異なるセット）のための別個のような集計予約。しかし、所与のIP宛先アドレスに指定されたソースIPアドレスから、単一の[RSVP-AGG]集約の予約は、与えられたPHBのために確立された（またはのPHBのセットを与えられる）ことができます。
Situations have since been identified where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). One example is where E2E reservations using different preemption priorities (as per [RSVP-PREEMP]) need to be aggregated through a Diffserv cloud using the same PHB. Using multiple aggregate reservations for the same PHB allows enforcement of the different preemption priorities within the aggregation region. In turn, this allows more efficient management of the Diffserv resources, and in periods of resource shortage, this allows sustainment of a larger number of E2E reservations with higher preemption priorities.
複数のそのような集計予約が同じ送信元IPアドレス、宛先IPアドレス、およびPHB（またはのPHBのセット）のために必要とされる状況は、以降確認されています。 （[RSVP-PREEMP]あたりのような）異なる先取り優先順位を使用して、E2E予約が同じPHBを使用Diffservのクラウドを介して集約する必要がある場合一例です。同じPHBに対して複数の集約の予約を使用すると、凝集領域内の異なる先取り優先順位の適用を可能にします。今度は、これは、Diffservのリソースのより効率的な管理を可能にし、リソース不足の期間において、これは、より高い先取優先度E2Eの予約の多数のサスティンを可能にします。
For example, [SIG-NESTED] discusses in detail how end-to-end RSVP reservations can be established in a nested VPN environment through RSVP aggregation. In particular, [SIG-NESTED] describes how multiple parallel generic aggregate reservations (for the same PHB), each with different preemption priorities, can be used to efficiently support the preemption priorities of end-to-end reservations.
例えば、[SIG-NESTED]は、エンドツーエンドのRSVP予約がRSVP集約を介して、ネストされたVPN環境で確立することができる方法を詳細に説明します。具体的には、[SIG-NESTEDは（同じPHBのための）複数の並列汎用集計予約、異なる先取優先度毎に、効率的にエンドツーエンド予約の先取優先度をサポートするために使用することができる方法について説明します。
This document addresses this requirement for multiple aggregate reservations for the same PHB (or same set of PHBs), by defining a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservations. This is achieved primarily by adding the notions of a Virtual Destination Port and of an Extended Virtual Destination Port in the RSVP SESSION object.
同じPHB（又はのPHBの同じセット）のための複数の集約の予約のためのこの要件この文書アドレスは、集約RSVP予約のより柔軟なタイプを定義することによって、一般的な集約の予約と称します。これは主に、RSVPセッションオブジェクトに仮想宛先ポートの拡張や仮想宛先ポートの概念を追加することによって達成されます。
The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] to address a similar requirement (albeit in a different context) for identification and demultiplexing of sessions beyond the IP destination address. This document reuses this notion from [RSVP-IPSEC] for identification and demultiplexing of generic aggregate sessions beyond the IP destination address and PHB. This allows multiple generic aggregate reservations to be established for a given PHB (or set of PHBs), from a given source IP address to a given destination IP address.
仮想宛先ポートの概念は、IP宛先アドレスを超えたセッションの識別と分離のための（異なる文脈ではあるが）同様の要件に対処するために、[RSVP-IPSEC]で紹介されました。この文書では、IP宛先アドレスとPHBを超えた一般的な集約セッションの識別と分離のための[RSVP-IPSEC]からこの概念を再利用します。これは、指定されたソースIPアドレスから特定の宛先IPアドレスに、与えられたPHBのために確立される複数の一般的な集約の予約を可能にする（またはのPHBのセット）。
[RSVP-TE] introduced the concept of an Extended Tunnel ID (in addition to the tunnel egress address and the Tunnel ID) in the SESSION object used to establish MPLS Traffic Engineering tunnels with RSVP. The Extended Tunnel ID provides a very convenient mechanism for the tunnel ingress node to narrow the scope of the session to the ingress-egress pair. The ingress node can achieve this by using one of its own IP addresses as a globally unique identifier and including it in the Extended Tunnel ID and therefore within the SESSION object. This document reuses this notion of Extended Tunnel ID from [RSVP-TE], simply renaming it Extended Virtual Destination Port. This provides a convenient mechanism to narrow the scope of a generic aggregate session to an Aggregator-Deaggregator pair.
[RSVP-TE]はRSVPとMPLSトラフィックエンジニアリングトンネルを確立するために使用されるセッションオブジェクト内（トンネル出口アドレスとトンネルIDに加えて）拡張トンネルIDの概念を導入しました。拡張トンネルIDは、入口、出口ペアへのセッションの範囲を狭くするトンネル入口ノードのための非常に便利なメカニズムを提供します。入口ノードは、グローバルに一意の識別子として自身のIPアドレスのいずれかを使用して拡張トンネルIDで、したがってセッションオブジェクト内に含めることによって、これを達成することができます。この文書では、単にそれが仮想宛先ポートを拡張リネーミング、[RSVP-TE]から拡張トンネルIDのこの概念を再利用します。これは、アグリゲータ・デアグリゲータのペアへの一般的な集約セッションの範囲を狭めるための便利なメカニズムを提供します。
The RSVP SESSION object for generic aggregate reservations uses the PHB Identification Code (PHB-ID) defined in [PHB-ID] to identify the PHB, or set of PHBs, from which the Diffserv resources are to be reserved. This is instead of using the Diffserv Code Point (DSCP) as per [RSVP-AGG]. Using the PHB-ID instead of the DSCP allows explicit indication of whether the Diffserv resources belong to a single PHB or to a set of PHBs. It also facilitates handling of situations where a generic aggregate reservation spans two (or more) Diffserv domains that use different DSCP values for the same Diffserv PHB (or set of PHBs) from which resources are reserved. This is because the PHB-ID allows conveying of the PHB (or set of PHBs) independently of what DSCP value(s) are used locally for that PHB (or set of PHBs).
汎用集合予約のためのRSVPセッションオブジェクトはPHB識別コード（PHB-ID）PHBを識別するために、[PHB-ID]で定義された、またはDiffservのリソースが予約される、そこからのPHBのセットを使用します。この代わりに[RSVP-AGG]に従ってDiffservのコードポイント（DSCP）を使用してのものです。 PHB-IDの代わりにDSCPを使用するDiffservのリソースが単一PHBまたはのPHBのセットに属するかどうかの明示的な表示を可能にします。それはまた、一般的な集約の予約は、2つ（またはそれ以上）に及ぶ状況リソースが予約されたのと同じたDiffserv PHB（またはのPHBのセット）に対して異なるDSCP値を使用するのDiffservドメインの取り扱いを容易にします。 PHB-IDは、独立して、DSCP値（S）がそのPHBのために局所的に使用される（またはのPHBのセット）されているもののPHBの搬送（またはのPHBのセット）を可能にするためです。
The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. These procedures are based on those of [RSVP-AGG], and this document only specifies the differences from those.
一般的な集約の予約は、エンドツーエンドのRSVP予約を集約するために使用することができます。この文書はまた、このような凝集のための手順を定義します。これらの手順は、[RSVP-AGG]のそれらに基づいており、この文書はのみとの違いを指定しています。
The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network.
一般的な集約の予約はまた、Diffservのネットワークに接続されたエンド・システムによって直接エンドツーエンドを使用することができます。
This document is heavily based on [RSVP-AGG]. It reuses [RSVP-AGG] wherever applicable and only specifies the necessary extensions beyond [RSVP-AGG].
この文書は重く[RSVP-AGG]に基づいています。それはどこに該当する[RSVP-AGG]を再利用し、のみ[RSVP-AGG]を超え、必要な拡張子を指定します。
The mechanisms defined in [BW-REDUC] allow an existing reservation to be reduced in allocated bandwidth by RSVP routers in lieu of tearing that reservation down. These mechanisms are applicable to the generic aggregate reservations defined in the present document.
[BW-REDUC]で定義されたメカニズムは、既存の予約がダウンその予約を引き裂くの代わりにRSVPルータによって割り当てられた帯域幅を小さくすることを可能にします。これらのメカニズムは、現在のドキュメントで定義されている一般的な集計の予約に適用されます。
[RSVP-TUNNEL] describes a general approach to running RSVP over various types of tunnels. One of these types of tunnel, referred to as a "type 2 tunnel", has some similarity with the generic aggregate reservations described in this document. The similarity stems from the fact that a single, aggregate reservation is made for the tunnel while many individual flows are carried over that tunnel. However, [RSVP-TUNNEL] does not address the use of Diffserv-based classification and scheduling in the core of a network (between tunnel endpoints), but rather relies on a UDP/IP tunnel header for classification. This is why [RSVP-AGG] required additional objects and procedures beyond those of [RSVP-TUNNEL]. Like [RSVP-AGG], this document also assumes the use of Diffserv-based classification and scheduling in the aggregation region and, thus, requires additional objects and procedures beyond those of [RSVP-TUNNEL].
[RSVP-トンネル]トンネルの様々な種類以上RSVPを実行する一般的なアプローチを記載しています。 「タイプ2トンネル」と呼ばれるトンネルのこれらの種類の一つは、この文書に記載され、一般的な集約の予約といくつかの類似性を有します。類似性は、多くの個々のフローがそのトンネルを介して搬送されながら、単一の集約予約トンネルのために作られているという事実から生じます。しかし、[RSVPトンネル（トンネルエンドポイント間の）ネットワークのコア内のDiffservベースの分類とスケジューリングの使用には対処していない、むしろ、分類のためのUDP / IPトンネルヘッダに依存しています。これは、なぜ[RSVP-TUNNEL]のものを超えて[RSVP-AGG]に必要な追加のオブジェクトと手順。 [RSVP-AGG]と同様に、この文書はまた、凝集領域でのDiffservベースの分類とスケジューリングの使用を前提とし、従って、[RSVP-TUNNEL]のものを超えて追加のオブジェクトおよび手順を必要とします。
As explained earlier, this document reuses the notion of Virtual Destination Port from [RSVP-IPSEC] and the notion of Extended Tunnel ID from [RSVP-TE].
先に説明したように、このドキュメントは[RSVP-IPSEC]から仮想宛先ポートの概念と[RSVP-TE]から拡張トンネルIDの概念を再利用します。
Section 2 defines the new RSVP objects related to generic aggregate reservations and to aggregation of E2E reservations onto those. Section 3 describes the processing rules for handling of generic aggregate reservations. Section 4 specifies the procedures for aggregation of end-to-end RSVP reservations over generic aggregate RSVP reservations. Section 5 provides example usage of how the generic aggregate reservations may be used.
セクション2は、一般的な集約の予約に、それらの上にE2Eの予約の集合に関連する新たなRSVPオブジェクトを定義します。第3節では、一般的な集約の予約の取り扱いのための処理ルールを説明します。第4節では、一般的な集約RSVP予約オーバーエンドツーエンドのRSVP予約の集約のための手順を指定します。第5節では、一般的な集計の予約を使用することができる方法の使用例を提供します。
The Security Considerations and the IANA Considerations are discussed in Sections 6 and 7, respectively.
セキュリティの考慮事項とIANAの考慮事項は、それぞれ、セクション6および7に記載されています。
Finally, Appendix A provides an example signaling flow that illustrates aggregation of E2E RSVP reservations onto generic aggregate RSVP reservations.
最後に、付録Aは、一般的な集約RSVP予約にE2EのRSVP予約の集合を示すシグナリングフローの例を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
This document reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP-AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE, and RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG].
この文書では、RSVP-AGGREGATE-IP4 FILTER_SPEC、RSVP-AGGREGATE-IP6 FILTER_SPEC、RSVP-AGGREGATE-IP4 SENDER_TEMPLATEを再利用し、RSVP-AGGREGATE-IP6の[RSVP-AGG]で定義SENDER_TEMPLATEオブジェクト。
This document defines:
この文書では、定義されています。
- two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION) under the existing SESSION Class, and
- 二つの新しいオブジェクト（GENERIC-AGGREGATE-IP4のSESSIONとGENERIC-AGGREGATE-IP6 SESSION）既存のSESSIONクラスの下で、と
- two new objects (GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI) under a new SESSION-OF-INTEREST Class.
- 新しいセッションの関心クラスの下に2つの新しいオブジェクト（GENERIC-AGG-IP4-SOIとGENERIC-AGG-IP6-SOI）。
Detailed description of these objects is provided below in this section.
これらのオブジェクトの詳細な説明は、このセクションで以下に提供されます。
The GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION objects are applicable to all types of RSVP messages.
GENERIC-AGGREGATE-IP4のSESSIONとGENERIC-AGGREGATE-IP6セッションオブジェクトは、RSVPメッセージのすべてのタイプに適用されます。
This specification defines the use of the GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI objects in two circumstances:
この仕様は、2つの状況でGENERIC-AGG-IP4-SOIとGENERIC-AGG-IP6-SOIオブジェクトの使用を定義します。
- inside an E2E PathErr message that contains an error code of NEW-AGGREGATE-NEEDED in order to convey the session of a new generic aggregate reservation that needs to be established.
- 確立する必要がある新しい汎用集約予約のセッションを伝えるために、NEW-AGGREGATE必要に応じたエラーコードが含まれているE2EのPathErrメッセージの内部。
- inside an E2E Resv message in order to convey the session of the generic aggregate reservation onto which this E2E reservation needs to be mapped.
- このE2E予約をマッピングする必要がある上、一般的な集約予約のセッションを搬送するためにE2E Resvメッセージ内部。
Details of the corresponding procedures can be found in Section 4.
対応する手順の詳細は、第4節に見出すことができます。
However, it is envisioned that the ability to signal, inside RSVP messages, the Session of another reservation (which has some relationship with the current RSVP reservation) might have some other applicability in the future. Thus, those objects have been specified in a more generic manner under a flexible SESSION-OF-INTEREST class.
しかし、合図する能力は、RSVPメッセージ内で、（現在のRSVP予約と何らかの関係を持っている）他の予約のセッションは、将来的に他のいくつかの適用可能性を持っている可能性があることが想定されます。したがって、これらのオブジェクトは、柔軟なセッション関心クラスの下で、より一般的な方法で指定されています。
All the new objects defined in this document are optional with respect to RSVP so that general RSVP implementations that are not concerned with generic aggregate reservations do not have to support these objects. RSVP routers supporting generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION object or the GENERIC-AGGREGATE-IP6 SESSION object, respectively. RSVP routers supporting RSVP aggregation over generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGG-IP4-SOI object or GENERIC-AGG-IP6-SOI object, respectively.
この文書で定義されたすべての新しいオブジェクトは、一般的な集計の予約に関係していない一般的なRSVPの実装は、これらのオブジェクトをサポートする必要がないようにRSVPに関しては省略可能です。一般的な集約IPv4またはIPv6の予約をサポートするRSVPルータはそれぞれ、GENERIC-AGGREGATE-IP4セッションオブジェクトまたはGENERIC-AGGREGATE-IP6・セッション・オブジェクトをサポートしなければなりません。一般的な集約IPv4またはIPv6予約上RSVP集約をサポートするRSVPルータはそれぞれ、GENERIC-AGG-IP4-SOIオブジェクトまたはGENERIC-AGG-IP6-SOIオブジェクトをサポートしなければなりません。
o GENERIC-AGGREGATE-IP4 SESSION object: Class = 1 (SESSION) C-Type = 17
O GENERIC-AGGREGATE-IP4 SESSIONオブジェクト：クラス= 1（セッション）Cタイプ= 17
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
IPv4 DestAddress (IPv4 Destination Address)
IPv4のDestAddress（IPv4の宛先アドレス）
IPv4 address of the receiver (or Deaggregator).
受信機（又はデアグリゲーター）のIPv4アドレス。
Reserved
予約済み
An 8-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt.
8ビットのフィールド。すべてのビットは、送信時に0に設定しなければなりません。このフィールドには、領収書で無視しなければなりません。
Flags
国旗
An 8-bit field. The content and processing of this field are the same as for the Flags field of the IPv4/UDP SESSION object (see [RSVP]).
8ビットのフィールド。このフィールドの内容及び処理は、IPv4 / UDPセッションオブジェクトのFlagsフィールドと同じである（[RSVP]を参照）。
PHB-ID (Per Hop Behavior Identification Code)
PHB-ID（パーホップ行動識別コード）
A 16-bit field containing the Per Hop Behavior Identification Code of the PHB, or of the set of PHBs, from which Diffserv resources are to be reserved. This field MUST be encoded as specified in Section 2 of [PHB-ID].
PHBの、またはDiffservのリソースが予約される、そこからのPHBのセットのホップ当たり挙動識別コードを含む16ビットのフィールド。 [PHB-ID]のセクション2で指定されるように、このフィールドは、符号化されなければなりません。
Reserved
予約済み
A 16-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt.
16ビットのフィールド。すべてのビットは、送信時に0に設定しなければなりません。このフィールドには、領収書で無視しなければなりません。
VDstPort (Virtual Destination Port)
VDstPort（仮想宛先ポート）
A 16-bit identifier used in the SESSION that remains constant over the life of the generic aggregate reservation.
一般的な集約予約の期間にわたって一定のままセッションで使用される16ビットの識別子。
Extended vDstPort (Extended Virtual Destination Port)
拡張vDstPort（拡張仮想宛先ポート）
A 32-bit identifier used in the SESSION that remains constant over the life of the generic aggregate reservation. A sender (or Aggregator) that wishes to narrow the scope of a SESSION to the sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD place its IPv4 address here as a network unique identifier. A sender (or Aggregator) that wishes to use a common session with other senders (or Aggregators) in order to use a shared reservation across senders (or Aggregators) MUST set this field to all zeros.
汎用集合予約の寿命にわたって一定のままでセッションで使用される32ビットの識別子。送信者 - 受信機対（またはアグリゲータ・デアグリゲーター対）へのセッションの範囲を狭めることを望む送信者（またはアグリゲータ）は、ネットワーク固有の識別子としてここにそのIPv4アドレスを配置する必要があります。送信者（又はアグリゲータ）間で共有の予約を使用するために、他の送信者（又はアグリゲータ）と共通のセッションを使用したい送信者（またはアグリゲータ）はすべてゼロにこのフィールドを設定しなければなりません。
o GENERIC-AGGREGATE-IP6 SESSION object: Class = 1 (SESSION) C-Type = 18
O GENERIC-AGGREGATE-IP6セッション・オブジェクト：クラス= 1（セッション）Cタイプ= 18
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| |
+ +
| Extended vDstPort |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 16 25 26 31
IPv6 DestAddress (IPv6 Destination Address)
IPv6のDestAddress（IPv6宛先アドレス）
IPv6 address of the receiver (or Deaggregator).
受信機（又はデアグリゲーター）のIPv6アドレス。
Reserved
予約済み
An 8-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt.
8ビットのフィールド。すべてのビットは、送信時に0に設定しなければなりません。このフィールドには、領収書で無視しなければなりません。
Flags
国旗
An 8-bit field. The content and processing of this field are the same as for the Flags field of the IPv6/UDP SESSION object (see [RSVP]).
8ビットのフィールド。このフィールドの内容及び処理は、IPv6 / UDPセッションオブジェクトのFlagsフィールドと同じである（[RSVP]を参照）。
PHB-ID (Per Hop Behavior Identification Code)
PHB-ID（パーホップ行動識別コード）
A 16-bit field containing the Per Hop Behavior Identification Code of the PHB, or of the set of PHBs, from which Diffserv resources are to be reserved. This field MUST be encoded as specified in Section 2 of [PHB-ID].
PHBの、またはDiffservのリソースが予約される、そこからのPHBのセットのホップ当たり挙動識別コードを含む16ビットのフィールド。 [PHB-ID]のセクション2で指定されるように、このフィールドは、符号化されなければなりません。
Reserved
予約済み
A 16-bit field. All bits MUST be set to 0 on transmit. This field MUST be ignored on receipt.
16ビットのフィールド。すべてのビットは、送信時に0に設定しなければなりません。このフィールドには、領収書で無視しなければなりません。
VDstPort (Virtual Destination Port)
VDstPort（仮想宛先ポート）
A 16-bit identifier used in the SESSION that remains constant over the life of the generic aggregate reservation.
一般的な集約予約の期間にわたって一定のままセッションで使用される16ビットの識別子。
Extended vDstPort (Extended Virtual Destination Port)
拡張vDstPort（拡張仮想宛先ポート）
A 128-bit identifier used in the SESSION that remains constant over the life of the generic aggregate reservation. A sender (or Aggregator) that wishes to narrow the scope of a SESSION to the sender-receiver pair (or Aggregator-Deaggregator pair) SHOULD place its IPv6 address here as a network unique identifier. A sender (or Aggregator) that wishes to use a common session with other senders (or Aggregators) in order to use a shared reservation across senders (or Aggregators) MUST set this field to all zeros.
汎用集合予約の寿命にわたって一定のままでセッションで使用される128ビットの識別子。送信者 - 受信機対（またはアグリゲータ・デアグリゲーター対）へのセッションの範囲を狭めることを望む送信者（またはアグリゲータ）は、ネットワーク固有の識別子としてここにそのIPv6アドレスを配置する必要があります。送信者（又はアグリゲータ）間で共有の予約を使用するために、他の送信者（又はアグリゲータ）と共通のセッションを使用したい送信者（またはアグリゲータ）はすべてゼロにこのフィールドを設定しなければなりません。
o GENERIC-AGG-IP4-SOI object: Class = 132 C-Type = 1
O GENERIC-AGG-IP4-SOIオブジェクト：クラス= 132 Cタイプ= 1
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP4 SESSION Object //
| |
+-------------+-------------+-------------+-------------+
Content of a GENERIC-AGGREGATE-IP4 SESSION Object:
GENERIC-AGGREGATE-IP4セッションオブジェクトの内容：
This field contains a copy of the SESSION object of the session that is of interest for the reservation. In the case of a GENERIC-AGG-IP4-SOI, the session of interest conveyed in this field is a GENERIC-AGGREGATE-IP4 SESSION.
このフィールドは、予約のための興味のあるセッションのセッションオブジェクトのコピーが含まれています。 GENERIC-AGG-IP4-SOIの場合には、この分野で搬送関心のセッションがGENERIC-AGGREGATE-IP4セッションです。
o GENERIC-AGG-IP6-SOI object: Class = 132 C-Type = 2
O GENERIC-AGG-IP6-SOIオブジェクト：クラス= 132 Cタイプ= 2
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP6- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP6 SESSION Object //
| |
+-------------+-------------+-------------+-------------+
Content of a GENERIC-AGGREGATE-IP6 SESSION Object:
GENERIC-AGGREGATE-IP6セッションオブジェクトの内容：
This field contains a copy of the SESSION object of the session that is of interest for the reservation. In the case of a GENERIC-AGG-IP6-SOI, the session of interest conveyed in this field is a GENERIC-AGGREGATE-IP6 SESSION.
このフィールドは、予約のための興味のあるセッションのセッションオブジェクトのコピーが含まれています。 GENERIC-AGG-IP6-SOIの場合には、この分野で搬送関心のセッションがGENERIC-AGGREGATE-IP6セッションです。
For example, if a SESSION-OF-INTEREST object is used inside an E2E Resv message (as per the procedures defined in Section 4) to indicate which generic aggregate IPv4 session the E2E reservation is to be mapped onto, then the GENERIC-AGG-IP4-SOI object will be used, and it will be encoded like this:
たとえば、SESSIONの関心オブジェクトは、GENERIC-AGG-、E2Eの予約にマッピングされるべき一般的な集計のIPv4セッションを示すために（セクション4で定義された手順の通り）E2E Resvメッセージ内で使用される場合IP4-SOIオブジェクトが使用され、それは次のようにエンコードされます。
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+--+----------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
Note that a SESSION-OF-INTEREST object is not a SESSION object in itself. It does not replace the SESSION object in RSVP messages. It does not modify the usage of the SESSION object in RSVP messages. It simply allows conveying the Session of another RSVP reservation inside RSVP signaling messages, for some particular purposes. In the context of this document, it is used to convey, inside an E2E RSVP message pertaining to an end-to-end reservation, the Session of a generic aggregate reservation associated with the E2E reservation. Details for the corresponding procedures are specified in Section 4.
SESSIONの関心物体は、それ自体のセッションオブジェクトではないことに留意されたいです。これは、RSVPメッセージ内のセッションオブジェクトに代わるものではありません。これは、RSVPメッセージ内のセッションオブジェクトの使用法を変更しません。単にいくつかの特定の目的のために、RSVPシグナリングメッセージ内の別のRSVP予約のセッションを搬送することができます。この文書の文脈では、エンド・ツー・エンドの予約に係るE2EのRSVPメッセージ、E2Eの予約に関連付けられている一般的な集約の予約のセッション内で、搬送するために使用されます。対応する手順の詳細は、セクション4で規定されています。
This section presents extensions to the processing of RSVP messages required by [RSVP] and presented in [RSVP-PROCESS]. These extensions are required in order to properly process the GENERIC-AGGREGATE-IP4 or GENERIC-AGGREGATE-IP6 SESSION object and the RSVP-AGGREGATE-IP4 or RSVP-AGGREGATE-IP6 FILTER_SPEC object. Values for referenced error codes can be found in [RSVP]. As with the other RSVP documents, values for internally reported (API) errors are not defined.
このセクションでは、[RSVP]と[RSVP-PROCESS]で提示することにより必要なRSVPメッセージの処理への拡張を提供します。これらの拡張機能は、適切にGENERIC-AGGREGATE-IP4またはGENERIC-AGGREGATE-IP6・セッション・オブジェクトとRSVP-AGGREGATE-IP4またはRSVP-AGGREGATE-IP6をFILTER_SPECオブジェクトを処理するために必要とされます。参照エラーコードの値は[RSVP]に見出すことができます。他のRSVPの文書と同じように、内部的に報告された（API）エラーの値が定義されていません。
When referring to the new GENERIC-AGGREGATE-IP4 and GENERIC-AGGREGATE-IP6 SESSION objects, IP version will not be included, and they will be referred to simply as GENERIC-AGGREGATE SESSION, unless a specific distinction between IPv4 and IPv6 is being made.
新しいGENERIC-AGGREGATE-IP4およびGENERIC-AGGREGATE-IP6セッション・オブジェクトを参照する場合、IPのバージョンが含まれません、そして、IPv4とIPv6との間に特定の区別がなされている場合を除き、それらは、単にGENERIC-AGGREGATE SESSIONと呼ぶことにします。
When referring to the [RSVP-AGG] RSVP-AGGREGATE-IP4 and RSVP-AGGREGATE-IP6 SESSION, FILTER_SPEC, and SENDER_TEMPLATE objects, IP version will not be included, and they will be referred to simply as RSVP-AGGREGATE, unless a specific distinction between IPv4 and IPv6 is being made.
[RSVP-AGG] RSVP-AGGREGATE-IP4を参照すると、RSVP-AGGREGATE-IP6 SESSION、FILTER_SPECとSENDER_TEMPLATEオブジェクトの場合、IPのバージョンが含まれない、と彼らは特定しない限り、単にRSVP-AGGREGATEと呼ぶことにしますIPv4とIPv6との間の区別がなされています。
The following PATH message processing changes are defined:
次PATHメッセージ処理の変更が定義されています。
o When a session is defined using the GENERIC-AGGREGATE SESSION object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may be used. When this condition is violated in a PATH message received by an RSVP end-station, the RSVP end-station SHOULD report a "Conflicting C-Type" API error to the application. When this condition is violated in a PATH message received by an RSVP router, the RSVP router MUST consider this as a message formatting error.
セッションがGENERIC-AGGREGATE SESSIONオブジェクトを使用して定義されている場合、O、唯一[RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATEを使用することができます。この条件は、RSVPのエンドステーションが受信したPATHメッセージに違反した場合、RSVPエンドステーションは、アプリケーションに、「競合C型」APIエラーを報告する必要があります。この条件は、RSVPルータが受信したPATHメッセージに違反した場合、RSVPルータは、メッセージのフォーマットエラーとしてこれを考慮する必要があります。
o For PATH messages that contain the GENERIC-AGGREGATE SESSION object, the VDstPort value, the Extended VDstPort value, and the PHB-ID value should be recorded (in addition to the destination/Deaggregator address and source/Aggregator address). These values form part of the recorded state of the session. The PHB-ID may need to be passed to traffic control; however the vDstPort and Extended VDstPort are not passed to traffic control since they do not appear inside the data packets of the corresponding reservation.
O GENERIC-AGGREGATE SESSIONオブジェクトを含むPATHメッセージの場合、VDstPort値、拡張VDstPort値、およびPHB-ID値は、（宛先/デアグリゲーターアドレス及びソース/アグリゲータアドレスに加えて）記録されるべきです。これらの値は、セッションの記録状態の一部を形成します。 PHB-IDは、トラフィック制御に渡される必要があるかもしれません。彼らは、対応する予約のデータパケット内に表示されませんので、しかしvDstPortと拡張VDstPortはトラフィック制御に渡されません。
The following changes to RESV message processing are defined:
RESVメッセージの処理に以下の変更が定義されています。
o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE FILTER_SPEC, the session MUST be defined using either the RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the GENERIC-AGGREGATE SESSION object (as per this document). If this condition is not met, an RSVP router or end-station MUST consider that there is a message formatting error.
RESVメッセージが含まれている場合、O [RSVP-AGG] RSVP-AGGREGATE FILTER_SPEC、セッションは、このあたりのいずれかまたはGENERIC-AGGREGATE SESSIONオブジェクト（[RSVP-AGG]の通り）RSVP-AGGREGATE SESSIONオブジェクトを（使用して定義されなければなりません資料）。この条件が満たされない場合、RSVPルータまたはエンドステーションは、メッセージの書式エラーがあることを考慮しなければなりません。
o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION type is GENERIC-AGGREGATE, each node uses data classifiers as per the following:
RSVP-AGGREGATE FILTER_SPECが使用され、セッションタイプがGENERIC-集合体である場合、O、各ノードは、次の通りのデータ分類器を使用します。
* to perform Diffserv classification the node MUST rely on the Diffserv data classifier based on the DSCP only. The relevant DSCP value(s) are those that are associated with the PHB-ID of the generic aggregate reservation.
*ノードでのみDSCPに基づいたDiffservデータ分類に依存しなければならないDiffservの分類を実行します。関連するDSCP値（単数または複数）は、一般的な集約予約のPHB-IDに関連付けられているものです。
* If the node also needs to perform fine-grain classification (for example, to perform fine-grain input policing at a trust boundary) then the node MUST create a data classifier described by the 3-tuple <DestAddress, SrcAddress, DSCP>.
*ノードはまた、微粒子分類を実行する必要がある場合、ノードは3タプル<DestAddress、srcaddress送信、DSCP>で記述されたデータ分類器を作成する必要があり（例えば、信頼境界でポリシング微粒子の入力を行うため）。
The relevant DSCP value(s) are those that are associated with the PHB-ID of the generic aggregate reservation.
関連するDSCP値（単数または複数）は、一般的な集約予約のPHB-IDに関連付けられているものです。
Note that if multiple generic aggregate reservations are established with different Virtual Destination Ports (and/or different Extended Virtual Destination Ports) but with the same <DestAddress, SrcAddress, PHB-ID>, then those cannot be distinguished by the classifier. If the router is using the classifier for policing purposes, the router will therefore police those together and MUST program the policing rate to the sum of the reserved rate across all the corresponding reservations.
複数の一般的な集計予約が異なる仮想宛先ポート（および/または異なる拡張仮想宛先ポート）で確立されている場合がありますが、同じ<DestAddress、srcaddress送信、PHB-ID>と、それらは分類器で区別することはできません。ルータはポリシング目的で分類器を使用している場合、ルータは、したがって、一緒にそれらをポリシングし、対応するすべての予約全体の予約率の合計にポリシングレートをプログラムしなければなりません。
The procedures for aggregation of E2E reservations over generic aggregate RSVP reservations are the same as the procedures specified in [RSVP-AGG] with the exceptions of the procedure changes listed in this section.
一般的な集約RSVP予約上E2Eの予約の集合のための手順は、このセクションに記載されている手順の変更の例外を除いて、[RSVP-AGG]で指定された手順と同様です。
As specified in [RSVP-AGG], the Deaggregator is responsible for mapping a given E2E reservation on a given aggregate reservation. The Deaggregator requests establishment of a new aggregate reservation by sending to the Aggregator an E2E PathErr message with an error code of NEW-AGGREGATE-NEEDED. In [RSVP-AGG], the
[RSVP-AGG]で指定されるように、デアグリゲーターは、所与の凝集予約で指定されたE2E予約をマッピングする責任があります。デアグリゲーターは、アグリゲータにNEW-AGGREGATE必要に応じたのエラーコードでE2EたPathErrメッセージを送信することにより、新たな集約予約の確立を要求します。 [RSVP-AGG]において、
Deaggregator conveys the DSCP of the new requested aggregate reservation by including a DCLASS Object in the E2E PathErr and encoding the corresponding DSCP inside. This document modifies and extends this procedure. The Deaggregator MUST include in the E2E PathErr message a SESSION-OF-INTEREST object that contains the GENERIC-AGGREGATE SESSION to be used for establishment of the requested generic aggregate reservation. Since this GENERIC-AGGREGATE SESSION contains the PHB-ID, the DCLASS object need not be included in the PathErr message.
デアグリゲータは、E2EのPathErrにDCLASSオブジェクトを含む内部対応するDSCPを符号化して新たな要求集約予約のDSCPを伝えます。この文書では、この手順を変更し、拡張します。デアグリゲータは、E2EのPathErrメッセージに要求された汎用の集合予約の確立のために使用されるGENERIC-AGGREGATE SESSIONを含むセッションの関心物体を含まなければなりません。このGENERIC-AGGREGATE SESSIONは、PHB-IDを含むので、DCLASSオブジェクトはのPathErrメッセージに含まれる必要はありません。
Note that the Deaggregator can easily ensure that different Aggregators use different sessions for their Aggregate Path towards a given Deaggregator. This is because the Deaggregator can easily select VDstPort and/or Extended VDstPort numbers which are different for each Aggregator (for example, by using the Aggregator address as the Extended VDstPort) and can communicate those inside the GENERIC-AGGREGATE SESSION included in the SESSION-OF-INTEREST object. This provides an easy solution to establish separate reservations from every Aggregator to a given Deaggregator. Conversely, if reservation sharing were needed across multiple Aggregators, the Deaggregator could facilitate this by allocating the same VDstPort and Extended VDstPort to the multiple Aggregators, and thus including the same GENERIC-AGGREGATE SESSION inside the SESSION-OF-INTEREST object in the E2E PathErr messages sent to these Aggregators. The Aggregators could then all establish an Aggregate Path with the same GENERIC-AGGREGATE SESSION.
デアグリゲータは、簡単に別のアグリゲータは、与えられたデアグリゲータに対するそれらの集約パスに別のセッションを使用することを確実にすることができることに注意してください。これは、デアグリゲーターが容易VDstPort及び/又は（例えば、拡張VDstPortとして集約アドレスを使用して）各アグリゲータで異なっており、GENERIC-AGGREGATEセッション内でそれらがセッション - に含まれる通信することができる拡張VDstPort番号を選択することができるのでOF-INTERESTオブジェクト。これは、与えられたデアグリゲータにすべてのアグリゲータとは別の予約を確立するための簡単なソリューションを提供します。予約の共有が複数アグリゲータ横切って必要とされた場合は逆に、デアグリゲーターは、複数のアグリゲータに同じVDstPortおよび拡張VDstPortを割り当てることによって、これを容易にすることができ、したがって、E2EのPathErrセッションの関心物体内部同じGENERIC-AGGREGATE SESSION含みますこれらのアグリゲータに送信されたメッセージ。アグリゲータは、すべて同じGENERIC-AGGREGATE SESSIONで集計パスを確立することができます。
Therefore, various sharing scenarios can easily be supported. Policies followed by the Deaggregator to determine which Aggregators need shared or separate reservations are beyond the scope of this document.
したがって、様々な共有シナリオを容易に支持することができます。共用または別個の予約を必要とするどのアグリゲータ決定するために、デアグリゲーター続いポリシーは、この文書の範囲を超えています。
The Deaggregator MAY also include in the E2E PathErr message (with an error code of NEW-AGGREGATE-NEEDED) additional RSVP objects which are to be used for establishment of the newly needed generic aggregate reservation. For example, the Deaggregator MAY include in the E2E PathErr an RSVP Signaled Preemption Priority Policy Element (as specified in [RSVP-PREEMP]).
デアグリゲータはまた、（NEW-AGGREGATE必要に応じたエラーコードを有する）E2EのPathErrメッセージ新たに必要ジェネリック集合予約の確立のために使用される付加的なRSVPオブジェクトで含むかもしれません。例えば、デアグリゲーターは、E2EのPathErrにRSVPを含むかもしれません（[RSVP-PREEMP]で指定されるように）先取り優先権方針要素の合図をしました。
The [RSVP-AGG] procedures for processing of an E2E PathErr message received with an error code of NEW-AGGREGATE-NEEDED by the Aggregator are extended correspondingly. On receipt of such a message containing a SESSION-OF-INTEREST object, the Aggregator MUST trigger establishment of a generic aggregate reservation. In particular, it MUST start sending aggregate Path messages with the GENERIC-AGGREGATE SESSION found in the received SESSION-OF-INTEREST object. When an RSVP Signaled Preemption Priority Policy Element is contained in the received E2E PathErr message, the Aggregator MUST include this object in the Aggregate Path for the corresponding generic aggregate reservation. When other additional objects are contained in the received E2E PathErr message and those can be unambiguously interpreted as related to the new needed generic aggregate reservation (as opposed to related to the E2E reservation), the Aggregator SHOULD include those in the Aggregate Path for the corresponding generic aggregate reservation. The Aggregator MUST use as the Source Address (i.e., as the Aggregator Address in the Sender-Template) for the generic aggregate reservation, the address it uses to identify itself as the PHOP (RSVP previous hop) when forwarding the E2E Path messages corresponding to the E2E PathErr message.
アグリゲータによってNEW-AGGREGATE必要に応じたエラーコードで受信E2EのPathErrメッセージを処理するための[RSVP-AGG]手順は、対応拡張されます。 SESSIONの関心物体を含むようなメッセージを受信すると、アグリゲータは、一般的な集約の予約の確立をトリガしなければなりません。特に、受信したセッションの関心対象で見出さGENERIC-AGGREGATE SESSIONと集約Pathメッセージの送信を開始しなければなりません。 RSVPは、先取り優先権方針要素は、受信E2EのPathErrメッセージに含まれている信号が送られると、アグリゲータは、対応する汎用集約予約の集約経路内にこのオブジェクトを含まなければなりません。他の追加のオブジェクトは（E2E予約に関連するとは対照的に）受信E2EのPathErrメッセージに含まれており、それらは明確に新しい必要な一般的な集約の予約に関連するものとして解釈することができる場合、アグリゲータは、対応の集約経路内のものを含むべきです一般的な集計予約。に対応したE2E Pathメッセージを転送するときアグリゲータは、一般的な集計予約、それはPHOPとして自分自身を識別するために使用するアドレス（前のホップをRSVP）のために（送信者テンプレートでアグリゲータアドレスとして、すなわち）送信元アドレスとして使用しなければなりませんE2EたPathErrメッセージ。
The Deaggregator follows the same procedures as described in [RSVP-AGG] for establishing, maintaining and clearing the aggregate Resv state. However, a Deaggregator behaving according to the present specification MUST use the generic aggregate reservations and hence use the GENERIC-AGGREGATE SESSION specified earlier in this document.
デアグリゲータは、確立、維持および凝集のResv状態をクリアする[RSVP-AGG]に記載のものと同じ手順に従います。しかしながら、本明細書に従って行動デアグリゲーターは、一般的な集約の予約を使用し、従って、このドキュメント内の指定されたGENERIC-AGGREGATEセッションを使用しなければなりません。
This document also modifies the procedures of [RSVP-AGG] related to exchange of E2E Resv messages between Deaggregator and Aggregator. The Deaggregator MUST include the new SESSION-OF-INTEREST object in the E2E Resv message, in order to indicate to the Aggregator the generic aggregate session to map a given E2E reservation onto. Again, since the GENERIC-AGGREGATE SESSION (included in the SESSION-OF-INTEREST object) contains the PHB-ID, the DCLASS object need not be included in the E2E Resv message. The Aggregator MUST interpret the SESSION-OF-INTEREST object in the E2E Resv as indicating which generic aggregate reservation session the corresponding E2E reservation is mapped onto. The Aggregator MUST not include the SESSION-OF-INTEREST object when sending an E2E Resv upstream towards the sender.
この文書はまた、デアグリゲーターおよびアグリゲータ間E2E RESVメッセージの交換に関連する[RSVP-AGG]の手順を修正します。デアグリゲーターは、アグリゲータに上に与えられたE2E予約をマッピングするための一般的な集合セッションを示すために、E2E Resvメッセージに新しいセッションの関心物体を含まなければなりません。再び、GENERIC-AGGREGATE SESSIONので（SESSIONの関心対象に含まれる）PHB-IDを含んでいる、DCLASSオブジェクトはE2E Resvメッセージに含まれる必要はありません。アグリゲータは、対応するE2E予約が上にマッピングされている一般的な集約の予約セッションを示すものとしてE2EのResvセッションの関心物体を解釈しなければなりません。送信者に向かってアップストリームE2EたResvを送信するときアグリゲータは、セッションの関心オブジェクトを含んではなりません。
Based on relevant policy, the Deaggregator may decide at some point that an aggregate reservation is no longer needed and should be torn down. In that case, the Deaggregator MUST send an aggregate ResvTear. On receipt of the aggregate ResvTear, the Aggregator SHOULD send an aggregate PathTear (unless the relevant policy instructs the Aggregator to do otherwise or to wait for some time before doing so, for example in order to speed up potential re-establishment of the aggregate reservation in the future).
関連するポリシーに基づいて、デアグリゲータは、集計事前予約不要になったと取り壊されるべきいくつかの点で決めることができます。その場合には、デアグリゲータは、集約たResvTearを送らなければなりません。関連する政策がそうでなければ行うことや集約予約の潜在的な再構築をスピードアップするために、例えば、その前にいくつかの時間を待つアグリゲータに指示しない限り、集約たResvTearを受信すると、アグリゲータは、（集計PathTearを送るべきです将来は）。
[RSVP-AGG] describes how the Aggregator and Deaggregator can communicate their respective identities to each other. For example, the Aggregator includes one of its IP addresses in the RSVP HOP object in the E2E Path that is transmitted downstream and received by the Deaggregator once it traversed the aggregation region. Similarly, the Deaggregator identifies itself to the Aggregator by including one of its IP addresses in various fields, including the ERROR SPECIFICATION of the E2E PathErr message (containing the NEW-AGGREGATE-NEEDED Error Code) and in the RSVP HOP object of the E2E Resv message. However, [RSVP-AGG] does not discuss which IP addresses are to be selected by the Aggregator and Deaggregator for such purposes. Because these addresses are intended to identify the Aggregator and Deaggregator and not to identify any specific interface on these devices, this document RECOMMENDS that the Aggregator and Deaggregator SHOULD use interface-independent addresses (for example, a loopback address) whenever they communicate their respective identities to each other. This ensures that respective identification of the Aggregator and Deaggregator is not impacted by any interface state change on these devices. In turn, this results in more stable operations and considerably reduced RSVP signaling in the aggregation region. For example, if interface-independent addresses are used by the Aggregator and the Deaggregator, then a failure of an interface on these devices may simply result in the rerouting of a given generic aggregate reservation, but will not result in the generic aggregate reservation having to be torn down and another one established. Moreover, it will not result in a change of mapping of E2E reservations on generic aggregate reservations (assuming the Aggregator and Deaggregator still have reachability after the failure, and the Aggregator and Deaggregator are still on the shortest path to the destination).
[RSVP-AGG]はアグリゲータとデアグリゲーターが互いに、それぞれの識別情報を通信することができる方法について説明します。例えば、アグリゲータは、凝集領域を横断した後デアグリゲーターによって下流送受信されるE2E経路内のRSVPホップオブジェクトそのIPアドレスのいずれかを含みます。同様に、デアグリゲーターは（NEW-AGGREGATE必要に応じたエラーコードを含む）E2EのPathErrメッセージの誤差の仕様を含む様々な分野でのIPアドレスのいずれかを含むことにより、アグリゲータに自分自身を識別し、E2EのResvのRSVPホップオブジェクトでメッセージ。ただし、[RSVP-AGG]はアドレスは、このような目的のために集約し、デアグリゲータによって選択されるべきIPについては説明しません。これらのアドレスは、アグリゲータとデアグリゲーターを識別し、これらのデバイス上の任意の特定のインターフェイスを識別しないことが意図されているので、この文書は、彼らがそれぞれの識別情報を通信するたびアグリゲータとデアグリゲーターは、インターフェイスに依存しないアドレス（例えば、ループバックアドレス）を使用することを推奨しますお互いに。これは、アグリゲータとデアグリゲーターのそれぞれの同定は、これらのデバイス上の任意の界面準位変化による影響を受けないことを保証します。今度は、これがより安定した動作になると、かなり凝集領域でRSVPシグナリングを減少させました。インターフェースに依存しないアドレスがアグリゲータとデアグリゲーターによって使用される場合、例えば、これらのデバイス上のインタフェースの障害は、単に与えられた一般的な集約の予約の再ルーティングをもたらすことができるが、これらに有する一般的な集約の予約にはなりません取り壊さと別の一つが確立されます。また、（依然として障害後の到達可能性を有しており、アグリゲータとデアグリゲーターが宛先への最短パス上に残っているアグリゲータとデアグリゲーターと仮定して）一般的な集約の予約にE2Eの予約のマッピングの変化をもたらさないであろう。
However, when identifying themselves to real RSVP neighbors (i.e., neighbors that are not on the other side of the aggregation region), the Aggregator and Deaggregator SHOULD continue using interface-dependent addresses as per regular [RSVP] procedures. This applies for example when the Aggregator identifies itself downstream as a PHOP for the generic aggregate reservation or identifies itself upstream as a NHOP (RSVP next hop) for an E2E reservation. This also applies when the Deaggregator identifies itself downstream as a PHOP for the E2E reservation or identifies itself upstream as a NHOP for the generic aggregate reservation. As part of the processing of generic aggregate reservations, interior routers (i.e., routers within the aggregation region) SHOULD continue using interface-dependent addresses as per regular [RSVP] procedures.
実際のRSVP隣人（凝集領域の他方の側にはない、すなわち、隣人）に自分自身を識別するときしかし、アグリゲータとデアグリゲーターは、通常[RSVP]の手順に従ってインターフェイス依存性アドレスを使用し続けるべきです。アグリゲータは、一般的な集計予約PHOPとしてそれ自体が下流の識別またはE2E予約のための上流NHOP（RSVP次ホップ）として自身を識別するとき、これは、例えば当てはまります。デアグリゲーターがE2E予約のPHOPとして下流自体を特定または汎用集約の予約のためのNHOPとして上流自身を識別する場合にも適用されます。一般的な集約の予約の処理の一部として、内部ルータ（凝集領域内、すなわち、ルータ）は正規[RSVP]の手順に従ってインターフェイス依存性アドレスを使用し続けるべきです。
More generally, within the aggregation region (i.e., between Aggregator and Deaggregator) the operation of RSVP should be modeled with the notion that E2E reservations are mapped to aggregate reservations and are no longer tied to physical interfaces (as was the case with regular RSVP). However, generic aggregate reservations (within the aggregation region) as well as E2E reservations (outside the aggregation region) retain the model of regular RVSP and remain tied to physical interfaces.
より一般的には、凝集領域内（すなわち、アグリゲータとデアグリゲーター間）RSVPの動作は、E2Eの予約は、予約を集約するためにマッピングされるという概念を用いてモデル化されるべきではないと（通常のRSVPとの場合のように）もはや物理インターフェイスに接続されています。しかし、一般的な（凝集領域内）集約の予約ならびに（凝集領域の外側）E2Eの予約は、通常RVSPのモデルを保持し、物理インタフェースに関連付けられたままです。
As discussed above, generic aggregate reservations may be established edge-to-edge as a result of the establishment of E2E reservations (from outside the aggregation region) that are to be aggregated over the aggregation region. However, generic aggregate reservations may also be used end-to-end by end-systems directly attached to a Diffserv domain, such as Public Switched Telephone Network (PSTN) gateways. In that case, the generic aggregate reservations may be established by the end-systems in response to application-level triggers such as voice call signaling. Alternatively, generic aggregate reservations may also be used edge-to-edge to manage bandwidth in a Diffserv cloud even if RSVP is not used end-to-end. A simple example of such a usage would be the static configuration of a generic aggregate reservation for a certain bandwidth for traffic from an ingress (Aggregator) router to an egress (Deaggregator) router.
上述したように、一般的な集計予約集合領域上に集約されることになる（凝集領域の外側から）E2Eの予約の確立の結果として、エッジ・ツー・エッジを確立することができます。しかし、一般的な集約の予約はまた、公衆交換電話網（PSTN）ゲートウェイスイッチなど、直接のDiffservドメインに取り付けられたエンド・システムによって、エンドツーエンドを使用することができます。その場合には、一般的な集約の予約は、アプリケーション・レベルに応じて、エンドシステムによって確立することができるような音声呼シグナリングとしてトリガー。代替的に、汎用の集約の予約はまた、RSVPはエンドツーエンドで使用されていない場合でも、Diffservのクラウドに帯域幅を管理するためのエッジ・ツー・エッジを使用することができます。このような使用の簡単な例は、入口（アグリゲータ）出力（デアグリゲーター）ルータにルータからのトラフィックのために特定の帯域幅のための一般的な集合予約の静的な構成であろう。
In this case, the establishment of the generic aggregate reservations is controlled by configuration on the Aggregator and on the Deaggregator. Configuration on the Aggregator triggers generation of the aggregate Path message and provides sufficient information to the Aggregator to derive the content of the GENERIC-AGGREGATE SESSION object. This would typically include Deaggregator IP address, PHB-ID and possibly VDstPort. Configuration on the Deaggregator would instruct the Deaggregator to respond to a received generic aggregate Path message and would provide sufficient information to the Deaggregator to control the reservation. This may include bandwidth to be reserved by the Deaggregator (for a given <Deaggregator, PHB-ID, VDstPort> tuple).
この場合、一般的な集約の予約の確立をアグリゲータに及びデアグリゲーターに構成することによって制御されます。アグリゲータの設定は、集合Pathメッセージの生成をトリガし、GENERIC-AGGREGATE SESSIONオブジェクトの内容を導出するアグリゲータに十分な情報を提供します。これは通常、デアグリゲータIPアドレス、PHB-IDおよびおそらくVDstPortが含まれるであろう。デアグリゲータの設定は、受け取った汎用の集計Pathメッセージに応答するデアグリゲータを命令すると、予約を制御するために、アグリゲーターに十分な情報を提供することになります。これは、（与えられた<デアグリゲーター、PHB-ID、VDstPort>タプルのために）デアグリゲーターによって予約される帯域幅を含んでもよいです。
In the absence of E2E microflow reservations, the Aggregator can use a variety of policies to set the DSCP of packets passing into the aggregation region and how they are mapped onto generic aggregate reservations, thus determining whether they gain access to the resources reserved by the aggregate reservation. These policies are a matter of local configuration, as is typical for a device at the edge of a Diffserv cloud.
E2Eのマイクロフローの予約がない場合、集約は、集約領域へ通過するパケットのDSCPを設定するポリシーの様々なを使用することができ、それらは、したがって、それらが凝集することによって予約されたリソースへのアクセスを得るかどうかを決定する、一般的な集約の予約にマッピングする方法予約。 Diffservのクラウドのエッジでデバイスに典型的であるように、これらのポリシーは、ローカル設定の問題です。
5. Example Usage Of Multiple Generic Aggregate Reservations per PHB from a Given Aggregator to a Given Deaggregator
与えられたデアグリゲータに与えられたアグリゲータからPHBごとに複数の汎用集計予約5.使用例
Let us consider the environment depicted in Figure 2 below. RSVP aggregation is used to support E2E reservations between Cloud-1, Cloud-2, and Cloud-3.
私たちは、以下の図2に示されている環境を考えてみましょう。 RSVP集約はクラウド1、クラウド2、及びクラウド3間E2E予約をサポートするために使用されます。
I----------I I----------I
I Cloud-1 I I Cloud-2 I
I----------I I----------I
| |
Agg-Deag-1------------ Agg-Deag-2
/ \
/ Aggregation |
| Region |
| |
| ---/
\ /
\Agg-Deag-3---------/
|
I----------I
I Cloud-3 I
I----------I
Figure 2 : Example Usage of Generic Aggregate IP Reservations
図2：一般的な集計IP予約の使用例
Let us assume that:
私たちはそれを想定してみましょう：
o The E2E reservations from Cloud-1 to Cloud-3 have a preemption of either P1 or P2.
クラウド3クラウド1からE2E予約oをP1またはP2のいずれかのプリエンプションを有します。
o The E2E reservations from Cloud-2 to Cloud-3 have a preemption of either P1 or P2.
クラウド3クラウド2からE2E予約oをP1またはP2のいずれかのプリエンプションを有します。
o The E2E reservations are only for Voice (which needs to be treated in the aggregation region using the EF -Expedited Forwarding- PHB).
E2E予約のみ（EF -Expedited Forwarding- PHBを用いて凝集領域で処理される必要がある）音声のためのものであるoを。
o Traffic from the E2E reservations is encapsulated in aggregate IP reservations from Aggregator to Deaggregator using Generic Routing Encapsulation [GRE] tunneling.
E2E予約からOトラフィックは、総称ルーティングカプセル化[GRE]トンネリングを使用してデアグリゲーターするアグリゲータから集約IP予約にカプセル化されます。
Then, the following generic aggregate RSVP reservations may be established from Agg-Deag-1 to Agg-Deag-3 for aggregation of the end-to-end RSVP reservations:
次に、以下の一般的な集約RSVP予約AGG-Deag -3-エンドツーエンドRSVP予約の集約のためにAGG-Deag-1から確立することができます。
(1) A first generic aggregate reservation for aggregation of Voice reservations from Cloud-1 to Cloud-3 requiring use of P1:
（1）P1のクラウド3要求される用途にクラウド-1からの音声の予約の集合のための最初の一般的な集約の予約：
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V1
PHB-ID = EF
Extended VDstPort = Agg-Deag-1
* STYLE = FF or SE
* STYLE = FFまたはSE
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-1
*のIPv4 / GPI FILTER_SPEC：IPv4のsrcaddress送信=フロント-AGG-1
* POLICY_DATA (PREEMPTION_PRI) = P1
* POLICY_DATA（PREEMPTION_PRI）= P1
(2) A second generic aggregate reservation for aggregation of Voice reservations from Cloud-1 to Cloud-3 requiring use of P2:
（2）P2のクラウド3要求される用途にクラウド-1からの音声の予約の集合のための第二の一般的な集約の予約：
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V2
PHB-ID = EF
Extended VDstPort = Agg-Deag-1
* STYLE = FF or SE
* STYLE = FFまたはSE
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-1
*のIPv4 / GPI FILTER_SPEC：IPv4のsrcaddress送信=フロント-AGG-1
* POLICY_DATA (PREEMPTION_PRI) = P2
* POLICY_DATA（PREEMPTION_PRI）= P2
where V1 and V2 are arbitrary VDstPort values picked by Agg-Deag-3.
V1とV2は、AGG-Deag-3で撮像された任意VDstPortの値です。
The following generic aggregate RSVP reservations may be established from Agg-Deag-2 to Agg-Deag-3 for aggregation of the end-to-end RSVP reservations:
以下の一般的な集約RSVP予約AGG-Deag -3-エンドツーエンドRSVP予約の集約のためにAGG-Deag-2から確立することができます。
(3) A third generic aggregate reservation for aggregation of Voice reservations from Cloud-2 to Cloud-3 requiring use of P1:
（3）P1のクラウド3要求される用途にクラウド2からの音声の予約の集合のための第三の一般的な集約の予約：
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V3
PHB-ID = EF
Extended VDstPort = Agg-Deag-2
* STYLE = FF or SE
* STYLE = FFまたはSE
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-2
*のIPv4 / GPI FILTER_SPEC：IPv4のsrcaddress送信=フロント-AGG-2
* POLICY_DATA (PREEMPTION_PRI) = P1
* POLICY_DATA（PREEMPTION_PRI）= P1
(4) A fourth generic aggregate reservation for aggregation of Voice reservations from Cloud-2 to Cloud-3 requiring use of P2:
（4）P2のクラウド3要求される用途にクラウド2からの音声の予約の集合のための第四の一般的な集約の予約：
* GENERIC-AGGREGATE-IP4 SESSION:
IPv4 DestAddress = Agg-Deag-3
vDstPort = V4
PHB-ID = EF
Extended VDstPort = Agg-Deag-2
* STYLE = FF or SE
* STYLE = FFまたはSE
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-2
*のIPv4 / GPI FILTER_SPEC：IPv4のsrcaddress送信=フロント-AGG-2
* POLICY_DATA (PREEMPTION_PRI) = P2
* POLICY_DATA（PREEMPTION_PRI）= P2
where V3 and V4 are arbitrary VDstPort values picked by Agg-Deag-3.
V3及びV4は、AGG-Deag-3で撮像された任意VDstPortの値です。
Note that V3 and V4 could be equal to V1 and V2 (respectively) since, in this example, the Extended VDstPort of the GENERIC-AGGREGATE Session contains the address of the Aggregator and, thus, ensures that different sessions are used from each Aggregator.
そのV3に注意しV4がV1とV2（それぞれ）ためには、この例では、GENERIC-AGGREGATEセッションの拡張VDstPortは、アグリゲータのアドレスが含まれており、従って、異なるセッションは、各アグリゲータから使用されていることを確実にするに等しいとすることができます。
In the environments addressed by this document, RSVP messages are used to control resource reservations for generic aggregate reservations and may be used to control resource reservations for E2E reservations being aggregated over the generic aggregate reservations. To ensure the integrity of the associated reservation and admission control mechanisms, the RSVP Authentication mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] may be used. These protect RSVP message integrity hop-by-hop and provide node authentication as well as replay protection, thereby protecting against corruption and spoofing of RSVP messages. These hop-by-hop integrity mechanisms can be naturally used to protect the RSVP messages used for generic aggregate reservations and to protect RSVP messages used for E2E reservations outside the aggregation region. These hop-by-hop RSVP integrity mechanisms can also be used to protect RSVP messages used for E2E reservations when those transit through the aggregation region. This is because the Aggregator and
この文書によって対処環境では、RSVPメッセージは、一般的な集約の予約のためのリソース予約を制御するために使用され、一般的な集約の予約上に集約されるE2Eの予約のためのリソース予約を制御するために使用することができます。関連する予約および入場制御機構の完全性を保証するために、[RSVP-CRYPTO1]で定義されたRSVP認証機構と[RSVP-CRYPTO2が使用され得ます。これらのプロテクトRSVPメッセージの整合性ホップバイホップすることにより、RSVPメッセージの破損やなりすましから守る、ノードの認証だけでなく、再生保護を提供します。これらのホップバイホップ完全性機構は当然一般的な集約の予約のために使用されるRSVPメッセージを保護するために、凝集領域外E2Eの予約のために使用されるRSVPメッセージを保護するために使用することができます。これらのホップバイホップRSVPの整合性メカニズムはまた、凝集領域を介してこれらのトランジットE2Eの予約に使用RSVPメッセージを保護するために使用することができます。これは、アグリゲータで、
Deaggregator behave as RSVP neighbors from the viewpoint of the E2E flows (even if they are not necessarily IP neighbors).
デアグリゲータ（彼らは必ずしもIP隣接していなくても）E2Eフローの観点から、RSVP隣人として振る舞います。
[RSVP-CRYPTO1] discusses several approaches for key distribution. First, the RSVP Authentication shared keys can be distributed manually. This is the base option and its support is mandated for any implementation. However, in some environments, this approach may become a burden if keys frequently change over time. Alternatively, a standard key management protocol for secure key distribution can be used. However, existing key distribution protocols may not be appropriate in all environments because of the complexity or operational burden they involve.
[RSVP-CRYPTO1]キー配布のためにいくつかのアプローチを議論します。まず、RSVP認証共有キーを手動で分配することができます。これは基本オプションであり、そのサポートは、任意の実装のために義務付けられています。キーは頻繁に時間をかけて変更した場合ただし、一部の環境では、このアプローチが負担になることがあります。代替的に、安全な鍵配布のための標準的な鍵管理プロトコルを使用することができます。しかし、既存の鍵配布プロトコルは理由彼らが関与し複雑さや運用負荷のすべての環境で適切でないかもしれません。
The use of RSVP Authentication in parts of the network where there may be one or more IP hops in between two RSVP neighbors raises an additional challenge. This is because, with some RSVP messages such as a Path message, an RSVP router does not know the RSVP next hop for that message at the time of forwarding it. In fact, part of the role of a Path message is precisely to discover the RSVP next hop (and to dynamically re-discover it when it changes, say because of a routing change). Hence, the RSVP router may not know which security association to use when forwarding such a message. This applies in particular to the case where RSVP Authentication mechanisms are to be used for protection of RSVP E2E messages (e.g., E2E Path) while they transit through an aggregation region and where the dynamic Deaggregator determination procedure defined in [RSVP-AGG] is used. This is because the Aggregator and the Deaggregator behave as RSVP neighbors for the E2E reservation, while there may be one or more IP hops in between them, and the Aggregator does not know ahead of time which router is going to act as the Deaggregator.
1つまたは複数のIPは、2人のRSVP隣人の間でホップがあるかもしれないネットワークの部分でRSVP認証の使用は、さらなる挑戦を提起します。これは、Pathメッセージなど、いくつかのRSVPメッセージで、RSVPルータがそれを転送する時に、そのメッセージのRSVPネクストホップを知らないからです。実際には、Pathメッセージの役割の一部を正確にRSVP次のホップを発見することである（それが変化したときに、動的にそれを再発見するために、ルーティングが原因の変更を言います）。したがって、RSVPルータは、メッセージを転送するときに使用するセキュリティアソシエーションを知らないかもしれません。これは、凝集領域を介して通過し、[RSVP-AGG]で定義された動的デアグリゲーターの決意手順が使用される場合ながらRSVP認証メカニズムは、RSVPのE2Eメッセージ（例えば、E2E経路）の保護のために使用される場合に当てはまります。 1つまたは複数のIPは、それらの間でホップし、アグリゲータは、ルータがアグリゲーターとして機能しようとしている前もって把握していないがあるかもしれませんしながら、アグリゲータとデアグリゲータは、E2Eの予約のためのRSVP隣人として振る舞うためです。
In that situation, one approach is to share the same RSVP Authentication shared key across all the RSVP routers of a part of the network where there may be RSVP neighbors with IP hops in between. For example, all the Aggregators or Deaggregators of an aggregation region could share the same RSVP Authentication key, while different per-neighbor keys could be used between any RSVP router pair straddling the boundary between two administrative domains that have agreed to use RSVP signaling.
そのような状況では、1つのアプローチは、IP間でホップでRSVP隣人があるかもしれないネットワークの部分のすべてのRSVPルータで同じRSVP認証共有鍵を共有することです。異なる単位の隣接キーがRSVPシグナリングを使用することに合意した2つの管理ドメイン間の境界を跨ぐ任意RSVPルータペアの間で使用することができるが、例えば、すべてのアグリゲータまたは凝集領域のデアグリゲータは、同じRSVP認証キーを共有することができます。
When the same RSVP Authentication shared key is to be shared among multiple RSVP neighbors, manual key distribution may be used. For situations where RSVP is being used for multicast flows, it might also be possible, in the future, to adapt a multicast key management method (e.g. from IETF Multicast Security Working Group) for key distribution with such multicast RSVP usage. For situations where RSVP is being used for unicast flows across domain boundaries, it is not currently clear how one might provide automated key management.
同じRSVP認証共有鍵は、複数のRSVP隣人の間で共有する場合、手動鍵配布を使用してもよいです。 RSVPは、マルチキャストフローのために使用されている状況では、それはまた、このようなマルチキャストRSVPの使用状況とキー配布のために（例えば、IETFマルチキャストセキュリティワーキンググループからの）マルチキャスト鍵管理方法を適応させるために、将来的には、可能であるかもしれません。 RSVPは、ドメインの境界を越えて、ユニキャストフローに使用されている状況では、1つが自動化されたキー管理を提供する方法を、現在明らかになっていません。
Specification of a specific automated key management technique is outside the scope of this document. Operators should consider these key management issues when contemplating deployment of this specification.
特定の自動化された鍵管理技術の仕様は、このドキュメントの範囲外です。この仕様の導入を検討する際のオペレータは、これらの重要な経営課題を検討すべきです。
The RSVP Authentication mechanisms do not provide confidentiality. If confidentiality is required, IPsec ESP [IPSEC-ESP] may be used, although it imposes the burden of key distribution. It also faces the additional issue discussed for key management above in the case where there can be IP hops in between RSVP hops. In the future, confidentiality solutions may be developed for the case where there can be IP hops in between RSVP hops, perhaps by adapting confidentiality solutions developed by the IETF MSEC Working Group. Such confidentiality solutions for RSVP are outside the scope of this document.
RSVP認証メカニズムは、機密性を提供していません。機密性が必要な場合は、鍵配布の負担を課しているが、IPsecのESP [IPSEC-ESP]は、使用されてもよいです。それはまた、IPがRSVPホップの間にホップが存在することができる場合には上記のキー管理のために議論追加の問題に直面しています。将来的には、機密性のソリューションは、IPは、おそらくIETF MSECワーキンググループによって開発された機密性のソリューションを適応させることによって、RSVPホップの間にホップが可能な場合のために開発することができます。 RSVPのためにこのような機密性ソリューションは、このドキュメントの範囲外です。
Protection against traffic analysis is also not provided by RSVP Authentication. Since generic aggregate reservations are intended to reserve resources collectively for a whole set of users or hosts, malicious snooping of the corresponding RSVP messages could provide more traffic analysis information than snooping of an E2E reservation. When RSVP neighbors are directly attached, mechanisms such as bulk link encryption might be used when protection against traffic analysis is required. This approach could be used inside the aggregation region for protection of the generic aggregate reservations. It may also be used outside the aggregation region for protection of the E2E reservation. However, it is not applicable to the protection of E2E reservations while the corresponding E2E RSVP messages transit through the aggregation region.
トラフィック分析に対する保護はまた、RSVP認証によって提供されていません。一般的な集計予約がユーザまたはホストのセット全体のための総称リソースを予約することが意図されているので、対応するRSVPメッセージの悪質なスヌーピングはE2E予約のスヌーピングより多くのトラフィック分析情報を提供することができます。 RSVP隣人が直接結合している場合、トラフィック分析に対する保護が必要な場合には、そのようなバルクリンク暗号化などのメカニズムが使用される可能性があります。このアプローチは、一般的な集約予約の保護のための凝集領域内に使用することができます。また、E2E予約の保護のために集約領域外に使用することができます。しかし、それは集約領域を介して対応するE2EのRSVPメッセージトランジットながらE2Eの予約の保護には適用されません。
When generic aggregate reservations are used for aggregation of E2E reservations, the security considerations discussed in [RSVP-AGG] apply and are revisited here.
一般的な集計予約がE2Eの予約を集約するために使用されている場合は、[RSVP-AGG]で説明したセキュリティの考慮事項が適用され、ここに再訪されています。
First, the loss of an aggregate reservation to an aggressor causes E2E flows to operate unreserved, and the reservation of a great excess of bandwidth may result in a denial of service. These issues are not confined to the extensions defined in the present document: RSVP itself has them. However, they may be exacerbated here by the fact that each aggregate reservation typically facilitates communication for many sessions. Hence, compromising one such aggregate reservation can result in more damage than compromising a typical E2E reservation. Use of the RSVP Authentication mechanisms to protect against such attacks has been discussed above.
まず、アグレッサに集約予約の損失がE2Eが予約されていない動作するように流れるせ、帯域幅の大過剰の予約は、サービスの拒否をもたらすことができます。これらの問題は、現在のドキュメントで定義された拡張子に限定されていません。自身がそれらを持っているRSVP。しかし、彼らはそれぞれの集計予約が一般的に多くのセッションのための通信を容易にしているという事実によって、ここで悪化することができます。したがって、そのような集約の予約を損なうことは一般的なE2E予約を損なうよりも損傷をもたらすことができます。このような攻撃から保護するRSVP認証メカニズムの使用は、上述されました。
An additional security consideration specific to RSVP aggregation involves the modification of the IP protocol number in RSVP Path messages that traverse an aggregation region. Malicious modification of the IP protocol number in a Path message would cause the message to be ignored by all subsequent RSVP devices on its path, preventing reservations from being made. It could even be possible to correct the value before it reached the receiver, making it difficult to detect the attack. Note that, in theory, it might also be possible for a node to modify the IP protocol number for non-RSVP messages as well, thus interfering with the operation of other protocols. It is RECOMMENDED that implementations of this specification only support modification of the IP protocol number for RSVP Path, PathTear, and ResvConf messages. That is, a general facility for modification of the IP protocol number SHOULD NOT be made available.
集約RSVPに固有の追加のセキュリティの考慮事項は、凝集領域を横切るのRSVP PathメッセージにおけるIPプロトコル番号の変更を含みます。 PathメッセージにおけるIPプロトコル番号の悪意のある変更が行われてから予約を防止すること、そのパス上のすべての後続RSVPデバイスによって無視されるべきメッセージを引き起こします。それも、それが困難な攻撃を検出すること、受信機に到達する前に値を補正することが可能である可能性があります。理論的には、それはまた、このようにして、他のプロトコルの動作を妨害、ならびに非RSVPメッセージのIPプロトコル番号を変更するノードに対して可能であるかもしれないことに留意されたいです。この仕様の実装は唯一のRSVPパス、PathTear、およびResvConfメッセージのIPプロトコル番号の変更をサポートすることが推奨されます。これは、IPプロトコル番号の変更のための一般的な機能が利用できるようにすべきではないです。
Network operators deploying routers with RSVP aggregation capability should be aware of the risks of inappropriate modification of the IP protocol number and should take appropriate steps (physical security, password protection, etc.) to reduce the risk that a router could be configured by an attacker to perform malicious modification of the protocol number.
RSVPの集約機能とルーターを展開ネットワークオペレータはIPプロトコル番号の不適切な変更のリスクを認識しておく必要があり、適切な手順（物理的なセキュリティ、パスワード保護など）を取るべきであるルータが攻撃者によって構成されることができるというリスクを減らすためにプロトコル番号の悪質な変更を実行します。
IANA modified the RSVP parameters registry, 'Class Names, Class Numbers, and Class Types' subregistry, and assigned two new C-Types under the existing SESSION Class (Class number 1), as described below:
IANAは、「クラス名、クラス番号、およびクラスタイプ」副登録、RSVPパラメータレジストリを変更し、そして以下に記載するように、既存のセッションクラス（クラス番号1）の下に2つの新しいC-タイプの割り当て：
Class
Number Class Name Reference
------ ----------------------- ---------
1 SESSION [RFC2205]
1 SESSION [RFC2205]
Class Types or C-Types:
クラスの型やC-タイプ：
17 GENERIC-AGGREGATE-IP4 [RFC4860] 18 GENERIC-AGGREGATE-IP6 [RFC4860]
17 GENERIC-AGGREGATE-IP4 [RFC4860] 18 GENERIC-AGGREGATE-IP6 [RFC4860]
IANA also modified the RSVP parameters registry, 'Class Names, Class Numbers, and Class Types' subregistry, and assigned one new Class Number for the SESSION-OF-INTEREST class and two new C-Types for that class, according to the table below:
IANAはまた、以下の表に従って、RSVPパラメータレジストリ、「クラス名、クラス番号、およびクラスタイプ」副登録を変更し、セッションの関心クラスおよびそのクラスのための2つの新しいC-タイプのために一つの新たなクラス番号を割り当てます：
Class
Number Class Name Reference
------ ----------------------- ---------
132 SESSION-OF-INTEREST [RFC4860]
132 SESSIONの関心[RFC4860]
Class Types or C-Types:
クラスの型やC-タイプ：
1 GENERIC-AGG-IP4-SOI [RFC4860] 2 GENERIC-AGG-IP6-SOI [RFC4860]
1 GENERIC-AGG-IP4-SOI [RFC4860] 2 GENERIC-AGG-IP6-SOI [RFC4860]
These allocations are in accordance with [RSVP-MOD].
これらの割り当ては、[RSVP-MOD]に従っています。
This document borrows heavily from [RSVP-AGG]. It also borrows the concepts of Virtual Destination Port and Extended Virtual Destination Port from [RSVP-IPSEC] and [RSVP-TE], respectively.
この文書では、[RSVP-AGG]から大いに借ります。それはまた、それぞれ、[RSVP-IPSEC]と[RSVP-TE]から仮想宛先ポートと拡張仮想宛先ポートの概念を借用します。
Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel Voce, Anil Agarwal, Alexander Sayenko, and Anca Zamfir for their input into the content of this document. Thanks to Steve Kent for insightful comments on usage of RSVP reservations in IPsec environments.
また、私たちは、この文書の内容に彼らの入力のためのフレッド・ベイカー、ロジャー・レヴェック、キャロルIturralde、ダニエル・ヴォーチェ、アニルAgarwalさん、アレクサンダーSayenko、及びANCA Zamfirに感謝します。 IPsecの環境でRSVP予約の使用に関する洞察に満ちたコメントのスティーブ・ケントに感謝します。
Ran Atkinson, Fred Baker, Luc Billot, Pascal Delprat, and Eric Vyncke provided guidance and suggestions for the security considerations section.
アトキンソン、フレッド・ベイカー、リュック・ビロ、パスカルDelprat、そしてエリックVynckeは、セキュリティ上の考慮事項セクションのための指導や提案を提供しました。
[IPSEC-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[IPSEC-ESP]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[PHB-ID] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[PHB-ID]ブラック、D.、つば、S.、大工、B.、およびF.ルFaucheur、 "当たりホップ行動識別コード"、RFC 3140、2001年6月。
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RSVP-AGG] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RSVP-AGG]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[RSVP-CRYPTO1] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RSVP-CRYPTO1]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RSVP-CRYPTO2] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RSVP-CRYPTO2]ブレーデン、R.とL.チャン、 "RSVP暗号化認証 - 更新メッセージタイプ価値"、RFC 3097、2001年4月。
[RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RSVP-IPSEC]バーガー、L.とT.オマリー、RFC 2207、1997年9月、 "IPSECデータのためのRSVP拡張フロー"。
[RSVP-MOD] Kompella, K. and J. Lang, "Procedures for Modifying the Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, October 2004.
[RSVP-MOD] Kompella、K.およびJ.ラング、 "リソース予約プロトコル（RSVP）を変更するための手順"、BCP 96、RFC 3936、2004年10月。
[BW-REDUC] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[BW-REDUC]ポーク、J.及びS. Dhesikan、 "リソース予約プロトコル（RSVP）予約フローの帯域幅を削減するための拡張"、RFC 4495、2006年5月。
[GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[GRE]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RSVP-PREEMP]ヘルツォーク、S.、2001年10月、RFC 3181、 "先取り優先権方針要素が通知さ"。
[RSVP-PROCESS] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[RSVP-PROCESS]ブレーデン、R.とL.チャン、 "資源予約プロトコル（RSVP） - バージョン1つのメッセージ処理ルール"、RFC 2209、1997年9月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209 、2001年12月。
[RSVP-TUNNEL] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RSVP-TUNNEL] Terzis、A.、Krawczyk、J.、Wroclawski、J.、およびL.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
[SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested Virtual Private Network", Work in Progress, February 2007.
[SIG-NESTED]ベイカー、F.およびP.ボーズ、 "ネストされた仮想プライベートネットワークにQoSシグナリング"、進歩、2007年2月での作業。
Appendix A. Example Signaling Flow
付録A.例シグナリングフロー
This appendix does not provide additional specification. It only illustrates the specification detailed in Section 4 through a possible flow of RSVP signaling messages. This flow assumes an environment where E2E reservations are aggregated over generic aggregate RSVP reservations. It illustrates a possible RSVP message flow that could take place in the successful establishment of a unicast E2E reservation that is the first between a given pair of Aggregator/Deaggregator.
この付録では、追加の仕様を提供していません。それだけでRSVPシグナリングメッセージのフローを可能セクション4で詳細な仕様を示します。この流れはE2Eの予約が一般的な集約RSVP予約の上に集約されている環境を想定しています。これは、アグリゲータ/デアグリゲーターの所与の対の間で最初にユニキャストE2E予約の成功確立に場所を取ることができる可能なRSVPメッセージフローを示します。
Aggregator Deaggregator
アグリゲータデアグリゲータ
E2E Path
----------->
(1)
E2E Path
------------------------------->
(2)
E2E PathErr(New-agg-needed,SOI=GAx)
<----------------------------------
E2E PathErr(New-agg-needed,SOI=GAy)
<----------------------------------
(3)
AggPath(Session=GAx)
------------------------------->
AggPath(Session=GAy)
------------------------------->
(4)
E2E Path
----------->
(5)
AggResv (Session=GAx)
<-------------------------------
AggResv (Session=GAy)
<-------------------------------
(6)
AggResvConfirm (Session=GAx)
------------------------------>
AggResvConfirm (Session=GAy)
------------------------------>
(7)
E2E Resv
<---------
(8)
E2E Resv (SOI=GAx)
<-----------------------------
(9)
E2E Resv
<-----------
(1) The Aggregator forwards E2E Path into the aggregation region after modifying its IP protocol number to RSVP-E2E-IGNORE
（1）するために、そのIPプロトコル番号を変更した後の凝集領域に集約転送E2EパスRSVP-E2Eは、IGNORE
(2) Let's assume no Aggregate Path exists. To be able to accurately update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC of Aggregate Path. In this example, the Deaggregator elects to instruct the Aggregator to set up Aggregate Path states for the two supported PHB-IDs. To do that, the Deaggregator sends two E2E PathErr messages with a New-Agg-Needed PathErr code. Both PathErr messages also contain a SESSION-OF-INTEREST (SOI) object. In the first E2E PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAx) whose PHB-ID is set to x. In the second E2E PathErr, the SOI contains a GENERIC-AGGREGATE SESSION (GAy) whose PHB-ID is set to y. In both messages the GENERIC-AGGREGATE SESSION contains an interface-independent Deaggregator address inside the DestAddress and appropriate values inside the vDstPort and Extended vDstPort fields.
（2）のは、何の集約パスが存在しないと仮定しましょう。正確E2EパスのADSPECを更新できるようにするには、デアグリゲータは、集約パスのADSPECを必要とします。この例では、デアグリゲータは、2つのサポートされているPHB-IDの集約パスの状態を設定するアグリゲータに指示することを選択します。そのためには、デアグリゲータは、New-AGG-必要なのPathErrコードを持つ2つのE2EのPathErrメッセージを送信します。両方のPathErrメッセージは、セッションの関心（SOI）オブジェクトを含みます。最初E2EたPathErrにおいて、SOIは、そのPHB-ID Xに設定されているGENERIC-AGGREGATE SESSION（GAX）を含みます。第E2EたPathErrにおいて、SOIは、そのPHB-ID yに設定されているGENERIC-AGGREGATE SESSION（GAY）を含みます。両方のメッセージにGENERIC-AGGREGATE SESSIONはDestAddressとvDstPort内の適切な値および拡張vDstPortフィールド内部インターフェースに依存しないデアグリゲーターアドレスを含みます。
(3) The Aggregator follows the request from the Deaggregator and signals an Aggregate Path for both GENERIC-AGGREGATE Sessions (GAx and GAy).
（3）集約はデアグリゲーターからの要求に従い、GENERIC-AGGREGATEセッション（GAXとGAY）の両方のために集約パス信号。
(4) The Deaggregator takes into account the information contained in the ADSPEC from both Aggregate Paths and updates the E2E Path ADSPEC accordingly. The Deaggregator also modifies the E2E Path IP protocol number to RSVP before forwarding it.
（4）デアグリゲーターを考慮に集約パスの両方からADSPECに含まれる情報を取得し、それに応じてE2EパスADSPECを更新します。デアグリゲータはまた、それを転送する前にRSVPするE2EパスIPプロトコル番号を変更します。
(5) In this example, the Deaggregator elects to immediately proceed with establishment of generic aggregate reservations for both PHB-IDs. In effect, the Deaggregator can be seen as anticipating the actual demand of E2E reservations so that resources are available on the generic aggregate reservations when the E2E Resv requests arrive, in order to speed up establishment of E2E reservations. Assume also that the Deaggregator includes the optional Resv Confirm Request in these Aggregate Resv.
（5）本例では、デアグリゲーターは直ちにPHB-IDの両方のための一般的な集約の予約の確立を続行することを選択します。実際には、デアグリゲータは、E2EのResv要求が到着したときのリソースは、一般的な集計予約で利用できるように、E2Eの予約の確立を高速化するために、E2Eの予約の実際の需要を先取りとして見ることができます。デアグリゲータは、これらの集計のResvではオプションのResv確認要求が含まれていることも前提としています。
(6) The Aggregator merely complies with the received ResvConfirm Request and returns the corresponding Aggregate ResvConfirm.
（6）集約は、単に受信ResvConfirm要求に準拠し、対応する集約ResvConfirmを返します。
(7) The Deaggregator has explicit confirmation that both Aggregate Resvs are established.
（7）デアグリゲーターは、両方の集合Resvsが確立された明示的な確認を有しています。
(8) On receipt of the E2E Resv, the Deaggregator applies the mapping policy defined by the network administrator to map the E2E Resv onto a generic aggregate reservation. Let's assume that this policy is such that the E2E reservation is to be mapped onto the generic aggregate reservation with PHB-ID=x. The Deaggregator knows that a generic aggregate reservation (GAx) is in place for the corresponding PHB-ID since (7). The Deaggregator performs admission control of the E2E Resv onto the generic aggregate reservation for PHB-ID=x (GAx). Assuming that the generic aggregate reservation for PHB-ID=x (GAx) had been established with sufficient bandwidth to support the E2E Resv, the Deaggregator adjusts its counter, tracking the unused bandwidth on the generic aggregate reservation. Then it forwards the E2E Resv to the Aggregator including a SESSION-OF-INTEREST object conveying the selected mapping onto GAx (and hence onto PHB-ID=x).
（8）E2EたResvを受信すると、デアグリゲーターは、一般的な集約の予約にE2EたResvをマッピングするために、ネットワーク管理者によって定義されたマッピングポリシーを適用します。のは、このポリシーはE2Eの予約がPHB-ID = xは、一般的な集計予約上にマッピングされるようなものであると仮定しよう。デアグリゲータは、一般的な集約の予約（GAX）は（7）ので、対応するPHB-IDのための場所であることを知ります。デアグリゲータは、PHB-ID = X（GAX）のための一般的な集約の予約にE2EたResvのアドミッション制御を行います。 PHB-ID = X（GAX）のための一般的な集計予約がE2EたResvをサポートするために十分な帯域幅との間で確立されていたと仮定すると、デアグリゲーターは、一般的な集約の予約に未使用の帯域幅を追跡し、そのカウンタを調整します。それはGAXに選択されたマッピングを搬送する（したがって、PHB-ID = Xに）セッションの関心物体を含むアグリゲータにE2EたResvを転送します。
(9) The Aggregator records the mapping of the E2E Resv onto GAx (and onto PHB-ID=x). The Aggregator removes the SOI object and forwards the E2E Resv towards the sender.
（9）アグリゲータがGAXにE2EたResvのマッピングを記録（およびPHB-ID = X上）。アグリゲータは、SOIオブジェクトを削除し、送信者に向けてE2EのResvを転送します。
Authors' Addresses
著者のアドレス
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France EMail: flefauch@cisco.com
フランソワ・リーパーシスコシステムズ社コーポレート・ヴィレッジグリーンサイド - T3ビル400、アベニューRoumanille 06410ビオソフィアアンティポリスフランスEメール：flefauch@cisco.com
Bruce Davie Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA EMail: bds@cisco.com
ブルース・デイビーシスコシステムズ株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA電子メール：bds@cisco.com
Pratik Bose Lockheed Martin 700 North Frederick Ave. Gaithersburg, MD 20879 USA EMail: pratik.bose@lmco.com
Pratikボーズロッキード・マーティン700ノースフレデリック・アベニュー。ゲーサーズバーグ、MD 20879 USA電子メール：pratik.bose@lmco.com
Chris Christou Booz Allen Hamilton 13200 Woodland Park Road Herndon, VA 20171 USA EMail: christou_chris@bah.com
クリスChristouのブーズ・アレン・ハミルトン13200ウッドランドパークロードハーンドン、VA 20171 USA電子メール：christou_chris@bah.com
Michael Davenport Booz Allen Hamilton Suite 390 5220 Pacific Concourse Drive Los Angeles, CA 90045 USA EMail: davenport_michael@bah.com
マイケル・ダベンポートブーズ・アレン・ハミルトンスイート390 5220パシフィック・コンコースドライブロサンゼルス、CA 90045 USA Eメール：davenport_michael@bah.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。