[要約] RFC 4860は、汎用の集約リソース予約プロトコル（RSVP）予約に関する情報を提供する。その目的は、RSVPを使用してネットワークリソースの予約を効率的に行うためのガイドラインを提供することである。
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）The IETF Trust（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）または与えられたPHBのセットのDiffServネットワークでリソースを予約できるようにします。RFC 3175は、Diffservクラウドを通過する際に、エンドツーエンドのRSVP予約をこのような集計予約にどのように集約できるかを定義しています。同じソースIPアドレス、宛先IPアドレス、およびPHB（またはPHBのセット）には、複数のこのような集計予約が必要な状況があります。ただし、これはRFC 3175で定義されている集計予約によってサポートされていません。これをサポートするために、現在のドキュメントでは、一般的な集計予約と呼ばれるより柔軟なタイプのRSVP予約を定義しています。特定のソースIPアドレスから特定の宛先IPアドレスまで、特定のPHB（またはPHBのセット）に対して、複数のこのような一般的な集約予約を確立できます。一般的な集計予約は、エンドツーエンドのRSVP予約を集約するために使用できます。このドキュメントは、このような集計の手順も定義しています。一般的な集計予約は、diffservネットワークに接続されたエンドシステムによって直接エンドツーエンドを使用することもできます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Related IETF Documents .....................................6
1.2. Organization of This Document ..............................6
1.3. Requirements Language ......................................7
2. Object Definition ...............................................7
2.1. SESSION Class ..............................................8
2.2. SESSION-OF-INTEREST (SOI) Class ...........................11
3. Processing Rules for Handling Generic Aggregate RSVP
Reservations ...................................................13
3.1. Extensions to Path and Resv Processing ....................13
4. Procedures for Aggregation over Generic Aggregate RSVP
Reservations ...................................................14
5. Example Usage Of Multiple Generic Aggregate Reservations
per PHB from a Given Aggregator to a Given Deaggregator ........19
6. Security Considerations ........................................21
7. IANA Considerations ............................................24
8. Acknowledgments ................................................25
9. Normative References ...........................................26
10. Informative References ........................................26
Appendix A. Example Signaling Flow ................................28
[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 Code Point>を特徴とするフローの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].
[RSVP-AGG]は、DiffServクラウドを通過する際に、このような集計予約にエンドツーエンド（E2E）予約を集約する手順を定義します。このような集計を図1に示します。このドキュメントは、[RSVP-AGG]で定義された用語を再利用します。
--------------------------
/ 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 = DEAGGREGATOR I =インテリアルーター
--> = E2E RSVP reservation
==> = Aggregate RSVP reservation
Figure 1 : Aggregation of E2E Reservations over Aggregate RSVP Reservations
図1：RSVP予約総額を介したE2E予約の集約
These aggregate reservations use a SESSION type specified in [RSVP-AGG] that contains the receiver (or Deaggregator) IP address and the Diffserv Code Point (DSCP) of the Per Hop Behavior (PHB) from which Diffserv resources are to be reserved. For example, in the case of IPv4, the SESSION object is specified as:
これらの集約予約は、[RSVP-AGG]で指定されたセッションタイプを使用します。このセッションタイプには、受信機（またはDeaggregator）IPアドレスと、Diffservリソースが予約されるPERホップ動作（PHB）のdiffservコードポイント（DSCP）が含まれます。たとえば、IPv4の場合、セッションオブジェクトは次のように指定されています。
o Class = SESSION, C-Type = RSVP-AGGREGATE-IP4
o class = session、c-type = 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 class = sender_template、c-type = 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宛先アドレスまで、特定のPHB（または指定されたPHB）に対して、単一の[RSVP-AGG]集約予約のみを確立できます。
Situations have since been identified where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). One example is where E2E reservations using different preemption priorities (as per [RSVP-PREEMP]) need to be aggregated through a Diffserv cloud using the same PHB. Using multiple aggregate reservations for the same PHB allows enforcement of the different preemption priorities within the aggregation region. In turn, this allows more efficient management of the Diffserv resources, and in periods of resource shortage, this allows sustainment of a larger number of E2E reservations with higher preemption priorities.
その後、同じソースIPアドレス、宛先IPアドレス、およびPHB（またはPHBのセット）に複数のこのような集計予約が必要な状況が特定されています。1つの例は、同じPHBを使用してDiffservクラウドを介して、異なる先制優先順位（[RSVP-Preemp]による）を使用したE2E予約を使用する必要がある場合です。同じ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集計を通じてネストされたVPN環境でエンドツーエンドのRSVP予約をどのように確立できるかを詳細に説明します。特に、[Sig-Nested]は、それぞれ異なる先制優先順位を持つ複数の並列汎用総予約（同じPHB）を使用して、エンドツーエンドの予約の先制優先度を効率的にサポートする方法を説明しています。
This document addresses this requirement for multiple aggregate reservations for the same PHB (or same set of PHBs), by defining a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservations. This is achieved primarily by adding the notions of a Virtual Destination Port and of an Extended Virtual Destination Port in the RSVP SESSION object.
このドキュメントでは、一般的な集計留置と呼ばれる、より柔軟なタイプの総計RSVP予約を定義することにより、同じPHB（または同じPHBのセット）の複数の集約予約のこの要件に対処します。これは、主に仮想宛先ポートとRSVPセッションオブジェクトに拡張された仮想宛先ポートの概念を追加することにより達成されます。
The notion of Virtual Destination Port was introduced in [RSVP-IPSEC] to address a similar requirement (albeit in a different context) for identification and demultiplexing of sessions beyond the IP destination address. This document reuses this notion from [RSVP-IPSEC] for identification and demultiplexing of generic aggregate sessions beyond the IP destination address and PHB. This allows multiple generic aggregate reservations to be established for a given PHB (or set of PHBs), from a given source IP address to a given destination IP address.
仮想宛先ポートの概念は、[RSVP-IPSEC]で導入され、IP宛先アドレスを超えたセッションの識別と非複数のプレックスのための同様の要件（別のコンテキストではありますが）に対処しました。このドキュメントは、[RSVP-IPSEC]からのこの概念を再利用して、IP宛先アドレスとPHBを超えた一般的な集計セッションの識別と非gultiplexを再評価します。これにより、特定のソース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は、トンネルイングレスノードの非常に便利なメカニズムを提供して、セッションの範囲を入り込み侵入ペアに絞り込みます。Ingressノードは、独自のIPアドレスの1つをグローバルに一意の識別子として使用し、拡張トンネルID、したがってセッションオブジェクト内に含めることにより、これを実現できます。このドキュメントは、[RSVP-TE]からの拡張トンネルIDというこの概念を再利用し、単に拡張された仮想宛先ポートを変更するだけです。これにより、一般的な集計セッションの範囲をアグリゲーターとディーグレジャーのペアに絞り込むための便利なメカニズムが提供されます。
The RSVP SESSION object for generic aggregate reservations uses the PHB Identification Code (PHB-ID) defined in [PHB-ID] to identify the PHB, or set of PHBs, from which the Diffserv resources are to be reserved. This is instead of using the Diffserv Code Point (DSCP) as per [RSVP-AGG]. Using the PHB-ID instead of the DSCP allows explicit indication of whether the Diffserv resources belong to a single PHB or to a set of PHBs. It also facilitates handling of situations where a generic aggregate reservation spans two (or more) Diffserv domains that use different DSCP values for the same Diffserv PHB (or set of PHBs) from which resources are reserved. This is because the PHB-ID allows conveying of the PHB (or set of PHBs) independently of what DSCP value(s) are used locally for that PHB (or set of PHBs).
ジェネリックアグリゲート予約のRSVPセッションオブジェクトは、[PHB-ID]で定義されたPHB識別コード（PHB-ID）を使用して、PHBまたはPHBのセットを識別します。これは、[RSVP-AGG]に従ってDiffServコードポイント（DSCP）を使用する代わりにです。DSCPの代わりにPHB-IDを使用すると、DiffServリソースが単一のPHBに属しているか、PHBのセットに属しているかを明示的に示すことができます。また、一般的な集約的な予約が、リソースが予約されている同じDifFServ PHB（またはPHBのセット）に異なるDSCP値を使用する2つの（またはそれ以上の）DIFSERVドメインに及ぶ状況の処理を容易にします。これは、PHB-IDにより、DSCP値がその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-Tunnel]は、さまざまな種類のトンネルでRSVPを実行する一般的なアプローチを説明しています。「タイプ2トンネル」と呼ばれるこれらのタイプのトンネルの1つは、このドキュメントで説明されている一般的な集計予約とある程度の類似性を持っています。類似性は、多くの個々のフローがそのトンネルの上に持ち込まれ、単一の骨材の予約がトンネルに行われるという事実に由来します。ただし、[RSVP-Tunnel]は、ネットワークのコア（トンネルエンドポイント間）でのDiffServベースの分類とスケジューリングの使用に対処するのではなく、分類のためにUDP/IPトンネルヘッダーに依存しています。これが、[RSVP-AGG]が[RSVPトンネル]のオブジェクトを超えて追加のオブジェクトと手順を必要としていた理由です。[RSVP-AGG]と同様に、このドキュメントは、集約領域でのDiffServベースの分類とスケジューリングの使用も想定しているため、[RSVPトンネル]のオブジェクトを超えて追加のオブジェクトと手順を必要とします。
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は、E2E RSVP予約の一般的な集計RSVP予約への集約を示すシグナル伝達フローの例を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
This document reuses the RSVP-AGGREGATE-IP4 FILTER_SPEC, RSVP-AGGREGATE-IP6 FILTER_SPEC, RSVP-AGGREGATE-IP4 SENDER_TEMPLATE, and RSVP-AGGREGATE-IP6 SENDER_TEMPLATE objects defined in [RSVP-AGG].
このドキュメントは、RSVP-Aggregate-IP4 Filter_Spec、RSVP-Aggregate-IP6 Filter_Spec、RSVP-Aggregate-IP4 Sender_Template、およびRSVP-Aggregate-IP6 Sender_Templateオブジェクトを[RSVP-Agg]で定義したものを再利用します。
This document defines:
このドキュメントは次のように定義しています。
- two new objects (GENERIC-AGGREGATE-IP4 SESSION and GENERIC-AGGREGATE-IP6 SESSION) under the existing SESSION Class, and
- 既存のセッションクラスの下で、2つの新しいオブジェクト（generic-aggregate-ip4セッションと汎用ggregate-ip6セッション）、および
- 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セッションと汎用総合-IP6セッションオブジェクトは、すべてのタイプのRSVPメッセージに適用できます。
This specification defines the use of the GENERIC-AGG-IP4-SOI and GENERIC-AGG-IP6-SOI objects in two circumstances:
この仕様では、2つの状況でのジェネリックAGG-IP4-SOIおよび汎用AGG-IP6-SOIオブジェクトの使用を定義します。
- inside an E2E PathErr message that contains an error code of NEW-AGGREGATE-NEEDED in order to convey the session of a new generic aggregate reservation that needs to be established.
- 確立する必要がある新しいジェネリック集計予約のセッションを伝えるために、新しい総合的に必要なエラーコードを含むE2E PATHERRメッセージの内部。
- inside an E2E Resv message in order to convey the session of the generic aggregate reservation onto which this E2E reservation needs to be mapped.
- E2E RESVメッセージの内部では、このE2E予約をマッピングする必要がある一般的な集約予約のセッションを伝えます。
Details of the corresponding procedures can be found in Section 4.
対応する手順の詳細は、セクション4に記載されています。
However, it is envisioned that the ability to signal, inside RSVP messages, the Session of another reservation (which has some relationship with the current RSVP reservation) might have some other applicability in the future. Thus, those objects have been specified in a more generic manner under a flexible SESSION-OF-INTEREST class.
ただし、RSVPメッセージ内で、別の予約のセッション（現在のRSVP予約と何らかの関係がある）が、将来他の適用可能性を持つ可能性があることが想定されています。したがって、これらのオブジェクトは、柔軟な対応セッションクラスの下で、より一般的な方法で指定されています。
All the new objects defined in this document are optional with respect to RSVP so that general RSVP implementations that are not concerned with generic aggregate reservations do not have to support these objects. RSVP routers supporting generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION object or the GENERIC-AGGREGATE-IP6 SESSION object, respectively. RSVP routers supporting RSVP aggregation over generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGG-IP4-SOI object or GENERIC-AGG-IP6-SOI object, respectively.
このドキュメントで定義されているすべての新しいオブジェクトは、RSVPに関してオプションであるため、一般的な集約予約に関係のない一般的なRSVP実装では、これらのオブジェクトをサポートする必要がありません。ジェネリック集合体IPv4またはIPv6の予約をサポートするRSVPルーターは、それぞれ汎用総合-IP4セッションオブジェクトまたは汎用総合-IP6セッションオブジェクトをサポートする必要があります。ジェネリック集約IPv4またはIPv6予約を介してRSVP集約をサポートするRSVPルーターは、それぞれ汎用AGG-IP4-SOIオブジェクトまたは汎用AGG-IP6-SOIオブジェクトをサポートする必要があります。
o GENERIC-AGGREGATE-IP4 SESSION object: Class = 1 (SESSION) C-Type = 17
o Generic-Aggregate-IP4セッションオブジェクト：class = 1（session）c-type = 17
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
IPv4 DestAddress (IPv4 Destination Address)
IPv4 DestAddress（IPv4宛先アドレス）
IPv4 address of the receiver (or Deaggregator).
受信機（または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セッションオブジェクトのフラグフィールドと同じです（[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またはPHBのセットのホップごとの動作識別コードを含む16ビットフィールド。そこからDiffServリソースを予約します。このフィールドは、[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ビット識別子は、一般的な集計予約の存続期間中に一定のままです。セッションの範囲をSender-Receiverペア（またはAggregator-Deaggregatorペア）に絞りたい送信者（またはアグリゲーター）は、ここにネットワーク一意の識別子としてIPv4アドレスを配置する必要があります。他の送信者（またはアグリゲーター）との共通のセッションを使用して、送信者（またはアグリゲーター）間で共有予約を使用するために共通のセッションを使用したい送信者（またはアグリゲーター）は、このフィールドをすべてのゼロに設定する必要があります。
o GENERIC-AGGREGATE-IP6 SESSION object: Class = 1 (SESSION) C-Type = 18
o Generic-Aggregate-IP6セッションオブジェクト：class = 1（session）c-type = 18
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| |
+ +
| Extended vDstPort |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 16 25 26 31
IPv6 DestAddress (IPv6 Destination Address)
IPv6 DestAddress（IPv6宛先アドレス）
IPv6 address of the receiver (or Deaggregator).
受信機（または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セッションオブジェクトのフラグフィールドと同じです（[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またはPHBのセットのホップごとの動作識別コードを含む16ビットフィールド。そこからDiffServリソースを予約します。このフィールドは、[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ビット識別子は、一般的な集計予約の存続期間中に一定のままです。セッションの範囲をSender-Receiverペア（またはAggregator-Deaggregatorペア）に絞りたい送信者（またはアグリゲーター）は、ここにネットワーク一意の識別子としてIPv6アドレスを配置する必要があります。他の送信者（またはアグリゲーター）との共通のセッションを使用して、送信者（またはアグリゲーター）間で共有予約を使用するために共通のセッションを使用したい送信者（またはアグリゲーター）は、このフィールドをすべてのゼロに設定する必要があります。
o GENERIC-AGG-IP4-SOI object: Class = 132 C-Type = 1
o generic-agg-ip4-soiオブジェクト：class = 132 c-type = 1
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP4 SESSION Object //
| |
+-------------+-------------+-------------+-------------+
Content of a GENERIC-AGGREGATE-IP4 SESSION Object:
汎用総合-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.
このフィールドには、予約に興味のあるセッションのセッションオブジェクトのコピーが含まれています。ジェネリックAGG-IP4-SOIの場合、この分野で伝えられる関心セッションは、一般的なアグレジェート-IP4セッションです。
o GENERIC-AGG-IP6-SOI object: Class = 132 C-Type = 2
o generic-agg-ip6-soiオブジェクト：class = 132 c-type = 2
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP6- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| |
// Content of a GENERIC-AGGREGATE-IP6 SESSION Object //
| |
+-------------+-------------+-------------+-------------+
Content of a GENERIC-AGGREGATE-IP6 SESSION Object:
汎用総合-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.
このフィールドには、予約に興味のあるセッションのセッションオブジェクトのコピーが含まれています。ジェネリックAGG-IP6-SOIの場合、この分野で伝えられる関心セッションは、一般的なアグレジェート-IP6セッションです。
For example, if a SESSION-OF-INTEREST object is used inside an E2E Resv message (as per the procedures defined in Section 4) to indicate which generic aggregate IPv4 session the E2E reservation is to be mapped onto, then the GENERIC-AGG-IP4-SOI object will be used, and it will be encoded like this:
たとえば、セッションセッションオブジェクトがE2E RESVメッセージ内（セクション4で定義されている手順に従って）内で使用されている場合、E2E予約がマッピングされる一般的な集約IPv4セッション、次に一般的なAGG-を示します。IP4-SOIオブジェクトが使用され、次のようにエンコードされます。
0 7 8 15 16 23 24 31
+-------------+-------------+-------------+-------------+
| | SOI |GEN-AGG-IP4- |
| Length (bytes) | Class-Num |SOI C-Type |
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+--+----------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
0 7 8 15 16 23 24 31
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.
セッションオブインターレストオブジェクトは、それ自体がセッションオブジェクトではないことに注意してください。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メッセージの処理と[RSVPプロセス]で提示された拡張機能を示します。これらの拡張機能は、汎用総合-IP4または汎用総合-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の特定の区別が行われない限り、一般的な凝集セッションと呼ばれます。。
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セッション、filter_spec、およびsender_templateオブジェクトを参照する場合、IPバージョンは含まれません。IPv4とIPv6の区別が作成されています。
The following PATH message processing changes are defined:
次のパスメッセージ処理の変更が定義されています。
o When a session is defined using the GENERIC-AGGREGATE SESSION object, only the [RSVP-AGG] RSVP-AGGREGATE SENDER_TEMPLATE may be used. When this condition is violated in a PATH message received by an RSVP end-station, the RSVP end-station SHOULD report a "Conflicting C-Type" API error to the application. When this condition is violated in a PATH message received by an RSVP router, the RSVP router MUST consider this as a message formatting error.
o 汎用総合セッションオブジェクトを使用してセッションを定義する場合、[rsvp-agg] rsvp-aggregate sender_templateのみを使用できます。RSVPエンドステーションによって受信されたパスメッセージでこの条件に違反した場合、RSVPエンドステーションは「矛盾するCタイプ」APIエラーをアプリケーションに報告する必要があります。RSVPルーターが受信したパスメッセージでこの条件に違反した場合、RSVPルーターはこれをメッセージフォーマットエラーと見なす必要があります。
o For PATH messages that contain the GENERIC-AGGREGATE SESSION object, the VDstPort value, the Extended VDstPort value, and the PHB-ID value should be recorded (in addition to the destination/Deaggregator address and source/Aggregator address). These values form part of the recorded state of the session. The PHB-ID may need to be passed to traffic control; however the vDstPort and Extended VDstPort are not passed to traffic control since they do not appear inside the data packets of the corresponding reservation.
o 一般的な凝集セッションオブジェクト、VDSTPORT値、拡張VDSTPORT値、およびPHB-ID値を含むパスメッセージの場合（宛先/Deaggregatorアドレスとソース/アグリゲーターアドレスに加えて）記録する必要があります。これらの値は、セッションの記録された状態の一部を形成します。PHB-IDは、トラフィックコントロールに渡す必要がある場合があります。ただし、VDSTPORTと拡張VDSTPORTは、対応する予約のデータパケット内に表示されないため、トラフィックコントロールに渡されません。
The following changes to RESV message processing are defined:
RESVメッセージ処理の次の変更が定義されています。
o When a RESV message contains a [RSVP-AGG] RSVP-AGGREGATE FILTER_SPEC, the session MUST be defined using either the RSVP-AGGREGATE SESSION object (as per [RSVP-AGG]) or the GENERIC-AGGREGATE SESSION object (as per this document). If this condition is not met, an RSVP router or end-station MUST consider that there is a message formatting error.
o RESVメッセージに[rsvp-agg] rsvp-aggregate filter_specが含まれている場合、セッションは、rsvp-aggregateセッションオブジェクト（[rsvp-agg]に従って）または汎用攻撃セッションオブジェクト（このドキュメントに従って）のいずれかを使用して定義する必要があります。）。この条件が満たされていない場合、RSVPルーターまたはエンドステーションは、メッセージフォーマットエラーがあることを考慮する必要があります。
o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION type is GENERIC-AGGREGATE, each node uses data classifiers as per the following:
o rsvp-aggregate filter_specが使用され、セッションタイプが一般的な凝集体である場合、各ノードは次のようにデータ分類子を使用します。
* 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.
* diffserv分類を実行するには、ノードはDSCPのみに基づいて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 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.
[RSVP-AGG]で指定されているように、Deaggregatorは、特定の集計予約で特定のE2E予約をマッピングする責任があります。Deaggregatorは、AggregatorにE2E PATHERRメッセージをNew-Aggregate-Neededのエラーコードを送信することにより、新しい集計予約の確立を要求します。[RSVP-AGG]では、Deaggregatorは、E2E PatherrにDCLASSオブジェクトを含め、対応するDSCPを内部にエンコードすることにより、新しい要求された集約予約のDSCPを伝えます。このドキュメントは、この手順を変更および拡張します。Deaggregatorは、要求された一般的な集約予約の確立に使用される汎用総合セッションを含む、E2E PatherrメッセージにInterestのセッションオブジェクトを含める必要があります。この一般的な凝集セッションには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.
Deaggregatorは、異なるアグリゲーターが特定のDeaggregatorへの集計パスに異なるセッションを使用することを簡単に保証できることに注意してください。これは、Deaggregatorが各アグリゲーターで異なるVDSTPortおよび/または拡張されたVDSTPort番号を簡単に選択できるため（たとえば、Aggregatorアドレスを拡張VDSTPortとして使用することで）、セッションに含まれる一般的なアグゲートセッション内のセッション内に通信できるためです。of-interestオブジェクト。これにより、すべてのアグリゲーターから特定のディーグレジャーターへの個別の予約を確立する簡単なソリューションが提供されます。逆に、複数のアグリゲーターにわたって予約の共有が必要な場合、Deaggregatorは同じVDSTPortとvdStportを複数のアグリゲーターに割り当てることでこれを促進することができ、したがって、E2E Patherrorrのセッションオブジェクト内の同じ一般的な凝集セッションを含めることができます。これらのアグリゲーターに送信されたメッセージ。アグリゲーターはすべて、同じ汎用総合セッションで集計パスを確立することができます。
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.
したがって、さまざまな共有シナリオを簡単にサポートできます。ポリシーに続いて、Deaggregatorがそれに続いて、どのアグリゲーターが共有または個別の予約を必要とするかを決定します。このドキュメントの範囲を超えています。
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]).
Deaggregatorは、E2E Patherrメッセージ（新集合の必要なエラーコードを使用）に、新たに必要な汎用総計予約の確立に使用する追加のRSVPオブジェクトを含めることもできます。たとえば、Deaggregatorは、E2E Patherに、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.
アグリゲーターが必要とする新しいアグレジェートのエラーコードで受信したE2E PATHERRメッセージの処理のための[RSVP-AGG]手順は、それに応じて拡張されます。セッションオブインテストオブジェクトを含むこのようなメッセージを受け取ったとき、アグリゲーターは一般的な集計予約の確立をトリガーする必要があります。特に、受信したセッションオブジェクトで見つかった一般的な総合セッションで集約パスメッセージの送信を開始する必要があります。RSVPが受信したE2E PATHERRメッセージにRSVPのシグナル前のプライリティポリシー要素が含まれている場合、アグリゲーターは、対応する汎用集約予約の集約パスにこのオブジェクトを含める必要があります。受信したE2E PatherRメッセージに他の追加のオブジェクトが含まれ、それらが新しい必要な総集計予約に関連するものと明確に解釈できる場合（E2E予約に関連するのではなく）、アグリゲーターには対応する集合パスにそれらを含める必要があります一般的な集計予約。アグリゲーターは、一般的な集約予約のためにソースアドレス（つまり、送信者テンプレートのアグリゲーターアドレスとして）として使用する必要があります。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.
Deaggregatorは、[RSVP-AGG]に記載されているものと同じ手順に従って、総RESV状態を確立、維持、クリアします。ただし、現在の仕様に従って動作するDeaggregatorは、一般的な集計予約を使用する必要があり、したがって、このドキュメントで前述した一般的な総合セッションを使用する必要があります。
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.
このドキュメントは、DeaggregatorとAggregator間のE2E RESVメッセージの交換に関連する[RSVP-AGG]の手順も変更します。Deaggregatorは、Aggregatorに一般的なAggregateセッションを指定して特定のE2E予約をマッピングするために、E2E RESVメッセージに新しいインテストセッションオブジェクトを含める必要があります。繰り返しますが、汎用総合セッション（Interest Objectに含まれる）にはPHB-IDが含まれているため、DCLASSオブジェクトをE2E RESVメッセージに含める必要はありません。アグリゲーターは、E2E RESVのセッションセッションオブジェクトを、対応するE2E予約がマッピングされている一般的な集約予約セッションを示すものとして解釈する必要があります。Aggregatorは、送信者に向かって上流のE2E RESVを送信するときに、Interestセッションオブジェクトを含めてはなりません。
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).
関連するポリシーに基づいて、Deaggregatorはある時点で、総予約が不要になり、取り壊されるべきであると判断する場合があります。その場合、Deaggregatorは集計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]は、アグリゲーターとDeaggregatorがそれぞれのアイデンティティを相互に伝える方法を説明しています。たとえば、アグリゲーターには、Agregation領域を通過するとDeaggregatorが下流に送信し、受信するE2EパスのRSVPホップオブジェクトにIPアドレスの1つを含めます。同様に、Deaggregatorは、E2E PATHERRメッセージのエラー仕様（新しいアグレジェートが必要なエラーコードを含む）およびE2E RESVのRSVPホップオブジェクトなど、さまざまなフィールドにIPアドレスのいずれかを含めることにより、アグリゲーターに識別します。メッセージ。ただし、[RSVP-AGG]は、そのような目的でアグリゲーターとDeaggregatorによって選択されるIPアドレスについては説明していません。これらのアドレスは、アグリゲーターとDeaggregatorを識別し、これらのデバイスの特定のインターフェイスを識別しないことを目的としているため、このドキュメントでは、アグリゲーターとDeaggregatorがインターフェイスに依存しないアドレス（例えば、ループバックアドレス）を使用することを推奨しています。お互いに。これにより、アグリゲーターとDeaggregatorのそれぞれの識別が、これらのデバイスのインターフェイス状態の変更によって影響を受けることが保証されます。次に、これにより、より安定した操作と、凝集領域でのRSVPシグナル伝達が大幅に減少します。たとえば、インターフェイスに依存しないアドレスがアグリゲーターとDeaggregatorによって使用されている場合、これらのデバイスでインターフェイスの障害が単に特定の一般的な集計リザベーションの再ルーティングにつながる可能性がありますが、ジェネリックアグリゲートリザベーションが必要になることはありません。取り壊して、もう1つを確立してください。さらに、ジェネリック集約予約の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の隣人（つまり、集約領域の反対側にない隣接）に身を識別する場合、アグリゲーターとDeaggregatorは、通常の[RSVP]手順に従ってインターフェイス依存アドレスを使用し続ける必要があります。これは、たとえば、アグリゲーターがジェネリック集約予約のPHOPとして下流に識別するか、E2E予約のNHOP（RSVP Next Hop）として上流に識別するときに適用されます。これは、Deaggregatorが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.
より一般的には、集約領域内（つまり、アグリゲーターとDeaggregatorの間）内で、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クラウドの帯域幅を管理することもできます。このような使用法の簡単な例は、イングレス（アグリゲーター）ルーターから出口（deaggregator）ルーターまでのトラフィックの特定の帯域幅の一般的な集約予約の静的構成です。
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).
この場合、一般的な集計予約の確立は、アグリゲーターとディーグレジャーの構成によって制御されます。アグリゲーターの構成は、集約パスメッセージの生成をトリガーし、汎用総合セッションオブジェクトのコンテンツを導出するためにアグリゲーターに十分な情報を提供します。これには、通常、Deaggregator IPアドレス、PHB-ID、および場合によってはVDSTPortが含まれます。Deaggregatorの構成は、Deaggregatorに受信した汎用集計パスメッセージに応答するように指示し、予約を制御するためにDeaggregatorに十分な情報を提供します。これには、Deaggregatorが予約する帯域幅（特定の<Deaggregator、PHB-ID、vdstport> tupleの場合）が含まれる場合があります。
In the absence of E2E microflow reservations, the Aggregator can use a variety of policies to set the DSCP of packets passing into the aggregation region and how they are mapped onto generic aggregate reservations, thus determining whether they gain access to the resources reserved by the aggregate reservation. These policies are a matter of local configuration, as is typical for a device at the edge of a Diffserv cloud.
E2Eマイクロフローの予約がない場合、アグリゲーターはさまざまなポリシーを使用して、アグリゲーション領域に渡るパケットのDSCPを設定し、それらが一般的な集計予約にマッピングされているため、集約によって予約されたリソースにアクセスできるかどうかを判断できます。予約。これらのポリシーは、diffservクラウドの端にあるデバイスに典型的なように、ローカル構成の問題です。
Let us consider the environment depicted in Figure 2 below. RSVP aggregation is used to support E2E reservations between Cloud-1, Cloud-2, and Cloud-3.
以下の図2に示す環境を考えてみましょう。RSVP集約は、Cloud-1、Cloud-2、およびCloud-3のE2E予約をサポートするために使用されます。
I----------I I----------I
I Cloud-1 I I Cloud-2 I
I----------I I----------I
| |
Agg-Deag-1------------ Agg-Deag-2
/ \
/ Aggregation |
| Region |
| |
| ---/
\ /
\Agg-Deag-3---------/
|
I----------I
I Cloud-3 I
I----------I
Figure 2 : Example Usage of Generic Aggregate IP Reservations
図2：一般的な集計IP予約の例の使用
Let us assume that:
それを想定しましょう：
o The E2E reservations from Cloud-1 to Cloud-3 have a preemption of either P1 or P2.
o Cloud-1からCloud-3へのE2E予約は、P1またはP2のいずれかの先制があります。
o The E2E reservations from Cloud-2 to Cloud-3 have a preemption of either P1 or P2.
o Cloud-2からCloud-3へのE2E予約は、P1またはP2のいずれかの先制があります。
o The E2E reservations are only for Voice (which needs to be treated in the aggregation region using the EF -Expedited Forwarding- PHB).
o E2Eの予約は、音声のみを対象としています（EF expedited転送-PHBを使用して凝集領域で処理する必要があります）。
o Traffic from the E2E reservations is encapsulated in aggregate IP reservations from Aggregator to Deaggregator using Generic Routing Encapsulation [GRE] tunneling.
o E2E予約からのトラフィックは、一般的なルーティングカプセル化[GRE]トンネリングを使用して、アグリゲーターからDeaggregatorへの集約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予約の集約のために、以下の汎用集約RSVP予約をAGG-DEAG-1からAgg-DEAG-3に確立できます。
(1) A first generic aggregate reservation for aggregation of Voice reservations from Cloud-1 to Cloud-3 requiring use of P1:
(1) P1の使用を必要とするクラウド1からクラウド3への音声予約の集約のための最初の一般的な集約予約：
* GENERIC-AGGREGATE-IP4 SESSION: IPv4 DestAddress = Agg-Deag-3 vDstPort = V1 PHB-ID = EF Extended VDstPort = Agg-Deag-1
* Generic-Aggregate-IP4セッション：IPv4 DestAddress = AGG-DEAG-3 VDSTPORT = V1 PHB-ID = EF拡張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-deag-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) Cloud-1からCloud-3への音声予約の集約のための2番目の一般的な集計予約：P2の使用を必要とする：
* GENERIC-AGGREGATE-IP4 SESSION: IPv4 DestAddress = Agg-Deag-3 vDstPort = V2 PHB-ID = EF Extended VDstPort = Agg-Deag-1
* Generic-Aggregate-IP4セッション：IPv4 DestAddress = AGG-DEAG-3 VDSTPORT = V2 PHB-ID = EF Extended VDSTPort = AGG-DEAG-1
* STYLE = FF or SE
* style = ffまたはse
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-1
* IPv4/gpi filter_spec：ipv4 srcaddress = agg-deag-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予約の集約のために、以下の一般的な集計RSVP予約をAgg-Deag-2からAgg-Deag-3に確立できます。
(3) A third generic aggregate reservation for aggregation of Voice reservations from Cloud-2 to Cloud-3 requiring use of P1:
(3) P1の使用を必要とするクラウド2からクラウド3への音声予約の集約のための3番目の一般的な集計予約：
* GENERIC-AGGREGATE-IP4 SESSION: IPv4 DestAddress = Agg-Deag-3 vDstPort = V3 PHB-ID = EF Extended VDstPort = Agg-Deag-2
* Generic-Aggregate-IP4セッション：IPv4 DestAddress = AGG-DEAG-3 VDSTPORT = V3 PHB-ID = EF拡張VDSTPORT = AGG-DEAG-2
* STYLE = FF or SE
* style = ffまたはse
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-2
* IPv4/GPIフィルター仕様：IPv4 SRCアドレス= AGG-DRAG-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の使用を必要とするクラウド2からクラウド3への音声予約の集約のための4番目の一般的な集計予約：
* GENERIC-AGGREGATE-IP4 SESSION: IPv4 DestAddress = Agg-Deag-3 vDstPort = V4 PHB-ID = EF Extended VDstPort = Agg-Deag-2
* Generic-Aggregate-IP4セッション：IPv4 DestAddress = AGG-DEAG-3 VDSTPORT = V4 PHB-ID = EF拡張VDSTPORT = AGG-DEAG-2
* STYLE = FF or SE
* style = ffまたはse
* IPv4/GPI FILTER_SPEC: IPv4 SrcAddress = Agg-Deag-2
* IPv4/GPIフィルター仕様：IPv4 SRCアドレス= AGG-DRAG-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-Drag-3によって選ばれた任意のWestport値です。
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.
この例では、一般的な凝集セッションの拡張VDSTポートにはアグリゲーターのアドレスが含まれているため、各アグリゲーターから異なるセッションが使用されることを保証するため、V3とV4はV1とV2に等しい可能性があることに注意してください。
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 Deaggregator behave as RSVP neighbors from the viewpoint of the E2E flows (even if they are not necessarily IP neighbors).
このドキュメントで扱われている環境では、RSVPメッセージを使用して、一般的な集計予約のリソース予約を制御し、一般的な集計予約にわたって集計されるE2E予約のリソース予約を制御するために使用できます。関連する予約および入学制御メカニズムの完全性を確保するために、[RSVP-CRYPTO1]および[RSVP-CRYPTO2]で定義されたRSVP認証メカニズムを使用することができます。これらは、RSVPメッセージの整合性ホップバイホップを保護し、ノード認証とリプレイ保護を提供するため、RSVPメッセージの破損とスプーフィングから保護します。これらのホップバイホップの整合性メカニズムは、一般的な集約予約に使用されるRSVPメッセージを保護し、集約領域以外のE2E予約に使用されるRSVPメッセージを保護するために自然に使用できます。これらのホップバイホップRSVP整合性メカニズムは、集約領域を通過するときにE2E予約に使用されるRSVPメッセージを保護するためにも使用できます。これは、AggregatorとDeaggregatorがE2Eフローの観点からRSVP隣人として振る舞うためです（必ずしもIP隣人ではない場合でも）。
[RSVP-CRYPTO1] discusses several approaches for key distribution. First, the RSVP Authentication shared keys can be distributed manually. This is the base option and its support is mandated for any implementation. However, in some environments, this approach may become a burden if keys frequently change over time. Alternatively, a standard key management protocol for secure key distribution can be used. However, existing key distribution protocols may not be appropriate in all environments because of the complexity or operational burden they involve.
[RSVP-CRYPTO1]は、キー分布のためのいくつかのアプローチについて説明します。まず、RSVP認証共有キーは手動で分散できます。これは基本オプションであり、そのサポートはあらゆる実装に対して義務付けられています。ただし、一部の環境では、キーが時間とともに頻繁に変化する場合、このアプローチは負担になる可能性があります。または、安全なキー分布のための標準のキー管理プロトコルを使用できます。ただし、既存の主要な分布プロトコルは、それらが関与する複雑さまたは運用上の負担のため、すべての環境で適切ではない場合があります。
The use of RSVP Authentication in parts of the network where there may be one or more IP hops in between two RSVP neighbors raises an additional challenge. This is because, with some RSVP messages such as a Path message, an RSVP router does not know the RSVP next hop for that message at the time of forwarding it. In fact, part of the role of a Path message is precisely to discover the RSVP next hop (and to dynamically re-discover it when it changes, say because of a routing change). Hence, the RSVP router may not know which security association to use when forwarding such a message. This applies in particular to the case where RSVP Authentication mechanisms are to be used for protection of RSVP E2E messages (e.g., E2E Path) while they transit through an aggregation region and where the dynamic Deaggregator determination procedure defined in [RSVP-AGG] is used. This is because the Aggregator and the Deaggregator behave as RSVP neighbors for the E2E reservation, while there may be one or more IP hops in between them, and the Aggregator does not know ahead of time which router is going to act as the Deaggregator.
2つのRSVP隣人の間に1つ以上のIPホップがある可能性のあるネットワークの一部でRSVP認証を使用すると、追加の課題が生じます。これは、パスメッセージなどのいくつかのRSVPメッセージで、RSVPルーターがRSVPの次のメッセージがそのメッセージを転送したときにホップを知らないためです。実際、パスメッセージの役割の一部は、RSVPの次のホップを正確に発見することです（ルーティングの変更のために、変更されたときに動的に再発見することです）。したがって、RSVPルーターは、そのようなメッセージを転送する際に使用するセキュリティ協会を知らない場合があります。これは、特にRSVP認証メカニズムがRSVP E2Eメッセージ（E2Eパスなど）の保護に使用される場合に適用されます。。これは、AggregatorとDeaggregatorがE2E予約のRSVP隣人として振る舞い、それらの間に1つ以上のIPホップがある可能性があり、アグリゲーターはどのルーターがDeaggregatorとして機能するかを事前に知らないためです。
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認証キーを共有できますが、RSVPシグナル伝達を使用することに同意した2つの管理ドメイン間の境界にまたがる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マルチキャストセキュリティワーキンググループから）を適応させることも可能かもしれません。ユニキャストフローがドメインの境界を越えて使用されている状況では、自動化された主要な管理をどのように提供するかは現在明確ではありません。
Specification of a specific automated key management technique is outside the scope of this document. Operators should consider these key management issues when contemplating deployment of this specification.
特定の自動化されたキー管理手法の仕様は、このドキュメントの範囲外です。オペレーターは、この仕様の展開を検討する際に、これらの主要な管理の問題を考慮する必要があります。
The RSVP Authentication mechanisms do not provide confidentiality. If confidentiality is required, IPsec ESP [IPSEC-ESP] may be used, although it imposes the burden of key distribution. It also faces the additional issue discussed for key management above in the case where there can be IP hops in between RSVP hops. In the future, confidentiality solutions may be developed for the case where there can be IP hops in between RSVP hops, perhaps by adapting confidentiality solutions developed by the IETF MSEC Working Group. Such confidentiality solutions for RSVP are outside the scope of this document.
RSVP認証メカニズムは機密性を提供しません。機密性が必要な場合は、重要な分布の負担を課しますが、IPSEC ESP [IPSEC-ESP]が使用される場合があります。また、RSVPホップの間にIPホップがある可能性がある場合、上記の主要な管理について議論された追加の問題に直面しています。将来的には、おそらくIETF MSECワーキンググループによって開発された機密性ソリューションを適応させることにより、RSVPホップの間にIPホップがある場合がある場合の機密性ソリューションを開発することができます。RSVPのこのような機密性ソリューションは、このドキュメントの範囲外です。
Protection against traffic analysis is also not provided by RSVP Authentication. Since generic aggregate reservations are intended to reserve resources collectively for a whole set of users or hosts, malicious snooping of the corresponding RSVP messages could provide more traffic analysis information than snooping of an E2E reservation. When RSVP neighbors are directly attached, mechanisms such as bulk link encryption might be used when protection against traffic analysis is required. This approach could be used inside the aggregation region for protection of the generic aggregate reservations. It may also be used outside the aggregation region for protection of the E2E reservation. However, it is not applicable to the protection of E2E reservations while the corresponding E2E RSVP messages transit through the aggregation region.
トラフィック分析に対する保護は、RSVP認証によっても提供されていません。一般的な集計予約は、ユーザーまたはホストのセット全体に集合的にリソースを予約することを目的としているため、対応するRSVPメッセージの悪意のあるスヌーピングは、E2E予約のスヌーピングよりも多くのトラフィック分析情報を提供する可能性があります。RSVPの近隣が直接接続されている場合、トラフィック分析に対する保護が必要な場合、バルクリンク暗号化などのメカニズムが使用される場合があります。このアプローチは、一般的な骨材の予約を保護するために、集約領域内で使用できます。また、E2E予約を保護するために集合領域の外側で使用することもできます。ただし、対応するE2E RSVPメッセージが集約領域を通過する一方で、E2E予約の保護には適用されません。
When generic aggregate reservations are used for aggregation of E2E reservations, the security considerations discussed in [RSVP-AGG] apply and are revisited here.
E2E予約の集約に一般的な集計予約が使用される場合、[RSVP-AGG]で議論されているセキュリティ上の考慮事項が適用され、ここで再検討されます。
First, the loss of an aggregate reservation to an aggressor causes E2E flows to operate unreserved, and the reservation of a great excess of bandwidth may result in a denial of service. These issues are not confined to the extensions defined in the present document: RSVP itself has them. However, they may be exacerbated here by the fact that each aggregate reservation typically facilitates communication for many sessions. Hence, compromising one such aggregate reservation can result in more damage than compromising a typical E2E reservation. Use of the RSVP Authentication mechanisms to protect against such attacks has been discussed above.
第一に、侵略者への総留保の喪失により、E2Eフローは予約されていない動作を引き起こし、帯域幅の大幅な留保によりサービスの拒否が生じる可能性があります。これらの問題は、現在のドキュメントで定義されている拡張機能に限定されていません。RSVP自体にはそれらがあります。ただし、これらは、各集計の予約が通常、多くのセッションのコミュニケーションを促進するという事実によって、ここで悪化する可能性があります。したがって、そのような総計を妥協すると、典型的なE2E予約を損なうよりも多くの損傷をもたらす可能性があります。このような攻撃から保護するためのRSVP認証メカニズムの使用については、上記で説明しています。
An additional security consideration specific to RSVP aggregation involves the modification of the IP protocol number in RSVP Path messages that traverse an aggregation region. Malicious modification 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パスメッセージのIPプロトコル番号の変更が含まれます。パスメッセージ内の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セッション[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パラメーターレジストリ、「クラス名、クラス番号、クラスタイプ」サブレジストリを変更し、以下の表によると、そのクラスのセッションクラスの1つの新しいクラス番号とそのクラスの2つの新しいCタイプを割り当てました。：
Class
Number Class Name Reference
------ ----------------------- ---------
132 SESSION-OF-INTEREST [RFC4860]
132セッションオブインテスト[RFC4860]
Class Types or C-Types:
クラスタイプまたはCタイプ：
1 GENERIC-AGG-IP4-SOI [RFC4860] 2 GENERIC-AGG-IP6-SOI [RFC4860]
1 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.
また、この文書の内容に入力してくれたフレッド・ベイカー、ロジャー・レバセク、キャロル・イトゥルラルデ、ダニエル・ボース、アニル・アガルワル、アレクサンダー・セーンコ、アンカ・ザムフィアに感謝します。IPSEC環境でのRSVP予約の使用に関する洞察に富んだコメントをしてくれたSteve Kentに感謝します。
Ran Atkinson, Fred Baker, Luc Billot, Pascal Delprat, and Eric Vyncke provided guidance and suggestions for the security considerations section.
Ran Atkinson、Fred Baker、Luc Billot、Pascal Delprat、およびEric Vynckeは、セキュリティに関する考慮事項セクションのガイダンスと提案を提供しました。
[IPSEC-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[IPSEC-ESP] Kent、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[PHB-ID] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[PHB-ID] Black、D.、Brim、S.、Carpenter、B。、およびF. Le Faucheur、「ホップの動作識別コード」、RFC 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] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「Resource Reservation Protocol（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] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「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] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RSVP-CRYPTO2] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RSVP-CRYPTO2] Braden、R。およびL. Zhang、「RSVP暗号化認証 - 更新されたメッセージタイプ値」、RFC 3097、2001年4月。
[RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RSVP-IPSEC] Berger、L。およびT. O'Malley、「IPSECデータフロー用のRSVP拡張」、RFC 2207、1997年9月。
[RSVP-MOD] Kompella, K. and J. Lang, "Procedures for Modifying the Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, October 2004.
[RSVP-Mod] Kompella、K。およびJ. Lang、「リソース予約プロトコル（RSVP）を変更する手順」、BCP 96、RFC 3936、2004年10月。
[BW-REDUC] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow", RFC 4495, May 2006.
[BW-Reduc] Polk、J。and 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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 2784、2000年3月。
[RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RSVP-Preemp] Herzog、S。、「シグナル前の先制優先政策要素」、RFC 3181、2001年10月。
[RSVP-PROCESS] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[RSVPプロセス] Braden、R。およびL. Zhang、「リソース予約プロトコル（RSVP） - バージョン1メッセージ処理ルール」、RFC 2209、1997年9月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSPトンネルのRSVPへの拡張"、RFC 3209、2001年12月。
[RSVP-TUNNEL] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RSVP-Tunnel] Terzis、A.、Krawczyk、J.、Wroclawski、J.、およびL. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、2000年1月。
[SIG-NESTED] Baker, F. and P. Bose, "QoS Signaling in a Nested Virtual Private Network", Work in Progress, February 2007.
[Sig-nested] Baker、F。and P. Bose、「ネストされた仮想プライベートネットワークでのQoSシグナル伝達」、2007年2月、進行中の作業。
This appendix does not provide additional specification. It only illustrates the specification detailed in Section 4 through a possible flow of RSVP signaling messages. This flow assumes an environment where E2E reservations are aggregated over generic aggregate RSVP reservations. It illustrates a possible RSVP message flow that could take place in the successful establishment of a unicast E2E reservation that is the first between a given pair of Aggregator/Deaggregator.
この付録では、追加の仕様は提供されていません。RSVPシグナリングメッセージの可能性のある流れを通じて、セクション4で詳述されている仕様のみを示しています。このフローは、一般的な総計RSVP予約にわたってE2E予約が集約される環境を想定しています。これは、アグリゲーター/Deaggregatorの特定のペアの間で最初のユニキャストE2E予約の成功した状態で行われる可能性のあるRSVPメッセージフローを示しています。
Aggregator Deaggregator
アグリゲーター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) Aggregatorは、IPプロトコル番号をRSVP-E2E-IGOREに変更した後、E2Eパスを集約領域に転送します
(2) Let's assume no Aggregate Path exists. To be able to accurately update the ADSPEC of the E2E Path, the Deaggregator needs the ADSPEC of Aggregate Path. In this example, the Deaggregator elects to instruct the Aggregator to set up Aggregate Path states for the two supported PHB-IDs. To do that, the Deaggregator 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を正確に更新できるようにするには、Deaggregatorが集約パスのADSPECを必要とします。この例では、Deaggregatorは、サポートされている2つのPHB-IDの集計パス状態を設定するようにアグリゲーターに指示することを選択します。そのために、Deaggregatorは2つのE2E PATHERRメッセージを新しいagg-Needed Patherrコードで送信します。両方のPatherrメッセージには、セッションの利益（SOI）オブジェクトも含まれています。最初のE2E Patherrでは、SOIには、PHB-IDがxに設定されているジェネリック凝集セッション（GAX）が含まれています。2番目のE2E Patherrでは、SOIには、PHB-IDがyに設定されている一般的な凝集セッション（Gay）が含まれています。両方のメッセージで、一般的な凝集セッションには、DestAddress内のインターフェイスに依存しないDeaggregatorアドレスが含まれ、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) アグリゲーターは、Deaggregatorからのリクエストに従い、ジェネリック凝集セッション（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) Deaggregatorは、ADSPECに含まれる集計パスの両方から含まれる情報を考慮し、それに応じてE2EパスADSPECを更新します。Deaggregatorは、E2E PATH IPプロトコル番号をRSVPに変更してから転送します。
(5) In this example, the Deaggregator elects to immediately proceed with establishment of generic aggregate reservations for both PHB-IDs. In effect, the Deaggregator can be seen as anticipating the actual demand of E2E reservations so that resources are available on the generic aggregate reservations when the E2E Resv requests arrive, in order to speed up establishment of E2E reservations. Assume also that the Deaggregator includes the optional Resv Confirm Request in these Aggregate Resv.
(5) この例では、Deaggregatorは、両方のPHB-IDの一般的な総計予約の確立を直ちに進めることを選択します。実際、Deaggregatorは、E2E RESV要求が到着すると、E2E予約の確立を高速化するために、E2E予約の実際の需要を予測すると見なすことができます。また、Deaggregatorには、これらの集計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) Deaggregatorは、両方の凝集RESVが確立されていることを明示的に確認しています。
(8) On receipt of the E2E Resv, the Deaggregator applies the mapping policy defined by the network administrator to map the E2E Resv onto a generic aggregate reservation. Let's assume that this policy is such that the E2E reservation is to be mapped onto the generic aggregate reservation with PHB-ID=x. The Deaggregator knows that a generic aggregate reservation (GAx) is in place for the corresponding PHB-ID since (7). The Deaggregator performs admission control of the E2E Resv onto the generic aggregate reservation for PHB-ID=x (GAx). Assuming that the generic aggregate reservation for PHB-ID=x (GAx) had been established with sufficient bandwidth to support the E2E Resv, the Deaggregator adjusts its counter, tracking the unused bandwidth on the generic aggregate reservation. Then it forwards the E2E Resv to the Aggregator including a SESSION-OF-INTEREST object conveying the selected mapping onto GAx (and hence onto PHB-ID=x).
(8) E2E RESVを受け取ると、Deaggregatorは、ネットワーク管理者によって定義されたマッピングポリシーを適用して、E2E RESVを一般的な集約予約にマッピングします。このポリシーは、E2E予約がPHB-ID = xを使用して汎用集計予約にマッピングされるようなものであると仮定します。Deaggregatorは、（7）以来、対応するPHB-IDには一般的な集約予約（GAX）が整っていることを知っています。Deaggregatorは、PHB-ID = X（GAX）の一般的な集計予約にE2E RESVの入場制御を実行します。PHB-ID = X（GAX）の一般的な骨材予約がE2E RESVをサポートするのに十分な帯域幅で確立されていたと仮定すると、Deaggregatorはカウンターを調整し、一般的な集合体予約の未使用の帯域幅を追跡します。次に、選択したマッピングをGAXに伝達する（そしてPHB-ID = x）に伝達する対立セッションオブジェクトを含む、Aggregatorに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) アグリゲーターは、E2E RESVのGAX（およびPHB-ID = x）にマッピングを記録します。アグリゲーターはSOIオブジェクトを削除し、E2E RESVを送信者に転送します。
Authors' Addresses
著者のアドレス
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France EMail: flefauch@cisco.com
Francois Le Faucheur Cisco Systems、Inc。Village D'Entreprise Green Side -Batiment T3 400、Avenue de Roumanille 06410 Biot Sophia -Antipolis France Email：flefauch@cisco.com
Bruce Davie Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA EMail: bds@cisco.com
Bruce Davie Cisco Systems、Inc。1414 Massachusetts Ave. Boxborough、MA 01719 USAメール：bds@cisco.com
Pratik Bose Lockheed Martin 700 North Frederick Ave. Gaithersburg, MD 20879 USA EMail: pratik.bose@lmco.com
Pratik Bose Lockheed Martin 700 North Frederick Ave. Gaithersburg、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
クリス・クリストゥ・ブーズ・アレン・ハミルトン13200ウッドランドパークロードハーンドン、バージニア州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太平洋コンコースドライブロサンゼルス、カリフォルニア州90045 USAメール：davenport_michael@bah.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。