RFC4495 日本語訳
4495 A Resource Reservation Protocol (RSVP) Extension for theReduction of Bandwidth of a Reservation Flow. J. Polk, S. Dhesikan. May 2006. (Format: TXT=44983 bytes) (Updates RFC2205) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Polk Request for Comments: 4495 S. Dhesikan Updates: 2205 Cisco Systems Category: Standards Track May 2006
コメントを求めるワーキンググループJ.ポークの要求をネットワークでつないでください: 4495秒間Dhesikanアップデート: 2205年のシスコシステムズカテゴリ: 標準化過程2006年5月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントは、既存の予約に割り当てられた保証された帯域幅を減少させるためにResource予約プロトコル(RSVPv1)に拡大を提案します。 個々の予約、集合予約、または他の形式のRSVPトンネルに影響するのにこのメカニズムを使用できます。 この仕様はRFC2205の拡大です。
Polk & Dhesikan Standards Track [Page 1] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[1ページ]。
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
1. 序論…2 1.1. このドキュメントで中古のコンベンション…4 2. 個々の予約減少シナリオ…4 3. RSVP集合概観…6 3.1. RSVP集合減少シナリオ…8 4. 予約減少のための要件…9 5. RSVP帯域幅削減対策…10 5.1. 部分的な先取りエラーコード…11 5.2. 誤り流れ記述子…11 5.3. 個々の予約流動減少…11 5.4. 個人の集合減少は流れます…12 5.5. IPsecにかかわるRSVP流動減少がトンネルを堀ります…12 5.6. 倍数の減少はすぐに、流れます…13 6. 遅れている互換性…13 7. セキュリティ問題…14 8. IANA問題…15 9. 承認…15 10. 参照…15 10.1. 標準の参照…15 10.2. 有益な参照…16 ソリューションを通って歩く付録A.…17
1. Introduction
1. 序論
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.
このドキュメントは、その予約のいくらかの帯域幅が他の目的に必要であるときにその予約を取りこわすことの代わりに既存の予約が割り当てられた帯域幅で抑えられるのを許容するためにResource予約プロトコル(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のこの指示は終点を導くかもしれません、下側の帯域幅コーデックのために合図して、予約を保有するのにSession Initiationプロトコル(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
RSVP集合[2]で、異なった優先順位に従った2回の集合流れが同じルータインタフェースを横断するかもしれません。 新しい予約を確立するか、または既存の予約を増加させるように頼まれて、そのルータインタフェースが帯域幅容量に達して、その時なら
Polk & Dhesikan Standards Track [Page 2] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[2ページ]。
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.
ルータは選択をしなければなりません: 新しい要求を否定するか(すべてのリソースが利用されたので)、または既存の低優先度の予約を先取りして、新しいか拡張している予約に場所を開けてください。
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]は明確にすべての個々の流れを終えるというわけではありませんが、この出来事で、集合予約再建の間パケットを捨てるでしょう。 このドキュメントは低優先度の集められた予約から最小の必要な帯域幅だけを持ち去って、全体の予約を先取りしない方法を説明します。 これには、いくらかのmicroflowsだけが集合を作って、影響を受ける利点があります。 この拡大がなければ、すべての個々の流れが影響を受けます、そして、「反-アグリゲータ」は減少している帯域幅に伴う予約の要請を試みなければならないでしょう。
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]で定義されています。([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.
明白なCongestion Notification(電子証券取引ネットワーク)[10]は伝える終点がトランスミッションを抑えなければならないという指示です。 それは減少がいくらであるべきであるかで終点を言うことができるくらいの指示を提供しません。 したがって、帯域幅利用を利用可能な限界より下であるまで落とすことができる前にアプリケーションは複数の回を試みなければならないかもしれません。 したがって、私たちは、電子証券取引ネットワークが非常に弾性のアプリケーションの役に立つと考えますが、それは帯域幅の有用性のしるしがコーデック選択の役に立つ弾力性のないアプリケーションの目的のために十分ではありません。
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の機能性を変更するかに関する立ち稽古の例を集合シナリオに提供します。
Polk & Dhesikan Standards Track [Page 3] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[3ページ]。
This document updates RFC 2205 [1], as this mechanism affects the behaviors of the ResvErr and ResvTear indications defined in that document.
このドキュメントはRFC2205[1]をアップデートします、このメカニズムが指摘がそのドキュメントで定義したResvErrとResvTearの振舞いに影響するとき。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[4]で説明されるように本書では解釈されることであるべきですか?
2. Individual Reservation Reduction Scenario
2. 個々の予約減少シナリオ
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 | |
+------------+ +------------+
+------------+ +------------+ | |Int1| |Int7| | 流れ1===>| +----- | |------+ | 流れ1===>| R1|Int2|===========>|Int8| R2| | | |:::::::::::>|、|、| 流れ2:、:、:>| +----- | |------+ | 流れ2:、:、:>||Int3| |Int9| | +------------+ +------------+
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は一方向だけへの予約設立プロトコルです。 この分裂経路哲学は一方向への発送された1台の装置からもう片方までの経路が反対の方向への同じ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)について表現します。 Int2を通してR1からR2まで流れを進めます。 この例のために、Flow1とFlow2がそれぞれ、80の帯域幅(沈黙抑圧のないコーデックG.711などの)を必要とすると言いましょう。
Polk & Dhesikan Standards Track [Page 4] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[4ページ]。
Let us also say that the RSVP bandwidth limit for Int 2 of R1 is 100 units.
また、R1のInt2のための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.
この例では、Flow1とFlow2はそれぞれ300と100の'設立'と'防御している'優先を持っています。 流れ2には、Flow1が防御している優先権のために持っているより高い設立優先度があるでしょう。 これは、Flow2が合図されるとき、どんな帯域幅もインタフェースで利用可能でないなら、Flow1がFlow2の、より高い優先度要求を支持して帯域幅を放棄しなければならないことを意味します。 予約に割り当てられたプライオリティは、終わるためにいつも終わって、トランジットにおけるどんなルータによっても変更されません。
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)
この仕様の利益がなければ、Flow1は先取りされるでしょう。 この仕様で、予約が(インタフェースのFlow2の80ユニットを引いて最大の100単位)を上がり続けるのが20個のユニットがまだ利用可能であることを示すResvErrメッセージに可能になります。 Flow1のために、ノード(ルータかエンドシステム)を開始する予約は流れのための存在と利用可能な帯域幅の中に許容できるパラメタのために再交渉する(呼び出しシグナリングで)機会を持っています。(例えば、それは、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.
- パケット損失を抑えました。(Flow1が、下側の帯域幅の予約を回復させるのを試みるとき、それは、結果として生じます)。
- 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.
- Flow1がことより等しいか、または低い状態で帯域幅を要求できるまで複数の試みで引き起こされた非能率は利用可能です。 多くが利用可能なことより少ない状態でFlow1が設立されるなら、それは利用可能な帯域幅の効率の悪い使用に通じます。
Polk & Dhesikan Standards Track [Page 5] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[5ページ]。
3. RSVP Aggregation Overview
3. RSVP集合概観
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による集合(私たちが本書では訴えているその問題を引き起こすために流れ9を導入する)の集合(XとY)あたり5回の流れがあるでしょう。 集合Xにおける流れ1〜5と集合Y.These2集合のFlows AからEはすべての有効な容量(この例の)を利用する1つのルータインタフェースを越えるでしょう。
RSVP aggregation (per [2]) is no different from an individual reservation with respect to being unidirectional.
RSVP集合、(1[2])あたり単方向に関して個々の予約と異なったノーはそうですか?
Polk & Dhesikan Standards Track [Page 6] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[6ページ]。
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
XのX Deaggregatorのアグリゲータ| | +に対するV------+ +------+ +------+ +------+ 流れ1-->|、|、|、|、|、|、| |-->流動1流動2-->|、|、|、|、|、|、| |-->流動2流動3-->| |==>|、|、| |==>| |-->流動3流動4-->|、| ^ | | | | ^ | |-->流動4流動5-->|、|、|、|、|、|、|、|、| |-->流動5流動9| R1| | | R2| | R3| | | R4| 流れ9+------+ | +------+ +------+ | +------+ | || || | Xに集めてください-->|、| 集合X| | <--集合X|| | || +--------------+ | +--------------+ | |Int7| | |Int1| | | +----- | V|------+ | | R10|Int8|===========>|Int2| R11| | | |:::::::::::>|、|、|、| +----- | ^ |------+ | | |Int9| | |Int3| | +--------------+ | +--------------+ .. | .. 集合Y--->。 Yに集めてください。<--集合Y| .. .. | +------+ | +------+ +------+ | +------+ 流れA-->|、|、|、|、|、|、|、|、| |-->流れA流動B-->|、| V| | | | V| |-->流れB流動C-->| |::>|、|、| |::>| |-->流れC流動D-->|、|、|、|、|、|、| |-->流れD流動E-->| R5| | R6| | R7| | R8|-->流れE+------+ +------+ +------+ +------+ ^ ^ | | YのY Deaggregatorのアグリゲータ
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--すべての箱がルータです--両方の集合は同じ方向に示されます(右にいなくなります)。 反対の方向への対応する集合はダイヤグラムの簡単さのために示されません。
Polk & Dhesikan Standards Track [Page 7] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[7ページ]。
The path for aggregate X is:
集合Xのための経路は以下の通りです。
R1 => R2 => R10 => R11 => R3 => R4
>>>>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のための経路は以下の通りです。
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の「反-集合」で始まります。
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の間では、その結果、彼らは1つの外国行きのインタフェースを共有します: R10のInt8。そこでは、リソースの主張が存在するかもしれません。 そのリンクには、800キロビット毎秒のRSVP容量があります。 この例の800キロビット毎秒の外でRSVPシグナリング(メッセージ)がSIPのようなどんなセッションシグナリングプロトコルのようにもあります。
3.1. RSVP Aggregation Reduction Scenario
3.1. RSVP集合減少シナリオ
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)を示しています。 この集められた予約は5microflows(流れ1、2、3、4、および5)から成ります。 この議論のために、各流れが音声通話を表して、80kb(沈黙抑圧のないコーデックG.711などの)を必要とすると仮定しましょう。 集合X要求は400キロビット毎秒(80キロビット毎秒*5回の流れ)のためのものです。 それが上がるようにされる個々のmicroflowsから集合の優先権を得ます。 簡単な場合では、ただ一つの優先のすべての流れがただ一つの集合として束ねられます(ネットワークを通して同じ経路を横断しても、別の集合には別の優先順位があるでしょう)。 集合の優先権が引き出される他の方法があるかもしれませんが、この議論では、各集合が優先(保持と防御している優先権の両方)を含むことに注意するのは十分です。 この議論のための範囲の外に優先権を引き出す手段があります。
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でFlows A、B、C、D、およびEから成って、400キロビット毎秒(80キロビット毎秒*5回の流れ)を必要として、R5で始まって、R8を終わらせます。 これは、RSVP容量のすべての800キロビット毎秒を占領する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
Flow9が集合Xに追加されるとき、これはR10の上のInt8が利用可能な(880kは800k容量に従った負荷を提供した)[1]と[2]に全体の集合Yを否定するためにRSVPで振舞いを作成させるより80キロビット毎秒を占領するでしょう。
Polk & Dhesikan Standards Track [Page 8] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[8ページ]。
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キロビット毎秒だけが別の(より高い優先度)集合に対応するのに必要であると集合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.
図2(RSVPへの少しも変更のない)の集合の再建の間、R8は新しいRESVメッセージでどのくらいの帯域幅を求めるかで推測するでしょう。 どんなそれだけの帯域幅も利用可能でなかったのが、あまりに多くの帯域幅を要求できて、誤りを待たなければなりません。 それで、あまりに小さい帯域幅を要求して、その集合を受け入れるかもしれませんが、これは、必要としたよりさらに個々の流れが、集合の外で先取りされる必要を意味するでしょう、逆方向で非能率に通じて。
4. Requirements for Reservation Reduction
4. 予約減少のための要件
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つの予約を区別する能力を持たなければなりません。 集合の場合では、それは他の流れと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--同じエラーメッセージの中に新しい最大の量の利用可能な帯域幅が既存の予約の中で利用されて、より多くないのを示す能力を持たなければなりません。
Polk & Dhesikan Standards Track [Page 9] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[9ページ]。
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倍に従ってルータが帯域幅を減少させるのは、ありそうです。 これは間違うでしょう。
5. RSVP Bandwidth Reduction Solution
5. RSVP帯域幅削減対策
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)メッセージはちょうど現在、先取りでそれをするように発生します。 また、ERROR_SPEC物とPREEMPTION_PRI物は含まれています。 ほんのわずかな追加/変化が部分的な先取りを支持するResvErrメッセージに必要です。 新しい誤り部分符号は、必要であり、セクション5.1で定義されます。 ResvErrメッセージに含まれたERROR_SPEC物は予約されたflowspecを示します。 帯域幅指示、このflowspec SHOULDでは、オリジナルの予約の要請より少なくいてください。 これはセクション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]であったなら通信させるこのドキュメントRECOMMENDS。
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.
付録は、セクション2と3に提示された問題の総合的な解決を通って歩くために書かれています。 付録における、このResvTearトランスミッションの振舞いの言及があります。
Polk & Dhesikan Standards Track [Page 10] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[10ページ]。
5.1. Partial Preemption Error Code
5.1. 部分的な先取りエラーコード
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メッセージはPREEMPTION_PRI物と同様にERROR_SPEC物を含んでいます。 ERROR_SPEC物の書式は[1]で定義されます。 [5] 現在先取りのためにERROR_SPEC物に記載されているエラーコードは以下の通りです:
Errcode = 2 (Policy Control Failure) and
ErrSubCode = 5 (ERR_PREEMPT)
Errcodeは2(方針コントロール失敗)とErrSubCode=5と等しいです。(間違え、_が先取りする、)
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と等しいです。(間違え、部分的な_が先取りする_)
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の同じ誤り値はまた、部分的な先取りケースに使用されるかもしれません。
5.2. Error Flow Descriptor
5.2. 誤り流れ記述子
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メッセージで受け入れることができる最も高い平均とピークレートを示します。 「反-アグリゲータ」は、コーデックを変えるか否かに関係なく、よりそれに付番して、予約、またはある他のメカニズムを落としながら、aに予約を抑えなければなりません。
5.3. Individual Reservation Flow Reduction
5.3. 個々の予約流動減少
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 PATHとRESVメッセージを発行するでしょう。
Polk & Dhesikan Standards Track [Page 11] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[11ページ]。
5.4. Aggregation Reduction of Individual Flows
5.4. 個々の流れの集合減少
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).
o その(「反-アグリゲータ」)ルータが、部分的に失敗されるのに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 その(「反-アグリゲータ」)ルータが、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 その(「反-アグリゲータ」)ルータが、複数の個々の流れが集合ResvErrを満たすために先取りされることであることを決定するなら、それは、どの流れが影響を受けるかを選びます。 そのルータはそれぞれの個々の流れへの[3]に従って新しいResvErrメッセージを川下に送ります。 また、ルータは同じ個々の流れのために上流へResvTearメッセージを送ります。 個々の流れに関するこれらのResvTearメッセージは集合を取りこわしません。 個々の流れだけが影響を受けます。
In all cases, the deaggregator lowers the bandwidth requested in the Aggregate Resv message to reflect the change.
すべての場合では、「反-アグリゲータ」は変化を反映するAggregate 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.
このドキュメントの範囲の外に集合の中のどの特定の流れかシリーズの流れが「反-アグリゲータ」によって帯域幅削減か先取りに選ばれるかがあります。
5.5. RSVP Flow Reduction Involving IPsec Tunnels
5.5. IPsec TunnelsにかかわるRSVP流動減少
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])単位でRSVPの予約がIPsecデータフローでどう機能するかを指定します。 IPsec流動を起こすノードはコンピュータのようにエンドシステムであるかもしれませんか2台のエンドシステムの間の缶のルータです、または、それはすぐルータインタフェースに隣接してインライン大量の暗号化装置であるかもしれません。 [11]は直接この後のシナリオを記述します。
Polk & Dhesikan Standards Track [Page 12] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[12ページ]。
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.
個々の予約流動について言及するこの仕様の中でどこでも、帯域幅削減と先取りの同じ規則は適用されなければなりません。
5.6. Reduction of Multiple Flows at Once
5.6. 倍数の減少はすぐに、流れます。
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.
警告的な注意、帯域幅SHOULD NOT、同時に複数の予約の向こう側に減少してください、同じ減少出来事への反応で。 1回以上の流れで予約帯域幅削減の衝撃を知らないと必要とするより広範囲の害が引き起こされるかもしれないルータ。
This says nothing to a policy where preemption should or should not occur across multiple flows.
これは先取りが起こるべきであるか、または複数の流れの向こう側に起こるべきでない方針に沈黙します。
6. Backwards Compatibility
6. 遅れている互換性
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メッセージの両方を発生させます。
Polk & Dhesikan Standards Track [Page 13] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[13ページ]。
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つ以上のルータはこの拡大を支持しません。
7. Security Considerations
7. セキュリティ問題
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認証機構の使用法は奨励されます。
Polk & Dhesikan Standards Track [Page 14] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[14ページ]。
8. IANA Considerations
8. IANA問題
The IANA has assigned the following from RFC 4495 (i.e., this document):
IANAはRFC4495(すなわち、このドキュメント)から以下を割り当てました:
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(間違え、部分的な_が先取りする_)
The behavior of this ErrSubCode is defined in this document.
このErrSubCodeの動きは本書では定義されます。
9. Acknowledgements
9. 承認
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.
作者は、役に立つコメントのためにこの努力とロジャー・レベスクとフランソアLe Faucheurにテキストと指導を寄付して頂いて、フレッド・ベイカーに感謝したがっています。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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の機能的な仕様」、RFC2205、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] ベイカー、F.、イトゥラルデ、C.、Le Faucheur、F.、およびB.デイビー、「IPv4とIPv6予約のためのRSVPの集合」、RFC3175(2001年9月)。
[3] Herzog, S., "Signaled Preemption Priority Policy Element", RFC
3181, October 2001.
[3] ハーツォグ、S.、「合図された先取り優先権方針要素」、RFC3181、2001年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000.
[5] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、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.、トンマージ、F.、およびS.Molendini、「RSVPは全般的な減少拡大をリフレッシュする」RFC2961(2001年4月)。
[7] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997.
[7]Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
Polk & Dhesikan Standards Track [Page 15] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[15ページ]。
[8] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data
Flows", RFC 2207, September 1997.
[8] バーガーとL.とT.オマリー、「IPSECデータフローのためのRSVP拡張子」、RFC2207、1997年9月。
10.2. Informative References
10.2. 有益な参照
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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.、フロイド、S.、およびD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168(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.、デイビー、B.、ボーズ、P.、クリストウ、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の暗号の認証」、RFC2747、2000年1月。
[13] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication --
Updated Message Type Value", RFC 3097, April 2001.
[13] ブレーデンとR.とL.チャン、「RSVPの暗号の認証--メッセージタイプ価値をアップデートする」RFC3097、2001年4月。
Polk & Dhesikan Standards Track [Page 16] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[16ページ]。
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
XのX Deaggregatorのアグリゲータ| | +に対するV------+ +------+ +------+ +------+ 流れ1-->|、|、|、|、|、|、| |-->流動1流動2-->|、|、|、|、|、|、| |-->流動2流動3-->| |==>|、|、| |==>| |-->流動3流動4-->|、| ^ | | | | ^ | |-->流動4流動5-->|、|、|、|、|、|、|、|、| |-->流動5流動9-->| R1| | | R2| | R3| | | R4|-->流動9+------+ | +------+ +------+ | +------+ | || || | 集合X--->|、| 集合X| | <--集合X|| | || +--------------+ | +--------------+ | |Int7| | |Int1| | | +----- | V|------+ | | R10|Int8|===========>|Int2| R11| | | |:::::::::::>|、|、|、| +----- | ^ |------+ | | |Int9| | |Int3| | +--------------+ | +--------------+ .. | .. 集合Y--->。 Yに集めてください。<--集合Y| .. .. | +------+ | +------+ +------+ | +------+ 流れA-->|、|、|、|、|、|、|、|、| |-->流れA流動B-->|、| V| | | | V| |-->流れB流動C-->| |::>|、|、| |::>| |-->流れC流動D-->|、|、|、|、|、|、| |-->流れD流動E-->| R5| | R6| | R7| | R8|-->流れE+------+ +------+ +------+ +------+ ^ ^ | | YのY Deaggregatorのアグリゲータ
Duplicate of Figure 2. Generic RSVP Aggregate Topology
図2の写し。 一般的なRSVP集合トポロジー
Polk & Dhesikan Standards Track [Page 17] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[17ページ]。
Looking at Figure 2, aggregate X (with five 80 kbps flows) traverses:
図2を見て、X(5で、80キロビット毎秒は流れる)横断に集めてください:
R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4
>>>>>R1=R2=R10=R11=R3=R4
And aggregate Y (with five 80 kbps flows) traverses:
そして、Y(5で、80キロビット毎秒は流れる)横断に集めてください:
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キロビット毎秒です。 これはR10のInt7で800キロビット毎秒を合計します。(R10はRSVPがこのインタフェースで近づく手段を持っている最大の帯域幅です)。 シグナリングメッセージは問題なしでインタフェースをまだ横断しています。 より高い相対的な優先権流れが混雑の倍の間、低優先度流れを先取りするように、この例の集合Y.Local方針より高い相対的な優先度には集合Xがあります。 集合AがFlow9を含むように増加するとき、以下のポイントは流れについて説明します。
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 Flow9(80キロビット毎秒における)がXに集めるために加えられるとき、R1は流れの目的地終点に向かってPATHメッセージを開始するでしょう。 ホップごとのこのメッセージはR2、R10、R11、R3、およびR4を通して終点ノードにそれを取り入れるでしょう(それは集合の初期のセットアップから[2]単位で建てられました)。R4は集合X経路です。
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[1])あたりの振舞いを定義しました。 「反-アグリゲータ」からのこの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のInt8は800キロビット毎秒を収容できるだけです、そして、集合XとYはそれぞれ既に5回の80のキロビット毎秒の個々の流れから成る400回のキロビット毎秒流れを確立しました。 したがって、R10(この例における混雑出来事を検出するインタフェース)はInt8に受け取られた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 このシナリオのローカルの方針は、より高い優先度の予約を置くために低優先度の予約を先取りすることです。 これで、通常、ただ追加80キロビット毎秒を求める集合Xの要求に対応するために集合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 このドキュメントは80キロビット毎秒で集合Yが完全に先取りされるというわけではありませんが、帯域幅でどう減少するかを定義します。 これはR10が(川下で)R11、R7、およびR8に向かって発生させるResvErrメッセージに含まれています。 エラーメッセージの詳細に関してセクション5を見てください。
Polk & Dhesikan Standards Track [Page 18] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[18ページ]。
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の通常の操作はまた、ResvTearメッセージ上流(すなわち、逆方向、R5に向かった)を発生させるように川下で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.の「反-アグリゲータ」です。「反-アグリゲータ」は集合予約のすべてのパラメタを制御します。 これはそのような動作を示すResvErrメッセージ(R10からの)のレセプションへの応答が求められるように集合の必要な帯域幅を減少させるノードになるでしょう。 この例では、帯域幅削減は、集合(恐らく、個々の先取りのためにその個々の流れで川下でResvErrを発生させることによって、Flow 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メッセージはその個々の流れ(流れD)でR8によって上流へ送られます。 これは、直接集合に影響しませんが、先取りされるそれの個々の流れがことであるルータ(そして、ソースエンドシステム)への指示です。
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メッセージを送ります。 「反-アグリゲータ」からのこのRESVは、残っている4を収容できるくらいの帯域幅の減少(現在、320キロビット毎秒(この例の)である)が流れるのを(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メッセージは予約の全体の経路を旅行します。 これはResvTearメッセージがR10によってR6とR5に向かって発生するのを防ぐのに必要なことです。
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に与えたなら、それはケース、声がプロトコル(SIPなどの)を示す場合その個々の流れの再交渉を減少している帯域幅に試みたかもしれないFlow D.Inのエンドシステムに向かって帯域幅削減ResvErr指示を伝えたかもしれません。(言いますが、音声コーデックをG.711からG.729に変えます。). これは先取りからFlow Dを取っておいたかもしれません。
Polk & Dhesikan Standards Track [Page 19] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[19ページ]。
Authors' Addresses
作者のアドレス
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェームスM.ポークシスコシステムズ2200の東社長のジョージ・ブッシュ・Turnpikeテキサス75082リチャードソン(米国)
EMail: jmpolk@cisco.com
メール: jmpolk@cisco.com
Subha Dhesikan Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Subha Dhesikanシスコシステムズ170w.タスマンDriveサンノゼ、カリフォルニア95134米国
EMail: sdhesika@cisco.com
メール: sdhesika@cisco.com
Polk & Dhesikan Standards Track [Page 20] RFC 4495 RSVP Bandwidth Reduction May 2006
ポークとDhesikan規格はRSVP帯域幅削減2006年5月にRFC4495を追跡します[20ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Polk & Dhesikan Standards Track [Page 21]
ポークとDhesikan標準化過程[21ページ]
一覧
スポンサーリンク
