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
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).
著作権（C）インターネット協会（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.
この文書では、[1]既存の予約は、その予約の帯域幅の一部が他の目的のために必要とされるときダウンその予約を引き裂くの代わりに割り当てられた帯域幅を小さくすることができるようにするためにリソース予約プロトコル（RSVP）への拡張を提案しています。いくつかの例は、このメカニズムが利用可能な存在します。
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にこの指示は、[9]、低帯域コーデックのための信号と、予約を保持するために、セッション開始プロトコル（SIP）のような別のプロトコルを使用して、エンドポイントを導き得ます。
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]明らかに、すべての個々のフローを終了しませんが、このイベントは、パケットが集約予約の再確立中に破棄されます。この文書では、必要最小限の帯域幅は、優先度の低い凝集予約から取り去られ、全体の予約がプリエンプトされていない唯一の方法を記載しています。これはのみの集計を構成するマイクロフローの一部が影響を受けているという利点があります。この拡張機能がなければ、すべての個々のフローが影響を受けているとデアグリゲータは、帯域幅が減少して予約要求を試行する必要があります。
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を利用したRSVPのトンネル[8]また、予約が一定量（以下）に低減されなければならないという指示を必要とします。 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を介して予約（S）のために利用可能な帯域幅のすべての下ことはないことに注意してください該当するポリシーが使用されてきました。リアルタイムトラフィックのポリシーは定期的なルーティングおよび非弾性アプリケーションのための容量を確保し、音声、ビデオ、およびその他のリアルタイムアプリケーションとを区別することができます。
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.
第3節では、集約予約フロー問題空間を議論しながら、第2節では、個々の予約フローの問題を論じています。第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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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）を用いて最初に2つのルータ（R1およびR2）を示します。フローはこの例ではR1からR2を介してのInt 2に転送され、米国は、フロー1及びフロー2はそれぞれ（例えば無音抑制を持つコーデックG.711のような）帯域幅の80個の単位を必要とするものとします。
Let us also say that the RSVP bandwidth limit for Int 2 of R1 is 100 units.
私たちはまた、R1の2のIntのための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）1は、予約を確立する、と
2) one to defend the reservation.
2）1予約を守ります。
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.
この例では、フロー1及びフロー2「確立」と、それぞれ300および100の「防御」の優先度を有します。フロー2は、フロー1は、その防御優先のために持っているよりも高い確立の優先順位を持つことになります。これは、フロー2が通知されたときにことを意味し、何の帯域幅が界面で利用できない場合、フロー1は、予約の優先順位は常にエンドツーあるフロー2の優先度の高い要求を支持して帯域幅を放棄する必要があります終わりではなく、輸送中の任意のルータによって変更。
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)
この仕様の恩恵がなければ、フロー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.
- フロー1まで、複数の試行に起因する非効率性に等しいか、または利用可能なものよりも低い帯域幅を要求することができます。フロー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）からなります。当初、2つの骨材（XとY）との集約あたり5つのフロー（流れ9は、我々は、この文書に取り組んでいる問題を起こすために導入される）、があるでしょう。図1は、集約X 5を通って流れ、これら2つの凝集体（この例では）すべての利用可能な容量を利用するのルータインターフェイスを横断する集計YにEを通って流れます。
RSVP aggregation (per [2]) is no different from an individual reservation with respect to being unidirectional.
（[2]あたりの）RSVP集約は、一方向であることに対して個体予約と変わりません。
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
R 1 => 2 => = R 10> R 11 => = R 3> R 4
where aggregate X starts in R1, and deaggregates in R4.
凝集XはR1で開始し、そしてR4でdeaggregatesあります。
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のパスは次のとおりです。
R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
where aggregate Y starts in R5, and deaggregates in R8.
集計Yは、R5で開始し、R8でdeaggregatesあります。
Flows A, B, C, D, and E communicate through aggregate B.
、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.
両方の凝集体は、一方の脚又は物理リンクを共有する：R10のint型8、リソースの競合が存在していてもよい：R10とR11との間に、このようにして彼らは、一つの発信インタフェースを共有します。そのリンクは、800 kbpsののRSVP能力を持っています。 SIPのような任意のセッションシグナリングプロトコルであるように、RSVPシグナリング（メッセージ）は、この例では800 kbpsの外側にあります。
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をフロー）。この議論のために、私たちは各フローは音声通話を表し、（例えば無音抑制を持つコーデックG.711のような）、80キロバイトを必要とすると仮定する。集約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.
凝集Yは、図2に、フロー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
流れ9が集約Xに追加されると、これはR10上のInt 8より80 kbpsの多くを占有する利用可能な（800K容量対880k提供荷重）[1]及び[2]の全体の集合体を拒否するRSVPにおける動作を作成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:
集計Xは、高い優先度を持っているので、そのすべての個人が流れます。この文書はその要件とソリューションのための呼び出しを焦点を当てているこのような状況があります。のみ80 kbpsのは、別の（優先度の高い）凝集体を収容するために必要とされる凝集体Yの影響を受けるすべてのルータに合図するためにいくつかの手段がなければなりません。代わりに、失敗可能性のこの減少を達成ソリューション：
- reduce significant packet loss of all flows within aggregate Y
- 集約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.
（RSVPへのいかなる変更なし）図2の凝集の再確立時には、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.
＃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.
＃2 REQ - 特定の予約（個々または集合体）の帯域幅が減少すること（輻輳インターフェースを備えたルータで発生）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.
＃3 REQ - 同じエラー・メッセージ内の既存の予約内で利用されるために利用可能である帯域幅の新たな最大量が、もはやを指示する能力を持たなければなりません。
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.
＃4 REQ - 再送された削減兆候がさらに予約の帯域幅を縮小した場合を生成してはなりません。指定された予約のための帯域幅内の任意の追加の減少は、新しいメッセージに合図しなければなりません。
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メッセージは信頼できないと迷子になることができます。この仕様は、ネットワーク内の任意のエラーを配合べきではありません。削減のメッセージが失われた場合は、別の1が送信される必要があります。受信機は、いくつかの量によって予約の帯域幅を減らすために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オブジェクトが予約されているフロースペックを示します。このフロースペック中の帯域幅指示は、元の予約要求未満であるべきです。これは、セクション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メッセージについてのコメント：この文書は、ResvErrメッセージが[6]にメカニズムを実装することによって確実なものとすることをお勧めします。
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メッセージがダウンストリーム送信されたときに上流の送信すべきたResvTearメッセージを必要とする（あたり[1]）。このた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.
付録では、付録のこのたResvTear伝達行動の言及があり、セクション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:
プリエンプションに起因して発生するResvErrメッセージはERROR_SPECオブジェクトならびにPREEMPTION_PRIオブジェクトを含みます。 ERROR_SPECオブジェクトのフォーマットは、[1]で定義されています。プリエンプションためERROR_SPECオブジェクトにリストされたエラーコードを以下のように[5]現在：
Errcode = 2 (Policy Control Failure) and
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.
プリエンプション-PRIオブジェクトのエラーコードもあります。このエラーコードは認め流れが[3]が横取りされたことを示すために、1の値をとります。 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]。部分的な障害が発生した場合に、エラーフロー記述子に含まれるフロースペックは、先取りシステムは次のRESVメッセージで受け入れることができる最高の平均およびピーク速度を示しています。デアグリゲータは、コーデックを変更予約、またはいくつかの他の機構を滴下したか否か、より少ないかまたはそれに等しい数にその予約を低減しなければなりません。
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メッセージに含まれるフロースペックは、現在割り当てられている帯域幅を示すために使用されるであろう。
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のPATHと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:
部分的な障害が凝集シナリオで発生した場合、デアグリゲーターは、集約のパスにおけるルータから縮小指示で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).
その（デアグリゲータ）ルータが部分的に失敗することがある1つの以上の個々の流れ（S）と判断した場合、O、それは、それらの個々の流れ（S）に減少した帯域幅の指示と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.
その（デアグリゲータ）ルータが一つの個別流が凝集ResvErrを満たすために先取りされるべきであると判断した場合、O、それが影響を受けるフローを判定する。そのルータは、[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.
その（デアグリゲータ）ルータが複数の個々のフローが集約ResvErrを満たすために先取りされるべきであると判断した場合、O、それが影響を受ける流れる選択します。そのルータは、[3]各個別流へに従って下流新しいResvErrメッセージを送信します。ルータは、同じ個々のフローのための上流たResvTearメッセージを送信します。個々の流れのこれらたResvTearメッセージは、集計を切断しないでください。唯一の個々のフローが影響を受けます。
In all cases, the deaggregator lowers the bandwidth requested in the Aggregate Resv message to reflect the change.
すべての場合において、デアグリゲータは、変更を反映するために集計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.
これ集約内の流れの特定のフロー又は一連の帯域幅低減またはプリエンプションのためにデアグリゲーターによって取得され、この文書の範囲外です。
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.
（[8]あたり）RFC 2207は、RSVP予約がIPSecのデータフローで機能する方法を指定します。 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.
たResvTearメッセージは（ResvErrメッセージと同時に、帯域幅の減少を指示する必要がある）最初に送信される場合は1）、すべてのアップストリームルータは、全予約を切断します。これは、不注意、この予約の帯域幅の総量を解放します。これは、そうでなければ良いの予約の再確立が失敗する可能性があります。これは、最も厳しいが動作推移していた多くの個々のフローを持つ集計に影響を与えています。
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.
著者は、有益なコメントのためにこの努力にとロジャー・レヴェックとフランソワ・ルFaucheurにテキストや指導に貢献するためにフレッド・ベイカーに感謝したいと思います。
[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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[2] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[2]ベーカー、F.、Iturralde、C.、ルFaucheur、F.、およびB.デイビー、 "IPv4とIPv6の予約のためのRSVPの集約"、RFC 3175、2001年9月。
[3] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[3]ヘルツォーク、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[5]ヘルツォーク、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]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[7] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[7] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[8] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[8]バーガー、L.とT.オマリー、 "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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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] "IPに明示的輻輳通知の添加（ECN）" ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、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]ルFaucheur、F.、デイビー、B.、ボーズ、P.、Christouの、C.、およびM.ダヴェンポート、 "汎用集約RSVP予約"、進歩、2005年10月に働いています。
[12] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[12]ベーカー、F.、リンデル、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]ブレーデン、R.、およびL.チャン、 "RSVP暗号化認証 - 更新メッセージタイプ値"、RFC 3097、2001年4月。
Appendix A. Walking through the Solution
ソリューションを歩い付録A.
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.
ここではRSVPはセクション2と、この文書の3に提示さの問題を解決してどのように振る舞うかおおよその簡潔な説明があります。この付録には規範的なテキストはありません。
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
== R1> R2 ==> == R 10> R 11 ==> R3 ==> R4
And aggregate Y (with five 80 kbps flows) traverses:
そして、Y（5 80 kbpsのでフロー）を集計横断：
R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
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のです。これは、RSVPは、この界面でのアクセスを有する最大帯域であるR10のint 7で800 kbpsのは、合計します。シグナリングメッセージはまだ問題なくインターフェースを通過します。集計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.
（80 Kbpsで）流れ9はXを集約するために添加される場合、O、R1は、フローの宛先エンドポイントに向けてPATHメッセージを開始します。このホップバイホップメッセージは、エンドポイントノードにR2、R10、R11、R3、及び（それは凝集の初期設定から[2]あたりに構築された）集約XパスでR4を介してそれを取るであろう。
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]あたりの定義された動作）を生成します。 〔2〕に記載のデアグリゲーターからこのRESVは、既存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このシナリオでのローカルポリシーは、優先度の高い予約を配置するために、優先度の低い予約を先取りすることです。これは通常、集約Yのすべてがちょうど追加80 kbpsのための集約Xの要求に対応するために先取りされる原因になります。
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の、帯域幅が縮小されていないどのように集計定義します。これはR11、R7、及びR8に向かってR10は（ダウンストリーム）を生成する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の正常動作も上流側（反対方向に、即ち、R5に向かって）たResvTearメッセージを生成するために、下流ResvErrメッセージを生成するルータを有することです。た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のデアグリゲーターです。このような動作が要求される指示（R10）からResvErrメッセージの受信に対する応答として集約の必要な帯域幅を減少させるノードとなります。この例では、帯域幅の減少は、凝集体（おそらく、個々の流れに下流ResvErrを生成することによって、個々のプリエンプションのためのフロー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同時にたResvTearメッセージは、R8によりその個々の流れ（フロー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).
R8が、いずれの個々の流れ（または集計入口で「帯域幅」）を差し替えたらO、そうではない新たな集約のために、その集合体（Y）のための新しいRESVメッセージを送信します。デアグリゲーターからこのRESVは現在（この例では）320 kbpsの残り4つの流れ（A、B、C、およびE）を収容するのに十分な帯域幅の減少を示しています。
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メッセージは、この新たな総帯域幅値にすべてのルータをリセットし、予約のパス全体を移動します。これはR6及びR5向かってR10によって生成された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.のエンドシステムに向かって帯域幅削減ResvErr指示を送信している可能性があり、音声シグナリングプロトコル（SIPなど）の再交渉を試みている可能性がその個人減少した帯域幅への流れ（と言うが、G. 729にG.711からの音声コーデックを変更します）。これは、プリエンプションからの流れ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
メールアドレス：jmpolk@cisco.com
Subha Dhesikan Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
サブハDhesikanシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134 USA
EMail: sdhesika@cisco.com
メールアドレス：sdhesika@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。