Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 5945 Cisco
Category: Informational J. Manner
ISSN: 2070-1721 Aalto University
D. Wing
Cisco
A. Guillou
SFR
October 2010
Resource Reservation Protocol (RSVP) Proxy Approaches
Abstract
抽象
The Resource Reservation Protocol (RSVP) can be used to make end-to-end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described.
リソース予約プロトコル（RSVP）は、特定のフローによって要求されるサービスの品質を保証するために、IPネットワーク内のエンド・ツー・エンドのリソース予約を行うために使用することができます。 RSVPは、特定のフローのデータの送信側と受信側の両方がRSVPシグナリングに参加することを想定しています。まだ、リソース予約が必要とされる用途場合があるが、受信機、送信者、またはその両方は、RSVP-ことができません。この文書では、RSVPルータが受信機またはRSVP-できない送信者に代わってRSVPシグナルを開始または終了することができRSVPプロキシの動作を示しています。これは、リソースの予約は、エンドツーエンドのパスの重要なサブセットに確立することができます。この文書では、RSVPプロキシを展開するための概念的なアプローチを検討し、RSVP予約が、送信者、受信者、またはその両方がRSVPに参加していないにも関わらず、アプリケーションの要件と同期させることができる方法について説明します。この文書はまた、拡張機能は、所与のRSVPプロキシアプローチの展開のために必要とされ得る（または他のプロトコル）RSVPする場所を指摘します。しかし、そのような拡張は、この文書の範囲外です。最後に、RSVPプロキシの実用例が記載されています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5945.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5945で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. RSVP Proxy Behaviors ............................................6
2.1. RSVP Receiver Proxy ........................................6
2.2. RSVP Sender Proxy ..........................................7
3. Terminology .....................................................7
4. RSVP Proxy Approaches ...........................................9
4.1. Path-Triggered Receiver Proxy ..............................9
4.1.1. Mechanisms for Maximizing the Reservation Span .....11
4.2. Path-Triggered Sender Proxy for Reverse Direction .........15
4.3. Inspection-Triggered Proxy ................................18
4.4. STUN-Triggered Proxy ......................................21
4.5. Application_Entity-Controlled Proxy .......................23
4.5.1. Application_Entity-Controlled Sender Proxy
Using "RSVP over GRE" ..............................26
4.5.2. Application_Entity-Controlled Proxy via Co-Location 28
4.6. Policy_Server-Controlled Proxy ............................29
4.7. RSVP-Signaling-Triggered Proxy ............................32
4.8. Reachability Considerations ...............................33
5. Security Considerations ........................................34
6. Acknowledgments ................................................36
7. References .....................................................36
7.1. Normative References ......................................36
7.2. Informative References ....................................37
Appendix A. Use Cases for RSVP Proxies ...........................40
A.1. RSVP-Based VoD Admission Control in Broadband
Aggregation Networks ......................................40
A.2. RSVP-Based Voice/Video Connection Admission Control
(CAC) in Enterprise WAN ...................................43
A.3. RSVP Proxies for Mobile Access Networks ...................44
A.4. RSVP Proxies for Reservations in the Presence of IPsec
Gateways ..................................................46
Guaranteed Quality of Service (QoS) for some applications with tight requirements (such as voice or video) may be achieved by reserving resources in each node on the end-to-end path. The main IETF protocol for these resource reservations is the Resource Reservation Protocol (RSVP), as specified in [RFC2205]. RSVP does not require that all intermediate nodes support RSVP; however, it assumes that both the sender and the receiver of the data flow support RSVP. There are environments where it would be useful to be able to reserve resources for a flow on at least a subset of the flow path even when the sender or the receiver (or both) is not RSVP-capable (for example, from the sender to the network edge, or from edge to edge, or from the network edge to the receiver).
（音声やビデオなど）厳しい要件を持ついくつかのアプリケーションのためのサービス（QoS）の保証の品質は、エンドツーエンドのパス上の各ノードのリソースを確保することによって達成することができます。これらの資源予約のための主要なIETFプロトコルは、[RFC2205]で指定されるように、リソース予約プロトコル（RSVP）です。 RSVPは、すべての中間ノードのサポートRSVPする必要はありません。しかし、送信者とデータフロー支持RSVPの受信機の両方と仮定しています。送信側または受信側（または両方）はRSVP-ことができない場合であっても（例えば、送信者からへの流路の少なくともサブセットのフローのためのリソースを確保できることが有用であろう環境がありますネットワークエッジ、またはエッジからエッジまで、または）受信機へのネットワークエッジから。
Since the data sender or receiver may be unaware of RSVP, there are two types of RSVP proxies. When the sender is not using RSVP, an entity in the network must operate on behalf of the data sender, and in particular, generate RSVP Path messages, and eventually receive, process, and sink Resv messages. We refer to this entity as the RSVP Sender Proxy. When the receiver is not using RSVP, an entity in the network must receive Path messages sent by a data sender (or by an RSVP Sender Proxy), sink those, and return Resv messages on behalf of the data receiver(s). We refer to this entity as the RSVP Receiver Proxy. The RSVP proxies need to be on the data path in order to establish the RSVP reservation; note, however, that some of the approaches described in this document allow the RSVP proxies to be controlled/triggered by an off-path entity.
データの送信側または受信側がRSVPを知らないかもしれないので、RSVPプロキシの2種類があります。送信者がRSVPを使用していない場合は、ネットワーク内のエンティティは、データ送信者に代わって動作しなければならず、特に、RSVPパスメッセージを生成し、最終的には、プロセスを受信し、RESVメッセージをシンクします。私たちは、RSVP送信者のプロキシとしてこの実体を参照してください。受信機は、RSVPを使用していない場合、ネットワーク内のエンティティは、データ送信側（又はRSVP送信側プロキシによって）によって送信されたPathメッセージを受信し、それらをシンク、及びデータ受信機（複数可）の代わりにRESVメッセージを返さなければなりません。私たちは、RSVPレシーバープロキシとしてこの実体を参照してください。 RSVPプロキシは、RSVP予約を確立するために、データパスにする必要があります。ただし、本書で説明する方法のいくつかは、RSVPプロキシがオフパスエンティティによってトリガ/制御することを可能にすること。
The flow sender and receiver generally have at least some (if not full) awareness of the application producing or consuming that flow. Hence, the sender and receiver are in a natural position to synchronize the establishment, maintenance, and teardown of the RSVP reservation with the application requirements. Similarly, they are in a natural position to determine the characteristics of the reservation (bandwidth, QoS service, etc.) that best match the application requirements. For example, before completing the establishment of a multimedia session, the endpoints may decide to establish RSVP reservations for the corresponding flows. Similarly, when the multimedia session is torn down, the endpoints may decide to tear down the corresponding RSVP reservations. For instance, [RFC3312] discusses how RSVP reservations can be very tightly synchronized by endpoints that uses the Session Initiation Protocol (SIP) ([RFC3261]) for session control.
フロー送信者と受信者は、一般的にその流れを生成または消費するアプリケーションの少なくとも一部（フルでない場合）意識を持っています。したがって、送信側と受信側は、アプリケーションの要件にRSVP予約の確立、維持、およびティアダウンを同期させる自然な位置にあります。同様に、彼らは最高のアプリケーションの要件に合わせた予約（帯域幅、QoSサービス、など）の特性を決定するために自然な位置にあります。例えば、マルチメディアセッションの確立を完了する前に、エンドポイントは、対応するフローのためのRSVP予約を確立することを決定することができます。マルチメディアセッションが切断されたとき、同様に、エンドポイントは、対応するRSVP予約を破棄することを決定することができます。例えば、[RFC3312]はRSVP予約が非常にしっかりセッション制御のためのセッション開始プロトコル（SIP）（[RFC3261]）を使用してエンドポイントで同期させることができる方法について説明します。
When RSVP reservation establishment, maintenance, and teardown are to be handled by RSVP proxies on behalf of an RSVP sender or receiver, a key challenge for the RSVP proxy is to determine when the RSVP reservations need to be established, maintained, and torn down, and to determine what the characteristics are (bandwidth, QoS, etc.) of the required RSVP reservations matching the application requirements. We refer to this problem as the synchronization of RSVP reservations with application-level requirements.
RSVP予約の確立、維持、およびティアダウンをRSVP送信者または受信者に代わってRSVPプロキシによって処理されるときに、RSVPプロキシの主要な課題は、RSVP予約が確立維持され、解体される必要があるときを決定することです。およびアプリケーション要件に合致する必要RSVP予約の特性が何であるか（帯域幅のQoS、等）を決定します。私たちは、アプリケーション・レベルの要件にRSVP予約の同期として、この問題を参照してください。
The IETF Next Steps in Signaling (NSIS) working group has specified a new QoS signaling protocol: the QoS NSIS Signaling Layer Protocol (NSLP) ([RFC5974]). This protocol also includes the notion of proxy operation, and terminating QoS signaling on nodes that are not the actual data senders or receivers (see Section 4.8, "Proxy Mode", of [RFC5974]. This is the same concept as the proxy operation for RSVP discussed in this document. One difference, though, is that the NSIS framework does not consider multicast resource reservations, which RSVP provides today.
QoSのNSISシグナリング層プロトコル（NSLP）（[RFC5974]）：IETFシグナリングに次のステップ（NSIS）ワーキンググループは、シグナリングプロトコル新しいQoSを指定しています。 、「プロキシモード」、[RFC5974]このプロトコルはまた、プロキシ動作の概念を含み、実際のデータの送信者または受信機がないノード上でシグナリングを終端するQoSは（セクション4.8を参照。これは、のプロキシ動作と同じ概念でありますRSVPは、この文書で説明する。一つの違いは、しかし、NSISフレームワークが今日提供するRSVP、マルチキャストリソース予約を考慮していないということです。
Section 2 introduces the notion of RSVP Sender Proxy and RSVP Receiver Proxy. Section 3 defines useful terminology. Section 4 then presents several fundamental RSVP proxy approaches, discussing how they achieve the necessary synchronization of RSVP reservations with application-level requirements. Appendix A includes more detailed use cases for the proxies in various real-life deployment environments.
第2節では、RSVP送信者プロキシおよびRSVPレシーバープロキシの概念を導入しています。第3節では、便利な用語を定義します。第4章では、彼らは、アプリケーション・レベルの要件にRSVP予約の必要な同期を実現する方法を議論し、いくつかの基本的なRSVPプロキシのアプローチを提示します。付録Aは、様々な現実のデプロイメント環境でのプロキシのより詳細なユースケースを含んでいます。
It is important to keep in mind that the strongly recommended RSVP deployment model remains end-to-end as assumed in [RFC2205] with RSVP support on the sender and the receiver. The end-to-end model allows the most effective synchronization between the reservation and application requirements. Also, when compared to the end-to-end RSVP model, the use of RSVP proxies involves additional operational burden and/or imposes some topological constraints. The additional operational burden comes in particular from additional configuration needed to activate the RSVP proxies and to help them identify for which senders/receivers a proxy behavior is required and for which senders/receivers it is not (so that an RSVP proxy does not perform establishment of reservations on behalf of devices that are capable of doing so themselves but would then be prevented -- without notification -- from doing so by the RSVP proxy). The additional topological constraints come in particular from the requirement to have one RSVP Receiver Proxy on the path from any sender to every non-RSVP-capable device (so that a non-RSVP-capable device is always taken care of by an RSVP proxy) and the objective to have only one such Receiver Proxy on the path from any sender to every non-RSVP-capable device (so that an RSVP Receiver Proxy does not short-circuit another RSVP Receiver Proxy closer to the non-RSVP-capable device, thereby reducing the span of the RSVP reservation and the associated benefits). In the case of the Path-Triggered Receiver Proxy approach, the operational burden and topological constraints can be significantly alleviated using the mechanisms discussed in Section 4.1.1.
[RFC2205]で仮定として強く推奨RSVPの展開モデルは、送信者と受信者のRSVPサポートをエンド・ツー・エンドのままであることを心に留めておくことが重要です。エンドツーエンドモデルは、予約とアプリケーション要件の間に最も効果的な同期を可能にします。エンドツーエンドのRSVPのモデルと比較しても、RSVPプロキシの使用は、追加の作業負担を伴う、および/またはいくつかの位相幾何学的制約を課します。追加の作業負担はRSVPプロキシを有効にするには、それらをプロキシ動作が必要とされた送信者/受信者のためにそれはない（RSVPプロキシが設立を実行しないようにですされている送信者/受信者のために識別しやすくするために必要な追加の設定から特に来て通知なし - - RSVPプロキシによってそうすることから）自分自身そうすることが可能であるが、その後に防止することが考えデバイスの代わりに予約を。追加のトポロジー制約が（非RSVP対応デバイスは常にRSVPプロキシによって世話をされるように）すべての非RSVP対応デバイスへの任意の送信者からの経路上の一台のRSVP受信機プロキシを有することが必要で、特に来RSVP受信プロキシは、近い非RSVP対応デバイスへの短絡、他のRSVP受信プロキシないように目的は、すべての非RSVP対応デバイス（の任意の送信者からのパスにのみこのような受信機プロキシを持っていますこれにより、RSVP予約のスパンと関連する利益を）減らします。パス・トリガレシーバプロキシアプローチの場合には、演算負担やトポロジー制約が大幅セクション4.1.1で説明したメカニズムを使用して緩和することができます。
It is also worth noting that RSVP operations on end-systems are considerably simpler than on a router, and consequently that RSVP implementations on end-systems are very lightweight (particularly considering modern end-systems' capabilities, including mobile and portable devices). For example, end-system RSVP implementations are reported to only consume low tens of kilobytes of code space. Hence, this document should not be seen as an encouragement to depart from the end-to-end RSVP model. Its purpose is only to allow RSVP deployment in special environments where RSVP just cannot be used on some senders and/or some receivers for reasons specific to the environment.
また、エンドシステム上のRSVP操作を注目に値するのは、ルータ上よりもかなり簡単であり、そしてエンド・システム上で結果的にそのRSVPの実装では、（特にモバイルやポータブルデバイスを含む、最新のエンドシステムの能力を考慮して）非常に軽量です。例えば、エンドシステムRSVP実装は、コード空間のキロバイトの低い数十のみ消費することが報告されています。したがって、この文書は、エンドツーエンドのRSVPモデルから逸脱する奨励として見られるべきではありません。その目的は、唯一のRSVPはいくつかの送信者および/または環境に固有の理由でいくつかの受信機では使用できない特殊環境でのRSVPの展開を可能にすることです。
This section discusses the two types of proxies: the RSVP Sender Proxy operating on behalf of data senders, and the RSVP Receiver Proxy operating for data receivers. The concepts presented in this document are not meant to deprecate the traditional [RFC2205] RSVP end-to-end model: end-to-end RSVP reservations are still expected to be used whenever possible. However, RSVP proxies are intended to facilitate RSVP deployment where end-to-end RSVP signaling is not possible.
RSVP送信者プロキシは、データの送信者に代わって操作すると、RSVP受信側プロキシは、データ受信のために操作する：このセクションでは、プロキシの2種類について説明します。この文書で説明する概念は、伝統的な[RFC2205] RSVPエンドツーエンドモデルを廃止することを意味していない：エンドツーエンドのRSVP予約はまだ可能な限り使用されることが期待されています。しかし、RSVPプロキシは、エンドツーエンドのRSVPシグナリングが可能でないRSVPの展開を容易にするために意図されています。
With conventional end-to-end RSVP operations, RSVP reservations are controlled by receivers of data. After a data sender has sent an RSVP Path message towards the intended recipient(s), each recipient that requires a reservation generates a Resv message. If, however, a data receiver is not running the RSVP protocol, the last-hop RSVP router will still send the Path message to the data receiver, which will silently drop this message as an IP packet with an unknown protocol number.
従来のエンドツーエンドのRSVPの動作により、RSVP予約は、データの受信機によって制御されます。データ送信側は、意図された受信者（複数可）、予約がResvメッセージを生成し、必要とする各受信者に向かってRSVP Pathメッセージを送信した後に。しかし、データの受信機はRSVPプロトコルを実行していない、場合、最終ホップRSVPルータはまだ黙っ不明なプロトコル番号を持つIPパケットとして、このメッセージをドロップしますデータ受信、にPathメッセージを送信します。
In order for reservations to be made in such a scenario, one of the RSVP routers on the data path determines that the data receiver will not be participating in the resource reservation signaling and performs RSVP Receiver Proxy functionality on behalf of the data receiver. This is illustrated in Figure 1. Various mechanisms by which the RSVP proxy router can gain the required information are discussed later in the document.
このようなシナリオで行われるべき予約のためには、データパス上のRSVPルータの1つは、データ受信装置は、リソース予約シグナリングに参加しないことを決定し、データ受信の代わりにRSVP受信プロキシ機能を行います。これは、RSVPプロキシルータは、必要な情報を得ることができる1.様々な機構は、後の文書に記載されている。図に示されています。
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
===================RSVP==============>
***********************************************************>
***********************************************************>
|****| RSVP-capable |----| non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> unidirectional media flow ==> segment of flow path protected by RSVP reservation
***>一方向メディアフロー==>流路のセグメントRSVP予約により保護
Figure 1: RSVP Receiver Proxy
図1：受信プロキシをRSVP
With conventional end-to-end RSVP operations, if a data sender is not running the RSVP protocol, a resource reservation cannot be set up; a data receiver alone cannot reserve resources without Path messages first being received. Thus, even if the data receiver is running RSVP, it still needs some node on the data path to send a Path message towards the data receiver.
データ送信者がRSVPプロトコルを実行していない場合は、従来のエンドツーエンドのRSVPの動作により、リソース予約を設定することができません。データ受信装置だけは、最初に受信されたPathメッセージなしでリソースを予約することはできません。このように、データ受信機がRSVPを実行している場合でも、それはまだデータ受信機に向けてPathメッセージを送信するために、データパス上のいくつかのノードを必要とします。
In that case, an RSVP node on the data path determines that it should generate Path messages to allow the receiver to set up the resource reservation. This node is referred to as the RSVP Sender Proxy and is illustrated in Figure 2. This case presents additional challenges over the Receiver Proxy case, since the RSVP Sender Proxy must be able to generate all the information in the Path message (such as the SENDER_TSPEC object) without the benefit of having previously received any RSVP message. An RSVP Receiver Proxy, by contrast, only needs to formulate an appropriate Resv message in response to an incoming Path message. Mechanisms to operate an RSVP Sender Proxy are discussed later in this document.
その場合に、データ経路上のRSVPノードは、受信機が、リソース予約を設定できるようにするPathメッセージを生成すべきであると判断します。このノードは、RSVP送信側プロキシは、SENDER_TSPECとしてPathメッセージのすべての情報を（生成することができなければならないので、RSVP送信側プロキシと呼ばれ、図この場合は、受信プロキシケース上の追加の課題を提示2に示されています。以前に任意のRSVPメッセージを受信したことの利点なしでオブジェクト）。 RSVP受信プロキシは、対照的に、唯一の受信Pathメッセージに応答して、適切なResvメッセージを定式化する必要があります。 RSVP送信者のプロキシを操作するためのメカニズムは、このドキュメントの後半で説明されています。
|----| |**********| *** *** |****|
| S |---------| RSVP |---------*r*----------*r*----------| R |
|----| | Sender | *** *** |****|
| Proxy |
|**********|
================RSVP==================>
***********************************************************>
***********************************************************>
|----| non-RSVP-capable |****| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |****| *** router
***> unidirectional media flow
***>一方向のメディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
Figure 2: RSVP Sender Proxy
図2：RSVP送信者のプロキシ
o On-Path: located on the data path of the actual flow of application data (regardless of where it is located with respect to the application-level signaling path).
Oオンパス：（かかわらず、それはアプリケーション・レベルのシグナリング経路に対して位置する場所の）アプリケーションデータの実際のフローのデータパス上に位置します。
o Off-Path: not On-Path.
Oオフパス：ないオンパス。
o RSVP-capable (or RSVP-aware): supporting the RSVP protocol as per [RFC2205].
O-可能なRSVP（またはRSVP対応）：[RFC2205]に従ってRSVPプロトコルをサポートします。
o RSVP Receiver Proxy: an RSVP-capable router performing, on behalf of a receiver, the RSVP operations that would normally be performed by an RSVP-capable receiver if end-to-end RSVP signaling were used. Note that while RSVP is used upstream of the RSVP Receiver Proxy, RSVP is not used downstream of the RSVP Receiver Proxy.
、受信機の代わりに、エンドツーエンドのRSVPシグナリングが使用された場合、通常、RSVP対応受信機によって実行されるRSVP操作を行うRSVP対応ルータ：OレシーバプロキシRSVP。 RSVPは、RSVP受信プロキシの上流で使用されている間、RSVPは、RSVP受信プロキシの下流で使用されていないことに留意されたいです。
o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of a sender, the RSVP operations that would normally be performed by an RSVP-capable sender if end-to-end RSVP signaling were used. Note that while RSVP is used downstream of the RSVP Sender Proxy, RSVP is not used upstream of the RSVP Sender Proxy.
O RSVP送信者プロキシ：RSVP対応ルータが送信者に代わって、実行は、通常、RSVP-できる送信者によって実行されるRSVP操作は、エンドツーエンドのRSVPシグナリングが使用された場合。 RSVPは、RSVP送信者のプロキシの下流で使用されている間、RSVPは、RSVP送信側プロキシの上流で使用されていないことに留意されたいです。
o Regular RSVP Router: an RSVP-capable router that is not behaving as an RSVP Receiver Proxy or as an RSVP Sender Proxy.
O通常のRSVPルータ：RSVPレシーバープロキシとして、あるいはRSVP送信者のプロキシとして動作しないRSVP対応ルータ。
o Application-level signaling: signaling between entities operating above the IP layer and that are aware of the QoS requirements for actual media flows. SIP ([RFC3261]) and the Real Time Streaming Protocol (RTSP) ([RFC2326]) are examples of application-level signaling protocols. The Session Description Protocol (SDP) ([RFC4566]) is an example of a protocol that can be used by the application-level signaling protocol and from which some of the RSVP reservation parameters (addresses, ports, and bandwidth) might be derived. RSVP is clearly not an application-level signaling protocol.
Oアプリケーションレベルシグナリング：IP層以上で動作するエンティティ間のシグナリングと実際のメディアフローのためのQoS要件を認識しています。 SIP（[RFC3261]）及びリアルタイムストリーミングプロトコル（RTSP）（[RFC2326]）は、アプリケーション・レベルのシグナリングプロトコルの例です。セッション記述プロトコル（SDP）（[RFC4566]）は、アプリケーションレベルのシグナリングプロトコルによって、およびRSVP予約パラメータ（アドレス、ポート、および帯域幅）の一部が導出されるかもしれないから、使用することができるプロトコルの一例です。 RSVPは、明らかに、アプリケーション・レベルのシグナリング・プロトコルではありません。
The roles of the RSVP Receiver Proxy, RSVP Sender Proxy, and regular RSVP router are all relative to a given unidirectional flow. A given router may act as the RSVP Receiver Proxy for a flow, as the RSVP Sender Proxy for another flow, and as a regular RSVP router for yet another flow.
RSVPレシーバープロキシ、RSVP送信者プロキシ、および通常のRSVPルータの役割が与えられたすべての一方向の流れを基準にしています。特定のルータは、他のフローに対するRSVP送信側プロキシとして、さらに別の流れのための定期的なRSVPルータとして、フローに対するRSVP受信プロキシとして働くことができます。
Some application-level signaling protocols support negotiation of QoS reservations for a media stream. For example, with [RFC3312], resource reservation requirements are explicitly signaled during session establishment using SIP and SDP. Also, [RFC5432] defines a mechanism to negotiate which resource reservation mechanism is to be used for a particular media stream. Clearly, these reservation negotiation mechanisms can be invoked and operate effectively when both ends support RSVP (and obviously RSVP proxies are not used). When both ends do not support RSVP (and RSVP proxies are used at both ends), these mechanisms will simply not be invoked. In the case where one end supports RSVP and the other does not (and is helped by an RSVP proxy), the application-level signaling entity supporting the non-RSVP-capable end might use the reservation negotiation mechanisms in such a way that the non-RSVP-capable end (helped by an RSVP proxy) appears to the remote end as an RSVP-capable device. This will ensure that the RSVP-capable end is not discouraged from using RSVP because the remote end is not RSVP-capable. In the case of SIP, the application-level entity may achieve this by taking advantage of the "segmented" status type of [RFC3312] and/or by taking advantage of a SIP [RFC3261] Back-to-Back User Agent (B2BUA).
いくつかのアプリケーションレベルのシグナリングプロトコルは、メディアストリームのためのQoS予約のネゴシエーションをサポートしています。例えば、[RFC3312]と、リソース予約要求は、明示的にSIP及びSDPを使用してセッション確立中にシグナリングされます。また、[RFC5432]は、特定のメディア・ストリームのために使用されるべきリソース予約メカニズム交渉するためのメカニズムを定義します。明らかに、これらの予約交渉メカニズムを呼び出すことができ、両方ともサポートRSVPを終了する（そして明らかにプロキシが使用されていないRSVP）ときに効果的に動作。両端がRSVPをサポートしていない（とRSVPプロキシは、両端で使用されている）場合、これらのメカニズムは単に呼び出されません。非ように予約交渉メカニズムを使用するかもしれない非RSVP対応端部を支持するアプリケーション・レベルのシグナリングエンティティ一端がRSVPをサポートし、他にはない（とRSVPプロキシによって助けられる）場合-RSVP対応端（RSVPプロキシによって助け）RSVP対応デバイスなどの遠隔端に現れます。これは、リモートエンドがRSVP対応されていないため、RSVP対応端部がRSVPを使用することから推奨されていないことを保証します。 SIPの場合には、アプリケーションレベルのエンティティは、[RFC3312]及び/またはSIPを利用して、[RFC3261]のステータスタイプを「セグメント」バックツーバックユーザエージェント（B2BUA）を利用することによって、これを達成することができます。
This section discusses fundamental RSVP proxy approaches.
このセクションでは、基本的なRSVPプロキシアプローチについて説明します。
In this approach, it is assumed that the sender is RSVP-capable and takes full care of the synchronization between application requirements and RSVP reservations. With this approach, the RSVP Receiver Proxy uses the RSVP Path messages generated by the sender as the cue for establishing the RSVP reservation on behalf of the receiver. The RSVP Receiver Proxy is effectively acting as a slave making reservations (on behalf of the receiver) under the sender's control. This changes somewhat the usual RSVP reservation model where reservations are normally controlled by receivers. Such a change greatly facilitates operations in the scenario of interest here, which is where the receiver is not RSVP-capable. Indeed, it allows the RSVP Receiver Proxy to remain application-unaware by taking advantage of the application awareness and RSVP awareness of the sender.
このアプローチでは、送信者がRSVP-ことが可能であり、アプリケーションの要件とRSVP予約の間の同期をフルに世話をすることが想定されます。このアプローチでは、RSVPレシーバープロキシは、受信機に代わってRSVP予約を確立するための手がかりとして、送信者によって生成されたRSVPのPathメッセージを使用しています。 RSVPレシーバープロキシが効果的に送信者の制御下で、（受信機に代わって）スレーブ作りの予約として機能しています。これは、やや予約が正常に受信機によって制御されている通常のRSVP予約モデルを変更します。そのような変化が大きく、受信機は、RSVP-ことができない場合であり、ここで関心のあるシナリオの動作を容易にします。確かに、それはRSVPレシーバープロキシが送信元のアプリケーション認識およびRSVP意識を利用することによって、アプリケーション気づかないままにすることができます。
With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router may be configured to use receipt of a regular RSVP Path message as the trigger for RSVP Receiver Proxy behavior.
パス・トリガRSVP受信プロキシアプローチで、RSVPルータはRSVP受信プロキシ動作のトリガとして正規RSVP Pathメッセージの受信を使用するように構成されてもよいです。
On receipt of the RSVP Path message, the RSVP Receiver Proxy:
RSVP Pathメッセージ、RSVPレシーバープロキシを受信します：
4. behaves as if a Resv message (whose details are discussed below) was received on the downstream interface. This includes performing admission control on the downstream interface, establishing a Resv state (in case of successful admission control), and forwarding the Resv message upstream, sending periodic refreshes of the Resv message and tearing down the reservation if the Path state is torn down.
4.振る舞うかのように（その詳細は以下で議論される）ダウンストリームインターフェイス上で受信されたResvメッセージ。これは（成功したアドミッション制御の場合）のResv状態を確立し、ダウンストリームインターフェイスにアドミッション制御を行い、上流のResvメッセージを転送し、Resvメッセージの定期的なリフレッシュを送信し、パス状態が切断された場合、予約を切断含みます。
In order to build the Resv message, the RSVP Receiver Proxy can take into account information received in the Path message. For example, the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv message that mirrors the SENDER_TSPEC object in the received Path message (as an RSVP-capable receiver would typically do).
Resvメッセージを構築するために、RSVP受信側プロキシは、Pathメッセージで受信したアカウント情報を考慮に入れることができます。例えば、RSVP受信プロキシ（RSVP対応レシーバ典型的だろうとして）受信したPathメッセージにSENDER_TSPECオブジェクトをミラーのResvメッセージのFLOWSPECオブジェクトを構成することができます。
Operation of the Path-Triggered Receiver Proxy in the case of a successful reservation is illustrated in Figure 3.
成功した予約の場合には経路トリガレシーバプロキシの動作は、図3に示されています。
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
---Path---> ----Path----> ---Path---->
<--Resv---> <---Resv----- <--Resv----
==================RSVP===============>
**********************************************************>
**********************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
Figure 3: Path-Triggered RSVP Receiver Proxy
図3：パス・トリガRSVPレシーバープロキシ
In case the reservation establishment is rejected (for example, because of an admission control failure on a regular RSVP router on the path between the RSVP-capable sender and the RSVP Receiver Proxy), a ResvErr message will be generated as per conventional RSVP operations and will travel downstream towards the RSVP Receiver Proxy. While this ensures that the RSVP Receiver Proxy is aware of the reservation failure, conventional RSVP procedures do not cater to the notification of the sender of the reservation failure. Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure is illustrated in Figure 4.
場合の予約の確立を（例えばためRSVP対応の送信側とRSVP受信プロキシとの間の経路上の正規RSVPルータのアドミッション制御不良）拒否され、ResvErrメッセージは、従来のRSVP操作に従って生成され、 RSVPレシーバープロキシに向けて下流に移動します。これはRSVPレシーバープロキシが予約失敗を認識していることを保証しますが、従来のRSVP手順は、予約の失敗の送信者の通知に応えていません。アドミッション制御に失敗した場合の経路トリガRSVP受信プロキシの動作は、図4に示されています。
|****| *** *** |**********| |----|
| S |---------*r*----------*r*---------| RSVP |----------| R |
|****| *** *** | Receiver | |----|
| Proxy |
|**********|
---Path---> ----Path----> ---Path---->
<---Resv----- <--Resv------
---ResvErr---> --ResvErr--->
===================RSVP===============>
**********************************************************>
**********************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
Figure 4: Path-Triggered RSVP Receiver Proxy with Failure
図4：失敗してパス・トリガRSVPレシーバープロキシ
Since, as explained above, in this scenario involving the RSVP Receiver Proxy, synchronization between an application and an RSVP reservation is generally performed by the sender, notifying the sender of reservation failure is needed. [RFC5946] specifies RSVP extensions allowing such sender notification in the case of reservation failure in the presence of a Path-Triggered RSVP Receiver Proxy.
RSVP受信プロキシが関与するこのシナリオでは、上述したように、あるので、アプリケーションおよびRSVP予約の間の同期は、一般に、予約の失敗の送信者が必要とされる通知、送信者によって行われます。 [RFC5946]はパス・トリガRSVP受信プロキシの存在下での予約に失敗した場合に、送信者の通知を可能にするRSVP拡張を指定します。
The presence in the flow path of a Path-Triggered RSVP Receiver Proxy (for a given flow) that strictly behaves as described previously would cause the Path message to be terminated and a Resv message to be generated towards the sender. When the receiver is indeed not RSVP-capable and there is no other RSVP Receiver Proxy downstream on the flow path, this achieves the best achievable result of establishing an RSVP reservation as far downstream as the RSVP Receiver Proxy.
パス・トリガ（所定のフローのための）RSVP受信プロキシ前述のように厳密に振る舞うの流路内の存在は、Pathメッセージを終了するとResvメッセージが送信者に向かって発生させるであろう。受信機が実際にRSVP対応ではなく、他のRSVP受信プロキシが流路のダウンストリームが存在しない場合、これは限り下流RSVP受信プロキシとしてRSVP予約を確立するための最良の達成可能な結果を達成します。
However, if the eventual receiver was in fact RSVP-capable, it would be prevented from participating in RSVP signaling, since it does not receive any Path message. As a result, the RSVP reservation would only span a subset of the path it could actually span. A similar sub-optimality would exist with multiple Receiver Proxies in the path of the flow: the first Receiver Proxy may prevent the Path message from reaching the second one and therefore prevent the reservation from extending down to the second Receiver Proxy.
最終的な受信機は、実際のRSVP対応であった場合は、それが任意のPathメッセージを受信しないので、RSVPシグナリングに参加することが防止されることになります。その結果、RSVP予約は、それが実際にまたがる可能性があり、パスのサブセットに及ぶでしょう。同様の準最適フローのパスに複数の受信プロキシで存在するであろう：第1の受信機プロキシは、第1に到達するPathメッセージを防止し、従って、第2の受信プロキシまで延びるの予約を防止することができます。
It is desirable that, in the presence of Path-Triggered RSVP Receiver Proxies and of a mix of RSVP-capable and non-RSVP-capable receivers, the RSVP reservation spans as much of the flow path as possible. This can be achieved dynamically (avoiding tedious specific configuration), using the mechanisms described in Sections 4.1.1.1 and 4.1.1.2.
パス・トリガRSVP受信プロキシのとRSVP-可能と非RSVP対応受信機の混合物の存在下で、RSVP予約が可能な限り流路だけに及ぶ、ことが望ましいです。これは、セクション4.1.1.1および4.1.1.2に説明されたメカニズムを使用して、動的に（退屈な具体的な構成を回避する）を達成することができます。
When generating a proxy Resv message upstream, a Receiver Proxy may be configured to perform dynamic discovery of downstream RSVP functionality. To that end, when generating the proxy Resv message upstream, the Receiver Proxy forwards the Path message downstream instead of terminating it. This allows an RSVP-capable receiver (or a downstream Receiver Proxy) to respond to the Path with an upstream Resv message. On receipt of a Resv message, the Receiver Proxy internally converts its state from a proxied reservation to a regular midpoint RSVP behavior. From then on, everything proceeds as if the RSVP router had behaved as a regular RSVP router at reservation establishment (as opposed to having behaved as an RSVP Receiver Proxy for that flow).
上位プロキシResvメッセージを生成する際、レシーバプロキシは、下流RSVP機能の動的な発見を実行するように構成されてもよいです。上位プロキシResvメッセージを生成する際に、その端部に、受信プロキシではなく、それを終端する下流Pathメッセージを転送します。これは、RSVP対応受信機（またはダウンストリーム受信プロキシ）は、上流Resvメッセージのパスに応答することを可能にします。 Resvメッセージを受信すると、受信側プロキシは、内部的に、通常の中間点RSVPの振る舞いにプロキシ予約からその状態を変換します。 RSVPルータは（その流れのためのRSVPレシーバープロキシとして振る舞ったとは反対に）予約成立で、通常のRSVPルータとして振る舞っていたかのようにその時から、すべてが進行します。
The RSVP Receiver Proxy behavior for dynamic discovery of downstream RSVP functionality is illustrated in Figure 5 and is also discussed in Section 4.1 of [RFC5946].
下流RSVP機能を動的に発見するためのRSVP受信プロキシの動作は、図5に示されており、また、[RFC5946]のセクション4.1で議論されています。
|****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----|
| Proxy |
| |
| | |****|
| |------------| R2 |
|**********| |****|
---Path---> --Path--->
(R1) (R1) \-------Path-->
/ (R1)
<--Resv--- <---Resv---
================RSVP===>
**************************************>
**************************************>
---Path---> --Path--->
(R2) (R2) \-------------Path---->
/ (R2)
<--Resv--- <---Resv---
<----Resv---
================RSVP===========================>
***********************************************>
***********************************************>
|****| RSVP-capable |----| non-RSVP-capable |****| RSVP-capable
| S | Sender | R | Receiver | R | Receiver
|****| |----| |****|
*** *r* regular RSVP *** router
*** * R *通常のRSVPルータ***
(R1) = Path message contains a Session object whose destination is R1
（R1）は= Pathメッセージは、その宛先R1されたセッションオブジェクトを含みます
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
Figure 5: Dynamic Discovery of Downstream RSVP Functionality
図5：ダウンストリームのRSVP機能の動的検出
This dynamic discovery mechanism has the benefit that new (or upgraded) RSVP endpoints will automatically and seamlessly be able to take advantage of end-to-end reservations, without impacting the ability of a Receiver Proxy to proxy RSVP for other, non-RSVP-capable endpoints. This mechanism also achieves the goal of automatically discovering the longest possible RSVP-supporting segment in a network with multiple Receiver Proxies along the path. This mechanism dynamically adjusts to any topology and routing change. Also, this mechanism dynamically handles the situation in which a receiver was RSVP-capable and for some reason (e.g., software downgrade) no longer is. Finally, this approach requires no new RSVP protocol extensions and no configuration changes to the Receiver Proxy as new RSVP-capable endpoints come and go.
この動的な検出メカニズムは、新しい（またはアップグレード）RSVPエンドポイントが自動的かつシームレスその他、非RSVP-の代理RSVPにレシーバープロキシの能力に影響を与えることなく、エンド・ツー・エンドの予約を利用することができます利点を持っています対応エンドポイント。この機構はまた、自動的に経路に沿って複数の受信プロキシを使用してネットワーク内の最長の可能RSVP-支持セグメントを発見するという目標を達成します。このメカニズムは、動的に任意のトポロジとルーティングの変更に調整されます。また、この機構は、動的にもはや受信機は、RSVP-可能であり、何らかの理由（例えば、ソフトウェアダウングレード）する状況を取り扱います。新しいRSVP対応エンドポイントが来て、行くように最後に、このアプローチは、新たなRSVPプロトコル拡張およびレシーバープロキシの設定なしに変更する必要はありません。
The only identified drawbacks to this approach are:
このアプローチには唯一の識別の欠点は以下のとおりです。
o If admission control fails on the segment between the Receiver Proxy and the RSVP-capable receiver, the receiver will get a ResvErr and can take application-level signaling steps to terminate the call. However, the Receiver Proxy has already sent a Resv upstream for this flow, so the sender will see a "false" reservation that is not truly end-to-end. The actual admission control status will resolve itself in a short while, but the sender will need to roll back any permanent action (such as billing) that may have been taken on receipt of the phantom Resv. Note that if the second receiver is also a Receiver Proxy that is not participating in application signaling, it will convert the received ResvErr into a PathErr that will be received by the sender.
アドミッション制御は、レシーバプロキシおよびRSVP-可能な受信機との間のセグメント上に失敗した場合はO、受信機は、ResvErrを取得し、通話を終了するために、アプリケーション・レベルシグナリング手順を取ることができます。しかし、レシーバープロキシは、すでにこの流れのために上流のResvを送信しているので、送信者は、真にエンドツーエンドではない「偽」の予約が表示されます。実際のアドミッションコントロールの状態はしばらくして自分自身を解決しますが、送信者は、ファントムのResvの受信時に取られている可能性があり（例えば、課金など）任意の恒久的なアクションをロールバックする必要があります。第2の受信機はまた、アプリケーションシグナリングに参加していない受信機プロキシである場合、それは、送信者によって受信されたPathErrに受信されたResvErrを変換することに注意してください。
o If there is no RSVP-capable receiver (or other Receiver Proxy) downstream of the Receiver Proxy, then the Path messages sent by the Receiver Proxy every RSVP refresh interval (e.g., 30 seconds by default) will never be responded to. However, these messages consume a small amount of bandwidth, and in addition would install some RSVP state on RSVP-capable midpoint nodes downstream of the first Receiver Proxy. This is seen as a very minor sub-optimality. We also observe that such resources would be consumed anyways if the receiver was RSVP-capable. Still, if deemed necessary, to mitigate this, the Receiver Proxy can tear down any unanswered downstream Path state and stop sending Path messages for the flow (or only send them at much lower frequency) as further discussed in [RFC5946].
レシーバープロキシの下流何RSVP対応の受信機（または他のレシーバープロキシ）が存在しない場合は、O、その後、レシーバープロキシによってすべてのRSVPのリフレッシュ間隔を送ったPathメッセージは、（例えば、デフォルトでは30秒）に対応することはありません。しかしながら、これらのメッセージは、帯域幅の小さな量を消費し、加えて、第1の受信プロキシの下流RSVP対応中点のノードでいくつかのRSVP状態をインストールします。これは非常にマイナーな準最適と見られています。また、受信機がRSVP-ことができたならば、そのようなリソースがとにかく消費されることを確認します。依然として、これを緩和するために、必要と認める場合、受信機プロキシは、さらに、[RFC5946]で説明した（または唯一のそれらをはるかに低い周波数を送信する）任意の未回答の下流路状態を切断し、フローのためのPathメッセージの送信を停止することができます。
An RSVP Receiver Proxy can be selective about the sessions that it terminates, based on local policy decision. For example, an edge router functioning as a Receiver Proxy may behave as a proxy only for Path messages that are actually going to exit the domain in question, and not for Path messages that are transiting through it but stay within the domain. As another example, the Receiver Proxy may be configurable to only proxy for flows addressed to a given destination address or destination address ranges (for which end devices are known to not be RSVP-capable).
RSVPレシーバープロキシは、ローカルの政策決定に基づいて、それが終了したセッションについて選択することができます。例えば、レシーバープロキシとして機能エッジルータは、実際に問題になっているドメインを終了しようとしているPathメッセージのためのプロキシとして動作し、ないそれを介して通過しているPathメッセージのためではなく、ドメイン内にとどまることがあります。フローが与えられた宛先アドレスまたは宛先アドレス範囲（れるエンドデバイスがRSVP-ことができないことが知られている）にアドレス指定するための別の例として、受信プロキシは、プロキシの構成であってもよいです。
The decision to proxy a Resv for a Path may also be based on information signaled from the sender in the Path message. For example, the sender may identify the type of application or flow in the Application Identity policy element ([RFC2872]) in the Path, and the Receiver Proxy may be configured to proxy for only certain types of flows. Or, if the sender knows (for example, through application signaling) that the receiver is RSVP-capable, the sender can include an indication in a policy element to any Receiver Proxy that it ought not to terminate the Path (or conversely, if the receiver is known not to support RSVP, the sender could include an indication to Receiver Proxies that they ought to generate a proxy Resv message). The Receiver Proxy Control policy element specified in Section 4.2 of [RFC5946] can be used for that purpose.
パスのプロキシのResvの決定はまた、Pathメッセージ内の送信者からのシグナリング情報に基づくことができます。例えば、送信者は、アプリケーションの種類を識別することができるか、パスのアプリケーションIDポリシーエレメント（[RFC2872]）に流れ、レシーバプロキシフローのみ、特定のタイプのプロキシを構成することができます。あるいは、送信側は受信側がRSVP対応である場合、送信者は、それが逆パス（または終了するべきではないことは、任意の受信プロキシにポリシー要素に指示を含むことができること（例えば、アプリケーションシグナリングを介して）知っている場合受信機は、送信者が、彼らは）プロキシResvメッセージを生成するべきであることを受信プロキシに指示を含むことができる、RSVPをサポートしないことが知られています。 [RFC5946]のセクション4.2で指定された受信側プロキシ制御ポリシーエレメントは、その目的のために使用することができます。
In this approach, it is assumed that one endpoint is RSVP-capable and takes full care of the synchronization between application requirements and RSVP reservations. This endpoint is the sender for one flow direction (which we refer to as the "forward" direction) and is the receiver for the flow in the opposite direction (which we refer to as the "reverse" direction).
このアプローチでは、一方のエンドポイントがRSVP-可能であり、アプリケーションの要件とRSVPの予約の間の同期を最大限に世話をすることが想定されます。このエンドポイントは、（我々が「前方」方向と呼ぶ）つの流れ方向のために送信者であり、（我々が「逆」方向と呼ぶ）と反対方向の流れのための受信機です。
With the Path-Triggered Sender Proxy for Reverse Direction approach, the RSVP proxy uses the RSVP signaling generated by the receiver (for the reverse direction) as the cue for initiating RSVP signaling for the reservation in the reverse direction. More precisely, the RSVP proxy can take the creation (or maintenance or teardown) of a Path state by the receiver as the cue to create (or maintain or tear down, respectively) a Path state towards the receiver. Thus, the RSVP proxy is effectively acting as a Sender Proxy for the reverse direction under the control of the receiver (for the reverse direction). Note that this assumes a degree of symmetry, for example, in terms of bandwidth for the two directions of the flow (as is currently typical for IP telephony).
逆方向のアプローチのためのパス・トリガ送信側プロキシで、RSVPプロキシは逆方向の予約のためのシグナリングRSVPを開始するためのキューとして（逆方向の場合）受信機によって生成されたRSVPシグナリングを使用します。より正確には、RSVPプロキシは、受信機に向かって（それぞれ、または維持するか、または破棄）を作成するキューとして受信機によってパスの状態を、パス状態の作成（又はメンテナンス又はティアダウン）をとることができます。したがって、RSVPプロキシを効果（逆方向の場合）受信機の制御の下で、逆方向の送信者のプロキシとして機能しています。例えば、流れの二つの方向のための帯域幅の点で（現在のIPテレフォニーのための典型的であるように）、これは対称性の程度を想定しています。
The signaling flow for the Path-Triggered Sender Proxy for Reverse Direction is illustrated in Figure 6.
逆方向のパス・トリガ送信元プロキシのためのシグナリング・フローは図6に示されています。
Path messages generated by the receiver need to transit via the RSVP Sender Proxy that is on the path from the sender to the receiver. In some topologies, this will always be the case: for example, where the sender is on a stub network hanging off the RSVP Sender Proxy or where there is no asymmetric routing (such that if an RSVP Sender Proxy is on the path from receiver to sender, then it is also on the path from sender to receiver). In some topologies (such as those involving asymmetric routing), this may not always happen naturally. Measures to ensure this does happen in these topologies are outside the scope of this document.
受信機によって生成されたPathメッセージは、送信側から受信側へのパス上にあるRSVP送信者のプロキシを経由して輸送する必要があります。一部のトポロジでは、これは常にそうであろう：例えば、送信者がRSVP送信者プロキシまたはここ全く非対称ルーティングがないオフぶら下がっスタブ・ネットワーク上にある場合（RSVP送信側プロキシが受信機からのパス上にある場合、このようなこと送信者は、それは）送信者から受信者のパスでもあります。 （例えば、非対称ルーティングを伴うものなど）いくつかのトポロジでは、これは常に自然に発生しないことがあります。これは、これらのトポロジで起こるん確保するための措置は、この文書の範囲外です。
|****| *** *** |**********| |----|
| R |---------*r*----------*r*---------| RSVP |----------| S |
|****| *** *** | Sender | |----|
| Proxy |
|**********|
---Path---> ----Path----> ---Path---->
<--Path---> <---Path----- <--Path----
---Resv---> ----Resv----> ---Resv---->
<================RSVP==================
<**********************************************************
<**********************************************************
|****| RSVP-capable |----| Non-RSVP-capable ***
| R | Receiver for | S | Sender for *r* regular RSVP
|****| reverse direction |----| reverse direction *** router
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation in reverse direction
==>流路のセグメント逆方向RSVP予約により保護
Figure 6: Path-Triggered Sender Proxy for Reverse Direction
図6：逆方向のパス・トリガ送信者のプロキシ
Of course, the RSVP proxy may simultaneously (and typically will) also act as the Path-Triggered Receiver Proxy for the forward direction, as defined in Section 4.1. Such an approach is most useful in situations involving RSVP reservations in both directions for symmetric flows. This is illustrated in Figure 7.
もちろん、RSVPプロキシは、同時にまた、セクション4.1で定義されるように、順方向のパス・トリガレシーバプロキシとして作用する（そして典型的に）してもよいです。そのようなアプローチは、対称フローの両方向でRSVP予約を伴う状況で最も有用です。これは、図7に示されています。
|****| *** *** |----------| |----|
|S/R |---------*r*----------*r*---------| RSVP |----------|S/R |
|****| *** *** | Receiver | |----|
| & Sender |
| Proxy |
|----------|
---Path---> ----Path----> ---Path---->
<--Resv---> <---Resv----- <--Resv----
<--Path---> <---Path----- <--Path----
---Resv---> ----Resv----> ---Resv---->
================RSVP==================>
<================RSVP==================
**********************************************************> <**********************************************************
**********************************************************> <**********************************************************
|****| RSVP-capable |----| Non-RSVP-capable ***
|S/R | Sender and |S/R | Sender and *r* regular RSVP
|****| Receiver |----| Receiver *** router
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation in forward and in reverse direction
順方向および逆方向RSVP予約により保護さ流路の==>セグメント
Figure 7: Path Triggered Receiver and Sender Proxy
図7：パストリガーReceiverとSenderプロキシ
With the Path-Triggered Sender Proxy for Reverse Direction approach, the RSVP router may be configurable to use receipt of a regular RSVP Path message as the trigger for Sender Proxy for Reverse Direction behavior.
逆方向のアプローチのためのパス・トリガ送信者のプロキシで、RSVPルータは逆方向動作用送信元プロキシのためのトリガーとして、通常のRSVP Pathメッセージの受信を使用するように構成可能です。
On receipt of the RSVP Path message for the forward direction, the RSVP Sender Receiver Proxy:
順方向、RSVPセンダレシーバプロキシのRSVP Pathメッセージを受信します：
2. behaves as if a Path message for the reverse direction (whose details are discussed below) had been received by the Sender Proxy. This includes establishing the corresponding Path state, forwarding the Path message downstream, sending periodic refreshes of the Path message, and tearing down the Path in the reverse direction when the Path state in the forward direction is torn down.
2.振る舞う（詳細は以下で議論される）逆方向のパスメッセージは、送信者のプロキシによって受信されたかのように。これは、対応する経路状態を確立するPathメッセージの定期的な更新を送信し、下流のPathメッセージを転送し、順方向のパス状態が切断されたときに、逆方向のパスを切断含みます。
In order to build the Path message for the reverse direction, the RSVP Sender Proxy can take into account information in the received Path message for the forward direction. For example, the RSVP Sender Proxy may mirror the SENDER_TSPEC object in the received Path message.
逆方向のパスメッセージを構築するために、RSVP送信者プロキシは、順方向のため、受信したPathメッセージにアカウント情報を考慮に入れることができます。例えば、RSVP送信側プロキシは、受信したPathメッセージにSENDER_TSPECオブジェクトを反映することができます。
We observe that this approach does not require any extensions to the existing RSVP protocol.
私たちは、このアプローチは、既存のRSVPプロトコルへの拡張を必要としないことを確認します。
In the case where reservations are required in both directions (as shown in Figure 7), the RSVP-capable device simply needs to behave as a regular RSVP sender and RSVP receiver. It need not be aware that an RSVP proxy happens to be used, and the Path message it sent for the forward reservation also acts as the trigger for establishment of the reverse reservation. However, in the case where a reservation is only required in the reverse direction (as shown in Figure 6), the RSVP-capable device has to generate Path messages in order to trigger the reverse-direction reservation even if no reservation is required in the forward direction. Although this is not in violation of [RFC2205], it may not be the default behavior of an RSVP-capable device and therefore may need a behavioral change specifically to facilitate operation of the Path-Triggered Sender Proxy for Reverse Direction.
（図7に示すように）予約が両方向に必要とされる場合に、RSVP対応デバイスは、単に定期的なRSVP送信側とRSVP受信機として動作する必要があります。これは、RSVPプロキシが使用されるように発生し、それが前方に予約するために送られたPathメッセージは、逆の予約の確立のためのトリガーとして作用することを意識する必要はありません。しかし、（図6に示すように）予約だけ逆方向に必要とされる場合に、RSVP対応デバイスには予約に必要とされない場合であっても逆方向予約をトリガするために、Pathメッセージを生成しなければなりません順方向。これは[RFC2205]に違反していないが、RSVP対応デバイスのデフォルトの動作ではないかもしれない、したがって、逆方向のパス・トリガ送信元プロキシの動作を容易にするために、具体的な行動変化を必要とするかもしれません。
In this approach, it is assumed that the RSVP proxy is on the data path of "packets of interest", that it can inspect such packets on the fly as they transit through it, and that it can infer information from these packets of interest to determine what RSVP reservations need to be established, as well as when and with what characteristics (possibly also using some configured information).
このアプローチでは、RSVPプロキシは、それを通ってそれらのトランジットとしてオンザフライでこのようなパケットを検査することができることを、「関心のパケット」のデータ・パス上にあり、そしてそれが関心のあるこれらのパケットからの情報を推測することができることと仮定されます予約が確立される必要があるだけでなく、ときにどのような特性（おそらく、いくつかの構成情報を使用して）とどのRSVP決定します。
One example of "packets of interest" could be application-level signaling. An RSVP proxy capable of inspecting SIP signaling for a multimedia session or RTSP signaling for video streaming can obtain from such signaling information about when a multimedia session is up or when a video is going to be streamed. It can also identify the addresses and ports of senders and receivers and can determine the bandwidth of the corresponding flows. It can also determine when the reservation is no longer needed and tear it down. Thus, such an RSVP proxy can determine all necessary information to synchronize RSVP reservations to application requirements. This is illustrated in Figure 8.
「対象パケット」の一例は、アプリケーションレベルのシグナルである可能性があります。ビデオストリーミングのためのマルチメディアセッションやRTSPシグナリングのためにSIPシグナリングを検査できるRSVPプロキシは、マルチメディアセッションがアップしているとき、またはビデオがストリーミングされようとしているとき。について、このようなシグナリング情報から取得することができますまた、送信者と受信者のアドレスおよびポートを識別することができ、対応するフローの帯域幅を決定することができます。また、予約が不要になったときに決定していないし、それを取り壊すことができます。したがって、そのようなRSVPプロキシは、アプリケーション要件にRSVP予約を同期させるために必要なすべての情報を決定することができます。これは図8に示されています。
|-------------|
| Application |
| Signaling |
| Entity |
|-------------|
/ \
/ \
/ \
</////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\>
|----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----|
|********| |********|
=======RSVP=======>
======= ======= RSVP>
********************************************************>
********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
</\> application-level signaling
</ \>アプリケーションレベルのシグナリング
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
Figure 8: Inspection-Triggered RSVP Proxy
図8：点検・トリガRSVPプロキシ
Another example of "packets of interest" could be transport control messages (e.g., the Real-time Transport Control Protocol (RTCP) [RFC3550]) traveling alongside the application flow itself (i.e., media packets). An RSVP proxy capable of detecting the transit of packets from a particular flow can attempt to establish a reservation corresponding to that flow. Characteristics of the reservation may be derived by various methods such as from configuration, flow measurement, or a combination of those. However, these methods usually come with their respective operational drawbacks: configuration involves an operational cost and may hinder introduction of new applications, and measurement is reactive so that accurate reservation may lag actual traffic.
「関心のパケット」の別の例は、トランスポート制御メッセージとすることができる（例えば、リアルタイムトランスポート制御プロトコル（RTCP）[RFC3550]）アプリケーションと一緒に走行自体（すなわち、メディアパケット）を流れます。特定のフローからのパケットの通過を検出することができるRSVPプロキシはそのフローに対応する予約を確立しようと試みることができます。予約の特性は、このような構成により、流量測定、またはそれらの組合せからなどの様々な方法によって誘導することができます。しかし、これらの方法は、通常、それぞれの業務の欠点が付属しています：構成は、運用コストを伴い、新しいアプリケーションの導入を妨げる可能性があり、正確な予約は、実際のトラフィックを遅らせることができるように、測定は、反応性です。
In the case of reservation failure, the Inspection-Triggered RSVP Proxy does not have a direct mechanism for notifying the application (since it is not participating itself actively in application signaling) so that the application is not in a position to take appropriate action (for example, terminate the corresponding session). To mitigate this problem, the Inspection-Triggered RSVP Proxy may differently mark the Differentiated Services codepoint (DSCP) ([RFC2474]) of flows for which an RSVP reservation has been successfully proxied from the flows for which a reservation is not in place. In some situations, the Inspection-Triggered Proxy might be able to modify the "packets of interest" (e.g., application signaling messages) to convey some hint to applications that the corresponding flows cannot be guaranteed by RSVP reservations.
（これはアプリケーションシグナリングに積極的に自分自身を参加していないため）、アプリケーションが（に適切な行動を取る位置にないように予約失敗した場合に、検査トリガRSVPプロキシは、アプリケーションに通知するための直接的なメカニズムを持っていません例えば、対応するセッションを終了します）。この問題を軽減するため、点検・トリガRSVPプロキシが異なりRSVP予約が正常に予約が所定の位置にされていないフローからプロキシされたフローの差別化サービスコードポイント（DSCP）（[RFC2474]）をマークすることができます。いくつかの状況では、検査トリガプロキシは、対応するフローは、RSVP予約によって保証することができないアプリケーションにいくつかのヒントを伝えるために、「対象パケット」（例えば、アプリケーションシグナリングメッセージ）を変更することができるかもしれません。
With the Inspection-Triggered Proxy approach, the RSVP proxy is effectively required to attempt to build application awareness by traffic inspection and then is somewhat limited in the actions it can take in case of reservation failure. Depending on the "packets of interest" used by the RSVP proxy to trigger the reservation, there is a risk that the RSVP proxy will end up establishing a reservation for a media flow that actually never starts. However, this can be mitigated by the timing out and tearing down of an unnecessary reservation by the RSVP proxy when no corresponding media flow is observed. This flow observation and timeout approach can also be used to tear down reservations that were rightfully established for a flow but are no longer needed because the flow stopped.
検査トリガ型プロキシのアプローチでは、RSVPプロキシが効果的にトラフィック検査によって、アプリケーション認識を構築しようとするために必要とされ、その後、それが予約失敗した場合に実行できるアクションにはやや限られています。予約をトリガするためにRSVPプロキシで使用される「対象パケット」に応じて、RSVPプロキシが実際に開始決してメディアフローの予約を確立終わるおそれがあります。しかしながら、これは、タイミングによって軽減することができ、該当するメディアフローが観察されないときにRSVPプロキシによって不要な予約の解体します。この流れの観察とタイムアウトアプローチも当然の流れのために確立されなかったが、流れが停止したため、もはや必要とされている予約を取り壊すために使用することができます。
The Inspection-Triggered approach is also subject to the general limitations associated with data inspection. This includes being impeded by encryption or tunneling, or being dependent on some topology constraints such as relying on the fact that both the packets of interest and the corresponding flow packets always transit through the same RSVP proxy.
検査トリガアプローチは、データ検査に関連付けられている一般的な制約を受けます。これは、暗号化やトンネリングによって妨げ、又はそのような同じRSVPプロキシ経由その関心のパケットと対応するフローパケットの両方が常にトランジット事実に頼るなど、いくつかのトポロジ上の制約に依存することを含みます。
Nonetheless, this may be a useful approach in specific environments. Note also that this approach does not require any change to the RSVP protocol.
それにもかかわらず、これは、特定の環境で有用なアプローチかもしれません。このアプローチは、RSVPプロトコルへの変更を必要としないことにも注意してください。
With the Inspection-Triggered RSVP Proxy approach, the RSVP router may be configurable to use and interpret some specific packets of interest as the trigger for RSVP Receiver Proxy behavior.
点検・トリガRSVPプロキシアプローチでは、RSVPルータはRSVPレシーバープロキシ動作のトリガとして関心のある特定のパケットを使用して解釈するために設定可能です。
When operating off signaling traffic, the Inspection-Triggered RSVP Proxy may be able to detect from the signaling that the endpoint is capable of establishing an RSVP reservation (e.g., in the case of SIP, via the inspection of the [RFC3312]/[RFC4032] precondition), in which case it would not behave as a proxy for that endpoint. Also, the Inspection-Triggered RSVP Proxy may inspect RSVP signaling, and if it sees RSVP signaling for the flow of interest, it can disable its Sender Proxy behavior for that flow (or that sender). Optionally, through RSVP signaling inspection, the Sender Proxy might also gradually "learn" (possibly with some timeout) which sender is RSVP-capable and which is not. These mechanisms can facilitate gradual and dynamic migration from the proxy model towards the end-to-end RSVP model as more and more endpoints become RSVP-capable.
シグナリングトラフィックをオフ操作する場合、検査トリガRSVPプロキシは、[RFC3312]の検査/ [RFC4032を介して、エンドポイントがSIPの場合には、例えば、（RSVP予約を確立することが可能であることをシグナリングから検出することができます]前提条件）、その場合には、そのエンドポイントのプロキシとして動作しないであろう。また、点検・トリガRSVPプロキシは、RSVPシグナリングを検査することができる、それが関心の流れのためのシグナリングRSVPを見れば、それはそのフロー（またはその送信者）のためにその送信者のプロキシの動作を無効にすることができます。必要に応じて、RSVPシグナリングの検査により、送信者のプロキシも徐々にRSVP-ことが可能であり、これはされていない送信者（おそらくいくつかのタイムアウト付き）「学習」することがあります。より多くのエンドポイントはRSVP-可能になるように、これらのメカニズムは、エンドツーエンドRSVPモデルに向かってプロキシモデルから漸進的かつ動的移行を容易にすることができます。
In this approach, the RSVP proxy takes advantage of the application awareness provided by the Session Traversal Utilities for NAT (STUN) ([RFC5389]) signaling to synchronize RSVP reservations with application requirements. The STUN signaling is sent from endpoint to endpoint. This is illustrated in Figure 9. In this approach, a STUN message triggers the RSVP proxy.
このアプローチでは、RSVPプロキシは、アプリケーション要件にRSVP予約を同期させるためにシグナリングNATのためのセッショントラバーサルユーティリティ（STUN）（[RFC5389]）によって提供されるアプリケーションの認識を利用します。 STUNシグナリングは、エンドポイントからエンドポイントに送信されます。これは、STUNメッセージはRSVPプロキシをトリガし、この手法では、図9に示されています。
|----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----|
|********| |********|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
=======RSVP=======>
======= ======= RSVP>
********************************************************>
********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
^^^> STUN message flow (over same UDP ports as media flow)
（メディアフローと同じUDPポートを介して）^^^> STUNメッセージフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
***> RTP media flow
***> RTPメディアフロー
Figure 9: STUN-Triggered Proxy
図9：STUN-トリガプロキシ
For unicast flows, [RFC5245] is a widely adopted approach for Network Address Translator (NAT) traversal. For our purposes of triggering RSVP proxy behavior, we rely on the Interactive Connectivity Establishment (ICE) protocol's connectivity check, which is based on the exchange of STUN Binding Request messages between hosts to verify connectivity (see Section 2.2 of [RFC5245]). The STUN message could also include (yet to be specified) STUN attributes to indicate information such as the bandwidth and application requesting the flow, which would allow the RSVP proxy agent to create an appropriately sized reservation for each flow. Including such new STUN attributes in the ICE connectivity check messages would facilitate operation of the RSVP proxy. To ensure RSVP reservations are only established when needed, the RSVP proxy needs to distinguish, among all the STUN messages, the ones that reflect (with high likelihood) an actual upcoming media flow. This can be achieved by identifying the STUN messages associated with an ICE connectivity check. In turn, this can be achieved through (some combination of) the following checks:
ユニキャストフローについて、[RFC5245]は、ネットワークアドレス変換（NAT）トラバーサルのために広く採用されているアプローチです。 RSVPプロキシ行動を誘発する我々の目的のために、私たちは（[RFC5245]のセクション2.2を参照）の接続性を確認するために、ホスト間で要求メッセージをバインディングSTUNの交換に基づいているインタラクティブ接続確立（ICE）プロトコルの接続性チェック、に依存しています。 STUNメッセージは、（まだ指定される）STUNは、RSVPプロキシエージェントは、各フローのために適切なサイズの予約を作成することを可能にする流れを、帯域要求およびアプリケーションなどの情報を示すために属性を含むことができます。 ICEの接続性チェックメッセージで、このような新しいSTUN属性を含めると、RSVPプロキシの動作を容易にするであろう。必要なときにRSVP予約が唯一の確立されていることを確認するには、RSVPプロキシは、すべてのSTUNメッセージのうち、（高い確率で）実際の今後のメディアフローを反映したものを区別する必要があります。これは、ICE接続性チェックに関連したSTUNメッセージを識別することによって達成することができます。今度は、これは以下のチェック（の組み合わせ）を介して達成することができます。
o if, as discussed above, new STUN attributes (e.g., conveying the flow bandwidth) are indeed defined in the future in view of facilitating STUN-Triggered reservations, then the presence of these attributes would reveal that the STUN message is part of an ICE connectivity check.
上述したように、O場合、新しいSTUN属性（例えば、フロー帯域幅を搬送する）実際STUN-トリガ予約を容易に鑑みて、将来的に定義され、次いで、これらの属性の存在は、STUNメッセージはICEの一部であることを明らかにする接続性チェック。
o the presence of the PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, or ICE-CONTROLLING attributes reveals that the STUN message is part of an ICE connectivity check.
PRIORITYの存在、O、USE候補、ICE制御、またはICE制御属性は、STUNメッセージがICE接続性チェックの一部であることがわかります。
o the RSVP proxy may wait for a STUN message containing the USE-CANDIDATE attribute indicating the selected ICE "path" to trigger reservation only for the selected "path". This allows the RSVP proxy to only trigger a reservation for the "path" actually selected and therefore for the media flow that will actually be established (for example, when ICE is being used for IPv4/v6 path selection).
O RSVPプロキシは、選択された「パス」の予約をトリガするために選択されたICE「パス」を示すUSE候補属性を含むSTUNメッセージを待つことができます。これは、実際に選択され、したがって、（ICEは、IPv4 / v6の経路選択に使用されている場合など）、実際に確立されるメディアフローのための「パス」の予約をトリガするRSVPプロキシを可能にします。
o the RSVP proxy configuration could contain some information facilitating determination of when to perform RSVP proxy reservation and when not to. For example, the RSVP proxy configuration could contain the IP addresses of the STUN servers such that STUN messages to/from those addresses are known to not be part of an ICE connectivity check. As another example, the RSVP proxy configuration could contain information identifying the set of Differentiated Services codepoint (DSCP) values that the media flows requiring reservation use, so that STUN messages not using one of these DSCP values are known to not be part of an ICE connectivity check.
RSVPプロキシ設定oをRSVPプロキシ予約としないときにを実行するときの決意を容易にするいくつかの情報を含むことができます。例えば、RSVPのプロキシ設定がSTUNサーバのIPアドレスを含めることができますに/これらのアドレスからのようにSTUNメッセージは、ICE接続性チェックの一部ではないと知られています。別の例として、RSVPプロキシ構成は、差別化サービスコードポイント（DSCP）のセットを識別する情報を含むことができ、これらのDSCP値のいずれかを使用していないことSTUNメッセージは、ICEの一部ではないことが知られているように、メディアは、予約の使用を必要と流れる値接続性チェック。
Despite these checks, there is always a potential risk that the RSVP proxy will end up establishing a reservation for a media flow that actually never starts. However, this is limited to situations in which the end-systems are interested enough in establishing connectivity for a flow but never transmit. Also, this can be mitigated by timing out and tear down of an unnecessary reservation by the RSVP proxy when no corresponding media flow is observed.
これらのチェックにもかかわらず、RSVPプロキシが実際に開始決してメディアフローの予約を確立することになりますことを潜在的な危険性が常にあります。しかし、これは、エンドシステムはフローの接続を確立するに十分な関心を持っているが、送信したことがないという状況に限定されています。また、これは、タイムアウトとは対応するメディアフローが観察されないときにRSVPプロキシによって不要な予約を破棄することによって緩和することができます。
The RSVP proxy agent can inform endpoints of an RSVP reservation failure implicitly by dropping the ICE connectivity check message or explicitly by sending ICMP messages back to the endpoint. This allows reasonably effective synchronization between RSVP reservations handled by the RSVP proxies and the application running on non-RSVP-capable endpoints. It also has the benefits of operating through NATs.
RSVPプロキシエージェントは、暗黙的にICEの接続性チェックメッセージをドロップすることにより、または明示的にバックエンドポイントへのICMPメッセージを送信することにより、RSVP予約の失敗のエンドポイントに知らせることができます。これは、RSVPプロキシと非RSVP対応のエンドポイント上で動作するアプリケーションによって処理RSVP予約の間に適度に効果的な同期を可能にします。また、NATを通過操作することの利点を持っています。
For multicast flows (or certain kinds of unicast flows that don't or can't use ICE), a STUN Indication message [RFC5389] could be used to carry the (yet to be defined) STUN attributes mentioned earlier to indicate the flow bandwidth, thereby providing a benefit similar to the ICE connectivity check. STUN Indication messages are not acknowledged by the receiver and have the same scalability as the underlying multicast flow.
マルチキャストフロー（またはしないか、ICEを使用することができないユニキャストフローの特定の種類）のために、STUN指示メッセージ[RFC5389]は、フロー帯域幅を示すために、前述の（まだ定義される）STUN属性を運ぶために使用することができます、それによって、ICE接続性チェックに似た利益を提供します。 STUN指示メッセージは、受信機によって認め、基礎となるマルチキャストフローと同じ拡張性を持っていません。
The corresponding extensions to ICE and STUN for such a STUN-Triggered RSVP Proxy approach are beyond the scope of this document. They may be defined in the future in a separate document. As the STUN-Triggered RSVP Proxy approach uses STUN in a way (i.e., to trigger reservations) that is beyond its initial intended purpose, the potential security implications need to be considered by the operator.
このようSTUN-トリガRSVPプロキシアプローチのためのICEとSTUNに対応する拡張は、このドキュメントの範囲を超えています。彼らは別の文書で、将来的に定義されてもよいです。 STUN・トリガRSVPプロキシアプローチは、その最初の意図された目的を超えているように、STUN（すなわち、予約をトリガするために）使用されるように、潜在的なセキュリティ上の影響は、オペレータによって考慮される必要があります。
ICE connectivity checks are not always used for all flows. When the STUN-Triggered RSVP Proxy approach is used, it can establish RSVP reservations for flows for which ICE connectivity is performed. However, the STUN-Triggered RSVP Proxy will not establish a reservation for flows for which an ICE connectivity check is not performed. Those flows either will not benefit from an RSVP reservation or can benefit from an RSVP reservation established through other means (end-to-end RSVP, other forms of RSVP proxy).
ICEの接続性チェックは、常にすべてのフローのために使用されていません。 STUN・トリガRSVPプロキシアプローチが使用される場合、それはICE接続が実行されたフローのためのRSVP予約を確立することができます。しかし、STUN-トリガRSVPプロキシは、ICE接続性チェックが実行されていないフローの予約を確立しません。これらのフローは、RSVP予約恩恵を受けるないか、または他の手段を介して確立されたRSVP予約（エンドツーエンドRSVP、RSVPプロキシの他の形態）から利益を得ることができるいずれか。
The STUN-Triggered approach relies on interception and inspection of STUN messages. Thus, this approach may be impeded by encryption or tunneling.
STUNトリガ型のアプローチは、STUNメッセージの傍受や検査に依存しています。したがって、このアプローチは、暗号化やトンネリングによって妨害することができます。
In this approach, it is assumed that an entity involved in the application-level signaling controls an RSVP proxy that is located in the data path of the application flows (i.e., "on-path"). With this approach, the RSVP proxy does not itself attempt to determine the application reservation requirements. Instead, the RSVP proxy is instructed by the entity participating in application-level signaling to establish, maintain, and tear down reservations as needed by the application flows. In other words, with this approach, the solution for synchronizing RSVP signaling with application-level requirements is to rely on an application-level signaling entity that controls an RSVP proxy function that sits in the flow data path. This approach allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy, or both.
このアプローチでは、それはアプリケーション・レベルのシグナル伝達に関与するエンティティは、アプリケーションフローのデータパスに位置するRSVPプロキシを制御することが想定される（すなわち、「オンパス」）。このアプローチでは、RSVPプロキシ自体はアプリケーションの予約の要件を決定しようとしません。代わりに、RSVPプロキシは、確立、維持、およびアプリケーションフローによって、必要に応じて予約を取り壊すために、アプリケーションレベルのシグナリングに参加するエンティティによって指示されています。換言すれば、このアプローチを用いて、アプリケーションレベルの要件とシグナリングRSVPを同期させるための解決策は、フローデータパスに座っRSVPプロキシ機能を制御するアプリケーションレベルシグナリングエンティティに依存することです。このアプローチは、RSVP送信側プロキシ、RSVP受信プロキシ、またはその両方の制御を可能にします。
Operation of the Application_Entity-Controlled Proxy is illustrated in Figure 10.
Application_Entity-制御プロキシの動作は、図10に示されています。
|---------| |---------|
/////////| App |////\\\\| App |\\\\\\\\
/ | Entity | | Entity | \
/ |---------| |---------| \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
|----| |********| *** |*********| |----|
| S |----------| |------*r*-------| |---------| R |
|----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver|
| Proxy | | Proxy |
|********| |*********|
=======RSVP=======>
======= ======= RSVP>
********************************************************>
********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
/\ Application signaling (e.g., SIP)
/ \アプリケーションシグナリング（例えば、SIP）
// RSVP proxy control interface
// RSVP代理制御インターフェース
Figure 10: Application_Entity-Controlled Proxy
図10：Application_Entity制御されたプロキシ
As an example, the Application_Entity-Controlled Proxy may be used in the context of SIP servers ([RFC3261]) or Session Border Controllers (SBCs) (see [RFC5853] for a description of SBCs) to establish RSVP reservations for multimedia sessions. In that case, the application entity may be the signaling component of the SBC.
一例として、Application_Entity-制御プロキシは、マルチメディアセッションのためのRSVP予約を確立するために（SBCSの説明については、[RFC5853]を参照）、SIPサーバ（[RFC3261]）またはセッションボーダーコントローラ（SBCS）の文脈で使用されてもよいです。その場合、アプリケーション・エンティティは、SBCのシグナリング成分であってもよいです。
This RSVP proxy approach does not require any extension to the RSVP protocol. However, it relies on an RSVP proxy control interface allowing control of the RSVP proxy by an application signaling entity. This RSVP proxy control interface is beyond the scope of this document. Candidate protocols for realizing such an interface include the IETF Network Configuration (NETCONF) Protocol ([RFC4741], [RFC5277]), the Web Services protocol ([W3C]), the QoS Policy Information Model (QPIM) ([RFC3644]), and Diameter ([RFC3588]). This interface can rely on soft states or hard states. Clearly, when hard states are used, those need to be converted appropriately by the RSVP proxy entities into the corresponding RSVP soft states. As an example, [RFC5866] is intended to allow control of RSVP proxy via Diameter.
このRSVPプロキシアプローチは、RSVPプロトコルへの拡張を必要としません。しかし、それはアプリケーションシグナリングエンティティによってRSVPプロキシの制御を可能にするRSVPプロキシ制御インターフェースに依存します。このRSVP代理制御インターフェースは、このドキュメントの範囲を超えています。 IETFネットワーク設定（NETCONF）プロトコル（[RFC4741]、[RFC5277]）、ウェブサービスプロトコル（[W3C]）を含め、このようなインタフェースを実現するための候補プロトコル、QoSポリシーの情報モデル（QPIM）（[RFC3644]）、そして直径（[RFC3588]）。このインタフェースは、柔らかい状態または困難な状態に依存することができます。困難な状態が使用されている場合、明らかに、これらは対応するRSVPソフト状態にRSVPプロキシエンティティによって適切に変換する必要があります。一例として、[RFC5866]はビア径RSVPプロキシの制御を可能にするように意図されています。
In general, the application entity is not expected to maintain awareness of which RSVP Receiver Proxy is on the path to which destination. However, in the particular cases where it does so reliably, we observe that the application entity could control the RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP reservations are used between those, instead of one reservation per flow. For example, these aggregate reservations could be of the RSVP-AGGREGATE type, as specified in [RFC3175], or of the GENERIC-AGGREGATE type, as specified in [RFC4860]. Such aggregate reservations could be used so that a single reservation can be used for multiple (possibly all) application flows transiting via the same RSVP Sender Proxy and the same RSVP Receiver Proxy.
一般に、アプリケーション・エンティティは、RSVP受信プロキシは、宛先へのパス上にあるの認識を維持することが期待されていません。しかし、それはそう確実に行い、特定のケースでは、我々は、集約RSVP予約が代わりにフローごとに予約のものの間で使用されているように、アプリケーション・エンティティがRSVP送信者プロキシおよびレシーバープロキシを制御することができることを確認します。例えば、これらの凝集予約が[RFC4860]で指定されるように、RSVP-AGGREGATEタイプの、[RFC3175]で指定されるように、または汎用集約型であってもよいです。単一の予約は（場合によってはすべて）アプリケーションが同じRSVP送信側プロキシと同じRSVP受信プロキシを介して通過する流れ、複数のために使用することができるように、そのような骨材の予約を使用することができます。
For situations in which only the RSVP Sender Proxy has to be controlled by this interface, the interface may be realized through the simple use of RSVP itself, over a Generic Routing Encapsulation (GRE) tunnel from the application entity to the RSVP Sender Proxy. This particular case is further discussed in Section 4.5.1. Another particular case of interest is where the application signaling entity resides on the same device as the RSVP proxy. In that case, this interface may be trivially realized as an internal API. An example environment based on this particular case is illustrated in Section 4.5.2.
のみRSVP送信側プロキシは、このインタフェースによって制御されなければならない状況のために、インターフェースは、RSVP送信側プロキシへのアプリケーションエンティティから総称ルーティングカプセル化（GRE）トンネルを介して、RSVP自体の簡単な使用を介して実現されてもよいです。この特定の場合は、さらに、セクション4.5.1に記載されています。アプリケーションシグナリングエンティティがRSVPプロキシと同じデバイス上に存在する場合、目的の別の特定の場合です。その場合、このインターフェイスは自明内部APIとして実現されてもよいです。この特定のケースに基づいて環境例は、4.5.2項に示されています。
The application entity controlling the RSVP proxy (e.g., a SIP Call Agent) would often be aware of a number of endpoint capabilities, and it has to be aware of which endpoint can be best "served" by which RSVP proxy anyways. So it is reasonable to assume that such an application is aware of whether a given endpoint is RSVP-capable or not. The application may also consider the QoS preconditions and QoS mechanisms signaled by an endpoint as per [RFC3312]/[RFC4032] and [RFC5432]. The information about endpoint RSVP capability can then be used by the application to decide whether to trigger proxy behavior or not for a given endpoint. This can facilitate gradual and dynamic migration from the proxy model towards the end-to-end RSVP model as more and more endpoints become RSVP-capable.
RSVPプロキシ（例えば、SIPコールエージェント）は、多くの場合、エンドポイント機能の数を認識しているであろう、そしてそれがどのエンドポイントを知っていなければならない制御アプリケーションエンティティは最高のことができとにかくどのRSVPプロキシによって「務め」。だから、このようなアプリケーションは、特定のエンドポイントがRSVP対応であるかどうかを認識していると仮定することは合理的です。アプリケーションは、QoSの前提条件と[RFC3312] / [RFC4032]及び[RFC5432]に従って、エンドポイントによってシグナリングQoSメカニズムを考慮することができます。エンドポイントRSVP機能についての情報は、特定のエンドポイントのプロキシの動作やないをトリガするかどうかを決定するために、アプリケーションで使用することができます。より多くのエンドポイントはRSVP-可能になるので、これは、エンドツーエンドRSVPモデルに向かってプロキシモデルから漸進的かつ動的移行を容易にすることができます。
In some environments, the application entities (e.g., SIP back-to-back user agents) that need to control the RSVP proxies would already be deployed independently of the use, or not, of the Application_Entity-Controlled Proxy approach. In this case, the activation of the RSVP proxy approach should not introduce significant disruption in the application signaling path. In some environments, additional application entities may need to be deployed to control the RSVP proxies. In this case, the network operator needs to consider the associated risks of disruption to the application signaling path.
でRSVPプロキシが既にApplication_Entity-制御プロキシアプローチの、独立して使用する、またはしない展開される制御する必要があるいくつかの環境では、アプリケーション・エンティティ（例えば、SIPバックツーバックユーザエージェント）。この場合には、RSVPプロキシアプローチの活性化は、アプリケーションシグナリング経路の有意な破壊を導入してはなりません。一部の環境では、追加のアプリケーションエンティティは、RSVPプロキシを制御するために展開する必要があるかもしれません。この場合、ネットワークオペレータは、アプリケーションシグナリング経路の中断のリスクを考慮する必要があります。
This approach is simply a particular case of the more general Application_Entity-Controlled Proxy, but where only RSVP Sender Proxies need to be controlled by the application, and where RSVP is effectively used as the control protocol between the application-signaling entity and the RSVP Sender Proxy.
このアプローチは、単により一般Application_Entity-制御プロキシの特定の場合であるが、唯一のRSVP送信側プロキシは、アプリケーションによって制御される必要がある場合、およびRSVPを効果的アプリケーションシグナリングエンティティとRSVP送信者との間の制御プロトコルとして使用される場合プロキシ。
In this approach, the RSVP messages (e.g., RSVP Path message) are effectively generated by the application entity and logically "tunneled" to the RSVP Sender Proxy via GRE tunneling. This is to ensure that the RSVP messages follow the exact same path as the flow they protect (as required by RSVP operations) on the segment of the end-to-end path that is to be subject to RSVP reservations.
このアプローチでは、RSVPメッセージ（例えば、RSVP Pathメッセージ）を効果的にアプリケーションエンティティによって生成され、論理的にGREトンネルを介してRSVP送信側プロキシに「トンネリング」。これは、RSVPメッセージは（RSVP操作によって要求されるように）、彼らは予約をRSVPの対象となるエンドツーエンドパスのセグメントに保護フローとまったく同じ経路に従うことを保証することです。
Figure 11 illustrates such an environment.
図11は、このような環境を示します。
|-------------|
////////////| Application |\\\\\\\\\
/ | Entity | \
/ |-------------| \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
|----| |********| *** |****|
| S |-----------| RSVP |-----------*r*-----------------| R |
|----| | Sender | *** |****|
| Proxy |
|********|
=========RSVP====================>
*****************************************************>
*****************************************************>
|----| non-RSVP-capable |----| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
/\ Application-level signaling
/ \アプリケーションレベルのシグナリング
/=/ GRE-tunneled RSVP (Path messages)
/ = / GREトンネリングRSVP（Pathメッセージ）
Figure 11: Application_Entity-Controlled Sender Proxy via
"RSVP over GRE"
With the Application_Entity-Controlled Sender Proxy using "RSVP Over GRE", the application entity:
Application_Entity制御された送信者のプロキシと「GREオーバーRSVP」、アプリケーション・エンティティーを使用しました：
o generates a Path message on behalf of the sender, corresponding to the reservation needed by the application, and maintains the corresponding Path state. The Path message built by the application entity is exactly the same as would be built by the actual sender (if it was RSVP-capable), with one single exception, which is that the application entity puts its own IP address as the RSVP previous hop. In particular, it is recommended that the source address of the Path message built by the application entity be set to the IP address of the sender (not of the application entity). This helps ensure that, in the presence of non-RSVP routers and of load-balancing in the network where the load-balancing algorithm takes into account the source IP address, the Path message generated by the application entity follows the exact same path as the actual stream sourced by the sender.
Oは、アプリケーションが必要とする予約に対応し、送信者に代わってPathメッセージを生成し、対応するパスの状態を維持しています。アプリケーションエンティティによって構築されたPathメッセージは、（それがRSVP対応であった場合）実際の送信者によって構築されるであろうと全く同じであり、アプリケーション・エンティティがRSVP前ホップとして自身のIPアドレスを置くことである一つの例外と。特に、アプリケーションエンティティによって構築されたPathメッセージの送信元アドレスは、送信者（ないのアプリケーション・エンティティ）のIPアドレスに設定することが推奨されます。これは、ロードバランシングアルゴリズムは、アカウントに送信元IPアドレスを取得し、ネットワーク内の非RSVPルータのとロード・バランシングの存在下で、アプリケーションのエンティティによって生成されたPathメッセージがまったく同じ経路をたどり、ことを保証するのに役立ちます実際のストリームは、送信者によって供給します。
o encapsulates the Path message into a GRE tunnel whose destination address is the RSVP Sender Proxy, i.e., an RSVP router sitting on the data path for the flow (and upstream of the segment that requires QoS guarantees via RSVP reservation).
oは宛先アドレス、すなわち、データフローの経路（およびRSVP予約を介してQoS保証を必要とするセグメントの上流側）に座っRSVPルータRSVP送信側プロキシであるGREトンネルへのPathメッセージをカプセル化します。
o processes the corresponding received RSVP messages (including Resv messages) as per regular RSVP.
Oは、通常のRSVPに従って（RESVメッセージを含む）に対応する受信されたRSVPメッセージを処理します。
o synchronizes the RSVP reservation state with application-level requirements and signaling.
Oは、アプリケーションレベル要求およびシグナリングにRSVP予約状態を同期させます。
Note that since the application entity encodes its own IP address as the previous RSVP hop inside the [RFC2205] RSVP_HOP object of the Path message, the RSVP router terminating the GRE tunnel naturally addresses all the RSVP messages traveling upstream hop-by-hop (such as Resv messages) to the application entity (without having to encapsulate those in a reverse-direction GRE tunnel towards the application entity).
アプリケーションエンティティは、Pathメッセージの[RFC2205] RSVP_HOPオブジェクト内の前のRSVPホップとして自身のIPアドレスを符号化するので、GREトンネルを終端RSVPルータは当然上流ホップバイホップ（例えば走行すべてのRSVPメッセージに対処することに注意してくださいアプリケーション・エンティティへRESVメッセージ）として（）アプリケーションエンティティに向かって逆方向GREトンネルにそれらをカプセル化することなく。
This approach is simply a particular case of the more general Application_Entity-Controlled Proxy, but where the application entity is co-located with the RSVP proxy. As an example, Session Border Controllers (SBCs) with on-board SIP agents could implement RSVP proxy functions and make use of such an approach to achieve session admission control over the SBC-to-SBC segment using RSVP signaling.
このアプローチは、単により一般Application_Entity-制御プロキシの特定の場合であるが、アプリケーション・エンティティは、RSVPプロキシと同じ場所に配置されます。一例として、オンボードSIP剤とセッションボーダーコントローラ（SBCS）は、RSVPプロキシ機能を実装し、RSVPシグナリングを使用して、SBC対SBCセグメント上セッションアドミッション制御を達成するために、そのようなアプローチを利用することができました。
Figure 12 illustrates operations of the Application_Entity-Controlled RSVP Proxy via co-location.
図12は、コロケーションを介しApplication_Entity-制御RSVPプロキシの動作を示します。
|---------| |---------|
////////| App |////////\\\\\\\| App |\\\\\\\\\
/ | Entity | | Entity | \
/ | | | | \
|----| |*********| *** |*********| |----|
| S |--------| RSVP |------*r*------| RSVP |---------| R |
|----| | Sender | *** | Receiver| |----|
| Proxy | | Proxy |
|*********| |*********|
=======RSVP======>
======= RSVP ======>
*******************************************************>
*******************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
/\ Application-level signaling
/ \アプリケーションレベルのシグナリング
Figure 12: Application_Entity-Controlled Proxy via Co-Location
図12：コロケーション経由Application_Entity制御されたプロキシ
This RSVP proxy approach does not require any protocol extensions. We also observe that when multiple sessions are to be established on paths sharing the same RSVP Sender Proxy and the same RSVP Receiver Proxy, the RSVP proxies have the option to establish aggregate RSVP reservations (as defined in ([RFC3175] or [RFC4860]) for a group of sessions, instead of establishing one RSVP reservation per session.
このRSVPプロキシアプローチは、任意のプロトコルの拡張を必要としません。我々はまた、複数のセッションが同じRSVP送信側プロキシと同じRSVPレシーバープロキシを共有する経路上に確立されるときに定義されるように、RSVPプロキシは（集約RSVP予約を確立するためのオプションを持っていることを観察する（[RFC3175]または[RFC4860]）セッションのグループのために、代わりのセッションにつき1つのRSVP予約を確立します。
In this approach, it is assumed that a policy server, which is located in the control plane of the network, controls an RSVP proxy that is located in the data path of the application flows (i.e., "on-path"). In turn, the policy server is triggered by an entity involved in the application-level signaling. With this approach, the RSVP proxy does not itself attempt to determine the application reservation requirements, but instead is instructed by the policy server to establish, maintain, and tear down reservations as needed by the application flows. Moreover, the entity participating in application-level signaling does not attempt to understand the specific reservation mechanism (i.e., RSVP) or the topology of the network layer, but instead it simply asks the policy server to perform (or tear down) a reservation. In other words, with this approach, the solution for synchronizing RSVP signaling with application-level requirements is to rely on an application-level entity that controls a policy server that, in turn, controls an RSVP proxy function that sits in the flow data path. This approach allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy, or both.
このアプローチでは、それはネットワークの制御プレーンに配置されたポリシーサーバは、アプリケーションフローのデータパスに位置するRSVPプロキシを制御することが想定される（すなわち、「オンパス」）。次に、ポリシーサーバは、アプリケーション・レベルのシグナル伝達に関与するエンティティによってトリガされます。このアプローチでは、RSVPプロキシ自体はアプリケーションの予約の要件を決定しようとしませんが、その代わりに、確立、維持、およびアプリケーションフローによって、必要に応じて予約を取り壊すためにポリシーサーバによって指示されました。また、アプリケーションレベルのシグナル伝達に関与するエンティティは、特定の予約メカニズム（即ち、RSVP）またはネットワーク層のトポロジーを理解しようとしないが、代わりに、単に予約を行う（または破棄）するポリシーサーバに要求します。換言すれば、このアプローチを用いて、アプリケーションレベルの要件とシグナリングRSVPを同期させるための溶液は、次に、フローデータパスに座っRSVPプロキシ機能を制御する、ポリシーサーバを制御するアプリケーションレベルのエンティティに依存することです。このアプローチは、RSVP送信側プロキシ、RSVP受信プロキシ、またはその両方の制御を可能にします。
Operation of the Policy_Server-Controlled proxy is illustrated in Figure 13.
Policy_Server-制御プロキシの動作は、図13に示されています。
|---------|
/////////////| App |\\\\\\\\\\\\\\
/ | Entity | \
/ |---------| \
/ I \
/ I \
/ |----------| \
/ | Policy | \
/ | Server | \
/ |----------| \
/ // \\ \
/ // \\ \
/ // \\ \
|----| |********| *** |*********| |----|
| S |-----------| |------*r*-----| |----------| R |
|----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver|
| Proxy | | Proxy |
|********| |*********|
=====RSVP========>
===== RSVP ========>
**********************************************************>
**********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
/\ Application signaling (e.g., SIP)
/ \アプリケーションシグナリング（例えば、SIP）
// RSVP proxy control interface
// RSVP代理制御インターフェース
I Interface between application entity and policy server
私は、アプリケーションエンティティとポリシーサーバ間のインタフェース
Figure 13: Policy_Server-Controlled Proxy
図13：Policy_Server-制御プロキシ
This RSVP proxy approach does not require any extension to the RSVP protocol. However, as with the Application_Entity-Controlled Proxy approach presented in Figure 10, this approach relies on an RSVP proxy control interface allowing control of the RSVP proxy (by the policy server in this case). This RSVP proxy control interface is beyond the scope of this document. Considerations about candidate protocols for realizing such an interface can be found in
このRSVPプロキシアプローチは、RSVPプロトコルへの拡張を必要としません。しかし、図10に提示Application_Entity-制御プロキシアプローチと同様に、このアプローチは、（ここで、ポリシーサーバによって）RSVPプロキシの制御を可能にするRSVP代理制御インターフェースに依存します。このRSVP代理制御インターフェースは、このドキュメントの範囲を超えています。そのようなインタフェースを実現するための候補プロトコルに関する考慮事項は、に見出すことができます
Section 4.5. Again, for situations in which only the RSVP Sender Proxy has to be controlled by this interface, the interface may be realized through the simple use of RSVP itself, over a GRE tunnel from the policy server to the RSVP Sender Proxy. This is similar to what is presented in Section 4.5.1, except that the "RSVP over GRE" interface is used in this case by the policy server (instead of the application entity).
4.5節。再び、唯一のRSVP送信側プロキシは、このインタフェースによって制御されなければならない状況のために、インターフェースは、RSVP送信側プロキシにポリシーサーバからGREトンネルを介して、RSVP自体の簡単な使用を介して実現されてもよいです。これは、「RSVP GRE上」インターフェースは、ポリシーサーバ（代わりのアプリケーションエンティティ）によって、この場合に使用されることを除いて、セクション4.5.1に提示されているものと同様です。
The interface between the application entity and the policy server is beyond the scope of this document.
アプリケーションエンティティとポリシーサーバ間のインタフェースは、このドキュメントの範囲を超えています。
An RSVP proxy can also be triggered and controlled through extended RSVP signaling from the remote end that is RSVP-capable (and supports these RSVP extensions for proxy control). For example, an RSVP-capable sender could send a new or extended RSVP message explicitly requesting an RSVP proxy on the path towards the receiver to behave as an RSVP Receiver Proxy and also to trigger a reverse-direction reservation, thus also behaving as an RSVP Sender Proxy. The new or extended RSVP message sent by the sender could also include attributes (e.g., bandwidth) for the reservations to be signaled by the RSVP proxy.
RSVPプロキシはまた、トリガとRSVP-可能である（プロキシ制御のため、これらのRSVPの拡張をサポートする）リモートエンドからのシグナリング拡張RSVPを介して制御することができます。例えば、RSVP-可能な送信者は、このようにしてもRSVPとして振る舞う、明示的RSVP受信プロキシとして動作するように、また逆方向予約をトリガするために受信機に向かって経路上のRSVPプロキシを要求する新規または拡張RSVPメッセージを送ることができます送信者のプロキシ。送信者によって送信された新しいまたは拡張RSVPメッセージはRSVPプロキシによって合図される予約の属性（例えば、帯域幅）をも含むことができます。
The challenges in these explicit signaling schemes include the following:
これらの明示的なシグナリングスキームにおける課題には次のものがあります。
o How can the nodes determine when a reservation request ought to be proxied and when it should not, and accordingly invoke appropriate signaling procedures?
Oどのように予約要求がプロキシであるべきときにノードが決定したとき、それはいけない、それに応じて適切なシグナリング手順を呼び出すことができますか？
o How does the node sending the messages explicitly triggering the proxy know where the proxy is located, e.g., determine an IP address of the proxy that should reply to the signaling?
Oどのように明示的にプロキシが配置されている場所プロキシが知っているトリガメッセージを送信するノードは、例えば、シグナリングに返信するプロキシのIPアドレスを決定するのですか？
o How is all the information needed by a Sender Proxy to generate a Path message actually communicated to the proxy?
Oどのようにすべての情報は、実際にはプロキシに伝えPathメッセージを生成するために、送信者のプロキシによって必要とされていますか？
An example of such a mechanism is presented in [QOS-MOBILE]. This scheme is primarily targeted to local access network reservations whereby an end host can request resource reservations for both incoming and outgoing flows only over the access network. This may be useful in environments where the access network is typically the bottleneck while the core is comparatively over-provisioned, as may be the case with a number of radio access technologies. In this proposal, messages targeted to the proxy are flagged with one bit in all RSVP messages. Similarly, all RSVP messages sent back by the proxy are also flagged. The use of such a flag allows differentiating between proxied and end-to-end reservations. For triggering an RSVP Receiver Proxy, the sender of the data sends a Path message that is marked with the mentioned flag. The Receiver Proxy is located on the signaling and data path, eventually gets the Path message, and replies back with a Resv message. A node triggers an RSVP Sender Proxy with a newly defined Path_Request message, which instructs the proxy to send Path messages towards the triggering node. The node then replies back with a Resv. More details can be found in [QOS-MOBILE].
そのような機構の例は、[QOS-MOBILE]に提示されています。この方式は、主にエンドホストのみアクセスネットワークを介して受信および送信の両方のフローのためのリソース予約を要求することができるローカル・アクセス・ネットワークの予約に標的化されます。これは、無線アクセス技術の数の場合であってもよいように、コアは、比較的オーバープロビジョニングされている間、アクセスネットワークは、典型的には、ボトルネックになっている環境において有用であり得ます。この提案では、プロキシを対象のメッセージは、すべてのRSVPメッセージ内の1ビットのフラグが立てられています。同様に、プロキシにより返送されたすべてのRSVPメッセージもフラグが付けられます。このようなフラグの使用は、プロキシとエンド・ツー・エンドの予約を区別することができます。 RSVP受信プロキシをトリガするため、データの送信者は、上述のフラグでマークされたPathメッセージを送信します。受信プロキシは、最終的にPathメッセージを取得し、バックResvメッセージで応答し、シグナリング及びデータ経路上に配置されています。ノードは、トリガーノードに向けてPathメッセージを送信するようにプロキシに指示し、新たに定義されたPath_RequestメッセージとRSVP送信側プロキシをトリガします。ノードは、当時のResvと返答します。詳細は[QOS-MOBILE]で見つけることができます。
Such an RSVP-Signaling-Triggered Proxy approach would require RSVP signaling extensions (that are outside the scope of this document). However, it could provide more flexibility in the control of the proxy behavior (e.g., control of reverse reservation parameters) than would the Path-Triggered approaches defined in Section 4.1 and Section 4.2.
そのようなRSVPシグナリング・トリガプロキシアプローチ（この文書の範囲外である）RSVPシグナリング拡張を必要とするであろう。しかし、プロキシ動作の制御における柔軟性を提供することができる（例えば、逆予約パラメータの制御）パス・トリガアプローチはセクション4.1およびセクション4.2で定義されたものより。
Through potential corresponding protocol extensions, an RSVP-Signaling-Triggered Proxy approach could facilitate operation (e.g., reduce or avoid the need for associated configuration) in hybrid environments involving both reservations established end-to-end and reservations established via RSVP proxies. For example, [QOS-MOBILE] proposed a mechanism allowing an end-system to control whether a reservation can be handled by an RSVP proxy on the path, or is to be established end-to-end.
電位対応するプロトコルの拡張機能を介して、RSVPシグナリング・トリガプロキシアプローチは、RSVPプロキシを介して確立された両方のエンド・ツー・エンドを確立予約と予約を含むハイブリッド環境での動作を（例えば、減少または関連する設定の必要性を回避するため）容易にすることができます。例えば、[QOS-MOBILE]は、エンドシステムが予約が経路上のRSVPプロキシによって処理することができ、またはエンド・ツー・エンドを確立するかどうかを制御することを可能にする機構を提案しました。
There may be situations in which the RSVP Receiver Proxy is reachable by the sender, while the receiver itself is not. In such situations, it is possible that the RSVP Receiver Proxy is not always aware that the receiver is unreachable, and consequently may accept to establish an RSVP reservation on behalf of that receiver. This would result in unnecessary reservation establishment and unnecessary network resource consumption.
受信機自体がいない間RSVPレシーバープロキシは、送信者が到達可能である状況があるかもしれません。このような状況では、RSVPレシーバープロキシがその受信機に代わってRSVP予約を確立することを受け入れることができ、その結果、受信機が到達不能であることを常に意識していない、とすることが可能です。これにより、不要な予約の確立と不必要なネットワークリソースの消費につながります。
This is not considered a significant practical concern for a number of reasons. First, in many cases, if the receiver is not reachable from the sender, it will not be reachable for application signaling either, and so application-level session establishment will not be possible in the first place. Secondly, where the receiver is unreachable from the sender but is reachable for application-level signaling (say, because session establishment is performed through an off-path SIP agent that uses a different logical topology to communicate with the receiver), then the sender may detect that the receiver is unreachable before attempting reservation establishment. This may be achieved through mechanisms such as ICE's connectivity check ([RFC5245]). Finally, even if the sender does not detect that
これは、多くの理由から重要な実用的な関心事とはみなされません。受信機は送信機から到達可能でない場合は最初、多くの場合、それはいずれかのシグナリングアプリケーションのために到達できなくなり、そのため、アプリケーション・レベル・セッション確立はそもそもできません。第二に、ここで、受信機は送信機から到達不可能であるが、アプリケーション・レベルのシグナリングのために到達可能である（例えば、セッション確立を受信機と通信するための異なる論理トポロジーを使用するオフパスSIPエージェントを介して行われるため）、送信者もよいです受信機は、予約の確立を試みる前に到達不能であることを検出します。これは、ICEの接続性チェック（[RFC5245]）などのメカニズムを介して達成することができます。最後に、送信者はそれを検出しない場合でも、
the receiver is unreachable before triggering the RSVP reservation establishment, it is very likely that the application will quickly realize this lack of connectivity (e.g., the human accepting the phone call on the receiver side will not hear the human's voice on the sender side) and therefore tear down the session (e.g., hang up the phone), which in turn will trigger RSVP reservation release.
受信機は、アプリケーションを素早く接続の欠如を実現することは非常に可能性があり、RSVP予約の確立をトリガする前に、到達不能である（例えば、送信者側の人間の声は聞こえません受信側の携帯電話の通話を受け入れる人間）としたがって、今度はRSVP予約のリリースをトリガする、（電話を切る、など）セッションを取り壊します。
Nonetheless, it is recommended that network administrators consider the above in light of their particular environment when deploying RSVP proxies.
それにもかかわらず、RSVPプロキシを展開する際にネットワーク管理者は、特定の環境の光の中で上記を考慮することをお勧めします。
The mirror considerations apply for situations involving an RSVP Sender Proxy and where the sender cannot reach the destination while the RSVP Sender Proxy can.
ミラーの考慮事項は、RSVP送信者プロキシを伴う状況に適用すると、送信者は、RSVP送信者プロキシすることができますが宛先に到達できない場合。
In the environments of concern for this document, RSVP messages are used to control resource reservations on a segment of the end-to-end path of flows. The general security considerations associated with [RFC2205] apply. To ensure the integrity of the associated reservation and admission control mechanisms, the RSVP cryptographic authentication mechanisms defined in [RFC2747] and [RFC3097] can be used. Those protect RSVP messages integrity hop-by-hop and provide node authentication, thereby protecting against corruption, spoofing of RSVP messages, and replay. [RSVP-SEC-KEY] discusses key types and key provisioning methods, as well as their respective applicability to RSVP authentication.
この文書の懸念の環境では、RSVPメッセージは、フローのエンドツーエンドパスのセグメントに資源予約を制御するために使用されます。 [RFC2205]に関連した一般的なセキュリティ上の考慮事項が適用されます。関連する予約および入場制御機構の完全性を保証するために、[RFC2747]及び[RFC3097]で定義されたRSVP暗号化認証メカニズムを使用することができます。これらの保護RSVPメッセージの完全性によってホップホップノードの認証を提供し、それによって破損、RSVPメッセージのなりすまし、リプレイに対する保護します。 [RSVP-SEC-KEY]は認証をRSVPキータイプとキープロビジョニング方法、ならびにそれらのそれぞれの適用性を論じています。
[RSVP-SEC-KEY] also discusses applicability of IPsec mechanisms ([RFC4302][RFC4303]) and associated key provisioning methods for security protection of RSVP. This discussion applies to the protection of RSVP in the presence of RSVP proxies as defined in this document.
[RSVP-SEC-KEY]もIPsecのメカニズム（[RFC4302]、[RFC4303]）とRSVPのセキュリティ保護のための関連キープロビジョニング方法の適用を論じています。この文書で定義されたように、この議論はRSVPプロキシの存在下でのRSVPの保護に適用されます。
A subset of RSVP messages are signaled with the IP router alert option ([RFC2113], [RFC2711]). Based on the current security concerns associated with the use of the IP router alert option, the applicability of RSVP (and therefore of the RSVP proxy approaches discussed in this document) is limited to controlled environments (i.e., environments where the security risks associated with the use of the IP router alert option are understood and protected against). The security aspects and common practices around the use of the current IP router alert option, and consequences of using the IP router alert option by applications such as RSVP, are discussed in detail in [RTR-ALERT].
RSVPメッセージのサブセットは、IPルータ警告オプション（[RFC2113]、[RFC2711]）で通知されます。 IPルータ警告オプションの使用に関連した現在のセキュリティ上の懸念に基づいて、（そのため、この文書で説明するRSVPプロキシアプローチの）RSVPの適用性は、制御された環境のセキュリティリスクは、関連付けられた（すなわち、環境に制限されていますIPルータアラートオプションの使用は）理解して保護されています。セキュリティ面および共通プラクティス現在のIPルータ警告オプションの使用の周りに、そのようなRSVPなどのアプリケーションによって、IPルータ警告オプションを使用しての結果は、[RTR-ALERT]で詳しく説明されています。
A number of additional security considerations apply to the use of RSVP proxies and are discussed below.
追加のセキュリティの考慮事項の数は、RSVPプロキシの使用に適用され、以下に議論されています。
With some RSVP proxy approaches, the RSVP proxy operates autonomously inside an RSVP router. This is the case for the Path-Triggered Proxy approaches defined in Section 4.1 and in Section 4.2, for the Inspection-Triggered Proxy approach defined in Section 4.3, for the STUN-Triggered Proxy approach defined in Section 4.4, and for the RSVP-Signaling-Triggered approach defined in Section 4.7. Proper reservation operation assumes that the RSVP proxy can be trusted to behave correctly in order to control the RSVP reservation as required and expected by the end-systems. Since the basic RSVP operation already assumes a trust model where end-systems trust RSVP nodes to appropriately perform RSVP reservations, the use of an RSVP proxy that behaves autonomously within an RSVP router is not seen as introducing any significant additional security threat or as fundamentally modifying the RSVP trust model.
いくつかのRSVPプロキシのアプローチでは、RSVPプロキシは、RSVPルータ内部で自律的に動作します。これは、の場合のパス・トリガプロキシは、セクション4.4で定義されたSTUN・トリガプロキシアプローチのために、セクション4.3で定義された検査トリガプロキシアプローチのために、セクション4.1およびセクション4.2で定義され、RSVPシグナリングのためのアプローチ4.7節で定義された-Triggeredアプローチ。適切な予約操作は、RSVPプロキシがエンドシステムで必要とされると予想されるようにRSVP予約を制御するために、正しく動作するために信頼できることを前提としています。エンドシステムの信頼RSVPノードが適切にRSVP予約を実行する場合、基本的なRSVPの動作は既に信頼モデルを想定しているので、RSVPルータ内で自律的に動作しRSVPプロキシの使用は、有意な追加のセキュリティ脅威を導入として、または基本的に変更するようには見られませんRSVPの信頼モデル。
With some RSVP proxy approaches, the RSVP proxy operates under the control of another entity. This is the case for the Application_Entity-Controlled Proxy approach defined in Section 4.5 and for the Policy_Server-Controlled Proxy approach defined in Section 4.6. This introduces additional security risks since the entity controlling the RSVP proxy needs to be trusted for proper reservation operation and also introduces additional authentication and confidentiality requirements. The exact mechanisms to establish such trust, authentication, and confidentiality are beyond the scope of this document, but they may include security mechanisms inside the protocol used as the control interface between the RSVP proxy and the entity controlling it, as well as security mechanisms for all the interfaces involved in the reservation control chain (e.g., inside the application signaling protocol between the end-systems and the application entity, and, in the case of the Policy_Server-Controlled Proxy approach, in the protocol between the application entity and the policy server).
いくつかのRSVPプロキシのアプローチでは、RSVPプロキシは別のエンティティの制御下で動作します。これは、4.5節で定義されたApplication_Entity制御されたプロキシのアプローチのためとセクション4.6で定義されたPolicy_Server制御されたプロキシのアプローチのためのケースです。 RSVPプロキシを制御エンティティは、適切な予約操作に対して信頼する必要があり、また、追加の認証と機密性の要件を紹介するので、これは、追加のセキュリティリスクを紹介します。正確なメカニズムはこの文書の範囲を超えて、このような信頼、認証、機密性を確立するために、彼らはそれを制御RSVPプロキシとエンティティ間の制御インタフェースとして使用されるプロトコル内のセキュリティメカニズム、ならびにセキュリティメカニズムを含んでいてもよいです予約制御チェーンに関与するすべてのインタフェース（例えば、エンド・システムおよびアプリケーション・エンティティ間のアプリケーションシグナリングプロトコルの内側、及び、Policy_Server-制御プロキシアプローチの場合には、アプリケーション・エンティティと、ポリシー間のプロトコルでサーバ）。
In some situations, the use of RSVP proxy to control reservations on behalf of end-systems may actually reduce the security risk (at least from the network operator viewpoint). This could be the case, for example, because the routers where the RSVP proxy functionality runs are less exposed to tampering than end-systems. Such a case is further discussed in Section 4 of [RFC5946]. This could also be the case because the use of RSVP proxy allows localization of RSVP operation within the boundaries of a given administrative domain (thus easily operating as a controlled environment) while the end-to-end flow path spans multiple administrative domains.
いくつかの状況では、エンド・システムに代わって予約を制御するためのRSVPプロキシの使用は、実際には（少なくともネットワークオペレータの観点から）セキュリティ上のリスクを減少させることができます。ルータは、RSVPプロキシ機能の実行が少ないエンドシステムよりも改ざんに露出されるので、これは、例えば、場合であってもよいです。このような場合には、さらに、[RFC5946]のセクション4で説明されています。エンドツーエンドの流路が複数の管理ドメインにまたがるながらRSVPプロキシの使用は（容易に制御された環境として動作する）所定の管理ドメインの境界内RSVP動作の局在化を可能にするので、これはまた場合であってもよいです。
This document benefited from earlier work on the concept of RSVP proxy including the one documented by Silvano Gai, Dinesh Dutt, Nitsan Elfassy, and Yoram Bernet. It also benefited from discussions with Pratik Bose, Chris Christou, and Michael Davenport. Tullio Loffredo and Massimo Sassi provided the base material for Section 4.6. Thanks to James Polk, Magnus Westerlund, Dan Romascanu, Ross Callon, Cullen Jennings, and Jari Arkko for their thorough review and comments.
この文書では、シルヴァーノガイ、ディネッシュダット、Nitsan Elfassy、およびYoram Bernetによって文書1を含むRSVPプロキシの概念上の以前の仕事の恩恵を受けました。またPratikボーズ、クリスChristouの、そしてマイケル・ダベンポートとの議論の恩恵を受けました。 TullioのLoffredoとマッシモサッシは、4.6節のための基材を提供しました。彼らの徹底的なレビューとコメントのためのジェームズ・ポーク、マグヌスウェスター、ダンRomascanu、ロスCallon、カレン・ジェニングス、とヤリArkkoに感謝します。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]ブレーデン、R.とL.チャン、 "RSVP暗号化認証 - 更新メッセージタイプ価値"、RFC 3097、2001年4月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[QOS-MOBILE] Manner, J., "Provision of Quality of Service in IP-based Mobile Access Networks", Doctoral dissertation, University of Helsinki, 2003, <http://ethesis.helsinki.fi>.
、博士論文、ヘルシンキ大学、2003年、<http://ethesis.helsinki.fi> [QOS-MOBILE]マナー、J.、 "IPベースのモバイルアクセスネットワークにおけるサービス品質の提供"。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、B.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]ウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000.
[RFC2872] Bernet、Y.およびR. Pabbati、 "RSVPで使用するアプリケーションおよびサブアプリケーションIDポリシー要素"、RFC 2872、2000年6月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、RFC 3312、2002年10月 "資源管理とセッション開始プロトコル（SIP）の統合"。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003.
[RFC3644] SNIR、Y.、Ramberg、Y.、Strassner、J.、コーエン、R.、およびB.ムーア、 "サービスの方針品質（QoS）情報モデル"、RFC 3644、2003年11月。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032]キャマリロ、G.とP. Kyzivat、 "セッション開始プロトコル（SIP）前提条件フレームワークへの更新"、RFC 4032、2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]エンス、R.、 "NETCONF構成プロトコル"、RFC 4741、2006年12月。
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC4860]ルFaucheur、F.、デイビー、B.、ボーズ、P.、Christouの、C.、およびM.ダヴェンポート、 "汎用集計リソース予約プロトコル（RSVP）予約"、RFC 4860、2007年5月。
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling in a Nested Virtual Private Network", RFC 4923, August 2007.
[RFC4923]ベイカー、F.およびP.ボーズ、RFC 4923、2007年8月 "ネストされた仮想プライベートネットワークにシグナリングサービス品質（QoS）"。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277]チザム、S.およびH.トレビノ、 "NETCONFイベント通知"、RFC 5277、2008年7月。
[RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", RFC 5432, March 2009.
[RFC5432]ポーク、J.、Dhesikan、S.、およびG.キャマリロ、 "QoS（Quality of Service）をセッション記述プロトコル（SDP）におけるメカニズムの選択"、RFC 5432、2009年3月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853] Hautakorpi、J.、カマリロ、G.、ペンフィールド、R.、Hawrylyshen、A.、およびM. Bhatiaは、RFC 5853年4月 "セッション開始プロトコル（SIP）セッションボーダーコントロール（SBC）デプロイメントの要件" 2010。
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010.
[RFC5866]日、D.、マッキャン、P.、Tschofenig、H.、ツオウ、T.、ドリア、A.、およびG.ツォルン、 "直径サービス品質の応用"、RFC 5866、2010年5月。
[RFC5946] Le Faucheur, F., Manner, J., Narayanan, A., Guillou, A., and H. Malik, "Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy", RFC 5946, October 2010.
[RFC5946]ルFaucheur、F.、マナー、J.、ナラヤナン、A.、Guillou、A.、およびH.マリク、 "リソース予約プロトコル（RSVP）パス・トリガRSVP受信プロキシの拡張"、RFC 5946年10月2010。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
[RFC5974]マナー、J.、Karagiannis、G.、およびA.マクドナルド、 "NSISシグナリング層プロトコルクオリティ・オブ・サービスシグナリングのための（NSLP）"、RFC 5974、2010年10月。
[RSVP-SEC-KEY] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, June 2009.
[RSVP-SEC-KEY]ベリンガー、M.とF.ルFaucheur、 "RSVPセキュリティのためのキーイング方法の適用"、進歩、2009年6月での作業。
[RTR-ALERT] Le Faucheur, F., "IP Router Alert Considerations and Usage", Work in Progress, October 2009.
[RTR-ALERT]ルFaucheur、F.、 "IPルータアラートの考慮事項および使用方法"、進歩、2009年10月に作業。
[W3C] "World Wide Web Consortium (W3C) - Web Services Architecture", <http://www.w3.org/TR/ws-arch/>.
[W3C] "ワールド・ワイド・ウェブ・コンソーシアム（W3C） - Webサービスのアーキテクチャ"、<http://www.w3.org/TR/ws-arch/>。
Appendix A. Use Cases for RSVP Proxies
RSVPプロキシの付録A.ユースケース
A.1. RSVP-Based VoD Admission Control in Broadband Aggregation Networks
A.1。ブロードバンド集約ネットワークにおけるRSVPベースのVoDアドミッション制御
As broadband services for residential customers are becoming more and more prevalent, next-generation aggregation networks are being deployed in order to aggregate traffic from broadband users (whether attached via Digital Subscriber Line technology, aka DSL; Fiber To The Home/Curb, aka FTTx; Cable; or other broadband access technology). Video on Demand (VoD) services, which may be offered to broadband users, present significant capacity planning challenges for the aggregation network for a number of reasons. First, each VoD stream requires significant dedicated sustained bandwidth (typically 2-4 Mb/s in Standard Definition TV and 6-12 Mb/s in High Definition TV). Secondly, the VoD codec algorithms are very sensitive to packet loss. Finally, the load resulting from such services is very hard to predict (e.g., it can vary quite suddenly with blockbuster titles made available as well as with promotional offerings). As a result, transport of VoD streams on the aggregation network usually translate into a strong requirement for admission control. The admission control solution protects the quality of established VoD sessions by rejecting the additional excessive session attempts during unpredictable peaks, during link or node failures, or a combination of those factors.
住宅の顧客のためのブロードバンドサービスがますます普及しつつあるとして、次世代のアグリゲーションネットワークは、DSL別名、ブロードバンドユーザー（デジタル加入者線技術を介して結合しているかどうかからのトラフィックを集約するために展開されている、ファイバーホーム/抑制するために、別名のFTTx ;ケーブル;またはその他のブロードバンドアクセス技術）。ブロードバンドユーザー、多くの理由からアグリゲーションネットワークの存在の重要なキャパシティプランニングの課題に提供することができるオンデマンド（VOD）サービス、ビデオオン。まず、各のVoDストリームは大きな専用の持続的な帯域幅を必要とする（通常は標準画質テレビで2-4 Mb /秒と高品位テレビで6-12 Mb /秒）。第二に、VoDのコーデックアルゴリズムは、パケット損失に非常に敏感です。最後に、このようなサービスから生じる負荷が（例えば、それはかなり急に大ヒットタイトルが利用できるだけでなく、プロモーションの供物で作られたと異なります）を予測するのは非常に困難です。結果として、のVoDの輸送は、通常、アドミッション制御のための強い要求に変換アグリゲーションネットワーク上でストリーム。アドミッションコントロール溶液は、リンクまたはノードの障害時に、予測できないピーク時の追加の過度セッションの試みを拒否することによって確立されたVoDセッションの品質、またはこれらの要因の組み合わせを保護します。
RSVP can be used in the aggregation network for admission control of the VoD sessions. However, since customer premises equipment such as Set Top Boxes (STBs) (which behave as the receiver for VoD streams) often do not support RSVP, the last IP hop in the aggregation network can behave as an RSVP Receiver Proxy. This way, RSVP can be used between VoD pumps and the last IP hop in the aggregation network to perform accurate admission control of VoD streams over the resources set aside for VoD in the aggregation network (typically a certain percentage of the bandwidth of any link). As VoD streams are unidirectional, a simple Path-Triggered RSVP Receiver Proxy (as described in Section 4.1) is all that is required in this use case.
RSVPは、VODセッションのアドミッション制御のためのアグリゲーションネットワークで使用することができます。しかし、そのような（VoDのための受信機がストリームとして振る舞う）セットトップボックス（STB）などの顧客宅内機器は、多くの場合、RSVPをサポートしていないことから、アグリゲーションネットワーク内の最後のIPホップはRSVPレシーバープロキシとして動作することができます。 VoDのポンプとのVoDの正確なアドミッション制御を実行するため、集約ネットワークにおける最後のIPホップはアグリゲーションネットワーク（任意のリンクの帯域幅の、典型的には一定の割合）でのVoD用に確保されたリソース上ストリーム間でこのように、RSVPを使用することができます。 VoDストリームが単方向であるように、単純なパス・トリガRSVP受信プロキシ（セクション4.1で説明したように）このユースケースで必要とされる全てです。
Figure 14 illustrates operation of RSVP-based admission control of VoD sessions in an aggregation network involving RSVP support on the VoD pump (the senders) and the RSVP Receiver proxy on the last IP hop of the aggregation network. All the customer premises equipment remains RSVP-unaware.
図14は、VODポンプ（送信者）とアグリゲーションネットワークの最後のIPホップでRSVPレシーバープロキシ上のRSVP支援を伴うアグリゲーションネットワーク内のVoDセッションのRSVPベースのアドミッション制御の動作を示します。すべての顧客宅内機器は、RSVP-気づかないまま。
|-------------|
| VoD SRM |
| |
////////| |\\\\\\\\\\\\\\
/ |-------------| \
/ \
/ \
/ \
/ \
/ \
|****| *** *** *** |********| |-----| |---|
|VoD |---*r*---*r*---*r*---|RSVP |---|DSLAM|~~~~|STB|--TV
|Pump| *** *** *** |Receiver| |-----| |---|
|****| |Proxy |
|********|
<---Aggregation Net----------->
************************************************>
************************************************>
==============RSVP================>
SRM Session Resource Manager
SRMセッションリソースマネージャ
*** |---|
*r* regular RSVP |STB| Set Top Box
*** router |---|
***> VoD media flow
***>のVoDメディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
/\ VoD Application-level signaling (e.g., RTSP)
/ \のVoDアプリケーションレベルシグナリング（例えば、RTSP）
Figure 14: VoD Use Case with Receiver Proxy
図14：レシーバープロキシとVoDのユースケース
In the case where the VoD pumps are not RSVP-capable, an Application_Entity-Controlled Sender Proxy via the "RSVP over GRE" approach (as described in Section 4.5.1) can also be implemented on the VoD Controller or Session Resource Manager (SRM) devices typically involved in VoD deployments. Figure 15 illustrates operation of RSVP-based admission control of VoD sessions in an aggregation network involving such an Application_Entity-Controlled Source Proxy combined with an RSVP Receiver Proxy on the last IP hop of the aggregation network. All the customer premises equipment, as well as the VoD pumps, remain RSVP-unaware.
VoDのポンプは、RSVP対応されていない、Application_Entity-制御センダプロキシを「RSVP GRE上」アプローチを介してケースに（セクション4.5.1で説明したように）もSRM（VODコントローラ又はセッション・リソース・マネージャに実装することができます）デバイスは、通常のVoDの展開に関与します。図15は、アグリゲーションネットワークの最後のIPホップでRSVP受信プロキシと組み合わせるようApplication_Entity制御型ソース・プロキシを含む集約ネットワーク内のVoDセッションのRSVPベースのアドミッション制御の動作を示します。すべての顧客宅内機器、などのVoDポンプ、RSVP-気づかないまま。
|-------------|
////| VoD SRM |\\\\\\\\\\\
/ | | \
/ | + | \
/ | RSVP Sender | \
/ |Proxy Control| \
/ |-------------| \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
/ /=/ \
|----| |******| *** *** |********| |-----| |---|
| VoD|--|RSVP |----*r*--*r*--|RSVP |--|DSLAM|~~~~|STB|--TV
|Pump| |Sender| *** *** |Receiver| |-----| |---|
|----| |Proxy | |Proxy |
|******| |********|
<---Aggregation Net------------->
************************************************>
************************************************>
=========RSVP==============>
SRM Systems Resource Manager
SRMシステムリソースマネージャ
*** |---|
*r* regular RSVP |STB| Set Top Box
*** router |---|
***> VoD media flow
***>のVoDメディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
/ VoD Application-level signaling (e.g., RTSP)
/ VODアプリケーション・レベルのシグナリング（例えば、RTSP）
/=/ GRE-tunneled RSVP (Path messages)
/ = / GREトンネリングRSVP（Pathメッセージ）
Figure 15: VoD Use Case with Receiver Proxy
and SRM-Based Sender Proxy
The RSVP proxy entities specified in this document play a significant role here since they allow immediate deployment of an RSVP-based admission control solution for VoD without requiring any upgrade to the huge installed base of non-RSVP-capable customer premises equipment. In one mode described above, they also avoid upgrade of non-RSVP-capable VoD pumps. In turn, this means that the benefits of on-path admission control can be offered to VoD services over broadband aggregation networks without network or VoD pump upgrade. Those include accurate bandwidth accounting regardless of topology (hub-and-spoke, ring, mesh, star, arbitrary combinations) and dynamic adjustment to any change in topology (such as failure, routing change, additional links, etc.).
彼らは非RSVP対応の顧客宅内機器の巨大なインストールベースへのアップグレードを必要とせずにVoDのためのRSVPベースのアドミッションコントロールソリューションの即時展開を許可するため、この文書で指定されたRSVPプロキシエンティティは、ここで重要な役割を果たしています。上記1つのモードでは、彼らはまた、非RSVP対応のVoDポンプのアップグレードを避けます。ターンでは、これは上のパスアドミッション制御の利点は、ネットワークやVoDのポンプをアップグレードすることなく、ブロードバンドアグリゲーションネットワーク上でVoDサービスを提供できることを意味しています。それらは関係なく、トポロジー（ハブアンドスポーク、リング、メッシュ、スター、任意の組み合わせ）と（等故障、ルーティング変更、追加リンク、など）、トポロジの変化に対する動的調整の会計正確な帯域幅を含みます。
A.2. RSVP-Based Voice/Video Connection Admission Control (CAC) in Enterprise WAN
A.2。エンタープライズWANでRSVPベースの音声/ビデオ接続アドミッション制御（CAC）
More and more enterprises are migrating their telephony and videoconferencing applications onto IP. When doing so, there is a need for retaining admission control capabilities of existing TDM-based (Time-Division Multiplexing) systems to ensure the QoS of these applications is maintained even when transiting through the enterprise's Wide Area Network (WAN). Since many of the endpoints already deployed (such as IP phones or videoconferencing terminals) are not RSVP-capable, RSVP proxy approaches are very useful: they allow deployment of an RSVP-based admission control solution over the WAN without requiring upgrade of the existing terminals.
より多くの企業は、IP上に自分の電話やビデオ会議アプリケーションを移行しています。その際、企業のワイドエリアネットワーク（WAN）を介して遷移するときにも維持されているこれらのアプリケーションのQoSを保証するために、既存のTDMベース（時分割多重）システムのアドミッション制御機能を保持する必要があります。 （たとえば、IP電話やビデオ会議端末など）は、すでに展開されたエンドポイントの多くは、RSVP対応していないので、RSVPプロキシアプローチは非常に便利です：彼らは、既存の端末のアップグレードを必要とせずにWAN経由でのRSVPベースのアドミッションコントロールソリューションの展開を許可します。
A common deployment architecture for such environments relies on the Application_Entity-Controlled Proxy approach as defined in Section 4.5. Routers sitting at the edges of the WAN are naturally "on-path" for all inter-campus calls (or sessions) and behave as RSVP proxies. The RSVP proxies establish, maintain, and tear down RSVP reservations over the WAN segment for the calls (or sessions) under the control of the SIP server/proxy. The SIP server/proxy synchronizes the RSVP reservation status with the status of end-to-end calls. For example, the called IP phone will only be instructed to play a ring tone if the RSVP reservation over the corresponding WAN segment has been successfully established.
4.5節で定義されているような環境のための一般的な展開アーキテクチャはApplication_Entity制御されたプロキシアプローチに依存しています。 WANの端に座ってルータは、すべてのインターキャンパスコール（またはセッション）のための「パスに」自然であり、RSVPプロキシとして動作します。 RSVPプロキシは、SIPサーバ/プロキシの制御下で、確立、維持、および呼（またはセッション）のためのWANセグメント上RSVP予約を取り壊します。 SIPサーバ/プロキシは、エンドツーエンドのコールのステータスでRSVP予約状態を同期します。例えば、と呼ばれるIP電話は、対応するWANセグメント経由RSVP予約が正常に確立されている場合に着信音を再生するように指示されます。
This architecture allowing RSVP-based admission control of voice and video on the enterprise WAN is illustrated in Figure 16.
企業WAN上の音声およびビデオのRSVPベースのアドミッション制御を可能にするこのアーキテクチャは、図16に示されています。
|---------|
//////////////| SIP |\\\\\\\\\\\\
/ | Server/ | \
/ | Proxy | \
/ |---------| \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
|-----| |********| *** *** |********| |-----|
| IP |------| Media |---*r*---*r*---| Media |-------|IP |
|Phone| | Relay | *** *** | Relay | |Phone|
|-----| | + | | + | |-----|
| RSVP | | RSVP |
| Proxy | | Proxy |
|********| |********|
<--campus--> <--campus--> network network
< - キャンパス - > < - キャンパス - >ネットワークネットワーク
<---------WAN----------->
<*************> <***********************> <**************>
<*************> <***********************> <**************>
<=========RSVP===========>
*** *r* Regular RSVP router ***
*** * R *通常のRSVPルータ***
<***> media flow
<***>メディアフロー
<==> segment of flow path protected by RSVP reservation
<==>流路のセグメントRSVP予約により保護
/\ SIP signaling
/ \ SIPシグナリング
// control interface between the SIP server/proxy and RSVP proxy
SIPサーバ/プロキシとRSVPプロキシ間//制御インタフェース
Figure 16: CAC on Enterprise WAN Use Case
図16：エンタープライズWANユースケースのCAC
A.3. RSVP Proxies for Mobile Access Networks
A.3。モバイルアクセスネットワークのためのRSVPプロキシ
Mobile access networks are increasingly based on IP technology. This implies that, on the network layer, all traffic, both traditional data and streamed data like audio or video, is transmitted as packets. Increasingly popular multimedia applications would benefit from better than best-effort service from the network, a forwarding service with strict Quality of Service (QoS) with guaranteed minimum bandwidth and bounded delay. Other applications, such as electronic commerce, network control and management, and remote-login applications, would also benefit from a differentiated treatment.
モバイルアクセスネットワークはますますIP技術をベースとしています。これは、ネットワーク層、すべてのトラフィック、従来のデータおよび音声やビデオなどのデータをストリーミングの両方で、パケットとして送信される、ということを意味します。人気急上昇マルチメディア・アプリケーションは、ネットワーク、最低保証帯域幅と有界の遅延でサービスの厳格な品質（QoS）と転送サービスからベストエフォート型サービスよりも良いの恩恵を受けるだろう。このような電子商取引、ネットワーク制御及び管理、およびリモート・ログイン・アプリケーションのような他のアプリケーションも、分化した治療から恩恵を受けるであろう。
The IETF has two main models for providing differentiated treatment of packets in routers. The Integrated Services (IntServ) model [RFC1633], together with the Resource Reservation Protocol (RSVP) [RFC2205], [RFC2210], [RFC2961] provides per-flow guaranteed end-to-end transmission service. The Differentiated Services (Diffserv) framework [RFC2475] provides non-signaled flow differentiation that usually provides, but does not guarantee, proper transmission service.
IETFは、ルータにおけるパケットの分化治療を提供するための2つの主要なモデルを有しています。一緒にリソース予約プロトコル（RSVP）と統合サービス（IntServの）モデル[RFC1633]、[RFC2205]、[RFC2210]、[RFC2961]はフローごとの保証エンド・ツー・エンド伝送サービスを提供します。差別化サービス（DiffServ）のフレームワーク[RFC2475]は、通常は提供するが、保証されない非シグナリングフロー分化、適切な伝送サービスを提供します。
However, these architectures have potential weaknesses for deployment in Mobile Access Networks. For example, RSVP requires support from both communication endpoints, and the protocol may have potential performance issues in mobile environments. Diffserv can only provide statistical guarantees and is not well suited for dynamic environments.
しかし、これらのアーキテクチャは、モバイルアクセスネットワークにおける展開のための潜在的な弱点を持っています。例えば、RSVPは、通信エンドポイントの両方からのサポートを必要とし、プロトコルは、モバイル環境における潜在的なパフォーマンスの問題を有していてもよいです。 DiffServは唯一の統計的な保証を提供し、動的な環境に適していないことができます。
Let us consider a scenario, where a fixed network correspondent node (CN) would be sending a multimedia stream to an end host behind a wireless link. If the correspondent node does not support RSVP, it cannot signal its traffic characteristics to the network and request specific forwarding services. Likewise, if the correspondent node is not able to mark its traffic with a proper Differentiated Services codepoint (DSCP) to trigger service differentiation, the multimedia stream will get only best-effort service, which may result in poor visual and audio quality in the receiving application. Even if the connecting wired network is over-provisioned, an end host would still benefit from local resource reservations, especially in wireless access networks, where the bottleneck resource is most probably the wireless link.
私たちは、固定ネットワークのコレスポンデントノード（CN）は無線リンクの背後にあるエンドホストにマルチメディアストリームを送信することになるシナリオを、考えてみましょう。コレスポンデントノードは、RSVPをサポートしていない場合は、ネットワークへのトラフィック特性を合図して、特定の転送サービスを要求することはできません。コレスポンデントノードは、サービスの差別化をトリガするために、適切な差別化サービスコードポイント（DSCP）とそのトラフィックをマークすることができない場合には同様に、マルチメディア・ストリームは、受信に乏しく、ビジュアルとオーディオ品質をもたらすことができる唯一のベストエフォート型のサービスを取得します応用。接続する有線ネットワークを介して、プロビジョニングされた場合でも、ボトルネックリソースは、おそらく無線リンクである場合には、エンドホストはまだ、特に無線アクセスネットワークでは、ローカルリソース予約の恩恵を受けるだろう。
RSVP proxies would be a very beneficial solution to this problem. It would allow distinguishing local network reservations from the end-to-end reservations. The end host does not need to know the access network topology or the nodes that will reserve the local resources. The access network would do resource reservations for both incoming and outgoing flows based on certain criteria, e.g., filters based on application protocols. Another option is that the mobile end host makes an explicit reservation that identifies the intention, and the access network will find the correct local access network node(s) to respond to the reservation. RSVP proxies would, thus, allow resource reservation over the segment that is the most likely bottleneck, the wireless link. If the wireless access network uses a local mobility management mechanism, where the IP address of the mobile node does not change during handover, RSVP reservations would follow the mobile node movement.
RSVPプロキシは、この問題に非常に有益な解決策になります。これは、エンド・ツー・エンドの予約からローカルネットワークの予約を区別できるようになります。エンドホストは、アクセスネットワークトポロジーや地元の資源を予約しますノードを知る必要はありません。アクセスネットワークは、例えば、一定の基準に基づいて、着信と発信の流れの両方のアプリケーションプロトコルに基づいてフィルタをリソース予約を行うだろう。別のオプションは、モバイルエンドホストが意図を特定する明示的な予約を行うことで、アクセスネットワークは、予約に対応するために正しいローカルアクセス・ネットワーク・ノード（複数可）を見つけます。 RSVPプロキシは、このように、最も可能性の高いボトルネック、無線リンクであるセグメント上のリソースの予約を可能にします。無線アクセスネットワークは、モバイルノードのIPアドレスは、ハンドオーバー中に変化しないローカルモビリティ管理メカニズムを、使用している場合は、RSVP予約は、モバイルノードの動きをたどります。
A.4. RSVP Proxies for Reservations in the Presence of IPsec Gateways
A.4。 IPsecのゲートウェイの存在下での予約のためのRSVPプロキシ
[RFC4923] discusses how resource reservation can be supported end-to-end in a nested VPN environment. At each VPN level, VPN routers behave as [RFC4301] security gateways between a plaintext domain and a ciphertext domain. To achieve end-to-end resource reservation, the VPN routers process RSVP signaling on the plaintext side, perform aggregation of plaintext reservations, and maintain the corresponding aggregate RSVP reservations on the ciphertext side. Each aggregate reservation is established on behalf of multiple encrypted end-to-end sessions sharing the same ingress and egress VPN routers. These aggregate reservations can be as specified in [RFC3175] or [RFC4860].
[RFC4923]は、リソース予約は、ネストされたVPN環境におけるエンドツーエンドをサポートすることができる方法について説明します。各VPNレベルでは、VPNルータは平文と暗号文ドメインのドメイン間の[RFC4301]のセキュリティゲートウェイとして振る舞います。エンドツーエンドのリソース予約を達成するために、平文側上でシグナリングVPNルータプロセスRSVPは、平文の予約の集計を行い、暗号文側に対応する集約RSVP予約を維持します。各集計予約は同じ入力および出力のVPNルータを共有する複数の暗号化されたエンドツーエンドのセッションに代わって確立されています。 [RFC3175]または[RFC4860]で指定されるように、これらの凝集体の予約をすることができます。
Section 3 of [RFC4923] discusses the necessary data flows within a VPN router to achieve the behavior described in the previous paragraph. Two mechanisms are described to achieve such data flows. Section 3.1 presents the case where the VPN router carries data across the cryptographic boundary. Section 3.2 discusses the case where the VPN router uses a Network Guard.
[RFC4923]のセクション3は、必要なデータは、前の段落に記載された動作を達成するために、VPNルータ内を流れる説明します。二つのメカニズムは、そのようなデータフローを達成するために記載されています。 3.1節は、VPNルータは、暗号境界を越えてデータを運ぶケースを提示します。 3.2節は、VPNルータは、ネットワークのガードを使用する場合について説明します。
Where such mechanisms are not supported by the VPN routers, the approach for end-to-end reservations presented in [RFC4923] cannot be deployed. An alternative approach to support resource reservations within the ciphertext core is to use the Application_Entity-Controlled Proxy approach (as defined in Section 4.5) in the following way:
そのようなメカニズムはVPNルータによってサポートされていない場合、[RFC4923]に提示され、エンドツーエンドの予約のためのアプローチを展開することができません。暗号文コア内のリソースの予約をサポートするための別のアプローチは、（セクション4.5で定義されるように）次のようにApplication_Entity-制御プロキシアプローチを使用することです。
o the RSVP proxies are located inside the ciphertext domain and use aggregate RSVP reservations.
O RSVPプロキシは、暗号文ドメイン内にあり、集約RSVP予約を使用しています。
o the application entity exchange application-level signaling with the end-systems in the plaintext domain.
平文ドメインでエンドシステムとアプリケーションエンティティ交換アプリケーションレベルシグナリングO。
o the application entity controls the RSVP proxies in the ciphertext domain via an RSVP proxy control interface.
Oアプリケーションエンティティは、RSVPプロキシ制御インターフェースを介して暗号文ドメインにおけるRSVPプロキシを制御します。
This is illustrated in Figure 17 in the case where the application is SIP-based multimedia communications.
これは、アプリケーションがSIPベースのマルチメディア通信である場合には、図17に示されています。
|-------| |-------|
|SIP |///////////////////\\\\\\\\\\\\\\\\\|SIP |
/|Server/| |Server/|\
/ |Proxy | |Proxy | \
/ |-------| |-------| \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
/ ^ \\ // ^ \
|***| |------| |********| *** *** |********| |------| |***|
| S |---|IPsec |--| ARSVP |---*r*---*r*---| ARSVP |--|IPsec |---| R |
|***| | GW | | Sender | *** *** |Receiver| | GW | |***|
|------| | Proxy | | Proxy | |------|
|********| |********|
***PT*****> **********************CT****************> ****PT***>
*** PT *****> ********************** CT ****************> **** PT ***>
=====> =====> =====ARSVP======>
=====> =====> ===== ARSVP ======>
|****| RSVP-capable |****| RSVP-capable *** | S | Sender | R | Receiver *r* regular RSVP |****| |****| *** router
| **** | RSVP対応| **** | RSVP対応*** | S |送信者| R |レシーバ* R *通常のRSVP | **** | | **** | ***ルータ
|------|
|IPsec | IPsec security gateway
| GW |
|------|
ARSVP Aggregate RSVP
RSVP集約RSVP
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
/ \ SIP signaling
/ \ SIPシグナリング
^ Network management interface between SIP server/proxy and IPsec security gateway
SIPサーバ/プロキシとのIPsecセキュリティゲートウェイとの間^ネットワーク管理インターフェース
// control interface between SIP server/proxy and ARSVP proxy
SIPサーバ/プロキシとARSVPプロキシ間//制御インタフェース
PT Plaintext network
PT平文ネットワーク
CT Ciphertext network
CT暗号文ネットワーク
Figure 17: RSVP Proxies for Reservations in the Presence of
IPsec Gateways
Where the sender and receiver are RSVP-capable, they may also use RSVP signaling. This achieves resource reservation on the plaintext segments of the end-to-end, i.e.,
送信側と受信側は、RSVP-可能である場合、それらはまた、RSVPシグナリングを使用することができます。これは、エンド・ツー・エンド、即ち平文のセグメントに資源予約を達成します
o from the sender to the ingress IPsec gateway, and
送信者からの入力IPsecゲートウェイにO、及び
o from the egress IPsec gateway to the receiver.
O出口IPsecゲートウェイから受信します。
In this use case, because the VPN routers do not support any RSVP-specific mechanism, the end-to-end RSVP signaling is effectively hidden by the IPsec gateways on the ciphertext segment of the end-to-end path.
VPNルータは、任意のRSVP固有のメカニズムをサポートしていないので、このユースケースでは、エンドツーエンドのRSVPシグナリングを効果的にエンドツーエンドパスの暗号文セグメント上のIPsecゲートウェイによって隠されています。
As with the Application_Entity-Controlled Proxy approach (defined in Section 4.5), the solution here for synchronizing RSVP signaling with application-level signaling is to rely on an application-level signaling device that controls an on-path RSVP proxy function. However, in this use case, the RSVP proxies are a component of a ciphertext network where all user (bearer) traffic is IPsec encrypted. This has a number of implications, including the following:
（セクション4.5で定義される）Application_Entity-制御プロキシアプローチと同様に、アプリケーション・レベルのシグナリングとシグナリングRSVPを同期させるための、ここで溶液は、オンパスRSVPプロキシ機能を制御するアプリケーションレベルの信号装置に依存することです。しかし、このユースケースでは、RSVPプロキシは、すべてのユーザ（ベアラ）トラフィックは、IPSecが暗号化され暗号文ネットワークの構成要素です。これは、次のような意味の数を持っています：
1. encrypted flows cannot be identified in the ciphertext domain so that network nodes can only classify traffic based on IP address and Differentiated Services codepoints (DSCPs). As a result, only aggregate RSVP reservations (such as those specified in [RFC3175] or [RFC4860]) can be used. This is similar to [RFC4923].
1.暗号化されたフローは、ネットワーク・ノードは、IPアドレスのみと差別化サービスコードポイント（DSCPを）に基づいてトラフィックを分類することができるように暗号文ドメイン内で識別することはできません。結果として、（例えば、[RFC3175]または[RFC4860]で指定されたもの）のみ集約RSVPの予約を使用することができます。これは、[RFC4923]に似ています。
2. Determining the RSVP Sender Proxy and RSVP Receiver Proxy to be used for aggregation of a given flow from sender to receiver creates a number of challenges. Details on how this may be achieved are beyond the scope of this document. We observe that, as illustrated in Figure 17, this may be facilitated by a network management interface between the application entity and the IPsec gateways. For example, this interface may be used by the application entity to obtain information about which IPsec gateway is on the path of a given end-to-end flow. Then, the application entity may maintain awareness of which RSVP proxy is on the ciphertext path between a given pair of IPsec gateways. How such awareness is achieved is beyond the scope of this document. We simply observe that such awareness can be easily achieved through simple configuration in the particular case where a single (physical or logical) RSVP proxy is fronting a given IPsec gateway. We also observe that when awareness of the RSVP Receiver Proxy for a particular egress IPsec gateway (or end-to-end flow) is not available, the aggregate reservation may be signaled by the RSVP Sender Proxy to the destination address of the egress IPsec gateway and then proxied by the RSVP Receiver Proxy.
2.送信側から受信側へ所与のフローの集合のために使用されるRSVP送信側プロキシおよびRSVP受信プロキシを決定することは、多くの課題を作成します。これを達成することができる方法についての詳細は、このドキュメントの範囲を超えています。我々は、図17に示すように、これはアプリケーション・エンティティとのIPsecゲートウェイとの間のネットワーク管理インターフェースによって容易にすることができる、ことを観察します。たとえば、このインタフェースは、IPsecゲートウェイが所定のエンド・ツー・エンドのフローのパス上にあるかについての情報を取得するために、アプリケーション・エンティティによって使用されてもよいです。次いで、アプリケーション・エンティティは、IPsecゲートウェイの所与の対の間の暗号文経路上にあるRSVPプロクシの意識を維持することができます。どのような意識を達成され、このドキュメントの範囲を超えています。我々は、単にそのような認識が容易に単一の（物理的または論理的な）RSVPプロキシが、所与のIPsecゲートウェイに面している特定の場合において、簡易な構成によって達成することができることを確認します。我々はまた、特定の出口のIPsecゲートウェイのRSVP受信プロキシの認識（またはエンド・ツー・エンドのフロー）が利用できない場合、集約予約出口IPsecゲートウェイの宛先アドレスにRSVP送信側プロキシによってシグナリングすることができることを観察しますその後、RSVP受信側プロキシによってプロキシ。
Different flavors of operations are possible in terms of aggregate reservation sizing. For example, the application entity can initiate an aggregate reservation of fixed size a priori and then simply keep count of the bandwidth used by sessions and reject sessions that would result in excess usage of an aggregate reservation. The application entity could also re-size the aggregate reservations on a session-by-session basis. Alternatively, the application entity could re-size the aggregate reservations in step increments typically corresponding to the bandwidth requirement of multiple sessions.
操作の異なるフレーバーが集約予約のサイジングの観点から可能です。例えば、アプリケーション・エンティティは先験的固定サイズの凝集予約を開始した後、単にセッションによって使用される帯域幅のカウントを維持し、凝集予約の過剰使用をもたらすであろうセッションを拒否することができます。アプリケーションエンティティは、サイズ直し可能性がセッションごとに集計予約。あるいは、アプリケーション・エンティティは、典型的には、複数のセッションの帯域幅要件に対応するステップ単位で集計予約サイズを再ことができました。
Authors' Addresses
著者のアドレス
Francois Le Faucheur Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France
フランソワ・リーパーシスコシステムズグリーンサイド、400アベニューRoumanille 06410ソフィアアンティポリスフランス
Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
電話：+33 4 97 23 26 19 Eメール：flefauch@cisco.com
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland
コミュニケーションのアアルト大学学部およびネットワーキング（Comnet）私書箱からユッカマナー13000 FIN-00076アアルトフィンランド箱
Phone: +358 9 470 22481 EMail: jukka.manner@tkk.fi URI: http://www.netlab.tkk.fi/~jmanner/
電話：+358 9 470 22481 Eメール：jukka.manner@tkk.fi URI：http://www.netlab.tkk.fi/~jmanner/
Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States
ダン・ウイングシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134米国
EMail: dwing@cisco.com
メールアドレス：dwing@cisco.com
Allan Guillou SFR 40-42 Quai du Point du Jour Boulogne-Billancourt 92659 France
アランGuillou SFR 40-42湖岸通りポイント92659ブーローニュビヤンクールフランスの日
EMail: allan.guillou@sfr.com
メールアドレス：allan.guillou@sfr.com