RFC2212 日本語訳
2212 Specification of Guaranteed Quality of Service. S. Shenker, C.Partridge, R. Guerin. September 1997. (Format: TXT=52330 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Shenker
Request for Comments: 2212 Xerox
Category: Standards Track C. Partridge
BBN
R. Guerin
IBM
September 1997
Shenkerがコメントのために要求するワーキンググループS.をネットワークでつないでください: 2212年のゼロックスカテゴリ: 標準化過程C.ヤマウズラBBN R.ゲランIBM1997年9月
Specification of Guaranteed Quality of Service
保証されたサービスの質の仕様
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queueing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth. This specification follows the service specification template described in [1].
このメモは振舞いがインターネットを保証されたサービス(保証された遅れと帯域幅)を果たすのを必要としたネットワーク要素について説明します。 保証されたサービスは堅い(数学的に証明可能な)領域に終わらせる終わりのデータグラム待ち行列遅れを提供します。 このサービスで、遅れと帯域幅の両方を保証するサービスを提供するのは可能になります。 この仕様は[1]で説明されたサービス仕様テンプレートに続きます。
Introduction
序論
This document defines the requirements for network elements that support guaranteed service. This memo is one of a series of documents that specify the network element behavior required to support various qualities of service in IP internetworks. Services described in these documents are useful both in the global Internet and private IP networks.
このドキュメントはネットワーク要素のためのサポートがアフターサービスを保証したという要件を定義します。 このメモは振舞いがIPインターネットワークにおける様々なサービスの品質を支持するのを必要としたネットワーク要素を指定する一連のドキュメントの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 RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
This document is based on the service specification template given in [1]. Please refer to that document for definitions and additional information about the specification of qualities of service within the IP protocol family.
このドキュメントは[1]で与えられたサービス仕様テンプレートに基づいています。 IPプロトコル家族の中のサービスの品質の仕様に関する定義と追加情報のためのそのドキュメントを参照してください。
Shenker, et. al. Standards Track [Page 1] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[1ページ]RFC2212
In brief, the concept behind this memo is that a flow is described using a token bucket and given this description of a flow, a service element (a router, a subnet, etc) computes various parameters describing how the service element will handle the flow's data. By combining the parameters from the various service elements in a path, it is possible to compute the maximum delay a piece of data will experience when transmitted via that path.
要するに、このメモの後ろの概念は流れが象徴バケツを使用することで説明されるということです、そして、流れのこの記述を考えて、サービス要素(ルータ、サブネットなど)はサービス要素がどう流れのデータを扱うかを説明する様々なパラメタを計算します。 経路の様々なサービス要素からのパラメタを結合することによって、その経路を通して伝えられると1つのデータがなる最大の遅れを計算するのは可能です。
It is important to note three characteristics of this memo and the service it specifies:
このメモの、そして、それが指定するサービスの3つの特性に注意するのは重要です:
1. While the requirements a setup mechanism must follow to achieve
a guaranteed reservation are carefully specified, neither the
setup mechanism itself nor the method for identifying flows is
specified. One can create a guaranteed reservation using a
protocol like RSVP, manual configuration of relevant routers or a
network management protocol like SNMP. This specification is
intentionally independent of setup mechanism.
1. セットアップメカニズムが保証された予約を達成するために続かなければならない要件は慎重に指定されますが、流れを特定するためのセットアップメカニズム自体も方法は指定されません。 1つは、RSVP(SNMPのような関連ルータかネットワーク管理プロトコルの手動の構成)のようにプロトコルを使用することで保証された予約を作成できます。 この仕様は故意にセットアップメカニズムから独立しています。
2. To achieve a bounded delay requires that every service element
in the path supports guaranteed service or adequately mimics
guaranteed service. However this requirement does not imply that
guaranteed service must be deployed throughout the Internet to be
useful. Guaranteed service can have clear benefits even when
partially deployed. If fully deployed in an intranet, that
intranet can support guaranteed service internally. And an ISP
can put guaranteed service in its backbone and provide guaranteed
service between customers (or between POPs).
2. 境界がある遅れを達成するのは、経路のあらゆるサービス要素が保証されたサービスを支持するか、または適切に保証されたサービスをまねるのを必要とします。 しかしながら、この要件は、役に立つようにインターネット中で保証されたサービスを配備しなければならないのを含意しません。 部分的に配備されると、保証されたサービスは明確な利益を持つことができます。 イントラネットで完全に配備されるなら、そのイントラネットは内部的に保証されたサービスを支持できます。 そして、ISPは、保証されたサービスを背骨に入れて、顧客(またはPOPの間で)の間に保証されたサービスを提供できます。
3. Because service elements produce a delay bound as a result
rather than take a delay bound as an input to be achieved, it is
sometimes assumed that applications cannot control the delay. In
reality, guaranteed service gives applications considerable
control over their delay.
3. サービス要素が達成されるために入力として縛られた遅れを取るよりその結果むしろ縛られた遅れを生産するので、時々アプリケーションが遅れを制御できないと思われます。 ほんとうは、保証されたサービスはそれらの遅れのかなりの支配力をアプリケーションに与えます。
In brief, delay has two parts: a fixed delay (transmission delays,
etc) and a queueing delay. The fixed delay is a property of the
chosen path, which is determined not by guaranteed service but by
the setup mechanism. Only queueing delay is determined by
guaranteed service. And (as the equations later in this memo
show) the queueing delay is primarily a function of two
parameters: the token bucket (in particular, the bucket size b)
要するに、遅れには、2つの部品があります: 固定遅れ(トランスミッション遅れなど)と待ち行列は延着します。 固定遅れは選んだ道の特性です。(それは、保証されたサービスで決定するのではなく、セットアップメカニズムで決定します)。 待ち行列遅れだけが保証されたサービスで決定します。 そして、(後でのこのメモの方程式が示すように)待ち行列遅れは主として2つのパラメタの関数です: 象徴バケツ(特にバケツサイズb)
Shenker, et. al. Standards Track [Page 2] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[2ページ]RFC2212
and the data rate (R) the application requests. These two values
are completely under the application's control. In other words,
an application can usually accurately estimate, a priori, what
queueing delay guaranteed service will likely promise.
Furthermore, if the delay is larger than expected, the application
can modify its token bucket and data rate in predictable ways to
achieve a lower delay.
そして、アプリケーションが要求するデータ信号速度(R)。 これらの2つの値がアプリケーションのコントロールの完全下にあります。 言い換えれば、通常、アプリケーションは、どんな待ち行列遅れがアフターサービスを保証したかがおそらく約束すると正確に先験的に見積もることができます。 その上、遅れが予想より大きいなら、アプリケーションは下側の遅れを達成する予測できる方法でその象徴バケツとデータ信号速度を変更できます。
End-to-End Behavior
終わりから終わりへの振舞い
The end-to-end behavior provided by a series of network elements that conform to this document is an assured level of bandwidth that, when used by a policed flow, produces a delay-bounded service with no queueing loss for all conforming datagrams (assuming no failure of network components or changes in routing during the life of the flow).
終わりから終わりへのこのドキュメントに一致している一連のネットワーク要素によって提供された振舞いは取り締まられた流れによって使用されるとデータグラム(流れの人生の間、ルーティングにおけるネットワーク要素か変化の失敗を全く仮定しない)を従わせながらすべてのための待ち行列の損失なしで遅れで境界があるサービスを起こす確実なレベルの帯域幅です。
The end-to-end behavior conforms to the fluid model (described under Network Element Data Handling below) in that the delivered queueing delays do not exceed the fluid delays by more than the specified error bounds. More precisely, the end-to-end delay bound is [(b- M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot for p>R>=r, and (M+Ctot)/R+Dtot for r<=p<=R, (where b, r, p, M, R, Ctot, and Dtot are defined later in this document).
渡された待ち行列遅れが指定された誤り領域以上で流体遅れを超えていないので、終わりから終わりへの振舞いは流体モデル(以下のNetwork Element Data Handlingの下で説明される)に従います。 より正確に、終わりから終わりへの遅れバウンドが+ (b M)/R*(p-R)/(p-r)]p p>R>=rのための(M+Ctot)/R+Dtot、およびr<のための(M+Ctot)/R+Dtot=<=Rである、(b、r、p、M、R、Ctot、およびDtotが後で本書では定義されるところ。)
NOTE: While the per-hop error terms needed to compute the end-to-
end delays are exported by the service module (see Exported
Information below), the mechanisms needed to collect per-hop
bounds and make the end-to-end quantities Ctot and Dtot known to
the applications are not described in this specification. These
functions are provided by reservation setup protocols, routing
protocols or other network management functions and are outside
the scope of this document.
以下に注意してください。 1ホップあたりの誤差項は、計算する必要がありましたが、機械船で終わりから終わりへの遅れを輸出します、そして、(以下のExported情報を見てください)メカニズムは、1ホップあたりの領域を集めて、終わりから端を量のCtotにする必要がありました、そして、この仕様でアプリケーションに知られているDtotについて説明しません。 これらの機能は、予約セットアッププロトコル、ルーティング・プロトコルまたは他のネットワークマネージメント機能によって提供されて、このドキュメントの範囲の外にあります。
The maximum end-to-end queueing delay (as characterized by Ctot and Dtot) and bandwidth (characterized by R) provided along a path will be stable. That is, they will not change as long as the end-to-end path does not change.
経路に沿って供給された終わりから終わりへの待ち行列最大の遅れ(CtotとDtotによって特徴付けられるように)と帯域幅(Rで、特徴付けられる)は安定するでしょう。 終わりから端への経路が変化しない限り、すなわち、彼らは変化しないでしょう。
Guaranteed service does not control the minimal or average delay of datagrams, merely the maximal queueing delay. Furthermore, to compute the maximum delay a datagram will experience, the latency of the path MUST be determined and added to the guaranteed queueing delay. (However, as noted below, a conservative bound of the latency can be computed by observing the delay experienced by any one packet).
保証されたサービスはデータグラムの最小量の、または、平均した遅れ、単に最大限度の待ち行列遅れを制御しません。 その上、データグラムが経験する最大の遅れを計算するために、保証された待ち行列遅れに経路の潜在は決定して、加えなければなりません。 (しかしながら、以下に述べられるように、どんなパケットによっても経験された遅れを観測することによって、潜在の保守的なバウンドを計算できます。)
This service is subject to admission control.
このサービスは入場コントロールを受けることがあります。
Shenker, et. al. Standards Track [Page 3] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[3ページ]RFC2212
Motivation
動機
Guaranteed service guarantees that datagrams will arrive within the guaranteed delivery time and will not be discarded due to queue overflows, provided the flow's traffic stays within its specified traffic parameters. This service is intended for applications which need a firm guarantee that a datagram will arrive no later than a certain time after it was transmitted by its source. For example, some audio and video "play-back" applications are intolerant of any datagram arriving after their play-back time. Applications that have hard real-time requirements will also require guaranteed service.
保証されたサービスは、データグラムが保証された納期中に到着して、待ち行列オーバーフローのため捨てられないのを保証します、流れの交通が指定された交通パラメタの範囲内にとどまるなら。 このサービスはそれが情報筋によって伝えられた後にデータグラムが、ある時間までに届くという安定した保証を必要とするアプリケーションのために意図します。 例えば、どんなデータグラムも彼らの再生時の後に届くのにおいていくつかのオーディオとビデオ「再生」アプリケーションが偏狭です。 また、確実なリアルタイムの要件を持っているアプリケーションが保証されたサービスを必要とするでしょう。
This service does not attempt to minimize the jitter (the difference between the minimal and maximal datagram delays); it merely controls the maximal queueing delay. Because the guaranteed delay bound is a firm one, the delay has to be set large enough to cover extremely rare cases of long queueing delays. Several studies have shown that the actual delay for the vast majority of datagrams can be far lower than the guaranteed delay. Therefore, authors of playback applications should note that datagrams will often arrive far earlier than the delivery deadline and will have to be buffered at the receiving system until it is time for the application to process them.
このサービスは、ジター(最小量の、そして、最大限度のデータグラム遅れの違い)を最小にするのを試みません。 それは単に最大限度の待ち行列遅れを制御します。 保証された遅れバウンドが堅いものであるので、遅れは長い待ち行列遅れの非常にまれなケースをカバーできるくらい大きいセットでなければなりません。 いくつかの研究が、データグラムのかなりの大部分の実際の遅れが保証された遅れよりはるかに低い場合があるのを示しました。 したがって、再生アプリケーションの作者は、データグラムがアプリケーションがもうそれらを処理するべき時間になるまで配送の締め切りよりはるかに早くしばしば到着して、受電方式でバッファリングされなければならないことに注意するべきです。
This service represents one extreme end of delay control for networks. Most other services providing delay control provide much weaker assurances about the resulting delays. In order to provide this high level of assurance, guaranteed service is typically only useful if provided by every network element along the path (i.e. by both routers and the links that interconnect the routers). Moreover, as described in the Exported Information section, effective provision and use of the service requires that the set-up protocol or other mechanism used to request service provides service characterizations to intermediate routers and to the endpoints.
このサービスはネットワークのために遅れコントロールのある極端な終わりを表します。 遅れコントロールを提供する他のほとんどのサービスが結果として起こる遅れに関してはるかに弱い保証を提供します。 この高いレベルを保証を提供するために、経路(すなわち、ルータとインタコネクトするルータとリンクの両方による)に沿ったあらゆるネットワーク要素で提供する場合にだけ、保証されたサービスは通常役に立ちます。 そのうえ、Exported情報部で説明されるように、サービスの有効な支給と使用は、セットアッププロトコルか他のメカニズムが、以前はよくサービスが中間的ルータと、そして、終点にサービス特殊化を提供するよう要求していたのを必要とします。
Network Element Data Handling Requirements
ネットワーク要素データハンドリング要件
The network element MUST ensure that the service approximates the "fluid model" of service. The fluid model at service rate R is essentially the service that would be provided by a dedicated wire of bandwidth R between the source and receiver. Thus, in the fluid model of service at a fixed rate R, the flow's service is completely independent of that of any other flow.
ネットワーク要素は、サービスがサービスの「流体モデル」に近似するのを確実にしなければなりません。 サービス率Rにおける流体モデルは本質的にはソースと受信機の間の帯域幅Rの専用ワイヤによって提供されるサービスです。その結果、定率Rでのサービスの流体モデルでは、流れのサービスはいかなる他の流れのものからも完全に独立しています。
Shenker, et. al. Standards Track [Page 4] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[4ページ]RFC2212
The flow's level of service is characterized at each network element by a bandwidth (or service rate) R and a buffer size B. R represents the share of the link's bandwidth the flow is entitled to and B represents the buffer space in the network element that the flow may consume. The network element MUST ensure that its service matches the fluid model at that same rate to within a sharp error bound.
流れのサービスのレベルはそれぞれのネットワーク要素で帯域幅(または、サービス率)Rによって特徴付けられます、そして、バッファサイズB.Rは流れが権利を与えられるリンクの帯域幅のシェアを表します、そして、Bは流れが消費するかもしれないネットワーク要素のバッファ領域を表します。 ネットワーク要素は、サービスがその同じ速度で機敏な誤りバウンドに流体モデルを合わせるのを確実にしなければなりません。
The definition of guaranteed service relies on the result that the fluid delay of a flow obeying a token bucket (r,b) and being served by a line with bandwidth R is bounded by b/R as long as R is no less than r. Guaranteed service with a service rate R, where now R is a share of bandwidth rather than the bandwidth of a dedicated line, approximates this behavior.
保証されたサービスの定義はrのようにRが長い同じくらいb/Rであるのにもかかわらずの、象徴バケツ(r、b)に従って、帯域幅Rがある線によって役立たれている流れの流体遅れによって制限されるという結果を当てにします。 サービス率Rがある保証されたサービスは現在Rが専用線の帯域幅よりむしろ帯域幅のシェアであるところでこの振舞いに近似します。
Consequently, the network element MUST ensure that the queueing delay of any datagram be less than b/R+C/R+D, where C and D describe the maximal local deviation away from the fluid model. It is important to emphasize that C and D are maximums. So, for instance, if an implementation has occasional gaps in service (perhaps due to processing routing updates), D needs to be large enough to account for the time a datagram may lose during the gap in service. (C and D are described in more detail in the section on Exported Information).
その結果、ネットワーク要素は、どんなデータグラムの待ち行列遅れもb/R+C/R+D以下であることを確実にしなければなりません。(そこで、CとDは流体モデルから遠くで最大限度の地方の逸脱について説明します)。 CとDが最大であると強調するのは重要です。そのように、例えば、時々のギャップが実現で使用中に(恐らく処理ルーティングアップデートによる)なるなら、大きく時にデータグラムを説明できるくらいなるDの必要性はギャップの間、使用中の状態で損をするかもしれません。 (CとDはさらに詳細にExported情報のセクションで説明されます。)
NOTE: Strictly speaking, this memo requires only that the service
a flow receives is never worse than it would receive under this
approximation of the fluid model. It is perfectly acceptable to
give better service. For instance, if a flow is currently not
using its share, R, algorithms such as Weighted Fair Queueing that
temporarily give other flows the unused bandwidth, are perfectly
acceptable (indeed, are encouraged).
以下に注意してください。 厳密に言うと、このメモは、流れが受けるサービスが流体モデルのこの近似で受信するだろうより決して悪いだけではないのを必要とします。 より良いサービスを与えるのは完全に許容できます。 例えば、流れが現在シェアを使用していないなら、R、一時未使用の帯域幅を他の流れに与えるWeighted Fair Queueingなどのアルゴリズムが完全に許容できる、(本当に、奨励される、)
Links are not permitted to fragment datagrams as part of guaranteed service. Datagrams larger than the MTU of the link MUST be policed as nonconformant which means that they will be policed according to the rules described in the Policing section below.
リンクが保証されたサービスの一部としてデータグラムを断片化することが許可されていません。 下のPolicing部で説明された規則に従ってそれらが取り締まられることを意味するnonconformantとしてリンクのMTUより大きいデータグラムを取り締まらなければなりません。
Invocation Information
実施の情報
Guaranteed service is invoked by specifying the traffic (TSpec) and the desired service (RSpec) to the network element. A service request for an existing flow that has a new TSpec and/or RSpec SHOULD be treated as a new invocation, in the sense that admission control SHOULD be reapplied to the flow. Flows that reduce their TSpec and/or their RSpec (i.e., their new TSpec/RSpec is strictly smaller than the old TSpec/RSpec according to the ordering rules described in the section on Ordering below) SHOULD never be denied service.
保証されたサービスは、交通(TSpec)とネットワーク要素に対する必要なサービス(RSpec)を指定することによって、呼び出されます。 入場コントロールSHOULDが流れに再び使われるという意味で新しいTSpec、そして/または、RSpec SHOULDを新しい実施として扱わせる既存の流れのためのサービスのリクエスト。 それはそれらのTSpec、そして/または、それらのRSpecを減少させます。流れ、(すなわち、それらの新しいTSpec/RSpecは厳密に決して小さくない否定されたサービスです。
Shenker, et. al. Standards Track [Page 5] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[5ページ]RFC2212
The TSpec takes the form of a token bucket plus a peak rate (p), a minimum policed unit (m), and a maximum datagram size (M).
TSpecは象徴バケツ、ピークレート(p)、最小の取り締まられた単位(m)、および最大のデータグラムサイズ(M)の形を取ります。
The token bucket has a bucket depth, b, and a bucket rate, r. Both b and r MUST be positive. The rate, r, is measured in bytes of IP datagrams per second, and can range from 1 byte per second to as large as 40 terabytes per second (or close to what is believed to be the maximum theoretical bandwidth of a single strand of fiber). Clearly, particularly for large bandwidths, only the first few digits are significant and so the use of floating point representations, accurate to at least 0.1% is encouraged.
象徴バケツには、バケツの深さ、b、およびバケツレート、rがあります。 bとrの両方が積極的であるに違いありません。 レート(r)が1秒あたりのバイトのIPデータグラムで測定されて、1秒あたり1バイトから変化できる、秒(またはファイバーの単一ストランドの最大の理論上の帯域幅であると信じられていることの近くで)あたりの40テラバイトと同じくらい大きいです。 最初の数ケタが重要であるだけであるので、明確に、そして、特に大きい帯域幅に関して、少なくとも0.1%に正確な浮動小数点表示の使用は重要です。奨励にされる。
The bucket depth, b, is also measured in bytes and can range from 1 byte to 250 gigabytes. Again, floating point representations accurate to at least 0.1% are encouraged.
バケツの深さ(b)は、また、バイトで測定されて、1バイトから250のギガバイトまで及ぶことができます。 一方、少なくとも0.1%に正確な浮動小数点表示は奨励されます。
The range of values is intentionally large to allow for the future bandwidths. The range is not intended to imply that a network element has to support the entire range.
値の範囲は、将来の帯域幅を考慮するために故意に大きいです。 範囲が、ネットワーク要素が全体の範囲を支持しなければならないのを含意することを意図しません。
The peak rate, p, is measured in bytes of IP datagrams per second and has the same range and suggested representation as the bucket rate. The peak rate is the maximum rate at which the source and any reshaping points (reshaping points are defined below) may inject bursts of traffic into the network. More precisely, it is a requirement that for all time periods the amount of data sent cannot exceed M+pT where M is the maximum datagram size and T is the length of the time period. Furthermore, p MUST be greater than or equal to the token bucket rate, r. If the peak rate is unknown or unspecified, then p MUST be set to infinity.
ピークレート(p)は、1秒あたりのバイトのIPデータグラムで測定されて、バケツレートとして同じ範囲と提案された表現を持っています。 ピークレートはソースと任意な造り直す点(造り直すポイントは以下で定義される)が交通の炸裂をネットワークに注ぐかもしれない最高率です。 より正確に、それはデータ量がすべての期間、発信したので、Mが最大のデータグラムサイズであり、Tが期間の長さであるM+pTを超えることができない要件です。 その上、pはそう以上であるに違いありません。象徴バケツレート、r。 ピークレートが未知である、または不特定であるなら、pを無限で設定しなければなりません。
The minimum policed unit, m, is an integer measured in bytes. All IP datagrams less than size m will be counted, when policed and tested for conformance to the TSpec, as being of size m. The maximum datagram size, M, is the biggest datagram that will conform to the traffic specification; it is also measured in bytes. The flow MUST be rejected if the requested maximum datagram size is larger than the MTU of the link. Both m and M MUST be positive, and m MUST be less than or equal to M.
最小の取り締まられた単位(m)はバイトで測定された整数です。 サイズmより少ないすべてのIPデータグラムが数えられるでしょう、順応がないかどうかTSpecに取り締まられて、テストされると、サイズmの存在として。 最大のデータグラムサイズ(M)は交通仕様に一致している最も大きいデータグラムです。 また、それはバイトで測定されます。 要求された最大のデータグラムサイズがリンクのMTUより大きいなら、流れを拒絶しなければなりません。 mとMの両方が積極的であるに違いありません、そして、mは、よりM以下でなければなりません。
The guaranteed service uses the general TOKEN_BUCKET_TSPEC
parameter defined in Reference [8] to describe a data flow's
traffic characteristics. The description above is of that
parameter. The TOKEN_BUCKET_TSPEC is general parameter number
127. Use of this parameter for the guaranteed service TSpec
simplifies the use of guaranteed Service in a multi-service
environment.
保証されたサービスはデータフローの交通の特性について説明するためにReference[8]で定義された一般的なTOKEN_BUCKET_TSPECパラメタを使用します。 上の記述はそのパラメタのものです。 TOKEN_BUCKET_TSPECは一般的指標No.127です。 このパラメタの保証されたサービスTSpecの使用はマルチサービス環境における保証されたServiceの使用を簡素化します。
Shenker, et. al. Standards Track [Page 6] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[6ページ]RFC2212
The RSpec is a rate R and a slack term S, where R MUST be greater than or equal to r and S MUST be nonnegative. The rate R is again measured in bytes of IP datagrams per second and has the same range and suggested representation as the bucket and the peak rates. The slack term S is in microseconds. The RSpec rate can be bigger than the TSpec rate because higher rates will reduce queueing delay. The slack term signifies the difference between the desired delay and the delay obtained by using a reservation level R. This slack term can be utilized by the network element to reduce its resource reservation for this flow. When a network element chooses to utilize some of the slack in the RSpec, it MUST follow specific rules in updating the R and S fields of the RSpec; these rules are specified in the Ordering and Merging section. If at the time of service invocation no slack is specified, the slack term, S, is set to zero. No buffer specification is included in the RSpec because the network element is expected to derive the required buffer space to ensure no queueing loss from the token bucket and peak rate in the TSpec, the reserved rate and slack in the RSpec, the exported information received at the network element, i.e., Ctot and Dtot or Csum and Dsum, combined with internal information about how the element manages its traffic.
RSpecがレートRと低調な用語Sである、Rがそう以上であるに違いないところでは、rとSは非負であるに違いありません。 レートRは、再び1秒あたりのバイトのIPデータグラムで測定されて、バケツとピークレートとして同じ範囲と提案された表現を持っています。 マイクロセカンドのときに、低調な用語Sがあります。 より高いレートが待ち行列遅れを減少させるので、RSpecレートはTSpecレートより大きい場合があります。 意味という必要な遅れと遅れの違いが予約のレベルのR.のThisの低調な用語を使用することによって得た低調な用語はネットワーク要素によって利用されて、この流れの資源予約を抑えることができます。 ネットワーク要素が、RSpecで何らかのゆるみを利用するのを選ぶとき、RSpecのRとS分野をアップデートする際に特定の規則に従わなければなりません。 これらの規則はOrderingとMerging部で指定されます。 ゆるみが全くサービス実施時点で指定されないなら、低調な用語(S)はゼロに決められます。 ネットワーク要素がRSpecのTSpecの象徴バケツとピークレート、予約されたレート、およびゆるみからの待ち行列の損失(すなわち、ネットワーク要素、Ctotに受け取られた輸出された情報とDtotかCsumとDsum)が全く要素がどう交通を管理するかの内部の情報に結合しなかったのを保証するために必要なバッファ領域を引き出すことが期待されるので、バッファ仕様は全くRSpecに含まれていません。
The TSpec can be represented by three floating point numbers in single-precision IEEE floating point format followed by two 32-bit integers in network byte order. The first floating point value is the rate (r), the second floating point value is the bucket size (b), the third floating point is the peak rate (p), the first integer is the minimum policed unit (m), and the second integer is the maximum datagram size (M).
ネットワークバイトオーダーにおける2つの32ビットの整数があとに続いた単精度IEEE浮動小数点形式における3つの浮動小数点はTSpecを表すことができます。 最初の浮動小数点値はレート(r)です、そして、2番目の浮動小数点値はバケツサイズ(b)です、そして、3番目の浮動小数点はピークレート(p)です、そして、最初の整数は最小の取り締まられた単位(m)です、そして、2番目の整数は最大のデータグラムサイズ(M)です。
The RSpec rate term, R, can also be represented using single- precision IEEE floating point.
また、RSpecレート用語(R)は表された使用ただ一つの精度IEEEが浮動小数点であったならそうすることができます。
The Slack term, S, can be represented as a 32-bit integer. Its value can range from 0 to (2**32)-1 microseconds.
32ビットの整数としてSlack用語(S)を表すことができます。 値は-1マイクロセカンドに0〜(2**32)まで及ぶことができます。
When r, b, p, and R terms are represented as IEEE floating point values, the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255) and a sign bit and mantissa of all zeroes.
r、b、p、およびR用語がIEEE浮動小数点値として表されるとき、符号ビットはゼロであるに違いありません(すべての値が非否定的であるに違いありません)。 解説者127(すなわち、0)は禁止されています。 無限のピークレートを指定するのを除いて、解説者より多くの162(すなわち、陽の35)はがっかりしています。 無限はすべてのゼロのすべてのもの(255)の解説者、符号ビット、および仮数で表されます。
Exported Information
輸出された情報
Each guaranteed service module MUST export at least the following information. All of the parameters described below are characterization parameters.
それぞれの保証された機械船は少なくとも以下の情報を輸出しなければなりません。 以下で説明されたパラメタのすべてが特殊化パラメタです。
Shenker, et. al. Standards Track [Page 7] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[7ページ]RFC2212
A network element's implementation of guaranteed service is characterized by two error terms, C and D, which represent how the element's implementation of the guaranteed service deviates from the fluid model. These two parameters have an additive composition rule.
ネットワーク要素の保証されたサービスの実現は2回の誤差項によって特徴付けられて、CとD(要素の保証されたサービスの実現がどう逸脱するかを表す)は流体からモデル化されます。 これらの2つのパラメタには、付加的な構成規則があります。
The error term C is the rate-dependent error term. It represents the delay a datagram in the flow might experience due to the rate parameters of the flow. An example of such an error term is the need to account for the time taken serializing a datagram broken up into ATM cells, with the cells sent at a frequency of 1/r.
誤差項Cはレート依存する誤差項です。 それは流れにおけるデータグラムが流れのレートパラメタのため経験するかもしれない遅れを表します。 そのような誤差項に関する例はATMセルに壊れるデータグラムを連載しながらかかる時間を説明する必要性です、1/rの頻度でセルを送って。
NOTE: It is important to observe that when computing the delay
bound, parameter C is divided by the reservation rate R. This
division is done because, as with the example of serializing the
datagram, the effect of the C term is a function of the
transmission rate. Implementors should take care to confirm that
their C values, when divided by various rates, give appropriate
results. Delay values that are not dependent on the rate SHOULD
be incorporated into the value for the D parameter.
以下に注意してください。 遅れを計算するのが付いたとき、C用語の効果がデータグラムを連載する例のように通信速度の関数であるので、R.This分割が行われる予約率がパラメタCに割られるのを観測するのは重要です。 作成者は、様々なレートが割られるとき、彼らのC値が適切な結果を与えると確認するために注意するべきです。 レートSHOULDに依存しない値を遅らせてください。Dパラメタのための値に法人組織になってください。
The error term D is the rate-independent, per-element error term and represents the worst case non-rate-based transit time variation through the service element. It is generally determined or set at boot or configuration time. An example of D is a slotted network, in which guaranteed flows are assigned particular slots in a cycle of slots. Some part of the per-flow delay may be determined by which slots in the cycle are allocated to the flow. In this case, D would measure the maximum amount of time a flow's data, once ready to be sent, might have to wait for a slot. (Observe that this value can be computed before slots are assigned and thus can be advertised. For instance, imagine there are 100 slots. In the worst case, a flow might get all of its N slots clustered together, such that if a packet was made ready to send just after the cluster ended, the packet might have to wait 100-N slot times before transmitting. In this case one can easily approximate this delay by setting D to 100 slot times).
誤差項Dは、1要素あたりのレートから独立している誤差項であり、サービス要素を通した最悪の場合の非レートベースのトランジット時間変化を表します。 それは、ブーツか構成時に一般に、決定するか、または設定されます。 Dに関する例は溝をつけられたネットワークです、どれが、1サイクルのスロットの特定のスロットが流れに割り当てられるのを保証したかで。 1流れあたりの遅れの何らかの部分がサイクルのどのスロットを流れに割り当てるかによって測定されるかもしれません。 この場合、Dは流れのかつて送る準備ができているデータがスロットを待たなければならないかもしれない最大の時間に測定するでしょう。 (この値がスロットが割り当てられる前に計算できて、その結果、広告を出すことができるのを観測してください。 例えば、100のスロットがあると想像してください。 最悪の場合には、流れはNスロットのすべてを群がらせるかもしれません、パケットをクラスタが終わったすぐ後に発信する準備ができているようにするなら、パケットが伝わる前に100-Nスロット回数を待たなければならないように。 この場合、100スロット回にDを設定することによって、1つは容易にこの遅れに近似できます。).
If the composition function is applied along the entire path to compute the end-to-end sums of C and D (Ctot and Dtot) and the resulting values are then provided to the end nodes (by presumably the setup protocol), the end nodes can compute the maximal datagram queueing delays. Moreover, if the partial sums (Csum and Dsum) from the most recent reshaping point (reshaping points are defined below) downstream towards receivers are handed to each network element then these network elements can compute the buffer allocations necessary
CとD(CtotとDtot)の終わりから終わりへの合計を計算するために全体の経路に沿って構成機能を適用して、次に、エンドノード(おそらくセットアッププロトコルによる)に結果として起こる値を提供するなら、エンドノードは最大限度のデータグラム待ち行列遅れを計算できます。 そのうえ、受信機に向かった最新の造り直すポイント(造り直すポイントは以下で定義される)川下からの部分和(CsumとDsum)がそれぞれのネットワーク要素に手渡されるなら、これらのネットワーク要素は必要な状態でバッファ配分を計算できます。
Shenker, et. al. Standards Track [Page 8] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[8ページ]RFC2212
to achieve no datagram loss, as detailed in the section Guidelines for Implementors. The proper use and provision of this service requires that the quantities Ctot and Dtot, and the quantities Csum and Dsum be computed. Therefore, we assume that usage of guaranteed service will be primarily in contexts where these quantities are made available to end nodes and network elements.
ImplementorsのためにセクションGuidelinesで詳しく述べられるようにデータグラムの損失を全く達成しないように。 このサービスの適切な使用と支給は、量の量のCtot、Dtot、Csum、およびDsumが計算されるのを必要とします。 したがって、私たちは、保証されたサービスの用法が主としてこれらの量がノードとネットワーク要素を終わらせるために利用可能にされる文脈にあると思います。
The error term C is measured in units of bytes. An individual element can advertise a C value between 1 and 2**28 (a little over 250 megabytes) and the total added over all elements can range as high as (2**32)-1. Should the sum of the different elements delay exceed (2**32)-1, the end-to-end error term MUST be set to (2**32)-1.
誤差項Cはユニットのバイトで測定されます。 個々の要素は1と2**28の間のC値(250メガバイト余り)の広告を出すことができます、そして、すべての要素の上加えられた合計は(2**32)-1と同じくらい上に及ぶことができます。 異なった要素遅れの合計は-1、終わりから終わりへの-1に(2**32)に設定しなければならない誤差項を超えるべきです(2**32)。
The error term D is measured in units of one microsecond. An individual element can advertise a delay value between 1 and 2**28 (somewhat over two minutes) and the total delay added over all elements can range as high as (2**32)-1. Should the sum of the different elements delay exceed (2**32)-1, the end-to-end delay MUST be set to (2**32)-1.
誤差項Dは1マイクロセカンドのユニットで測定されます。 個々の要素は1と2**28の間の遅れ値(いくらか2分以上)の広告を出すことができます、そして、すべての要素の上加えられた総遅れは(2**32)-1と同じくらい上に及ぶことができます。 -1、遅れを設定しなければならない終わりによって異なった要素遅れの合計は-1に超えるべきです(2**32)(2**32)。
The guaranteed service is service_name 2.
保証されたサービスはサービス_名前2です。
The RSpec parameter is numbered 130.
RSpecパラメタは番号付の130です。
Error characterization parameters C and D are numbered 131 and 132. The end-to-end composed values for C and D (Ctot and Dtot) are numbered 133 and 134. The since-last-reshaping point composed values for C and D (Csum and Dsum) are numbered 135 and 136.
誤り特殊化パラメタCとDは、番号付の131と132です。 D(CtotとDtot)は、終わりから終わりがCのために値を構成して、番号付の133と134です。 D(CsumとDsum)は、最後の造り直すの以来のポイントがCのために値を構成して、番号付の135と136です。
Policing
取り締まり
There are two forms of policing in guaranteed service. One form is simple policing (hereafter just called policing to be consistent with other documents), in which arriving traffic is compared against a TSpec. The other form is reshaping, where an attempt is made to restore (possibly distorted) traffic's shape to conform to the TSpec, and the fact that traffic is in violation of the TSpec is discovered because the reshaping fails (the reshaping buffer overflows).
保証されたサービスにおける、取り締まりの2つのフォームがあります。 1つのフォームは簡単な取り締まりです(他のドキュメントと一致しているように今後ただ取り締まりと呼ばれます)。(そこでは、TSpecに対して到着交通が比較されます)。 もう片方のフォームは造り直されています、TSpecに従うためにトラフィックの形を回復するのを(ことによると歪められています)試みをして、造り直すことが失敗するので(造り直すバッファはあふれます)、交通がTSpecを違反しているという事実を発見するところで。
Policing is done at the edge of the network. Reshaping is done at all heterogeneous source branch points and at all source merge points. A heterogeneous source branch point is a spot where the multicast distribution tree from a source branches to multiple distinct paths, and the TSpec's of the reservations on the various outgoing links are not all the same. Reshaping need only be done if the TSpec on the outgoing link is "less than" (in the sense described in the Ordering section) the TSpec reserved on the immediately upstream link. A source merge point is where the distribution paths
ネットワークの縁で取り締まりをします。 すべての異種のソースブランチポイントにおいてすべてのソースマージポイントで造り直すことをします。 異種のソースブランチポイントはソースからのマルチキャスト分配木を複数の異なった経路に枝を出す場所です、そして、様々な出発しているリンクの予約のTSpecはちょうど同じではありません。 出発しているリンクの上のTSpecがするなら造り直すことをするだけでよい、「」 すぐに上流のリンクの上に予約された(Ordering部で説明された意味における)TSpecよりそれほど。 ソースマージポイントがどこであるか、分配経路
Shenker, et. al. Standards Track [Page 9] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[9ページ]RFC2212
or trees from two different sources (sharing the same reservation) merge. It is the responsibility of the invoker of the service (a setup protocol, local configuration tool, or similar mechanism) to identify points where policing is required. Reshaping may be done at other points as well as those described above. Policing MUST not be done except at the edge of the network.
または、2人のさまざまな原因(同じ予約を共有します)からの木は合併します。 取り締まりが必要であるポイントを特定するのは、サービス(セットアッププロトコル、ローカルの構成ツール、または同様のメカニズム)の呼び出し元の責任です。 上で説明されたものと同様に他のポイントで造り直すことをするかもしれません。 ネットワークの縁以外に、取り締まりをしてはいけません。
The token bucket and peak rate parameters require that traffic MUST obey the rule that over all time periods, the amount of data sent cannot exceed M+min[pT, rT+b-M], where r and b are the token bucket parameters, M is the maximum datagram size, and T is the length of the time period (note that when p is infinite this reduces to the standard token bucket requirement). For the purposes of this accounting, links MUST count datagrams which are smaller than the minimum policing unit to be of size m. Datagrams which arrive at an element and cause a violation of the the M+min[pT, rT+b-M] bound are considered non-conformant.
象徴バケツとピークレートパラメタは、交通がすべての期間にわたって送られたデータ量がM+分[pT、rT+b-M]を超えることができないという規則に従わなければならないのを必要とします。(そこでは、rとbが象徴バケツパラメタであり、Mが最大のデータグラムサイズであり、Tは期間の長さ(pが無限であるときに、これが標準の象徴バケツ要件に減少することに注意する)です)。 この会計の目的のために、リンクはサイズmがユニットを取り締まる最小限より小さいデータグラムを数えなければなりません。 要素に達して、M+分[pT、rT+b-M]バウンドの違反を引き起こすデータグラムは非conformantであると考えられます。
At the edge of the network, traffic is policed to ensure it conforms to the token bucket. Non-conforming datagrams SHOULD be treated as best-effort datagrams. [If and when a marking ability becomes available, these non-conformant datagrams SHOULD be ''marked'' as being non-compliant and then treated as best effort datagrams at all subsequent routers.]
ネットワークの縁では、交通が、それが象徴バケツに従うのを保証するために取り締まられます。 非の従うデータグラムSHOULD、ベストエフォート型データグラムとして扱われてください。[マーク能力が利用可能になるなら、これらの非conformantデータグラムSHOULDは不従順で次に、ベストエフォート型データグラムとしてすべてのその後のルータで扱われるとして「マーク」でした。]
Best effort service is defined as the default service a network element would give to a datagram that is not part of a flow and was sent between the flow's source and destination. Among other implications, this definition means that if a flow's datagram is changed to a best effort datagram, all flow control (e.g., RED [2]) that is normally applied to best effort datagrams is applied to that datagram too.
ベストエフォート型サービスをネットワーク要素が流れの一部でないデータグラムに与えるデフォルトサービスと定義して、流れのソースと目的地の間に送りました。 流れのデータグラムがベストエフォート型データグラムに変わるなら、他の含意の中では、この定義はそれを意味します、すべてのフロー制御。(例えば通常、ベストエフォート型データグラムに適用されるRED[2])はそのデータグラムにも適用されます。
NOTE: There may be situations outside the scope of this document,
such as when a service module's implementation of guaranteed
service is being used to implement traffic sharing rather than a
quality of service, where the desired action is to discard non-
conforming datagrams. To allow for such uses, implementors SHOULD
ensure that the action to be taken for non-conforming datagrams is
configurable.
以下に注意してください。 このドキュメントの範囲の外に状況があるかもしれません、機械船の保証されたサービスの実現が非従っているデータグラムを捨てる必要な動作がことであるサービスの質よりむしろ交通共有を実行するのに使用されている時のように。そのような用途を考慮するために、作成者SHOULDは非の従うデータグラムに取られるべき動きが確実に構成可能になるようにします。
Inside the network, policing does not produce the desired results, because queueing effects will occasionally cause a flow's traffic that entered the network as conformant to be no longer conformant at some downstream network element. Therefore, inside the network, network elements that wish to police traffic MUST do so by reshaping traffic to the token bucket. Reshaping entails delaying datagrams until they are within conformance of the TSpec.
ネットワークの中では、取り締まりは望み通りの成果を作り出しません、待ち行列効果が、時折conformantとしてネットワークに入った流れの交通がもう何らかの川下のネットワーク要素のconformantでないことを引き起こさないので。 したがって、ネットワークの中では、警察の交通に願われているネットワーク要素は、交通を造り直すことによって、そう象徴バケツにしなければなりません。 造り直すのは、TSpecの順応の中にそれらがあるまでデータグラムを遅らせるのを伴います。
Shenker, et. al. Standards Track [Page 10] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[10ページ]RFC2212
Reshaping is done by combining a buffer with a token bucket and peak rate regulator and buffering data until it can be sent in conformance with the token bucket and peak rate parameters. (The token bucket regulator MUST start with its token bucket full of tokens). Under guaranteed service, the amount of buffering required to reshape any conforming traffic back to its original token bucket shape is b+Csum+(Dsum*r), where Csum and Dsum are the sums of the parameters C and D between the last reshaping point and the current reshaping point. Note that the knowledge of the peak rate at the reshapers can be used to reduce these buffer requirements (see the section on "Guidelines for Implementors" below). A network element MUST provide the necessary buffers to ensure that conforming traffic is not lost at the reshaper.
象徴バケツとピークレート監視委員にバッファを結合して、順応でそれを送ることができるまでデータをバッファリングすることによって、象徴バケツとピークレートパラメタで造り直すことをします。 (象徴バケツ監視委員は象徴でいっぱいの象徴バケツから始まらなければなりません。) 保証されたサービスの下では、元の象徴バケツ形への交通を従わせながらいずれも造り直すのに必要であるバッファリングの量はb+Csum+(Dsum*r)です。(そこでは、CsumとDsumは最後の造り直すポイントと現在の造り直すポイントの間のパラメタCとDの合計です)。 これらのバッファ要件を減らすのにリシェーパのピークレートに関する知識を使用できることに注意してください(以下の「作成者へのガイドライン」のセクションを見てください)。 ネットワーク要素は、交通を従わせるのがリシェーパで失われていないのを保証するために必要なバッファを提供しなければなりません。
NOTE: Observe that a router that is not reshaping can still
identify non-conforming datagrams (and discard them or schedule
them at lower priority) by observing when queued traffic for the
flow exceeds b+Csum+(Dsum*r).
以下に注意してください。 流れのための列に並ばせられた交通がいつb+Csum+(Dsum*r)を超えているかを観測することによって造り直されていないルータがまだ、非の従うデータグラム(それらを捨てるか、または低優先度でそれらの計画をする)を特定できるのを観測してください。
If a datagram arrives to discover the reshaping buffer is full, then the datagram is non-conforming. Observe this means that a reshaper is effectively policing too. As with a policer, the reshaper SHOULD relegate non-conforming datagrams to best effort. [If marking is available, the non-conforming datagrams SHOULD be marked]
データグラムが造り直すバッファが完全であると発見するために届くなら、データグラムは非の従うことです。 事実上、また、リシェーパが取り締まっているこの手段を観測してください。 policerのように、リシェーパSHOULDは非の従うデータグラムをベストエフォート型に左遷します。 [マークが利用可能であり、非の従うのがデータグラムSHOULDである、マークされてください、]
NOTE: As with policers, it SHOULD be possible to configure how
reshapers handle non-conforming datagrams.
以下に注意してください。 policersのようにそれ、SHOULD、リシェーパがどう非の従うデータグラムを扱うかを構成するのにおいて、可能であってください。
Note that while the large buffer makes it appear that reshapers add considerable delay, this is not the case. Given a valid TSpec that accurately describes the traffic, reshaping will cause little extra actual delay at the reshaping point (and will not affect the delay bound at all). Furthermore, in the normal case, reshaping will not cause the loss of any data.
大きいバッファがリシェーパがかなりの遅延を加えるのを現れさせますが、これがそうでないことに注意してください。 正確に交通を説明する有効なTSpecを考えて、造り直すのはほとんど造り直すポイント(そして、全く縛られた遅れに影響しない)の余分な実際の遅れを引き起こさないでしょう。 その上、正常な場合で造り直すのが、どんなデータの損失ももたらさないでしょう。
However, (typically at merge or branch points), it may happen that the TSpec is smaller than the actual traffic. If this happens, reshaping will cause a large queue to develop at the reshaping point, which both causes substantial additional delays and forces some datagrams to be treated as non-conforming. This scenario makes an unpleasant denial of service attack possible, in which a receiver who is successfully receiving a flow's traffic via best effort service is pre-empted by a new receiver who requests a reservation for the flow, but with an inadequate TSpec and RSpec. The flow's traffic will now be policed and possibly reshaped. If the policing function was chosen to discard datagrams, the best-effort receiver would stop receiving traffic. For this reason, in the normal case, policers are simply to treat non-conforming datagrams as best effort (and marking
しかしながら、(通常マージかブランチポイントの)、TSpecが実際の交通より小さいのは起こるかもしれません。 これが起こるなら、造り直すので、大きい待ち行列がともにかなりの追加遅れを引き起こす造り直すポイントで展開することを引き起こして、いくつかのデータグラムがやむを得ず非の従うとして扱われます。 このシナリオはサービス攻撃の可能な不快な否定をします。((それでは、新しい受信機のだれが流れのために予約を要求しますが、不十分なTSpecと共に要求するか、そして、RSpecによって先取りされます)ベストエフォート型サービスで流れの交通を首尾よく受けている受信機)。 流れの交通は、今、取り締まられて、ことによると造り直されるでしょう。 取り締まり機能がデータグラムを捨てるために選ばれているなら、ベストエフォート型受信機は、交通を受けるのを止めるでしょうに。 この理由で、正常な場合では、policersがベストエフォート型として単に非の従うデータグラムを扱うことになっている、(マーク
Shenker, et. al. Standards Track [Page 11] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[11ページ]RFC2212
them if marking is implemented). While this protects against denial of service, it is still true that the bad TSpec may cause queueing delays to increase.
それら、マークが実行されるかどうか、) これはサービスの否定から守りますが、悪いTSpecが待ち行列遅れを増加させるのは、まだ本当です。
NOTE: To minimize problems of reordering datagrams, reshaping
points may wish to forward a best-effort datagram from the front
of the reshaping queue when a new datagram arrives and the
reshaping buffer is full.
以下に注意してください。 新しいデータグラムが届いて、造り直すバッファが完全であるときに、データグラムを再命令するという問題を最小にするために、造り直すポイントは造り直す待ち行列の前部からベストエフォート型データグラムを進めたがっているかもしれません。
Readers should also observe that reclassifying datagrams as best
effort (as opposed to dropping the datagrams) also makes support
for elastic flows easier. They can reserve a modest token bucket
and when their traffic exceeds the token bucket, the excess
traffic will be sent best effort.
また、読者は、また、ベストエフォート型(データグラムを落とすことと対照的に)としてデータグラムに分類し直すのに弾性の流れのサポートが、より簡単になるのを観測するべきです。 彼らは穏やかな象徴バケツを予約できます、そして、それらの交通が象徴バケツを超えているとき、過剰交通を送るでしょう。ベストエフォート型。
A related issue is that at all network elements, datagrams bigger than the MTU of the network element MUST be considered non-conformant and SHOULD be classified as best effort (and will then either be fragmented or dropped according to the element's handling of best effort traffic). [Again, if marking is available, these reclassified datagrams SHOULD be marked.]
関連する問題はネットワーク要素のMTUより大きいデータグラムがすべてのネットワーク要素では、そうであるに違いないということです。非conformantとSHOULDであると考えられて、ベストエフォート型として分類されてください(ベストエフォート型交通の要素の取り扱いに応じて、次にどちらかが、断片化されるか、または落とされるでしょう)。 再びこれらはマークが利用可能であるならデータグラムSHOULDに分類し直しました。[マークされる、]
Ordering and Merging
注文と合併
TSpec's are ordered according to the following rules.
以下の規則に従って、TSpecのものを注文します。
TSpec A is a substitute ("as good or better than") for TSpec B if (1)
both the token rate r and bucket depth b for TSpec A are greater than
or equal to those of TSpec B; (2) the peak rate p is at least as
large in TSpec A as it is in TSpec B; (3) the minimum policed unit m
is at least as small for TSpec A as it is for TSpec B; and (4) the
maximum datagram size M is at least as large for TSpec A as it is for
TSpec B.
TSpec Aが代用品である、(「同じくらい良いか、より良い、」、)、(1) 象徴レートrとTSpec Aのためのバケツの深さbの両方であるならTSpec Bがそう以上である、TSpec Bのもの。 (2) ピークレートpはTSpec AでそれがTSpec Bにあるのと少なくとも同じくらい大きいです。 (3) TSpec Aに、最小の取り締まられたユニットmはそれがTSpec Bのためのものであるのと少なくとも同じくらい小さいです。 (4) そして、TSpec Aに、最大のデータグラムサイズMはそれがTSpec Bのためのものであるのと少なくとも同じくらい大きいです。
TSpec A is "less than or equal" to TSpec B if (1) both the token rate r and bucket depth b for TSpec A are less than or equal to those of TSpec B; (2) the peak rate p in TSpec A is at least as small as the peak rate in TSpec B; (3) the minimum policed unit m is at least as large for TSpec A as it is for TSpec B; and (4) the maximum datagram size M is at least as small for TSpec A as it is for TSpec B.
TSpec Aは(1) 象徴レートrとTSpec Aのためのバケツの深さbの両方がTSpec Bの、よりもの以下であるならTSpec Bより「以下か等しいです」。 (2) TSpec AのピークレートpはTSpec Bでピークレートと少なくとも同じくらいわずかです。 (3) TSpec Aに、最小の取り締まられたユニットmはそれがTSpec Bのためのものであるのと少なくとも同じくらい大きいです。 (4) そして、TSpec Aに、最大のデータグラムサイズMはそれがTSpec Bのためのものであるのと少なくとも同じくらい小さいです。
A merged TSpec may be calculated over a set of TSpecs by taking (1) the largest token bucket rate, (2) the largest bucket size, (3) the largest peak rate, (4) the smallest minimum policed unit, and (5) the smallest maximum datagram size across all members of the set. This use of the word "merging" is similar to that in the RSVP protocol [10]; a merged TSpec is one which is adequate to describe the traffic from any one of constituent TSpecs.
合併しているTSpecはセットのすべてのメンバーの向こう側に(4) 最も小さい(1) 最も大きい象徴バケツレート、(2) 最も大きいバケツサイズ、(3) 最も大きいピークレート、最小の取り締まられた単位、および(5)を取るのによるTSpecsの最も小さい最大のデータグラムサイズの1セットについて計算されるかもしれません。 「合併」という言葉のこの使用はRSVPプロトコル[10]においてそれと同様です。 合併しているTSpecは構成しているTSpecsのどれかからの交通を説明するために適切なものです。
Shenker, et. al. Standards Track [Page 12] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[12ページ]RFC2212
A summed TSpec may be calculated over a set of TSpecs by computing (1) the sum of the token bucket rates, (2) the sum of the bucket sizes, (3) the sum of the peak rates, (4) the smallest minimum policed unit, and (5) the maximum datagram size parameter.
まとめられたTSpecは、TSpecsの1セットについて(4) (1) 象徴バケツレートの合計、(2) バケツサイズの合計、(3) ピークレートの合計、最も小さい最小の取り締まられた単位、および(5) 最大のデータグラムサイズ・パラメータを計算することによって、計算されるかもしれません。
A least common TSpec is one that is sufficient to describe the traffic of any one in a set of traffic flows. A least common TSpec may be calculated over a set of TSpecs by computing: (1) the largest token bucket rate, (2) the largest bucket size, (3) the largest peak rate, (4) the smallest minimum policed unit, and (5) the largest maximum datagram size across all members of the set.
最も一般的でないTSpecは交通の流れのセットのいくらか1つの交通を説明するために十分なものです。 最も一般的でないTSpecはTSpecsの1セットについてコンピューティングによって計算されるかもしれません: (1) (2) (3) (4) 最も大きい象徴バケツレート、最も大きいバケツサイズ、最も大きいピークレート、最もわずかな最小限はセットのすべてのメンバーの向こう側に(5) 単位、および最も大きい最大のデータグラムサイズを取り締まりました。
The minimum of two TSpecs differs according to whether the TSpecs can be ordered. If one TSpec is less than the other TSpec, the smaller TSpec is the minimum. Otherwise, the minimum TSpec of two TSpecs is determined by comparing the respective values in the two TSpecs and choosing (1) the smaller token bucket rate, (2) the larger token bucket size (3) the smaller peak rate, (4) the smaller minimum policed unit, and (5) the smaller maximum datagram size.
TSpecsを注文できるかどうかに従って、2TSpecsの最小限は異なります。 1TSpecがもう片方のTSpec以下であるなら、より小さいTSpecは最小限です。 2TSpecsの最小のTSpecがさもなければ、2TSpecsでそれぞれの値を比較することによって断固としていて(1) よりわずかな象徴バケツレートを選んで、(2) より大きい象徴バケツサイズ(3)が、よりわずかなピークレートであり、(4) よりわずかな最小限取り締まられたユニット、および(5)は、より小さい最大のデータグラムサイズです。
The RSpec's are merged in a similar manner as the TSpecs, i.e. a set of RSpecs is merged onto a single RSpec by taking the largest rate R, and the smallest slack S. More precisely, RSpec A is a substitute for RSpec B if the value of reserved service rate, R, in RSpec A is greater than or equal to the value in RSpec B, and the value of the slack, S, in RSpec A is smaller than or equal to that in RSpec B.
予約されたサービス率の値、Rである、RSpec AのRSpec BによるRSpec AのRSpec Bの値、およびゆるみ、Sの値がそれ以上以下であるということであるので、RSpecのものは同じようにTSpecsとして合併されていて、すなわち、RSpecsの1セットは正確に最も大きいレートRの、そして、最もわずかなゆるみS.Moreを取ることによって、独身のRSpecに合併されていて、RSpec AはRSpec Bの代用品です。
Each network element receives a service request of the form (TSpec, RSpec), where the RSpec is of the form (Rin, Sin). The network element processes this request and performs one of two actions:
それぞれのネットワーク要素はフォーム(TSpec、RSpec)に関するサービスのリクエストを受け取ります。そこでは、RSpecがフォーム(りん、Sin)のものです。 ネットワーク要素は、この要求を処理して、2つの動作の1つを実行します:
a. it accepts the request and returns a new Rspec of the form
(Rout, Sout);
b. it rejects the request.
a. それは、要請を受け入れて、形式の新しいRspecを返します(Sout、掘ってください)。 b. それは要求を拒絶します。
The processing rules for generating the new RSpec are governed by the delay constraint:
新しいRSpecを発生させるための処理規則は遅れ規制で支配されます:
Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin,
Sout+b/総崩れする+Ctoti/総崩れする<は罪+b/りん+Ctoti/りんと等しいです。
where Ctoti is the cumulative sum of the error terms, C, for all the network elements that are upstream of and including the current element, i. In other words, this element consumes (Sin - Sout) of slack and can use it to reduce its reservation level, provided that the above inequality is satisfied. Rin and Rout MUST also satisfy the constraint:
Ctotiが誤差項の累積合計であるところでは、上流であり、電流素子、iを含んでいるすべてのネットワーク要素のために、Cです。 言い換えれば、この要素は、予約レベルを減少させるそれをゆるみを消費して(罪--Sout)、使用できます、上の不平等が満たされていれば。 また、りんとRoutは規制を満たさなければなりません:
r <= Rout <= Rin.
総崩れするr<=<はりんと等しいです。
Shenker, et. al. Standards Track [Page 13] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[13ページ]RFC2212
When several RSpec's, each with rate Rj, j=1,2..., are to be merged at a split point, the value of Rout is the maximum over all the rates Rj, and the value of Sout is the minimum over all the slack terms Sj.
レートRj、それぞれj=1がある数個RSpecのものであるときに、2です。, Routの値はすべてのレートRjの上最大です、そして、分裂ポイントで合併されることになっていてください、そして、Sjというすべての低調な期間にわたってSoutの値は最小限です。
NOTE: The various TSpec functions described above are used by
applications which desire to combine TSpecs. It is important to
observe, however, that the properties of the actual reservation
are determined by combining the TSpec with the RSpec rate (R).
以下に注意してください。 上で説明された様々なTSpec機能はTSpecsを結合することを望んでいるアプリケーションで使用されます。 しかしながら、実際の予約の特性がTSpecを結合することによってRSpecレート(R)に決定しているのを観測するのは重要です。
Because the guaranteed reservation requires both the TSpec and the
RSpec rate, there exist some difficult problems for shared
reservations in RSVP, particularly where two or more source
streams meet. Upstream of the meeting point, it would be
desirable to reduce the TSpec and RSpec to use only as much
bandwidth and buffering as is required by the individual source's
traffic. (Indeed, it may be necessary if the sender is
transmitting over a low bandwidth link).
保証された予約がTSpecとRSpecレートの両方を必要とするので、RSVPでの共有された予約のためのいくつかの難問が存在しています、特に2つ以上のソースの流れが満たされるところで。 ミーティングポイントで上流です、帯域幅とせいぜい個々のソースの交通によって必要とされるくらいのバッファリングだけを使用するためにTSpecとRSpecを減少させるのは望ましいでしょう。 (本当に、送付者が低い帯域幅リンクの上に伝わるなら、必要であるかもしれません。)
However, the RSpec's rate is set to achieve a particular delay
bound (and is notjust a function of the TSpec), so changing the
RSpec may cause the reservation to fail to meet the receiver's
delay requirements. At the same time, not adjusting the RSpec
rate means that "shared" RSVP reservations using guaranteed
service will fail whenever the bandwidth available at a particular
link is less than the receiver's requested rate R, even if the
bandwidth is adequate to support the number of senders actually
using the link. At this time, this limitation is an open problem
in using the guaranteed service with RSVP.
しかしながら、RSpecのレートが制限(notjustはTSpecの機能である)にされるのであって、したがって、RSpecが予約に受信機の遅れ必要条件を満たさせることができないように変化している特定の遅れを達成するように設定されます。 同時に、RSpecレートを調整しないのは、使用が特定のリンクで利用可能な帯域幅が受信機の以下であるときはいつも、失敗するのがサービスに保証される「共有された」RSVPの予約がレートRを要求したことを意味します、帯域幅が実際にリンクを使用することで送付者の数を支持するために適切であっても。 このとき、この制限はRSVPとの保証されたサービスを利用することにおいて開いている問題です。
Guidelines for Implementors
作成者へのガイドライン
This section discusses a number of important implementation issues in no particular order.
このセクションは特に決まった順番でなく多くの重要な導入問題について論じます。
It is important to note that individual subnetworks are network elements and both routers and subnetworks MUST support the guaranteed service model to achieve guaranteed service. Since subnetworks typically are not capable of negotiating service using IP-based protocols, as part of providing guaranteed service, routers will have to act as proxies for the subnetworks they are attached to.
個々のサブネットワークがネットワーク要素であり、ルータとサブネットワークの両方が保証されたサービスを達成するために保証されたサービスモデルをサポートしなければならないことに注意するのは重要です。 サブネットワークがIPベースのプロトコルを使用することでサービスを通常交渉できないとき、提供の一部がアフターサービスを保証したので、ルータはそれらが付けられているサブネットワークのためのプロキシとして務めなければならないでしょう。
In some cases, this proxy service will be easy. For instance, on leased line managed by a WFQ scheduler on the upstream node, the proxy need simply ensure that the sum of all the flows' RSpec rates does not exceed the bandwidth of the line, and needs to advertise the rate-based and non-rate-based delays of the link as the values of C and D.
いくつかの場合、この代理業務は簡単になるでしょう。 例えば、プロキシは、上流のノードの上のWFQスケジューラによって管理された専用線の上では、すべての流れのRSpecレートの合計が線の帯域幅を超えていないのを単に保証しなければならなくて、CとDの値としてリンクのレートベースの、そして、非レートベースの遅れの広告を出す必要があります。
Shenker, et. al. Standards Track [Page 14] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[14ページ]RFC2212
In other cases, this proxy service will be complex. In an ATM network, for example, it may require establishing an ATM VC for the flow and computing the C and D terms for that VC. Readers may observe that the token bucket and peak rate used by guaranteed service map directly to the Sustained Cell Rate, Burst Size, and Peak Cell Rate of ATM's Q.2931 QoS parameters for Variable Bit Rate traffic.
他の場合では、この代理業務は複雑になるでしょう。 ATMネットワークでは、例えば、それは、流れのためにATM VCを設立して、そのVCのためにCとD用語を計算するのを必要とするかもしれません。 読者は、保証されたサービスで使用される象徴バケツとピークレートが直接Variable Bit RateのためのATMのQ.2931 QoSパラメタのSustained Cell Rate、Burst Size、およびPeak Cell Rateに交通を写像するのを観測するかもしれません。
The assurance that datagrams will not be lost is obtained by setting the router buffer space B to be equal to the token bucket b plus some error term (described below).
ルータバッファ領域Bに等しいように象徴バケツbといつかの誤差項(以下で、説明される)まで設定することによって、データグラムがなくされないという保証を得ます。
Another issue related to subnetworks is that the TSpec's token bucket rates measure IP traffic and do not (and cannot) account for link level headers. So the subnetwork network elements MUST adjust the rate and possibly the bucket size to account for adding link level headers. Tunnels MUST also account for the additional IP headers that they add.
サブネットワークに関連する別の問題はTSpecの象徴バケツレートがリンク・レベルヘッダーのためにIP交通を測定して、どんな(and cannot)アカウントもしないということです。 それで、サブネットワークネットワーク要素は、リンク・レベルヘッダーを加えるのを説明するようにレートとことによるとバケツサイズを調整しなければなりません。 また、Tunnelsは彼らが加える追加IPヘッダーの原因にならなければなりません。
For datagram networks, a maximum header rate can usually be computed by dividing the rate and bucket sizes by the minimum policed unit. For networks that do internal fragmentation, such as ATM, the computation may be more complex, since one MUST account for both per-fragment overhead and any wastage (padding bytes transmitted) due to mismatches between datagram sizes and fragment sizes. For instance, a conservative estimate of the additional data rate imposed by ATM AAL5 plus ATM segmentation and reassembly is
データグラム・ネットワークにおいて、通常、最小の取り締まられた単位でレートとバケツサイズを分割することによって、最大のヘッダーレートを計算できます。 ATMなどの内部の断片化をするネットワークには、計算は、より複雑であるかもしれません、データグラムサイズと断片サイズの間のミスマッチのため、1断片あたりのオーバーヘッドとどんな消耗の両方(バイトを水増しするのは伝わった)も説明しなければならないので。 例えば、ATM AAL5、ATM分割、および再アセンブリによって課された追加データ信号速度の内輪な見積りはそうです。
((r/48)*5)+((r/m)*(8+52))
((r/48)*5) +(r/m)*(8 +52))
which represents the rate divided into 48-byte cells multiplied by the 5-byte ATM header, plus the maximum datagram rate (r/m) multiplied by the cost of the 8-byte AAL5 header plus the maximum space that can be wasted by ATM segmentation of a datagram (which is the 52 bytes wasted in a cell that contains one byte). But this estimate is likely to be wildly high, especially if m is small, since ATM wastage is usually much less than 52 bytes. (ATM implementors should be warned that the token bucket may also have to be scaled when setting the VC parameters for call setup and that this example does not account for overhead incurred by encapsulations such as those specified in RFC 1483).
5バイトのATMヘッダーに掛けられた48バイトのセルに分割されたレート、最大の8バイトのAAL5ヘッダーの費用が掛けられたデータグラムレート(r/m)、およびデータグラム(どれが52バイトであるかは1バイトを含むセルの中でむだになった)のATM分割で浪費できる最大領域を表します。 しかし、この見積りはむやみやたらに高い傾向があります、特にmが小さいなら、ATM消耗が通常はるかに52バイト未満であるので。 (ATM作成者はまた、呼び出しセットアップのためのVCパラメタを設定するとき象徴バケツがスケーリングされなければならないかもしれなくて、この例がRFC1483で指定されたものなどのカプセル化によって被られたオーバーヘッドを説明しないのに注意されるべきです。)
To ensure no loss, network elements will have to allocate some buffering for bursts. If every hop implemented the fluid model perfectly, this buffering would simply be b (the token bucket size). However, as noted in the discussion of reshaping earlier, implementations are approximations and we expect that traffic will become more bursty as it goes through the network. However, as with
損失を全く確実にしないように、ネットワーク要素は炸裂のためのいくつかのバッファリングを割り当てなければならないでしょう。 あらゆるホップが流体モデルを完全に実行するなら、このバッファリングは単にb(象徴バケツサイズ)でしょうに。 しかしながら、より早く造り直す議論で注意されるように、実現は近似です、そして、私たちはネットワークに直面しているのに応じて交通が、より多くのburstyになると予想します。 with
Shenker, et. al. Standards Track [Page 15] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[15ページ]RFC2212
shaping the amount of buffering required to handle the burstiness is bounded by b+Csum+Dsum*R. If one accounts for the peak rate, this can be further reduced to
バッファリングの量がburstinessを扱うのを必要とした形成はb+Csum+Dsum*Rで境界があります。 ピークへの1つのアカウントが評価するなら、さらにこれに減少できます。
M + (b-M)(p-X)/(p-r) + (Csum/R + Dsum)X
M+(b-M)(p-X)/(p-r)+(Csum/R+Dsum)X
where X is set to r if (b-M)/(p-r) is less than Csum/R+Dsum and X is R if (b-M)/(p-r) is greater than or equal to Csum/R+Dsum and p>R; otherwise, X is set to p. This reduction comes from the fact that the peak rate limits the rate at which the burst, b, can be placed in the network. Conversely, if a non-zero slack term, Sout, is returned by the network element, the buffer requirements are increased by adding Sout to Dsum.
Xが(b-M)/(p-r)であるならどこにrに設定されるかは、(b-M)/(p-r)がR以上であるならCsum/R+DsumとXがRであるより少ないCsum/R+Dsumとp>Rです。 さもなければ、Xはpに設定されます。 この減少はピークレートが炸裂(b)をネットワークに置くことができる速度を制限するという事実から来ます。 逆に、ネットワーク要素で、非ゼロの低調な用語(Sout)を返すなら、DsumにSoutを加えることによって、バッファ要件を増加させます。
While sending applications are encouraged to set the peak rate parameter and reshaping points are required to conform to it, it is always acceptable to ignore the peak rate for the purposes of computing buffer requirements and end-to-end delays. The result is simply an overestimate of the buffering and delay. As noted above, if the peak rate is unknown (and thus potentially infinite), the buffering required is b+Csum+Dsum*R. The end-to-end delay without the peak rate is b/R+Ctot/R+Dtot.
送付アプリケーションがピークレートパラメタを設定するよう奨励されて、造り直すポイントはそれに従わなければなりませんが、バッファ要件と終わりから終わりへの遅れを計算する目的のピークレートを無視するのはいつも許容できます。 結果は単にバッファリングと遅れの過大評価です。 上で述べたように、ピークレートが未知と(その結果、潜在的に無限)であるなら、必要であるバッファリングはb+Csum+Dsum*Rです。 終わりから終わりへのピークレートのない遅れはb/R+Ctot/R+Dtotです。
The parameter D for each network element SHOULD be set to the maximum datagram transfer delay variation (independent of rate and bucket size) through the network element. For instance, in a simple router, one might compute the difference between the worst case and best case times it takes for a datagram to get through the input interface to the processor, and add it to any variation that may occur in how long it would take to get from the processor to the outbound link scheduler (assuming the queueing schemes work correctly).
最大のデータグラム転送遅れ変化へのセットがネットワーク要素を通して(レートとバケツサイズから独立する)であったなら、それぞれのためのパラメタDは要素SHOULDをネットワークでつなぎます。 例えば、簡単なルータでは、人は、プロセッサからアウトバウンドリンクスケジューラに得るために最悪の場合とデータグラムが入力インタフェースをプロセッサへ通り抜けて、どれくらいかかるだろうかに起こるどんな変化にもそれを加えるのに要する中で最も良いケース時間の違いを計算するかもしれません(待ち行列計画が働きであると正しく仮定して)。
For weighted fair queueing in a datagram environment, D is set to the link MTU divided by the link bandwidth, to account for the possibility that a packet arrives just as a maximum-sized packet begins to be transmitted, and that the arriving packet should have departed before the maximum-sized packet. For a frame-based, slotted system such as Stop and Go queueing, D is the maximum number of slots a datagram may have to wait before getting a chance to be transmitted.
データグラム環境における荷重している公正な待ち行列において、Dはリンク帯域幅がちょうど最大サイズのパケットが伝えられ始めるようにパケットが到着して、到着パケットが最大サイズのパケットの前で出発するはずであった可能性を説明するために割られたリンクMTUに設定されます。 StopやGo待ち行列などのフレームベースの、そして、溝をつけられたシステムのために、Dはデータグラムが伝えられるべき機会を得る前に待つために持っているかもしれないスロットの最大数です。
Note that multicasting may make determining D more difficult. In many subnets, ATM being one example, the properties of the subnet may depend on the path taken from the multicast sender to the receiver. There are a number of possible approaches to this problem. One is to
マルチキャスティングでDを決定するのが、より難しくなるかもしれないことに注意してください。 多くのサブネット、1つの例であるATMでは、サブネットの特性はマルチキャスト送付者から受信機まで取られた経路に依存するかもしれません。この問題への多くの可能なアプローチがあります。 1つがあります。
Shenker, et. al. Standards Track [Page 16] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[16ページ]RFC2212
choose a representative latency for the overall subnet and set D to the (non-negative) difference from that latency. Another is to estimate subnet properties at exit points from the subnet, since the exit point presumably is best placed to compute the properties of its path from the source.
総合的なサブネットのための代表している潜在を選んでください、そして、その潜在から(非否定的)の違いにDを設定してください。 別のものはサブネットからサブネットの特性をエキジットポイントと見積もることになっています、おそらく、ソースから経路の特性を計算するためにエキジットポイントを置くのが最も良いので。
NOTE: It is important to note that there is no fixed set of rules
about how a subnet determines its properties, and each subnet
technology will have to develop its own set of procedures to
accurately compute C and D and slack values.
以下に注意してください。 サブネットが特性を決定して、それぞれのサブネット技術が正確にCとDを計算するためにそれ自身の手順のセットをどう発展させなければならないかに関する規則と低調な値の固定セットが全くないことに注意するのは重要です。
D is intended to be distinct from the latency through the network element. Latency is the minimum time through the device (the speed of light delay in a fiber or the absolute minimum time it would take to move a packet through a router), while parameter D is intended to bound the variability in non-rate-based delay. In practice, this distinction is sometimes arbitrary (the latency may be minimal) -- in such cases it is perfectly reasonable to combine the latency with D and to advertise any latency as zero.
Dを潜在からネットワーク要素まで異ならせることを意図します。 潜在は装置(ファイバーの軽い遅れの速度か絶対最小値わざわざそれがルータを通ってパケットが動く)を通した最小の時間です、パラメタDは非レートベースの可変性が遅らせるバウンドに意図しますが。 実際には、この区別は時々任意です(潜在は最小限であるかもしれません)--そのような場合それは潜在をDに結合して、ゼロとしてどんな潜在も広告を出すのが完全に妥当です。
NOTE: It is implicit in this scheme that to get a complete
guarantee of the maximum delay a packet might experience, a user
of this service will need to know both the queueing delay
(provided by C and D) and the latency. The latency is not
advertised by this service but is a general characterization
parameter (advertised as specified in [8]).
以下に注意してください。 この計画では、パケットが経験するかもしれない最大の遅れの完全な保証を得るのに、このサービスのユーザが、待ち行列遅れ(CとDで、提供する)と潜在の両方を知る必要があるのは、暗黙です。 潜在は、このサービスで広告を出しませんが、一般的性質パラメタです。(指定されるとして、[8])では、広告を出します。
However, even if latency is not advertised, this service can still
be used. The simplest approach is to measure the delay
experienced by the first packet (or the minimum delay of the first
few packets) received and treat this delay value as an upper bound
on the latency.
しかしながら、潜在が広告に掲載されないでも、まだこのサービスを利用できます。 最も簡単なアプローチは、受け取られた最初のパケット(または、わずかな最初のパケットの最小の遅れ)によって経験された遅れを測定して、潜在でこの遅れ値を上限として扱うことです。
The parameter C is the data backlog resulting from the vagaries of how a specific implementation deviates from a strict bit-by-bit service. So, for instance, for datagramized weighted fair queueing, C is set to M to account for packetization effects.
パラメタCは特定の実現がビット・サービスによる厳しいビットからどう逸れるかに関する気まぐれから生じるデータ予備です。 そのように、そして、例えば、datagramized荷重している公正な待ち行列において、MにCがpacketization効果の原因になるように設定されます。
If a network element uses a certain amount of slack, Si, to reduce the amount of resources that it has reserved for a particular flow, i, the value Si SHOULD be stored at the network element. Subsequently, if reservation refreshes are received for flow i, the network element MUST use the same slack Si without any further computation. This guarantees consistency in the reservation process.
ネットワーク要素が、ある量のゆるみ、Siを使用するなら、それが特定の流れ、iのために予約したリソースの量、値のSi SHOULDを減少させるには、ネットワーク要素で、格納されてください。 予約はリフレッシュします。次に、流れi、ネットワーク要素が同じゆるみSiを使用しなければならないので、少しもさらなる計算なしで受けます。 これは予約の過程による一貫性を保証します。
Shenker, et. al. Standards Track [Page 17] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[17ページ]RFC2212
As an example for the use of the slack term, consider the case where the required end-to-end delay, Dreq, is larger than the maximum delay of the fluid flow system. The latter is obtained by setting R=r in the fluid delay formula (for stability, R>=r must be true), and is given by
低調な用語の使用のための例と、終わりから終わりへの必要な遅れ(Dreq)が流体流れ作業の最大の遅れより大きいケースを考えてください。 後者を流体遅れ公式(安定性において、R>=rは本当であるに違いない)にR=rをはめ込むことによって得て、与えます。
b/r + Ctot/r + Dtot.
b/r+Ctot/r+Dtot。
In this case the slack term is
この場合存在という低調な用語
S = Dreq - (b/r + Ctot/r + Dtot).
SはDreqと等しいです--(b/r+Ctot/r+Dtot。)
The slack term may be used by the network elements to adjust their local reservations, so that they can admit flows that would otherwise have been rejected. A network element at an intermediate network element that can internally differentiate between delay and rate guarantees can now take advantage of this information to lower the amount of resources allocated to this flow. For example, by taking an amount of slack s <= S, an RCSD scheduler [5] can increase the local delay bound, d, assigned to the flow, to d+s. Given an RSpec, (Rin, Sin), it would do so by setting Rout = Rin and Sout = Sin - s.
低調な用語はネットワーク要素によって使用されて、地元の予約を調整するかもしれません、彼らがそうでなければ拒絶された流れを認めることができるように。 内部的に遅れとレート保証を区別できる中間ネットワーク要素のネットワーク要素は、現在、この流れに割り当てられたリソースの量を下げるのにこの情報を利用できます。 例えば、ゆるみs<=Sの量を取ることによって、RCSDスケジューラ[5]は地方の遅れバウンド、流れに割り当てられたdを増加させることができます、d+sに。 RSpec、(りん、Sin)と考えて、りんとSout=が犯すRout=を設定することによって、そうするでしょう--s。
Similarly, a network element using a WFQ scheduler can decrease its local reservation from Rin to Rout by using some of the slack in the RSpec. This can be accomplished by using the transformation rules given in the previous section, that ensure that the reduced reservation level will not increase the overall end-to-end delay.
同様に、WFQスケジューラを使用するネットワーク要素は、RSpecで何らかのゆるみを使用することによって、地方のりんからRoutまでの予約を減少させることができます。 前項で与えられた変換規則を使用することによって、これを達成できて、それは、減少している予約レベルが終わりから終わりへの総合的な遅れを増加させないのを確実にします。
Evaluation Criteria
評価基準
The scheduling algorithm and admission control algorithm of the element MUST ensure that the delay bounds are never violated and datagrams are not lost, when a source's traffic conforms to the TSpec. Furthermore, the element MUST ensure that misbehaving flows do not affect the service given to other flows. Vendors are encouraged to formally prove that their implementation is an approximation of the fluid model.
要素のスケジューリングアルゴリズムと入場コントロールアルゴリズムは遅れ領域が決して違反されないで、またデータグラムが無くならないのを確実にしなければなりません、ソースの交通がTSpecに従うと。 その上、要素は、ふらちな事する流れが他の流れに与えられたサービスに影響しないのを確実にしなければなりません。 業者が、彼らの実現が流体モデルの近似であると正式に立証するよう奨励されます。
Examples of Implementation
実現に関する例
Several algorithms and implementations exist that approximate the fluid model. They include Weighted Fair Queueing (WFQ) [2], Jitter- EDD [3], Virtual Clock [4] and a scheme proposed by IBM [5]. A nice theoretical presentation that shows these schemes are part of a large class of algorithms can be found in [6].
流体モデルに近似するいくつかのアルゴリズムと実現が存在しています。 彼らはIBM[5]によって提案されたWeighted Fair Queueing(WFQ)[2]、Jitter- EDD[3]、Virtual Clock[4]、および計画を含んでいます。 [6]でこれらの計画が多人数のクラスのアルゴリズムの一部であることを示す楽しい理論上のプレゼンテーションは見つけることができます。
Shenker, et. al. Standards Track [Page 18] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[18ページ]RFC2212
Examples of Use
使用に関する例
Consider an application that is intolerant of any lost or late datagrams. It uses the advertised values Ctot and Dtot and the TSpec of the flow, to compute the resulting delay bound from a service request with rate R. Assuming R < p, it then sets its playback point to [(b-M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot.
どんな無くなっているか遅いデータグラムでも偏狭なアプリケーションを考えてください。それはレートR.Assuming R<pでサービスのリクエストから縛られた結果として起こる遅れを計算するのに流れの広告を出している値のCtot、Dtot、およびTSpecを使用して、次に、+ 再生ポイントから(b-M)への/R*(p-R)/(p-r](M+Ctot)/R+Dtotを設定します。
Security Considerations
セキュリティ問題
This memo discusses how this service could be abused to permit denial of service attacks. The service, as defined, does not allow denial of service (although service may degrade under certain circumstances).
このメモはサービス不能攻撃を可能にするためにどうこのサービスを乱用できたかについて議論します。 定義されるサービスはサービスの否定を許しません(サービスが、ある状況で下がるかもしれませんが)。
Appendix 1: Use of the Guaranteed service with RSVP
付録1: RSVPとのGuaranteedサービスの使用
The use of guaranteed service in conjunction with the RSVP resource reservation setup protocol is specified in reference [9]. This document gives the format of RSVP FLOWSPEC, SENDER_TSPEC, and ADSPEC objects needed to support applications desiring guaranteed service and gives information about how RSVP processes those objects. The RSVP protocol itself is specified in Reference [10].
RSVP資源予約セットアッププロトコルに関連した保証されたサービスの使用は参照[9]で指定されます。 このドキュメントは、保証されたサービスを望んでいるアプリケーションをサポートするのが必要であるRSVP FLOWSPEC、SENDER_TSPEC、およびADSPECオブジェクトの書式を与えて、RSVPがどうそれらのオブジェクトを処理するかに関して知らせます。 RSVPプロトコル自体はReference[10]で指定されます。
References
参照
[1] Shenker, S., and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, September 1997.
[1] Shenker、S.とJ.Wroclawski、「ネットワーク要素サービス仕様テンプレート」、RFC2216、1997年9月。
[2] A. Demers, S. Keshav and S. Shenker, "Analysis and Simulation of a Fair Queueing Algorithm," in Internetworking: Research and Experience, Vol 1, No. 1., pp. 3-26.
インターネットワーキングにおける[2]A.Demersと、S.KeshavとS.Shenkerと、「公正な待ち行列アルゴリズムの分析とシミュレーション」: 研究とExperience、Vol1、No.1.、ページ 3-26.
[3] L. Zhang, "Virtual Clock: A New Traffic Control Algorithm for Packet Switching Networks," in Proc. ACM SIGCOMM '90, pp. 19-29.
[3] L.チャン、「仮想の時計:」 Procの「パケット交換網のための新しいトラフィックコントロールアルゴリズム。」 ACM SIGCOMM90年、ページ 19-29.
[4] D. Verma, H. Zhang, and D. Ferrari, "Guaranteeing Delay Jitter Bounds in Packet Switching Networks," in Proc. Tricomm '91.
[4] D.Verma、H.チャン、およびD.フェラーリ、Procの「パケット交換網で遅れジター領域を保証します。」 Tricomm91年。
[5] L. Georgiadis, R. Guerin, V. Peris, and K. N. Sivarajan, "Efficient Network QoS Provisioning Based on per Node Traffic Shaping," IBM Research Report No. RC-20064.
[5] L.ジョージアディス、R.ゲラン、V.ペリス、およびK.N.Sivarajan、「形成ノードトラフィックあたりに基づいた効率的なネットワークQoSの食糧を供給する」IBM研究レポートNo. RC-20064。
[6] P. Goyal, S.S. Lam and H.M. Vin, "Determining End-to-End Delay Bounds in Heterogeneous Networks," in Proc. 5th Intl. Workshop on Network and Operating System Support for Digital Audio and Video, April 1995.
[6] P.Goyal、S.S.ラム、およびH.M.ヴィン、Procで「終わりから終わりへの遅れを決定するのは異機種ネットワークでバウンドしています」。 第5Intl。 ネットワークに関するワークショップとデジタル・オーディオとビデオ、1995年4月のオペレーティングシステムサポート。
Shenker, et. al. Standards Track [Page 19] RFC 2212 Guaranteed Quality of Service September 1997
et Shenker、アル。 サービスの質1997年9月に保証された標準化過程[19ページ]RFC2212
[7] A.K.J. Parekh, A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks, MIT Laboratory for Information and Decision Systems, Report LIDS-TH-2089, February 1992.
[7] A.K.J.Parekh(統合サービスネットワークにおけるフロー制御、情報のためのMIT研究所、および決定システムへの一般化されたプロセッサ共有アプローチ)が報告する、ふた、2089日、2月1992日
[8] Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[8]Shenker、S.、およびJ.Wroclawski、「統合サービスネットワークElementsへの一般的性質パラメタ」、RFC2215、1997年9月。
[9] Wroclawski, J., "Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[9]Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
[10] Braden, R., Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[10] ブレーデン、R.、エド、etアル、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、9月1997日
Authors' Addresses
作者のアドレス
Scott Shenker Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304-1314
コヨーテヒル・Roadパロアルト、スコットShenkerゼロックスPARC3333カリフォルニア94304-1314
Phone: 415-812-4840 Fax: 415-812-4471 EMail: shenker@parc.xerox.com
以下に電話をしてください。 415-812-4840 Fax: 415-812-4471 メールしてください: shenker@parc.xerox.com
Craig Partridge BBN 2370 Amherst St Palo Alto CA 94306
クレイグヤマウズラBBN2370アマースト通りパロアルトカリフォルニア 94306
EMail: craig@bbn.com
メール: craig@bbn.com
Roch Guerin IBM T.J. Watson Research Center Yorktown Heights, NY 10598
ニューヨーク RochゲランIBM T.J.ワトソン研究所ヨークタウンの高さ、10598
Phone: 914-784-7038 Fax: 914-784-6318 EMail: guerin@watson.ibm.com
以下に電話をしてください。 914-784-7038 Fax: 914-784-6318 メールしてください: guerin@watson.ibm.com
Shenker, et. al. Standards Track [Page 20]
et Shenker、アル。 標準化過程[20ページ]
一覧
スポンサーリンク
