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
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）は、特定のフローによって要求されるサービス品質（QoS）を保証するために、IPネットワーク内のエンド・ツー・エンドのリソース予約を行うために使用することができます。従来のRSVPと、データ送信者と所定のフローの受信機の両方は、RSVPシグナリングに参加します。しかし、リソース予約が必要とされる多くのユースケースがありますが、受信機、送信者、またはその両方は、RSVP対応されていません。受信機は、RSVP対応していない場合、RSVPルータは、それによって受信機の代わりにRSVPシグナリングを行う、RSVP受信プロキシとして動作してもよいです。これは、リソース予約がRSVP受信プロキシに送信者からのエンドツーエンドパスのセグメント上に確立されることを可能にします。 「プロキシアプローチRSVP」しかし、仲間の文書で説明したように、RSVPの拡張は、シグナリング送信者からのRSVPのPathメッセージの受信によってトリガーされる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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................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のPathメッセージを生成し、最終的に受信、処理、及びRESVメッセージをシンクする必要があります。私たちは、RSVP送信者のプロキシとしてこの実体を参照してください。第二のケースでは、ネットワーク内のエンティティは、受信機の代わりにRSVPを操作するので、データ送信側（又はRSVP送信側プロキシによって）によって送信されたPathメッセージを受信する必要がある、との代わりに生成されたRESVメッセージを有するものに返信データ受信装置（S）。私たちは、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).
一つのRSVPプロキシアプローチは、パス・トリガRSVP受信プロキシアプローチと呼ばれます。このアプローチでは、RSVP受信側プロキシは、非RSVP対応受信機（複数可）の代わりにRSVP予約を確立するための合図として、送信者（又はRSVP送信側プロキシ）によって生成されたRSVP Pathメッセージを使用します。 RSVPレシーバープロキシが効果的に送信者のコントロール（またはRSVP送信者プロキシのコントロール）の下で（受信機の代わりに）仲介作りの予約として機能しています。これは、やや予約が正常に受信機によって制御されている通常のRSVP予約モデルを変更します。そのような変化が大きく、受信機は、RSVP-ことができない場合であり、ここで関心のあるシナリオの動作を容易にします。確かにそれはRSVPレシーバープロキシはアプリケーション認識および送信者のRSVP意識（または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送信側プロキシ）によって行われるので、送信者（又はRSVP送信側プロキシ）は予約状態を認識していることが重要です。従来の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レシーバープロキシのサブセットのみが、（アプリケーションレベルのシグナリングは、送信者と受信者の間で実行されている場合でも）成功した予約を返す場合はさらに、送信者は遡求権を有していなくてもよいです予約を持っていません。送信者がPathTearメッセージを送信し、送信を停止することによって、これを確保することができますし、すべての受信機が（送信者からそれぞれのRSVP受信プロキシに）予約の恩恵を受ける場合にのみ、ただし、マルチキャストトラフィックが送信される動作モードをサポートすることが可能ですそれは予約のための通知を取得するたびに一つ以上の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]で説明したように、[RFC2205]で仮定として強く推奨RSVPの展開モデルは、送信者と受信者のRSVPサポートをエンドツーエンドのままであることを心に留めておくことが重要です。エンドツーエンドモデルは、予約とアプリケーション要件の間に最も効果的な同期を可能にします。エンドツーエンドの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をサポートするようにアップグレードされ、その後、瞬時にエンド・ツー・エンドの予約の恩恵を受けることができるので、ターンでは、これは、エンドツーエンドの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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
、受信機の代わりに、エンドツーエンドのRSVPシグナリングが使用された場合、通常、RSVP対応受信機によって実行されるRSVP操作を行うRSVP対応ルータ：OレシーバプロキシRSVP。 RSVPは、RSVP受信プロキシの上流で使用されている間、RSVPは、RSVP受信プロキシの下流で使用されていないことに留意されたいです。
o RSVP Sender Proxy: an RSVP-capable router performing, on behalf of a sender, the RSVP operations that 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送信者プロキシ：RSVP対応ルータが送信者に代わって、実行は、通常、RSVP-できる送信者によって実行されるRSVP操作は、エンドツーエンドのRSVPシグナリングが使用された場合。 RSVPは、RSVP送信者のプロキシの下流で使用されている間、RSVPは、RSVP送信側プロキシの上流で使用されていないことに留意されたいです。
o Regular RSVP Router: an RSVP-capable router that is not behaving as an RSVP Receiver Proxy nor as an RSVP Sender Proxy.
O通常のRSVPルータ：RSVPレシーバープロキシとしても、RSVP送信者のプロキシとして動作しない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送信者：RSVP対応ホスト考えフローに対する送信者として動作して、[RFC2205]で指定された送信者の動作に応じて、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受信機：RSVP対応ホスト考え流れのための受信機として動作して、[RFC2205]で指定された受信機の動作に応じて、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 Pathメッセージの受信を使用するように構成されてもよいです。 RSVP Pathメッセージ、RSVPレシーバープロキシを受信します：
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
==>流路のセグメントは、RSVP予約恩恵を受ける
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--
-ResvErr-> -ResvErr->
-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
==>流路のセグメントは、RSVP予約恩恵を受ける
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受信プロキシの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メッセージを生成する。この概念は全く新しいものではないということ。それは、それが故障のTEトンネルヘッドエンドに通知するためにMPLSトラフィックエンジニアリング（TE）ラベルスイッチングルーターを可能にすることで同様の要件（すなわち、送信者）を満たすために導入された[RFC3209]から借用されます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.
アドミッション制御に失敗した場合の経路トリガRSVP受信プロキシの動作は、のPathErrメッセージを介して送信者に通知を使用して、図3に示されています。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path---> --Path---> --Path---> --Path--->
<---Resv-- <---Resv--
-ResvErr-> -ResvErr->
-ResvErr-> -ResvErr->
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
<-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
受信側プロキシによって生成されたPathErrに失敗したResvメッセージの生成をトリガし、送信者（単数または複数）に対応します。 FF-スタイル（固定フィルター）ご予約の場合、受信側プロキシは、失敗した予約をマッチング（シングル）送信者に向けたのPathErrを送らなければなりません。 SE-スタイルのために（共有-明示）の予約、
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（複数可）を送らなければなりません。これは、残りの送信者が自分の予約が無傷であろうとのPathErrを受信しないであろう場合には、同じ予約を共有して送信者のサブセットであってもよいです。両方の場合において、ルールは、のPathErrメッセージに送信者の記述子を生成する場合にも適用するResvErrメッセージでフロー記述子を生成するために[RFC2205]のセクション3.1.8に記載します。
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-スタイル（ワイルドカード・フィルター）ご予約の場合、それは常に可能ではありません。そのため、レシーバープロキシは、各送信者に向けたPathErrを送るべきです。これは、すべての送信者は予約が予約失敗を引き起こさなかった送信者を含め、確立されていない通知を受信することを意味します。したがって、たPathErrメッセージを介して送信者通知の方法は、多少過度に保守的である（すなわち、いくつかの場合には、それらが実際に確立されている可能性がいくつかの送信者から拒絶予約）がある場合にワイルドカードフィルタスタイルと組み合わせて使用（及び）1つの送信者より。
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メソッドを経由して送信者の通知は、ユニキャストとマルチキャストセッションの両方に適用されます。しかし、マルチキャストセッションのために、送信者に近いノードに予約失敗（例えば、アドミッションコントロール不良）が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.エラー。これらのエラーのエラーコードは、明示的に送信者に返送されなければなりません。送信者が潜在的に小さいトラフィックパラメータとPathメッセージを再送する可能性があるため、この例では、「アドミッション制御失敗コード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
受信側プロキシによって生成されたPathErrメッセージは、[RFC2205]で定義された正規のPathErrメッセージと同じフォーマットを有します。 SESSION、ERROR_SPEC、および送信者の記述はで構成されています
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.
以下のサブセクションで指定された受信機プロキシ。レシーバープロキシはバック任意のPOLICY_DATAオブジェクトがResvErrで受信したPathErrで、送信者への反映することができます。
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:
次のように受信プロキシのPathErrに挿入するERROR_SPECを構成しなければなりません。
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：ポリシー制御の失敗」 - その後、レシーバープロキシ・コピーでERROR_SPECからのエラーコードと値PathErrメッセージのERROR_SPECにResvErr。た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:
「：回復不能なレシーバープロキシエラー36」レシーバープロキシは、上記1に記載されているものを除き、すべてのエラーコードでResvErrを受信した場合2.は、エラーコードを使用して新しいERROR_SPECを構成します。たPathErrのエラーノードアドレスは、受信プロキシのアドレスに設定しなければなりません。この手順はまた、通常の中点は、上記項目1に記載されたもの以外のエラーコードでResvErrを生成する原因となる受信プロキシ上のローカルエラー追跡しなければならない、または受信プロキシは、ローカル・エラーのためのPathErrを生成する場合に通常ResvErrの生成を引き起こすことはありません。いくつかのケースでは、のPathErrが送信者に届かないことを予め決定することができます。たとえば、「コード3：たResvなしパス」とResvErrを受信したノードは、それが生成したPathErrメッセージがのResvを処理できませんでした同じノードによって転送することができないことを事前に知っています。それにもかかわらず、手順は上記に従わなければなりません。エラーコードは、「36：回復不能な受信プロキシエラー」、エラー値フィールドの16ビットです。
* hhhh hhhh 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.
* = 0000 0000 HHHH HHHH：次に下位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.
* = 0000 0001 HHHH HHHH：次に下位8ビット（LLLL LLLL）はエラーコードの値に受信プロキシによって設定されなければならないResvErr ERROR_SPECで受信（または、場合に受信プロキシは、受信されたことなくたPathErrを生成それはResvErrを生成することであった場合にも、同様の条件でERROR_SPECにおける受信プロキシに含まれていたエラーコード値にResvErr）。このエラー値は、さらに予約が失敗した理由を解釈するために、送信者によって使用されるかもしれません。
* 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.
受信プロキシERROR_SPECに設定インプレースフラグでResvErrを受信した場合3.、それはまたのPathErrのERROR_SPECにインプレースフラグを設定しなければなりません。
[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受信プロキシのPathErrメッセージのERROR_SPECにPath_State_Removedフラグを含み、そのローカルパス状態を除去することによりRSVP受信プロキシ（構成によって活性化される）任意のモードをサポートするかもしれません。予約のパス上のすべてのルータが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.
受信機は、RSVP-可能である場合（これは両方に関与するので）、受信機は、RSVP予約状態およびアプリケーション状態を同期させることができるので、O、[RFC2205]の現在の受信機駆動型モデルが完全に適用可能です。送信者（複数可）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.
RSVP受信プロキシは、送信者がすることができるが、実際の受信機はもはや、（受信機がRSVPシグナリングに関与しないため）、アプリケーション状態にRSVP予約を同期させることができるという事実にある場合に送信元のエラー通知を追加するための動機O 。この動機は、通常の受信機の場合には適用されません。
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).
障害通知を可能にする第1の受信プロキシ向かって下流に進行した後、送信者に受信プロキシから上流の走行とは対照的に障害が（発生ルータによって送信者に直接上流に送信されるO、として効果的に定義された方法で発生3.1節で）。
o allowing the failure notification to travel without hop-by-hop RSVP processing.
障害通知は、ホップバイホップRSVP処理せずに走行することができ、O。
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).
そのような通知のみ（RSVPシグナリングが受信機に見えないように、我々が受信プロキシの存在下にあるため、すなわち、）受信機が可能とアプリケーションとの同期を行うことをいとわ自体ない場合に送信されることを保証するO 。
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]を定義（セクション4.3で、「NOTIFYメッセージ」）RSVP予約に関連するイベントの非隣接ノードに通知するためのメカニズムを提供する通知メッセージ。通知メッセージは、それが直上流または下流の隣接以外のノードに、それが一般的な通知メカニズムであることを「標的化」することができるという点で、[RFC2205]（すなわち、のPathErrとResvErrメッセージ）で定義されたエラーメッセージとは異なります。通知メッセージは、通常、通知Requestオブジェクトが受信された後にのみ生成されます。
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受信プロキシに固有の通知メッセージの使用の態様を論じています。他の態様では、通知メッセージは、[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の送信者は、それが生成するPathメッセージに（送信者のIPアドレスを含む）通知Requestオブジェクトを含まなければなりません。
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通知要求オブジェクトとPathメッセージを受信すると、RSVP受信側プロキシは、それが生成RESVメッセージで通知リクエストオブジェクトを含まなければなりません。この通知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
*送信者のアドレスとしても知られ、受信したPathメッセージの通知要求に含まれたアドレス。私たちは、「直接通知する」アプローチとして、このアプローチを参照しますか、
* 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、RSVP受信プロキシ（通知、ResvErr、またはその両方の形でか）下流エラー通知を受信します。
* 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).
単にこのような状況で、のPathErrに頼ると比較して、送信者に通知を加速するレシーバープロキシからの通知の生成：通知が送信者が実際に故障ノードからの通知を受け取っていない可能性がありますRSVPレシーバープロキシによって要求されました。すべてのノードが通知サポートすることが知られている制御された環境では、受信機プロキシは、直接通知を使用する場合、上流通知で通知発生通知メッセージ（すなわち、の重複を避けるために、送信者が受信の両方Aに通知しないように構成することができます）、障害ノードから及び受信プロキシから。
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・リルート後のアドミッション制御拒否）は、RSVPルータは、搬送（通知メッセージを送信しますResvに含まれるIPアドレスにResvErrエラーコード下流通知）要求オブジェクトを受け取ります。このアドレスは（直接通知）送信者のアドレスにRSVPレシーバープロキシで設定されている場合は、通知メッセージが送信者に直接送信されます。このアドレスは、独自のアドレス（間接の通知）のいずれかにRSVPレシーバープロキシで設定されている場合は、通知メッセージが順番に、通知メッセージを直接送信者宛生成します、という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.
通知ダイレクト介して送信者に通知を使用して、アドミッション制御に失敗した場合の経路トリガRSVP受信プロキシの動作は、図4に示されています。
|****| *** *** *** |**********| |----|
| S |--------*r*--------*r*--------*r*--------| RSVP |------| R |
|****| *** *** *** | Receiver | |----|
| Proxy |
|**********|
--Path*--> --Path*--> --Path*--> --Path*-->
--path * - > --path * - > --path * - > --path * - >
<--Resv*-- <--Resv*--
< - のResv * - < - のResv * -
<------NotifyD--------
-ResvErr-> -ResvErr->
-ResvErr-> -ResvErr->
<------------------NotifyU------------------
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
<-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アドレスを通知するRequestオブジェクトを含むパス* = Pathメッセージ
Resv* = Resv message containing a Notify Request object with sender IP address
送信元のIPアドレスで通知するRequestオブジェクトを含むRESV * = 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
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*-->
--path * - > --path * - > --path * - > --path * - >
<--Resv*-- <--Resv*--
< - のResv * - < - のResv * -
-------NotifyD------->
<------------------NotifyU------------------
-ResvErr-> -ResvErr->
-ResvErr-> -ResvErr->
<-PathErr- <-PathErr- <-PathErr- <-PathErr-
<-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アドレスを通知するRequestオブジェクトを含むパス* = Pathメッセージ
Resv* = Resv message containing a Notify Request object with RSVP Receiver Proxy IP address
RSVPレシーバープロキシのIPアドレスで通知するRequestオブジェクトを含むRESV * = 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
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.
通知メッセージを経由して送信者通知の方法が使用されている場合は、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.
このセクションで定義された手順をサポートしていない送信者は、それはより速く、上流の通知を得ることに興味を持っているという理由だけで、予約のためのPathメッセージにRequestオブジェクトに通知が含まれる場合があります。予約はこのセクションで定義された手順をサポートするRSVP受信側プロキシによって制御されている場合、送信者はまた、下流の通知を含む予期しない通知メッセージを受信します。このような送信者は、単に自然に無効などの下流の通知をドロップすることが期待されます。それはRSVPレシーバープロキシものPathErrメッセージを介して送信者に通知を発行することを送信者に通知が通知メッセージを介して行われる場合でも、送信者がまだ「のPathErrを経由して送信者通知」に従って予約の失敗が通知されます上記の推奨されているので方法。要約すると、レシーバープロキシのメソッドを「通知を経由して送信者通知」オプションをアクティブにすると、メソッド「のPathErrを経由して送信者通知」MANDATORYに依存するから、このメソッドをサポートしていない送信者を防ぐことはできません。しかし、この方法「通知を経由して送信者通知」支援送信者は、このオプションのメソッドを利用できるようになります。
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で議論するようにのPathErr方法と同様である：通知、FF又はSEで、それぞれ、送信者または影響を受けた送信者の組に送信されなければなりません。 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メッセージを生成する際、レシーバプロキシは、Pathメッセージを転送しなければならない下流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
*** * R *通常のRSVPルータ***
(R1) = Path message contains a Session object whose destination is R1
（R1）は= Pathメッセージは、その宛先R1されたセッションオブジェクトを含みます
***> media flow
***>メディアフロー
==> segment of flow path protected by RSVP reservation
==>流路のセグメントRSVP予約により保護
Figure 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のリフレッシュ間隔を送ったPathメッセージは、（例えば、デフォルトでは30秒）に対応することはありません。しかしながら、これらのメッセージは、帯域幅の小さな量を消費し、加えて、第1の受信プロキシの下流RSVP対応中点のノードでいくつかのRSVP状態をインストールします。これは非常にマイナーな準最適と見られています。しかし、これを緩和するために、レシーバープロキシは、（それが大きいまたはパスのリフレッシュ間隔に等しいはずである）、所定時間後に任意の未回答の下流パスの状態を取り壊すことができ、フローのためのPathメッセージの送信を停止することがあります（または唯一のそれらを送るかもしれませんはるかに低い周波数で）。
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.
この文書では、レシーバのプロキシ制御ポリシー要素と呼ばれる新しいポリシー要素を定義します。この文書では、唯一のPathメッセージ内とユニキャストの予約のため、このポリシー要素の使用を定義します。その他の使用方法は、この文書の範囲外です。
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（レシーバ・プロキシ必要）：このポリシーエレメントは、対応するPathメッセージは、この制御値が含まれている場合、そのフローのための受信機プロキシとしてそれ自身を挿入しようとしなければならない理解RSVP受信プロキシ。セクション4.1で指定されたレシーバープロキシも下流RSVP機能の動的検出をサポートしている場合、それはまだPathメッセージを下流に送信し、予約が最後レシーバープロキシに拡張することができるように）下流の予約を拡張しようとしなければなりません。それは知っているときに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レシーバープロキシ対応するPathメッセージは、この制御値が含まれている場合、このポリシー要素は、その流れのためのレシーバープロキシとしての地位を挿入しようとしてはなりません理解しています。それは知っているときに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)
<--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
*** * R *正規RSVP ***ルータ（R1）= Pathメッセージは、その宛先R1されたセッションオブジェクトを含みます
(N) = Path message contains a Receiver Proxy Control policy element whose Control-Value is set to Receiver-Proxy-Needed
（N）= Pathメッセージは、その制御値レシーバ・プロキシ必要に設定されている受信プロキシ制御ポリシーエレメントを含んでいます
(NN) = Path message contains a Receiver Proxy Control policy element whose Control-Value is set to Receiver-Proxy-Not-Needed
（NN）は= Pathメッセージは、制御値がReceiver-プロキシ-必要としないに設定されているレシーバープロキシ制御ポリシー要素が含まれています
***> media flow ==> segment of flow path protected by RSVP reservation
***>メディアフロー==>流路のセグメントRSVP予約により保護
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で指定されるように、ポリシー無知ノード（ピン）これらのオブジェクトはつのポリシー施行点（PEP）から別の輸送中にPINを通過できることを確実POLICY_DATAオブジェクトのデフォルト処理を実装します。これは、これらのオブジェクトは、PINを横断できるように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キータイプとキープロビジョニング方法ならびにそれらのそれぞれの適用性を論じています。 （[RFC2747]及び[RFC3097]で定義される）RSVP認証は、この文書の実装によってサポートされてください。
[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]もIPsecのメカニズム（[RFC4302]、[RFC4303]）とRSVPのセキュリティ保護のための関連キープロビジョニング方法の適用を論じています。この議論は、この文書で定義されたパス・トリガRSVPレシーバープロキシの存在下でのRSVPの保護に適用されます。
A subset of RSVP messages are signaled with the IP router alert option ([RFC2113], [RFC2711]). Based on the current security concerns associated with the use of the IP router alert option, the applicability of RSVP (and therefore of the RSVP Proxy approaches discussed in this document) is limited to controlled environments (i.e., 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予約は、受信機によって制御されなくなり、むしろ送信者に代わって受信プロキシ（Pathメッセージで送信者から受信されたヒントを使用して）によって制御されます。したがって、受信機プロキシ適切RSVP予約を制御するために、エンドシステムによって信頼されるべきです。しかし、基本的なRSVPの動作は既にエンドシステムの信頼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レシーバープロキシの使用は、セキュリティリスクを軽減する状況があります。ネットワークオペレータは、ネットワーク内のリソース予約およびアドミッション制御を実行するためにRSVPに依存しており、多くのRSVP受信機は、オペレータの顧客の敷地内に位置していながら、RSVP送信者とRSVPルータは、オペレータの構内に置かれている場所をどこ一例です。このような環境はさらに、付録A.1、[RFC5945]の「ブロードバンド集約ネットワークにおけるRSVPベースのVoDアドミッションコントロール」に示されています。受信機は、物理的に保護されていない、従って、改ざんされたのより高いリスクにさらされる場所でありながら、オペレータの観点から、RSVPルータとRSVP送信者は、物理的に保護された場所にあり、従って、改ざんされているのより低いリスクにさらされます。 RSVP受信プロキシ機能を使用することは、効果的にその動作から完全に除く受信機によってオペレータの予約および入場制御ソリューションのセキュリティを増大させます。フィルタは、エンドユーザから受信したRSVPメッセージを破棄、オペレータネットワークのエッジに配置することができます。これは、オペレータのネットワーク内で動作してRSVP予約とアドミッションコントロールソリューションの非常にシンプルかつ効果的な保護を提供します。
5.1. Security Considerations for the Sender Notification via Notify Message
5.1. 通知メッセージを介して送信者への通知のためのセキュリティの考慮事項
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
このドキュメントは、セクション3.2、[RFC3473]で指定された通知メッセージの用途に依存する任意の方法で、定義しています。通知メッセージはRSVPホップバイホップ整合性と認証モデルの使用を妨げる非ホップバイホップ方式で送信することができます。 [RFC3473]適用のセキュリティの考慮事項のセクションで説明この問題に対処するためのアプローチと考慮事項。に
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.
特に、ここで通知メッセージは、非ホップバイホップ送信され、[RFC2747]で提供されるセキュリティの同じレベルが所望される、IPsecベースの完全性及び認証（[RFC4302]または[RFC4303]）を用いることができます。また、Notifyメッセージを非ホップバイホップの送信は無効にすることができます。最後に、[SEC-GRP-KEYは非ホップバイホップメッセージを通知するためのキーインググループの適用可能性を論じています。
5.2. Security Considerations for the Receiver Proxy Control Policy Element
5.2. レシーバープロキシ制御ポリシー要素のためのセキュリティの考慮事項
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によってシグナリングされます。 [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.
第1の機構は、すべてのRSVPノードがポリシーが可能である場合に、信頼の連鎖を提供する上述RSVP認証に依存しています。このメカニズムでは、INTEGRITYオブジェクトは、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のメカニズムは、隣人をRSVPされていないRSVPポリシー施行ポイント（のPEP）との整合性を保証するためにPOLICY_DATAオブジェクト内INTEGRITYオブジェクトに依存しています。これは、いくつかのRSVPノードがポリシー無知なノード（ピン）の場合のみ有効です。 POLICY_DATAオブジェクト内のINTEGRITYオブジェクトは、この文書の実装によってサポートされるかもしれません。
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.
INTEGRITYオブジェクトの内容を計算するための詳細は、[RFC2750]の付録Bに見出すことができます。これは、ポリシー決定ポイント（PDP）は、その裁量で、宛先PEP / 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
ここで、非RSVPホップがRSVPホップの間で存在し得る、ならびにRSVP対応ポリシー無知ノード（PINが）のPEPとの間で存在し得る場合、それは先のPDPが何のためにあるのかを決定するためにPDPのために困難であってもよいことに留意されたいですPOLICY_DATAオブジェクトは（例えば、Pathメッセージのような）いくつかのRSVPメッセージに含まれています。これらのケースでは、次のPEPは、メッセージを転送する時には知られていないためです。このような状況では、複数のPDP全体で共有キーを使用することができます。 [SEC-GRP-KEY]で説明したように、これは、複数のRSVPネイバ間で共有キーを使用すると概念的に類似しています。私たちは、この問題は、単一のいくつかの展開シナリオには存在しない可能性があることもを観察します
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).
PDP（プラズマディスプレイパネル又は低い数）（例えば管理ドメインなど）領域の全てのPEPを制御するために使用されます。そのようなシナリオにおいては、ネクストホップPDPは、ネクストホップPEPは、単に次の領域は、それがに基づいて、たとえば（トラバースされているかを決定することによって、知られていない場合でも、何であるかを決定するために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で説明したように、このドキュメントは[RFC2205]のみResvErrメッセージでの使用は、IANAは、「エラーコードの下でこれらの2つのエラーコードのための既存のエントリを更新した指定しながら、2つのエラー・コードがのPathErrメッセージで使用することができますので、そしてグローバル定義のエラー値サブコード」レジストリ。各エントリは、[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:
セクション3.1.2で説明したようにIANAはまた、新しい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で、この文書は、Receiverプロキシ制御ポリシーエレメント内の制御値フィールドを定義します。 IANAは、「レシーバープロキシ制御ポリシー要素（P型0x07の）制御値フィールド」のレジストリを作成し、以下の値を割り当てています。
o 0 : Reserved
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の中の数字は、範囲128から240の中の数字は、基礎「最初の最初に添え是非」、および中の番号に割り当てられている、「IETFレビュー」ポリシーに応じて割り当てられ、範囲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.
この文書では、キャロルIturraldeとANCA Zamfirとの議論の恩恵を受けました。ルー・バーガー、エードリアンファレル、ジョンドレイクPath_State_Removedフラグの使用に、特に、レビューとガイダンスを提供し、通知メッセージの、両方が[RFC3473]から借用します。我々はまた、彼らの貴重な入力と提案の強化のためにスティーブン・ケント、ケン・カールバーグ、およびティムポークに感謝します。最後に、我々は、拡張予約スパンを最大化し、エンドツーエンドのRSVPモデルにプロキシモデルからの移行を円滑に仕事を刺激するためのカレン・ジェニングス、マグヌスウェスター、ロバート・スパークスに感謝します。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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]ウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]ブレーデン、R.とL.チャン、 "RSVP暗号化認証 - 更新メッセージタイプ価値"、RFC 3097、2001年4月。
[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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[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]ヘルツォーク、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]ルFaucheur、F.、マナー、J.、ウィング、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]ル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]ベリンガー、M.とF.ル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
フランソワ・リーパーシスコシステムズグリーンサイド、400アベニューRoumanille 06410ソフィアアンティポリスフランス電話：+33 4 97 23 26 19 Eメール：flefauch@cisco.com
Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland Phone: +358 9 470 22481 EMail: jukka.manner@tkk.fi URI: http://www.netlab.tkk.fi/~jmanner/
コミュニケーションとネットワーキングのユッカマナーアールト大学学部（Comnet）P。ボックス13000 FIN-00076アアルトフィンランド電話：+358 9 470 22481 Eメール：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
アショク・ナラヤナンシスコシステムズ300ビーバーブルック・ロードボックスボロー、MA 01719米国電子メール：ashokn@cisco.com
Allan Guillou SFR 40-42 Quai du Point du Jour Boulogne-Billancourt 92659 France EMail: allan.guillou@sfr.com
アランGuillou SFR 40-42湖岸通りポイントドゥジュール92659ブーローニュビヤンクールフランスEメール：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マリクはエアテル、ltidを交換してください。 4階には、ノープロットします。 16仕事ビハール、グルガオンの顔、インド122015 Eメール：హేమంత్.మాలిక్@ఎయిర్టెల్.ఇన్