[要約] RFC 5946は、Path-Triggered RSVP Receiver ProxyのためのRSVP拡張に関するものであり、要約すると以下のようになります。1. Path-Triggered RSVP Receiver Proxyは、RSVPプロトコルの拡張機能であり、リソース予約を効率的に行うために使用されます。 2. このRFCは、Path-Triggered RSVP Receiver Proxyの動作と構成に関する詳細な仕様を提供し、ネットワークのパフォーマンスと効率を向上させることを目的としています。 3. また、このRFCは、既存のRSVPプロトコルに対する拡張機能として、ネットワークのリソース管理とトラフィック制御の改善を目指しています。
Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 5946 Cisco
Updates: 2205 J. Manner
Category: Standards Track Aalto University
ISSN: 2070-1721 A. Narayanan
Cisco
A. Guillou
SFR
H. Malik
Airtel
October 2010
Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy
リソース予約プロトコル（RSVP）パストリガーされたRSVPレシーバープロキシの拡張
Abstract
概要
Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to-end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions.
リソース予約プロトコル（RSVP）シグナリングを使用して、特定のフローで必要なサービス品質（QO）を保証するために、IPネットワークでエンドツーエンドのリソース予約を作成できます。従来のRSVPを使用すると、特定のフローのデータ送信者と受信機の両方がRSVPシグナル伝達に参加します。しかし、リソースの予約が必要な多くのユースケースがありますが、受信者、送信者、またはその両方はRSVP対応ではありません。レシーバーがRSVP対応ではない場合、RSVPルーターはRSVPレシーバープロキシとして動作し、それによりレシーバーに代わってRSVPシグナリングを実行できます。これにより、送信者からRSVPレシーバープロキシへのエンドツーエンドパスのセグメントにリソース予約を確立できます。ただし、コンパニオンドキュメント「RSVPプロキシアプローチ」で説明したように、RSVP拡張機能は、送信者からのRSVPパスメッセージの受信によってシグナリングがトリガーされるRSVPレシーバープロキシで操作を促進するために必要です。このドキュメントは、これらの拡張機能を指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5946.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5946で取得できます。
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 ....................................................4
1.1. Conventions Used in This Document ..........................7
2. Terminology .....................................................7
3. RSVP Extensions for Sender Notification .........................8
3.1. Sender Notification via PathErr Message ...................11
3.1.1. Composition of SESSION and Sender Descriptor .......14
3.1.2. Composition of ERROR_SPEC ..........................14
3.1.3. Use of Path_State_Removed Flag .....................15
3.1.4. Use of PathErr by Regular Receivers ................16
3.2. Sender Notification via Notify Message ....................17
4. Mechanisms for Maximizing the Reservation Span .................23
4.1. Dynamic Discovery of Downstream RSVP Functionality ........24
4.2. Receiver Proxy Control Policy Element .....................26
4.2.1. Default Handling ...................................29
5. Security Considerations ........................................29
5.1. Security Considerations for the Sender
Notification via Notify Message ...........................30
5.2. Security Considerations for the Receiver Proxy
Control Policy Element ....................................31
6. IANA Considerations ............................................32
6.1. RSVP Error Codes ..........................................32
6.2. Policy Element ............................................32
7. Acknowledgments ................................................33
8. References .....................................................33
8.1. Normative References ......................................33
8.2. Informative References ....................................34
Guaranteed Quality of Service (QoS) for some applications with tight QoS requirements 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, but it assumes that both the sender and the receiver of the data flow support RSVP. However, there are environments where it would be useful to be able to reserve resources for a flow (at least a subset of the flow path) even when the sender or the receiver (or both) is not RSVP-capable.
エンドツーエンドパスの各ノードのリソースを予約することにより、QoS要件が厳しい一部のアプリケーションの保証サービス品質（QOS）が達成される場合があります。これらのリソース予約の主なIETFプロトコルは、[RFC2205]で指定されているように、リソース予約プロトコル（RSVP）です。RSVPは、すべての中間ノードがRSVPをサポートすることを必要としませんが、データフローの送信者と受信者の両方がRSVPをサポートすることを前提としています。ただし、送信者またはレシーバー（またはその両方）がRSVP対応ではない場合でも、フローのリソースを（少なくともフローパスのサブセット）に予約できることが役立つ環境があります。
Since both the data sender and receiver may be unaware of RSVP, there are two types of RSVP Proxies. In the first case, an entity in the network needs to invoke RSVP on behalf of the data sender and thus generate RSVP Path messages, and eventually receive, process, and sink Resv messages. We refer to this entity as the RSVP Sender Proxy. In the second case, an entity in the network needs to operate RSVP on behalf of the receiver and thus receive Path messages sent by a data sender (or by an RSVP Sender Proxy), and reply to those with Resv messages generated on behalf of the data receiver(s). We refer to this entity as the RSVP Receiver Proxy.
データ送信者と受信機の両方がRSVPに気付いていない可能性があるため、RSVPプロキシには2つのタイプがあります。最初のケースでは、ネットワーク内のエンティティは、データ送信者に代わってRSVPを呼び出し、RSVPパスメッセージを生成し、最終的にRESVメッセージを受信、処理、およびシンクする必要があります。このエンティティをRSVP送信者プロキシと呼びます。2番目のケースでは、ネットワーク内のエンティティはレシーバーに代わってRSVPを操作する必要があり、したがって、データ送信者（またはRSVP送信者プロキシ）から送信されたパスメッセージを受信し、生成されたRESVメッセージを使用して生成されたRESVメッセージを持つ人に返信する必要があります。データ受信機。このエンティティをRSVPレシーバープロキシと呼びます。
RSVP Proxy approaches are presented in [RFC5945]. That document also discusses, for each approach, how the reservations controlled by the RSVP Proxy can be synchronized with the application requirements (e.g., when to establish, maintain, and tear down the RSVP reservation to satisfy application requirements).
RSVPプロキシアプローチは[RFC5945]に示されています。また、このドキュメントでは、各アプローチについて、RSVPプロキシによって制御される予約をアプリケーション要件と同期する方法についても説明しています（たとえば、アプリケーション要件を満たすためにRSVP予約を確立、維持、取り壊す時期など）。
One RSVP Proxy approach is referred to as the Path-Triggered RSVP Receiver Proxy approach. With this approach, the RSVP Receiver Proxy uses the RSVP Path messages generated by the sender (or RSVP Sender Proxy) as the cue for establishing the RSVP reservation on behalf of the non-RSVP-capable receiver(s). The RSVP Receiver Proxy is effectively acting as an intermediary making reservations (on behalf of the receiver) under the sender's control (or RSVP Sender Proxy's control). This somewhat changes 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 (or RSVP Sender Proxy).
1つのRSVPプロキシアプローチは、パストリガーされたRSVPレシーバープロキシアプローチと呼ばれます。このアプローチにより、RSVPレシーバープロキシは、RSVP対応の受信者に代わってRSVP予約を確立するためのキューとして、送信者（またはRSVP Sender Proxy）によって生成されたRSVPパスメッセージを使用します。RSVPレシーバープロキシは、送信者のコントロール（またはRSVP送信者プロキシのコントロール）の下で（レシーバーに代わって）留保を（またはレシーバーに代わって）実質的に機能しています。これにより、予約が通常受信機によって制御される通常のRSVP予約モデルが多少変更されます。このような変更により、ここでの関心のシナリオでの操作が大幅に促進されます。これは、レシーバーがRSVP対応ではない場合です。実際、RSVPレシーバープロキシは、送信者（またはRSVP Sender Proxy）のアプリケーション認識とRSVP認識を活用することにより、アプリケーションとアウェアのままになります。
Since the synchronization between an RSVP reservation and an application is now effectively performed by the sender (or RSVP Sender Proxy), it is important that the sender (or RSVP Sender Proxy) is aware of the reservation state. However, as conventional RSVP assumes that the reservation is to be controlled by the receiver, some notifications about reservation state (notably the error message sent in the case of admission control rejection of the reservation) are only sent towards the receiver and therefore, in our case, sunk by the RSVP Receiver Proxy. Section 3 of this document specifies extensions to RSVP procedures allowing such notifications to be also conveyed towards the sender. This facilitates synchronization by the sender (or RSVP Sender Proxy) between the RSVP reservation and the application requirements, and it facilitates sender-driven control of reservation in scenarios involving a Path-Triggered RSVP Receiver Proxy.
RSVP予約とアプリケーションとの間の同期は、送信者（またはRSVP Sender Proxy）によって効果的に実行されるようになりました。Sender（またはRSVP Sender Proxy）が予約状態を認識することが重要です。ただし、従来のRSVPは予約が受信機によって制御されることを想定しているため、予約状態に関する一部の通知（特に予約の入場制御拒否の場合に送信されたエラーメッセージは、レシーバーにのみ送信されます。RSVPレシーバープロキシによって沈むケース。このドキュメントのセクション3では、RSVPプロシージャへの拡張機能を指定して、このような通知を送信者にも伝えることができます。これにより、RSVP予約とアプリケーション要件の間の送信者（またはRSVP送信者プロキシ）による同期が容易になり、パストリガーされたRSVP受信機プロキシを含むシナリオでの予約の送信者主導の制御が容易になります。
With unicast applications in the presence of RSVP Receiver Proxies, if the sender is notified about the state of the reservation towards the receiver (as enabled by this document), the sender is generally in a good position to synchronize the reservation with the application and to perform efficient sender-driven reservation: the sender can control the establishment or removal of the reservation towards the receiver by sending Path or PathTear messages, respectively. For example, if the sender is notified that the reservation for a point-to-point audio session towards the receiver is rejected, the sender may trigger rejection of the session at the application layer and may issue a PathTear message to remove any corresponding RSVP state (e.g., Path states) previously established.
RSVP受信機プロキシの存在下でユニキャストアプリケーションを使用すると、送信者がレシーバーへの予約の状態について通知された場合（このドキュメントで有効になっている場合）、送信者は通常、申請と予約を同期させるための適切な位置にあります。効率的な送信者駆動型予約を実行する：送信者は、それぞれパスまたはPathTearメッセージを送信することにより、レシーバーへの予約の確立または削除を制御できます。たとえば、送信者が受信機に向けてポイントツーポイントオーディオセッションの予約が拒否されたことを通知された場合、送信者はアプリケーションレイヤーでセッションの拒否を引き起こす可能性があり、対応するRSVP状態を削除するPATHTEARメッセージを発行する場合があります。（例えば、パス状態）以前に確立された。
However, we note that multicast applications do not always coexist well with RSVP Receiver Proxies, since sender notification about reservation state towards each RSVP Receiver Proxy may not be sufficient to achieve tight application-level synchronization by multicast senders. These limitations stem from the fact that multicast operation is receiver driven and, while end-to-end RSVP is also receiver driven (precisely to deal with multicast efficiently), the use of RSVP Receiver Proxies only allows sender-driven reservation. For example, a sender generally is not aware of which receivers have joined downstream of a given RSVP Receiver Proxy, or even which RSVP Receiver Proxies have joined downstream of a given failure point. Therefore, it may not be possible to support a mode of operation whereby a given receiver only joins a group if that receiver benefits from a reservation. Additionally, a sender may have no recourse if only a subset of RSVP Receiver Proxies return successful reservations (even if application-level signaling runs between the sender and receivers), since the sender may not be able to correctly identify the set of receivers who do not have reservations. However, it is possible to support a mode of operation whereby multicast traffic is transmitted if and only if all receivers benefit from a reservation (from sender to their respective RSVP Receiver Proxy): the sender can ensure this by sending a PathTear message and stopping transmission whenever it gets a notification for reservation reject for one or more RSVP Receiver Proxies. It is also possible to support a mode of operation whereby receivers join independently of whether or not they can benefit from a reservation (to their respective RSVP Receiver Proxy), but do benefit from a reservation whenever the corresponding resources are reservable on the relevant path.
ただし、各RSVP受信機プロキシに対する予約状態に関する送信者通知は、マルチキャスト送信者による緊密なアプリケーションレベルの同期を達成するのに十分ではない可能性があるため、マルチキャストアプリケーションはRSVPレシーバープロキシと常にうまく共存しているわけではないことに注意してください。これらの制限は、マルチキャスト操作が受信機駆動型であり、エンドツーエンドのRSVPもレシーバー駆動型であるが（マルチキャストを効率的に処理するため）、RSVPレシーバープロキシの使用は送信者駆動型の予約のみを可能にするという事実に起因します。たとえば、送信者は一般に、どのレシーバーが特定のRSVPレシーバープロキシの下流に参加したか、またはどのRSVPレシーバープロキシが特定の障害点の下流に参加したかを認識していません。したがって、そのレシーバーが予約の恩恵を受けた場合、特定のレシーバーがグループにのみ参加する操作モードをサポートすることはできない場合があります。さらに、送信者は、RSVPレシーバーのプロキシのサブセットだけが予約を成功させた場合（送信者と受信機の間でアプリケーションレベルのシグナリングが実行されたとしても）、リコースを持たない場合があります。予約はありません。ただし、すべてのレシーバーが予約（送信者からそれぞれのRSVPレシーバープロキシまで）の恩恵を受ける場合にのみ、マルチキャストトラフィックが送信される操作モードをサポートすることができます：送信者は、PATHTEARメッセージを送信して送信を停止することでこれを確実にすることができます予約の通知を取得するたびに、1つ以上のRSVPレシーバープロキシの拒否。また、レシーバーが予約（それぞれのRSVPレシーバープロキシ）の恩恵を受けることができるかどうかとは独立して結合する操作モードをサポートすることも可能ですが、関連するパスで対応するリソースが予約可能である場合はいつでも予約の恩恵を受けます。
This document discusses extensions to facilitate operations in the presence of a Path-Triggered RSVP Receiver Proxy. As pointed out previously, those apply equally whether RSVP signaling is initiated by a regular RSVP sender or by an RSVP Sender Proxy (with some means to synchronize reservation state with application-level requirements that are outside the scope of this document). For readability, the rest of this document discusses operations assuming a regular RSVP sender; however, such an operation is equally applicable where an RSVP Sender Proxy is used to initiated RSVP signaling on behalf of a non-RSVP-capable sender.
このドキュメントでは、パストリガーされたRSVPレシーバープロキシの存在下での操作を容易にするための拡張機能について説明します。前に指摘したように、それらはRSVPシグナル伝達が通常のRSVP送信者によって開始されるか、RSVP送信者プロキシによって開始されるかどうかを等しく適用します（このドキュメントの範囲外のアプリケーションレベルの要件と予約状態を同期するための何らかの手段）。読みやすさのために、このドキュメントの残りの部分では、通常のRSVP送信者を仮定した操作について説明します。ただし、このような操作は、RSVP送信者プロキシを使用して、非RSVP対応の送信者に代わってRSVPシグナリングを開始する場合に等しく適用できます。
As discussed in [RFC5945], 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. Thus, the purpose of this document 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.
[RFC5945]で説明したように、強く推奨されているRSVP展開モデルは、送信者と受信者のRSVPサポートを伴う[RFC2205]で想定されているように終了し続けることに留意することが重要です。エンドツーエンドモデルにより、予約要件とアプリケーション要件との間の最も効果的な同期が可能になります。また、エンドツーエンドのRSVPモデルと比較すると、RSVPプロキシの使用には、追加の運用上の負担が含まれます。したがって、このドキュメントの目的は、RSVPが環境に固有の理由で一部の送信者や一部のレシーバーで使用できない特別環境でのRSVPの展開を許可することです。
Section 4.1.1 of [RFC5945] discusses mechanisms allowing the RSVP reservation for a given flow to be dynamically extended downstream of an RSVP Proxy whenever possible (i.e., when the receiver is RSVP-capable or when there is another RSVP Receiver Proxy downstream). This can considerably alleviate the operational burden and the topological constraints associated with Path-Triggered RSVP Receiver Proxies. This allows (without corresponding manual configuration) an RSVP reservation to dynamically span as much of the corresponding flow path as possible, with any arbitrary number of RSVP Receiver Proxies on the flow path and whether or not the receiver is RSVP-capable. In turn, this facilitates migration from an RSVP deployment model based on Path-Triggered Receiver Proxies to an end-to-end RSVP model, since receivers can gradually and independently be upgraded to support RSVP and then instantaneously benefit from end-to-end reservations. Section 4 of this document specifies these mechanisms and associated RSVP extensions.
[RFC5945]のセクション4.1.1は、可能な限りRSVPプロキシの下流にある特定のフローのRSVP予約を可能にするメカニズムについて説明します。これにより、パストリガーされたRSVPレシーバープロキシに関連する運用上の負担とトポロジカルな制約を大幅に軽減できます。これにより、（対応する手動構成なしで）RSVPの予約が可能になり、対応するフローパスができるだけ多くのフローパスに及び、フローパスでの任意の数のRSVPレシーバープロキシと、レシーバーがRSVP対応であるかどうかが可能になります。これにより、受信機を徐々に独立してアップグレードしてRSVPをサポートし、エンドツーエンドの予約から即座に利益を得ることができるため、パストリガーレシーバープロキシに基づくRSVP展開モデルからエンドツーエンドのRSVPモデルへの移行が促進されます。。このドキュメントのセクション4では、これらのメカニズムと関連するRSVP拡張機能を指定しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The following terminology is borrowed from [RFC5945] and is used extensively in this document:
次の用語は[RFC5945]から借用されており、このドキュメントで広く使用されています。
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 normally would 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 nor as an RSVP Sender Proxy.
o 通常のRSVPルーター：RSVP受信機プロキシとしてもRSVP Sender Proxyとしても動作していないRSVP対応ルーター。
Note that the roles of the RSVP Receiver Proxy, RSVP Sender Proxy, and regular RSVP Router are all relative to one 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ルーターの役割はすべて、1つの単方向フローに関連していることに注意してください。特定のルーターは、フローのRSVPレシーバープロキシ、別のフローのRSVP送信者プロキシとして、またさらに別のフローの通常のRSVPルーターとして機能する場合があります。
The following terminology is also used in this document:
このドキュメントでは、次の用語も使用されています。
o Regular RSVP sender: an RSVP-capable host behaving as the sender for the considered flow and participating in RSVP signaling in accordance with the sender behavior specified in [RFC2205].
o 通常のRSVP送信者：[RFC2205]で指定された送信者行動に従って、考慮されたフローの送信者として動作し、RSVPシグナル伝達に参加するRSVP対応ホスト。
o Regular RSVP receiver: an RSVP-capable host behaving as the receiver for the considered flow and participating in RSVP signaling in accordance with the receiver behavior specified in [RFC2205].
o 通常のRSVPレシーバー：[RFC2205]で指定されたレシーバーの動作に従って、考慮されたフローの受信機として動作し、RSVPシグナル伝達に参加するRSVP対応ホスト。
This section defines extensions to RSVP procedures allowing sender notification of reservation failure. This facilitates synchronization by the sender between RSVP reservation and application requirements in scenarios involving a Path-Triggered RSVP Receiver Proxy.
このセクションでは、RSVP手順への拡張機能を定義して、予約障害の送信者通知を可能にします。これにより、パストリガーされたRSVPレシーバープロキシを含むシナリオで、RSVP予約とアプリケーション要件の間の送信者による同期が容易になります。
As discussed in [RFC5945], 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. On receipt of the RSVP Path message, the RSVP Receiver Proxy:
[RFC5945]で説明したように、パストリガーされたRSVPレシーバープロキシアプローチを使用して、RSVPルーターは、RSVPレシーバープロキシ動作のトリガーとして通常のRSVPパスメッセージの受信を使用するように構成されている場合があります。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 corresponding Resv message (on its way upstream from the receiver) was received on the downstream interface. This includes performing admission control on the downstream interface, establishing a Resv state (in the 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メッセージの定期的な更新の送信、パス状態が引き裂かれた場合の予約を引き裂くことが含まれます。。
Operation of the Path-Triggered Receiver Proxy in the case of a successful reservation is illustrated in Figure 1.
予約が成功した場合のパストリガーレシーバープロキシの操作を図1に示します。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv-- <---Resv-- <---Resv--
===================RSVP===================>
************************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
==> segment of flow path benefiting from an RSVP reservation
Figure 1: Successful Reservation
図1：予約の成功
We observe that, in the case of successful reservation, conventional RSVP procedures ensure that the sender is notified of the successful reservation establishment. Thus, no extensions are required in the presence of a Path-Triggered RSVP Receiver Proxy in the case of successful reservation establishment.
予約が成功した場合、従来のRSVP手順により、送信者に予約施設が成功したことが保証されていることがわかります。したがって、予約施設が成功した場合、パストリガーされたRSVPレシーバープロキシの存在下では、拡張機能は必要ありません。
However, in the case of reservation failure, conventional RSVP procedures ensure only that the receiver (or the RSVP Receiver Proxy) is notified of the reservation failure. Specifically, in the case of an admission control rejection on a regular RSVP router, a ResvErr message is sent downstream towards the receiver. In the presence of an RSVP Receiver Proxy, if we simply follow conventional RSVP procedures, this means that the RSVP Receiver Proxy is notified of the reservation failure, but the sender is not. Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, assuming conventional RSVP procedures, is illustrated in Figure 2.
ただし、予約の障害の場合、従来のRSVP手順により、受信者（またはRSVPレシーバープロキシ）が予約障害を通知されることのみを保証します。具体的には、通常のRSVPルーターでの入場制御拒否の場合、RESVERRメッセージがレシーバーに向かって下流に送信されます。RSVP受信機プロキシが存在する場合、従来のRSVP手順に従うだけの場合、これはRSVPレシーバープロキシに予約障害が通知されることを意味しますが、送信者はそうではありません。従来のRSVP手順を仮定して、入場制御障害の場合にパストリガーされたRSVP受信機プロキシの動作を図2に示します。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv--
<--- resv-- <--- resv--
-ResvErr-> -ResvErr->
===================RSVP===================>
************************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
==> segment of flow path benefiting from an RSVP reservation
Figure 2: Reservation Failure with Conventional RSVP
図2：従来のRSVPによる予約障害
While the sender could infer reservation failure from the fact that it has not received a Resv message after a certain time, there are clear benefits to ensuring that the sender gets a prompt, explicit notification in the case of reservation failure. This includes faster end-user notification at the application layer (e.g., busy signal) and faster application-level reaction (e.g., application-level rerouting), as well as faster release of application-level resources.
送信者は、特定の時間の後にRESVメッセージを受信していないという事実から予約の失敗を推測することができますが、予約障害の場合に送信者が迅速で明示的な通知を取得できるようにするには明確な利点があります。これには、アプリケーションレイヤーでのエンドユーザー通知の高速化（忙しい信号など）およびアプリケーションレベルの反応が高速（アプリケーションレベルの再ルーティングなど）、およびアプリケーションレベルのリソースの高速リリースが含まれます。
Section 3.1 defines a method that can be used to achieve sender notification of reservation failure. A router implementation claiming compliance with this document MUST support the method defined in Section 3.1.
セクション3.1は、予約障害の送信者通知を達成するために使用できる方法を定義します。このドキュメントへのコンプライアンスを主張するルーターの実装は、セクション3.1で定義されている方法をサポートする必要があります。
Section 3.2 defines another method that can be used to achieve sender notification of reservation failure. A router implementation claiming compliance with this document MAY support the method defined in Section 3.2.
セクション3.2では、予約障害の送信者通知を達成するために使用できる別の方法を定義します。このドキュメントのコンプライアンスを主張するルーターの実装は、セクション3.2で定義されている方法をサポートする場合があります。
In a given network environment, a network administrator may elect to use the method defined in Section 3.1, the method defined in Section 3.2, or possibly combine the two.
特定のネットワーク環境では、ネットワーク管理者は、セクション3.1で定義されているメソッド、セクション3.2で定義されているメソッドを使用することを選択できます。
With this method, the RSVP Receiver Proxy MUST generate a PathErr message whenever the two following conditions are met:
この方法では、RSVP受信機プロキシは、次の2つの条件が満たされるたびにPatherRメッセージを生成する必要があります。
1. The reservation establishment has failed (or the previously established reservation has been torn down).
1. 予約施設は失敗しました（または以前に確立された予約は取り壊されました）。
2. The RSVP Receiver Proxy determines that it cannot re-establish the reservation (e.g., by adapting its reservation request in reaction to the error code provided in the received ResvErr in accordance with local policy).
2. RSVPレシーバーのプロキシは、予約を再確立できないと判断します（たとえば、現地ポリシーに従って受信したRESVERRで提供されたエラーコードに対応して予約要求を適応させることにより）。
Note that this notion of generating a PathErr message upstream in order to notify the sender about a reservation failure is not completely new. It is borrowed from [RFC3209] where it was introduced in order to satisfy a similar requirement, which is to allow an MPLS Traffic Engineering (TE) Label Switching Router to notify the TE Tunnel head-end (i.e., the sender) of a failure to establish (or maintain) a TE Tunnel Label Switch Path.
予約障害について送信者に通知するために上流のPatherrメッセージを生成するというこの概念は完全に新しいものではないことに注意してください。同様の要件を満たすために導入された[RFC3209]から借用されています。これは、MPLSトラフィックエンジニアリング（TE）ラベルスイッチルーターを許可するために、障害のTEトンネルヘッドエンド（つまり、送信者）にTEトンネルヘッドエンド（つまり、送信者）に通知することを許可します。TEトンネルラベルスイッチパスを確立（または維持）します。
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, using sender notification via a PathErr message, is illustrated in Figure 3.
PATHERRメッセージを介した送信者通知を使用して、入場制御障害の場合にパストリガーされたRSVP受信機プロキシの操作を図3に示します。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv--
<--- resv-- <--- resv--
-ResvErr-> -ResvErr->
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================RSVP===================>
************************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
==> segment of flow path benefiting from RSVP (but not benefiting from a reservation in this case)
==> RSVPの恩恵を受けるフローパスのセグメント（ただし、この場合の予約の恩恵を受けていません）
Figure 3: Reservation Failure with Sender Notification via PathErr
図3：Patherr経由の送信者通知による予約障害
The role of this PathErr is to notify the sender that the reservation was not established or was torn down. This may be in the case of receipt of a ResvErr, or because of local failure on the Receiver Proxy. On receipt of a ResvErr, in all situations where the reservation cannot be installed, the Receiver Proxy MUST generate a PathErr towards the sender. For local failures on the Receiver Proxy node, if a similar failure on an RSVP midpoint would cause the generation of a ResvErr (for example, admission control failure), the Receiver Proxy MUST generate a PathErr towards the sender. The Receiver Proxy MAY additionally generate a PathErr upon local failures that would not ordinarily cause generation of a ResvErr message, such as those described in Appendix B of [RFC2205].
このPatherrの役割は、予約が確立されていないか、取り壊されたことを送信者に通知することです。これは、RESVERRの受領の場合、または受信機プロキシの局所障害のためにある場合があります。RESVERRを受け取ったとき、予約をインストールできないすべての状況で、受信機プロキシは送信者に向かってPatherRを生成する必要があります。受信機プロキシノードの局所障害の場合、RSVP中点で同様の障害がRESVERRの生成を引き起こす場合（たとえば、入場制御障害）、受信機プロキシは送信者に対してPatherRを生成する必要があります。受信機プロキシは、[RFC2205]の付録Bに記載されているようなものなど、通常、RESVERRメッセージの生成を引き起こさない局所障害にPatherRを生成する場合があります。
The PathErr generated by the Receiver Proxy corresponds to the sender(s) that triggered generation of Resv messages that failed. For FF-style (Fixed-Filter) reservations, the Receiver Proxy MUST send a PathErr towards the (single) sender matching the failed reservation. For SE-style (Shared-Explicit) reservations, the Receiver Proxy MUST send the PathErr(s) towards the set of senders that triggered reservations that failed. This may be a subset of senders sharing the same reservation, in which case the remaining senders would have their reservation intact and would not receive a PathErr. In both cases, the rules described in Section 3.1.8 of [RFC2205] for generating flow descriptors in ResvErr messages also apply when generating sender descriptors in PathErr messages.
受信機プロキシによって生成されたPatherrは、失敗したRESVメッセージの生成をトリガーした送信者に対応します。FFスタイル（固定フィルター）の予約の場合、受信機プロキシは、失敗した予約に一致する（単一の）送信者にPatherrを送信する必要があります。SEスタイルの（共有エクスプリティ）予約の場合、受信機プロキシは、失敗した予約をトリガーした送信者のセットにPatherrを送信する必要があります。これは、同じ予約を共有する送信者のサブセットである可能性があります。その場合、残りの送信者は予約をそのままにし、Patherrを受け取りません。どちらの場合も、RESVERRメッセージでフロー記述子を生成するための[RFC2205]のセクション3.1.8で説明されているルールも、PatherRメッセージで送信者記述子を生成するときに適用されます。
For WF-style (Wildcard-Filter) reservations, it is not always possible for the Receiver Proxy to reliably know which sender caused the reservation failure. Therefore, the Receiver Proxy SHOULD send a PathErr towards each sender. This means that all the senders will receive a notification that the reservation is not established, including senders that did not cause the reservation failure. Therefore, the method of sender notification via a PathErr message is somewhat overly conservative (i.e., in some cases, rejecting reservations from some senders when those could have actually been established) when used in combination with the Wildcard-Filter style (and when there is more than one sender).
WFスタイル（WildCard-Filter）の予約の場合、受信機プロキシがどのセンダーが予約障害を引き起こしたかを確実に知ることが常に可能ではありません。したがって、受信機プロキシは、各送信者にPatherrを送信する必要があります。これは、すべての送信者が、予約の障害を引き起こさない送信者を含む予約が確立されないという通知を受け取ることを意味します。したがって、Patherrメッセージを介した送信者通知の方法は、WildCard-Filterスタイルと組み合わせて使用する場合（そして、あるときに実際に確立された場合、一部の送信者からの予約を拒否します）（つまり、場合によっては、一部の送信者からの予約を拒否することもあります）複数の送信者）。
The sender notification via the PathErr method applies to both unicast and multicast sessions. However, for a multicast session, it is possible that reservation failure (e.g., admission control failure) in a node close to a sender may cause ResvErr messages to be sent to a large group of Receiver Proxies. These Receiver Proxies would, in turn, all send PathErr messages back to the same sender, which could cause a scalability issue in some environments.
Patherrメソッドを介した送信者通知は、Unicastセッションとマルチキャストセッションの両方に適用されます。ただし、マルチキャストセッションでは、送信者に近いノード内の予約障害（入場制御の失敗など）により、RESVERRメッセージがレシーバープロキシの大規模なグループに送信される可能性があります。これらのレシーバープロキシは、すべてが同じ送信者にPatherrメッセージを送り返し、一部の環境でスケーラビリティの問題を引き起こす可能性があります。
From the perspective of the sender, errors that prevent a reservation from being set up can be classified in two ways:
送信者の観点から見ると、予約がセットアップされるのを防ぐエラーは、次の2つの方法で分類できます。
1. Errors that the sender can attempt to correct. The error code for these errors should explicitly be communicated back to the sender. An example of this is "Code 1: Admission Control Failure", because the sender could potentially resend a Path message with smaller traffic parameters.
1. 送信者が修正しようとするエラー。これらのエラーのエラーコードは、送信者に明示的に通信する必要があります。この例は、「コード1：入場管理の失敗」です。これは、送信者がトラフィックパラメーターが小さいパスメッセージを再送信できる可能性があるためです。
2. Errors over which the sender has no control. For these errors, it is sufficient to notify the sender that the reservation was not set up successfully. An example of this is "Code 13: Unknown Object", because the sender has no control over the objects inserted into the reservation by the Receiver Proxy.
2. 送信者が制御できないエラー。これらのエラーについては、予約が正常に設定されていないことを送信者に通知するだけで十分です。この例は、「コード13：不明オブジェクト」です。送信者は、受信機プロキシによって予約に挿入されたオブジェクトを制御できないためです。
The PathErr message generated by the Receiver Proxy has the same format as regular PathErr messages defined in [RFC2205]. The SESSION, ERROR_SPEC, and sender descriptor are composed by the Receiver Proxy as specified in the following subsections. The Receiver Proxy MAY reflect back towards the sender in the PathErr any POLICY_DATA objects received in the ResvErr.
受信機プロキシによって生成されたPATHERRメッセージは、[RFC2205]で定義された通常のPatherRメッセージと同じ形式を持っています。セッション、ERROR_SPEC、および送信者記述子は、以下のサブセクションで指定されているように、受信機プロキシによって作成されます。受信機プロキシは、RESVERRで受け取ったPolicy_DataオブジェクトをPatherの送信者に振り返ることができます。
The Receiver Proxy MUST insert the SESSION object corresponding to the failed reservation into the PathErr. For FF-style reservations, the Receiver Proxy MUST insert a sender descriptor corresponding to the failed reservation into the PathErr. This is equal to the error flow descriptor in the ResvErr received by the Receiver Proxy. For SE-style reservations, the Receiver Proxy MUST insert a sender descriptor corresponding to the sender triggering the failed reservation into the PathErr. This is equal to the error flow descriptor in the ResvErr received by the Receiver Proxy. If multiple flow descriptors could not be admitted at a midpoint node, that node would generate multiple ResvErr messages towards the receiver as per Section 3.1.8 of [RFC2205]. Each ResvErr would contain an error flow descriptor that matches a specific sender. The Receiver Proxy MUST generate a PathErr for each ResvErr received towards the corresponding sender. As specified earlier, for WF-style reservations, the Receiver Proxy SHOULD send a PathErr to each sender.
受信機プロキシは、Patherrへの予約の失敗に対応するセッションオブジェクトを挿入する必要があります。FFスタイルの予約の場合、受信機プロキシは、PATHERRへの留保の失敗に対応する送信者記述子を挿入する必要があります。これは、受信機プロキシが受信したRESVERRのエラーフロー記述子に等しくなります。SEスタイルの予約の場合、受信機プロキシは、Patherrへの予約の失敗をトリガーする送信者に対応する送信者記述子を挿入する必要があります。これは、受信機プロキシが受信したRESVERRのエラーフロー記述子に等しくなります。ミッドポイントノードで複数のフロー記述子を認めることができなかった場合、そのノードは[RFC2205]のセクション3.1.8に従って、受信機に向けて複数のRESVERRメッセージを生成します。各resverrには、特定の送信者に一致するエラーフロー記述子が含まれます。受信機プロキシは、対応する送信者に向けて受信した各resverrに対してpatherrを生成する必要があります。前述のように、WFスタイルの予約については、受信機プロキシは各送信者にPatherrを送信する必要があります。
The Receiver Proxy MUST compose the ERROR_SPEC to be inserted into the PathErr as follows:
受信機プロキシは、次のようにeRRER_SPECをPATHERRに挿入する必要があります。
1. If the Receiver Proxy receives a ResvErr with either of these error codes -- "Code 1: Admission Control Failure" or "Code 2: Policy Control Failure" -- then the Receiver Proxy copies the error code and value from the ERROR_SPEC in the ResvErr into the ERROR_SPEC of the PathErr message. The error node in the PathErr MUST be set to the address of the Receiver Proxy. This procedure MUST also be followed for a local error on the Receiver Proxy that would ordinarily cause a midpoint to generate a ResvErr with one of the above codes.
1. レシーバープロキシがこれらのエラーコードのいずれかを備えたRESVERRを受信した場合、「コード1：入場制御障害」または「コード2：ポリシー制御障害」 - レシーバープロキシは、RESVERRのERROR_SPECからエラーコードと値をコピーします。patherrメッセージのerror_specに。Patherrのエラーノードは、受信機プロキシのアドレスに設定する必要があります。また、この手順には、通常の中間点が上記のコードのいずれかを備えたRESVERRを生成するようにするレシーバープロキシのローカルエラーについても実行する必要があります。
2. If the Receiver Proxy receives a ResvErr with any error code except the ones listed in item 1 above, it composes a new ERROR_SPEC with error code "36: Unrecoverable Receiver Proxy Error". The error node address in the PathErr MUST be set to the address of the Receiver Proxy. This procedure MUST also be followed for a local error on the Receiver Proxy that would ordinarily cause a midpoint to generate a ResvErr with any error code other than those listed in item 1 above, or if the Receiver Proxy generates a PathErr for a local error that ordinarily would not cause generation of a ResvErr. In some cases, it may be predetermined that the PathErr will not reach the sender. For example, a node receiving a ResvErr with "Code 3: No Path for Resv", knows a priori that the PathErr message it generates cannot be forwarded by the same node that could not process the Resv. Nevertheless, the procedures above MUST be followed. For the error code "36: Unrecoverable Receiver Proxy Error", the 16 bits of the Error Value field are:
2. 受信機プロキシが、上記のアイテム1にリストされているものを除くエラーコードを除いてRESVERRを受信した場合、エラーコード「36：Recoverable Receiver Proxyエラー」を使用して新しいERROR_SPECを構成します。Patherrのエラーノードアドレスは、受信機プロキシのアドレスに設定する必要があります。また、この手順は、上記のアイテム1に記載されているもの以外のエラーコードを備えた中間点を生成する、または受信機プロキシがローカルエラーのPatherrを生成する場合、ミッドポイントをresvotrrを生成するために、受信機プロキシのローカルエラーについても実行する必要があります。通常、Resverrの生成を引き起こしません。場合によっては、Patherrが送信者に到達しないことが事前に決定される場合があります。たとえば、「コード3：RESVのパスなし」のRESVERRを受信するノードは、生成するPatherRメッセージをRESVを処理できない同じノードで転送できないという先験的なものを知っています。それにもかかわらず、上記の手順に従う必要があります。エラーコード「36：回復可能なレシーバープロキシエラー」の場合、エラー値フィールドの16ビットは次のとおりです。
* hhhh hhhh llll llll
* hhhhhhh llll llll
where the bits are:
ビットがある場所：
* hhhh hhhh = 0000 0000: then the low order 8 bits (llll llll) MUST be set by Receiver Proxy to 0000 0000 and MUST be ignored by the sender.
* HHHH HHHH = 0000 0000：その後、低次8ビット（LLLL LLLL）は、レシーバープロキシによって0000 0000に設定する必要があり、送信者は無視する必要があります。
* hhhh hhhh = 0000 0001: then the low order 8 bits (llll llll) MUST be set by the Receiver Proxy to the value of the error code received in the ResvErr ERROR_SPEC (or, in case the Receiver Proxy generated the PathErr without having received a ResvErr, to the error code value that would have been included by the Receiver Proxy in the ERROR_SPEC in similar conditions if it was to generate a ResvErr). This error value MAY be used by the sender to further interpret the reason for the reservation failure.
* hhhh hhhh = 0000 0001：その後、レシーバーのプロキシによって、resverr error_specで受信されたエラーコードの値（または、受信者プロキシがPatherrを生成した場合に受信した場合にPatherrを生成した場合に、低次8ビット（llll llll）を設定する必要があります。RESVERR、RESVERRを生成する場合、同様の条件でERROR_SPECのレシーバープロキシによって含まれていたエラーコード値まで。このエラー値は、予約障害の理由をさらに解釈するために送信者が使用する場合があります。
* hhhh hhhh = any other value: reserved.
* HHHH HHHH =その他の値：予約されています。
3. If the Receiver Proxy receives a ResvErr with the InPlace flag set in the ERROR_SPEC, it MUST also set the InPlace flag in the ERROR_SPEC of the PathErr.
3. Receiver Proxyがerror_Specに設定されたInplaceフラグを備えたResverrを受信した場合、PatherrのERROR_SPECにInplaceフラグを設定する必要があります。
[RFC3473] defines an optional behavior whereby a node forwarding a PathErr message can remove the Path state associated with the PathErr message and indicate so by including the Path_State_Removed flag in the ERROR_SPEC object of the PathErr message. This can be used in some situations to expedite release of resources and minimize signaling load.
[RFC3473]は、PATHERRメッセージに関連付けられたパス状態を削除し、PATHERRメッセージのERROR_SPECオブジェクトにPATH_STATE_REMOVEDフラグを含めることにより、PATHERRメッセージに関連するパス状態を削除できるオプションの動作を定義します。これは、リソースのリリースを促進し、シグナリング負荷を最小限に抑えるために、状況によっては使用できます。
This section discusses aspects of the use of the Path_State_Removed flag that are specific to the RSVP Receiver Proxy. In any other aspects, the Path_State_Removed flag operates as per [RFC3473].
このセクションでは、RSVPレシーバープロキシに固有のPATH_STATE_REMOVEDフラグの使用の側面について説明します。他の面では、path_state_removedフラグは[RFC3473]に従って動作します。
By default, the RSVP Receiver Proxy MUST NOT include the Path_State_Removed flag in the ERROR_SPEC of the PathErr message. This ensures predictable operations in all environments including those where some RSVP routers do not understand the Path_State_Removed flag.
デフォルトでは、RSVPレシーバープロキシには、PATHERRメッセージのERROR_SPECにPATH_STATE_REMOVEDフラグを含めてはなりません。これにより、一部のRSVPルーターがPATH_STATE_REMOVEDフラグを理解していないものを含むすべての環境での予測可能な操作が保証されます。
The RSVP Receiver Proxy MAY support an OPTIONAL mode (to be activated by configuration) whereby the RSVP Receiver Proxy includes the Path_State_Removed flag in the ERROR_SPEC of the PathErr message and removes its local Path state. When all routers on the path of a reservation support the Path_State_Removed flag, its use will indeed result in expedited resource release and reduced signaling. However, if there are one or more RSVP routers on the path of the reservation that do not support the Path_State_Removed flag (we refer to such routers as "old RSVP routers"), the use of the Path_State_Removed flag will actually result in slower resource release and increased signaling. This is because the Path_State_Removed flag will be propagated upstream by an old RSVP router (even if it does not understand it and does not tear its Path state). Thus, the sender will not send a Path Tear, and the old RSVP router will release its Path state only through refresh time-out. A network administrator needs to keep these considerations in mind when deciding whether to activate the use of the Path_State_Removed flag on the RSVP Receiver Proxy. In a controlled environment where all routers are known to support the Path_State_Removed flag, its use can be safely activated on the RSVP Receiver Proxy. In other environments, the network administrator needs to assess whether the improvement achieved with some reservations outweighs the degradation experienced by other reservations.
RSVPレシーバープロキシは、RSVPレシーバープロキシにPATHERRメッセージのERROR_SPECにPATH_STATE_REMOVEDフラグが含まれ、ローカルパス状態を削除するオプションモード（構成によってアクティブ化される）をサポートする場合があります。予約のパス上のすべてのルーターがPATH_STATE_REMOVEDフラグをサポートすると、その使用により、リソースのリリースが促進され、シグナル伝達が削減されます。ただし、Path_State_Removedフラグをサポートしていない予約のパスに1つ以上のRSVPルーターがある場合（そのようなルーターを「古いRSVPルーター」と呼んでいます）、Path_State_Removedフラグの使用は実際にリソースのリリースが遅くなりますシグナル伝達の増加。これは、Path_State_Removedフラグが古いRSVPルーターによって上流に伝播されるためです（たとえそれを理解せず、パス状態を引き裂かない場合でも）。したがって、送信者はパスの裂け目を送信せず、古いRSVPルーターはリフレッシュタイムアウトによってのみパス状態を解放します。ネットワーク管理者は、RSVPレシーバープロキシでPATH_STATE_REMOVEDフラグの使用をアクティブにするかどうかを決定する際に、これらの考慮事項を念頭に置いておく必要があります。すべてのルーターがpath_state_removedフラグをサポートすることが知られている制御環境では、その使用をRSVPレシーバープロキシで安全にアクティブ化できます。他の環境では、ネットワーク管理者は、いくつかの予約で達成された改善が他の予約によって経験される劣化を上回るかどうかを評価する必要があります。
Note that while this document specifies that an RSVP Receiver Proxy generates a PathErr upstream in the case of reservation failure, this document does NOT propose that the same be done by regular receivers. In other words, this document does NOT propose modifying the behavior of regular receivers as currently specified in [RFC2205]. The rationale for this includes the following:
このドキュメントは、RSVPレシーバープロキシが予約障害の場合に上流のPatherrを生成することを指定しているが、このドキュメントは通常の受信機によって同じことを行うことを提案していないことに注意してください。言い換えれば、この文書は、現在[RFC2205]で指定されているように、通常の受信機の動作を変更することを提案していません。これの理論的根拠には、次のものが含まれます。
o When the receiver is RSVP-capable, the current receiver-driven model of [RFC2205] is fully applicable because the receiver can synchronize RSVP reservation state and application state (since it participates in both). The sender(s) need not be aware of the RSVP reservation state. Thus, we can retain the benefits of receiver-driven operations that were explicitly sought by [RFC2205], which states, "In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS". But even for the simplest single_sender/ single_receiver reservations, the current receiver-driven model reduces signaling load and per-hop RSVP processing by not sending any error message to the sender in case of admission control reject.
o 受信機がRSVP対応の場合、[RFC2205]の現在のレシーバー駆動型モデルは、RSVP予約状態とアプリケーション状態を同期できるため（両方に関与するため）、完全に適用できます。送信者は、RSVP予約状態に注意する必要はありません。したがって、[RFC2205]によって明示的に求められた受信機主導の操作の利点を保持できます。これは、「大規模なグループ、動的グループメンバーシップ、不均一なレシーバー要件に効率的に対応するために、RSVPが特定のリクエストを担当する責任を負わせます。qos "。しかし、最も単純なsingle_sender/ single_receiverの予約でさえ、現在のレシーバー駆動型モデルは、入学制御の拒否の場合にエラーメッセージを送信者に送信しないことにより、シグナリング負荷とホップごとのRSVP処理を削減します。
o The motivation for adding sender error notification in the case of an RSVP Receiver Proxy lies in the fact that the actual receiver can no longer synchronize the RSVP reservation with application state (since the receiver does not participate in RSVP signaling), while the sender can. This motivation does not apply in the case of a regular receiver.
o RSVP受信機プロキシの場合に送信者エラー通知を追加する動機は、実際の受信機がRSVP予約をアプリケーション状態と同期できなくなるという事実にあります（受信者はRSVPシグナリングに参加しないため）、送信者はできます。この動機は、通常のレシーバーの場合には適用されません。
o There is a lot of existing code and deployed systems successfully working under the current [RFC2205] model in the absence of proxy today. The current behavior of existing deployed systems should not be changed unless there were a very strong motivation.
o 現在のプロキシがない場合、現在の[RFC2205]モデルの下で正常に動作する既存のコードと展開システムがたくさんあります。既存の展開されたシステムの現在の動作は、非常に強い動機がなければ変更されるべきではありません。
The OPTIONAL method for sender notification of reservation failure defined in this section aims to provide a more efficient method than the one defined in Section 3.1. Its objectives include:
このセクションで定義されている予約障害の送信者通知のオプションの方法は、セクション3.1で定義されている方法よりも効率的な方法を提供することを目的としています。その目的は次のとおりです。
o allowing the failure notification to be sent directly upstream to the sender by the router where the failure occurs (as opposed to first traveling downstream towards the Receiver Proxy and then traveling upstream from the Receiver Proxy to the sender, as effectively happens with the method defined in Section 3.1).
o 失敗通知を、失敗が発生するルーターによって送信者に直接上流に送られるようにすることができます（最初にレシーバーのプロキシに向かって下流に移動し、次にレシーバープロキシから送信者への上流に移動します。セクション3.1）。
o allowing the failure notification to travel without hop-by-hop RSVP processing.
o ホップバイホップRSVP処理なしで失敗通知を移動できるようにします。
o ensuring that such a notification is sent to senders that are capable and willing to process it (i.e., to synchronize reservation status with application).
o そのような通知が、それを処理することができて喜んでいる送信者に送られるようにします（つまり、予約ステータスをアプリケーションと同期させるため）。
o ensuring that such a notification is only sent in case the receiver is not itself capable and willing to do the synchronization with the application (i.e., because we are in the presence of a Receiver Proxy so that RSVP signaling is not visible to the receiver).
o そのような通知が、受信者自体が能力がなく、アプリケーションと同期することをいとわない場合にのみ送信されることを保証します（つまり、RSVPシグナル伝達が受信機に見えないように受信機プロキシが存在しているため）。
Note, however, that such benefits come at the cost of:
ただし、そのような利点は次の犠牲を払ってもたらされることに注意してください。
o a requirement for RSVP routers and senders to support the Notify messages and procedures defined in [RFC3473].
o RSVPルーターと送信者が[RFC3473]で定義されている通知メッセージと手順をサポートするための要件。
o a requirement for senders to process Notify messages traveling upstream but conveying a downstream notification.
o 上流に移動するメッセージを通知するが、下流の通知を伝える送信者が処理するための要件。
[RFC3473] defines (in Section 4.3, "Notify Messages") the Notify message that provides a mechanism to inform non-adjacent nodes of events related to the RSVP reservation. The Notify message differs from the error messages defined in [RFC2205] (i.e., PathErr and ResvErr messages) in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor and that it is a generalized notification mechanism. Notify messages are normally generated only after a Notify Request object has been received.
[RFC3473]は、RSVP予約に関連するイベントの非隣接ノードを通知するメカニズムを提供する通知メッセージを（セクション4.3、「Notifyメッセージ」）定義しています。Notifyメッセージは、[RFC2205]（すなわち、PatherrおよびResverrメッセージ）で定義されているエラーメッセージとは異なります。通知メッセージは通常、通知要求オブジェクトが受信された後にのみ生成されます。
This section discusses aspects of the use of the Notify message that are specific to the RSVP Receiver Proxy. In any other aspects, the Notify message operates as per [RFC3473].
このセクションでは、RSVPレシーバープロキシに固有のNotifyメッセージの使用の側面について説明します。他の面では、Notifyメッセージは[RFC3473]に従って動作します。
In order to achieve sender notification of reservation failure in the context of this document:
このドキュメントのコンテキストでの予約障害の送信者通知を達成するために：
o An RSVP sender interested in being notified of reservation failure MUST include a Notify Request object (containing the sender's IP address) in the Path messages it generates.
o 予約障害の通知に関心のあるRSVP送信者には、生成するパスメッセージに通知要求オブジェクト（送信者のIPアドレスを含む）を含める必要があります。
o Upon receiving a Path message with a Notify Request object, the RSVP Receiver Proxy MUST include a Notify Request object in the Resv messages it generates. This Notify Request object MUST contain either:
o Notify Requestオブジェクトを使用してパスメッセージを受信すると、RSVP受信機プロキシには、生成するRESVメッセージにNotify Requestオブジェクトを含める必要があります。この通知リクエストオブジェクトには次のいずれかを含める必要があります。
* the address that was included in the Notify Request of the received Path message, a.k.a. the sender's address. We refer to this approach as the "Direct Notify" approach, or
* 受信パスメッセージの通知要求に含まれていたアドレス、A.K.A.送信者のアドレス。このアプローチを「直接通知」アプローチと呼びます。
* an address of the Receiver Proxy. We refer to this approach as the "Indirect Notify" approach.
* 受信機プロキシのアドレス。このアプローチを「間接通知」アプローチと呼びます。
o Upon receiving a downstream error notification (whether in the form of a Notify, ResvErr, or both), the RSVP Receiver Proxy:
o 下流のエラー通知を受信すると（Notify、Resverr、またはその両方の形で）、RSVP受信機プロキシ：
* MUST generate a Notify message with upstream notification to the corresponding sender, if the sender included a Notify Request object in its Path messages and if Indirect Notification is used.
* 対応する送信者にアップストリーム通知を含む通知メッセージを生成する必要があります。
* SHOULD generate a Notify message with upstream notification to the corresponding sender, if the sender included a Notify Request object in its Path messages and if Direct Notification is used. The reason for this recommendation is that the failure node may not support Notify, so that even if Direct Notification was requested by the RSVP Receiver Proxy, the sender may not actually have received a Notify from the failure node: generating a Notify from the Receiver Proxy will accelerate sender notification, as compared to simply relying on PathErr, in this situation. In controlled environments where all the nodes are known to support Notify, the Receiver Proxy MAY be configured to not generate the Notify with upstream notification when Direct Notification is used, in order to avoid duplication of Notify messages (i.e., the sender receiving both a Notify from the failure node and from the Receiver Proxy).
* 対応する送信者にアップストリーム通知を含む通知メッセージを生成する必要があります。この推奨の理由は、障害ノードが通知をサポートしない可能性があるため、RSVP受信機プロキシによって直接通知が要求されたとしても、送信者は実際に障害ノードから通知を受け取っていない可能性があるためです。この状況では、単にPatherrに依存するのと比較して、送信者通知を加速します。すべてのノードが通知をサポートすることが知られている制御された環境では、通知メッセージの複製を回避するために、直接通知が使用されているときにアップストリーム通知で通知を生成しないように受信機プロキシを構成することができます（つまり、送信者は通知を受信します。故障ノードおよびレシーバープロキシから）。
As a result of these sender and Receiver Proxy behaviors, as per existing Notify procedures, if an RSVP router detects an error relating to a Resv state (e.g., admission control rejection after IP reroute), the RSVP router will send a Notify message (conveying the downstream notification with the ResvErr error code) to the IP address contained in the Resv Notify Request object. If this address has been set by the RSVP Receiver Proxy to the sender's address (Direct Notify), the Notify message is sent directly to the sender. If this address has been set by the RSVP Receiver Proxy to one of its own addresses (Indirect Notify), the Notify message is sent to the RSVP Receiver Proxy that, in turn, will generate a Notify message directly addressed to the sender.
これらの送信者および受信機プロキシ動作の結果、既存の通知手順に従って、RSVPルーターがRESV状態に関連するエラーを検出した場合（例：IP Reroute後の入場制御拒否）、RSVPルーターはNotifyメッセージを送信します（RESV通知要求オブジェクトに含まれるIPアドレスへのRESVERRエラーコードを使用した下流通知。このアドレスがRSVPレシーバープロキシによって送信者のアドレス（Direct Notify）に設定されている場合、Notifyメッセージは送信者に直接送信されます。このアドレスがRSVPレシーバープロキシによって独自のアドレスのいずれかに設定されている場合（間接通知）、NotifyメッセージがRSVPレシーバープロキシに送信され、次に送信者に直接アドレス指定された通知メッセージが生成されます。
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, using sender notification via Direct Notify, is illustrated in Figure 4.
Direct Notifyを介した送信者通知を使用して、入場制御障害の場合のパストリガーRSVP受信機プロキシの操作を図4に示します。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path*--> --Path*--> --Path*--> --Path*-->
<--Resv*-- <--Resv*--
<------NotifyD--------
-ResvErr-> -ResvErr->
<------------------NotifyU------------------
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================RSVP===================>
************************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
==> segment of flow path benefiting from RSVP (but not benefiting from a reservation in this case)
==> RSVPの恩恵を受けるフローパスのセグメント（ただし、この場合の予約の恩恵を受けていません）
Path* = Path message containing a Notify Request object with sender IP Address
パス* =送信者IPアドレスを含む通知リクエストオブジェクトを含むパスメッセージ
Resv* = Resv message containing a Notify Request object with sender IP address
resv* =送信者IPアドレスを含む通知要求オブジェクトを含むRESVメッセージ
NotifyD = Notify message containing a downstream notification
notifyd =ダウンストリーム通知を含むメッセージを通知します
NotifyU = Notify message containing an upstream notification
notifyu =アップストリーム通知を含むメッセージを通知します
Figure 4: Reservation Failure with Sender Notification via Direct Notify
図4：直接通知による送信者通知による予約障害
Operation of the Path-Triggered RSVP Receiver Proxy in the case of an admission control failure, using sender notification via Indirect Notify, is illustrated in Figure 5.
間接通知を介した送信者通知を使用して、入場制御障害の場合にパストリガーされたRSVP受信機プロキシの操作を図5に示します。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path*--> --Path*--> --Path*--> --Path*-->
<--Resv*-- <--Resv*--
-------NotifyD------->
<------------------NotifyU------------------
-ResvErr-> -ResvErr->
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
===================RSVP===================>
************************************************************>
|****| RSVP-capable |----| Non-RSVP-capable ***
| S | Sender | R | Receiver *r* regular RSVP
|****| |----| *** router
***> media flow
==> segment of flow path benefiting from RSVP (but not benefiting from a reservation in this case)
==> RSVPの恩恵を受けるフローパスのセグメント（ただし、この場合の予約の恩恵を受けていません）
Path* = Path message containing a Notify Request object with sender IP Address
パス* =送信者IPアドレスを含む通知リクエストオブジェクトを含むパスメッセージ
Resv* = Resv message containing a Notify Request object with RSVP Receiver Proxy IP address
RESV* = RSVPレシーバープロキシIPアドレスを備えたNotifyリクエストオブジェクトを含むRESVメッセージ
NotifyD = Notify message containing a downstream notification
notifyd =ダウンストリーム通知を含むメッセージを通知します
NotifyU = Notify message containing an upstream notification
notifyu =アップストリーム通知を含むメッセージを通知します
Figure 5: Reservation Failure with Sender Notification via Indirect Notify
図5：間接通知による送信者通知による予約障害
For local failures on the Receiver Proxy node, if a similar failure on an RSVP midpoint would cause the generation of a ResvErr (for example, admission control failure), the Receiver Proxy MUST generate a Notify towards the sender. The Receiver Proxy MAY additionally generate a Notify upon local failures that would not ordinarily cause generation of a ResvErr message, such as those described in Appendix B of [RFC2205].
レシーバープロキシノードのローカル障害の場合、RSVPミッドポイントで同様の障害がRESVERRの生成を引き起こす場合（たとえば、入場制御障害）、受信機プロキシは送信者に通知を生成する必要があります。レシーバープロキシは、[RFC2205]の付録Bに記載されているように、通常、RESVERRメッセージの生成を引き起こさない局所障害に通知を生成する場合があります。
When the method of sender notification via a Notify message is used, it is RECOMMENDED that the RSVP Receiver Proxy also issue a sender notification via a PathErr message. This maximizes the chances that the notification will reach the sender in all situations (e.g., even if some RSVP routers do not support the Notify procedure, or if a Notify message gets dropped). However, for controlled environments (e.g., where all RSVP routers are known to support Notify procedures) and where it is desirable to minimize the volume of signaling, the RSVP Receiver Proxy MAY rely exclusively on sender notification via a Notify message and thus not issue sender notification via a PathErr message.
Notifyメッセージを介した送信者通知の方法が使用される場合、RSVPレシーバープロキシもPatherRメッセージを介して送信者通知を発行することをお勧めします。これにより、通知があらゆる状況で送信者に届く可能性が最大化されます（たとえば、一部のRSVPルーターが通知手順をサポートしていない場合でも、通知メッセージが削除された場合でも）。ただし、制御された環境（たとえば、すべてのRSVPルーターが通知手順をサポートすることが知られている場合）の場合、およびシグナリングの量を最小限に抑えることが望ましい場合、RSVP受信機プロキシは通知メッセージを介して送信者通知に依存する可能性があります。Patherrメッセージによる通知。
In environments where there are both RSVP-capable receivers and RSVP Receiver Proxies acting on behalf of non-RSVP-capable receivers, a sender does not know whether a given reservation is established with an RSVP-capable receiver or with an RSVP Receiver Proxy. Thus, a sender that supports the procedures defined in this section may include a Notify Request object in Path messages for a reservation that happens to be controlled by an RSVP-capable receiver. This document does not define, nor expect, any change in existing receiver behavior. As a result, in this case, the sender will not receive Notify messages conveying downstream notifications. However, this is perfectly fine because the synchronization between the RSVP reservation state and the application requirement can be performed by the actual receiver in this case as per the regular end-to-end RSVP model, so that in this case, the sender need not care about downstream notifications.
RSVP対応レシーバーとRSVP受信機プロキシの両方がない環境では、RSVP対応レシーバーに代わって作用しているため、送信者は、特定の予約がRSVP対応レシーバーまたはRSVPレシーバープロキシを使用して確立されているかどうかを知りません。したがって、このセクションで定義されている手順をサポートする送信者には、RSVP対応レシーバーによって制御される予約のパスメッセージに通知要求オブジェクトが含まれる場合があります。このドキュメントは、既存の受信者動作の変更を定義したり、期待したりしません。その結果、この場合、送信者は下流の通知を伝える通知メッセージを受信しません。ただし、RSVP予約状態とアプリケーション要件との間の同期は、通常のエンドツーエンドのRSVPモデルに従って実際のレシーバーが実行できるため、これはまったく問題ありません。下流の通知に注意してください。
A sender that does not support the procedures defined in this section might include a Notify Request object in Path messages for a reservation simply because it is interested in getting upstream notifications faster. If the reservation is controlled by an RSVP Receiver Proxy supporting the procedures defined in this section, the sender will also receive unexpected Notify messages containing downstream notifications. It is expected that such a sender will simply naturally drop such downstream notifications as invalid. Because it is RECOMMENDED above that the RSVP Receiver Proxy also issue a sender notification via a PathErr message even when sender notification is effected via a Notify message, the sender will still be notified of a reservation failure in accordance with the "sender notification via PathErr" method. In summary, activating the OPTIONAL "sender notification via Notify" method on a Receiver Proxy does not prevent a sender that does not support this method from relying on the MANDATORY "sender notification via PathErr" method. It would, however, allow a sender supporting the "sender notification via Notify" method to take advantage of this OPTIONAL method.
このセクションで定義されている手順をサポートしていない送信者には、予約のためのパスメッセージに通知要求オブジェクトが含まれる場合があります。予約がこのセクションで定義されている手順をサポートするRSVP受信機プロキシによって制御されている場合、送信者は下流通知を含む予期しない通知メッセージも受信します。このような送信者は、そのような下流通知を無効と単純にドロップすることが予想されます。上記で推奨されているため、RSVPレシーバープロキシは、送信者通知が通知メッセージを介して行われた場合でも、PatherRメッセージを介して送信者通知を発行することを推奨するため、送信者は「Patherを介した送信者通知」に従って予約障害を通知されます。方法。要約すると、受信機プロキシのオプションの「通知による送信者通知」メソッドをアクティブにすることは、このメソッドをサポートしていない送信者が必須の「Patherrによる送信者通知」メソッドに依存することを妨げません。ただし、このオプションの方法を活用するために、「通知を介して送信者通知」メソッドをサポートする送信者が「送信者通知」メソッドを可能にします。
With Direct Notification, the downstream notification generated by the RSVP router where the failure occurs is sent to the IP address contained in the Notification Request Object of the corresponding Resv message. In the presence of multiple senders towards the same session, it cannot be generally assumed that a separate Resv message is used for each sender (in fact, with WF and SE there is a single Resv message for all senders, and with FF the downstream router has the choice of generating separate Resv messages or a single one). Hence, in the presence of multiple senders, Direct Notification cannot guarantee notification of all affected senders. Therefore, Direct Notification is better suited to single-sender applications.
直接通知により、障害が発生するRSVPルーターによって生成された下流通知は、対応するRESVメッセージの通知要求オブジェクトに含まれるIPアドレスに送信されます。同じセッションに向けて複数の送信者が存在する場合、各送信者に個別のRESVメッセージが使用されるとは想定できません（実際、WFとSEではすべての送信者に単一のRESVメッセージがあり、FFはダウンストリームルーターにあります。個別のRESVメッセージまたは単一のメッセージを生成する選択肢があります）。したがって、複数の送信者が存在する場合、直接通知は影響を受けるすべての送信者の通知を保証することはできません。したがって、直接通知はシングルセンダーアプリケーションにより適しています。
With Indirect Notification, the RSVP Receiver Proxy can generate Notify messages with the same logic that is used to generate PathErr messages in the "Sender Notification via PathErr" method (in fact, those are conveying the same error information, only the Notify is directly addressed to the sender while the PathErr travels hop-by-hop). Therefore, operations of the Indirect Notify method in the presence of multiple senders is similar to that of the PathErr method as discussed in Section 3.1: with FF or SE, a Notify MUST be sent to the sender or the set of affected senders, respectively. With WF, the RSVP Receiver Proxy SHOULD send a Notify to each sender, again resulting in a somewhat overly conservative behavior in the presence of multiple senders.
間接通知を使用すると、RSVP受信機プロキシは、「Patherrを介した送信者通知」メソッドでPatherRメッセージを生成するために使用される同じロジックで通知メッセージを生成できます（実際、それらは同じエラー情報を伝えていますが、通知のみが直接アドレス指定されます。Patherrがホップバイホップを旅行する間、送信者に）。したがって、複数の送信者の存在下での間接通知メソッドの操作は、セクション3.1：FFまたはSEで説明したPatherRメソッドの操作と類似しています。WFを使用すると、RSVPレシーバープロキシは各送信者に通知を送信し、再び複数の送信者の存在下でやや過度に保守的な動作をもたらします。
This section defines extensions to RSVP procedures allowing an RSVP reservation to span as much of the flow path as possible, with any arbitrary number of RSVP Receiver Proxies on the flow path and whether or not the receiver is RSVP-capable. This facilitates deployment and operations of Path-Triggered RSVP Receiver Proxies since it alleviates the topological constraints and/or configuration load otherwise associated with Receiver Proxies (e.g., make sure there is no RSVP Receiver Proxy for a flow upstream of a given Receiver Proxy, ensure there is no Receiver Proxy for a flow if the receiver is RSVP-capable). This also facilitates migration from an RSVP deployment model based on Path-Triggered Receiver Proxies to an end-to-end RSVP model, since receivers can gradually and independently be upgraded to support RSVP and then instantaneously benefit from end-to-end reservations.
このセクションでは、RSVPプロシージャへの拡張機能を定義して、RSVP予約を可能な限り多くのフローパスに及ぼすことができます。フローパスでの任意の数のRSVPレシーバープロキシと、レシーバーがRSVP対応かどうか。これにより、受信機プロキシに関連付けられているトポロジーの制約および/または構成負荷を軽減するため、パストリガーRSVP受信機プロキシの展開と操作が容易になります（たとえば、特定のレシーバープロキシの上流のフローのRSVPレシーバープロキシがないことを確認してください。レシーバーがRSVP対応である場合、フローのレシーバープロキシはありません）。また、これにより、RSVPをサポートし、エンドツーエンドの予約から即座に利益を得るために受信機を徐々にアップグレードできるため、パストリガーレシーバープロキシに基づいてエンドツーエンドのRSVPモデルに基づいたRSVP展開モデルからの移行も容易になります。
Section 4.1 defines a method that allows a Path-Triggered Receiver Proxy function to discover whether there is another Receiver Proxy or an RSVP-capable receiver downstream and then dynamically extend the span of the RSVP reservation downstream. A router implementation claiming compliance with this document SHOULD support the method defined in Section 4.1.
セクション4.1は、パストリガーされた受信機プロキシ関数が別の受信機プロキシまたはRSVP対応レシーバーが下流にあるかどうかを発見し、RSVP予約の下流のスパンを動的に拡張できるかどうかを定義します。このドキュメントのコンプライアンスを主張するルーターの実装は、セクション4.1で定義されている方法をサポートする必要があります。
Section 4.2 defines a method that allows a sender to control whether or not an RSVP router supporting the Path-Triggered Receiver Proxy function is to behave as a Receiver Proxy for a given flow. A router implementation claiming compliance with this document MAY support the method defined in Section 4.2.
セクション4.2は、送信者がパストリガーレシーバープロキシ関数をサポートするRSVPルーターが特定のフローのレシーバープロキシとして動作するかどうかを制御できるかどうかを定義します。このドキュメントのコンプライアンスを主張するルーターの実装は、セクション4.2で定義されている方法をサポートする場合があります。
In a given network environment, a network administrator may elect to use the method defined in Section 4.1, or the method defined in Section 4.2, or possibly combine the two.
特定のネットワーク環境では、ネットワーク管理者は、セクション4.1で定義されているメソッド、またはセクション4.2で定義されている方法を使用することを選択できます。
When generating a proxy Resv message upstream, a Receiver Proxy supporting dynamic discovery of downstream RSVP functionality MUST forward the Path message downstream instead of terminating it (unless dynamic discovery of downstream RSVP functionality is explicitly disabled). If the destination endpoint supports RSVP (or there is another Receiver Proxy downstream), it will receive the Path and generate a Resv upstream. When this Resv message reaches the Receiver Proxy, it recognizes the presence of an RSVP-capable receiver (or of another RSVP Receiver Proxy) downstream and MUST internally convert its state from a proxied reservation to a regular midpoint RSVP behavior. From then on, the RSVP router MUST behave as a regular RSVP router for that reservation (i.e., as if the RSVP router never behaved as an RSVP Receiver Proxy for that flow). This method is illustrated in Figure 6.
上流のプロキシRESVメッセージを生成する場合、下流のRSVP機能の動的発見をサポートするレシーバープロキシは、それを終了するのではなく、下流のメッセージを下流に転送する必要があります（下流のRSVP機能の動的発見が明示的に無効になっていない限り）。宛先エンドポイントがRSVPをサポートしている場合（または別のレシーバープロキシが下流にある）、パスを受け取り、上流のRESVを生成します。このRESVメッセージが受信機プロキシに到達すると、下流のRSVP対応レシーバー（または別のRSVPレシーバープロキシ）の存在が下流にあることを認識し、その状態をプロキシの予約から通常のミッドポイントRSVP挙動に内部的に変換する必要があります。それ以降、RSVPルーターは、その予約の通常のRSVPルーターとして動作する必要があります（つまり、RSVPルーターがそのフローのRSVPレシーバープロキシとして動作しなかったかのように）。この方法を図6に示します。
|****| *** |**********| |----|
| 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 6: Dynamic Discovery of Downstream RSVP Functionality
図6：下流のRSVP機能の動的発見
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; however, to mitigate this, the Receiver Proxy MAY tear down any unanswered downstream Path state after a predetermined time (that SHOULD be greater or equal to the Path refresh interval), and MAY stop sending Path messages for the flow (or MAY only send them at much lower frequency).
RSVP対応のレシーバー（またはその他の受信機プロキシ）がレシーバープロキシの下流にない場合、RSVPリフレッシュ間隔ごとにレシーバープロキシによって送信されたパスメッセージ（デフォルトでは30秒）は応答しません。ただし、これらのメッセージは少量の帯域幅を消費し、さらに、最初の受信機プロキシの下流のRSVP対応のMidpointノードにRSVP状態をインストールします。これは非常に小さな亜光学と見なされています。ただし、これを緩和するために、受信機プロキシは、所定の時間（パスリフレッシュ間隔と等しいか等しい）後に未回答の下流のパス状態を取り壊すことができ、フローのパスメッセージの送信を停止する可能性があります（または送信する場合がありますはるかに低い周波数）。
This approach only requires support of the behavior described in the previous paragraph and does not require any new RSVP extensions.
このアプローチでは、前の段落で説明されている動作のサポートのみが必要であり、新しいRSVP拡張機能を必要としません。
[RFC2750] defines extensions for supporting generic policy-based admission control in RSVP. These extensions include the standard format of POLICY_DATA objects and a description of RSVP handling of policy events.
[RFC2750]は、RSVPでの一般的なポリシーベースの入場制御をサポートするための拡張機能を定義しています。これらの拡張機能には、policy_dataオブジェクトの標準形式と、ポリシーイベントのRSVP処理の説明が含まれます。
The POLICY_DATA object contains one or more policy elements, each representing a different (and perhaps orthogonal) policy. As an example, [RFC3181] specifies the preemption priority policy element.
Policy_Dataオブジェクトには、それぞれが異なる（そしておそらく直交）ポリシーを表す1つ以上のポリシー要素が含まれています。例として、[RFC3181]は、先制優先ポリシー要素を指定します。
This document defines a new policy element called the Receiver Proxy Control policy element. This document only defines the use of this policy element in Path messages and for unicast reservations. Other usage is outside the scope of this document.
このドキュメントは、受信機プロキシ制御ポリシー要素と呼ばれる新しいポリシー要素を定義します。このドキュメントは、パスメッセージとユニキャストの予約でこのポリシー要素の使用のみを定義します。その他の使用法は、このドキュメントの範囲外です。
The format of the Receiver Proxy Control policy element is as shown in Figure 7:
受信機プロキシ制御ポリシー要素の形式は、図7に示すとおりです。
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type=REC_PROXY_CONTROL |
+-------------+-------------+-------------+-------------+
| Reserved |Control-Value|
+---------------------------+---------------------------+
Figure 7: Receiver Proxy Control Policy Element
図7：受信機プロキシ制御ポリシー要素
where:
ただし：
o Length: 16 bits
o 長さ：16ビット
* Always 8. The overall length of the policy element, in bytes.
* 常に8.ポリシー要素の全長、バイト。
o P-Type: 16 bits
o Pタイプ：16ビット
* REC_PROXY_CONTROL = 0x07 (see the "IANA Considerations" section).
* rec_proxy_control = 0x07（「IANA考慮事項」セクションを参照）。
o Reserved: 24 bits
o 予約済み：24ビット
* SHALL be set to zero on transmit and SHALL be ignored on reception.
* 送信時にゼロに設定され、受信時に無視されます。
o Control-Value: 8 bits (unsigned)
o コントロール値：8ビット（署名なし）
* 0 (Reserved): An RSVP Receiver Proxy that understands this policy element MUST ignore the policy element if its Control-Value is set to that value.
* 0（予約済み）：このポリシー要素を理解しているRSVPレシーバープロキシは、そのコントロール値がその値に設定されている場合、ポリシー要素を無視する必要があります。
* 1 (Receiver-Proxy-Needed): An RSVP Receiver Proxy that understands this policy element MUST attempt to insert itself as a Receiver Proxy for that flow if the corresponding Path message contains this Control-Value. If the Receiver Proxy also supports dynamic discovery of downstream RSVP functionality as specified in Section 4.1, it MUST still send the Path message downstream and attempt to extend the reservation downstream so that the reservation can be extended to the last Receiver Proxy). An RSVP sender MAY insert the Receiver Proxy Control policy element with this Control-Value when it knows (say, by other means, such as application-level signaling) that the receiver is not RSVP-capable.
* 1（レシーバー - プロキシニード）：このポリシー要素を理解しているRSVPレシーバープロキシは、対応するパスメッセージにこのコントロール値が含まれている場合、そのフローのレシーバープロキシとして自分自身を挿入しようと試みなければなりません。受信機プロキシがセクション4.1で指定されている下流のRSVP機能の動的発見もサポートしている場合、下流のパスメッセージを送信し、予約を下流に拡張して、予約を最後のレシーバープロキシに拡張できるようにする必要があります。RSVP送信者は、受信機がRSVP対応ではないことを知っている場合（たとえば、アプリケーションレベルのシグナリングなどの他の手段で）、このコントロール値で受信機プロキシ制御ポリシー要素を挿入する場合があります。
* 2 (Receiver-Proxy-Not-Needed): An RSVP Receiver Proxy that understands this policy element MUST NOT attempt to insert itself as a Receiver Proxy for that flow if the corresponding Path message contains this Control-Value. An RSVP sender MAY insert the Receiver Proxy Control policy element with this Control-Value when it knows (say, by other means, such as application-level signaling) that the receiver is RSVP-capable.
* 2（レシーバー - ポキシなし必要）：このポリシー要素を理解しているRSVPレシーバープロキシは、対応するパスメッセージにこのコントロール値が含まれている場合、そのフローのレシーバープロキシとして自分自身を挿入しようとしてはなりません。RSVP送信者は、受信機がRSVP対応であることを知っている（たとえば、アプリケーションレベルのシグナリングなどの他の手段で）この制御値で受信機プロキシ制御ポリシー要素を挿入する場合があります。
Figure 8 illustrates the method based on the Receiver Proxy Control policy element that allows a sender to control whether or not an RSVP router supporting the Path-Triggered Receiver Proxy function is to behave as a Receiver Proxy for a given flow.
図8は、送信者がパストリガーレシーバープロキシ関数をサポートするRSVPルーターが特定のフローのレシーバープロキシとして動作するかどうかを制御できるかどうかを制御できるかどうかを制御できるようにするメソッドを示しています。
|****| *** |**********| |----|
| S |---------*r*---------| RSVP |---| R1 |
|****| *** | Receiver | |----|
| Proxy |
| |
| | |****|
| |------------| R2 |
|**********| |****|
---Path---> --Path---> (R1/N) (R1/N)
---パス---> - パス--->（r1/n）（r1/n）
<--Resv--- <---Resv---
<-RESV --- <--- RESV ---
================RSVP===>
**************************************>
---Path---> --Path---> ----Path---->
(R2/NN) (R2/NN) (R2/NN)
<--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
(N) = Path message contains a Receiver Proxy Control policy element whose Control-Value is set to Receiver-Proxy-Needed
（n）=パスメッセージには、コントロール値がレシーバー - プロキシを必要とするように設定されているレシーバープロキシ制御ポリシー要素が含まれています
(NN) = Path message contains a Receiver Proxy Control policy element whose Control-Value is set to Receiver-Proxy-Not-Needed
（nn）=パスメッセージには、コントロール値がレシーバーポキシに設定されているレシーバープロキシ制御ポリシー要素が含まれています。
***> media flow
==> segment of flow path protected by RSVP reservation
Figure 8: Receiver Proxy Control by Sender
図8：送信者によるレシーバープロキシコントロール
As specified in Section 4.2 of [RFC2750], Policy-Ignorant Nodes (PINs) implement a default handling of POLICY_DATA objects ensuring that those objects can traverse PINs in transit from one Policy Enforcement Point (PEP) to another. This applies to the situations in which POLICY_DATA objects contain the Receiver Proxy Control policy element specified in this document, so that those objects can traverse PINs.
[RFC2750]のセクション4.2で指定されているように、ポリシー無視ノード（PIN）は、ポリシー_DATAオブジェクトのデフォルトの処理を実装して、これらのオブジェクトがあるポリシー施行ポイント（PEP）から別のポリシー施行ポイント（PEP）から輸送中にピンを通過できるようにします。これは、Policy_Dataオブジェクトがこのドキュメントで指定された受信機プロキシ制御ポリシー要素を含む状況に適用され、それらのオブジェクトがピンを通過できるようにします。
Section 4.2 of [RFC2750] also defines a similar default behavior for policy-capable nodes that do not recognize a particular policy element. This applies to the Receiver Proxy Control policy element specified in this document, so that messages carrying the element can traverse policy-capable nodes that do not support the extensions described in this document.
[RFC2750]のセクション4.2は、特定のポリシー要素を認識しないポリシー対応ノードの同様のデフォルト動作を定義しています。これは、このドキュメントで指定された受信機プロキシ制御ポリシー要素に適用されるため、要素を運ぶメッセージは、このドキュメントで説明されている拡張機能をサポートしていないポリシー対応ノードを通過できます。
As this document defines extensions to RSVP, the security considerations of RSVP apply, which are discussed in [RFC2205], [RFC4230], and [SEC-GRP-KEY]. Approaches for addressing those concerns are discussed further below.
このドキュメントでRSVPへの拡張機能を定義すると、RSVPのセキュリティに関する考慮事項が適用されます。これは[RFC2205]、[RFC4230]、および[SEC-GRP-KEY]で説明されています。これらの懸念に対処するためのアプローチについては、以下でさらに説明します。
The RSVP authentication mechanisms defined in [RFC2747] and [RFC3097] protect RSVP message integrity hop-by-hop and provide node authentication as well as replay protection, thereby protecting against corruption and spoofing of RSVP messages. These hop-by-hop integrity mechanisms can be used to protect RSVP reservations established using an RSVP Receiver Proxy in accordance with this document. [SEC-GRP-KEY] discusses key types and key provisioning methods as well as their respective applicability to RSVP authentication. RSVP authentication (defined in [RFC2747] and [RFC3097]) SHOULD be supported by an implementation of this document.
[RFC2747]および[RFC3097]で定義されているRSVP認証メカニズムは、RSVPメッセージの整合性を保護し、ホップバイホップを保護し、ノード認証とリプレイ保護を提供し、それによってRSVPメッセージの汚職とスプーフィングから保護します。これらのホップバイホップの整合性メカニズムは、このドキュメントに従ってRSVPレシーバープロキシを使用して確立されたRSVP予約を保護するために使用できます。[SEC-GRP-KEY]は、主要なタイプと主要なプロビジョニング方法、およびRSVP認証へのそれぞれの適用性について説明します。RSVP認証（[RFC2747]および[RFC3097]で定義）は、このドキュメントの実装によってサポートされる必要があります。
[SEC-GRP-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 Path-Triggered RSVP Receiver Proxies as defined in this document.
[SEC-GRP-KEY]は、RSVPのセキュリティ保護のためのIPSECメカニズム（[RFC4302]、[RFC4303]）および関連する重要なプロビジョニング方法の適用性についても説明しています。この議論は、このドキュメントで定義されているように、パストリガーされた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., 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]で詳しく説明します。
When an RSVP Receiver Proxy is used, the RSVP reservation is no longer controlled by the receiver, but rather is controlled by the Receiver Proxy (using hints received from the sender in the Path message) on behalf of the sender. Thus, the Receiver Proxy ought to be trusted by the end-systems to control the RSVP reservation appropriately. However, basic RSVP operation already assumes a trust model where end-systems trust RSVP nodes to appropriately perform RSVP reservations. So the use of an RSVP Receiver Proxy is not seen as introducing any significant additional security threat or as modifying the RSVP trust model.
RSVPレシーバープロキシを使用すると、RSVP予約は受信機によって制御されなくなりますが、送信者に代わってレシーバープロキシ（パスメッセージの送信者から受信されたヒントを使用）によって制御されます。したがって、RSVP予約を適切に制御するために、レシーバープロキシは最終システムによって信頼されるべきです。ただし、基本的なRSVP操作では、End-SystemsがRSVPノードを信頼してRSVPの予約を適切に実行する信頼モデルを既に想定しています。したがって、RSVPレシーバープロキシの使用は、重要な追加のセキュリティ脅威を導入したり、RSVPトラストモデルを変更したりするとは見なされません。
In fact, there are situations in which the use of an RSVP Receiver Proxy reduces the security risks. One example is where a network operator relies on RSVP to perform resource reservation and admission control within a network and where RSVP senders and RSVP routers are located in the operator's premises, while the many RSVP receivers are located in the operator's customers' premises. Such an environment is further illustrated in Appendix A.1, "RSVP-Based VoD Admission Control in Broadband Aggregation Networks", of [RFC5945]. From the operator's perspective, the RSVP routers and RSVP senders are in physically secured locations and therefore exposed to a lower risk of being tampered with, while the receivers are in locations that are physically unsecured and therefore subject to a higher risk of being tampered with. The use of an RSVP Receiver Proxy function effectively increases the security of the operator's reservation and admission control solution by completely excluding receivers from its operation. Filters can be placed at the edge of the operator network, discarding any RSVP message received from end-users. This provides a very simple and effective protection of the RSVP reservation and admission control solution operating inside the operator's network.
実際、RSVP受信機プロキシを使用するとセキュリティリスクが減少する状況があります。1つの例は、ネットワークオペレーターがRSVPに依存してネットワーク内でリソースの予約と入学制御を実行し、RSVP送信者とRSVPルーターがオペレーターの敷地内にある場合、多くのRSVPレシーバーはオペレーターの顧客の敷地内にあります。このような環境は、[RFC5945]の付録A.1、「ブロードバンド集約ネットワークにおけるRSVPベースのVOD入容制御」にさらに示されています。オペレーターの観点から見ると、RSVPルーターとRSVP送信者は物理的に保護された場所にあり、したがって、改ざんされるリスクが低くなりますが、受信機は物理的に無担保であり、したがって改ざんされるリスクが高い場所にあります。RSVP受信機プロキシ機能を使用すると、受信機を運転から完全に除外することにより、オペレーターの予約および入場制御ソリューションのセキュリティが効果的に向上します。フィルターは、オペレータネットワークの端に配置でき、エンドユーザーから受信したRSVPメッセージを破棄できます。これにより、オペレーターのネットワーク内で動作するRSVP予約および入場制御ソリューションの非常にシンプルで効果的な保護が提供されます。
This document defines, in Section 3.2, an optional method relying on the use of the Notify message specified in [RFC3473]. The Notify message can be sent in a non-hop-by-hop fashion that precludes the use of the RSVP hop-by-hop integrity and authentication model. The approaches and considerations for addressing this issue presented in the Security Considerations section of [RFC3473] apply. In particular, where the Notify messages are transmitted non-hop-by-hop and the same level of security provided by [RFC2747] is desired, IPsec-based integrity and authentication can be used ([RFC4302] or [RFC4303]). Alternatively, the sending of non-hop-by-hop Notify messages can be disabled. Finally, [SEC-GRP-KEY] discusses the applicability of group keying for non-hop-by-hop Notify messages.
このドキュメントは、セクション3.2で、[RFC3473]で指定された通知メッセージの使用に依存するオプションの方法を定義しています。Notifyメッセージは、RSVPホップバイホップの整合性と認証モデルの使用を排除する非ホップバイホップファッションで送信できます。[RFC3473]のセキュリティに関する考慮事項セクションで提示されたこの問題に対処するためのアプローチと考慮事項が適用されます。特に、通知メッセージが非ホップバイホップで送信され、[RFC2747]によって提供される同じレベルのセキュリティが望まれる場合、IPSECベースの整合性と認証を使用できます（[RFC4302]または[RFC4303]）。または、非ホップバイホップ通知メッセージの送信は無効になる可能性があります。最後に、[SEC-GRP-KEY]は、非ホップバイホップ通知メッセージのグループキーイングの適用性について説明します。
This document also defines, in Section 4.2, the optional Receiver Proxy Control policy element. Policy elements are signaled by RSVP through encapsulation in a Policy Data object as defined in [RFC2750]. Therefore, like any other policy elements, the integrity of the Receiver Proxy Control policy element can be protected as discussed in Section 6 of [RFC2750] by two optional security mechanisms.
このドキュメントは、セクション4.2で、オプションの受信機プロキシ制御ポリシー要素も定義しています。[RFC2750]で定義されているように、ポリシーデータオブジェクトのカプセル化を通じて、ポリシー要素はRSVPによってシグナル化されます。したがって、他のポリシー要素と同様に、2つのオプションのセキュリティメカニズムによって[RFC2750]のセクション6で説明されているように、受信機プロキシ制御ポリシー要素の整合性を保護できます。
The first mechanism relies on the RSVP authentication discussed above that provides a chain of trust when all RSVP nodes are policy capable. With this mechanism, the INTEGRITY object is carried inside RSVP messages.
最初のメカニズムは、上記のRSVP認証に依存しており、すべてのRSVPノードがポリシーが可能である場合に信頼の連鎖を提供します。このメカニズムにより、整合性オブジェクトはRSVPメッセージ内に運ばれます。
The second mechanism relies on the INTEGRITY object within the POLICY_DATA object to guarantee integrity between RSVP Policy Enforcement Points (PEPs) that are not RSVP neighbors. This is useful only when some RSVP nodes are Policy-Ignorant Nodes (PINs). The INTEGRITY object within the POLICY_DATA object MAY be supported by an implementation of this document.
2番目のメカニズムは、Policy_Dataオブジェクト内の整合性オブジェクトに依存して、RSVPネイバーではないRSVPポリシー施行ポイント（PEP）間の完全性を保証します。これは、一部のRSVPノードがポリシー無視ノード（PIN）である場合にのみ役立ちます。Policy_Dataオブジェクト内の整合性オブジェクトは、このドキュメントの実装によってサポートされる場合があります。
Details for the computation of the content of the INTEGRITY object can be found in Appendix B of [RFC2750]. This states that the Policy Decision Point (PDP), at its discretion, and based on destination PEP/PDP or other criteria, selects an Authentication Key and the hash algorithm to be used. Keys to be used between PDPs can be distributed manually or via a standard key management protocol for secure key distribution.
整合性オブジェクトの内容の計算の詳細は、[RFC2750]の付録Bに記載されています。これは、その裁量により、宛先PEP/PDPまたはその他の基準に基づいて、ポリシー決定ポイント（PDP）が使用される認証キーとハッシュアルゴリズムを選択することを示しています。PDP間で使用するキーは、手動で分布するか、安全なキー分布のために標準のキー管理プロトコルを介して分布させることができます。
Note that where non-RSVP hops may exist in between RSVP hops, as well as where RSVP-capable Policy-Ignorant Nodes (PINs) may exist in between PEPs, it may be difficult for the PDP to determine what the destination PDP is for a POLICY_DATA object contained in some RSVP messages (such as a Path message). This is because in those cases, the next PEP is not known at the time of forwarding the message. In this situation, a key shared across multiple PDPs may be used. This is conceptually similar to the use of a key shared across multiple RSVP neighbors, as discussed in [SEC-GRP-KEY]. We also observe that this issue may not exist in some deployment scenarios where a single PDP (or a low number of PDPs) is used to control all the PEPs of a region (such as an administrative domain). In such scenarios, it may be easy for a PDP to determine what the next-hop PDP is, even when the next-hop PEP is not known, simply by determining what the next region is that will be traversed (say, based on the destination address).
RSVPホップの間に非RSVPホップが存在する可能性がある場合、およびRSVP対応のポリシーイノラントノード（PIN）がPEPの間に存在する場合は、PDPが宛先PDPが何であるかをPDPが判断することは困難かもしれません。Policy_Dataオブジェクトは、いくつかのRSVPメッセージ（パスメッセージなど）に含まれています。これは、これらの場合、メッセージの転送時に次のPEPが知られていないためです。この状況では、複数のPDPにわたって共有されたキーを使用できます。これは、[SEC-GRP-KEY]で説明されているように、複数のRSVPネイバーで共有されたキーの使用と概念的に類似しています。また、この問題は、単一のPDP（または少ない数のPDP）が地域のすべてのPEP（管理ドメインなど）を制御するために使用されるいくつかの展開シナリオに存在しない可能性があることも観察します。このようなシナリオでは、PDPが次のホップPPEPがわからない場合でも、次の領域が何であるかを判断するだけで、次のホップPDPが何であるかを判断するのは簡単かもしれません（たとえば、宛先アドレス）。
Since, as discussed in Section 3.1.2, this document allows two error codes to be used in PathErr messages while [RFC2205] only specified their use in ResvErr messages, IANA has updated the existing entries for these two error codes under the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. Each entry refers to this document, in addition to referring to [RFC2205]. Specifically, the entry for Error Code 1 and Error Code 2 read:
セクション3.1.2で説明したように、このドキュメントでは2つのエラーコードをPATHERRメッセージで使用できますが、[RFC2205]はRESVERRメッセージでの使用のみを指定しました。およびグローバルに定義されたエラー値サブコード "レジストリ。各エントリは、[RFC2205]を参照することに加えて、このドキュメントを指します。具体的には、エラーコード1およびエラーコード2のエントリを読み取ります。
1 Admission Control Failure [RFC2205] [RFC5946]
1入学制御の失敗[RFC2205] [RFC5946]
2 Policy Control Failure [RFC2205] [RFC5946]
2ポリシー管理の失敗[RFC2205] [RFC5946]
IANA has also allocated a new RSVP Error Code "36;: Unrecoverable Receiver Proxy Error", as discussed in Section 3.1.2. This error code has been allocated under the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. The entry for this error code reads:
IANAは、セクション3.1.2で説明したように、新しいRSVPエラーコード「36;：回復可能なレシーバープロキシエラー」を割り当てました。このエラーコードは、「エラーコードとグローバルに定義されたエラー値サブコード」レジストリの下で割り当てられています。このエラーコードのエントリは次のとおりです。
36 Unrecoverable Receiver Proxy Error [RFC5946]
36回復可能なレシーバープロキシエラー[RFC5946]
The sixteen bits of the Error Value field are defined in [RFC5946]
エラー値フィールドの16ビットは[RFC5946]で定義されています
This document defines, in Section 4.2, a new policy element called the Receiver Proxy Control policy element. As specified in [RFC2750], standard RSVP policy elements (P-Type values) are to be assigned by IANA as per "IETF Consensus" policy following the policies outlined in [RFC2434] (this policy is now called "IETF Review" as per [RFC5226]).
このドキュメントは、セクション4.2で、受信機プロキシ制御ポリシー要素と呼ばれる新しいポリシー要素を定義しています。[RFC2750]で指定されているように、標準のRSVPポリシー要素（Pタイプ値）は、[RFC2434]で概説されているポリシーに続いて「IETFコンセンサス」ポリシーに従ってIANAによって割り当てられます（このポリシーは現在、「IETFレビュー」と呼ばれます。[RFC5226]）。
Thus, IANA has allocated one P-Type to the Receiver Proxy Control policy element from the standard RSVP policy element range.
したがって、IANAは、標準のRSVPポリシー要素範囲からレシーバープロキシ制御ポリシー要素に1つのpタイプを割り当てました。
In Section 4.2, this document defines a Control-Value field inside the Receiver Proxy Control policy element. IANA has created the "Receiver Proxy Control Policy Element (P-Type 0x07) Control-Value field" registry and allocated the following values:
セクション4.2では、このドキュメントでは、受信機プロキシ制御ポリシー要素内のコントロール値フィールドを定義しています。IANAは、「受信機プロキシ制御ポリシー要素（Pタイプ0x07）制御値フィールド」レジストリを作成し、次の値を割り当てました。
o 0 : Reserved
o 0：予約済み
o 1 : Receiver-Proxy-Needed
o 1：レシーバー - プロキシが必要です
o 2 : Receiver-Proxy-Not-Needed
o 2：レシーバー - プロキシは必要ありません
Following the policies outlined in [RFC5226], numbers in the range 3-127 are allocated according to the "IETF Review" policy, numbers in the range 128-240 are assigned on a "First Come First Served" basis, and numbers in the range 241-255 are reserved for "Private Use".
[RFC5226]で概説されているポリシーに続いて、範囲3〜127の数値は「IETFレビュー」ポリシーに従って割り当てられ、範囲128-240の数字は「First Come First Serve」ベースで割り当てられ、数字は範囲241-255は、「私的使用」のために予約されています。
This document benefited from discussions with Carol Iturralde and Anca Zamfir. Lou Berger, Adrian Farrel, and John Drake provided review and guidance, in particular on the usage of the Path_State_Removed flag and of the Notify message, both borrowed from [RFC3473]. We also thank Stephen Kent, Ken Carlberg, and Tim Polk for their valuable input and proposed enhancements. Finally, we thank Cullen Jennings, Magnus Westerlund, and Robert Sparks for stimulating the work on extensions maximizing the reservation span and facilitating migration from the Proxy model to the end-to-end RSVP model.
この文書は、Carol IturraldeとAnca Zamfirとの議論の恩恵を受けました。Lou Berger、Adrian Farrel、およびJohn Drakeは、特にPath_state_Removed FlagとNotifyメッセージの使用に関するレビューとガイダンスを提供しました。どちらも[RFC3473]から借りました。また、Stephen Kent、Ken Carlberg、およびTim Polkの貴重な意見と提案された機能強化に感謝します。最後に、Cullen Jennings、Magnus Westerlund、およびRobert Sparksに感謝し、拡張スパンを最大化し、プロキシモデルからエンドツーエンドのRSVPモデルへの移行を促進した拡張機能を刺激してくれました。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711] Partridge、C。およびA. Jackson、「IPv6ルーターアラートオプション」、RFC 2711、1999年10月。
[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月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750] Herzog、S。、「ポリシー管理のためのRSVP拡張」、RFC 2750、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月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソースリソースプロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181] Herzog、S。、「シグナル前の先制優先政策要素」、RFC 3181、2001年10月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230] Tschofenig、H。およびR. Graveman、「RSVPセキュリティプロパティ」、RFC 4230、2005年12月。
[RFC5945] Le Faucheur, F., Manner, J., Wing, D., and A. Guillou, "Resource Reservation Protocol (RSVP) Proxy Approaches", RFC 5945, October 2010.
[RFC5945] Le Faucheur、F.、Mather、J.、Wing、D。、およびA. Guillou、「リソース予約プロトコル（RSVP）プロキシアプローチ」、RFC 5945、2010年10月。
[RTR-ALERT] Le Faucheur, F., "IP Router Alert Considerations and Usage", Work in Progress, October 2009.
[RTR-Alert] Le Faucheur、F。、「IPルーターのアラートの考慮事項と使用法」、2009年10月、進行中の作業。
[SEC-GRP-KEY] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, June 2010.
[Sec-Grp-Key] Behringer、M。およびF. Le Faucheur、「RSVPセキュリティのためのキーイングメソッドの適用可能性」、2010年6月、進行中の作業。
Authors' Addresses
著者のアドレス
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
Francois Le Faucheur Cisco Systems Greenside、400 Avenue de Roumanille Sophia Antipolis 06410 France電話：33 4 97 23 26 19メール：flefauch@cisco.com
Jukka Manner Aalto University Department 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/
Jukka Mather Aalto University of Communications and Networking（COMNET）P.O。Box 13000 Fin-00076 Aalto Finland電話：358 9 470 22481メール：jukka.manner@tkk.fi uri：http：//www.netlab.tkk.fi/~jmanner/
Ashok Narayanan Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 United States EMail: ashokn@cisco.com
Ashok Narayanan Cisco Systems 300 Beaver Brook Road Boxborough、MA 01719米国メール：ashokn@cisco.com
Allan Guillou SFR 40-42 Quai du Point du Jour Boulogne-Billancourt 92659 France EMail: allan.guillou@sfr.com
Allan Guillou SFR 40-42 Quai Du Point du Jour Boulogne-Billancourt 92659 France Email：allan.guillou@sfr.com
Hemant Malik Bharti Airtel, Ltd. 4th Floor, Plot No. 16 Udyog Vihar, Phase IV Gurgaon, 122015 India EMail: Hemant.Malik@airtel.in
Hemant Malik Bharti Airtel、Ltd。4階、プロットNo. 16 Udyog Vihar、Phase IV Gurgaon、122015 India Email：hemant.malik@airtel.in