[要約] RFC 4804は、MPLS TE/DS-TEトンネル上のRSVP予約の集約に関する規格です。目的は、ネットワークリソースの効率的な利用とトラフィックエンジニアリングの向上です。
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
MPLS TE/DS-TEトンネル上のリソース予約プロトコル（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 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-Aware MPLSトラフィックエンジニアリング（DS-TE）トンネルを介したRSVPエンドツーエンド予約の集約を指定しています。このアプローチはRFC 3175に基づいており、総RSVP予約ではなく、MPLS TEトンネルを介した操作の対応する手順を単純に変更します。ネットワークのコアのデバイスはエンドツーエンドのRSVP予約を知らず、MPLS TE Tunnelsのみを認識しているため、このアプローチをスケーラブルな方法で非常に多数のフローの入場制御を実現するために使用できます。
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.
Integrated Services（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サービス仕様（[保証]、[制御]）で定義されているように、INTSVパラメーターを使用してこれらの要件を表します。
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 CodePoint（DSCP）に基づいて、少数の集約されたフローまたは「クラス」の1つにパケットを分類します。各diffservルーターで、パケットは「ホップごとの動作」（PHB）にさらされ、DSCPによって呼び出されます。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]で詳述されているように、リソースベースの入場制御、ポリシーベースの入場管理、トラフィックの識別/分類の支援、トラフィックコンディショニングなど、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予約のこのような集約を実行する方法を詳細に説明しています。彼らは、「集約領域」のエッジで同じイングレスルーター（アグリゲーター）と出口ルーター（Deaggregator）を共有する複数のエンドツーエンドの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] RSVP-TEシグナル伝達を使用して、このようなMPLS TEトンネルをどのように確立できるかを指定します。MPLS 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-Aware MPLSトラフィックエンジニアリング（DS-TE）のサポートに関するサービスプロバイダーの要件を提示します。DS-TEを使用すると、個別のDS-TEトンネルを使用して、さまざまなDiffServクラスのトラフィックを運ぶことができ、これらの異なるクラスで異なるリソースの制約を実施できます。[DSTE-PROTO]は、DS-TEをサポートするために、RSVP-TEシグナル伝達拡張機能と中間システム（IS-IS）拡張機能を指定します。
In the rest of this document we will refer to both TE tunnels and DS-TE tunnels simply as "TE tunnels".
このドキュメントの残りの部分では、Te TunnelsとDS-TEトンネルの両方を単に「Te Tunnels」と呼びます。
TE tunnels have much in common with the aggregate RSVP reservations used in [RSVP-AGG] and [RSVP-GEN-AGG]:
TEトンネルは、[RSVP-AGG]および[RSVP-Gen-Agg]で使用される集計RSVP予約と多くの共通点を持っています。
- 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.
- TEトンネルと凝集RSVP予約の両方は、「集約コア」の端にある「インテリジェント」デバイス（TEトンネルの場合のヘッドエンドとテールエンドによって制御されます。集約RSVP予約の場合のアグリゲーターとディーグレジェーター。
- 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プロトコル（[RSVP-TE]および[DSTE-Proto]でそれぞれTEトンネルとDS-TEトンネルで定義されている拡張機能を使用）を使用してシグナル伝えられます。
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集約手順に対する主な変更は、これらの手順を変更して、Deaggregatorからアグリゲーター（つまり、トンネルヘッドエンド）に責任を再割り当てすることです。
[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]このようなLSPの階層を作成することにより、MPLS TEラベルスイッチパス（LSP）を集約する方法を定義します。これには、エンドツーエンドのLSPをコア内の凝集LSPにネストすることが含まれます（ラベルスタックコンストラクトを使用して）。エンドツーエンドのTE LSPは、それ自体がすべてのホップでRSVP-TEおよびリザーブリソースでシグナルであるため、これはMPLS TEトンネル上のRSVP（-TE）予約の集合の形と見なすことができます。このドキュメントは、Te Tunnels上のTe LSPのネストとTe Tunnels上の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).
- このドキュメントでは、MPLSトンネルの操作について説明しますが、RFC 2746はIPトンネルを使用した動作について説明しています。この違いの結果の1つは、最後から2番目のホップポップ（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.
- MPLS-TEトンネルは本質的にリソースを留保しますが、RFC 2746のトンネルにはデフォルトではリソースの予約がありません。これにより、現在のドキュメントのいくつかの単純化につながります。
- 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.
- このドキュメントは、MPLS-TEトンネルごとに1つの集計予約があるという事実に基づいて構築されていますが、RFC 2746では、各エンドツーエンドフローのトンネルパスに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 2746と多くの類似点があります。MPLS-TEトンネルは、RFC 2746の命名法の「タイプ2トンネル」です。
"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]と[RSVP-Gen-Agg]の利点と、以下を含むMPLSの利点を組み合わせたものです。
- 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コアの上流と下流のリンクがコア容量と比較して非常に過剰にエンジニアリングされている場合、入場制御は膨大です。これらの過剰な設計リンクでは必要ありませんが、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予約に気付いておらず、コアのデータパス分類とスケジュールは純粋に依存しているため、コアはエンドツーエンドのRSVP予約に気付いておらず、総計を維持する必要があるため、コアスケーラビリティは影響を受けません（従来のMPLS展開モデルと比較して）diffservメカニズム（より正確には、[diff-mpls]で指定されているMPLS 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 Fast Rerouteを使用して障害から保護できます。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[キーワード]で説明されていると解釈されます。
For readability, a number of definitions from [RSVP-AGG] as well as definitions for commonly used MPLS TE terms are provided here:
読みやすさのために、[RSVP-AGG]からの多くの定義と、一般的に使用されるMPLS TE用語の定義はここに記載されています。
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
Deaggregatorこれは、集約領域の出口端のルーター（エンドツーエンドの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
(i) 対応するパスメッセージは、アグリゲーターの上流に開始され、ディーグレジャーの下流に終了し、
(ii) corresponding Resv messages are initiated downstream of the Deaggregator and terminated upstream of the Aggregator, and
（ii）対応するRESVメッセージがDeaggregatorの下流に開始され、アグリゲーターの上流に終了し、
(iii) this RSVP reservation is aggregated over an MPLS TE tunnel between the Aggregator and Deaggregator.
（iii）このRSVP予約は、アグリゲーターとDeaggregatorの間の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トンネルを考慮に入れることを許可することを目指しているためです。現在のドキュメントでは、TEトンネルに集約されるエンドツーエンドのRSVP予約は、通常のSPFルーティングに依存しています。ただし、[LSP-Hier]ですでに述べたように、TEトンネルはIS-ISまたはOSPFに宣伝され、アグリゲーターの上流のノードによって通常のSPFで使用される可能性があることに注意してください。これは、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.
[LSP-Hier] GMPLSメカニズムによってトリガーされる場合、骨材の確立/終了に適用されます（たとえば、集約境界で受け取ったエンドツーエンドのTE LSP確立要求の結果として）。このドキュメントは事前に確立されたトンネルを想定しているため、これらの側面はここでは関連していません。[LSP-Hier]のセクション6.1で説明されているシグナルの側面は、骨材のTEトンネル上のエンドツーエンドのTE LSPの確立/メンテナンスに関連しています。このドキュメントでは、[LSP-Hier]のセクション6.1で指定されている手順と同じ手順を使用する方法について説明しますが、TEトンネル上のエンドツーエンドの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ルーターHE/AGG = TEトンネルヘッドエンド/アグリゲーターTE/DEAG = TEトンネルテールエンド/ディーグレジャーT =トランジットLSR
-- = E2E RSVP reservation
== = TE tunnel
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パスメッセージの到着です。アグリゲーターは、このセクションで文書化された拡張機能で増強されたこの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).
アグリゲーターは、最初にE2E予約をTEトンネルにマッピングしようとする必要があります。この決定は、ルーティング情報と、アグリゲーターで利用可能なローカルポリシー情報に従って行われます。このようなポリシーの例は、次の段落に表示されます。イラストの目的のために、他の多くの基準の中でも、そのようなマッピングポリシーは、IntServサービスタイプ、アプリケーションID [RSVP-Appid]、および/またはE2E予約のシグナル前の先制[RSVP-PREEMP]を考慮する可能性があります（たとえば、例えば、アグリゲーターは、E2E予約のRSVP先制優先度とMPLS TEトンネルのセットアップを考慮し、E2E予約をMPLS TEトンネルにマッピングするときに優先順位を保持する場合があります。
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.
アグリゲーターが最終決定を行うことができない状況があります。たとえば、ルーティングが目的地に向かって2つのDSTEトンネルを識別する場合、DS-TEクラスタイプ1に属するものとクラスタイプ0に1つを識別する場合、ポリシーがINTSERV保証サービスの予約をマッピングする場合、クラスタイプ1トンネルとクラスタイプ0トンネルへのIntServ制御の負荷予約、およびE2E RSVPパスメッセージが保証されたサービスと制御された負荷の両方を宣伝する場合。
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パスメッセージを受信機に転送する前に、アグリゲーターはE2Eパスメッセージ内のADSPECを更新して、E2Eフローによって達成可能なQOSへのMPLS TEクラウドの影響を反映する必要があります。この更新はローカルの問題であり、構成された情報、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.
アグリゲーターは、E2EパスメッセージをDeaggregator（選択したTEトンネルのテールエンド）に転送する必要があります。[LSP-Hier]に従って、アグリゲーターはRSVP_HOPオブジェクトの代わりにIF_ID RSVP_HOPオブジェクトを使用してE2Eパスメッセージを送信する必要があります。データインターフェイス識別は、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パスメッセージを送信するには、アグリゲーターは、E2EパスメッセージのIPヘッダーにDeaggregatorアドレスに宛先アドレスを設定することにより、Deaggregatorに直接対処する必要があります。ルーターアラートは、E2Eパスメッセージには設定されていません。
Optionally, the Aggregator MAY also encapsulate the E2E Path message in an IP tunnel or in the TE tunnel itself.
オプションで、アグリゲーターは、IPトンネルまたはTEトンネル自体のE2Eパスメッセージをカプセル化する場合があります。
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パスメッセージは、アグリゲーターからDeaggregatorへのパスに沿ったルーターに表示されません。したがって、[rsvp-agg]および[rsvp-gen-agg]の手順とは対照的に、IPプロトコル番号を「rsvp-e2e-ignore」に変更する必要はありません。アグリゲーターによってそのまま（「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.
一部の環境では、アグリゲーターとDeaggregatorは、AggregatorとDeaggregatorの間を通過するときにE2EトラフィックにIPSEC保護を提供するために、IPSECセキュリティゲートウェイとして機能する場合があります。その場合、E2EパスメッセージをDeaggregatorに送信するには、アグリゲーターはE2EパスメッセージをDeaggregatorで終了する関連するIPSECトンネルに送信する必要があります。
E2E PathTear and ResvConf messages MUST be forwarded by the Aggregator to the Deaggregator exactly like Path messages.
E2E PATHTEARおよびRESVCONFメッセージは、アグリゲーターによってパスメッセージとまったく同じようにDeaggregatorに転送する必要があります。
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パスメッセージはDeaggregatorに直接アドレス指定され、ルーターアラートセットがないため、すべてのトランジット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パスメッセージを受信すると、DeaggregatorはIPプロトコル番号が「RSVP」に設定されていることに気付き、したがってE2Eパスメッセージの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]と同様に、IP TTL対RSVP TTLチェックを作成してはなりません。Deaggregatorは、IF_ID RSVPホップオブジェクトの存在のためにこのチェックを作成しないことを通知されます。
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:
Deaggregatorは、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_idrsvp_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.
これらのチェックを実行するために必要な情報は、Deaggregatorが常に利用できるとは限りません。したがって、Deaggregatorは、チェックを作成できない環境での操作をサポートする必要があります。
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.
Deaggregatorは、E2Eパスを下流にレシーバーに向かって転送する必要があります。そうすることで、Deaggregatorは、セッションオブジェクトの宛先アドレスフィールドにあるIPアドレスにE2EパスメッセージのIPヘッダーに宛先アドレスを設定します。Deaggregatorは、ルーターアラートも設定します。
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.
E2Eパスメッセージ（IF_ID RSVP_HOPオブジェクトを含む）に応じてDeaggregatorによって送信された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を受信すると、DeaggregatorはE2E RESVメッセージを受信したときに従来のRSVP手順に従う必要があります。これには、Deaggregatorの下流のセグメントの入場制御の実行と、E2E PATHメッセージで前述したPHOPにE2E RESVメッセージを転送し、アグリゲーターを識別することが含まれます。E2E RESVメッセージはアグリゲーターに直接アドレス指定され、ルーターアラートオプション（従来のRSVP RESV手順に従って）を搭載していないため、E2E RESVメッセージはDeaggregatorとAggregatorの間のルーターから隠されています。通常の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.
アグリゲーターとDeaggregatorもIPSECセキュリティゲートウェイとして機能している場合、DeaggregatorはAggregatorで終了する関連する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トンネルを介してDeaggregatorへの適切な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手順を使用してリソース要求のサイズを計算します。つまり、[RSVP]の手順に従って、送信者TSPECとRESVに含まれるFlowsPecからのリソース要件を決定します。次に、リソース要求を選択した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トンネルで十分な帯域幅が利用可能な場合、アグリゲーターは、TEトンネルの使用量の内部理解を更新し、E2E RESVメッセージを対応するPHOPに転送する必要があります。
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手順に従う必要があります。つまり、予約は設置されておらず、レスバーロールがレシーバーに向かって送り返されます。
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
最終マッピング中にトンネルが変更された場合、アグリゲーターは最初にDeaggregatorにe2eパスメッセージに再送信する必要があります。if_idRSVP_HOPデータインターフェイス識別最終TEトンネルを識別する必要があります。必要に応じて、このE2EパスメッセージのADSPEC情報を更新する必要があります。その後、アグリゲーターはしなければなりません
- 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 RESVメッセージを受信した場合にのみ発生します（Resent E2Eに応じてDeaggregatorによって送信されます。道）。後者の場合、最終トンネルの入場制御はアグリゲーターによって直ちに実行され、成功した場合、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.
AggregatorからE2E ResvConfを受信すると、DeaggregatorはE2E RESVCONFを下流にレシーバーに向けて転送する必要があります。そうすることで、Deaggregatorは、対応するRESVのRESV_CONFIRMオブジェクトにあるIPアドレスにE2E RESVCONFメッセージのIPヘッダーに宛先アドレスを設定します。Deaggregatorは、ルーターアラートも設定します。
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.
アグリゲーターとDeaggregatorがIPSECセキュリティゲートウェイとしても機能している場合、アグリゲーターは、MPLS TEトンネルに送信する前に、Deaggregatorで終了する関連する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_ERRORメッセージを送信する場合があります。パスメッセージが別のディーグレジェレーターで終了する別のトンネルに転送された場合、または予約がパスエラーメッセージを介して取り壊される場合、TEトンネルがなくなる前にディーグレジェレーターとして機能するルーターに確立された予約状態は、タイムアウトしますそれはもはやリフレッシュされないので。
Aggregator Deaggregator
アグリゲーター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トンネルを事前に確立するようにトリガーされます
(**) TE tunnel(s) are pre-established
(1) Aggregator tentatively selects the TE tunnel and forwards E2E path to Deaggregator
(1) アグリゲーターはTEトンネルを暫定的に選択し、E2EパスをDeaggregatorに転送します
(2) Deaggregator forwards the E2E Path toward the receiver
(2) Deaggregatorは、E2Eパスを受信機に向かって転送します
(3) Deaggregator forwards the E2E Resv to the Aggregator
(3) Deaggregatorは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トンネルに十分な帯域幅があることを確認し、E2E RESVをPHOPに転送します。最終トンネルが暫定的に選択されたトンネルと異なる場合、アグリゲーターは、更新された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.
(1) IPv4 TEトンネル上のE2E IPv4 RSVP予約の集約。
(2) Aggregation of E2E IPv6 RSVP reservations over IPv6 TE tunnels.
(2) IPv6 TEトンネル上のE2E IPv6 RSVP予約の集約。
(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)
(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トラフィックをルーティングするためにアグリゲーターとDeaggregatorがメカニズムを使用することができました。
The procedures defined in this document are applicable to many types of E2E RSVP reservations including the following cases:
(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)
(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トンネルを介してパケットコアを介して集約されます。ユーザーによって定義されたマッピングポリシーは、オーディオおよび音声ストリームのすべての予約がクラスタイプ1のDS-TEトンネルにマッピングされ、ビデオストリームの予約はクラスタイプ0の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 = deaggregator（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
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 Tunnelを介して集約され、トンネルヘッドエンドがアグリゲーターとして機能し、MPLS TEトンネルへのトランクゲートウェイの予約の入場制御を実行することができます。MPLS TEトンネルは、MPLS Fast Rerouteによって保護される場合があります。このシナリオを以下に示します。
------ ------
| 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 = DEAGGREGATOR（TE Tunnel TailEnd）T = Transit LSR
/ = Aggregate Gateway to Gateway E2E RSVP reservation
== = TE tunnel
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メッセージを使用して、MPLS領域外のE2Eフローのリソース予約を制御し、MPLS領域内のMPLS TEトンネルのリソース予約を制御します。関連する予約および入場制御メカニズムの完全性を確保するために、[RSVP-CRYPTO1]および[RSVP-CRYPTO2]で定義されているメカニズムを使用できます。このメカニズムは、RSVPメッセージの整合性を保護し、ホップバイホップを提供し、ノード認証を提供し、それによりRSVPメッセージの腐敗とスプーフィングから保護します。これらのホップバイホップの整合性メカニズムは、MPLS地域外のE2E予約に使用されるRSVPメッセージを保護するために自然に使用できます。これらのホップバイホップRSVP整合性メカニズムは、MPLS領域を通過する場合にE2E予約に使用されるRSVPメッセージを保護するためにも使用できます。これは、AggregatorとDeaggregatorがE2Eフローの観点からRSVPの隣人として振る舞うためです（必ずしもIP隣人でもRSVP-TE隣人ではない場合でも）。その場合、アグリゲーターとDeaggregatorは、恥ずかしい秘密を使用する必要があります。
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 filtering of RSVP messages associated with MPLS TE tunnels can be deployed to that end.
[RSVP-TE]のセクション6で説明したように、MPLS TEトンネルに関連するトラフィックのフィルタリングは、[RSVP]に従って、従来のRSVP予約の5タプルではなく、MPLSラベルに基づいてのみ行うことができます。したがって、[RSVP-TE]で説明されているように、管理者は、この仕様に従ってRSVP E2E予約の集約に使用されるTEトンネル（この仕様に従ってRSVP E2E予約に使用される）を制限することを希望する場合があります。MPLS TEトンネルに関連付けられたRSVPメッセージのフィルタリングをその端に展開する方法の説明については、[RSVP-TE]のセクション6を参照してください。
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-AGG]に一部基づいており、RSVP予約の集約を指定しています。[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トンネルを動的にサイズ変更する場合、コアのRSVP集約HOGリソースに使用される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パスメッセージの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.
アグリゲーターとDeaggregatorも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]仕様に基づいて構築されます。この文書に入力してくれたトム・フェラン、ジョン・ドレイク、アルティ・アヤンガル、フレッド・ベイカー、スバ・ディカン、クウォック・ホ・チャン、キャロル・イトゥルラルデ、ジェームズ・ギブソンに感謝します。
[CONTROLLED] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[Controled] 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.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[DSTE-PROTO] Le Faucheur, F., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[DSTE-Proto] Le Faucheur、F。、「Diffserv-akeare 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.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、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.、Ford、P.、Yavatkar、R.、Baker、F.、Zhang、L.、Speer、M.、Braden、R.、Davie、B.、Wroclawski、J.、E. Felstaine、「Diffserv Networksを介した統合サービス操作のフレームワーク」、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] Braden、R.、Clark、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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[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.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] 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-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月。
[SEC-ARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[Sec-arch] Kent、S。and 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] De Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用したIPv6 MPLSを使用してIPv6島を接続する」、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 and Leroux、「マルチプロトコル（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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P.、J。Heinanen、 "Multi-protocol差別化されたサービスのラベルスイッチング（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] Le Faucheur、F。およびW. Lai、「差別化されたサービス認識MPLSトラフィックエンジニアリングのサポートの要件」、RFC 3564、2003年7月。
[L-RSVP] Manner, et al., Localized RSVP for Controlling RSVP Proxies, Work in Progress.
[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.、Ford、P.、Moore、T.、Herzog、S。、およびR. Hess、「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-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-PREEMP] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RSVP-Preemp] Herzog、S。、「シグナル前の先制優先政策要素」、RFC 3181、2001年10月。
[RSVP-PROXY1] Gai, et al., RSVP Proxy, Work in Progress.
[RSVP-Proxy1] Gai、et al。、RSVP Proxy、Work in Progress。
[RSVP-PROXY2] Le Faucheur, et al., RSVP Proxy Approaches, Work in Progress.
[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. Zhang、「RSVP Operation over IP Tunnels」、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] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（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:
- originates the Resv Message (in response to the Path message) on behalf of the destination node
- 宛先ノードに代わって（パスメッセージに応じて）RESVメッセージを発信します
- originates the Path message (in response to some trigger) on behalf of the source node.
-
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.
The information in this Appendix is purely informational and illustrative.
As discussed in [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."
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).
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).
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）：Aggregator/Deaggregator/Proxyはパスメッセージを受信し、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）：Aggregator/Deaggregator/Proxyは、ホストに対する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）：Aggregator/Deaggregator/Proxyは、予約のためにホストに向かってパスメッセージを生成します。これの実際のトリガーは、実際の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.
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):
(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) 入場制御とリソースの予約は、エンドツーエンドのパスのすべてのセグメントで実行されます（つまり、ソースホストとアグリゲーターの間、アグリゲーターとDeaggregatorの間のTEトンネルで、それ自体がMPLS TEによる、Deaggregatorの間での入場制御の対象となっています。および宛先ホスト）。
(ii) this is achieved in both directions.
(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.
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for VoIP Call Admission Control (CAC)
付録B- VoIPコール入学制御（CAC）のためのDSTEトンネルを介したRSVP集約の例の使用
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.
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はDeaggregator/Tail-Endとして機能します。GW2からGW2への予約のために、PE2はアグリゲーター/ヘッドエンドとして機能し、PE1はDeaggregator/TailEndとして機能します。
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コアに接続を完了するのに十分な帯域幅があるかどうかを判断するために、各接続に対して各接続と宛先GWSがリソース予約プロトコル（RSVP）帯域幅要求を、接続するネットワークPEルーターに送信します。Aggregatorの役割の一部として、PEルーターは、GWによって生成された帯域幅要求の入場制御を、対応するDS-TEトンネルのリソースに効果的に実行します。
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.
この例では、アグリゲーター/Deaggregatorとして動作することに加えて、PE1とPE2はRSVPプロキシとして動作します。したがって、PEがGWからパスメッセージを受信した場合、パスメッセージはこれ以上伝播しません。むしろ、PEは、DSTEトンネルを介して宛先に向かってパスメッセージに合図された帯域幅の入場制御を実行します。そのトンネルに十分な帯域幅があると仮定すると、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 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]は、セッション開始プロトコル（SIP）によって開始されたセッションの確立のためのネットワークサービスの品質をどのように進めることができるかについて説明します。これらの前提条件では、参加者がセッションを継続する前にネットワークリソースを予約する必要があります。ネットワークリソースの予約は、RSVPなどのシグナル伝達プロトコルを通じて実行されます。
Through the collaboration between SIP resource management, RSVP signaling, RSVP Aggregation and DS-TE as described above, we see that:
上記のように、SIPリソース管理、RSVPシグナル伝達、RSVP集約、DS-TEのコラボレーションを通じて、次のようになります。
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は協力して、接続に対応するために呼び出しと呼び出されたGWSの間にトンネルに十分な帯域幅があるかどうかを判断します。
b) the corresponding accept/reject decision is communicated to the GWs on a connection-by-connection basis, and
b) 対応する受け入れ/拒否決定は、接続ごとにGWSに伝えられ、
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:
また、GWSが1コールのRSVP予約ではなく、集約RSVP予約自体を使用することも可能です。たとえば、各コールに1つの予約を設定する代わりに、GW1がGW2に向かって導入されているため、GW1は[RSVP-AGG]または[RSVP-Gen-Agg]で定義されている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)
- 集約RSVP予約（あるGWから別のGWへの呼び出しの場合）は、DSTEトンネル（このドキュメントで定義されている「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
Michael Dibiasio Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 USAメール：dibiasio@cisco.com
Bruce Davie Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: bdavie@cisco.com
Bruce Davie Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 USAメール：bdavie@cisco.com
Christou Christou Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 USA EMail: christou_chris@bah.com
Christou Christou Booz Allen Hamilton 8283 Greensboro Drive McLean、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グリーンズボロドライブマクリーン、バージニア州22102 USAメール：davenport_michael@bah.com
Jerry Ash AT&T 200 Laurel Avenue Middletown, NJ 07748 USA EMail: gash@att.com
ジェリーアッシュAT＆T 200ローレルアベニューミドルタウン、ニュージャージー07748 USAメール：gash@att.com
Bur Goode AT&T 32 Old Orchard Drive Weston, CT 06883 USA EMail: bgoode@att.com
Bur Goode at＆t 32 Old Orchard Drive Weston、CT 06883 USAメール：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
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
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.