[要約] RFC 4495は、帯域幅を削減するためのリソース予約プロトコル（RSVP）の拡張に関するものです。このRFCの目的は、予約フローの帯域幅を最小限に抑えるための手法を提案することです。
Network Working Group J. Polk
Request for Comments: 4495 S. Dhesikan
Updates: 2205 Cisco Systems
Category: Standards Track May 2006
A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
リソース予約プロトコル（RSVP）予約フローの帯域幅を減らすための拡張
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations, or other forms of RSVP tunnels. This specification is an extension of RFC 2205.
このドキュメントは、既存の予約に割り当てられた保証された帯域幅を減らすために、リソース予約プロトコル（RSVPV1）の拡張を提案しています。このメカニズムは、個々の予約、総留保、またはRSVPトンネルの他の形式に影響を与えるために使用できます。この仕様は、RFC 2205の拡張です。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. Individual Reservation Reduction Scenario .......................4
3. RSVP Aggregation Overview .......................................6
3.1. RSVP Aggregation Reduction Scenario ........................8
4. Requirements for Reservation Reduction ..........................9
5. RSVP Bandwidth Reduction Solution ..............................10
5.1. Partial Preemption Error Code .............................11
5.2. Error Flow Descriptor .....................................11
5.3. Individual Reservation Flow Reduction .....................11
5.4. Aggregation Reduction of Individual Flows .................12
5.5. RSVP Flow Reduction Involving IPsec Tunnels ...............12
5.6. Reduction of Multiple Flows at Once .......................13
6. Backwards Compatibility ........................................13
7. Security Considerations ........................................14
8. IANA Considerations ............................................15
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................16
Appendix A. Walking through the Solution ..........................17
This document proposes an extension to the Resource Reservation Protocol (RSVP) [1] to allow an existing reservation to be reduced in allocated bandwidth in lieu of tearing that reservation down when some of that reservation's bandwidth is needed for other purposes. Several examples exist in which this mechanism may be utilized.
このドキュメントでは、リソース予約プロトコル（RSVP）[1]の拡張を提案して、その予約の一部が他の目的に必要な場合に、その予約を引き裂く代わりに、割り当てられた帯域幅で既存の予約を削減できるようにします。このメカニズムを利用できるいくつかの例が存在します。
The bandwidth allotted to an individual reservation may be reduced due to a variety of reasons such as preemption, etc. In such cases, when the entire bandwidth allocated to a reservation is not required, the reservation need not be torn down. The solution described in this document allows endpoints to negotiate a new (lower) bandwidth that falls at or below the specified new bandwidth maximum allocated by the network. Using a voice session as an example, this indication in RSVP could lead endpoints, using another protocol such as Session Initiation Protocol (SIP) [9], to signal for a lower-bandwidth codec and retain the reservation.
個々の予約に割り当てられた帯域幅は、先制などのさまざまな理由により減少する可能性があります。そのような場合、予約に割り当てられた帯域幅全体が必要ない場合、予約を取り壊す必要はありません。このドキュメントで説明されているソリューションにより、エンドポイントは、ネットワークによって割り当てられた指定された新しい帯域幅の最大値以下にある新しい（低い）帯域幅をネゴシエートすることができます。例として音声セッションを使用すると、RSVPでのこの表示は、セッション開始プロトコル（SIP）[9]などの別のプロトコルを使用して、低帯域幅コードのシグナルを使用して予約を維持するためにエンドポイントをリードする可能性があります。
With RSVP aggregation [2], two aggregate flows with differing priority levels may traverse the same router interface. If that router interface reaches bandwidth capacity and is then asked to establish a new reservation or increase an existing reservation, the router has to make a choice: deny the new request (because all resources have been utilized) or preempt an existing lower-priority reservation to make room for the new or expanded reservation.
RSVP集約[2]では、優先度レベルが異なる2つの集計フローが同じルーターインターフェイスを横断する可能性があります。そのルーターインターフェイスが帯域幅の容量に達し、新しい予約を確立するか、既存の予約を増やすように求められた場合、ルーターは選択を行う必要があります。新しいまたは拡張された予約のためのスペースを作る。
If the flow being preempted is an aggregate of many individual flows, this has greater consequences. While [2] clearly does not terminate all the individual flows if an aggregate is torn down, this event will cause packets to be discarded during aggregate reservation reestablishment. This document describes a method where only the minimum required bandwidth is taken away from the lower-priority aggregated reservation and the entire reservation is not preempted. This has the advantage that only some of the microflows making up the aggregate are affected. Without this extension, all individual flows are affected and the deaggregator will have to attempt the reservation request with a reduced bandwidth.
先制されるフローが多くの個々のフローの集合体である場合、これは大きな結果をもたらします。[2]は、集約が取り壊された場合、すべての個々のフローを明らかに終了しませんが、このイベントは、総予約の再確立中にパケットを破棄します。このドキュメントでは、最小必要な帯域幅のみがより低い優先度の集約予約から除外され、予約全体が先制されない方法について説明します。これには、骨材を構成するマイクロフローの一部のみが影響を受けるという利点があります。この拡張機能がなければ、すべての個々のフローが影響を受け、Deaggregatorは帯域幅を減らして予約要求を試みなければなりません。
RSVP tunnels utilizing IPsec [8] also require an indication that the reservation must be reduced to a certain amount (or less). RSVP aggregation with IPsec tunnels is being defined in [11], which should be able to take advantage of the mechanism created here in this specification.
IPSEC [8]を使用しているRSVPトンネルには、予約を一定量（またはそれ以下）に削減する必要があることを示す必要があります。IPSECトンネルとのRSVP集約は[11]で定義されています。これは、この仕様でここで作成されたメカニズムを活用できるはずです。
Note that when this document refers to a router interface being "full" or "at capacity", this does not imply that all of the bandwidth has been used, but rather that all of the bandwidth available for reservation(s) via RSVP under the applicable policy has been used. Policies for real-time traffic routinely reserve capacity for routing and inelastic applications, and may distinguish between voice, video, and other real-time applications.
このドキュメントは、ルーターインターフェイスが「フル」または「容量」であることを指している場合、これはすべての帯域幅が使用されていることを意味するのではなく、むしろすべての帯域幅がRSVPを介して予約できるすべての帯域幅が使用可能であることを意味します。該当するポリシーが使用されています。リアルタイムトラフィックのポリシーは、ルーティングおよび非弾性アプリケーションのための定期的に容量を確保し、音声、ビデオ、およびその他のリアルタイムアプリケーションを区別する場合があります。
Explicit Congestion Notification (ECN) [10] is an indication that the transmitting endpoint must reduce its transmission. It does not provide sufficient indication to tell the endpoint by how much the reduction should be. Hence the application may have to attempt multiple times before it is able to drop its bandwidth utilization below the available limit. Therefore, while we consider ECN to be very useful for elastic applications, it is not sufficient for the purpose of inelastic application where an indication of bandwidth availability is useful for codec selection.
明示的な混雑通知（ECN）[10]は、送信エンドポイントが送信を減らす必要があることを示しています。エンドポイントにどれだけの削減があるべきかを伝えるのに十分な兆候は提供されません。したがって、アプリケーションは、利用可能な制限を下回る帯域幅の使用率を削除する前に、複数回試行する必要がある場合があります。したがって、ECNは弾性アプリケーションに非常に役立つと考えていますが、帯域幅の可用性を示すことがコーデックの選択に役立つ非弾性アプリケーションの目的では不十分です。
Section 2 discusses the individual reservation flow problem, while Section 3 discusses the aggregate reservation flow problem space. Section 4 lists the requirements for this extension. Section 5 details the protocol changes necessary in RSVP to create a reservation reduction indication. And finally, the appendix provides a walk-through example of how this extension modifies RSVP functionality in an aggregate scenario.
セクション2では、個々の予約フローの問題について説明し、セクション3では、総予約フローの問題スペースについて説明します。セクション4には、この拡張機能の要件を示します。セクション5では、RSVPで必要なプロトコルの変更について、予約削減の表示を作成します。最後に、付録は、この拡張機能が集計シナリオでRSVP機能をどのように変更するかのウォークスルー例を示しています。
This document updates RFC 2205 [1], as this mechanism affects the behaviors of the ResvErr and ResvTear indications defined in that document.
このドキュメントは、RFC 2205 [1]を更新します。このメカニズムは、そのドキュメントで定義されているRESVERRおよびRESVTEAR表示の動作に影響を与えるためです。
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 [4].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[4]で説明されているように解釈される。
Figure 1 is a network topology that is used to describe the benefit of bandwidth reduction in an individual reservation.
図1は、個々の予約における帯域幅の削減の利点を説明するために使用されるネットワークトポロジです。
+------------+ +------------+
| |Int 1 | |Int 7 | |
Flow 1===> | +----- | |------+ | Flow 1===>
| R1 |Int 2 |===========>|Int 8 | R2 |
| | |:::::::::::>| | |
Flow 2:::> | +----- | |------+ | Flow 2:::>
| |Int 3 | |Int 9 | |
+------------+ +------------+
Figure 1. Simple Reservation Flows
図1.単純な予約フロー
Legend/Rules:
伝説/ルール：
- Flow 1 priority = 300 - Flow 2 priority = 100 - Both flows are shown in the same direction (left to right). Corresponding flows in the reverse direction are not shown for diagram simplicity
- フロー1優先度= 300-フロー2優先度= 100-両方のフローが同じ方向（左から右）に表示されます。逆方向の対応するフローは、図の単純さでは示されていません
RSVP is a reservation establishment protocol in one direction only. This split-path philosophy is because the routed path from one device to the other in one direction might not be the routed path for communicating between the same two endpoints in the reverse direction. End-systems must request 2 one-way reservations if that is what is needed for a particular application (like voice calls). Please refer to [1] for the details on how this functions. This example only describes the reservation scenario in one direction for simplicity's sake.
RSVPは、一方向のみの予約施設プロトコルです。このスプリットパス哲学は、一方の方向にあるデバイスから別のデバイスへのルーティングされたパスが、同じ2つのエンドポイント間で逆方向に通信するためのルーティングパスではない可能性があるためです。エンドシステムは、それが特定のアプリケーション（音声通話など）に必要なものである場合、2つの一方向予約を要求する必要があります。この機能の詳細については、[1]を参照してください。この例では、シンプルさのために、一方向の予約シナリオのみを説明しています。
Figure 1 depicts 2 routers (R1 and R2) initially with only one flow (Flow 1). The flows are forwarded from R1 to R2 via Int 2. For this example, let us say that Flow 1 and Flow 2 each require 80 units of bandwidth (such as for the codec G.711 with no silence suppression).
図1は、最初は1つのフロー（フロー1）のみで2つのルーター（R1とR2）を示しています。フローは、INT 2を介してR1からR2に転送されます。この例では、流れ1とフロー2にはそれぞれ80単位の帯域幅が必要であるとしましょう（沈黙抑制のないコーデックG.711など）。
Let us also say that the RSVP bandwidth limit for Int 2 of R1 is 100 units.
また、R1のInt 2のRSVP帯域幅制限は100単位であると言ってみましょう。
As described in [3], a priority indication is established for each flow. In fact, there are two priority indications:
[3]で説明されているように、各フローに対して優先度の表示が確立されます。実際、2つの優先度の表示があります。
1) one to establish the reservation, and
1) 予約を確立するために、そして
2) one to defend the reservation.
2) 予約を守るためのもの。
In this example, Flow 1 and Flow 2 have an 'establishing' and a 'defending' priority of 300 and 100, respectively. Flow 2 will have a higher establishing priority than Flow 1 has for its defending priority. This means that when Flow 2 is signaled, and if no bandwidth is available at the interface, Flow 1 will have to relinquish bandwidth in favor of the higher-priority request of Flow 2. The priorities assigned to a reservation are always end-to-end, and not altered by any routers in transit.
この例では、Flow 1とFlow 2には、それぞれ300と100の「確立」と「防御」優先度があります。Flow 2は、フロー1が防御の優先順位に対して持っているよりも高い優先度を持ちます。これは、Flow 2が信号を受け、インターフェイスで帯域幅が利用できない場合、Flow 1はより優先度の高いリクエストを支持して帯域幅を放棄する必要があることを意味します。終了し、輸送中のルーターによって変更されません。
Without the benefit of this specification, Flow 1 will be preempted. This specification makes it possible for the ResvErr message to indicate that 20 units are still available for a reservation to remain up (the interface's 100 units maximum minus Flow 2's 80 units). The reservation initiating node (router or end-system) for Flow 1 has the opportunity to renegotiate (via call signaling) for acceptable parameters within the existing and available bandwidth for the flow (for example, it may decide to change to using a codec such as G.729)
この仕様の利点がなければ、Flow 1は先制されます。この仕様により、RESVERRメッセージは、予約が留まるために20ユニットがまだ利用可能であることを示すことができます（インターフェイスの100ユニットの最大値マイナスフロー2の80ユニット）。フロー1の予約開始ノード（ルーターまたはエンドシステム）は、フローの既存および利用可能な帯域幅内の許容可能なパラメーターに対して（コールシグナルを介して）再交渉する機会があります（たとえば、そのようなコーデックの使用に変更することを決定する場合がありますG.729として）
The problems avoided with the partial failure of the flow are:
フローの部分的な障害で避けられた問題は次のとおりです。
- Reduced packet loss, which results as Flow 1 attempts to reestablish the reservation for a lower bandwidth.
- パケット損失の減少。これは、フロー1が低帯域幅の予約を再確立しようとすると結果として生じます。
- Inefficiency caused by multiple attempts until Flow 1 is able to request bandwidth equal to or lower than what is available. If Flow 1 is established with much less than what is available then it leads to inefficient use of available bandwidth.
- Flow 1が利用可能なものよりも等しいか低い帯域幅を要求できるまで、複数の試行によって引き起こされる非効率性。Flow 1が利用可能なものよりもはるかに少ないと確立されている場合、利用可能な帯域幅の非効率的な使用につながります。
The following network overview is to help visualize the concerns that this specification addresses in RSVP aggregates. Figure 2 consists of 10 routers (the boxes) and 11 flows (1, 2, 3, 4, 5, 9, A, B, C, D, and E). Initially, there will be 5 flows per aggregate (Flow 9 will be introduced to cause the problem we are addressing in this document), with 2 aggregates (X and Y); Flows 1 through 5 in aggregate X and Flows A through E in aggregate Y. These 2 aggregates will cross one router interface utilizing all available capacity (in this example).
次のネットワークの概要は、この仕様がRSVP集合体で扱う懸念を視覚化するのに役立ちます。図2は、10個のルーター（ボックス）と11個のフロー（1、2、3、4、5、9、A、B、C、D、およびE）で構成されています。最初は、集合体ごとに5つのフローがあります（このドキュメントで対処する問題を引き起こすためにフロー9が導入されます）、2つの集計（xとy）。集合体Xで1〜5を流し、集合体YでaからEを流します。これら2つの集合体は、利用可能なすべての容量を使用して1つのルーターインターフェイスを越えます（この例で）。
RSVP aggregation (per [2]) is no different from an individual reservation with respect to being unidirectional.
RSVP集約（[2]ごと）は、単方向であることに関して個々の予約と違いはありません。
Aggregator of X Deaggregator of X
| |
V V
+------+ +------+ +------+ +------+
Flow 1-->| | | | | | | |-->Flow 1
Flow 2-->| | | | | | | |-->Flow 2
Flow 3-->| |==>| | | |==>| |-->Flow 3
Flow 4-->| | ^ | | | | ^ | |-->Flow 4
Flow 5-->| | | | | | | | | |-->Flow 5
Flow 9 | R1 | | | R2 | | R3 | | | R4 | Flow 9
+------+ | +------+ +------+ | +------+
| || || |
Aggregate X-->|| Aggregate X ||<--Aggregate X
|| | ||
+--------------+ | +--------------+
| |Int 7 | | |Int 1 | |
| +----- | V |------+ |
| R10 |Int 8 |===========>|Int 2 | R11 |
| | |:::::::::::>| | |
| +----- | ^ |------+ |
| |Int 9 | | |Int 3 | |
+--------------+ | +--------------+
.. | ..
Aggregate Y--->.. Aggregate Y ..<---Aggregate Y
| .. .. |
+------+ | +------+ +------+ | +------+
Flow A-->| | | | | | | | | |-->Flow A
Flow B-->| | V | | | | V | |-->Flow B
Flow C-->| |::>| | | |::>| |-->Flow C
Flow D-->| | | | | | | |-->Flow D
Flow E-->| R5 | | R6 | | R7 | | R8 |-->Flow E
+------+ +------+ +------+ +------+
^ ^
| |
Aggregator of Y Deaggregator of Y
Figure 2. Generic RSVP Aggregate Topology
図2.一般的なRSVP集約トポロジ
Legend/Rules:
伝説/ルール：
- Aggregate X priority = 100 - Aggregate Y priority = 200 - All boxes are routers - Both aggregates are shown in the same direction (left to right). Corresponding aggregates in the reverse direction are not shown for diagram simplicity.
- 集約x優先度= 100 -集合体y優先度= 200 -すべてのボックスはルーターです - 両方の集合体は同じ方向（左から右）に表示されます。逆方向の対応する集合体は、図の単純さでは示されていません。
The path for aggregate X is:
集約xのパスは次のとおりです。
R1 => R2 => R10 => R11 => R3 => R4
where aggregate X starts in R1, and deaggregates in R4.
ここで、集約XはR1で始まり、R4で脱毛剤が始まります。
Flows 1, 2, 3, 4, 5, and 9 communicate through aggregate A.
フロー1、2、3、4、5、および9は、集合体Aを通じて通信します。
The path for aggregate Y is:
yのyのパスは次のとおりです。
R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
where aggregate Y starts in R5, and deaggregates in R8.
ここで、凝集体yはR5で始まり、R8でdeaggregが拡張します。
Flows A, B, C, D, and E communicate through aggregate B.
流れa、b、c、d、およびeは総計Bを通じて通信します
Both aggregates share one leg or physical link: between R10 and R11, thus they share one outbound interface: Int 8 of R10, where contention of resources may exist. That link has an RSVP capacity of 800 kbps. RSVP signaling (messages) is outside the 800 kbps in this example, as is any session signaling protocol like SIP.
どちらの集合体も、1つの脚または物理的リンクを共有します：R10とR11の間では、リソースの競合が存在する可能性のあるR10のINT 8のアウトバウンドインターフェイスを1つ共有します。そのリンクのRSVP容量は800 kbpsです。この例では、RSVPシグナル伝達（メッセージ）は800 kbpsの外側にあり、SIPのようなセッションシグナリングプロトコルも同様です。
Figure 2 shows an established aggregated reservation (aggregate X) between the routers R1 and R4. This aggregated reservation consists of 5 microflows (Flows 1, 2, 3, 4, and 5). For the sake of this discussion, let us assume that each flow represents a voice call and requires 80 kb (such as for the codec G.711 with no silence suppression). Aggregate X request is for 400 kbps (80 kbps * 5 flows). The priority of the aggregate is derived from the individual microflows that it is made up of. In the simple case, all flows of a single priority are bundled as a single aggregate (another priority level would be in another aggregate, even if traversing the same path through the network). There may be other ways in which the priority of the aggregate is derived, but for this discussion it is sufficient to note that each aggregate contains a priority (both hold and defending priority). The means of deriving the priority is out of scope for this discussion.
図2は、ルーターR1とR4の間に確立された集約予約（集約x）を示しています。この集約された予約は、5つのマイクロフローで構成されています（フロー1、2、3、4、および5）。この議論のために、各フローが音声コールを表し、80 KBが必要であると仮定しましょう（沈黙の抑制のないコーデックG.711など）。集計Xリクエストは400 kbps（80 kbps * 5フロー）の場合です。骨材の優先度は、それが構成されている個々のマイクロフローから派生しています。単純な場合、単一の優先度のすべてのフローが単一の集計としてバンドルされます（別の優先度レベルは、ネットワークを通って同じパスを通過しても、別の集計です）。集合体の優先順位が導出される他の方法があるかもしれませんが、この議論では、各集合体に優先順位が含まれていることに注意するだけで十分です（ホールドとディフェンディングの優先順位）。優先事項を導き出す手段は、この議論の範囲外です。
Aggregate Y, in Figure 2, consists of Flows A, B, C, D, and E and requires 400 kbps (80 kbps * 5 flows), and starts at R5 and ends R8. This means there are two aggregates occupying all 800 kbps of the RSVP capacity.
図2の凝集Yは、流れa、b、c、d、およびeで構成され、400 kbps（80 kbps * 5フロー）が必要であり、R5から始まり、R8を終了します。これは、RSVP容量の800 kbpsすべてを占める2つの集合体があることを意味します。
When Flow 9 is added into aggregate X, this will occupy 80 kbps more than Int 8 on R10 has available (880k offered load vs. 800k capacity) [1] and [2] create a behavior in RSVP to deny the entire aggregate Y and all its individual flows because aggregate X has a higher priority. This situation is where this document focuses its requirements and calls for a solution. There should be some means to signal to all affected routers of aggregate Y that only 80 kbps is needed to accommodate another (higher priority) aggregate. A solution that accomplishes this reduction instead of a failure could:
流れ9が集合体Xに追加されると、これはR10でint 8を超える80 kbpsを占有します（880kは荷重と800k容量を提供します）[1]と[2]は、RSVPの動作を作成し、集合体y全体を拒否し、集合体Xの優先度が高いため、すべての個々のフローが流れます。この状況は、このドキュメントが要件に焦点を当て、ソリューションを要求する場所です。別の（優先度の高い）凝集体に対応するために80 kbpsのみが必要であることを、骨材yのすべての影響を受けるルーターに信号を送るためのいくつかの手段があるはずです。障害の代わりにこの削減を達成するソリューションは次のとおりです。
- reduce significant packet loss of all flows within aggregate Y
- 集合体内のすべてのフローの大幅なパケット損失を減らす
During the re-reservation request period of time no packets will traverse the aggregate until it is reestablished.
再保存要求期間中、再確立されるまでパケットは集約を横断しません。
- reduces the chances that the reestablishment of the aggregate will reserve an inefficient amount of bandwidth, causing the likely preemption of more individual flows at the aggregator than would be necessary had the aggregator had more information (that RSVP does not provide at this time)
- 骨材の再確立が非効率的な量の帯域幅を留保する可能性を減らし、アグリゲーターがより多くの情報を持っていた場合、必要になるよりも多くの個々のフローをアグリゲーターでより多くの個別のフローを先取りする可能性があります（RSVPは現時点では提供しません）
During reestablishment of the aggregation in Figure 2 (without any modification to RSVP), R8 would guess at how much bandwidth to ask for in the new RESV message. It could request too much bandwidth, and have to wait for the error that not that much bandwidth was available; it could request too little bandwidth and have that aggregation accepted, but this would mean that more individual flows would need to be preempted outside the aggregate than were necessary, leading to inefficiencies in the opposite direction.
図2の集約が再確立されている間（RSVPに変更されていない）、R8は新しいRESVメッセージでどの帯域幅を要求するかを推測します。帯域幅が多すぎると、それほど多くの帯域幅が利用できないというエラーを待つ必要があります。帯域幅が少なすぎてその集合体を受け入れることができますが、これは、より多くの個々のフローを必要以上に骨材の外側で先取りする必要があり、反対方向の非効率性につながることを意味します。
The following are the requirements to reduce the bandwidth of a reservation. This applies to both individual and aggregate reservations:
以下は、予約の帯域幅を減らすための要件です。これは、個人と集計の両方の予約に適用されます。
Req#1 - MUST have the ability to differentiate one reservation from another. In the case of aggregates, it MUST distinguish one aggregate from other flows.
req＃1-ある予約を別の予約と区別する機能が必要です。集合体の場合、1つの凝集体を他の流れと区別する必要があります。
Req#2 - MUST have the ability to indicate within an RSVP error message (generated at the router with the congested interface) that a specific reservation (individual or aggregate) is to be reduced in bandwidth.
REQ＃2-特定の予約（個別または骨材）が帯域幅で削減されることをRSVPエラーメッセージ（混雑したインターフェイスを使用してルーターで生成）内で示す機能が必要です。
Req#3 - MUST have the ability to indicate within the same error message the new maximum amount of bandwidth that is available to be utilized within the existing reservation, but no more.
REQ＃3-同じエラーメッセージ内で、既存の予約内で利用できる新しい最大帯域幅を示す機能が必要ですが、それ以上はありません。
Req#4 - MUST NOT produce a case in which retransmitted reduction indications further reduce the bandwidth of a reservation. Any additional reduction in bandwidth for a specified reservation MUST be signaled in a new message.
REQ＃4-再送信された削減適応が予約の帯域幅をさらに減らすケースを作成してはなりません。指定された予約の帯域幅の追加の削減は、新しいメッセージで通知する必要があります。
RSVP messages are unreliable and can get lost. This specification should not compound any error in the network. If a reduction message were lost, another one needs to be sent. If the receiver ends up receiving two copies to reduce the bandwidth of a reservation by some amount, it is likely the router will reduce the bandwidth by twice the amount that was actually called for. This will be in error.
RSVPメッセージは信頼できず、迷子になります。この仕様は、ネットワーク内のエラーを悪化させるものではありません。削減メッセージが失われた場合、別のメッセージを送信する必要があります。レシーバーが予約の帯域幅をいくらか金額削減するために2つのコピーを受け取ることになった場合、ルーターは実際に求められた量の2倍の帯域幅を減らす可能性があります。これは誤っています。
When a reservation is partially failed, a ResvErr (Reservation Error) message is generated just as it is done currently with preemptions. The ERROR_SPEC object and the PREEMPTION_PRI object are included as well. Very few additions/changes are needed to the ResvErr message to support partial preemptions. A new error subcode is required and is defined in Section 5.1. The ERROR_SPEC object contained in the ResvErr message indicates the flowspec that is reserved. The bandwidth indication in this flowspec SHOULD be less than the original reservation request. This is defined in Section 5.2.
予約が部分的に失敗した場合、現在の先制で行われているように、Resverr（予約エラー）メッセージが生成されます。ERROR_SPECオブジェクトとPreEmption_Priオブジェクトも含まれています。部分的な先制をサポートするために、RESVERRメッセージに追加/変更が非常に少ないです。新しいエラーサブコードが必要であり、セクション5.1で定義されています。RESVERRメッセージに含まれるERROR_SPECオブジェクトは、予約されているFlowsPecを示します。このFlowsPecの帯域幅の表示は、元の予約要求よりも少ないはずです。これは、セクション5.2で定義されています。
A comment about RESV messages that do not use reliable transport: This document RECOMMENDS that ResvErr messages be made reliable by implementing mechanisms in [6].
信頼できるトランスポートを使用しないRESVメッセージに関するコメント：このドキュメントでは、[6]でメカニズムを実装することにより、RESVERRメッセージを信頼できることを推奨しています。
The current behavior in RSVP requires a ResvTear message to be transmitted upstream when the ResvErr message is transmitted downstream (per [1]). This ResvTear message terminates the reservation in all routers upstream of the router where the failure occurred. This document requires that the ResvTear is only generated when the reservation is to be completely removed. In cases where the reservation is only to be reduced, routers compliant with this specification require that the ResvTear message MUST NOT be sent.
RSVPでの現在の動作では、Resverrメッセージが下流（[1]に従って）送信される場合、上流の上流にresvtearメッセージを送信する必要があります。このresvtearメッセージは、障害が発生したルーターの上流のすべてのルーターの予約を終了します。このドキュメントでは、ResvTEARが予約を完全に削除する場合にのみ生成される必要があります。予約が削減される場合のみ、この仕様に準拠したルーターは、resvtearメッセージを送信しないでください。
The appendix has been written to walk through the overall solution to the problems presented in Sections 2 and 3. There is mention of this ResvTear transmission behavior in the appendix.
付録は、セクション2および3に示されている問題に対する全体的な解決策を順守するために書かれています。
The ResvErr message generated due to preemption includes the ERROR_SPEC object as well as the PREEMPTION_PRI object. The format of ERROR_SPEC objects is defined in [1]. The error code listed in the ERROR_SPEC object for preemption [5] currently is as follows:
Preemptionのために生成されたRESVERRメッセージには、ERROR_SPECオブジェクトとPreEmption_Priオブジェクトが含まれます。ERROR_SPECオブジェクトの形式は[1]で定義されています。Preemption [5]のためにERROR_SPECオブジェクトにリストされているエラーコードは、次のとおりです。
Errcode = 2 (Policy Control Failure) and ErrSubCode = 5 (ERR_PREEMPT)
errcode = 2（ポリシー制御障害）およびerrsubcode = 5（err_preempt）
The following error code is suggested in the ERROR_SPEC object for partial preemption:
部分的な先制のために、次のエラーコードがERROR_SPECオブジェクトで提案されています。
Errcode = 2 (Policy Control Failure) and ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)
errcode = 2（ポリシー制御障害）およびerrsubcode = 102（err_partial_preempt）
There is also an error code in the PREEMPTION-PRI object. This error code takes a value of 1 to indicate that the admitted flow was preempted [3]. The same error value of 1 may be used for the partial preemption case as well.
Preemption-Priオブジェクトにはエラーコードもあります。このエラーコードは1の値を取り、認められたフローが先制されたことを示します[3]。1の同じエラー値が、部分的な先制ケースにも使用できます。
The error flow descriptor is defined in [1] and [7]. In the case of partial failure, the flowspec contained in the error flow descriptor indicates the highest average and peak rates that the preempting system can accept in the next RESV message. The deaggregator must reduce its reservation to a number less than or equal to that, whether by changing codecs, dropping reservations, or some other mechanism.
エラーフロー記述子は[1]および[7]で定義されています。部分的な障害の場合、エラーフロー記述子に含まれるFlowsPecは、先制システムが次のRESVメッセージで受け入れることができる最も高い平均およびピークレートを示します。Deaggregatorは、コーデックの変更、予約の削除、またはその他のメカニズムなど、予約をそれ以上の数に減らす必要があります。
When a router requires part of the bandwidth that has been allocated to a reservation be used for another flow, the router engages in the partial reduction of bandwidth as described in this document. The router sends a ResvErr downstream to indicate the partial error with the error code and subcode as described in section 5.1. The flowspec contained in the ResvErr message will be used to indicate the bandwidth that is currently allocated.
ルーターが予約に割り当てられた帯域幅の一部を別のフローに使用する必要がある場合、ルーターはこのドキュメントで説明されているように帯域幅の部分的な削減に従事します。ルーターは、セクション5.1で説明されているように、エラーコードとサブコードで部分的なエラーを示すために下流のResverrを送信します。Resverrメッセージに含まれるFlowsPecは、現在割り当てられている帯域幅を示すために使用されます。
The requesting endpoint that receives the ResvErr can then negotiate with the transmitting endpoint to lower the bandwidth requirement (by selecting another lower bandwidth codec, for example). After the negotiations, both endpoints will issue the RSVP PATH and RESV message with the new, lowered bandwidth.
RESVERRを受信する要求エンドポイントは、送信エンドポイントと交渉して帯域幅要件を下げることができます（たとえば、別の下部帯域幅コーデックを選択することにより）。交渉の後、両方のエンドポイントは、新しい低下した帯域幅を使用してRSVPパスとRESVメッセージを発行します。
When a partial failure occurs in an aggregation scenario, the deaggregator receives the ResvErr message with the reduction indication from a router in the path of the aggregate. It then decides whether one or more individual flows from the aggregate are to be affected by this ResvErr message. The following choices are possible:
集約シナリオで部分的な障害が発生すると、Deaggregatorは、集合体の経路でルーターから削減された表示を伴うResverrメッセージを受信します。次に、骨材からの1つまたは複数の個々のフローがこのRESVERRメッセージの影響を受けるかどうかを決定します。次の選択肢が可能です。
o If that (deaggregator) router determines that one or more individual flow(s) are to partially failed, then it sends a ResvErr message with a reduced bandwidth indication to those individual flow(s). This is as per the descriptions in the previous section (5.3).
o その（Deaggregator）ルーターが、1つ以上の個々のフローが部分的に故障することを決定した場合、それらの個々のフローに対する帯域幅の表示を減らしてResverrメッセージを送信します。これは、前のセクション（5.3）の説明に従ってです。
o If that (deaggregator) router determines that one individual flow is to be preempted to satisfy the aggregate ResvErr, it determines which flow is affected. That router transmits a new ResvErr message downstream per [3]. That same router transmits a ResvTear message upstream. This ResvTear message of an individual flow does not tear down the aggregate. Only the individual flow is affected.
o その（Deaggregator）ルーターが、1つの個々のフローが凝集resverrを満たすために先制されることを決定した場合、どのフローが影響を受けるかを決定します。そのルーターは、[3]ごとに下流の新しいResverrメッセージを送信します。その同じルーターは、上流のresvtearメッセージを送信します。個々のフローのこのresvtearメッセージは、骨材を取り壊しません。個々のフローのみが影響を受けます。
o If that (deaggregator) router determines that multiple individual flows are to be preempted to satisfy the aggregate ResvErr, it chooses which flows are affected. That router transmits a new ResvErr message downstream as per [3] to each individual flow. The router also transmits ResvTear messages upstream for the same individual flows. These ResvTear messages of an individual flow do not tear down the aggregate. Only the individual flows are affected.
o その（Deaggregator）ルーターが、複数の個々のフローが凝集resverrを満たすために先制されると判断した場合、どのフローが影響を受けるかを選択します。そのルーターは、各フローに[3]に従って下流の新しいResverrメッセージを送信します。ルーターは、同じ個々のフローに対して上流のメッセージをresvtearメッセージに送信します。これらの個々のフローのメッセージは、集計を取り壊すことはありません。個々のフローのみが影響を受けます。
In all cases, the deaggregator lowers the bandwidth requested in the Aggregate Resv message to reflect the change.
すべての場合において、Deaggregatorは、変更を反映するために集計RESVメッセージで要求された帯域幅を下げます。
Which particular flow or series of flows within an aggregate are picked by the deaggregator for bandwidth reduction or preemption is outside the scope of this document.
帯域幅の削減またはプリエンプションのためにDeaggregatorによって選択される特定のフローまたは一連のフローは、このドキュメントの範囲外です。
RFC 2207 (per [8]) specifies how RSVP reservations function in IPsec data flows. The nodes initiating the IPsec flow can be an end-system like a computer, or it can router between two end-systems, or it can be an in-line bulk encryption device immediately adjacent to a router interface; [11] directly addresses this later scenario.
RFC 2207（[8] Per [8]）は、IPSECデータの流れにおけるRSVP予約機能を指定します。IPSECフローを開始するノードは、コンピューターのようなエンドシステムになる可能性があります。または、2つのエンドシステム間のルーターまたはルーターインターフェイスに隣接するインラインバルク暗号化デバイスにすることができます。[11]は、この後のシナリオに直接対処します。
The methods of identification of an IPsec with reservation flow are different from non-encrypted flows, but how the reduction mechanism specified within this document functions is not.
予約フローを使用したIPSECの識別方法は、暗号化されていないフローとは異なりますが、このドキュメント関数内で指定された還元メカニズムはそうではありません。
An IPsec with reservation flow is, for all intents and purposes, considered an individual flow with regard to how to reduce the bandwidth of the flow. Obviously, an IPsec with reservation flow can be a series of individual flows or disjointed best-effort packets between two systems. But to this specification, this tunnel is an individual RSVP reservation.
予約フローを備えたIPSECは、すべての意図と目的で、流れの帯域幅を減らす方法に関して個々のフローと見なされます。明らかに、予約フローを備えたIPSECは、2つのシステム間で一連の個々のフローまたはバラバラのベストエフォートパケットである可能性があります。しかし、この仕様に合わせて、このトンネルは個々のRSVP予約です。
Anywhere within this specification that mentions an individual reservation flow, the same rules of bandwidth reduction and preemption MUST apply.
個々の予約フローに言及するこの仕様内のどこでも、帯域幅の削減と先制の同じルールが適用する必要があります。
As a cautionary note, bandwidth SHOULD NOT be reduced across multiple reservations at the same time, in reaction to the same reduction event. A router not knowing the impact of reservation bandwidth reduction on more than one flow may cause more widespread ill effects than is necessary.
警告的なメモとして、同じ削減イベントに反応して、同時に複数の予約にわたって帯域幅を減らすべきではありません。予約帯域幅の減少が複数の流れに及ぼす影響を知らないルーターは、必要以上に広範な悪影響を引き起こす可能性があります。
This says nothing to a policy where preemption should or should not occur across multiple flows.
これは、複数のフローにわたって先制が発生するかどうかにかかわらないポリシーには何も述べていません。
Backwards compatibility with this extension will result in RSVP operating as it does without this extension, and no worse. The two routers involved in this extension are the router that had the congested interface and the furthest downstream router that determines what to do with the reduction indication.
この拡張機能との逆方向の互換性は、この拡張機能なしで行われるようにRSVPが動作するようになり、悪化することはありません。この拡張機能に関与する2つのルーターは、混雑したインターフェイスを備えたルーターと、削減の表示をどうするかを決定する最も遠い下流ルーターです。
In the case of the router that experiences congestion or otherwise needs to reduce the bandwidth of an existing reservation:
渋滞を経験するルーターの場合、または既存の予約の帯域幅を減らす必要があります。
- If that router supports this extension:
- そのルーターがこの拡張機能をサポートしている場合：
#1 - it generates the ResvErr message with the error code indicating the reduction in bandwidth.
＃1-帯域幅の減少を示すエラーコードを使用してRESVERRメッセージを生成します。
#2 - it does not generate the ResvTear message.
＃2- resvtearメッセージは生成されません。
- If that router does not support this extension, it generates both ResvErr and ResvTear messages according to [1].
- そのルーターがこの拡張機能をサポートしていない場合、[1]に従ってResverrとResvTearメッセージの両方を生成します。
In the case of the router at the extreme downstream of a reservation that receives the ResvErr message with the reduction indication:
削減兆候を伴うRESVERRメッセージを受信する予約の極端な下流のルーターの場合：
- If that router does support this extension:
- そのルーターがこの拡張機能をサポートしている場合：
#1 - it processes this error message and applies whatever local policy it is configured to do to determine how to reduce the bandwidth of this designated flow.
＃1-このエラーメッセージを処理し、この指定されたフローの帯域幅を減らす方法を決定するために構成されているローカルポリシーを適用します。
- If the router does not support this extension:
- ルーターがこの拡張機能をサポートしていない場合：
#1 - it processes the ResvErr message according to [1] and all extensions it is able to understand, but not this extension from this document.
＃1- [1]および理解できるすべての拡張機能に従ってResverrメッセージを処理しますが、このドキュメントからのこの拡張機能は処理しません。
Thus, this extension does not cause ill effects within RSVP if one or more routers support this extension, and one or more routers do not support this extension.
したがって、1つ以上のルーターがこの拡張機能をサポートしている場合、この拡張はRSVP内で悪影響を引き起こしません。1つ以上のルーターがこの拡張機能をサポートしていません。
This document does not lessen the overall security of RSVP or of reservation flows through an aggregate.
このドキュメントは、RSVPの全体的なセキュリティや、総計を介した予約フローを軽減するものではありません。
If this specification is implemented poorly - which is never intended, but is a consideration - the following issues may arise:
この仕様が不十分に実装されていない場合 - これは決して意図されていませんが、考慮事項です - 次の問題が発生する可能性があります。
1) If the ResvTear messages are transmitted initially (at the same time as the ResvErr messages indicating a reduction in bandwidth is necessary), all upstream routers will tear down the entire reservation. This will free up the total amount of bandwidth of this reservation inadvertently. This may cause the re-establishment of an otherwise good reservation to fail. This has the most severe affects on an aggregate that has many individual flows that would have remained operational.
1) resvtearメッセージが最初に送信される場合（帯域幅の減少が必要であることを示すRESVERRメッセージと同時に）、すべての上流のルーターは予約全体を取り壊します。これにより、この予約の帯域幅の総量が不注意に解放されます。これにより、それ以外の場合は適切な予約が失敗する可能性があります。これは、運用を維持し続けるであろう多くの個別のフローを持つ骨材に最も深刻な影響を及ぼします。
2) Just as RSVP has the vulnerability of premature termination of valid reservations by rogue flows without authentication [12, 13], this mechanism will have the same vulnerability. Usage of RSVP authentication mechanisms is encouraged.
2) RSVPが認証なしで不正な流れによる有効な予約の早期終了の脆弱性を持っているように[12、13]、このメカニズムは同じ脆弱性を持ちます。RSVP認証メカニズムの使用が推奨されます。
The IANA has assigned the following from RFC 4495 (i.e., this document):
IANAは、RFC 4495（つまり、このドキュメント）から以下を割り当てました。
The following error code has been defined in the ERROR_SPEC object for partial reservation failure under "Errcode = 2 (Policy Control Failure)":
次のエラーコードは、「errcode = 2（ポリシー制御障害）」の下で部分的な予約障害のためにerror_specオブジェクトで定義されています。
ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)
errsubcode = 102（err_partial_preempt）
The behavior of this ErrSubCode is defined in this document.
このerrsubCodeの動作は、このドキュメントで定義されています。
The authors would like to thank Fred Baker for contributing text and guidance in this effort and to Roger Levesque and Francois Le Faucheur for helpful comments.
著者は、この努力でテキストとガイダンスを提供してくれたフレッド・ベイカーに感謝し、ロジャー・レベスクとフランソワ・ル・ファウチュールに有益なコメントをしたいと思います。
[1] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[1] Braden、R.、ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[2] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[2] Baker、F.、Iturralde、C.、Le Faucheur、F。、およびB. Davie、「IPv4およびIPv6予約のRSVPの集約」、RFC 3175、2001年9月。
[3] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[3] Herzog、S。、「シグナル付き先制優先政策要素」、RFC 3181、2001年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[5] Herzog、S。、「ポリシー管理のためのRSVP拡張」、RFC 2750、2000年1月。
[6] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[6] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F。、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、RFC 2961、2001年4月。
[7] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[7] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[8] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[8] Berger、L。およびT. O'Malley、「IPSECデータフローのRSVP拡張機能」、RFC 2207、1997年9月。
[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[9] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[10] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[11] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate RSVP Reservations", Work in Progress, October 2005.
[11] Le Faucheur、F.、Davie、B.、Bose、P.、Christou、C。、およびM. Davenport、「一般的な集計RSVP予約」、2005年10月、進行中の作業。
[12] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[12] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[13] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[13] Braden、R。およびL. Zhang、「RSVP暗号認証 - 更新されたメッセージタイプ値」、RFC 3097、2001年4月。
Here is a concise explanation of roughly how RSVP behaves with the solution to the problems presented in Sections 2 and 3 of this document. There is no normative text in this appendix.
このドキュメントのセクション2および3に示されている問題の解決策と、RSVPがどのように動作するかについての簡潔な説明を以下に示します。この付録には規範的なテキストはありません。
Here is a duplicate of Figure 2 from section 3 of the document body (to bring it closer to the detailed description of the solution).
ドキュメント本体のセクション3の図2の複製を次に示します（ソリューションの詳細な説明に近づけるため）。
Aggregator of X Deaggregator of X
| |
V V
+------+ +------+ +------+ +------+
Flow 1-->| | | | | | | |-->Flow 1
Flow 2-->| | | | | | | |-->Flow 2
Flow 3-->| |==>| | | |==>| |-->Flow 3
Flow 4-->| | ^ | | | | ^ | |-->Flow 4
Flow 5-->| | | | | | | | | |-->Flow 5
Flow 9-->| R1 | | | R2 | | R3 | | | R4 |-->Flow 9
+------+ | +------+ +------+ | +------+
| || || |
Aggregate X--->|| Aggregate X ||<--Aggregate X
|| | ||
+--------------+ | +--------------+
| |Int 7 | | |Int 1 | |
| +----- | V |------+ |
| R10 |Int 8 |===========>|Int 2 | R11 |
| | |:::::::::::>| | |
| +----- | ^ |------+ |
| |Int 9 | | |Int 3 | |
+--------------+ | +--------------+
.. | ..
Aggregate Y--->.. Aggregate Y ..<---Aggregate Y
| .. .. |
+------+ | +------+ +------+ | +------+
Flow A-->| | | | | | | | | |-->Flow A
Flow B-->| | V | | | | V | |-->Flow B
Flow C-->| |::>| | | |::>| |-->Flow C
Flow D-->| | | | | | | |-->Flow D
Flow E-->| R5 | | R6 | | R7 | | R8 |-->Flow E
+------+ +------+ +------+ +------+
^ ^
| |
Aggregator of Y Deaggregator of Y
Duplicate of Figure 2. Generic RSVP Aggregate Topology
図2の複製。一般的なRSVP集計トポロジ
Looking at Figure 2, aggregate X (with five 80 kbps flows) traverses:
図2を見ると、集約X（5つの80 kbpsフローを含む）トラバース：
R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4
And aggregate Y (with five 80 kbps flows) traverses:
Y（5つの80 kbpsフローを含む）agregate yは横断します。
R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
Both aggregates are 400 kbps. This totals 800 kbps at Int 7 in R10, which is the maximum bandwidth that RSVP has access to at this interface. Signaling messages still traverse the interface without problem. Aggregate X is at a higher relative priority than aggregate Y. Local policy in this example is for higher relative priority flows to preempt lower-priority flows during times of congestion. The following points describe the flow when aggregate A is increased to include Flow 9.
両方の凝集体は400 kbpsです。これは、R10のINT 7で合計800 kbpsです。これは、RSVPがこのインターフェイスでアクセスできる最大帯域幅です。シグナリングメッセージは、問題なくインターフェイスを横断します。集合体Xは、集合体Yよりも相対的な優先度が高い。この例のローカルポリシーは、混雑の時点でより低い優先順位の流れを先取りするための相対的な優先度の高いフローのためのものである。次のポイントは、凝集体Aが増加してフロー9を含む場合の流れを説明します。
o When Flow 9 (at 80 kbps) is added to aggregate X, R1 will initiate the PATH message towards the destination endpoint of the flow. This hop-by-hop message will take it through R2, R10, R11, R3, and R4, which is the aggregate X path (that was built per [2] from the aggregate's initial setup) to the endpoint node.
o 流れ9（80 kbpsで）が集合体Xに追加されると、R1は流れの宛先エンドポイントに向かってパスメッセージを開始します。このホップバイホップメッセージは、R2、R10、R11、R3、およびR4を介して、アグリゲートXパス（集計の初期セットアップから[2]ごとに構築された）であり、エンドポイントノードになります。
o In response, R4 will generate the RESV (reservation) message (defined behavior per [1]). This RESV from the deaggregator indicates an increase bandwidth sufficient to accommodate the existing 5 flows (1, 2, 3, 4, and 5) and the new flow (9), as stated in [2].
o これに応じて、R4はRESV（予約）メッセージ（[1]ごとに定義された動作）を生成します。DeaggregatorからのこのRESVは、[2]に記載されているように、既存の5フロー（1、2、3、4、および5）と新しいフロー（9）に対応するのに十分な帯域幅の増加を示します。
o As mentioned before, in this example, Int 8 in R10 can only accommodate 800 kbps, and aggregates X and Y have each already established 400 kbps flows comprised of five 80 kbps individual flows. Therefore, R10 (the interface that detects a congestion event in this example) must make a decision about this new congestion generating condition in regard to the RESV message received at Int 8.
o 前述のように、この例では、R10のINT 8は800 kbpsしか収容できず、集合体XとYはそれぞれ5つの80 kbpsの個々のフローで構成される400 kbpsフローを確立しています。したがって、R10（この例では輻輳イベントを検出するインターフェイス）は、INT 8で受信したRESVメッセージに関して、この新しい輻輳生成条件について決定する必要があります。
o Local policy in this scenario is to preempt lower-priority reservations to place higher-priority reservations. This would normally cause all of aggregate Y to be preempted just to accommodate aggregate X's request for an additional 80 kbps.
o このシナリオのローカルポリシーは、優先順位の留保を先取りして、より優先順位の留保を行うことです。これにより、通常、集計Xの追加の80 kbpsのリクエストに対応するために、すべての骨材Yが先制されます。
o This document defines how aggregate Y is not completely preempted, but reduced in bandwidth by 80 kbps. This is contained in the ResvErr message that R10 generates (downstream) towards R11, R7, and R8. See section 5 for the details of the error message.
o このドキュメントでは、Yが完全に先取りされるのではなく、帯域幅が80 kbps減少する方法を定義しています。これは、R10がR11、R7、およびR8に向かって（下流）生成するRESVERRメッセージに含まれています。エラーメッセージの詳細については、セクション5を参照してください。
o Normal operation of RSVP is to have the router that generates a ResvErr message downstream to also generate a ResvTear message upstream (in the opposite direction, i.e., towards R5). The ResvTear message terminates an individual flow or aggregate flow. This document calls for that message not to be sent on any partial failure of reservation.
o RSVPの通常の動作は、下流のRESVERRメッセージを生成するルーターを使用して、上流（反対方向、つまりR5に向かって）上流のメッセージを生成することです。resvtearメッセージは、個々のフローまたは集約フローを終了します。このドキュメントでは、予約の部分的な障害で送信されないようにそのメッセージを求めています。
o R8 is the deaggregator of aggregate Y. The deaggregator controls all the parameters of an aggregate reservation. This will be the node that reduces the necessary bandwidth of the aggregate as a response to the reception of an ResvErr message (from R10) indicating such an action is called for. In this example, bandwidth reduction is accomplished by preempting an individual flow within the aggregate (perhaps picking on Flow D for individual preemption by generating a ResvErr downstream on that individual flow).
o R8は集合体Yのディーグレジャーターです。Deaggregatorは、集合体予約のすべてのパラメーターを制御します。これは、そのようなアクションが求められていることを示すRESVERRメッセージの受信（R10から）の応答として、集約の必要な帯域幅を減らすノードとなります。この例では、帯域幅の削減は、骨材内の個々のフローを先制することによって達成されます（おそらく、個々のフローで下流のレストバーを生成することにより、個々の先制のフローDを選択します）。
o At the same time, a ResvTear message is transmitted upstream on that individual flow (Flow D) by R8. This will not affect the aggregate directly, but is an indication to the routers (and the source end-system) which individual flow is to be preempted.
o 同時に、r8 by R8にresvtearメッセージがその個々のフロー（フローd）で上流に送信されます。これは集合体に直接影響するわけではありませんが、個々の流れが先制するルーター（およびソースエンドシステム）への兆候です。
o Once R8 preempts whichever individual flow (or 'bandwidth' at the aggregate ingress), it transmits a new RESV message for that aggregate (Y), not for a new aggregate. This RESV from the deaggregator indicates a decrease in bandwidth sufficient to accommodate the remaining 4 flows (A, B, C, and E), which is now 320 kbps (in this example).
o R8が個々のフロー（または集約侵入で「帯域幅」）を先取りすると、新しい集計ではなく、その集合体（y）に対して新しいRESVメッセージを送信します。DeaggregatorからのこのRESVは、残りの4つのフロー（A、B、C、およびE）を収容するのに十分な帯域幅の減少を示しています。これは現在320 kbpsです（この例）。
o This RESV message travels the entire path of the reservation, resetting all routers to this new aggregate bandwidth value. This should be what is necessary to prevent a ResvTear message from being generated by R10 towards R6 and R5.
o このRESVメッセージは、予約のパス全体を移動し、すべてのルーターをこの新しい集計帯域幅値にリセットします。これは、R10によってR6とR5に向かってRESVTEARメッセージが生成されないようにするために必要なものである必要があります。
R5 will not know through this RESV message which individual flow was preempted. If in this example, R8 was given more bandwidth to keep, it might have transmitted a bandwidth reduction ResvErr indication towards the end-system of Flow D. In that case, a voice signaling protocol (such as SIP) could have attempted a renegotiation of that individual flow to a reduced bandwidth (say, but changing the voice codec from G.711 to G. 729). This could have saved Flow D from preemption.
R5は、このRESVメッセージを介して、どの個々のフローが先制されたかを知りません。この例では、R8に維持するためにより多くの帯域幅が与えられた場合、フローDの最終システムに向けて帯域幅削減の表示が送信された可能性があります。その個々の流れは帯域幅の減少に流れます（たとえば、G.711からG. 729に音声コーデックを変更します）。これにより、フローDを先制から節約できた可能性があります。
Authors' Addresses
著者のアドレス
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェームズM.ポークシスコシステム2200イースト大統領ジョージブッシュターンパイクリチャードソン、テキサス75082 USA
EMail: jmpolk@cisco.com
Subha Dhesikan Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Subha Dhesikan Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 USA
EMail: sdhesika@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。