RFC2211 日本語訳
2211 Specification of the Controlled-Load Network Element Service. J.Wroclawski. September 1997. (Format: TXT=46523 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Wroclawski Request For Comments: 2211 MIT LCS Category: Standards Track September 1997
Wroclawskiがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2211年のMIT LCSカテゴリ: 標準化過程1997年9月
Specification of the Controlled-Load Network Element 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 specifies the network element behavior required to deliver Controlled-Load service in the Internet. Controlled-load service provides the client data flow with a quality of service closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded.
このメモは振舞いがインターネットでControlled-負荷サービスを提供するのを必要としたネットワーク要素を指定します。 制御負荷サービスは、密接に、同じ流れが降ろされたネットワーク要素から受けるQoSに近似するサービスの質をクライアントデータフローに提供しますが、ネットワーク要素が積みすぎられるとき、このサービスが受けられさえすることを保証するのに容量(入場)コントロールを使用します。
1. Introduction
1. 序論
This document defines the requirements for network elements that support the Controlled-Load 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.
このドキュメントはControlled-負荷がサービスであるとサポートするネットワーク要素のための要件を定義します。 このメモは振舞いがIPインターネットワークにおける様々なサービスの品質をサポートするのを必要としたネットワーク要素を指定する一連のドキュメントの1つです。 これらのドキュメントで説明されたサービスは世界的なインターネットとプライベートアイピーネットワークで役に立ちます。
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プロトコルファミリーの中のサービスの品質の仕様に関する定義と追加情報のためのそのドキュメントを参照してください。
Wroclawski Standards Track [Page 1] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[1ページ]RFC2211
2. End-to-End Behavior
2. 終わりから終わりへの振舞い
The end-to-end behavior provided to an application by a series of network elements providing controlled-load service tightly approximates the behavior visible to applications receiving best- effort service *under unloaded conditions* from the same series of network elements. Assuming the network is functioning correctly, these applications may assume that:
制御負荷サービスがしっかりアプリケーションに目に見える振舞いに近似するなら、終わりから終わりへの振舞いは、最も良い取り組みサービス*を同じシリーズのネットワーク要素から降ろされた状態*の下に受けながら、一連のネットワーク要素に従ったアプリケーションに提供されました。 ネットワークが正しく機能していると仮定する場合、これらのアプリケーションは、以下のことと仮定するかもしれません。
- A very high percentage of transmitted packets will be
successfully delivered by the network to the receiving end-nodes.
(The percentage of packets not successfully delivered must closely
approximate the basic packet error rate of the transmission
medium).
- 非常に高い百分率の伝えられたパケットがネットワークによって首尾よく受信エンドノードに提供されるでしょう。 (首尾よく提供されなかったパケットの割合は密接にトランスミッション媒体の基本的なパケット誤り率に近似しなければなりません。)
- The transit delay experienced by a very high percentage of the
delivered packets will not greatly exceed the minimum transmit
delay experienced by any successfully delivered packet. (This
minimum transit delay includes speed-of-light delay plus the fixed
processing time in routers and other communications devices along
the path.)
- 非常に高い百分率の提供されたパケットによって経験されたトランジット遅れは最小限をはるかに超えないでしょう。パケットが首尾よく提供されたいずれによっても経験された遅れを伝えてください。 (この最小のトランジット遅れは経路に沿ってルータと他のコミュニケーションデバイスに光速遅れと固定処理時間を含んでいます。)
To ensure that these conditions are met, clients requesting controlled-load service provide the intermediate network elements with a estimation of the data traffic they will generate; the TSpec. In return, the service ensures that network element resources adequate to process traffic falling within this descriptive envelope will be available to the client. Should the client's traffic generation properties fall outside of the region described by the TSpec parameters, the QoS provided to the client may exhibit characteristics indicative of overload, including large numbers of delayed or dropped packets. The service definition does not require that the precise characteristics of this overload behavior match those which would be received by a best-effort data flow traversing the same path under overloaded conditions.
これらの条件が満たされるのを保証するために、制御負荷サービスを要求するクライアントはそれらが生成するデータ通信量に関する見積りを中間ネットワーク要素に提供します。 TSpec。 代わりに、サービスは、この描写的である封筒の中に下がるトラフィックを処理するために適切なネットワーク要素リソースがクライアントにとって利用可能になるのを確実にします。 多くの遅らせられたか下げられたパケットを含んでいて、オーバーロードを暗示した特性がクライアントに展示会に出品されているかもしれないなら領域の外部がTSpecパラメタ、QoSで説明したクライアントのトラフィック特性の秋の発生はそうするべきです。 サービス定義は、このオーバーロードの振舞いの正確な特性が積みすぎられた条件のもとで同じ経路を横断しながらベストエフォート型データフローによって受け取られるものに合っているのを必要としません。
NOTE: In this memo, the term "unloaded" is used in the sense of
"not heavily loaded or congested" rather than in the sense of "no
other network traffic whatsoever".
以下に注意してください。 このメモでは、「降ろす」という用語は「いかなる他のネットワークトラフィックがありませんも」の意味でというよりむしろ「ずっしりとロードされないか、または充血していないこと」の意味で使用されます。
3. Motivation
3. 動機
The controlled load service is intended to support a broad class of applications which have been developed for use in today's Internet, but are highly sensitive to overloaded conditions. Important members of this class are the "adaptive real-time applications" currently
制御負荷サービスが広いクラスの今日のインターネットでの使用のために開発されましたが、積みすぎられた状態に非常に敏感なアプリケーションをサポートすることを意図します。 現在、このクラスの重要なメンバーは「適応型のリアルタイムのアプリケーション」です。
Wroclawski Standards Track [Page 2] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[2ページ]RFC2211
offered by a number of vendors and researchers. These applications have been shown to work well on unloaded nets, but to degrade quickly under overloaded conditions. A service which mimics unloaded nets serves these applications well.
多くのベンダーと研究者によって提供されます。 これらのアプリケーションはしかし、降ろされるところでうまくいくのが積みすぎられた条件のもとですばやく退行するために網状になるのが示されました。 物真似が降ろしたサービスはこれらのアプリケーションをサーブによく網で覆います。
The controlled-load service is intentionally minimal, in that there are no optional functions or capabilities in the specification. The service offers only a single function, and system and application designers can assume that all implementations will be identical in this respect.
仕様にはどんな任意の機能も能力もないので、制御負荷サービスは故意に最小限です。 サービスはただ一つの機能だけを申し出ます、そして、システムとアプリケーション設計者はすべての実装がこの点で同じになると仮定できます。
Internally, the controlled-load service is suited to a wide range of implementation techniques, including evolving scheduling and admission control algorithms that allow implementations to be highly efficient in the use of network resources. It is equally amenable to extremely simple implementation in circumstances where maximum utilization of network resources is not the only concern.
本質的に、制御負荷サービスはさまざまな実装のテクニックに合っています、スケジューリングと実装がネットワーク資源の使用で高能率的であることを許容する入場コントロールアルゴリズムを発展するのを含んでいて。 それは等しくネットワーク資源の最大の利用が唯一の関心でない事情の非常に簡単な実装に従順です。
4. Network Element Data Handling Requirements
4. ネットワーク要素データハンドリング要件
Each network element accepting a request for controlled-load service must ensure that adequate bandwidth and packet processing resources are available to handle the requested level of traffic, as given by the requestor's TSpec. This must be accomplished through active admission control. All resources important to the operation of the network element must be considered when admitting a request. Common examples of such resources include link bandwidth, router or switch port buffer space, and computational capacity of the packet forwarding engine.
制御負荷サービスのために申し込みに応じるそれぞれのネットワーク要素は、適切な帯域幅とパケット処理リソースが要求されたレベルのトラフィックを扱うために利用可能であることを確実にしなければなりません、要請者のTSpecによって与えられているように。 動作入場制御でこれを達成しなければなりません。 要求を認めるとき、ネットワーク要素の操作に重要なすべてのリソースを考えなければなりません。 そのようなリソースの一般的な例はパケット推進エンジンのリンク帯域幅かルータかスイッチポートバッファ領域と、コンピュータの容量を含んでいます。
The controlled-load service does not accept or make use of specific target values for control parameters such as delay or loss. Instead, acceptance of a request for controlled-load service is defined to imply a commitment by the network element to provide the requestor with service closely equivalent to that provided to uncontrolled (best-effort) traffic under lightly loaded conditions.
制御負荷サービスは、遅れか損失などの管理パラメータに特定の目標値を受け入れもしませんし、利用もしません。 代わりに、制御負荷サービスを求める要求の承認は、ネットワーク要素に従って密接に軽くロードされた状態の非制御(ベストエフォート型)のトラフィックに提供されたそれに同等なサービスを要請者に提供するために委任を含意するために定義されます。
The definition of "closely equivalent to unloaded best-effort service" is necessarily imprecise. It is easiest to define this quality of service by describing the events which are expected to *not* occur with any frequency. A flow receiving controlled-load service at a network element may expect to experience:
「密接に降ろされたベストエフォート型サービスに同等」の定義は必ず不正確です。 *でないのが起こる*に予想されるイベントについて説明するのによるどんな頻度にもこのサービスの質を定義するのは最も簡単です。 ネットワーク要素で制御負荷サービスを受ける流れは、以下を経験すると予想するかもしれません。
Wroclawski Standards Track [Page 3] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[3ページ]RFC2211
- Little or no average packet queueing delay over all timescales
significantly larger than the "burst time". The burst time is
defined as the time required for the flow's maximum size data burst
to be transmitted at the flow's requested transmission rate, where
the burst size and rate are given by the flow's TSpec, as described
below.
- ほとんど「炸裂時間」よりかなり大きいすべてのスケールの上の平均したパケット待ち行列遅れがありません。 炸裂時間は放出量とレートが流れのTSpecによって与えられている流れの要求された通信速度で伝えられるために押し破かれた流れの最大サイズデータに必要である時間と定義されます、以下で説明されるように。
- Little or no congestion loss over all timescales significantly
larger than the "burst time" defined above. In this context,
congestion loss includes packet losses due to shortage of any
required processing resource, such as buffer space or link
bandwidth. Although occasional congestion losses may occur, any
substantial sustained loss represents a failure of the admission
control algorithm.
- ほとんど上で定義された「炸裂時間」よりかなり大きいすべてのスケールの上の混雑の損失がありません。 このような関係においては、混雑の損失はどんな必要な処理リソースの不足によるパケット損失も含んでいます、バッファ領域やリンク帯域幅のように。 時々の混雑の損失は発生するかもしれませんが、どんなかなりの持続している損失も入場コントロールアルゴリズムの失敗を表します。
The basic effect of this language is to establish an expectation on the *duration* of a disruption in delivery service. Events of shorter duration are viewed as statistical effects which may occur in normal operation. Events of longer duration are indicative of failure to allocate adequate capacity to the controlled-load flow.
この言語の基本的な効果はデリバリ・サービスにおける分裂の*持続時間*で期待を確立することです。 より短い持続時間のイベントは通常の操作で起こるかもしれない統計的な効果として見なされます。 より長い持続時間のイベントは制御負荷流動に適切な容量を割り当てないことを暗示しています。
A network element may employ statistical approaches to decide whether adequate capacity is available to accept a service request. For example, a network element processing a number of flows with long- term characteristics predicted through measurement of past behavior may be able to overallocate its resources to some extent without reducing the level of service delivered to the flows.
ネットワーク要素は、適切な容量がサービスのリクエストを受け入れるために有効であるかどうか決めるのに統計的なアプローチを使うかもしれません。 例えば、長い用語の特性に従った多くの流れを処理するネットワーク要素は、リソースがサービスのレベルを減少させないで流れにある程度配送されたと振舞いがoverallocateにできるかもしれない過去の測定で予測しました。
A network element may employ any appropriate scheduling means to ensure that admitted flows receive appropriate service.
ネットワーク要素は認められた流れが適切なサービスを受けるのを保証するどんな適切なスケジューリング手段も使うかもしれません。
NOTE: The flexibility implied by the above paragraph exists within
definite limits. Readers should observe that the specification's
requirement that the delay and loss behavior described above
imposes concrete requirements on implementations.
以下に注意してください。 上のパラグラフによって含意された柔軟性は明確な限界の中に存在しています。 読者は、遅れと損失の振舞いが上で説明した仕様の要件が具体的な要件を実装に課すのを観測するべきです。
Perhaps the most important requirement is that the implementation
has to make bandwidth greater than the Tspec token rate available
to the flow in certain situations. The requirement for the
availability of extra bandwidth may be derived from the fluid
model of traffic scheduling (e.g. [7]). If a flow receives exactly
its promised token rate at all times, queueing caused by an over-
rate burst arriving at the network element may never clear,
causing the traffic queueing delay to permanantly increase. This
will happen if the flow continues to generate traffic at exactly
the token rate after emitting the burst.
恐らく、最も重要な要件は実装で帯域幅が、ある状況における流れに有効なTspecトークンレートよりすばらしくならなければならないということです。 道路使用時間割の流体モデルから付加的な帯域幅の有用性のための要件を得るかもしれません。(例えば、[7])。 流れがいつもちょうど約束のトークンレートを受け取るなら、ネットワーク要素に達する過剰レート炸裂によって引き起こされた待ち行列は決してクリアされないかもしれません、トラフィック待ち行列遅れがpermanantlyに増加することを引き起こして。 流れが、炸裂を放った後にちょうどトークンレートでトラフィックを生成し続けていると、これは起こるでしょう。
Wroclawski Standards Track [Page 4] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[4ページ]RFC2211
To control the long-term effects of traffic bursts, a Controlled
Load implementation has several options. At minimum, a mechanism
must be present to "borrow" bandwidth needed to clear bursts from
the network. There are a number of ways to implement such a
mechanism, ranging from explicit borrowing schemes within the
traffic scheduler to implicit schemes based on statistical
multiplexing and measurement-based admission control. The
specification does not prefer any method over any other, but does
require that some such mechanism must exist.
トラフィック炸裂の長期効果を制御するために、Controlled Load実装には、いくつかのオプションがあります。 最小限では、メカニズムは、ネットワークから炸裂をクリアするのに必要である帯域幅を「借りる」ために存在していなければなりません。 そのようなメカニズムを実装する多くの方法があります、トラフィックスケジューラの中の明白な借入れの体系から統計的多重化に基づく暗黙の体系と測定ベースの入場コントロールまで及んで。 仕様は、いかなる他のも少しのメソッドも好みませんが、そのような何らかのメカニズムが存在しなければならないのを必要とします。
Similarly, the requirement for low congestion loss for in-Tspec
traffic implies that buffer management must have some flexibility.
Because the controlled-load service does not reshape traffic to
its token-bucket parameters at every node, traffic flowing through
the network will be distorted as it traverses queueing points.
This distortion is particularly likely to occur during traffic
bursts, precisely when buffering is most heavily used. In these
circumstances, rigidly restricting the buffering capacity to a
size equal to the flow's TSpec burst size may lead to congestion
loss. An implementaton should be prepared to make additional
buffering available to bursting flows. Again, this may be
accomplished in a number of ways. One obvious choice is
statistical multiplexing of a shared buffer pool.
同様に、Tspecのトラフィックのための低い混雑の損失のための要件は、バッファ管理には何らかの柔軟性がなければならないのを含意します。 制御負荷サービスがあらゆるノードにおけるトークンバケツパラメタにトラフィックを造り直さないので、待ち行列ポイントを横断するとき、ネットワークを通して流れるトラフィックは歪められるでしょう。 まさにバッファリングがずっしりと最も使用されているとき、このひずみはトラフィック炸裂の間、特に起こりそうです。 こういう事情ですから、バッファリング容量を流れのTSpec放出量と等しいサイズに厳格に制限すると、混雑の損失は出されるかもしれません。 implementatonは追加バッファリングを流れを押し破くのに利用可能にするように準備されるべきです。 一方、これは多くの方法で達成されるかもしれません。 1つの当然の選択が共有バッファプールの統計的多重化です。
Links are not permitted to fragment packets which receive the controlled-load service. Packets larger than the MTU of the link must be treated as nonconformant to the TSpec. This implies that they will be forwarded according to the rules described in the Policing section below.
リンクが制御負荷サービスを受けるパケットを断片化することが許可されていません。 リンクのMTUより大きいパケットをTSpecへのnonconformantとして扱わなければなりません。 これは、下のPolicing部で説明された規則に従ってそれらが進められるのを含意します。
Implementations of controlled-load service are not required to provide any control of short-term packet delay jitter beyond that described above. However, the use of packet scheduling algorithms that provide additional jitter control is not prohibited by this specification.
制御負荷サービスの実装は、上で説明されたそれを超えて短期的なパケット遅れジターのどんなコントロールも提供するのに必要ではありません。 しかしながら、追加ジターコントロールを提供するパケットスケジューリングアルゴリズムの使用はこの仕様で禁止されていません。
Packet losses due to non-congestion-related causes, such as link errors, are not bounded by this service.
非混雑関連の原因によるパケット損失はリンク誤りなどにこのサービスで境界がなかった状態で似ています。
5. Invocation Information
5. 実施の情報
The controlled-load service is invoked by specifying the data flow's desired traffic parameters (TSpec) to the network element. Requests placed for a new flow will be accepted if the network element has the capacity to forward the flow's packets as described above. Requests to change the TSpec for an existing flow should be treated as a new invocation, in the sense that admission control must be reapplied to the flow. Requests that reduce the TSpec for an existing flow (in the
制御負荷サービスは、データフローの必要なトラフィックパラメタ(TSpec)をネットワーク要素に指定することによって、呼び出されます。 ネットワーク要素に上で説明されるように流れのパケットを進める容量があると、新しい流れのために置かれた要求を受け入れるでしょう。 既存の流れのためにTSpecを変えるという要求は新しい実施として扱われるべきです、入場コントロールを流れに再び使わなければならないという意味で。 中既存の流れのためにTSpecを減少させる要求、(。
Wroclawski Standards Track [Page 5] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[5ページ]RFC2211
sense that the new TSpec is strictly smaller than the old TSpec according to the ordering rules given below) should never be denied service.
以下に与えられた注文規則に従って新しいTSpecが古いTSpecより厳密に小さいという感覚) サービスは決して否定されるべきではありません。
The Controlled-Load service uses the TOKEN_BUCKET_TSPEC defined in Reference [5] to describe a data flow's traffic parameters. This TSpec takes the form of a token bucket specification plus a peak rate (p), a minimum policed unit (m) and a maximum packet size (M).
Controlled-負荷サービスはTSPECがデータフローのトラフィックパラメタについて説明するためにReference[5]で定義したTOKEN_BUCKET_を使用します。 このTSpecはトークンバケツ仕様、ピークレート(p)、最小の取り締まられた単位(m)、および最大のパケットサイズ(M)の形を取ります。
The token bucket specification includes a bucket rate r and a bucket depth, b. Both r and b must be positive. The rate, r, is measured in bytes of IP datagrams per second. Values of this parameter may range from 1 byte per second to 40 terabytes per second. Network elements MUST return an error for requests containing values outside this range. Network elements MUST return an error for any request containing a value within this range which cannot be supported by the element. In practice, only the first few digits of the r parameter are significant, so the use of floating point representations, accurate to at least 0.1% is encouraged.
トークンバケツ仕様はバケツレートrとバケツの深さ、bを含んでいます。 rとbの両方が積極的であるに違いありません。 レート(r)は1秒あたりのバイトのIPデータグラムで測定されます。 このパラメタの値は1秒あたり1バイトから40まで1秒あたりのテラバイトに及ぶかもしれません。 ネットワーク要素はこの範囲の外に値を保管している要求のための誤りを返さなければなりません。 ネットワーク要素は要素でサポートすることができないこの範囲の中に値を保管しているどんな要求のための誤りも返さなければなりません。 少なくとも0.1%に正確な浮動小数点表示の使用が重要であることで、実際には、rパラメタの最初の数ケタだけが重要です。奨励にされる。
The bucket depth, b, is measured in bytes. Values of this parameter may range from 1 byte to 250 gigabytes. Network elements MUST return an error for requests containing values outside this range. Network elements MUST return an error for any request containing a value within this range which cannot be supported by the element. In practice, only the first few digits of the b parameter are significant, so the use of floating point representations, accurate to at least 0.1% is encouraged.
バケツの深さ(b)はバイトで測定されます。 このパラメタの値は1バイトから250のギガバイトまで及ぶかもしれません。 ネットワーク要素はこの範囲の外に値を保管している要求のための誤りを返さなければなりません。 ネットワーク要素は要素でサポートすることができないこの範囲の中に値を保管しているどんな要求のための誤りも返さなければなりません。 少なくとも0.1%に正確な浮動小数点表示の使用が重要であることで、実際には、bパラメタの最初の数ケタだけが重要です。奨励にされる。
The range of values allowed for these parameters is intentionally large to allow for future network technologies. Any given network element is not expected to support the full range of values.
これらのパラメタのために許容された値の範囲は、将来のネットワーク技術を考慮するために故意に大きいです。 どんな与えられたネットワーク要素も最大限の範囲の値をサポートしないことが期待されます。
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 parameter exists in this version of the specification primarily for TSpec compatability with other QoS control services and the shared TOKEN_BUCKET_TSPEC parameter. While some admission control and buffer allocation algorithms may find the peak rate value useful, the field may always be ignored by a Controlled-Load service conforming to this version of the specification. That is, the service module at a network element may always assume that the peak data rate arriving at that element is the line rate of the incoming interface, and the service's evaluation criteria do not require a network element to consider the peak rate value. More explicit use of the peak-rate parameter by a Controlled-Load service module may be added to the specification in the future.
ピークレート(p)は、1秒あたりのバイトのIPデータグラムで測定されて、バケツレートとして同じ範囲と提案された表現を持っています。 ピークレートパラメタは主として他のQoSコントロールサービスと共有されたTOKEN_BUCKET_TSPECパラメタがあるTSpec compatabilityのための仕様のこのバージョンに存在しています。 ピークレート価値が役に立つのがいくつかの入場コントロールとバッファ割り当てアルゴリズムによってわかっているかもしれない間、分野は仕様のこのバージョンに従うControlled-負荷サービスでいつも無視されるかもしれません。 すなわち、ネットワーク要素の機械船は、いつもその要素に達するピークデータ信号速度が入って来るインタフェースのライン料率であると仮定するかもしれません、そして、サービスの評価基準はピークレート価値を考えるためにネットワーク要素を必要としません。 ピークレートパラメタのControlled-負荷機械船による、より明白な使用は将来、仕様に追加されるかもしれません。
Wroclawski Standards Track [Page 6] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[6ページ]RFC2211
The minimum policed unit, m, is an integer measured in bytes. All IP datagrams less than size m will be counted against the token bucket as being of size m. The maximum packet size, M, is the biggest packet that will conform to the traffic specification; it is also measured in bytes. Network elements MUST reject a service request if the requested maximum packet size is larger than the MTU of the link. Both m and M must be positive, and m must be less then or equal to M.
最小の取り締まられた単位(m)はバイトで測定された整数です。 サイズmより少ないすべてのIPデータグラムがサイズmの存在としてトークンバケツに対して数えられるでしょう。 最大のパケットサイズ(M)はトラフィック仕様に従う最も大きいパケットです。 また、それはバイトで測定されます。 要求された最大のパケットサイズがリンクのMTUより大きいなら、ネットワーク要素はサービスのリクエストを拒絶しなければなりません。 mとMの両方が積極的であるに違いなく、mは以下がその時かMへの同輩であったなら積極的でなければなりません。
The preferred concrete representation for the TSpec is three floating point numbers in single-precision IEEE floating point format followed by two 32-bit integers in network byte order. The first value is the rate (r), the second value is the bucket size (b), the third is the peak rate (p), the fourth is the minimum policed unit (m), and the fifth is the maximum packet size (M). For the parameters (r) and (b), only bit-patterns which represent valid non-negative floating point numbers are allowed. Negative numbers (including "negative zero), infinities, and NAN's are not allowed. For the parameter (p) only bit-patterns which represent valid non-negative floating point numbers or positive infinity are allowed. Positive infinity is represented with an exponent of all ones (255) and a sign bit and mantissa of all zeroes. Negative numbers (including "negative zero"), negative infinity, and NAN's are not allowed.
TSpecの都合のよい具体的な表現はネットワークバイトオーダーにおける2つの32ビットの整数があとに続いた単精度IEEE浮動小数点形式において3つの浮動小数点です。 最初の値はレート(r)です、そして、2番目の値はバケツサイズ(b)です、そして、3番目はピークレート(p)です、そして、4番目は最小の取り締まられた単位(m)です、そして、5番目は最大のパケットサイズ(M)です。 パラメタ(r)と(b)に関しては、有効な非否定的な浮動小数点を表すビット・パターンだけが許容されています。 負数、(包含、「負のゼロ)、無辺際、およびNANが許容されていない、」 パラメタ(p)において、有効な非否定的な浮動小数点か陽の無限を表すビット・パターンだけが許容されています。 陽の無限はすべてのゼロのすべてのもの(255)の解説者、符号ビット、および仮数で表されます。 負数(「負のゼロ」を含んでいる)、負の無限、およびNANのものは許容されていません。
NOTE: An implementation which utilizes general-purpose hardware or
software IEEE floating-point support may wish to verify that
arriving parameters meet this requirement before using the
parameters in floating-point computations, in order to avoid
unexpected exceptions or traps.
以下に注意してください。 汎用のハードウェアかソフトウェアのIEEEの浮動小数点のサポートを利用する実装は、浮動小数点の計算にパラメタを使用する前に到着パラメタがこの必要条件を満たすことを確かめたがっているかもしれません、予期していなかった例外か罠を避けるために。
The controlled-load service is assigned service_name 5.
制御負荷サービスは割り当てサービス_名前5です。
The TOKEN_BUCKET_TSPEC parameter used by the Controlled-Load service is general parameter number 127, as indicated in [5].
Controlled-負荷サービスで使用されるTOKEN_BUCKET_TSPECパラメタは[5]にみられるように一般的指標No.127です。
6. Exported Information
6. 情報であるとエクスポートされます。
The controlled-load service has no required characterization parameters. Individual implementations may export appropriate implementation-specific measurement and monitoring information.
制御負荷サービスには、どんな必要な特殊化パラメタもありません。 個々の実装は適切な実装特有の測定と監視情報をエクスポートするかもしれません。
7. Policing
7. 取り締まり
The controlled-load service is provided to a flow on the basis that the flow's traffic conforms to a TSpec given at flow setup time. This section defines the meaning of conformance to the controlled-load TSpec, describes the circumstances under which a controlled-load flow's traffic might *not* conform to the TSpec, and specifies the network element's action in those circumstances.
流れのトラフィックが流れ準備時間に与えられたTSpecに従わせるベースで制御負荷サービスを流れに提供します。 このセクションは、制御負荷TSpecと順応の意味を定義して、*ではなく、流れのトラフィックがそうするかもしれない制御負荷*がTSpecに従う事情について説明して、それらの事情におけるネットワーク要素の動作を指定します。
Wroclawski Standards Track [Page 7] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[7ページ]RFC2211
Controlled-load service modules provide QoS control for traffic conforming to the TSpec given at setup time. The TSpec's token bucket parameters require that traffic must obey the rule that over all time periods, the amount of data sent does not exceed rT+b, where r and b are the token bucket parameters and T is the length of the time period. For the purposes of this accounting, links must count packets that are smaller than the minimal policing unit m to be of size m. Packets that arrive at an element and cause a violation of the the rT+b bound are considered nonconformant.
制御負荷機械船は準備時間に与えられたTSpecに従うトラフィックのためのコントロールをQoSに供給します。 TSpecのトークンバケツパラメタは、トラフィックがすべての期間にわたって送られたデータ量がrT+bを超えていないという規則に従わなければならないのを必要とします。そこでは、rとbがトークンバケツパラメタであり、Tは期間の長さです。 この会計の目的のために、リンクはサイズmがある最小量の取り締まりユニットより小さいmであるパケットを数えなければなりません。 要素に達して、rT+bバウンドの違反を引き起こすパケットはnonconformantであると考えられます。
Additionally, packets bigger than the outgoing link MTU are considered nonconformant. It is expected that this situation will not arise with any frequency, because flow setup mechanisms are expected to notify the sending application of the appropriate path MTU.
さらに、出発しているリンクMTUより大きいパケットはnonconformantであると考えられます。 この状況がどんな頻度でも起こらないと予想されます、流れセットアップメカニズムが適切な経路MTUの送付アプリケーションに通知すると予想されるので。
In the presence of nonconformant packets arriving for one or more controlled-load flows, each network element must ensure locally that the following requirements are met:
1回以上の制御負荷の流れのために到着するnonconformantパケットがあるとき、それぞれのネットワーク要素は、以下の必要条件が満たされるのを局所的に確実にしなければなりません:
1) The network element MUST continue to provide the contracted
quality of service to those controlled-load flows not experiencing
excess traffic.
1) ネットワーク要素は、余分なトラフィックにならないそれらの制御負荷流れに収縮したサービスの質を提供し続けなければなりません。
2) The network element SHOULD prevent excess controlled-load
traffic from unfairly impacting the handling of arriving best-
effort traffic. This requirement is discussed further in Section 9
of this document (Guidelines for Implementors).
2) ネットワーク要素SHOULDは、余分な制御負荷トラフィックが不公平に到着している最も良い取り組みトラフィックの取り扱いに影響を与えるのを防ぎます。 このドキュメント(Implementorsのためのガイドライン)のセクション9で、より詳しくこの要件について議論します。
3) Consistent with points 1 and 2, the network element MUST attempt
to forward the excess traffic on a best-effort basis if sufficient
resources are available.
3) ポイント1と2と一致しています、十分なリソースが利用可能であるなら、ネットワーク要素はベストエフォート型ベースの余分なトラフィックを進めるのを試みなければなりません。
Network elements must not assume that that arrival of nonconformant traffic for a specific controlled-load flow will be unusual, or indicative of error. In certain circumstances (particularly, routers acting as the "split points" of a multicast distribution tree supporting a shared reservation) large numbers of packets will fail the conformance test *as a matter of normal operation*.
ネットワーク要素は、誤りが特定の制御負荷流動のためのnonconformantトラフィックのその到着が珍しいか、または暗示するようになると仮定してはいけません。 ある特定の状況では(特に共有された予約をサポートするマルチキャスト分配木の「分裂ポイント」として機能するルータ)多くのパケットが通常操作*の問題として順応テスト*に失敗するでしょう。
Network elements must not assume that data sources or upstream elements have taken action to "police" controlled-load flows by limiting their traffic to conform to the flow's TSpec. Each network element providing controlled-load service MUST independently ensure that the requirements given above are met in the presence of nonconformant arriving traffic for one or more controlled-load flows.
ネットワーク要素は、データ送信端末か上流の要素が従わせるそれらのトラフィックを流れのTSpecに制限することによって「警察」制御負荷流れように行動を取ったと仮定してはいけません。 制御負荷サービスが、上に与えられた必要条件が1つ以上の制御負荷のためのnonconformant到着トラフィックがあるとき満たされるのを独自に確実にしなければならないなら、それぞれのネットワーク要素は流れます。
Wroclawski Standards Track [Page 8] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[8ページ]RFC2211
Network elements may use any appropriate implementation mechanism to meet the requirements given above. Examples of such mechanisms include token-bucket policing filters and per-flow scheduling algorithms. However, it is insufficient to simply place all controlled-load flows into the same shared resource pool, without first ensuring that non-conformant flows are prevented from starving conformant flows of the necessary processing resources.
ネットワーク要素は、上に与えられた必要条件を満たすのにどんな適切な実装メカニズムも使用するかもしれません。 そのようなメカニズムに関する例は、フィルタと1流れあたりのスケジューリングアルゴリズムを取り締まりながら、トークンバケツを含んでいます。しかしながら、単に同じ共用資源プールへのすべての制御負荷流れを置くのは不十分です、最初に非conformant流れが必要な処理リソースのconformant流れを飢えさせるのが防がれるのを確実にしない。
Further discussion of this issue may be found in Section 11 of this note.
この問題のさらなる議論はこの注意のセクション11で見つけられるかもしれません。
Beyond requirements 2 and 3 above, the controlled-load service does not define the QoS behavior delivered to flows with non-conformant arriving traffic. Specifically, it is permissible either to degrade the service delivered to all of the flow's packets equally, or to sort the flow's packets into a conformant set and a nonconformant set and deliver different levels of service to the two sets. This point is discussed further in Section 9 of this note.
要件2と3を超えて、上では、制御負荷サービスが非conformant到着トラフィックで流れに提供されたQoSの振舞いを定義しません。 明確に、等しく流れのパケットのすべてに提供されたサービスを下がらせるか、流れのパケットをconformantセットとnonconformantセットに分類して、または2セットに対する異なったレベルのサービスを提供するのが許されています。 この注意のセクション9で、より詳しくこのポイントについて議論します。
When resources are available, network elements at points within the interior of the network SHOULD be prepared to accommodate packet bursts somewhat larger than the actual TSpec. This requirement derives from the traffic distortion effect described in Section 4. As described there, it may be met either through explicit means or statistical multiplexing of shared buffering resources.
リソースがネットワークSHOULDの内部の中のポイントの有効なネットワーク要素であるときには、実際のTSpecよりいくらか大きいパケット炸裂を収容するように用意してください。 この要件がセクション4で説明されたトラフィックひずみ効果に由来しています。 そこで説明されるように、それは共有されたバッファリングリソースの明白な手段か統計的多重化を通して会われるかもしれません。
When handling such traffic, it is permissible to allow some delaying of a packet if that delay would allow it to pass the policing function. (In other words, to reshape the traffic). However, the overall requirement for limiting the duration of any such traffic distortion must be considered. The challenge is to define a viable reshaping function.
そのようなトラフィックを扱うとき、その遅れで取り締まり機能を通過できるなら、パケットのいくつかの延着を許容するのは許されています。 (言い換えれば、トラフィックを造り直す。) しかしながら、どんなそのようなトラフィックひずみの持続時間も制限するための総合的な要件を考えなければなりません。 挑戦は実行可能な造り直す機能を定義することです。
Intuitively, a plausible approach is to allow a delay of (roughly) up to the maximum queueing delay experienced by completely conforming packets before declaring that a packet has failed to pass the policing function. The merit of this approach, and the precise wording of the specification that describes it, require further study.
もっともらしいアプローチは直観的に、それを宣言する前にパケットを完全に従わせるのによる(およそ)最大の待ち行列遅れまで経験されていることの遅れにパケットを許容するのが取り締まり機能を通過していないということです。 このアプローチの長所、およびそれについて説明する仕様の正確な言葉遣いはさらなる研究を必要とします。
8. Ordering and Merging
8. 注文と合併
The controlled-load service TSpec is ordered according to the
following rule: TSpec A is a substitute for ("as good or better than"
or "greater than or equal to") TSpec B if and only if:
以下の規則に従って、制御負荷サービスTSpecを注文します: TSpec Aが代用品である、(「同じくらい良いか」 “greater than or equal to") TSpec Bより良い、唯一、:
Wroclawski Standards Track [Page 9] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[9ページ]RFC2211
(1) the token bucket rate r for TSpec A is greater than or equal to
that of TSpec B,
(1) TSpec Aのトークンバケツレートrがそう以上である、TSpec Bのもの
(2) the token bucket depth b for TSpec A is greater than or equal
to that of TSpec B,
(2) TSpec Aのためのトークンバケツの深さbがそう以上である、TSpec Bのもの
(3) the peak rate p for TSpec A is greater than or equal to that of
TSpec B,
(3) TSpec Aのピークレートpがそう以上である、TSpec Bのもの
(4) the minimum policed unit m for TSpec A is less than or equal to
that of TSpec B,
(4) TSpec Aに、最小の取り締まられたユニットmはTSpec Bの、よりもの以下です。
(5) the maximum packet size M of TSpec A is greater than or equal
to that of TSpec B.
(5) Mの最大のパケットサイズTSpec Aはそう以上です。TSpec Bのもの。
Note that not all TSpecs can be ordered with respect to each other. If two TSpecs differ but not all five of the points above are true, then the TSpecs are unordered.
互いに関してすべてのTSpecsを注文できるというわけではないことに注意してください。 2TSpecsが異なりますが、上のすべての5ポイントがどんな本当であるというわけではないなら、TSpecsは順不同のです。
A merged TSpec is the TSpec used by the RSVP protocol when merging a set of TSpecs to create a "merged" reservation. TSpec merging is described further in [4] and [3]. The TSpec merge operation addresses two requirements:
合併しているTSpecは「合併している」予約を作成するためにTSpecsの1セットを合併するときRSVPプロトコルによって使用されるTSpecです。 TSpec合併は[4]と[3]で、より詳しく説明されます。 TSpecマージ操作は2つの要件を扱います:
- The "merged" TSpec parameters are used as the traffic flow's
TSpec at the local node.
- 「合併している」TSpecパラメタは交通の流れのTSpecとしてローカルのノードで使用されます。
- The merged parameters are passed upstream to traffic source(s) to
describe characteristics of the actually installed reservation
along the data path.
- 合併しているパラメタは、データ経路に沿って実際にインストールされた予約の特性について説明するために上流へトラフィックソースに渡されます。
For the controlled-load service, a merged TSpec may be calculated over a set of TSpecs by taking:
制御負荷サービスにおいて、合併しているTSpecはTSpecsの1セットについて取ることによって、計算されるかもしれません:
(1) the largest token bucket rate r;
(1) 最も大きいトークンバケツレートr。
(2) the largest token bucket size b;
(2) 最も大きいトークンバケツサイズb。
(3) the largest peak rate p;
(3) 最も大きいピークレートp。
(4) the smallest minimal policed unit m;
(4) 最も小さい最小量の取り締まられたユニットm。
(5) the *smallest* maximum packet size M;
(5) *最も小さい*最大のパケットサイズM。
across all members of the set.
セットのすべてのメンバーの向こう側に。
Wroclawski Standards Track [Page 10] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[10ページ]RFC2211
A Least Common TSpec is a TSpec adequate to describe the traffic from any one of a number of traffic flows. The least common TSpec may be useful when creating a shared reservation for a number of flows using SNMP or another management protocol. This differs from the merged TSpec described above in that the computed parameters are not passed upstream to the sources of traffic.
Least Common TSpecは多くの交通の流れのどれかからトラフィックについて説明するために適切なTSpecです。 SNMPか別の管理プロトコルを使用することで多くの流れの共有された予約を作成するとき、最も一般的でないTSpecは役に立つかもしれません。 これは計算されたパラメタが上流へ通過されないので上で説明された合併しているTSpecからトラフィックの源まで異なります。
For the controlled-load service, the Least Common TSpec may be calculated over a set of TSpecs by taking:
制御負荷サービスにおいて、Least Common TSpecはTSpecsの1セットについて取ることによって、計算されるかもしれません:
(1) the largest token bucket rate r;
(1) 最も大きいトークンバケツレートr。
(2) the largest token bucket size b;
(2) 最も大きいトークンバケツサイズb。
(3) the largest peak rate p;
(3) 最も大きいピークレートp。
(4) the smallest minimal policed unit m;
(4) 最も小さい最小量の取り締まられたユニットm。
(5) the largest maximum packet size M;
(5) 最も大きい最大のパケットサイズM。
across all members of the set.
セットのすべてのメンバーの向こう側に。
The sum of n controlled-load service TSpecs is used when computing the TSpec for a shared reservation of n flows. It is computed by taking:
nの共有された予約のためにTSpecを計算するのが流れるとき、合計n制御負荷サービスTSpecsが使用されています。 それは取ることによって、計算されます:
- The sum across all TSpecs of the token bucket rate parameter r.
- トークンバケツレートパラメタrのすべてのTSpecsの向こう側の合計。
- The sum across all TSpecs of the token bucket size parameter b.
- トークンバケツサイズ・パラメータbのすべてのTSpecsの向こう側の合計。
- The sum across all TSpecs of the peak rate parameter p.
- ピークレートパラメタpのすべてのTSpecsの向こう側の合計。
- The minimum across all TSpecs of the minimum policed unit
parameter m.
- 最小限のすべてのTSpecsの向こう側の最小限はユニットパラメタmを取り締まりました。
- The maximum across all TSpecs of the maximum packet size
parameter M.
- 最大のパケットサイズ・パラメータMのすべてのTSpecsの向こう側の最大。
The minimum of two TSpecs differs according to whether the TSpecs can be ordered according to the "greater than or equal to" rule above. If one TSpec is less than the other TSpec, the smaller TSpec is the minimum. For unordered TSpecs, a different rule is used. The minimum of two unordered TSpecs is determined by comparing the respective values in the two TSpecs and choosing:
“greater than or equal to"規則に従って上でTSpecsを注文できるかどうかに従って、2TSpecsの最小限は異なります。 1TSpecがもう片方のTSpec以下であるなら、より小さいTSpecは最小限です。 順不同のTSpecsに関しては、異なった規則は使用されています。 2順不同のTSpecsの最小限は、2TSpecsでそれぞれの値を比較することによって断固としていて選びます:
Wroclawski Standards Track [Page 11] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[11ページ]RFC2211
(1) the smaller token bucket rate r;
(1) よりわずかなトークンバケツレートr。
(2) the *larger* token bucket size b;
(2) *より大きい*トークンバケツサイズb。
(3) the smaller peak rate p;
(3) よりわずかなピークレートp。
(4) the *smaller* minimum policed unit m;
(4) *よりわずかな*最小限はユニットmを取り締まりました。
(5) the smaller maximum packet size M;
(5) より小さい最大のパケットサイズM。
9. Guidelines for Implementors
9. 作成者へのガイドライン
REQUIREMENTS PLACED ON ADMISSION CONTROL ALGORITHM: The intention of this service specification is that network elements deliver a level of service closely approximating best-effort service under unloaded conditions. As with best-effort service under these conditions, it is not required that every single packet must be successfully delivered with zero queueing delay. Network elements providing controlled-load service are permitted to oversubscribe the available resources to some extent, in the sense that the bandwidth and buffer requirements indicated by summing the TSpec token buckets of all controlled-load flows may exceed the maximum capabilities of the network element. However, this oversubscription may only be done in cases where the element is quite sure that actual utilization is less than the sum of the token buckets would suggest, so that the implementor's performance goals will be met. This information may come from measurement of the aggregate traffic flow, specific knowledge of application traffic statistics, or other means. The most conservative approach, rejection of new flows whenever the addition of their traffic would cause the strict sum of the token buckets to exceed the capacity of the network element (including consideration of resources needed to maintain the delay and loss characteristics specified by the service) may be appropriate in other circumstances.
入場に置かれた要件はアルゴリズムを制御します: このサービス仕様の意志はネットワーク要素が降ろされた条件のもとで密接にベストエフォート型サービスに近似するサービスのレベルを提供するということです。 これらの状態のベストエフォート型サービスでどんな待ち行列遅れでも首尾よくあらゆるパケットを提供しなければならないというわけではないのが必要でないときに。 oversubscribeへの利用可能資源は制御負荷サービスを提供するネットワーク要素にある程度受入れられます、要件がすべての制御負荷流れのTSpecトークンバケツをまとめることによって示した帯域幅とバッファがネットワーク要素の最大の能力を超えるかもしれないという意味で。 しかしながら、要素がその実際の利用がトークンバケツの合計が示すだろう以下であることをかなり確信している場合でこの応募超過をするだけであるかもしれません、作成者の性能目標が達成されるように。 この情報は集合交通の流れ、アプリケーショントラフィック統計に関する特定の知識、または他の手段の測定から来るかもしれません。 最も保守的なアプローチ、トークンバケツの厳しい合計がそれらのトラフィックの追加でネットワーク要素の容量を超えているだろうという(リソースの考慮を含んでいるのは、遅れを維持する必要がありました、そして、損失の特性はサービスで指定しました)ときはいつも、新しい流れの拒絶は他の事情で適切であるかもしれません。
Specific issues related to this subject are discussed in the "Evaluation Criteria" and "Examples of Implementation" sections below.
下の「評価基準」と「実装に関する例」セクションでこの対象に関連する特定の問題について議論します。
INTERACTION WITH BEST-EFFORT TRAFFIC: Implementors of this service should clearly understand that in certain circumstances (routers acting as the "split points" of a multicast distribution tree supporting a shared reservation) large numbers of a flow's packets may fail the TSpec conformance test *as a matter of normal operation*. According to the requirements of Section 7, these packets should be forwarded on a best-effort basis if resources permit.
ベストエフォート型トラフィックとの相互作用: このサービスの作成者は、ある特定の状況では(共有された予約をサポートするマルチキャスト分配木の「分裂ポイント」として機能するルータ)流れの多くのパケットが通常操作*の問題としてTSpec順応テスト*に失敗するかもしれないのを明確に理解するべきです。セクション7の要件に従って、リソースが可能にするなら、ベストエフォート型ベースでこれらのパケットを進めるべきです。
Wroclawski Standards Track [Page 12] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[12ページ]RFC2211
If the network element's best-effort queueing algorithm does not distinguish between these packets and elastic best-effort traffic such as TCP flows, THE EXCESS CONTROLLED-LOAD PACKETS WILL "BACK OFF" THE ELASTIC TRAFFIC AND DOMINATE THE BEST-EFFORT BANDWIDTH USAGE. The integrated services framework does not currently address this issue. However, several possible solutions to the problem are known [RED, xFQ]. Network elements supporting the controlled load service should implement some mechanism in their best-effort queueing path to discriminate between classes of best-effort traffic and provide elastic traffic with protection from inelastic best-effort flows.
ネットワーク要素のベストエフォート型待ち行列アルゴリズムがこれらのパケットを見分けないで、TCPなどの弾性のベストエフォート型トラフィックが流れると、EXCESS CONTROLLED-LOAD PACKETSは弾性のトラフィックを「引き返し」て、ベストエフォート型帯域幅用法を支配するでしょう。 統合サービスフレームワークは現在、この問題を扱いません。 しかしながら、問題へのいくつかの可能な解決が知られています[RED、xFQ]。 制御負荷がサービスであるとサポートするネットワーク要素は、ベストエフォート型トラフィックのクラスを区別して、保護を弾力性のないベストエフォート型流れから弾性のトラフィックに提供するためにそれらのベストエフォート型待ち行列経路の何らかのメカニズムを実装するはずです。
Two basic approaches are available to meet this requirement. The network element can maintain separate resource allocations for different classes of best-effort traffic, so that no one class will excessively dominate the loaded best-effort mix. Alternatively, an element can process excess controlled-load traffic at somewhat lower priority than elastic best-effort traffic, so as to completely avoid the back-off effect discussed above.
2つの基本的なアプローチが、この必要条件を満たすために利用可能です。 ネットワーク要素は異なったクラスのベストエフォート型トラフィックのために別々の資源配分を維持できます、いいえ1のクラスがロードされたベストエフォート型ミックスを過度に支配するように。 あるいはまた、要素は弾性のベストエフォート型トラフィックよりいくらか低い優先度で余分な制御負荷トラフィックを処理できます、上で検討された下に後部効果を完全に避けるために。
If most or all controlled-load traffic arises from non-rate-adaptive real-time applications, the use of priority mechanisms might be desirable. If most controlled-load traffic arises from rate-adaptive realtime or elastic applications attempting to establish a bounded minimum level of service, the use of separate resource classes might be preferable. However, this is not a firm guideline. In practice, the network element designer's choice of mechanism will depend heavily on both the goals of the design and the implementation techniques appropriate for the designer's platform. This version of the service specification does not specify one or the other behavior, but leaves the choice to the implementor.
大部分かすべての制御負荷トラフィックが起こる、非レート適応型である、リアルタイムのアプリケーションであり、優先権メカニズムの使用は望ましいかもしれません。 制御最も負荷のトラフィックがレート適応型のリアルタイムか境界がある最低水準のサービスを確立するのを試みる弾性のアプリケーションから起こるなら、別々のリソースのクラスの使用は望ましいかもしれません。 しかしながら、これは堅いガイドラインではありません。 実際には、ネットワーク要素デザイナーのメカニズムのこの選択は大いにデザインの目標とデザイナーのプラットホームに、適切な実装のテクニックの両方次第でしょう。 サービス仕様のこのバージョンは、1かもう片方の振舞いを指定しませんが、作成者に選択を任せます。
FORWARDING BEHAVIOR IN PRESENCE OF NONCONFORMANT TRAFFIC: As indicated in Section 7, the controlled-load service does not define the QoS behavior delivered to flows with non-conformant arriving traffic. It is permissible either to degrade the service delivered to all of the flow's packets equally, or to sort the flow's packets into a conformant set and a nonconformant set and deliver different levels of service to the two sets.
NONCONFORMANTトラフィックの存在における推進の振舞い: セクション7にみられるように、制御負荷サービスは非conformant到着トラフィックで流れに提供されたQoSの振舞いを定義しません。 等しく流れのパケットのすべてに提供されたサービスを下がらせるか、流れのパケットをconformantセットとnonconformantセットに分類して、または2セットに対する異なったレベルのサービスを提供するのが許されています。
In the first case, expected queueing delay and packet loss probability will rise for all packets in the flow, but packet delivery reordering will, in general, remain at low levels. This behavior is preferable for those applications or transport protocols which are sensitive to excessive packet reordering. A possible example is an unmodified TCP connection, which would see reordering as lost packets, triggering duplicate acks and hence excessive retransmissions.
前者の場合、予想された待ち行列遅れとパケット紛失率はすべてのパケットのために流れで上昇するでしょうが、一般に、パケット配信再命令は低レベルに残るでしょう。 過度のパケット再命令に敏感なそれらのアプリケーションかトランスポート・プロトコルに、この振舞いは望ましいです。 可能な例は変更されていないTCP接続です、写しacksとしたがって、過度の「再-トランスミッション」の引き金となって。(それは、無くなっているパケットであると再命令をみなすでしょう)。
Wroclawski Standards Track [Page 13] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[13ページ]RFC2211
In the second case, some subset of the flow's packets will be delivered with low loss and delay, while some other subset will be delivered with higher loss and potentially higher delay. The delayed packets will appear to the receiver to have been reordered in the network, while the non-delayed packets will, on average, arrive in a more timely fashion than if all packets were treated equally. This might be preferable for applications which are highly time-sensitive, such as interactive conferencing tools.
2番目の場合では、流れのパケットの何らかの部分集合が低い損失と遅れで提供されるでしょう、ある他の部分集合は、より高い損失と潜在的により高い遅れで提供されるでしょうが。 遅れたパケットはネットワークで再命令されるべきであった受信機に現れるでしょう、非遅れたパケットがパケットがすべてなら等しく扱われたよりタイムリーなファッションに平均的に到着するでしょうが。 対話的な会議ツールなどのように時間非常に敏感なアプリケーションに、これは望ましいかもしれません。
10. Evaluation Criteria
10. 評価基準
The basic requirement placed on an implementation of controlled-load service is that, under all conditions, it provide accepted data flows with service closely similar to the service that same flow would receive using best-effort service under unloaded conditions.
制御負荷サービスの実装に置かれた基本的な要件はすべての条件のもとで降ろされた条件のもとでベストエフォート型サービスを利用することで密接に同じ流れが受けるサービスと同様のサービスを受け入れられたデータフローに提供するということです。
This suggests a simple two-step evaluation strategy. Step one is to compare the service given best-effort traffic and controlled-load traffic under underloaded conditions.
これは簡単なツーステップ評価戦略を示します。 ステップ1はunderloaded状態のベストエフォート型トラフィックと制御負荷トラフィックを考えて、サービスを比較することです。
- Measure the packet loss rate and delay characteristics of a test
flow using best-effort service and with no load on the network
element.
- ベストエフォート型サービスとどんな負荷もオンな状態でネットワーク要素を使用しないで、テスト流動のパケット損失率と遅れの特性を測定してください。
- Compare those measurements with measurements of the same flow
receiving controlled-load service with no load on the network
element.
- ネットワーク要素の上で負荷なしで制御負荷サービスを受ける同じ流れの測定値とそれらの測定値を比べてください。
Closer measurements indicate higher evaluation ratings. A
substantial difference in the delay characteristics, such as the
smoothing which would be seen in an implementation which scheduled
the controlled-load flow using a fixed, constant-bitrate algorithm,
should result in a somewhat lower rating.
より近い測定値は、より高い評価格付けを示します。 修理されて、一定のbitrateのアルゴリズムを使用することで制御負荷流動の計画をした実装で見られるスムージングなどの遅れの特性のかなりの違いがいくらか低い格付けをもたらすべきです。
Step two is to observe the change in service received by a controlled-load flow as the load increases.
ステップtwoは負荷が増加するのに応じてサービスにおける変化が制御負荷流動によって受信されたのを観測することです。
- Increase the background traffic load on the network element,
while continuing to measuring the loss and delay characteristics of
the controlled-load flow. Characteristics which remain essentially
constant as the element is driven into overload indicate a high
evaluation rating. Minor changes in the delay distribution indicate
a somewhat lower rating. Significant increases in delay or loss
indicate a poor evaluation rating.
- 制御負荷流動の損失と遅れの特性を測定するのに続いている間、ネットワーク要素でバックグラウンドトラヒック負荷を増強してください。 オーバーロードが要素に追い込まれるとき本質的には一定のままで残っている特性は高い評価格付けを示します。 遅れ分配におけるマイナーチェンジはいくらか低い格付けを示します。 遅れか損失のかなりの増加は不十分な評価格付けを示します。
Wroclawski Standards Track [Page 14] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[14ページ]RFC2211
This simple model is not adequate to fully evaluate the performance of controlled-load service. Three additional variables affect the evaluation. The first is the short-term burstiness of the traffic stream used to perform the tests outlined above. The second is the degree of long-term change in the controlled-load traffic within the bounds of its TSpec. (Changes in this characteristic will have great effect on the effectiveness of certain admission control algorithms.) The third is the ratio of controlled-load traffic to other traffic at the network element (either best effort or other controlled services).
この単純モデルは、制御負荷サービスの性能を完全に評価するために適切ではありません。 3つの追加変数が評価に影響します。 1番目は上に概説されたテストを実行するのに使用されるトラフィックストリームの短期的なburstinessです。 2番目はTSpecの領域の中の制御負荷トラフィックにおける長期変化の度合いです。 (この特性における変化はある入場コントロールアルゴリズムの有効性にすばらしい影響を与えるでしょう。) 3番目は制御負荷トラフィック対ネットワーク要素(ベストエフォート型か他の制御サービス)の他のトラフィックの比率です。
The third variable should be specifically evaluated using the following procedure.
3番目の変数は、以下の手順を用いることで明確に評価されるべきです。
With no controlled-load flows in place, overload the network
element with best-effort traffic (as indicated by substantial
packet loss and queueing delay).
適所にある制御負荷流れがなければ、ベストエフォート型トラフィックでネットワーク要素を積みすぎてください(かなりのパケット損失と待ち行列遅れによって示されるように)。
Execute requests for controlled-load service giving TSpecs with
increasingly large rate and burst parameters. If the request is
accepted, verify that traffic matching the TSpec is in fact handled
with characteristics closely approximating the unloaded
measurements taken above.
ますます大きいレートでTSpecsに与える制御負荷サービスを求める要求を実行してください、そして、パラメタを押し破いてください。 要求を受け入れるなら、事実上、特性が密接に上で取られた降ろされた測定値に近似であっているのでTSpecに合っているトラフィックが扱われることを確かめてください。
Repeat these experiments to determine the range of traffic
parameter (rate, burst size) values successfully handled by the
network element. The useful range of each parameter must be
determined for several settings of the other parameter, to map out
a two-dimensional "region" of successfully handled TSpecs. When
compared with network elements providing similar capabilities, this
region indicates the relative ability of the elements to provide
controlled-load service under high load. A larger region indicates
a higher evaluation rating.
これらの実験を繰り返して、ネットワーク要素によって首尾よく扱われたトラフィックパラメタ(評価してください、そして、サイズを押し破く)値の範囲を決定してください。 首尾よく扱われたTSpecsの二次元「領域」を計画することをもう片方のパラメタのいくつかの設定にそれぞれのパラメタの有効範囲を決定しなければなりません。 同様の能力を提供するネットワーク要素と比べると、この領域は要素が高い負荷の下での制御負荷サービスを提供する相対的な能力を示します。 より広大な地域は、より高い評価格付けを示します。
11. Examples of Implementation
11. 実装に関する例
One possible implementation of controlled-load service is to provide a queueing mechanism with two priority levels; a high priority one for controlled-load and a lower priority one for best effort service. An admission control algorithm is used to limit the amount of traffic placed into the high-priority queue. This algorithm may be based either on the specified characteristics of the high-priority flows (using information provided by the TSpecs), or on the measured characteristics of the existing high-priority flows and the TSpec of the new request.
1つの可能な制御負荷サービスの実装は2つの優先順位を待ち行列メカニズムに提供することです。 制御負荷のための高い優先度1とベストエフォート型サービスのための低優先度1。 入場コントロールアルゴリズムは、高い優先待ち行列に置かれたトラフィックの量を制限するのに使用されます。 このアルゴリズムは高優先度流れ(TSpecsによって提供された情報を使用する)の指定された特性、または、既存の高優先度流れの測定特性と新しい要求のTSpecに基づくかもしれません。
Another possible implementation of controlled-load service is based on the existing capabilities of network elements which support
既存の能力に基づいてサービスがある制御負荷ネットワーク要素の別の可能な実装はどのサポートであるか。
Wroclawski Standards Track [Page 15] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[15ページ]RFC2211
"traffic classes" based on mechanisms such as weighted fair queueing or class-based queueing [6]. In this case, it is sufficient to map data flows accepted for controlled-load service into an existing traffic class with adequate capacity to avoid overload. This
「トラフィックのクラス」は荷重している公正な待ち行列かクラスベースの待ち行列[6]などのメカニズムを基礎づけました。 この場合、制御負荷サービスのためにオーバーロードを避ける適切な容量で既存のトラフィックのクラスに受け入れられたデータフローを写像するのは十分です。 これ
requirement is enforced by an admission control algorithm which considers the characteristics of the traffic class, the characteristics of the traffic already admitted to the class, and the TSpec of the new flow requesting service. Again, the admission control algorithm may be based either on the TSpec-specified or the measured characteristics of the existing traffic.
要件はトラフィックのクラスの特性を考える入場コントロールアルゴリズムによって励行されます、とトラフィックの特性は既にクラス、およびサービスを要求する新しい流れのTSpecに認めました。 一方、入場コントロールアルゴリズムはTSpecに指定にされるか既存のトラフィックの測定特性に基づくかもしれません。
A specific case of the above approach is to employ a scheduler which implements weighted fair queueing or similar load-management scheme, allocating a separate scheduling queue with correctly chosen weight to each individual controlled-load flow. In this circumstance, the traffic scheduler also plays the role of the policing function, by ensuring that nonconformant traffic arriving for one controlled-load flow does not affect either other controlled-load flows or the best- effort traffic. This elimination of mechanism is balanced by the drawback that the approach does not benefit from any performance or resource usage gain arising from statistical aggregation of several flows into a single queueing class.
上のアプローチの特定のケースが荷重している公正な待ち行列を実装するスケジューラを使うことであるまたは同様の負荷調整は計画されます、正しく選ばれた重さと共にそれぞれの個々の制御負荷流動に別々のスケジューリング待ち行列を割り当てて。 また、この状況では、トラフィックスケジューラは取り締まり機能の役割を果たします、1つの制御負荷流動のために到着するnonconformantトラフィックが他の制御負荷流れか最も良い取り組みトラフィックのどちらかに影響しないのを確実にすることによって。 メカニズムのこの除去はアプローチが1つの待ち行列のクラスへの数回の流れの統計的な集合から起こるどんな性能やリソース用法利得からもためにならない欠点でバランスをとっています。
Admission control algorithms based on specified characteristics are likely be appropriate when the number of flows in the high-priority class is small, or the traffic characteristics of the flows appear highly variable. In these situations the measured behavior of the aggregate controlled-load traffic stream may not serve as an effective predictor of future traffic, leading a measurement-based admission control algorithm to produce incorrect results. Conversely, in situations where the past behavior of the aggregate controlled- load traffic *is* a good predictor of future behavior, a measurement- based admission control algorithm may allow more traffic to be admitted to the controlled-load service class with no degradation in performance. An implementation may choose to switch between these two approaches depending on the nature of the traffic stream at a given time.
指定された特性に基づく入場コントロールアルゴリズムは高優先度のクラスの流れの数が少ないときには適切にしてくださいか、または流れのトラフィックの特性が非常に可変に見える傾向があります。 これらの状況で、集合制御負荷トラフィックストリームの測定振舞いは将来のトラフィックの有能な予言者として機能しないかもしれません、測定ベースの入場コントロールアルゴリズムが不正確な結果を生むように導いて。 逆に、集合制御負荷トラフィック*の過去の振舞いが*今後の振舞いの良い予言者、測定が入場を基礎づけたということである状況で、コントロールアルゴリズムは、より多くのトラフィックが性能における退行なしで制御負荷サービスのクラスに認められるのを許容するかもしれません。 実装は、一時にトラフィックストリームの本質によるこれらの2つのアプローチを切り換えるのを選ぶかもしれません。
A variety of techniques may be used to provide the desired isolation between excess (nonconformant) controlled-load traffic and other best-effort traffic. Use of a low priority queue for nonconformant controlled-load traffic is simple, but other approaches may provide superior service or fit better into existing architectures. Variants of fair queueing or weighted fair queueing may be used to allocate a percentage of the available resources to different best-effort traffic classes. One approach would be to allocate each controlled- load flow a a 1/N "fair share" percentage of the available best-
さまざまなテクニックが、余分な(nonconformant)制御負荷トラフィックと他のベストエフォート型トラフィックの間に必要な分離を提供するのに使用されるかもしれません。 低い優先待ち行列のnonconformant制御負荷トラフィックの使用が簡単ですが、他のアプローチは、優れたサービスを提供するか、または、より一層既存のアーキテクチャに収まるかもしれません。 公正な待ち行列か荷重している公正な待ち行列の異形は、利用可能資源対異なったベストエフォート型トラフィックのクラスの割合を割り当てるのに使用されるかもしれません。 1つのアプローチは利用可能なベストの1/N「正当な分け前」割合をそれぞれの制御負荷流動に割り当てるだろうことです。
Wroclawski Standards Track [Page 16] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[16ページ]RFC2211
effort bandwidth for its excess traffic. An alternate approach would be to provide a single WFQ resource class for all excess controlled- load traffic. Finally, alternate mechanisms such as RED [xxx] may be used to provide the same overall function.
余分なトラフィックのための取り組み帯域幅。 代替のアプローチはすべての過剰のための1つのWFQリソースのクラスに制御負荷トラフィックを提供するだろうことです。 最終的に、RED[xxx]などの代替のメカニズムは、同じ総括的機能を提供するのに使用されるかもしれません。
12. Examples of Use
12. 使用に関する例
The controlled-load service may be used by any application which can make use of best-effort service, but is best suited to those applications which can usefully characterize their traffic requirements. Applications based on the transport of "continuous media" data, such as digitized audio or video, are an important example of this class.
制御負荷サービスをベストエフォート型サービスを利用できるどんなアプリケーションでも使用されるかもしれませんが、有効にそれらのトラフィック要件を特徴付けることができるそれらのアプリケーションに合わせるのは最も良いです。 デジタル化しているオーディオかビデオなどの「連続したメディア」データの輸送に基づくアプリケーションはこのクラスの重要な例です。
The controlled-load service is not isochronous and does not provide any explicit information about transmission delay. For this reason, applications with end-to-end timing requirements, including the continuous-media class mentioned above, provide an application- specific timing recovery mechanism, similar or identical to the mechanisms required when these applications use best-effort service. A protocol useful to applications requiring this capability is the IETF Real-Time Transport Protocol [2].
制御負荷サービスは、同一時間でなく、またトランスミッション遅れに関する少しの明示的な情報も提供しません。 この理由で、終わりから終わりへのタイミング前記のように連続したメディアのクラスを含む要件があるアプリケーションはこれらのアプリケーションがベストエフォート型サービスを利用すると必要であるメカニズムと同様の、または、同じアプリケーション特定のタイミング回収機構を提供します。 この能力を必要とするアプリケーションの役に立つプロトコルはIETFレアル-時間Transportプロトコル[2]です。
Load-sensitive applications may choose to request controlled-load service whenever they are run. Alternatively, these applications may monitor their own performance and request controlled-load service from the network only when best-effort service is not providing acceptable performance. The first strategy provides higher assurance that the level of quality delivered to the user will not change over the lifetime of an application session. The second strategy provides greated flexibility and offers cost savings in environments where levels of service above best-effort incur a charge.
負荷敏感なアプリケーションは、それらが実行されるときはいつも、制御負荷サービスを要求するのを選ぶかもしれません。 あるいはまた、ベストエフォート型サービスが許容性能を提供していないときだけ、これらのアプリケーションは、それら自身の性能をモニターして、ネットワークから制御負荷サービスを要求するかもしれません。 最初の戦略はユーザに提供された品質のレベルがアプリケーションセッションの生涯変化しないというより高い保証を提供します。 2番目の戦略はgreated柔軟性を提供します、そして、申し出はベストエフォート型の上のサービスのレベルが充電を被る環境における貯蓄かかります。
13. Security Considerations
13. セキュリティ問題
A network element implementing the service described here is intentionally and explicitly expected to give preferential treatment to selected packet traffic. This memo does not describe the mechanism used to indicate which traffic is to receive the preferential treatment - rather, the controlled-load service described here may be invoked by a number of mechanisms, including RSVP, SNMP network management software, or proprietary control software. However, any mechanism used to invoke the controlled load service must provide security sufficient to guard against use of this preferential treatment capability by undesired or unauthorized traffic. A correct implementation of the controlled-load service is *not* susceptable to a denial-of-service attack based on maliciously requesting a very small resource allocation for the attacked traffic flow. This is
ここで説明されたサービスを実装するネットワーク要素が選択されたパケットトラフィックの優遇を与えることが故意に、明らかに期待されます。 このメモは優遇を受けるためにトラフィックがどれであるかを示すのに使用されるメカニズムについて説明しません--むしろ、ここで説明された制御負荷サービスは多くのメカニズムによって呼び出されるかもしれません、RSVP、SNMPネットワークマネージメントソフトウェア、または独占制御ソフトウェアを含んでいて。 しかしながら、制御負荷サービスを呼び出すのに使用されるどんなメカニズムも望まれないか権限のないトラフィックでこの優遇能力の使用に用心できるくらいのセキュリティを提供しなければなりません。 正しい制御負荷サービスの実装は攻撃された交通の流れのために陰湿に非常に小さい資源配分を要求することに基づいたサービス不能攻撃への**susceptableではありません。 これはそうです。
Wroclawski Standards Track [Page 17] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[17ページ]RFC2211
because the service specification requires that traffic in excess of the requested level be carried on a best-effort basis, rather than being dropped. This requirement is discussed further in Section 7 of this memo.
サービス仕様が要求されたレベルを超えてそのトラフィックを必要とするので、ベストエフォート型ベースでは、下げられるよりむしろ運ばれてください。 このメモのセクション7で、より詳しくこの要件について議論します。
Of necessity, giving preferential service to certain traffic flows implies giving less service to other traffic flows. Thus, it is possible to conduct a denial of service attack by maliciously reconfiguring the controlled-load "admission control algorithm" to allow overallocation of available bandwidth or other forwarding resources, starving non-controlled-load flows. In general, this is unlikely to increase the network's vulnerability to attack, because many other reconfigurations of a router or host can cause denial of service. It is reasonable to assume that whatever means is used to protect against other reconfiguration attacks will be adequate to protect against this one as well.
必要であることで、他のトラフィックに対する、より少ないサービスを与えるある交通の流れに対する優先のサービスが含意する付与が流れます。 したがって、利用可能な帯域幅か他の推進リソースの過剰配分を許すために陰湿に制御負荷「入場コントロールアルゴリズム」を再構成することによってサービス不能攻撃を行うのは可能です、非制御された負荷流れを飢えさせて。 一般に、これは攻撃するためにネットワークの脆弱性を増強しそうにはありません、ルータかホストの他の多くの再構成がサービスの否定を引き起こす場合があるので。 他の再構成攻撃から守るのに使用されるどんな手段もまた、これから守るために適切になると仮定するのは妥当です。
Appendix 1: Use of the Controlled-Load service with RSVP
付録1: RSVPとのControlled-負荷サービスの使用
The use of Controlled-Load service in conjunction with the RSVP resource reservation setup protocol is specified in reference [4]. This document gives the format of RSVP FLOWSPEC, SENDER_TSPEC, and ADSPEC objects needed to support applications desiring Controlled- Load service and gives information about how RSVP processes those objects. The RSVP protocol itself is specified in Reference [3].
RSVP資源予約セットアッププロトコルに関連したControlled-負荷サービスの使用は参照[4]で指定されます。 このドキュメントは、Controlled負荷サービスを望んでいるアプリケーションをサポートするのが必要であるRSVP FLOWSPEC、SENDER_TSPEC、およびADSPECオブジェクトの書式を与えて、RSVPがどうそれらのオブジェクトを処理するかに関して知らせます。 RSVPプロトコル自体はReference[3]で指定されます。
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] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson. "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[2]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン。 「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[3] Braden, R., Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[3] ブレーデン、R.、エド、etアル、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、9月1997日
[4] Wroclawski, J., "The use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[4]Wroclawski、J.、「IETF Integrated ServicesとのRSVPの使用」、RFC2210、1997年9月。
[5] Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[5]Shenker、S.、およびJ.Wroclawski、「統合サービスネットワークElementsへの一般的性質パラメタ」、RFC2215、1997年9月。
Wroclawski Standards Track [Page 18] RFC 2211 Controlled-Load Network September 1997
ネットワーク1997年9月の制御負荷のWroclawski標準化過程[18ページ]RFC2211
[6] S. Floyd, and V. Jacobson. "Link-sharing and Resource Management Models for Packet Networks," IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995.
[6] S.フロイド、およびV.ジェーコブソン。 「Packet Networksのためのリンク共有とResource Management Models」、Networkingの上のIEEE/ACM Transactions、Vol.3No.4、ページ 365-386と、1995年8月。
[7] A. K. J. Parekh. "A Generalized Processor Sharing Approach to Flow Control in Integrated Service Networks". MIT Laboratory for Information and Decision Systems, Report LIDS-TH-2089, February 1992
[7] A.K.J.Parekh。 「フロー制御へのアプローチを分担する一般化されたプロセッサはサービスネットワークを統合しました。」 情報のためのMIT研究所と決定システム、レポート、ふた、2089番目、1992年2月
Author's Address
作者のアドレス
John Wroclawski MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
ジョンWroclawski MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA 02139
Phone: 617-253-7885 Fax: 617-253-2673 (FAX) EMail: jtw@lcs.mit.edu
以下に電話をしてください。 617-253-7885 Fax: 617-253-2673(ファックスする)に、メールしてください: jtw@lcs.mit.edu
Wroclawski Standards Track [Page 19]
Wroclawski標準化過程[19ページ]
一覧
スポンサーリンク
