Network Working Group F. Le Faucheur, Ed.
Request for Comments: 4804 Cisco Systems, Inc.
Category: Standards Track February 2007
Aggregation of Resource ReSerVation Protocol (RSVP)
Reservations over MPLS TE/DS-TE Tunnels
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 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations. This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels.
RFC 3175は、リソース予約プロトコル（RSVP）集約RSVP予約オーバーエンド・ツー・エンドの予約の凝集を指定します。この文書では、MPLSトラフィックエンジニアリング（TE）トンネルやMPLSのDiffservを意識したMPLSトラフィックエンジニアリング（DS-TE）トンネルを介しRSVPエンドツーエンドの予約の凝集を指定します。このアプローチは、RFC 3175に基づいており、単にMPLS TEトンネルの代わりに集約RSVP予約上の操作のための対応する手順を変更しています。ネットワークのコア内のデバイスは、エンドツーエンドのRSVPの予約を知らないとMPLS TEトンネルの唯一知っているので、このアプローチは、スケーラブルな方法でフローの非常に多数のアドミッション制御を実現するために使用することができます。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................7
3. Definitions .....................................................7
4. Operations of RSVP Aggregation over TE with
Pre-established Tunnels .........................................8
4.1. Reference Model ............................................9
4.2. Receipt of E2E Path Message by the Aggregator ..............9
4.3. Handling of E2E Path Message by Transit LSRs ..............11
4.4. Receipt of E2E Path Message by the Deaggregator ...........11
4.5. Handling of E2E Resv Message by the Deaggregator ..........12
4.6. Handling of E2E Resv Message by the Aggregator ............12
4.7. Forwarding of E2E Traffic by the Aggregator ...............14
4.8. Removal of E2E Reservations ...............................14
4.9. Removal of the TE Tunnel ..................................14
4.10. Example Signaling Flow ...................................15
5. IPv4 and IPv6 Applicability ....................................16
6. E2E Reservations Applicability .................................16
7. Example Deployment Scenarios ...................................16
7.1. Voice and Video Reservations Scenario .....................16
7.2. PSTN/3G Voice Trunking Scenario ...........................17
8. Security Considerations ........................................18
9. Acknowledgments ................................................20
10. Normative References ..........................................20
11. Informative References ........................................21
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator ........23
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels
for VoIP Call Admission Control (CAC) ................25
The Integrated Services (Intserv) [INT-SERV] architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks.
統合サービス（IntServの）INT-SERV]アーキテクチャ異種ネットワーク上のアプリケーションへのサービス（QOS）のエンド・ツー・エンド品質の送達のための手段を提供します。
[RSVP] defines the Resource reSerVation Protocol that can be used by applications to request resources from the network. The network responds by explicitly admitting or rejecting these RSVP requests. Certain applications that have quantifiable resource requirements express these requirements using Intserv parameters as defined in the appropriate Intserv service specifications ([GUARANTEED], [CONTROLLED]).
[RSVP]はネットワークからリソースを要求するためにアプリケーションで使用可能なリソース予約プロトコルを定義します。ネットワークは、明示的に認めるか、これらのRSVP要求を拒否することによって応答します。適切なのIntServサービス仕様（[CONTROLLED]、[保証]）で定義されるように定量化リソース要件を有する特定の用途は、IntServのパラメータを使用してこれらの要件を発現します。
The Differentiated Services (DiffServ) architecture ([DIFFSERV]) was then developed to support the differentiated treatment of packets in very large scale environments. In contrast to the per-flow orientation of Intserv and RSVP, Diffserv networks classify packets into one of a small number of aggregated flows or "classes", based on the Diffserv codepoint (DSCP) in the packet IP header. At each Diffserv router, packets are subjected to a "per-hop behavior" (PHB), which is invoked by the DSCP. The primary benefit of Diffserv is its scalability. Diffserv eliminates the need for per-flow state and per-flow processing, and therefore scales well to large networks.
差別化サービス（DiffServの）アーキテクチャ（[DIFFSERV]）を非常に大規模な環境におけるパケットの微分処理をサポートするために開発されました。 IntServとRSVPのフローごとの向きとは対照的に、DiffservのネットワークはパケットのIPヘッダ内のDiffservコードポイント（DSCP）に基づいて、集約フローまたは「クラス」の少数の一つにパケットを分類します。それぞれのDiffservルータにおいて、パケットはDSCPによって呼び出される「ホップ単位動作」（PHB）に供されます。 Diffservのの主な利点は、そのスケーラビリティです。 DiffServはフロー毎の状態とフローごとの処理の必要性を排除し、したがって大規模なネットワークに適切に拡張します。
However, DiffServ does not include any mechanism for communication between applications and the network. Thus, as detailed in [INT-DIFF], significant benefits can be achieved by using Intserv over Diffserv including resource-based admission control, policy-based admission control, assistance in traffic identification/classification, and traffic conditioning. As discussed in [INT-DIFF], Intserv can operate over Diffserv in multiple ways. For example, the Diffserv region may be statically provisioned or RSVP aware. When it is RSVP aware, several mechanisms may be used to support dynamic provisioning and topology-aware admission control, including aggregate RSVP reservations, per-flow RSVP, or a bandwidth broker. The advantage of using aggregate RSVP reservations is that it offers dynamic, topology-aware admission control over the Diffserv region without per-flow reservations and the associated level of RSVP signaling in the Diffserv core. In turn, this allows dynamic, topology-aware admission control of flows requiring QoS reservations over the Diffserv core even when the total number of such flows carried over the Diffserv core is extremely large.
しかし、DiffServは、アプリケーションとネットワークの間の通信のための任意のメカニズムが含まれていません。したがって、[INT-DIFF]に詳述されるように、有意な利点は、リソースベースのアドミッション制御、ポリシーベースのアドミッション制御、トラフィック識別/分類に案内、交通調節などのDiffserv上のIntServを使用することによって達成することができます。 [INT-DIFF]で説明したように、のIntServは、複数の方法でのDiffservにわたって動作することができます。例えば、Diffservの領域は、静的プロビジョニングまたは認識RSVPすることができます。それはRSVP認識している場合、いくつかのメカニズムは、集約RSVP予約、フローごとのRSVP、または帯域幅ブローカーを含む動的プロビジョニングおよびトポロジー対応アドミッション制御をサポートするために使用されてもよいです。集約RSVP予約を使用することの利点は、フローごとの予約とDiffservコアにおけるRSVPシグナリングの関連レベル無しのDiffserv領域にわたって動的、トポロジ対応アドミッション制御を提供することです。今度は、これは、Diffservのコアを介して搬送されるようなフローの総数が非常に大きい場合でもDiffservのコア上にQoS予約を要求フローの動的なトポロジ対応アドミッション制御を可能にします。
[RSVP-AGG] and [RSVP-GEN-AGG] describe in detail how to perform such aggregation of end-to-end RSVP reservations over aggregate RSVP reservations in a Diffserv cloud. They establish an architecture where multiple end-to-end RSVP reservations sharing the same ingress router (Aggregator) and egress router (Deaggregator) at the edges of an "aggregation region" can be mapped onto a single aggregate reservation within the aggregation region. This considerably reduces the amount of reservation state that needs to be maintained by routers within the aggregation region. Furthermore, traffic belonging to aggregate reservations is classified in the data path purely using Diffserv marking.
[RSVP-AGG]および[RSVP-GEN-AGG]のDiffservクラウドにおける集約RSVP予約上のエンドツーエンドのRSVPの予約のような集計を実行する方法を詳細に述べます。彼らは、「凝集領域」のエッジで同じ入口ルータ（アグリゲータ）と出口ルータ（デアグリゲーター）を共有する複数のエンドツーエンドのRSVP予約が凝集領域内の単一の集約の予約にマッピングすることができるアーキテクチャを確立します。これは、かなり凝集領域内のルータによって維持される必要がある予約状態の量を減少させます。また、予約を集約するために属するトラフィックは、純粋にマーキングのDiffservを使用してデータパスに分類されます。
[MPLS-TE] describes how MPLS Traffic Engineering (TE) tunnels can be used to carry arbitrary aggregates of traffic for the purposes of traffic engineering. [RSVP-TE] specifies how such MPLS TE tunnels can be established using RSVP-TE signaling. MPLS TE uses Constraint-Based Routing to compute the path for a TE tunnel. Then, Admission Control is performed during the establishment of TE tunnels to ensure they are granted their requested resources.
[MPLS-TE]はMPLSトラフィックエンジニアリング（TE）トンネルはトラフィックエンジニアリングの目的のために、トラフィックの任意の集合体を搬送するために使用することができる方法を説明します。 [RSVP-TEは、このようなMPLS TEトンネルは、RSVP-TEシグナリングを用いて確立することができる方法を指定します。 MPLS TEは、TEトンネルのパスを計算するために、制約ベースのルーティングを使用します。次に、アドミッション制御は、彼らが要求されたリソースを付与されていることを確認するためにTEトンネルの確立中に行われます。
[DSTE-REQ] presents the Service Providers requirements for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). With DS-TE, separate DS-TE tunnels can be used to carry different Diffserv classes of traffic, and different resource constraints can be enforced for these different classes. [DSTE-PROTO] specifies RSVP-TE signaling extensions as well as OSPF and Intermediate System to Intermediate System (IS-IS) extensions for support of DS-TE.
[DSTE - REQ]のDiffservを意識したMPLSトラフィックエンジニアリング（DSTE）をサポートするためのサービスプロバイダの要件を提示します。 DS-TEを使用すると、別のDS-TEトンネルはトラフィックの異なるDiffservのクラスを運ぶために使用することができ、かつ異なるリソースの制約は、これらの異なるクラスのために強制することができます。 [DSTE - プロト]は中間システム（IS-IS）DSTEのサポートのための拡張にRSVP-TEシグナリング拡張ならびにOSPFおよび中間システムを指定します。
In the rest of this document we will refer to both TE tunnels and DS-TE tunnels simply as "TE tunnels".
このドキュメントの残りの部分では、単に「TEトンネル」としてTEトンネルおよびDS-TEトンネルの両方を指します。
TE tunnels have much in common with the aggregate RSVP reservations used in [RSVP-AGG] and [RSVP-GEN-AGG]:
TEトンネルは[RSVP-AGG]で使用される集約RSVP予約と多くの共通点を持っているし、[RSVP-GEN-AGG]：
- A TE tunnel is subject to Admission Control and thus is effectively an aggregate bandwidth reservation.
- TEトンネルは、アドミッション制御の対象であり、従って、有効総帯域幅予約あります。
- In the data plane, packet scheduling relies exclusively on Diffserv classification and PHBs.
- データプレーンでは、パケットスケジューリングは、Diffservの分類とのPHBのみに依存しています。
- Both TE tunnels and aggregate RSVP reservations are controlled by "intelligent" devices on the edge of the "aggregation core" (Head-end and Tail-end in the case of TE tunnels; Aggregator and Deaggregator in the case of aggregate RSVP reservations.
アグリゲータとデアグリゲーター集約RSVPの予約の場合には、 - TEトンネルと集約RSVPの予約の両方がTEトンネルの場合には「集約コア」（ヘッドエンドとテールエンドの縁の「インテリジェント」デバイスによって制御されます。
- Both TE tunnels and aggregate RSVP reservations are signaled using the RSVP protocol (with some extensions defined in [RSVP-TE] and [DSTE-PROTO] respectively for TE tunnels and DS-TE tunnels).
- TEトンネルと集約RSVPの予約の両方が（[RSVP-TE]および[DSTE - プロト]それぞれTEトンネルとDSTEトンネルの定義されたいくつかの拡張子を持つ）、RSVPプロトコルを用いてシグナリングされます。
This document provides a detailed specification for performing aggregation of end-to-end RSVP reservations over MPLS TE tunnels (which act as aggregate reservations in the core). This document builds on the RSVP Aggregation procedures defined in [RSVP-AGG] and [RSVP-GEN-AGG], and only changes those where necessary to operate over TE tunnels. With [RSVP-AGG] and [RSVP-GEN-AGG], a lot of responsibilities (such as mapping end-to-end reservations to Aggregate reservations and resizing the Aggregate reservations) are assigned to the Deaggregator (which is the equivalent of the tunnel Tail-end) while with TE, the tunnels are controlled by the tunnel Head-end. Hence, the main change over the RSVP Aggregations procedures defined in [RSVP-AGG] and [RSVP-GEN-AGG] is to modify these procedures to reassign responsibilities from the Deaggregator to the Aggregator (i.e., the tunnel Head-end).
この文書は、（コアに集約予約として作用する）MPLS TEトンネル上のエンドツーエンドのRSVPの予約の集合を実行するための詳細な仕様を提供します。この文書では、[RSVP-AGG]および[RSVP-GEN-AGG]で定義されたRSVP集約手順で構築し、唯一必要な場合TEトンネル上で動作するようにそれらを変更します。 [RSVP-AGG]および[RSVP-GEN-AGG]と、（このようなマッピングのエンドツーエンドの予約などの予約を集約し、集約の予約のサイズを変更する）責任の多くは、と等価であるデアグリゲーター（に割り当てられていますトンネルテールエンド）TEと、トンネルは、トンネルヘッドエンドによって制御されます。したがって、[RSVP-AGG]および[RSVP-GEN-AGG]で定義されたRSVP集約手続き上メイン変化がアグリゲータ（すなわち、トンネルヘッドエンド）にデアグリゲーターから責任を再割り当てするために、これらの手順を修正することです。
[LSP-HIER] defines how to aggregate MPLS TE Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. This involves nesting of end-to-end LSPs into an aggregate LSP in the core (by using the label stack construct). Since end-to-end TE LSPs are themselves signaled with RSVP-TE and reserve resources at every hop, this can be looked at as a form of aggregation of RSVP(-TE) reservations over MPLS TE tunnels. This document capitalizes on the similarities between nesting of TE LSPs over TE tunnels and RSVP aggregation over TE tunnels, and reuses the procedures of [LSP-HIER] wherever possible.
[LSP-HIER]はMPLS TEラベルを集約する方法を定義し、そのようなLSPの階層を作成することにより、パス（LSPを）スイッチ。これは、（ラベルスタック構築物を使用して）コアに集約LSPにエンドツーエンドLSPのネスティングを含みます。エンドツーエンドのTE LSPのため自体はすべてのホップでRSVP-TEと予備リソースでシグナリングされる、これは、MPLS TEトンネル上のRSVPの集合の形（-TE）予約として見たことができます。この文書では、TEトンネル上TEトンネル上TE LSPのネスティングおよびRSVP集合間の類似性を活かして、可能な限り[LSP-HIER]の手順を再利用します。
This document also builds on the "RSVP over Tunnels" concepts of RFC 2746 [RSVP-TUN]. It differs from that specification in the following ways:
この文書はまた、RFC 2746 [RSVP-TUN]のコンセプト「トンネル経由RSVP」に基づいています。これは、次の方法でその仕様と異なります。
- This document describes operation over MPLS tunnels, whereas RFC 2746 describes operation with IP tunnels. One consequence of this difference is the need to deal with penultimate hop popping (PHP).
- RFC 2746は、IPトンネルでの動作を説明するのに対し、この文書では、MPLSトンネルを介した操作を説明します。この違いの1つの結果は最後から二番目のホップのポッピング（PHP）に対処する必要があります。
- MPLS-TE tunnels inherently reserve resources, whereas the tunnels in RFC 2746 do not have resource reservations by default. This leads to some simplifications in the current document.
- RFC 2746でのトンネルがデフォルトでリソース予約を持っていないのに対し、MPLS-TEトンネルは、本質的に、リソースを予約します。これは、現在のドキュメント内のいくつかの簡略化につながります。
- This document builds on the fact that there is exactly one aggregate reservation per MPLS-TE tunnel, whereas RFC 2746 permits a model where one reservation is established on the tunnel path for each end-to-end flow.
- この文書は、RFC 2746一の予約が各エンド・ツー・エンドのフローのためのトンネル経路上に確立されたモデルを可能にする一方、MPLS-TEトンネルごとに正確に1つの集約の予約があるという事実に基づいています。
- We have assumed in the current document that a given MPLS-TE tunnel will carry reserved traffic and nothing but reserved traffic, which negates the requirement of RFC 2746 to distinguish reserved and non-reserved traffic traversing the same tunnel by using distinct encapsulations.
- 我々は、所与のMPLS-TEトンネルが予約トラフィックと異なるカプセル化を使用して、同じトンネルを横断予約と非予約トラフィックを区別するためにRFC 2746の要件を否定予約トラフィックだけを伝送する現在のドキュメントで想定しています。
- There may be several MPLS-TE tunnels that share common Head-end and Tail-end routers, with the Head-end policy determining which tunnel is appropriate for a particular flow. This scenario does not appear to be addressed in RFC 2746.
- 特定のフローのために適切であるトンネル決定ヘッドエンドポリシーと、共通のヘッドエンドとテールエンドルータを共有する複数のMPLS-TEトンネルがあってもよいです。このシナリオは、RFC 2746で対処するためには表示されません。
At the same time, this document does have many similarities with RFC 2746. MPLS-TE tunnels are "type 2 tunnels" in the nomenclature of RFC 2746:
同時に、この文書はRFC MPLS-TEトンネルは、RFC 2746の命名法における「タイプ2のトンネル」です2746.と多くの類似点を持っています：
"The (logical) link may be able to promise that some overall level of resources is available to carry traffic, but not to allocate resources specifically to individual data flows".
「（論理）リンクは、リソースの一部全体のレベルがトラフィックを運ぶために利用可能であることを約束することであってもよいが、具体的には、個々のデータフローにリソースを割り当てることではありません」。
Aggregation of end-to-end RSVP reservations over TE tunnels combines the benefits of [RSVP-AGG] and [RSVP-GEN-AGG] with the benefits of MPLS, including the following:
TEトンネル上のエンドツーエンドのRSVP予約の集合[RSVP-AGG]の利点を組み合わせて、以下を含むMPLSの利点を有する[RSVP-GEN-AGG]：
- Applications can benefit from dynamic, topology-aware, resource-based admission control over any segment of the end-to-end path, including the core.
- アプリケーションは、コアを含む、エンドツーエンドパスの任意のセグメントにわたって動的、トポロジ対応、リソースベースのアドミッション制御から利益を得ることができます。
- As per regular RSVP behavior, RSVP does not impose any burden on routers where such admission control is not needed (for example, if the links upstream and downstream of the MPLS TE core are vastly over-engineered compared to the core capacity, admission control is not required on these over-engineered links and RSVP need not be processed on the corresponding router hops).
- 定期的なRSVPの動作に従って、RSVPは、上流とMPLS TEコアの下流リンクはコア容量、アドミッションコントロールと比較して過剰操作大幅にある場合、そのようなアドミッション制御は、例えば、（必要とされないルータ上の任意の負担を課しませんこれらのオーバーエンジニアリングリンクおよびRSVPには必要ありません）対応ルータのホップで処理する必要はありません。
- The core scalability is not affected (relative to the traditional MPLS TE deployment model) since the core remains unaware of end-to-end RSVP reservations and only has to maintain aggregate TE tunnels since the datapath classification and scheduling in the core relies purely on the Diffserv mechanism (or more precisely the MPLS Diffserv mechanisms, as specified in [DIFF-MPLS]).
- コアは、エンドツーエンドのRSVPの予約を知らないままであり、コアのみにデータパス分類及びスケジューリングは純粋に依存するので、総計TEトンネルを維持しなければならないので、コアのスケーラビリティは、（従来のMPLS TE配置モデルと比較して）影響されません（[DIFF-MPLS]で指定されるように、またはより正確にMPLSのDiffserv機構）Diffservの機構。
- The aggregate reservation (and thus the traffic from the corresponding end to end reservations) can be network engineered via the use of Constraint based routing (e.g., affinity, optimization on different metrics) and when needed can take advantage of resources on other paths than the shortest path.
- 凝集予約（したがって、予約を終了するための対応する端部からのトラフィック）がネットワーク制約ベースのルーティング（例えば、親和性、異なるメトリックに最適化）の使用を介して操作され、必要なときにすることができること以外のパス上のリソースを活用することができ最短パス。
- The aggregate reservations (and thus the traffic from the corresponding end-to-end reservations) can be protected against failure through the use of MPLS Fast Reroute.
- 凝集予約（したがって対応するエンドツーエンドの予約からのトラフィック）がMPLS高速リルートを使用することによって障害から保護することができます。
This document, like [RSVP-AGG] and [RSVP-GEN-AGG], covers aggregation of unicast sessions. Aggregation of multicast sessions is for further study.
この文書は、[RSVP-AGG]および[RSVP-GEN-AGG]のように、ユニキャストセッションの集合をカバーします。マルチキャストセッションの集約は、今後の検討課題です。
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 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
For readability, a number of definitions from [RSVP-AGG] as well as definitions for commonly used MPLS TE terms are provided here:
読みやすくするために、一般的に使用されるMPLS TEの用語の[RSVP-AGG]の定義と同様の定義の数は、ここで提供されます。
Aggregator This is the process in (or associated with) the router at the ingress edge of the aggregation region (with respect to the end-to-end RSVP reservation) and behaving in accordance with [RSVP-AGG]. In this document, it is also the TE tunnel Head-end.
アグリゲータこれは、（エンドツーエンドRSVP予約に関して）の処理（又は関連する）凝集領域の入口エッジルータであり、[RSVP-AGG]に従って振る舞います。この文書では、それはまた、TEトンネルヘッドエンドです。
Deaggregator This is the process in (or associated with) the router at the egress edge of the aggregation region (with respect to the end-to-end RSVP reservation) and behaving in accordance with [RSVP-AGG]. In this document, it is also the TE tunnel Tail-end
デアグリゲーターこれは、（エンドツーエンドRSVP予約に関して）の処理（又は関連する）凝集領域の出口エッジルータであり、[RSVP-AGG]に従って振る舞います。この文書では、それはまた、TEトンネルテールエンドです
E2E End to end
E2Eは、エンドツーエンド
E2E Reservation This is an RSVP reservation such that:
このE2E予約は、RSVP予約は、次のとおりです。
(i) corresponding Path messages are initiated
upstream of the Aggregator and terminated
downstream of the Deaggregator, and
(ii) corresponding Resv messages are initiated downstream of the Deaggregator and terminated upstream of the Aggregator, and
（ii）は、対応するRESVメッセージは、デアグリゲーターの下流に開始し、アグリゲータの上流側終端され、そして
(iii) this RSVP reservation is aggregated over an MPLS TE tunnel between the Aggregator and Deaggregator.
（III）このRSVP予約がアグリゲータとデアグリゲーター間のMPLS TEトンネルを介して集約されます。
An E2E RSVP reservation may be a per-flow reservation. Alternatively, the E2E reservation may itself be an aggregate reservation of various types (e.g., Aggregate IP reservation, Aggregate IPsec reservation). See Section 5 and 6 for more details on the types of E2E RSVP reservations. As per regular RSVP operations, E2E RSVP reservations are unidirectional.
E2EのRSVP予約は、フローごとの予約も可能。あるいは、E2E予約自体は、様々なタイプ（例えば、集約IP予約、集約のIPsec予約）の集合予約であってもよいです。 E2EのRSVP予約の種類の詳細については、セクション5および6を参照してください。通常のRSVP操作に従って、E2EのRSVP予約は単方向です。
Head-end This is the Label Switch Router responsible for establishing, maintaining, and tearing down a given TE tunnel.
このヘッドエンドは、確立、維持、および特定のTEトンネルを切断する責任ラベルスイッチルータです。
Tail-end This is the Label Switch Router responsible for terminating a given TE tunnel.
このテールエンドは、与えられたTEトンネルを終端する責任ラベルスイッチルータです。
Transit LSR This is a Label Switch Router that is on the path of a given TE tunnel and is neither the Head-end nor the Tail-end.
トランジットLSRこれは、与えられたTEトンネルのパス上にあり、ヘッドエンドでもテールエンドでもないラベルスイッチルータです。
[RSVP-AGG] and [RSVP-GEN-AGG] support operations both in the case where aggregate RSVP reservations are pre-established and where Aggregators and Deaggregators have to dynamically discover each other and dynamically establish the necessary aggregate RSVP reservations.
[RSVP-AGG]および[RSVP-GEN-AGG]サポート業務の両方集約RSVP予約が予め確立された場合のアグリゲータおよびデアグリゲータが互いを動的に検出し、動的に必要な集約RSVP予約を確立する必要があります。
Similarly, RSVP Aggregation over TE tunnels could operate both in the case where the TE tunnels are pre-established and where the tunnels need to be dynamically established.
同様に、TEトンネル上のRSVP集約は、両方のTEトンネルを事前に確立されたトンネルを動的に確立する必要がある場合にされている場合に動作することができます。
In this document we provide a detailed description of the procedures in the case where TE tunnels are already established. These procedures are based on those defined in [LSP-HIER]. The routing aspects discussed in Section 3 of [LSP-HIER] are not relevant here because those aim at allowing the constraint based routing of end-to-end TE LSPs to take into account the (aggregate) TE tunnels. In the present document, the end-to-end RSVP reservations to be aggregated over the TE tunnels rely on regular SPF routing. However, as already mentioned in [LSP-HIER], we note that a TE tunnel may be advertised into IS-IS or OSPF, to be used in normal SPF by nodes upstream of the Aggregator. This would affect SPF routing and thus routing of end-to-end RSVP reservations. The control of aggregation boundaries discussed in Section 6 of [LSP-HIER] is also not relevant here. This uses information exchanged in GMPLS protocols to dynamically discover the aggregation boundary. In this document, TE tunnels are pre-established, so that the aggregation boundary can be easily inferred. The signaling aspects discussed in Section 6.2 of
この文書では、TEトンネルがすでに確立されている場合の手順の詳細な説明を提供します。これらの手順は、[LSP-HIER]で定義されたものに基づいています。 [LSP-HIER]のセクション3で説明したルーティングの態様は、これらは、エンドツーエンドTE LSPの制約に基づくルーティングを考慮に（集約）TEトンネルを取ることを可能にすることを目指しているためここでは関係ありません。本文書では、エンドツーエンドのRSVPの予約は、通常のSPFルーティングに依存しているTEトンネル上に集約されます。既に[LSP-HIER]で述べたようしかし、我々は、TEトンネルは、アグリゲータの上流のノードによって正常なSPFで使用するIS-ISまたはOSPFにアドバタイズされてもよいことに留意されたいです。これは、SPFルーティングとエンドツーエンドのRSVP予約のため、ルーティングに影響を与えます。 [LSP-HIER]のセクション6で説明した凝集境界の制御は、ここでも関係ありません。これは、動的に集約境界を発見するGMPLSプロトコルで交換される情報を使用しています。凝集境界を容易に推測することができるように、この文書では、TEトンネルは、事前に確立されています。セクション6.2で議論シグナリング側面
[LSP-HIER] apply to the establishment/termination of the aggregate TE tunnels when this is triggered by GMPLS mechanisms (e.g., as a result of an end-to-end TE LSP establishment request received at the aggregation boundary). As this document assumes pre-established tunnels, those aspects are not relevant here. The signaling aspects discussed in Section 6.1 of [LSP-HIER] relate to the establishment/maintenance of the end-to-end TE LSPs over the aggregate TE tunnel. This document describes how to use the same procedures as those specified in Section 6.1 of [LSP-HIER], but for the establishment of end-to-end RSVP reservations (instead of end-to-end TE LSPs) over the TE tunnels. This is covered further in Section 4 of the present document.
これはGMPLSメカニズムによってトリガーされたとき[LSP-HIERは、（例えば、凝集境界で受信し、エンドツーエンドのTE LSP確立要求の結果として、）集約TEトンネルの確立/終了に適用されます。この文書は、事前に確立されたトンネルを想定しているように、これらの側面は、ここでは関係ありません。 [LSP-HIER]のセクション6.1で説明したシグナルの態様は、骨材TEトンネル経由でエンドツーエンドのTE LSPの確立/維持に関連します。この文書では、TEトンネル上[LSP-HIER]のセクション6.1で指定されたものと同じ手順を使用する方法について説明したが、エンドツーエンドのRSVP予約の確立のために（代わりに、エンドツーエンドTE LSPの）。これは、本文書のセクション4でさらに覆われています。
Pre-establishment of the TE tunnels may be triggered by any mechanisms including; for example, manual configuration or automatic establishment of a TE tunnel mesh through dynamic discovery of TE Mesh membership as allowed in [AUTOMESH].
TEトンネルの事前確立を含む任意のメカニズムによってトリガされてもよいです。 【AUTOMESH]で許可されたように、例えば、TEトンネルの手動設定または自動確立は、TEメッシュメンバーシップの動的な発見を介してメッシュ。
Procedures in the case of dynamically established TE tunnels are for further studies.
動的に確立TEトンネルの場合の手順は、さらなる研究のためのものです。
|----| |----|
H--| R |\ |-----| |------| /| R |--H
H--| |\\| | |---| | |//| |--H
|----| \| He/ | | T | | Te/ |/ |----|
| Agg |=======================| Deag |
/| | | | | |\
H--------//| | |---| | |\\--------H
H--------/ |-----| |------| \--------H
H = Host requesting end-to-end RSVP reservations R = RSVP router He/Agg = TE tunnel Head-end/Aggregator Te/Deag = TE tunnel Tail-end/Deaggregator T = Transit LSR
H =ホスト要求するエンドツーエンドのRSVP予約R = RSVPルータ彼/ AGG = TEトンネルヘッドエンド/アグリゲータTE / Deag = TEトンネルテールエンド/デアグリゲーターT =トランジットLSR
-- = E2E RSVP reservation == = TE tunnel
- = E2EのRSVP予約== = TEトンネル
The first event is the arrival of the E2E Path message at the Aggregator. The Aggregator MUST follow traditional RSVP procedures for the processing of this E2E path message augmented with the extensions documented in this section.
最初のイベントは、アグリゲータでE2E Pathメッセージの到着です。アグリゲータは、このセクションに記載の拡張で拡張このE2E経路メッセージを処理するための伝統的なRSVPの手順に従わなければなりません。
The Aggregator MUST first attempt to map the E2E reservation onto a TE tunnel. This decision is made in accordance with routing information as well as any local policy information that may be available at the Aggregator. Examples of such policies appear in the following paragraphs. Just for illustration purposes, among many other criteria, such mapping policies might take into account the Intserv service type, the Application Identity [RSVP-APPID], and/or the signaled preemption [RSVP-PREEMP] of the E2E reservation (for example, the aggregator may take into account the E2E reservations RSVP preemption priority and the MPLS TE tunnel setup and/or hold priorities when mapping the E2E reservation onto an MPLS TE tunnel).
アグリゲータは、第1のTEトンネルにE2E予約をマッピングしようとしなければなりません。この決定は、ルーティング情報、ならびにアグリゲータで利用可能である任意のローカルポリシー情報に基づいて行われます。そのような政策の例としては、以下の段落に表示されます。ただ、説明のために、多くの他の基準の中で、このようなマッピングポリシーは、アカウントに例えばイントサーブサービスタイプ、アプリケーションID [RSVP-APPID]、および/またはE2E予約の合図プリエンプション[RSVP-PREEMPを]（かかる場合がありますアグリゲータ）を考慮に予約先取り優先順位をRSVP E2EとMPLS TEトンネルの設定を取り、及び/又はMPLS TEトンネル上E2E予約をマッピングする際の優先度を保持することができます。
There are situations where the Aggregator is able to make a final mapping decision. That would be the case, for example, if there is a single TE tunnel toward the destination and if the policy is to map any E2E RSVP reservation onto TE tunnels.
アグリゲータは、最終的なマッピング決定を行うことが可能である状況があります。先に向かって、ポリシーは、TEトンネルに任意E2EのRSVP予約をマッピングする場合、単一のTEトンネルが存在する場合には、例えば、場合です。
There are situations where the Aggregator is not able to make a final determination. That would be the case, for example, if routing identifies two DS-TE tunnels toward the destination, one belonging to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel and Intserv Controlled Load reservations to a Class-Type 0 tunnel, and if the E2E RSVP Path message advertises both Guaranteed Service and Controlled Load.
アグリゲータは、最終的な決意を作ることができない状況があります。ルーティングは、DS-TEクラスタイプ1およびクラスタイプ0の1つに属するものを宛先に向けて2つのDS-TEトンネルを識別する場合、ポリシーはへのIntServ保証サービスの予約をマッピングすることである場合には、例えば、場合でありますクラスタイプ1トンネルとのIntServクラスタイプ0トンネルにロード予約を制御し、E2EのRSVP Pathメッセージは、保証されたサービスと制御負荷の両方をアドバタイズしている場合。
Whether final or tentative, the Aggregator makes a mapping decision and selects a TE tunnel. Before forwarding the E2E Path message toward the receiver, the Aggregator SHOULD update the ADSPEC inside the E2E Path message to reflect the impact of the MPLS TE cloud onto the QoS achievable by the E2E flow. This update is a local matter and may be based on configured information, on the information available in the MPLS TE topology database, on the current TE tunnel path, on information collected via RSVP-TE signaling, or a combination thereof. Updating the ADSPEC allows receivers that take into account the information collected in the ADSPEC within the network (such as delay and bandwidth estimates) to make more informed reservation decisions.
最終的な又は仮のかどうか、アグリゲータは、マッピングの決定を行い、TEトンネルを選択します。受信機に向かってE2E Pathメッセージを転送する前に、アグリゲータは、E2Eフローによって達成可能なQoSへのMPLS TE雲の影響を反映するために、E2E Pathメッセージ内のADSPECを更新する必要があります。この更新は、ローカルの問題であると設定された情報に、MPLS TEトポロジデータベースにおいて入手可能な情報に、現在のTEトンネル経路上の、RSVP-TEシグナリングを介して収集された情報、またはそれらの組み合わせに基づくことができます。 ADSPECを更新する（このような遅延と帯域幅の推定値など）のアカウントにネットワーク内のADSPECで収集した情報を取る受信機は、より多くの情報の予約の決定を行うことができます。
The Aggregator MUST then forward the E2E Path message to the Deaggregator (which is the Tail-end of the selected TE tunnel). In accordance with [LSP-HIER], the Aggregator MUST send the E2E Path message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object. The data interface identification MUST identify the TE tunnel.
アグリゲータは、次に、（選択されたTEトンネルのテールエンドです）デアグリゲーターへE2E Pathメッセージを転送しなければなりません。 [LSP-HIER]によれば、アグリゲータは、代わりRSVP_HOPオブジェクトのIF_ID RSVP_HOPオブジェクトとE2E Pathメッセージを送らなければなりません。データインタフェース識別はTEトンネルを識別しなければなりません。
To send the E2E Path message, the Aggregator MUST address it directly to the Deaggregator by setting the destination address in the IP Header of the E2E Path message to the Deaggregator address. The Router Alert is not set in the E2E Path message.
E2E Pathメッセージを送信するには、アグリゲータは、デアグリゲータアドレスにE2E PathメッセージのIPヘッダの宛先アドレスを設定することにより、アグリゲーターに直接対処する必要があります。ルータアラートは、E2E Pathメッセージに設定されていません。
Optionally, the Aggregator MAY also encapsulate the E2E Path message in an IP tunnel or in the TE tunnel itself.
必要に応じて、アグリゲータは、IPトンネルまたはTEトンネル自体におけるE2E Pathメッセージをカプセル化することができます。
Regardless of the encapsulation method, the Router Alert is not set. Thus, the E2E Path message will not be visible to routers along the path from the Aggregator to the Deaggregator. Therefore, in contrast to the procedures of [RSVP-AGG] and [RSVP-GEN-AGG], the IP Protocol number does not need to be modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating "RSVP") by the Aggregator.
かかわらず、カプセル化方式の、ルータアラートが設定されていません。したがって、E2E Pathメッセージはデアグリゲーターへアグリゲータからの経路に沿ってルータに表示されません。したがって、[RSVP-AGG]の手順および[RSVP-GEN-AGG]とは対照的に、IPプロトコル番号が「RSVP-E2E-無視」に変更する必要がありません。アグリゲータによって（「RSVP」を示す）であるとして残さなければなりません。
In some environments, the Aggregator and Deaggregator MAY also act as IPsec Security Gateways in order to provide IPsec protection to E2E traffic when it transits between the Aggregator and the Deaggregator. In that case, to transmit the E2E Path message to the Deaggregator, the Aggregator MUST send the E2E Path message into the relevant IPsec tunnel terminating on the Deaggregator.
一部の環境では、アグリゲータとデアグリゲータはまた、アグリゲータとデアグリゲータの間で遷移する際E2EトラフィックにIPsec保護を提供するために、IPsecのセキュリティ・ゲートウェイとして機能することができます。その場合には、デアグリゲーターへE2E Pathメッセージを送信するために、アグリゲータはデアグリゲーターに関連するIPsecトンネルの終端にE2E Pathメッセージを送らなければなりません。
E2E PathTear and ResvConf messages MUST be forwarded by the Aggregator to the Deaggregator exactly like Path messages.
E2E PathTearとResvConfメッセージは正確にパスのメッセージのようなデアグリゲータにアグリゲータによって転送されなければなりません。
Since the E2E Path message is addressed directly to the Deaggregator and does not have Router Alert set, it is hidden from all transit LSRs.
E2E Pathメッセージがデアグリゲータに直接アドレス指定されているとルータアラートが設定されていませんので、それがすべてのトランジットのLSRから隠されています。
Upon receipt of the E2E Path message addressed to it, the Deaggregator will notice that the IP Protocol number is set to "RSVP" and will thus perform RSVP processing of the E2E Path message.
E2E Pathメッセージの受信は、それ宛の際、デアグリゲーターは、IPプロトコル番号が「RSVP」に設定されているので、E2E PathメッセージのRSVP処理を実行することに気づくであろう。
As with [LSP-HIER], the IP TTL vs. RSVP TTL check MUST NOT be made. The Deaggregator is informed that this check is not to be made because of the presence of the IF_ID RSVP HOP object.
[LSP-HIER]と同様に、RSVPのTTLチェック対IP TTLが行われてはなりません。デアグリゲータは、このチェックが原因IF_ID RSVP HOPの物体の存在で作られるべきでないことを知らされます。
The Deaggregator MAY support the option to perform the following checks (defined in [LSP-HIER]) by the receiver Y of the IF_ID RSVP_HOP object:
デアグリゲーターはIF_ID RSVP_HOPオブジェクトの受信機Yによって（[LSP-HIER]で定義された）次のチェックを実行するためのオプションをサポートすることがあります。
1. Make sure that the data interface identified in the IF_ID RSVP_HOP object actually terminates on Y.
1. IF_ID RSVP_HOPオブジェクトで識別されるデータ・インタフェースは、実際にY.に終了していることを確認してください
2. Find the "other end" of the above data interface, i.e., X. Make sure that the PHOP in the IF_ID RSVP_HOP object is a control channel address that belongs to the same node as X.
2.上記データインタフェースの「他端」を検索、すなわち、X. IF_ID RSVP_HOPオブジェクト内のPHOPがXと同じノードに属する制御チャネルアドレスであることを確認してください
The information necessary to perform these checks may not always be available to the Deaggregator. Hence, the Deaggregator MUST support operations in such environments where the checks cannot be made.
これらのチェックを実行するために必要な情報が常にデアグリゲータに利用できない場合があります。したがって、デアグリゲーターは、チェックを行うことができないような環境での動作をサポートしなければなりません。
The Deaggregator MUST forward the E2E Path downstream toward the receiver. In doing so, the Deaggregator sets the destination address in the IP header of the E2E Path message to the IP address found in the destination address field of the Session object. The Deaggregator also sets the Router Alert.
デアグリゲータは、受信機に向かって下流E2Eパスを転送する必要があります。そうすることで、デアグリゲーターは、セッションオブジェクトの宛先アドレスフィールドに見つかったIPアドレスにE2E PathメッセージのIPヘッダ内の宛先アドレスを設定します。デアグリゲータはまた、ルータアラートを設定します。
An E2E PathErr sent by the Deaggregator in response to the E2E Path message (which contains an IF_ID RSVP_HOP object) SHOULD contain an IF_ID RSVP_HOP object.
（IF_ID RSVP_HOPオブジェクトを含む）E2E Pathメッセージに応答して、デアグリゲーターによって送信されたE2EとのPathErrはIF_ID RSVP_HOPオブジェクトを含むべきです。
As per regular RSVP operations, after receipt of the E2E Path, the receiver generates an E2E Resv message which travels upstream hop-by-hop towards the sender.
定期的なRSVPの操作に従って、E2E経路の受信後、受信側は送信側に向かって上流ホップバイホップを移動E2E Resvメッセージを生成します。
Upon receipt of the E2E Resv, the Deaggregator MUST follow traditional RSVP procedures on receipt of the E2E Resv message. This includes performing admission control for the segment downstream of the Deaggregator and forwarding the E2E Resv message to the PHOP signaled earlier in the E2E Path message and which identifies the Aggregator. Since the E2E Resv message is directly addressed to the Aggregator and does not carry the Router Alert option (as per traditional RSVP Resv procedures), the E2E Resv message is hidden from the routers between the Deaggregator and the Aggregator which, therefore, handle the E2E Resv message as a regular IP packet.
E2EたResvを受信すると、デアグリゲーターは、E2E Resvメッセージの受信時に、伝統的なRSVPの手順に従わなければなりません。これは、以前のE2E Pathメッセージにおけるシグナリングかつアグリゲータを識別する下流デアグリゲーターのセグメントのためのアドミッション制御を実行し、PHOPにE2E Resvメッセージの転送を含みます。 E2E Resvメッセージがアグリゲータ宛直接れ、（従来のRSVPのResv手順に従って）ルータ警告オプションを有していないので、E2E Resvメッセージは、したがって、E2Eハンドル、デアグリゲーターおよびアグリゲータ間のルータから隠されています通常のIPパケットとしてResvメッセージ。
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Deaggregator MUST send the E2E Resv message into the relevant IPsec tunnel terminating on the Aggregator.
アグリゲータとデアグリゲータはまた、IPsecのセキュリティ・ゲートウェイとして動作している場合は、デアグリゲータは、アグリゲータに関連するIPsecトンネル終端にE2E Resvメッセージを送らなければなりません。
The Aggregator is responsible for ensuring that there is sufficient bandwidth available and reserved over the appropriate TE tunnel to the Deaggregator for the E2E reservation.
アグリゲータは、十分な帯域幅が利用可能であり、E2E予約のデアグリゲーターに適切なTEトンネル上に予約があることを保証する責任があります。
On receipt of the E2E Resv message, the Aggregator MUST first perform the final mapping onto the final TE tunnel (if the previous mapping was only a tentative one).
（以前のマッピングのみ暫定的だった場合）E2E Resvメッセージを受信すると、アグリゲータは、第一最終TEトンネルに最終マッピングを実行しなければなりません。
If the tunnel did not change during the final mapping, the Aggregator continues the processing of the E2E Resv as described in the four following paragraphs.
トンネルは、最終的なマッピングの間に変化しなかった場合は次の4つの段落に記載されているように、アグリゲータは、E2EのResvの処理を継続します。
The aggregator calculates the size of the resource request using traditional RSVP procedures. That is, it follows the procedures in [RSVP] to determine the resource requirements from the Sender Tspec and the Flowspec contained in the Resv. Then it compares the resource request with the available resources of the selected TE tunnel.
アグリゲータは、伝統的なRSVPの手順を使用してリソース要求のサイズを算出します。すなわち、のResvに含まれる送信者Tspecは及びFLOWSPECからリソース要件を決定するために、[RSVP]の手順に従います。それは選択されたTEトンネルの利用可能なリソースとリソース要求とを比較します。
If sufficient bandwidth is available on the final TE tunnel, the Aggregator MUST update its internal understanding of how much of the TE tunnel is in use and MUST forward the E2E Resv messages to the corresponding PHOP.
十分な帯域幅が最終的なTEトンネルで利用可能な場合は、アグリゲータは使用中で、対応するPHOPにE2E RESVメッセージを転送しなければなりませんどのくらいのTEトンネルの、その内部の理解を更新する必要があります。
As noted in [RSVP-AGG], a range of policies MAY be applied to the re-sizing of the aggregate reservation (in this case, the TE tunnel). For example, the policy may be that the reserved bandwidth of the tunnel can only be changed by configuration. More dynamic policies are also possible, whereby the aggregator may attempt to increase the reserved bandwidth of the tunnel in response to the amount of allocated bandwidth that has been used by E2E reservations. Furthermore, to avoid the delay associated with the increase of the tunnel size, the Aggregator may attempt to anticipate the increases in demand and adjust the TE tunnel size ahead of actual needs by E2E reservations. In order to reduce disruptions, the Aggregator SHOULD use "make-before-break" procedures as described in [RSVP-TE] to alter the TE tunnel bandwidth.
[RSVP-AGG]で述べたように、ポリシーの範囲は、集合予約の再サイズ（この場合、TEトンネル）に適用してもよいです。たとえば、ポリシーは、トンネルの予約された帯域幅のみ設定によって変更することができることとすることができます。アグリゲータは、E2Eの予約で使用された割り当てられた帯域幅の量に応じて、トンネルの予約帯域幅を増加させることを試みることができることにより、より動的なポリシーが、また可能です。さらに、トンネルのサイズの増加に伴う遅延を回避するために、アグリゲータは、需要の増加を予測し、E2Eの予約によって先に実際のニーズのTEトンネルのサイズを調整することを試みることができます。 [RSVP-TE]で説明されるように混乱を低減するために、アグリゲータは、TEトンネル帯域幅を変更するために「メークビフォアブレーク」手順を使用すべきです。
If sufficient bandwidth is not available on the final TE tunnel, the Aggregator MUST follow the normal RSVP procedure for a reservation being placed with insufficient bandwidth to support it. That is, the reservation is not installed and a ResvError is sent back toward the receiver.
十分な帯域幅が、最終的なTEトンネル上で利用できない場合、アグリゲータはそれをサポートするのに十分な帯域幅で配置されている予約のための通常のRSVPの手順に従わなければなりません。すなわち、予約がインストールされていないとResvErrorバック受信機に向かって送信されます。
If the tunnel did change during the final mapping, the Aggregator MUST first resend to the Deaggregator an E2E Path message with the IF_ID RSVP_HOP data interface identification identifying the final TE tunnel. If needed, the ADSPEC information in this E2E Path message SHOULD be updated. Then the Aggregator MUST
トンネルは、最終的なマッピングの間に変化しなかった場合、アグリゲータは、まずデアグリゲーターへの最終的なTEトンネルを識別するIF_ID RSVP_HOPデータインタフェース識別とE2E Pathメッセージを再送しなければなりません。必要であれば、このE2E PathメッセージでADSPEC情報を更新する必要があります。そして、アグリゲータMUST
- either drop the E2E Resv message
- どちらかE2E Resvメッセージをドロップ
- or proceed with the processing of the E2E Resv in the same manner as in the case where the tunnel did not change (described above).
- 又はトンネルが変化しなかった場合（上記）と同様に、E2EのResvの処理を進めます。
In the former case, admission control over the final TE tunnel (and forwarding of E2E Resv message upstream toward the sender) would only occur when the Aggregator received the subsequent E2E Resv message (that will be sent by the Deaggregator in response to the resent E2E Path). In the latter case, admission control over the final tunnel is carried out immediately by the Aggregator, and if successful the E2E Resv message is generated upstream toward the sender.
前者の場合、入場最終TEトンネルの制御（および上流の送信者に向かってE2E Resvメッセージの転送）に集約（つまり再送E2Eに応答してデアグリゲーターによって送信される後続のE2E Resvメッセージを受信した場合にのみ発生します道）。後者の場合には、最終的なトンネルを介して受付制御を集約することにより直ちに行われ、成功した場合E2E Resvメッセージは、送信側に向かって上流に生成されます。
Upon receipt of an E2E ResvConf from the Aggregator, the Deaggregator MUST forward the E2E ResvConf downstream toward the receiver. In doing so, the Deaggregator sets the destination address in the IP header of the E2E ResvConf message to the IP address found in the RESV_CONFIRM object of the corresponding Resv. The Deaggregator also sets the Router Alert.
アグリゲータからE2E ResvConfを受信すると、デアグリゲーターは、受信機に向かって下流E2E ResvConfを転送しなければなりません。そうすることで、デアグリゲーターは、対応のResvのRESV_CONFIRMオブジェクトで見つかったIPアドレスにE2E ResvConfメッセージのIPヘッダ内の宛先アドレスを設定します。デアグリゲータはまた、ルータアラートを設定します。
When the Aggregator receives a data packet belonging to an E2E reservations currently mapped over a given TE tunnel, the Aggregator MUST encapsulate the packet into that TE tunnel.
アグリゲータは、現在与えられたTEトンネル上にマッピングされたE2Eの予約に属するデータパケットを受信すると、アグリゲータは、TEトンネルにパケットをカプセル化しなければなりません。
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Aggregator MUST also encapsulate the data packet into the relevant IPsec tunnel terminating on the Deaggregator before transmission into the MPLS TE tunnel.
アグリゲータとデアグリゲータはまた、IPsecのセキュリティ・ゲートウェイとして動作している場合は、アグリゲータはまた、MPLS TEトンネルに送信される前にデアグリゲータで終端関連するIPsecトンネルにデータパケットをカプセル化しなければなりません。
E2E reservations are removed in the usual way via PathTear, ResvTear, timeout, or as the result of an error condition. When a reservation is removed, the Aggregator MUST update its local view of the resources available on the corresponding TE tunnel accordingly.
E2E予約がPathTearを介して通常の方法で除去され、たResvTear、タイムアウト、またはエラー状態の結果として。予約が除去されると、アグリゲータは、それに応じて、対応するTEトンネル上で利用可能なリソースのローカルビューを更新する必要があります。
Should a TE tunnel go away (presumably due to a configuration change, route change, or policy event), the Aggregator behaves much like a conventional RSVP router in the face of a link failure. That is, it may try to forward the Path messages onto another tunnel, if routing and policy permit, or it may send Path_Error messages to the sender if a suitable tunnel does not exist. In case the Path messages are forwarded onto another tunnel, which terminates on a different Deaggregator, or the reservation is torn down via Path Error messages, the reservation state established on the router acting as the Deaggregator before the TE tunnel went away, will time out since it will no longer be refreshed.
TEトンネルが（おそらく設定変更、ルート変更、またはポリシーイベントに）離れて行く必要があり、アグリゲータは、多くのリンク障害に直面して、従来のRSVPルータのように動作します。つまり、それは、ルーティングおよびポリシーの許可場合は、別のトンネルにPathメッセージを転送しようとすること、または適切なトンネルが存在しない場合には、送信者にPath_Errorメッセージを送信することができます。場合にはPathメッセージが異なるデアグリゲータに終了し、別のトンネル上に転送され、または予約がパスのエラー・メッセージを介して取り壊されるTEトンネルが離れて行く前に、予約状態がデアグリゲータとして動作するルータに設立され、タイムアウトしますそれはもはやリフレッシュされないからです。
Aggregator Deaggregator
アグリゲータデアグリゲータ
(*)
RSVP-TE Path
=========================>
RSVP-TE Resv
<=========================
(**)
E2E Path
-------------->
(1)
E2E Path
------------------------------->
(2)
E2E Path
----------->
E2E Resv
<-----------
(3)
E2E Resv
<-----------------------------
(4)
E2E Resv
<-------------
(*) Aggregator is triggered to pre-establish the TE tunnel(s)
（*）集約は、TEトンネルを事前に確立するためにトリガされる（S）
(**) TE tunnel(s) are pre-established
（**）TEトンネル（S）予め確立されています
(1) Aggregator tentatively selects the TE tunnel and forwards E2E path to Deaggregator
（1）集約は、仮デアグリゲーターにTEトンネルおよび転送E2E経路を選択します
(2) Deaggregator forwards the E2E Path toward the receiver
（2）デアグリゲーターは、受信機に向かってE2Eパスを転送します
(3) Deaggregator forwards the E2E Resv to the Aggregator
（3）デアグリゲーターは、アグリゲータにE2EたResvを転送します
(4) Aggregator selects final TE tunnel, checks that there is sufficient bandwidth on TE tunnel, and forwards E2E Resv to PHOP. If final tunnel is different from tunnel tentatively selected, the Aggregator re-sends an E2E Path with an updated IF_ID RSVP_HOP and possibly an updated ADSPEC.
（4）アグリゲータは、最終的なTEトンネルを選択TEトンネルに十分な帯域幅があることを確認し、PHOPに転送E2EのResv。最終的なトンネルが暫定的に選択したトンネルと異なる場合、アグリゲータ更新IF_ID RSVP_HOP、おそらく更新ADSPECとE2Eパスを再送信します。
The procedures defined in this document are applicable to all the following cases:
この文書で定義された手順は、以下のすべての例に適用されます。
(1) Aggregation of E2E IPv4 RSVP reservations over IPv4 TE tunnels.
IPv4のTEトンネル上E2EのIPv4 RSVP予約（1）集約。
(2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE tunnels.
IPv6のTEトンネル上E2EのIPv6 RSVP予約（2）集約。
(3) Aggregation of E2E IPv6 RSVP reservations over IPv4 TE tunnels, provided a mechanism such as [6PE] is used by the Aggregator and Deaggregator for routing of IPv6 traffic over an IPv4 MPLS core.
（3）IPv4のTEトンネル上E2EのIPv6 RSVPの予約の凝集は、[6PE]のIPv4 MPLSコア上のIPv6トラフィックのルーティングのためのアグリゲータとデアグリゲーターで使用されるような仕組みを提供しました。
(4) Aggregation of E2E IPv4 RSVP reservations over IPv6 TE tunnels, provided a mechanism is used by the Aggregator and Deaggregator for routing IPv4 traffic over IPv6 MPLS.
（4）IPv6のTEトンネル上E2EのIPv4 RSVPの予約の凝集は、IPv6のMPLS上のIPv4トラフィックをルーティングするためのアグリゲータとデアグリゲーターによって使用されるメカニズムを提供しました。
The procedures defined in this document are applicable to many types of E2E RSVP reservations including the following cases:
この文書で定義された手順は、以下の場合を含むE2EのRSVPの予約には多くの種類に適用されます。
(1) The E2E RSVP reservation is a per-flow reservation where the flow is characterized by the usual 5-tuple
（1）E2EのRSVP予約は、フローは、通常の5タプルを特徴とするフロー毎の予約であります
(2) The E2E reservation is an aggregate reservation for multiple flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the set of flows is characterized by the <source address, destination address, DSCP>
（2）E2E予約は[RSVP-AGG]に記載されているように複数のフローの集約の予約であるか、またはフローの集合は、<送信元アドレス、宛先アドレス、DSCP>ことを特徴とする[RSVP-GEN-AGG]
(3) The E2E reservation is a reservation for an IPsec protected flow. For example, where the flow is characterized by the <source address, destination address, SPI> as described in [RSVP-IPSEC].
（3）E2E予約は、IPsec保護されたフローのための予約です。例えば、ここで、[RSVP-IPSEC]に記載されているように、フローは、<送信元アドレス、宛先アドレス、SPI>ことを特徴とします。
An example application of the procedures specified in this document is admission control of voice and video in environments with a very high number of hosts. In the example illustrated below, hosts generate E2E per-flow reservations for each of their video streams associated with a video-conference, each of their audio streams associated with a video-conference and each of their voice calls.
この文書で指定された手順の適用例は、ホストの非常に高い数の環境で音声およびビデオのアドミッション制御です。以下に示す例では、ホストは、音声通話のビデオ会議に関連付けられたそれらのビデオストリームの各々は、各ビデオ会議に関連付けられ、そのオーディオストリームの各々のためのE2Eフロー毎の予約を生成します。
These reservations are aggregated over MPLS DS-TE tunnels over the packet core. The mapping policy defined by the user may be that all the reservations for audio and voice streams are mapped onto DS-TE tunnels of Class-Type 1, while reservations for video streams are mapped onto DS-TE tunnels of Class-Type 0.
これらの予約はパケットコア上でMPLS DS-TEトンネルの上に集約されます。ユーザによって定義されたマッピングポリシーは、ビデオストリームのための予約がクラスタイプ0のDS-TEトンネルにマッピングされている間、オーディオおよび音声ストリームのすべての予約は、クラスタイプ1のDS-TEトンネルにマッピングされることがあってもよいです。
------ ------
| H |# ------- -------- #| H |
| |\#| | ----- | |#/| |
-----| \| Agg | | T | | Deag |/ ------
| |==========================| |
------ /| |::::::::::::::::::::::::::| |\ ------
| H |/#| | ----- | |#\| H |
| |# ------- -------- #| |
------ ------
H = Host Agg = Aggregator (TE tunnel Head-end) Deagg = Deaggregator (TE tunnel Tail-end) T = Transit LSR
H =ホストAGG =アグリゲータ（TEトンネルヘッドエンド）Deagg =デアグリゲーター（TEトンネルテールエンド）T =トランジットLSR
/ = E2E RSVP reservation for a Voice flow # = E2E RSVP reservation for a Video flow == = DS-TE tunnel from Class-Type 1 :: = DS-TE tunnel from Class-Type 0
動画の流れのための音声フロー＃= E2EのRSVP予約のための/ =のE2E RSVP予約== =クラスタイプクラスタイプ0から1 :: = DS-TEトンネルからのDS-TEトンネル
An example application of the procedures specified in this document is voice call admission control in large-scale telephony trunking environments. A Trunk VoIP Gateway may generate one aggregate RSVP reservation for all the calls in place toward another given remote Trunk VoIP Gateway (with resizing of this aggregate reservation in a step function depending on the current number of calls). In turn, these reservations may be aggregated over MPLS TE tunnels over the packet core so that tunnel Head-ends act as Aggregators and perform admission control of Trunk Gateway reservations into MPLS TE tunnels. The MPLS TE tunnels may be protected by MPLS Fast Reroute. This scenario is illustrated below:
この文書で指定された手順の応用例では、大規模なテレフォニートランキング環境における音声コールアドミッション制御です。トランクVoIPゲートウェイは、（呼の現在の数に応じてステップ関数で、この集計予約のサイズ変更で）別の特定のリモートトランクVoIPゲートウェイに向かって所定の位置にあるすべてのコールの1つの集約RSVP予約を生成することができます。トンネルヘッドエンドは、アグリゲータとして機能し、MPLS TEトンネルにトランクゲートウェイ予約の受付制御を行うように順番に、これらの予約パケットコア上のMPLS TEトンネル上に集約してもよいです。 MPLS TEトンネルがMPLS高速リルートによって保護することができます。このシナリオは、以下に説明します：
------ ------
| GW |\ ------- -------- /| GW |
| |\\| | ----- | |//| |
-----| \| Agg | | T | | Deag |/ ------
| |==========================| |
------ /| | | | | |\ ------
| GW |//| | ----- | |\\| GW |
| |/ ------- -------- \| |
------ ------
GW = VoIP Gateway Agg = Aggregator (TE tunnel Head-end) Deagg = Deaggregator (TE tunnel Tail-end) T = Transit LSR
GW = VoIPゲートウェイAGG =アグリゲータ（TEトンネルヘッドエンド）Deagg =デアグリゲーター（TEトンネルテールエンド）T =トランジットLSR
/ = Aggregate Gateway to Gateway E2E RSVP reservation == = TE tunnel
/ =集約ゲートウェイゲートウェイE2E RSVP予約== = TEトンネルへ
In the environments concerned by this document, RSVP messages are used to control resource reservations for E2E flows outside the MPLS region as well as to control resource reservations for MPLS TE tunnels inside the MPLS region. To ensure the integrity of the associated reservation and admission control mechanisms, the mechanisms defined in [RSVP-CRYPTO1] and [RSVP-CRYPTO2] can be used. The mechanisms protect the integrity of RSVP messages hop-by-hop and provide node authentication, thereby protecting against corruption and spoofing of RSVP messages. These hop-by-hop integrity mechanisms can naturally be used to protect the RSVP messages used for E2E reservations outside the MPLS region, to protect RSVP messages used for MPLS TE tunnels inside the MPLS region, or for both. These hop-by-hop RSVP integrity mechanisms can also be used to protect RSVP messages used for E2E reservations when those transit through the MPLS 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 nor RSVP-TE neighbors). In that case, the Aggregator and Deaggregator need to use a pre-shared secret.
この文書に関係環境では、RSVPメッセージは、E2EがMPLS領域外に流れるだけでなく、MPLS領域内のMPLS TEトンネルのためのリソース予約を制御するためのリソースの予約を制御するために使用されます。関連する予約および入場制御機構の完全性を保証するために、[RSVP-CRYPTO1]で定義されたメカニズムと[RSVP-CRYPTO2]は使用することができます。メカニズムは、それによって破損及びRSVPメッセージのなりすましに対する保護、ノードの認証を提供することによってホップホップとRSVPメッセージの完全性を保護します。これらのホップバイホップ完全性機構は当然MPLS領域内のMPLS TEトンネルのための、または両方のために使用されるRSVPメッセージを保護するために、MPLS領域外E2Eの予約のために使用されるRSVPメッセージを保護するために使用することができます。これらのホップバイホップRSVPの整合性メカニズムはまた、MPLS領域を介してこれらのトランジットE2Eの予約に使用RSVPメッセージを保護するために使用することができます。 （彼らは必ずしもIP隣人やRSVP-TE隣人でない場合でも）、集約およびデアグリゲータは、E2Eフローの観点から、RSVP隣人として振る舞うためです。その場合には、アグリゲータとデアグリゲータは、事前共有秘密鍵を使用する必要があります。
As discussed in Section 6 of [RSVP-TE], filtering of traffic associated with an MPLS TE tunnel can only be done on the basis of an MPLS label, instead of the 5-tuple of conventional RSVP reservation as per [RSVP]. Thus, as explained in [RSVP-TE], an administrator may wish to limit the domain over which TE tunnels (which are used for aggregation of RSVP E2E reservations as per this specification) can be established. See Section 6 of [RSVP-TE] for a description of how
[RSVP-TE]のセクション6で説明したように、MPLS TEトンネルに関連するトラフィックのフィルタリングは、MPLSラベルに基づいてのみ行うことができ、代わりに、従来のRSVP予約の5タプルの[RSVP]の通り。したがって、[RSVP-TE]で説明したように、管理者は、（本仕様に従ってRSVPのE2Eの予約の凝集のために使用される）TEトンネルを確立することができる上に、ドメインを制限することを望むかもしれません。方法については、[RSVP-TE]のセクション6を参照してください。
filtering of RSVP messages associated with MPLS TE tunnels can be deployed to that end.
MPLS TEトンネルに関連付けられているRSVPメッセージのフィルタリングは、そのために展開することができます。
This document is based in part on [RSVP-AGG], which specifies aggregation of RSVP reservations. Section 5 of [RSVP-AGG] raises the point that because many E2E flows may share an aggregate reservation, if the security of an aggregate reservation is compromised, there is a multiplying effect in the sense that it can in turn compromise the security of many E2E reservations whose quality of service depends on the aggregate reservation. This concern applies also to RSVP Aggregation over TE tunnels as specified in the present document. However, the integrity of MPLS TE tunnels operation can be protected using the mechanisms discussed in the previous paragraphs. Also, while [RSVP-AGG] specifies RSVP Aggregation over dynamically established aggregate reservations, the present document restricts itself to RSVP Aggregation over pre-established TE tunnels. This further reduces the security risks.
この文書は、RSVP予約の集合を指定する[RSVP-AGG]、に部分的に基づいています。 [RSVP-AGG]のセクション5は、多くのE2Eフローが集約予約を共有することができるので、集約予約のセキュリティが侵害されている場合、それは順番に多くのセキュリティを危険にさらすことができるという意味で乗算する効果があるという点を提起しますそのサービスの品質集計予約に依存E2Eの予約。この懸念は、現在のドキュメントに指定されているTEトンネルの上に集約RSVPにも適用されます。しかし、MPLS TEトンネルの動作の完全性は、前の段落で説明したメカニズムを用いて保護することができます。 [RSVP-AGG]が動的に確立された集約の予約上RSVP集約を指定しながら、また、本文書は、予め確立されたTEトンネル上集約RSVPに自身を制限します。これは、さらにセキュリティリスクを低減します。
In the case where the Aggregators dynamically resize the TE tunnels based on the current level of reservation, there are risks that the TE tunnels used for RSVP aggregation hog resources in the core, which could prevent other TE tunnels from being established. There are also potential risks that such resizing results in significant computation and signaling as well as churn on tunnel paths. Such risks can be mitigated by configuration options allowing control of TE tunnel dynamic resizing (maximum TE tunnel size, maximum resizing frequency, etc.), and/or possibly by the use of TE preemption.
アグリゲータは、動的に予約の現在のレベルに基づいて、TEトンネルのサイズを変更する場合には、から他のTEトンネルを防ぐことができるコアにRSVP集約豚のリソースに使用TEトンネルが確立されるリスクがあります。潜在的なリスクも存在することトンネル経路に著しい計算およびシグナル伝達ならびに解約におけるこのようなサイズ変更の結果。そのようなリスクは、および/または場合によってTEプリエンプションの使用によって、TEトンネル動的サイズ変更（最大TEトンネルサイズ、最大サイズ変更頻度、等）の制御を可能にする設定オプションによって緩和することができます。
Section 5 of [RSVP-AGG] also discusses a security issue specific to RSVP aggregation related to the necessary modification of the IP Protocol number in RSVP E2E Path messages that traverses the aggregation region. This security issue does not apply to the present document since aggregation of RSVP reservation over TE tunnels does not use this approach of changing the protocol number in RSVP messages.
[RSVP-AGG]のセクション5はまた、集約地域を横断RSVPのE2EのPathメッセージでIPプロトコル番号の必要な修正に集約関連RSVPに特有のセキュリティ問題について説明します。 TEトンネル経由RSVP予約の凝集がRSVPメッセージでプロトコル番号を変更するこのアプローチを使用していないため、このセキュリティ上の問題は存在ドキュメントには適用されません。
Section 7 of [LSP-HIER] discusses security considerations stemming from the fact that the implicit assumption of a binding between data interface and the interface over which a control message is sent is no longer valid. These security considerations are equally applicable to the present document.
[LSP-HIER]のセクション7は、データ・インターフェースおよび制御メッセージが送信されるインタフェースとの間の結合の暗黙の仮定はもはや有効であるという事実に起因するセキュリティ問題を論じています。これらのセキュリティ上の考慮事項は、現在のドキュメントにも同様に適用可能です。
If the Aggregator and Deaggregator are also acting as IPsec Security Gateways, the Security Considerations of [SEC-ARCH] apply.
アグリゲータとデアグリゲータはまた、IPsecのセキュリティ・ゲートウェイとして動作している場合は、[SEC-ARCH]のセキュリティについての考慮事項が適用されます。
This document builds on the [RSVP-AGG], [RSVP-TUN], and [LSP-HIER] specifications. We would like to thank Tom Phelan, John Drake, Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol Iturralde, and James Gibson for their input into this document.
この文書では、[RSVP-AGG]、[RSVP-TUN]、および[LSP-HIER]の仕様に基づいています。私たちは、この文書に彼らの入力のためにトム・フェラン、ジョン・ドレイク、Arthi Ayyangar、フレッド・ベイカー、サブハDhesikan、クォック・ホーちゃん、キャロルIturralde、そしてジェームズ・ギブソンに感謝したいと思います。
[CONTROLLED] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[CONTROLLED] Wroclawski、J.、RFC 2211 "制御負荷ネットワーク要素サービスの仕様"、1997年9月。
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[DIFFSERV]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[DSTE-PROTO] Le Faucheur, F., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[DSTE - プロト]ルFaucheur、F.、 "Diffservの認識MPLSトラフィックエンジニアリングのサポートのためのプロトコル拡張機能"、RFC 4124、2005年6月。
[GUARANTEED] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[保証] Shenker、S.、ヤマウズラ、C.、およびR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[INT-DIFF] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[INT-DIFF] Bernet、Y.、フォード、P.、Yavatkar、R.、ベイカー、F.、チャン、L.、シュペーア、M.、ブレーデン、R.、デイビー、B.、Wroclawski、J.、そしてE. Felstaine、「Diffservのネットワーク経由の統合サービス操作のための枠組み」、RFC 2998、2000年11月。
[INT-SERV] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[INT-SERV]ブレーデン、R.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[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月。
[LSP-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[LSP-HIER] Kompella、K.とY. Rekhterは、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[MPLS-TE] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[MPLS-TE] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
[RSVP] Braden, R., 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、1997年9月。
[RSVP-AGG] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RSVP-AGG]ベーカー、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-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月。
[SEC-ARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[SEC-ARCH]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[6PE] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
【6PE】デClercq、J.、Ooms、D.、プレボ、S.、およびF.ルFaucheur、 "IPv6のプロバイダエッジルータを用いたIPv4 MPLS上のIPv6諸島接続（6PE）"、RFC 4798、2007年2月。
[AUTOMESH] Vasseur and Leroux, "Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership", Work in Progress.
[AUTOMESH] Vasseurとルルー、「マルチプロトコル（MPLS）ラベルスイッチルータ（LSR）トラフィックエンジニアリング（TE）メッシュメンバーシップの発見のためのルーティング機能拡張」が進行中で働いています。
[DIFF-MPLS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[DIFF-MPLS]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング差別化サービスの（MPLS）サポート」、RFC 3270、2002年5月。
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.
[DSTE - REQ]ルFaucheur、F.およびW.ライ、 "差別化サービスを意識したMPLSトラフィックエンジニアリングのサポートのための要件"、RFC 3564、2003年7月。
[L-RSVP] Manner, et al., Localized RSVP for Controlling RSVP Proxies, Work in Progress.
[L-RSVP]マナーら、RSVPプロキシ、進行中の作業を制御するためのローカライズRSVP。
[RSVP-APPID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RSVP-APPID] Yadavが、S.、Yavatkar、R.、Pabbati、R.、フォード、P.、ムーア、T.、ヘルツォーク、S.、およびR.ヘス、 "RSVPのためのアイデンティティ表現"、RFC 3182、 2001年10月。
[RSVP-GEN-AGG] Le Faucheur, R., Davie, B., Bose, P., Martin, L., Christou, C., Davenport, M., and A. Hamilton, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", Work in Progress, January 2007.
[RSVP-GEN-AGG]ルFaucheur、R.、デイビー、B.、ボーズ、P.、マーティン、L.、Christouの、C.、ダベンポート、M.、およびA.ハミルトン、「汎用集計リソース予約プロトコル（ RSVP）予約」、進歩、2007年1月の作業。
[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-PREEMP] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RSVP-PREEMP]ヘルツォーク、S.、2001年10月、RFC 3181、 "先取り優先権方針要素が通知さ"。
[RSVP-PROXY1] Gai, et al., RSVP Proxy, Work in Progress.
[RSVP-PROXY1]ガイら、RSVPプロキシ、進行中で働いています。
[RSVP-PROXY2] Le Faucheur, et al., RSVP Proxy Approaches, Work in Progress.
[RSVP-PROXY2]刈り取り、ら。、RSVPプロキシアプローチ、進行中で働いています。
[RSVP-TUN] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RSVP-TUN] Terzis、A.、Krawczyk、J.、Wroclawski、J.、およびL.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
[SIP-RSVP] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[SIP-RSVP]カマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、 "リソース管理の統合およびセッション開始プロトコル（SIP）"、RFC 3312、2002年10月。
Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator
付録A - RSVPアグリゲータのRSVPプロキシのオプションを使用します
A number of approaches ([RSVP-PROXY1],[RSVP-PROXY2], [L-RSVP]) have been, or are being, discussed in the IETF in order to allow a network node to behave as an RSVP proxy which:
多数のアプローチ（[RSVP-PROXY1]、[RSVP-PROXY2]、[L-RSVP]）をされている、またはネットワークノードがどのRSVPプロキシとして動作することを可能にするために、IETFで議論、されています。
- originates the Resv Message (in response to the Path message) on behalf of the destination node
- 宛先ノードの代わりに（Pathメッセージに応答して）RESVメッセージを発信
- originates the Path message (in response to some trigger) on behalf of the source node.
- 送信元ノードの代わりに（いくつかのトリガーに応答して）、Pathメッセージを発信。
We observe that such approaches may optionally be used in conjunction with the aggregation of RSVP reservations over MPLS TE tunnels as specified in this document. In particular, we consider the case where the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy.
我々は、この文書で指定されるように、このようなアプローチは、必要に応じてMPLS TEトンネル上のRSVP予約の凝集と組み合わせて使用することができることを確認します。特に、我々はRSVPアグリゲータ/デアグリゲータはまた、RSVPプロキシとして動作する場合を考えます。
The information in this Appendix is purely informational and illustrative.
この付録の情報は、純粋に情報および例示です。
As discussed in [RSVP-PROXY1]:
[RSVP-PROXY1]で議論するように。
"The proxy functionality does not imply merely generating a single Resv message. Proxying the Resv involves installing state in the node doing the proxy i.e. the proxying node should act as if it had received a Resv from the true endpoint. This involves reserving resources (if required), sending periodic refreshes of the Resv message and tearing down the reservation if the Path is torn down."
「プロキシ機能は、単に、単一のResvメッセージを生成意味するものではありません。のResvは、それが真のエンドポイントからのResvを受信したかのように行動しなければならないプロキシノード、すなわち代理をしているノードに状態のインストールが含まプロキシ処理。これは（もし予約のリソースを必要としますResvメッセージの定期的なリフレッシュを送信し、パスが切断された場合、予約を取り壊す、）が必要。」
Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may effectively perform resource reservation over the MPLS TE tunnel (and hence over the whole segment between the RSVP Aggregator and the RSVP Deaggregator) even if the RSVP signaling only takes place upstream of the MPLS TE tunnel (i.e., between the host and the RSVP aggregator).
RSVPプロキシとして動作する場合したがって、RSVP集約を効果のみRSVPシグナリングは、MPLSの上流で行われる場合であっても（したがって、RSVP集約RSVPとデアグリゲーター間の全体のセグメントにわたって）MPLS TEトンネル経由でリソース予約を実行することができますTEトンネル（すなわち、ホストとRSVPアグリゲータ間）。
Also, the RSVP Proxy can generate the Path message on behalf of the remote source host in order to achieve reservation in the return direction (i.e., from RSVP aggregator/Deaggregator to host).
また、RSVPプロキシ（すなわち、RSVPアグリゲータ/デアグリゲータからホストへ）戻り方向に予約を達成するために、リモート・ソース・ホストに代わってPathメッセージを生成することができます。
The resulting Signaling Flow is illustrated below, covering reservations for both directions:
得られたシグナリングフローは、両方向の予約を覆う、以下に示します。
|----| |--------------| |------| |--------------| |----|
| | | Aggregator/ | | MPLS | | Aggregator/ | | |
|Host| | Deaggregator/| | cloud| | Deaggregator/| |Host|
| | | RSVP Proxy | | | | RSVP Proxy | | |
|----| |--------------| |------| |--------------| |----|
==========TE Tunnel==========>
<========= TE Tunnel==========
Path Path
------------> (1)-\ /-(i) <----------
Resv | | Resv
<------------ (2)-/ \-(ii) ------------>
Path Path
<------------ (3) (iii) ------------>
Resv Resv
------------> <------------
(1)(i) : Aggregator/Deaggregator/Proxy receives Path message, selects the TE tunnel, performs admission control over the TE tunnel. (1) and (i) happen independently of each other.
（1）（I）：アグリゲータ/デアグリゲータ/プロキシは、Pathメッセージを受信したTEトンネルを選択し、TEトンネルを介して受付制御を行います。 （1）及び（I）互いに独立して起こります。
(2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message toward Host. (2) is triggered by (1) and (ii) is triggered by (i). Before generating this Resv message, the Aggregator/Proxy performs admission control of the corresponding reservation over the TE tunnel that will eventually carry the corresponding traffic.
（2）（II）：アグリゲータ/デアグリゲータ/プロキシホストに向かってResvメッセージを生成します。 （2）（1）によってトリガされると（II）は（I）によってトリガされます。このResvメッセージを生成する前に、アグリゲータ/プロキシは、最終的に対応するトラフィックを伝送するTEトンネルを介して、対応する予約の受付制御を行います。
(3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message toward Host for reservation in return direction. The actual trigger for this depends on the actual RSVP proxy solution. As an example, (3) and (iii) may simply be triggered respectively by (1) and (i).
（3）（III）：アグリゲータ/デアグリゲータ/プロキシが戻り方向に予約するためのホストに向かってPathメッセージを生成します。このため、実際のトリガは、実際のRSVPプロキシソリューションに依存します。一例として、（3）および（iii）は、単に（1）及び（I）によってそれぞれトリガされてもよいです。
Note that the details of the signaling flow may vary slightly depending on the actual approach used for RSVP Proxy. For example, if the [L-RSVP] approach was used instead of [RSVP-PROXY1], an additional PathRequest message would be needed from host to Aggregator/Deaggregator/Proxy in order to trigger the generation of the Path message for return direction.
シグナリングフローの詳細は、RSVPプロキシに使用される実際のアプローチによって多少変化してもよいことに留意されたいです。 [L-RSVP]アプローチを用いる代わりに[RSVP-PROXY1]れた場合、例えば、追加のPathRequestメッセージが戻り方向のパスメッセージの生成をトリガするためにホストからアグリゲータ/デアグリゲーター/プロキシに必要とされるであろう。
But regardless of the details of the call flow and of the actual RSVP Proxy approach, RSVP proxy may optionally be deployed in combination with RSVP Aggregation over MPLS TE tunnels, in such a way that ensures (when used on both the Host-Aggregator and Deaggregator-Host sides, and when both end systems support RSVP):
しかしかかわらず、コールフローの詳細と実際のRSVPプロキシアプローチの、RSVPプロキシは、必要に応じてホストアグリゲータとデアグリゲーターの両方で使用される場合（保証するように、MPLS TEトンネル上のRSVP集約と組み合わせて展開することができます-host辺とき両端システムサポートRSVP）：
(i) admission control and resource reservation is performed on every segment of the end-to-end path (i.e., between source host and Aggregator, over the TE tunnel between the Aggregator and Deaggregator that itself has been subject to admission control by MPLS TE, between Deaggregator and destination host).
（I）アドミッション制御及びリソース予約は、それ自体がMPLS TEによるアドミッション制御の対象となっていること（すなわち、ソースホストとアグリゲータ間、アグリゲータとデアグリゲーター間TEトンネル経由でエンドツーエンドパスの各セグメントに対して実行されます）デアグリゲーターと宛先ホストとの間。
(ii) this is achieved in both directions.
（II）これは両方向に達成されます。
(iii) RSVP signaling is localized between hosts and Aggregator/Deaggregator, which may result in significant reduction in reservation establishment delays (and in turn in post-dial delay in the case where these reservations are pre-conditions for voice call establishment), particularly in the case where the MPLS TE tunnels span long distances with high propagation delays.
（iii）のRSVPシグナリングが予約確立遅延の有意な減少をもたらすことができるホスト及びアグリゲータ/デアグリゲータ、間局在化している（これらの予約が音声通話確立のための前提条件である場合には、ポストダイヤル遅延の順番で）、特にMPLS TEトンネルが高い伝搬遅延との長距離に及ぶ場合には
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for VoIP Call Admission Control (CAC)
付録B - VoIPコールアドミッション制御のためのDSTEトンネル経由RSVP集約（CAC）の使用例
This Appendix presents an example scenario where the mechanisms described in this document are used, in combination with other mechanisms specified by the IETF, to achieve Call Admission Control (CAC) of Voice over IP (VoIP) traffic over the packet core.
この付録では、この文書で説明するメカニズムは、パケットコアオーバーIP（VoIP）のトラフィックボイスオーバーのコールアドミッション制御（CAC）を達成するために、IETFによって指定された他のメカニズムと組み合わせて、使用されているシナリオの例を示します。
The information in this Appendix is purely informational and illustrative.
この付録の情報は、純粋に情報および例示です。
Consider the scenario depicted in Figure B1. VoIP Gateways GW1 and GW2 are both signaling and media gateways. They are connected to an MPLS network via edge routers PE1 and PE2, respectively. In each direction, a DSTE tunnel passes from the Head-end edge router, through core network P routers, to the Tail-end edge router. GW1 and GW2 are RSVP-enabled. The RSVP reservations established by GW1 and GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For reservations going from GW1 to GW2, PE1 serves as the Aggregator/Head-end and PE2 serves as the Deaggregator/Tail-end. For reservations going from GW2 to GW2, PE2 serves as the Aggregator/Head-end and PE1 serves as the Deaggregator/Tail-end.
図B1に示されたシナリオを考えます。 VoIPのゲートウェイGW1とGW2は、シグナリングおよびメディアゲートウェイの両方です。これらは、それぞれ、エッジルータPE1とPE2を介してMPLSネットワークに接続されています。各方向において、DSTEトンネルは、テールエンドのエッジルータに、コアネットワークのPルータを介して、ヘッドエンドエッジルータから通過します。 GW1とGW2はRSVPに対応しています。 GW1とGW2によって確立されたRSVP予約はDS-TEトンネル上PE1とPE2によって集約されます。 GW1からGW2に行くご予約は、PE1は、アグリゲータ/ヘッドエンドとして機能し、PE2は、デアグリゲータ/テールエンドとして機能します。 GW2からGW2に行くご予約は、PE2は、アグリゲータ/ヘッドエンドとして機能し、PE1は、デアグリゲータ/テールエンドとして機能します。
To determine whether there is sufficient bandwidth in the MPLS core to complete a connection, the originating and destination GWs each send for each connection a Resource Reservation Protocol (RSVP) bandwidth request to the network PE router to which it is connected. As part of its Aggregator role, the PE router effectively performs admission control of the bandwidth request generated by the GW onto the resources of the corresponding DS-TE tunnel.
接続を完了するためにMPLSコアに十分な帯域幅があるかどうかを決定するために、発信元と宛先のGW各々は、各接続のためのリソース予約プロトコル（RSVP）は、それが接続されるネットワークのPEルータに帯域幅要求を送信します。そのアグリゲータの役割の一部として、PEルータは、効果的に対応するDS-TEトンネルのリソースにGWによって生成された帯域要求の受付制御を行います。
In this example, in addition to behaving as Aggregator/Deaggregator, PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path message from a GW, it does not propagate the Path message any further. Rather, the PE performs admission control of the bandwidth signaled in the Path message over the DSTE tunnel toward the destination. Assuming there is enough bandwidth available on that tunnel, the PE adjusts its bookkeeping of remaining available bandwidth on the tunnel and generates a Resv message back toward the GW to confirm resources have been reserved over the DSTE tunnel.
この例では、アグリゲータ/デアグリゲーターとして挙動に加えて、PE1及びPE2は、RSVPプロキシとして振る舞います。 PEは、GWからPathメッセージを受信したときので、それはそれ以上のPathメッセージを伝播しません。むしろ、PEは、宛先に向かってDSTEトンネルを介しPathメッセージにシグナリング帯域幅のアドミッション制御を行います。そのトンネル上で利用可能な十分な帯域幅があると仮定すると、PEは、トンネル上に残っている利用可能な帯域幅のその簿記を調整し、リソースを確認するためにバックGW向けてResvメッセージを生成DSTEトンネルを介して予約されています。
,-. ,-.
_.---' `---' `-+
,-'' +------------+ :
( | | `.
\ ,' CCA `. :
\ ,' | | `. ;
;' +------------+ `._
,'+ ; `.
,' -+ Application Layer' `.
SIP,' `---+ | ; `.SIP
,' `------+---' `.
,' `.
,' `.
,' ,-. ,-. `.
,' ,--+ `--+--'- --'\ `._
+-`--+_____+------+ { +----+ +----+ `. +------+_____+----+
|GW1 | RSVP| |______| P |___| P |______| | RSVP|GW2 |
| |-----| PE1 | { +----+ +----+ /+| PE2 |-----| |
| | | |==========================>| | | |
+-:--+ RTP | |<==========================| | RTP +-:--+
_|..__ +------+ { DSTE Tunnels ; +------+ __----|--.
_,' \-| ./ -'._ / |
| Access \ / +----+ \, |_ Access |
| Network | \_ | P | | / Network |
| / `| +----+ / | '
`--. ,.__,| | IP/MPLS Network / '---'- ----'
'`' '' ' .._,,'`.__ _/ '---' |
| '`''' |
C1 C2
Figure B1. Integration of SIP Resource Management and
RSVP Aggregation over MPLS TE Tunnels
[SIP-RSVP] discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session
[SIP-RSVP]サービスのネットワーク品質は、セッションによって開始されたセッションの確立のための前提条件とすることができる方法について説明します
Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. The reservation of network resources are performed through a signaling protocol such as RSVP.
開始プロトコル（SIP）。これらの前提条件は、セッションを続行する前に、参加者の予備ネットワークリソースする必要があります。ネットワークリソースの予約は、RSVPのようなシグナリングプロトコルを介して行われます。
Through the collaboration between SIP resource management, RSVP signaling, RSVP Aggregation and DS-TE as described above, we see that:
SIPリソース管理、RSVPシグナリングの間のコラボレーションを通じ、前述したように、私たちがいることがわかり集約とDS-TEをRSVP：
a) the PE and GW collaborate to determine whether there is enough bandwidth on the tunnel between the calling and called GWs to accommodate the connection,
A）PEとGWは、呼び出しの間のトンネルに十分な帯域幅があるかどうかを決定するために協力して接続を収容するためのGWと呼ばれます
b) the corresponding accept/reject decision is communicated to the GWs on a connection-by-connection basis, and
B）対応する接続ごとにのGWに伝達される決定を拒否/承諾、及び
c) the PE can optimize network resources by dynamically adjusting the bandwidth of each tunnel according to the load over that tunnel. For example, if a tunnel is operating at near capacity, the network may dynamically adjust the tunnel size within a set of parameters.
C）PEは動的にトンネルを介して負荷に応じて各トンネルの帯域幅を調整することにより、ネットワークリソースを最適化することができます。トンネルが近く容量で動作している場合、例えば、ネットワークは、動的パラメータのセット内のトンネルサイズを調整することができます。
We note that admission Control of voice calls over the core network capacity is achieved in a hierarchical manner whereby:
私たちは、コアネットワークの容量はそれによって階層的に達成された上での音声のアドミッションコントロールが呼び出されます注意してください。
- DSTE tunnels are subject to Admission Control over the resources of the MPLS TE core
- DSTEトンネルは、MPLS TEコアのリソースに対するアドミッション制御の対象となっています
- Voice calls are subject to CAC over the DSTE tunnel bandwidth
- 音声通話はDSTEトンネル帯域幅でCACの対象となります
This hierarchy is a key element in the scalability of this CAC solution for voice calls over an MPLS Core.
この階層は、MPLSコア上での音声通話のために、このCACソリューションのスケーラビリティの重要な要素です。
It is also possible for the GWs to use aggregate RSVP reservations themselves instead of per-call RSVP reservations. For example, instead of setting one reservation for each call GW1 has in place toward GW2, GW1 may establish one (or a small number of) aggregate reservations as defined in [RSVP-AGG] or [RSVP-GEN-AGG], which is used for all (or a subset of all) the calls toward GW2. This effectively provides an additional level of hierarchy whereby:
GWは、集約RSVP予約そのものの代わりに、コールごとのRSVP予約を使用することも可能です。例えば、代わりごとに1つの予約の設定である、[RSVP-AGG]または[RSVP-GEN-AGG]で定義されるようGW1がGW2に向けて所定の位置に、GW1は、1つ（または少数の）集約の予約を確立することができるしている呼び出しGW2に向けてコールはすべての（またはすべてのサブセット）に使用されます。これは事実上、階層れる追加のレベルを提供します。
- DSTE tunnels are subject to Admission Control over the resources of the MPLS TE core
- DSTEトンネルは、MPLS TEコアのリソースに対するアドミッション制御の対象となっています
- Aggregate RSVP reservations (for the calls from one GW to another GW) are subject to Admission Control over the DSTE tunnels (as per the "RSVP Aggregation over TE Tunnels" procedures defined in this document)
- （別のGWへの1 GWからの呼び出しのために）集約RSVP予約（この文書で定義された手順「TEトンネル上集約RSVP」に従って）DSTEトンネル上アドミッション制御の対象となっています
- Voice calls are subject to CAC by the GW over the aggregate reservation toward the appropriate destination GW.
- 音声通話は、適切な宛先GWに向かって凝集予約上GWによってCACの対象となっています。
This pushes even further the scalability limits of this voice CAC architecture.
これはさらに、この音声CACアーキテクチャのスケーラビリティの限界をプッシュします。
Contributing Authors
共著
This document was the collective work of several authors. The text and content were contributed by the editor and the co-authors listed below.
この文書では、数人の著者の集合的な仕事でした。テキストやコンテンツはエディタと以下のとおり共著者によって寄与されました。
Michael DiBiasio Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: dibiasio@cisco.com
マイケルDiBiasioシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719 USA電子メール：dibiasio@cisco.com
Bruce Davie Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: bdavie@cisco.com
ブルース・デイビーシスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719 USA Eメール：bdavie@cisco.com
Christou Christou Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA EMail: christou_chris@bah.com
ChristouのChristouのブーズ・アレン・ハミルトン8283グリーンズボロドライブマクリーン、VA 22102 USA電子メール：christou_chris@bah.com
Michael Davenport Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA EMail: davenport_michael@bah.com
マイケル・ダベンポートブーズ・アレン・ハミルトン8283グリーンズボロドライブマクリーン、VA 22102 USA電子メール：davenport_michael@bah.com
Jerry Ash AT&T 200 Laurel Avenue Middletown, NJ 07748 USA EMail: gash@att.com
ジェリー・アッシュAT＆T 200ローレルアベニューミドルタウン、NJ 07748 USA電子メール：gash@att.com
Bur Goode AT&T 32 Old Orchard Drive Weston, CT 06883 USA EMail: bgoode@att.com
バール・グッドAT＆T 32オールドオーチャードドライブウェストン、CT 06883 USA Eメール：bgoode@att.com
Editor's Address
編集者の住所
Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France
フランソワ・リーパーシスコシステムズ社コーポレート・ヴィレッジグリーンサイド - T3ビル400、アベニューRoumanille 06410ビオソフィアアンティポリスフランス
EMail: flefauch@cisco.com
メールアドレス：flefauch@cisco.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機能のための基金は現在、インターネット協会によって提供されます。