[要約] RFC 5945は、RSVPプロキシのアプローチに関する情報を提供するものであり、RSVPトラフィックの制御と管理を改善するためのガイドラインを提供します。目的は、ネットワークリソースの予約とトラフィックエンジニアリングを効果的に行うためのRSVPプロキシの実装を支援することです。
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
リソース予約プロトコル（RSVP）プロキシアプローチ
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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送信者プロキシ）によって送信されたパスメッセージを受信する必要があり、それらを沈め、データレシーバーに代わって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]は、セッション制御にセッション開始プロトコル（SIP）（[RFC3261]）を使用するエンドポイントによってRSVPの予約を非常に緊密に同期する方法について説明します。
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.
IETFのシグナル伝達（NSIS）ワーキンググループの次のステップは、新しいQoSシグナル伝達プロトコルを指定しました：QOS NSISシグナルレイヤープロトコル（NSLP）（[RFC5974]）。このプロトコルには、プロキシ操作の概念と、実際のデータ送信者または受信機ではないノードでのQOSシグナル伝達の終了も含まれます（[RFC5974]のセクション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 Sender ProxyおよびRSVP Receiver Proxyの概念を紹介します。セクション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対応デバイスへのパスに1つのRSVPレシーバープロキシを配置するための要件から生じます（RSVPプロキシによって常にRSVP対応デバイスが常に処理されるように）また、送信者からすべての非RSVP対応デバイスへのパス上にそのような受信機プロキシを1つだけ持っていることを目的としています（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.
このセクションでは、2種類のプロキシについて説明します。データ送信者に代わって動作するRSVP送信者プロキシと、データレシーバー用に動作するRSVPレシーバープロキシについて説明します。このドキュメントに示されている概念は、従来の[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の予約はデータの受信機によって制御されます。データ送信者が意図した受信者に向かってRSVPパスメッセージを送信した後、予約を必要とする各受信者がRESVメッセージを生成します。ただし、データ受信機がRSVPプロトコルを実行していない場合、ラストホップRSVPルーターは引き続きデータ受信機にパスメッセージを送信します。これにより、このメッセージは未知のプロトコル番号を持つIPパケットとして静かにドロップします。
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受信機プロキシ機能を実行することを決定します。これを図1に示します。RSVPプロキシルーターが必要な情報を取得できるさまざまなメカニズムについては、ドキュメントの後半で説明します。
|****| *** *** |**********| |----|
| 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
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を実行している場合でも、データ受信機に向かってパスメッセージを送信するためにデータパス上のノードが必要です。
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ノードは、レシーバーがリソース予約を設定できるようにパスメッセージを生成する必要があると判断します。このノードはRSVP送信者プロキシと呼ばれ、図2に示されています。このケースは、RSVP送信者プロキシがパスメッセージ内のすべての情報を生成できる必要があるため、受信機プロキシケースに対する追加の課題を示しています（sender_tspeceなどの情報を生成できる必要があります。オブジェクト）以前にRSVPメッセージを受け取ったという利点がありません。対照的に、RSVPレシーバープロキシは、着信パスメッセージに応じて適切な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
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.
o RSVPレシーバープロキシ：レシーバーに代わって実行されるRSVP対応ルーターは、エンドツーエンドのRSVPシグナルを使用した場合にRSVP対応レシーバーによって通常実行される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 Sender Proxy：送信者に代わって実行されるRSVP対応のルーターは、エンドツーエンドのRSVPシグナルを使用した場合にRSVP対応の送信者によって通常実行されるRSVP操作を実行しました。RSVPはRSVP Sender Proxyの下流で使用されますが、RSVPはRSVP Sender Proxyの上流では使用されていません。
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対応の終わりが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パスメッセージを使用します。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パスメッセージの受信を使用するように構成されている場合があります。
On receipt of the RSVP Path message, the RSVP Receiver Proxy:
RSVPパスメッセージを受信したとき、RSVPレシーバープロキシ：
1. establishes the RSVP Path state as per regular RSVP processing.
1. 通常のRSVP処理に従って、RSVPパス状態を確立します。
2. identifies the downstream interface towards the receiver.
2. レシーバーに向かってダウンストリームインターフェイスを識別します。
3. sinks the Path message.
3. パスメッセージを沈めます。
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レシーバープロキシはパスメッセージで受信した情報を考慮することができます。たとえば、RSVPレシーバープロキシは、受信したパスメッセージ内のsender_tspecオブジェクトをミラーリングするRESVメッセージのFlowsPecオブジェクトを作成する場合があります（RSVP対応レシーバーが通常行うにつれて）。
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
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ルーターの入場制御障害のため）、従来のRSVP操作とRESVERRメッセージが生成されます。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
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レシーバープロキシ（特定のフローの場合）のフローパスでの存在は、パスメッセージを終了させ、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対応である場合、パスメッセージを受信しないため、RSVPシグナリングに参加することができません。その結果、RSVP予約は、実際に範囲のパスのサブセットにのみ及ぶだけです。フローのパスに複数の受信機プロキシを使用すると、同様のサブオプティマリティが存在します。最初のレシーバープロキシは、パスメッセージが2番目のメッセージに到達するのを防ぐため、予約が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メッセージを上流に生成するとき、レシーバープロキシは、それを終了するのではなく、下流のパスメッセージを転送します。これにより、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
(R1) = Path message contains a Session object whose destination is R1
（R1）=パスメッセージには、宛先がR1であるセッションオブジェクトが含まれています
***> media flow
==> segment of flow path protected by RSVP reservation
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対応であり、何らかの理由で（たとえば、ソフトウェアのダウングレード）がもはやそうではない状況を動的に処理します。最後に、このアプローチでは、新しい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.
o 受信機プロキシとRSVP対応レシーバーの間のセグメントで入場制御が失敗した場合、受信機はRESVERRを取得し、アプリケーションレベルの信号手順を実行してコールを終了できます。ただし、レシーバープロキシはすでにこのフローのために上流のRESVを送信しているため、送信者は真にエンドツーエンドではない「誤った」予約を表示します。実際の入場管理ステータスはすぐに解決されますが、送信者は、Phantom RESVを受け取ったときに取られた可能性のある永続的なアクション（請求など）をロールバックする必要があります。2番目のレシーバーがアプリケーションシグナリングに参加していないレシーバープロキシでもある場合、受信したResverrを送信者が受信するPatherrに変換することに注意してください。
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].
o RSVP対応のレシーバー（またはその他の受信機プロキシ）がレシーバープロキシの下流にない場合、RSVPリフレッシュ間隔ごとにレシーバープロキシによって送信されたパスメッセージ（デフォルトでは30秒）は応答しません。ただし、これらのメッセージは少量の帯域幅を消費し、さらに、最初の受信機プロキシの下流のRSVP対応のMidpointノードにRSVP状態をインストールします。これは非常に小さな亜光学と見なされています。また、レシーバーがRSVP対応である場合、とにかくそのようなリソースが消費されることも観察します。それでも、これを軽減するために必要と思われる場合、受信機プロキシは、未回答の下流のパス状態を取り壊し、[RFC5946]でさらに説明するように、フローのパスメッセージの送信を停止する（またははるかに低い周波数でのみ送信する）ことができます。
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レシーバープロキシは、ローカルポリシーの決定に基づいて、終了するセッションについて選択することができます。たとえば、レシーバープロキシとして機能するエッジルーターは、実際に問題のドメインを終了するパスメッセージのみでプロキシとして動作する場合があります。別の例として、受信機プロキシは、特定の宛先アドレスまたは宛先アドレス範囲（最終デバイスが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をプロキシする決定は、パスメッセージ内の送信者からの通知された情報に基づいている場合があります。たとえば、送信者は、パスのアプリケーションIDポリシー要素（[RFC2872]）のアプリケーションまたはフローのタイプまたはフローを特定することができ、受信機プロキシは特定のタイプのフローのみのプロキシに構成されます。または、送信者がレシーバーがRSVP対応であることを（たとえば、アプリケーションシグナルを介して）知っている場合、送信者は、パスを終了するべきではない場合、受信機プロキシにポリシー要素に示すことを含めることができます（または逆に、逆に、レシーバーはRSVPをサポートしないことが知られていますが、送信者は、プロキシRESVメッセージを生成する必要があるというレシーバープロキシへの兆候を含めることができます）。[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).
このアプローチでは、1つのエンドポイントがRSVP対応であり、アプリケーション要件とRSVP予約の間の同期に完全な注意を払っていると想定されています。このエンドポイントは、1つのフロー方向（「前方」方向と呼ばれる）の送信者であり、反対方向のフローの受信機（「逆」方向と呼ばれます）です。
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プロキシは、受信機の制御下での逆方向の送信者プロキシとして効果的に機能しています（逆方向）。これは、たとえば、流れの2つの方向の帯域幅の観点から、程度の対称性を想定していることに注意してください（現在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.
受信者によって生成されたパスメッセージは、送信者から受信機へのパス上にある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：パストリガーレシーバーと送信者のプロキシ
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パスメッセージの受信を使用するように構成できる場合があります。
On receipt of the RSVP Path message for the forward direction, the RSVP Sender Receiver Proxy:
フォワード方向のRSVPパスメッセージを受信したとき、RSVP送信者レシーバープロキシ：
1. sinks the Path message.
1. パスメッセージを沈めます。
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. 逆方向のパスメッセージ（詳細は以下で説明されている）が送信者プロキシによって受信されたかのように動作します。これには、対応するパス状態の確立、パスメッセージの下流の転送、パスメッセージの定期的な更新の送信、前方向のパス状態が取り壊されたときに逆方向のパスを引き裂くことが含まれます。
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送信者プロキシは、順方向の受信パスメッセージの情報を考慮することができます。たとえば、RSVP Senderプロキシは、受信したパスメッセージの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プロキシがたまたま使用されていることに注意する必要はなく、フォワード予約に送信したパスメッセージは、逆予約の確立のトリガーとしても機能します。ただし、予約が逆方向にのみ必要な場合（図6を参照）、RSVP対応デバイスは、逆方向の予約をトリガーするためにパスメッセージを生成する必要があります。前方向。これは[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.
「関心のあるパケット」の一例は、アプリケーションレベルのシグナリングです。マルチメディアセッションのSIPシグナリングまたはビデオストリーミングのRTSPシグナリングを検査できるRSVPプロキシは、マルチメディアセッションがいつ上がっているか、またはビデオがストリーミングされる時期に関するこのようなシグナリング情報から取得できます。また、送信者とレシーバーのアドレスとポートを識別し、対応するフローの帯域幅を決定できます。また、予約がいつ必要でないかを判断し、それを取り壊すこともできます。したがって、このようなRSVPプロキシは、RSVPの予約をアプリケーション要件に同期させるために必要なすべての情報を決定できます。これを図8に示します。
|-------------|
| Application |
| Signaling |
| Entity |
|-------------|
/ \
/ \
/ \
</////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\>
|----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----|
|********| |********|
=======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
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.
「関心のあるパケット」のもう1つの例は、アプリケーションフロー自体（つまり、メディアパケット）に沿って移動する輸送制御メッセージ（リアルタイムトランスポートコントロールプロトコル（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プロキシは、エンドポイントがRSVP予約を確立できるというシグナリングから検出できる可能性があります（たとえば、SIPの場合、[RFC3312]/[RFC40322の検査を介して]前提条件）、その場合、そのエンドポイントのプロキシとして動作しません。また、検査トリガーされた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プロキシは、NAT（STUN）（[RFC5389]）のセッショントラバーサルユーティリティによって提供されるアプリケーションの認識を利用して、RSVPの予約をアプリケーション要件と同期させます。スタンシグナリングはエンドポイントからエンドポイントに送信されます。これを図9に示します。このアプローチでは、スタンメッセージがRSVPプロキシをトリガーします。
|----| |********| *** |********| |----|
| S |--------| RSVP |------*r*--------| RSVP |----------| R |
|----| | Proxy | *** | Proxy | |----|
|********| |********|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>
=======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)
==> segment of flow path protected by RSVP reservation
***> RTP media flow
Figure 9: STUN-Triggered Proxy
図9：スタントリガープロキシ
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プロキシの動作をトリガーする目的のために、インタラクティブな接続性確立（ICE）プロトコルの接続チェックに依存しています。これは、ホスト間のスタンバインディングリクエストメッセージの交換に基づいて接続を確認します（[RFC5245]のセクション2.2を参照）。スタンメッセージには、フローを要求する帯域幅やアプリケーションなどの情報を示すための（まだ指定されていない）スタン属性も含めることができます。これにより、RSVPプロキシエージェントは各フローの適切なサイズの予約を作成できます。ICE接続チェックメッセージにこのような新しいスタン属性を含めると、RSVPプロキシの操作が容易になります。RSVPの予約が必要なときにのみ確立されるようにするために、RSVPプロキシは、すべてのスタンメッセージを区別する必要があります。これは、氷の接続チェックに関連するスタンメッセージを識別することで実現できます。次に、これは次のチェックを通じて（ある程度の組み合わせ）を通じて達成できます。
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 上記で説明したように、新しいスタン属性（例えば、流れ帯域幅を伝える）が、スタントリガーの予約を促進することを考慮して将来的に定義されている場合、これらの属性の存在は、スタンメッセージが氷の接続性の一部であることを明らかにします小切手。
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.
o 優先順位、使用能力、アイス制御、またはアイスコントロール属性の存在は、スタンメッセージが氷の接続チェックの一部であることを明らかにしています。
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プロキシは、選択された「パス」を選択した「パス」を示すユースキャンディデート属性を含むスタンメッセージが、選択された「パス」のみをトリガーすることを待つことができます。これにより、RSVPプロキシは、実際に選択された「パス」の予約のみをトリガーすることができ、したがって実際に確立されるメディアフロー（たとえば、ICがIPv/V6パスの選択に使用されている場合）。
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.
o RSVPプロキシ構成には、RSVPプロキシ予約をいつ実行しないかの決定を容易にする情報が含まれています。たとえば、RSVPプロキシ構成には、スタンサーバーのIPアドレスが含まれているため、これらのアドレスへの賛成では、氷の接続チェックの一部ではないことが知られています。別の例として、RSVPプロキシ構成には、差別化されたサービスCodePoint（DSCP）値のセットを識別する情報が含まれている可能性があります。接続チェック。
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プロキシエージェントは、ICMPメッセージをエンドポイントに戻すことにより、ICM接続チェックメッセージをドロップするか、明示的に氷の接続チェックメッセージをドロップすることにより、暗黙的に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.
マルチキャストフロー（または氷を使用しない、または使用できない特定の種類のユニキャストフロー）の場合、スタン表示メッセージ[RFC5389]を使用して（まだ定義されている）スタン属性を運ぶために使用できます。、それにより、氷の接続チェックと同様の利益を提供します。スタン表示メッセージはレシーバーによって認められず、基礎となるマルチキャストフローと同じスケーラビリティを持っています。
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.
このようなスタントリガーされたRSVPプロキシアプローチの氷とスタンへの対応する拡張機能は、このドキュメントの範囲を超えています。それらは、将来、別のドキュメントで定義される場合があります。スタントリガーされたRSVPプロキシアプローチは、最初の目的の目的を超えている方法でスタン（つまり、予約をトリガーするために）を使用するため、潜在的なセキュリティへの影響をオペレーターが考慮する必要があります。
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).
氷の接続性チェックは、すべてのフローに常に使用されるとは限りません。スタントリガーされたRSVPプロキシアプローチを使用すると、氷の接続が実行されるフローのRSVP予約を確立できます。ただし、スタントリガーされたRSVPプロキシは、氷の接続チェックが実行されないフローの予約を確立しません。これらのフローは、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.
スタントリガーされたアプローチは、スタンメッセージの傍受と検査に依存しています。したがって、このアプローチは、暗号化またはトンネリングによって妨げられる場合があります。
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-Controlledプロキシの操作を図10に示します。
|---------| |---------|
/////////| App |////\\\\| App |\\\\\\\\
/ | Entity | | Entity | \
/ |---------| |---------| \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
/ // \\ \
|----| |********| *** |*********| |----|
| S |----------| |------*r*-------| |---------| R |
|----| | RSVP | *** | RSVP | |----|
| Sender | | Receiver|
| Proxy | | Proxy |
|********| |*********|
=======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
/\ Application signaling (e.g., SIP)
/\アプリケーションシグナリング（例：SIP）
// RSVP proxy control interface
// RSVPプロキシコントロールインターフェイス
Figure 10: Application_Entity-Controlled Proxy
図10：Application_Entity-Controlled Proxy
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-Controlledプロキシは、SIPサーバー（[RFC3261]）またはセッションボーダーコントローラー（SBCS）のコンテキストで使用できます（SBCSの説明については[RFC5853]を参照）。その場合、アプリケーションエンティティは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]）、Webサービスプロトコル（[W3C]）、QOSポリシー情報モデル（QPIM）（[RFC3644]）、[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送信者プロキシとレシーバープロキシを制御できるため、1つのフローごとの予約ではなく、それらの間でRSVP予約が使用されることがわかります。たとえば、これらの総留保は、[RFC3175]で指定されているRSVPアグレジェートタイプ、または[RFC4860]で指定されている一般的な総合タイプである可能性があります。このような総計は、同じ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対応であるかどうかを認識していると想定することは合理的です。アプリケーションでは、[RFC3312]/[RFC4032]および[RFC5432]に従ってエンドポイントによってシグナルが示すQOSの前処理と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プロキシを制御する必要があるアプリケーションエンティティ（たとえば、SIPバックツーバックユーザーエージェント）は、Application_Entity-Controlled Proxyアプローチの使用とは無関係に既に展開されています。この場合、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-Controlled Proxyの特定のケースですが、RSVP Senderプロキシのみをアプリケーションによって制御する必要があり、RSVPがアプリケーション署名エンティティとRSVP Sendererの間の制御プロトコルとして効果的に使用される場合プロキシー。
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パスメッセージなど）は、アプリケーションエンティティによって効果的に生成され、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
/\ Application-level signaling
/\アプリケーションレベルの信号
/=/ GRE-tunneled RSVP (Path messages)
/ =/ gre-tunneled rsvp（パスメッセージ）
Figure 11: Application_Entity-Controlled Sender Proxy via "RSVP over GRE"
図11：Application_Entity-Controlled Sender Proxy「RSVP over GRE」を介してプロキシ
With the Application_Entity-Controlled Sender Proxy using "RSVP Over GRE", the application entity:
Application_Entity-Controlled Sender Proxyを使用して、「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 送信者に代わってパスメッセージを生成し、アプリケーションが必要とする予約に対応し、対応するパス状態を維持します。アプリケーションエンティティによって構築されたパスメッセージは、実際の送信者によって構築されるのとまったく同じです（RSVP対応の場合）、1つの例外を除きます。。特に、アプリケーションエンティティによって構築されたパスメッセージのソースアドレスを、送信者のIPアドレス（アプリケーションエンティティではなく）に設定することをお勧めします。これにより、荷重バランスアルゴリズムがソースIPアドレスを考慮したネットワーク内の非RSVPルーターの存在下で、およびアプリケーションエンティティによって生成されたパスメッセージがまったく同じパスをたどることを保証するのに役立ちます。送信者によって供給された実際のストリーム。
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送信者プロキシであるGREトンネルへのパスメッセージをカプセル化します。つまり、フローのデータパスに座っているRSVPルーター（およびRSVP予約を介してQoS保証を必要とするセグメントの上流）です。
o processes the corresponding received RSVP messages (including Resv messages) as per regular RSVP.
o 通常のRSVPに従って、対応する受信RSVPメッセージ（RESVメッセージを含む）を処理します。
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).
アプリケーションエンティティは、パスメッセージの[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-Controld Proxyの特定のケースですが、アプリケーションエンティティがRSVPプロキシと共同で開催される場合です。例として、オンボードSIPエージェントを備えたセッションボーダーコントローラー（SBC）は、RSVPプロキシ関数を実装し、RSVPシグナル伝達を使用してSBC-SBCセグメントのセッション入場制御を達成するためにこのようなアプローチを使用することができます。
Figure 12 illustrates operations of the Application_Entity-Controlled RSVP Proxy via co-location.
図12は、Colocationを介したApplication_Entity-Controlled RSVP Proxyの操作を示しています。
|---------| |---------|
////////| App |////////\\\\\\\| App |\\\\\\\\\
/ | Entity | | Entity | \
/ | | | | \
|----| |*********| *** |*********| |----|
| S |--------| RSVP |------*r*------| RSVP |---------| R |
|----| | Sender | *** | Receiver| |----|
| Proxy | | Proxy |
|*********| |*********|
=======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
/\ Application-level signaling
/\アプリケーションレベルの信号
Figure 12: Application_Entity-Controlled Proxy via Co-Location
図12：Application_Entity-Controlled Proxyを介した共同ロケーションによるプロキシ
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 Senderプロキシと同じ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========>
**********************************************************>
|----| Non-RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|----| |----| *** router
***> media flow
==> segment of flow path protected by RSVP reservation
/\ 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-controlledプロキシ
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 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).
このRSVPプロキシアプローチでは、RSVPプロトコルの拡張は必要ありません。ただし、図10に示すApplication_Entity-Controlledプロキシアプローチと同様に、このアプローチはRSVPプロキシコントロールインターフェイスに依存して、RSVPプロキシの制御を可能にします（この場合はポリシーサーバーによる）。このRSVPプロキシ制御インターフェイスは、このドキュメントの範囲を超えています。このようなインターフェイスを実現するための候補プロトコルに関する考慮事項は、セクション4.5に記載されています。繰り返しますが、RSVP送信者プロキシのみをこのインターフェイスによって制御する必要がある状況では、ポリシーサーバーからRSVP送信者プロキシまでのGREトンネルを介して、RSVP自体の単純な使用を通じてインターフェイスを実現できます。これは、セクション4.5.1で提示されているものと似ています。ただし、この場合は（アプリケーションエンティティの代わりに）ポリシーサーバーによって「GRE上のRSVP」インターフェイスが使用されていることを除きます。
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プロキシによって予約が通知されるための属性（例：帯域幅）を含めることもできます。
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 送信者プロキシが実際にプロキシに通信するパスメッセージを生成するために必要なすべての情報はどのようにしていますか？
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レシーバープロキシをトリガーするために、データの送信者は、前述のフラグにマークされたパスメッセージを送信します。受信機プロキシは、信号とデータパスに配置され、最終的にパスメッセージを取得し、RESVメッセージで返信します。ノードは、新しく定義された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 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.
これは、いくつかの理由で重要な実際的な懸念とは見なされません。第一に、多くの場合、受信者が送信者から到達できない場合、アプリケーションシグナリングにも到達できないため、そもそもアプリケーションレベルのセッションの確立は不可能です。第二に、受信者は送信者からの到達不能であるが、アプリケーションレベルのシグナリングに到達可能である場合（たとえば、セッション確立は、レシーバーとの別の論理トポロジを使用して通信するオフパスSIPエージェントを介して実行されるため）、送信者は予約施設を試みる前に、受信機が到達できないことを検出します。これは、ICEの接続性チェック（[RFC5245]）などのメカニズムを通じて達成できます。最後に、送信者が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 Sender Proxyを含む状況に適用され、RSVP Sender Proxyができる間、送信者が宛先に到達できない場合。
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.1およびセクション4.2で定義されたパストリガープロキシアプローチ、セクション4.3で定義された検査トリガープロキシアプローチ、セクション4.4で定義されたスタントリガープロキシアプローチ、およびRSVPシグナル伝達についての場合です。 - セクション4.7で定義されたトリガーアプローチ。適切な予約操作は、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-Controlled Proxyアプローチと、セクション4.6で定義されているpolicy_Server-Controld Proxyアプローチの場合です。これにより、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.
この文書は、シルバノ・ガイ、ディネシュ・ダット、ニサン・エルファシー、ヨラム・ベルネットによって文書化されたものを含む、RSVPプロキシの概念に関する以前の研究の恩恵を受けました。また、Pratik Bose、Chris Christou、Michael Davenportとの議論の恩恵も受けました。Tullio LoffredoとMassimo Sassiは、セクション4.6のベース材料を提供しました。ジェームズ・ポーク、マグナス・ウェスターランド、ダン・ロマスカヌ、ロス・カロン、カレン・ジェニングス、ジャリ・アークコの徹底的なレビューとコメントに感謝します。
[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] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、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] Braden、R。およびL. Zhang、「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] Rosenberg、J。、「Interactive Connectivity Indecivity（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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「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>.
[Qos-Mobile] Mather、J。、「IPベースのモバイルアクセスネットワークにおけるサービス品質の提供」、博士論文、ヘルシンキ大学、2003年、<http://ethesis.helsinki.fi>。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633] Braden、B.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、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.、Rao、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711] Partridge、C。およびA. Jackson、「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] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F.、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、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] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
[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.、Frederick、R。、およびV. Jacobson、「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] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、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.、Cohen、R。、およびB. Moore、「Policy of Service（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] Camarillo、G。およびP. Kyzivat、「セッション開始プロトコル（SIP）Preconditions Frameworkの更新」、RFC 4032、2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R。、「NetConf Configuration Protocol」、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] Le Faucheur、F.、Davie、B.、Bose、P.、Christou、C。、およびM. Davenport、「ジェネリック集約リソース予約プロトコル（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] Baker、F。およびP. Bose、「ネストされた仮想プライベートネットワークでのサービス品質（QoS）シグナリング」、RFC 4923、2007年8月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277] Chisholm、S。およびH. Trevino、「NetConf Event Notifications」、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] Polk、J.、Dhesikan、S。、およびG. Camarillo、「セッション説明プロトコル（SDP）におけるサービス品質（QOS）メカニズムの選択」、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.、Camarillo、G.、Penfield、R.、Hawrylyshen、A。、およびM. Bhatia、「セッション開始プロトコル（SIP）セッション国境管理（SBC）の要件」、RFC 5853、4月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] Sun、D.、McCann、P.、Tschofenig、H.、Tsou、T.、Doria、A。、およびG. Zorn、「直径のサービス品質アプリケーション」、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] Le Faucheur、F.、Mather、J.、Narayanan、A.、Guillou、A.、およびH. Malik、「Resource Reservation Protocol（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] MANER、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のための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] Behringer、M。およびF. Le Faucheur、「RSVPセキュリティのためのキーイングメソッドの適用可能性」、2009年6月、進行中の作業。
[RTR-ALERT] Le Faucheur, F., "IP Router Alert Considerations and Usage", Work in Progress, October 2009.
[RTR-Alert] Le Faucheur、F。、「IPルーターのアラートの考慮事項と使用法」、2009年10月、進行中の作業。
[W3C] "World Wide Web Consortium (W3C) - Web Services Architecture", <http://www.w3.org/TR/ws-arch/>.
[W3C]「World Wide Web Consortium（W3C）-Web Services Architecture "、<http://www.w3.org/tr/ws-arch/>。
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ストリームには、重要な専用の持続帯域幅（通常、標準定義TVで2〜4 MB/s、高解像度TVで6〜12 MB/s）が必要です。第二に、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セッションの入場制御のために集約ネットワークで使用できます。ただし、セットトップボックス（STB）（VODストリームのレシーバーとして動作するSTBS）などの顧客がRSVPをサポートしていないことが多いため、集約ネットワークの最後のIPホップはRSVPレシーバープロキシとして動作する可能性があります。これにより、RSVPはVODポンプと集約ネットワークの最後のIPホップ間で使用して、集約ネットワークのVODのために確保されたリソース（通常、リンクの帯域幅の一定の割合）を介してVODストリームの正確な入場制御を実行できます。。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ポンプ（送信者）のRSVPサポートと集約ネットワークの最後のIPホップでのRSVPレシーバープロキシを含む集約ネットワークでのVODセッションのRSVPベースの入場制御の動作を示しています。すべての顧客施設機器は、RSVP-Unawareのままです。
|-------------|
| 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
==> segment of flow path protected by RSVP reservation
/\ 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対応ではない場合、「GRE上のRSVP」アプローチ（セクション4.5.1で説明）を介したApplication_Entity-Controld Sender ProxyをVODコントローラーまたはセッションリソースマネージャー（SRMに実装することもできます。）通常、VODの展開に関与するデバイス。図15は、集約ネットワークの最後のIPホップでのRSVPレシーバープロキシと組み合わせた、そのようなApplication_Entity-Controlledソースプロキシを含む集約ネットワークでの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
==> segment of flow path protected by RSVP reservation
/ VoD Application-level signaling (e.g., RTSP)
/ VODアプリケーションレベルのシグナリング（例：RTSP）
/=/ GRE-tunneled RSVP (Path messages)
/ =/ gre-tunneled rsvp（パスメッセージ）
Figure 15: VoD Use Case with Receiver Proxy and SRM-Based Sender Proxy
図15：レシーバープロキシとSRMベースの送信者プロキシ付きVODユースケース
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プロキシエンティティは、ここで重要な役割を果たします。これは、RSVPベースのAndimint Controlソリューションの即時展開をVOD用に即座に展開できるため、RSVP以外の顧客施設機器の巨大なインストールベースへのアップグレードを必要とせずに。上記の1つのモードでは、非RSVP対応VODポンプのアップグレードも避けています。次に、これは、ネットワークまたはVODポンプのアップグレードなしで、ブロードバンド集約ネットワークを介したVODサービスに、オンパス入場制御の利点を提供できることを意味します。これらには、トポロジー（ハブアンドスポーク、リング、メッシュ、星、任意の組み合わせ）に関係なく、正確な帯域幅の会計や、トポロジの変化（障害、ルーティングの変更、追加リンクなど）への動的な調整が含まれます。
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に移行しています。そうする場合、既存のTDMベースの（時間分割マルチプレックス）システムの入場制御機能を保持する必要があります。これらのアプリケーションのQOがエンタープライズの広いエリアネットワーク（WAN）を通過する場合でも、これらのアプリケーションのQOが維持されるようにします。既に展開されているエンドポイントの多く（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-Controlled Proxyアプローチに依存しています。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.
このアーキテクチャにより、RSVPベースのエンタープライズWAN上の音声とビデオの入場制御を図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
***
<***> media flow
<==> segment of flow path protected by RSVP reservation
/\ 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
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つの主要なモデルがあります。統合サービス（INTSERV）モデル[RFC1633]、およびリソース予約プロトコル（RSVP）[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プロキシは、この問題に対する非常に有益な解決策です。これにより、ローカルネットワークの予約をエンドツーエンドの予約と区別できます。エンドホストは、アクセスネットワークトポロジまたはローカルリソースを予約するノードを知る必要はありません。Access Networkは、特定の基準、たとえばアプリケーションプロトコルに基づいたフィルターに基づいて、着信と発信フローの両方に対してリソース予約を行います。もう1つのオプションは、モバイルエンドホストが意図を識別する明示的な予約を行い、アクセスネットワークが予約に応答する正しいローカルアクセスネットワークノードを見つけることです。したがって、RSVPプロキシは、最も可能性の高いボトルネックであるワイヤレスリンクであるセグメントに対するリソース予約を可能にします。ワイヤレスアクセスネットワークがローカルモビリティ管理メカニズムを使用している場合、モバイルノードのIPアドレスがハンドオーバー中に変更されない場合、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]プレーンテキストドメインと暗号文化ドメインの間の[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ルーター内の必要なデータフローについて説明して、前の段落で説明した動作を実現します。このようなデータフローを達成するために、2つのメカニズムが説明されています。セクション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]で提示されたエンドツーエンドの予約のアプローチを展開することはできません。Ciphertextコア内のリソース予約をサポートする代替アプローチは、次の方法でApplication_Entity-Controlled Proxyアプローチ（セクション4.5で定義されている）を使用することです。
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***>
=====> =====>
=====ARSVP======>
|****| RSVP-capable |****| RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |****| *** router
|------|
|IPsec | IPsec security gateway
| GW |
|------|
ARSVP Aggregate RSVP
ARSVP集計RSVP
***> media flow
==> segment of flow path protected by RSVP reservation
/ \ SIP signaling
^ 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 Plantext Network
CT Ciphertext network
CT ciphertextネットワーク
Figure 17: RSVP Proxies for Reservations in the Presence of IPsec Gateways
図17：IPSECゲートウェイの存在下での予約のためのRSVPプロキシ
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
o 送信者からイングレスIPSECゲートウェイまで、そして
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:
Application_Entity-Controlled Proxyアプローチ（セクション4.5で定義）と同様に、アプリケーションレベルのシグナル伝達とRSVPシグナルを同期するための解決策は、オンパスRSVPプロキシ関数を制御するアプリケーションレベルのシグナル伝達デバイスに依存することです。ただし、このユースケースでは、RSVPプロキシは、すべてのユーザー（Bearer）トラフィックが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）に基づいてトラフィックのみを分類できます。その結果、総計RSVP予約（[RFC3175]または[RFC4860]で指定されているものなど）のみを使用できます。これは[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ゲートウェイの特定のペア間のCiphertextパス上にあるRSVPプロキシがどのRSVPプロキシであるかについての認識を維持する場合があります。そのような意識がどのように達成されるかは、このドキュメントの範囲を超えています。単一の（物理的または論理的な）RSVPプロキシが特定のIPSECゲートウェイをフロンツしている特定のケースで、そのような認識は簡単な構成によって簡単に達成できることを単純に観察します。また、特定の出力IPSECゲートウェイ（またはエンドツーエンドのフロー）のRSVPレシーバープロキシの認識が利用できない場合、総計は、RSVP Sender ProxyがEgress Ipsec Gatewayの宛先アドレスに合図する可能性があることを観察します。その後、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
Francois Le Faucheur Cisco Systems Greenside、400 Avenue de Roumanille Sophia Antipolis 06410 France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland
Jukka Mather Aalto University of Communications and Networking（COMNET）P.O。Box 13000 Fin-00076 Aalto Finland
Phone: +358 9 470 22481
EMail: 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ウェストタスマンドライブサンノゼ、カリフォルニア95134アメリカ合衆国
EMail: dwing@cisco.com
Allan Guillou SFR 40-42 Quai du Point du Jour Boulogne-Billancourt 92659 France
Allan Guillou SFR 40-42 Quai Du Point du Jour Boulogne-Billancourt 92659フランス
EMail: allan.guillou@sfr.com