RFC2859 日本語訳
2859 A Time Sliding Window Three Colour Marker (TSWTCM). W. Fang, N.Seddigh, B. Nandy. June 2000. (Format: TXT=19203 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Fang
Request for Comments: 2859 Princeton University
Category: Experimental N. Seddigh
B. Nandy
Nortel Networks
June 2000
コメントを求めるワーキンググループW.牙の要求をネットワークでつないでください: 2859年のプリンストン大学カテゴリ: 実験的なN.Seddigh B.ナンディノーテルは2000年6月をネットワークでつなぎます。
A Time Sliding Window Three Colour Marker (TSWTCM)
時間引窓Three色のマーカー(TSWTCM)
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner [RFC2475, RFC2474]. The marker is intended to mark packets that will be treated by the Assured Forwarding (AF) Per Hop Behaviour (PHB) [AFPHB] in downstream routers. The TSWTCM meters a traffic stream and marks packets to be either green, yellow or red based on the measured throughput relative to two specified rates: Committed Target Rate (CTR) and Peak Target Rate (PTR).
このメモはTime Sliding Window Three Colour Marker(TSWTCM)を定義します。(コンポーネントとしてDiff-Serv交通コンディショナー[RFC2475、RFC2474]でTime Sliding Window Three Colour Markerを使用できます)。 マーカーが川下のルータでHop Behaviour(PHB)[AFPHB]あたりのAssured Forwarding(AF)によって扱われるパケットをマークすることを意図します。 TSWTCMは、交通の流れを計量して、パケットが2つの指定されたレートに比例した測定スループットに基づいて緑色であって、黄色いか、または赤であるとマークします: 遂行された目標金利(CTR)とピークはレート(PTR)を狙います。
1.0 Introduction
1.0 序論
The Time Sliding Window Three Colour Marker (TSWTCM) is designed to mark packets of an IP traffic stream with colour of red, yellow or green. The marking is performed based on the measured throughput of the traffic stream as compared against the Committed Target Rate (CTR) and the Peak Target Rate (PTR). The TSWTCM is designed to mark packets contributing to sending rate below or equal to the CTR with green colour. Packets contributing to the portion of the rate between the CTR and PTR are marked yellow. Packets causing the rate to exceed PTR are marked with red colour.
Time Sliding Window Three Colour Marker(TSWTCM)は、赤、黄色または緑色の色をIP交通の流れのパケットに付けるように設計されています。 Committed Target Rate(CTR)とPeak Target Rate(PTR)に対して比べて、マークは交通の流れの測定スループットに基づいて実行されます。 TSWTCMは、緑色の色についてCTRと以下の、または、等しいレートを送るのに貢献するパケットをマークするように設計されています。 CTRとPTRの間のレートの部分に貢献するパケットは黄色であるとマークされます。 レートがPTRを超えているパケットは赤色でマークされます。
The TSWTCM has been primarily designed for traffic streams that will be forwarded based on the AF PHB in core routers.
TSWTCMはコアルータにおけるAF PHBに基づいて進められる交通の流れのために主として設計されています。
Fang, et al. Experimental [Page 1] RFC 2859 TSWTCM June 2000
牙、他 [1ページ]実験的なRFC2859TSWTCM2000年6月
The TSWTCM operates based on simple control theory principles of proportionally regulated feedback control.
TSWTCMは比例して規制されたフィードバック制御の簡単な制御理論原則に基づいて作動します。
2.0 Overview of TSWTCM
2.0 TSWTCMの概観
The TSWTCM consists of two independent components: a rate estimator, and a marker to associate a colour (drop precedence) with each packet. The marker uses the algorithm specified in section 4. If the marker is used with the AF PHB, each colour would correspond to a level of drop precedence.
TSWTCMは2つの独立しているコンポーネントから成ります: 色(先行を落とす)を各パケットに関連づけるレート見積り人、およびマーカー。 マーカーはセクション4で指定されたアルゴリズムを使用します。 マーカーがAF PHBと共に使用されるなら、各色は低下先行のレベルに対応しているでしょう。
The rate estimator provides an estimate of the running average bandwidth. It takes into account burstiness and smoothes out its estimate to approximate the longer-term measured sending rate of the traffic stream.
レート見積り人は移動平均帯域幅の見積りを提供します。 それは、交通の流れの、より長い期間の測定送付速度に近似するためにburstinessを考慮に入れて、見積りを取り除きます。
The marker uses the estimated rate to probabilistically associate packets with one of the three colours. Using a probabilistic function in the marker is beneficial to TCP flows as it reduces the likelihood of dropping multiple packets within a TCP window. The marker also works correctly with UDP traffic, i.e., it associates the appropriate portion of the UDP packets with yellow or red colour marking if such flows transmit at a sustained level above the contracted rate.
マーカーは、probabilisticallyに3つの色の1つにパケットを関連づけるのに見積率を使用します。 TCPの窓の中で複数のパケットを落とすという見込みを減少させるので、マーカーで確率的な機能を使用するのはTCP流れに有益です。 また、マーカーはUDP交通で正しく働いています、すなわち、そのような流れが契約率より上でレベル維持で伝わるなら、それがUDPパケットの適切な部分を黄色か赤色マークに関連づけます。
+---------+
| Rate | Rate
|estimator| ==========
| | |
+---------+ |
^ V
| +---------+
| | |
Packet ====================>| Marker |====> Marked packet stream
Stream | | (Green, Yellow and Red)
+---------+
+---------+ | レート| レート|見積り人| ========== | | | +---------+ | ^V| +---------+ | | | パケット====================>| マーカー|====>は、パケットの流れがStreamであるとマークしました。| | (グリーン、黄色、および赤) +---------+
Figure 1. Block diagram for the TSWTCM
図1。 TSWTCMのためのブロック図
The colour of the packet is translated into a DS field packet marking. The colours red, yellow and green translate into DS codepoints representing drop precedence 2, 1 and 0 of a single AF class respectively.
パケットの色はDS分野パケットマークに翻訳されます。 赤、黄色、および緑色がそれぞれ1つのAFのクラスの低下先行2、1、および0を表すDS codepointsに翻訳する色。
Based on feedback from four different implementations, the TSWTCM is simple and straightforward to implement. The TSWTCM can be implemented in either software or hardware depending on the nature of the forwarding engine.
4つの異なった実現からのフィードバックに基づいて、TSWTCMは、実行するために簡単であって、簡単です。 推進エンジンの自然によって、ソフトウェアかハードウェアのどちらかでTSWTCMを実行できます。
Fang, et al. Experimental [Page 2] RFC 2859 TSWTCM June 2000
牙、他 [2ページ]実験的なRFC2859TSWTCM2000年6月
3.0 Rate Estimator
3.0 レート見積り人
The Rate Estimator provides an estimate of the traffic stream's arrival rate. This rate should approximate the running average bandwidth of the traffic stream over a specific period of time (AVG_INTERVAL).
Rate Estimatorは交通の流れの到着率の見積りを提供します。 このレートは特定の期間(AVG_INTERVAL)の間、交通の流れの移動平均帯域幅に近似するべきです。
This memo does not specify a particular algorithm for the Rate Estimator. However, different Rate Estimators should yield similar results in terms of bandwidth estimation over the same fixed window (AVG_INTERVAL) of time. Examples of Rate Estimation schemes include: exponential weighted moving average (EWMA) and the time-based rate estimation algorithm provided in [TON98].
このメモは特定のアルゴリズムをRate Estimatorに指定しません。 しかしながら、異なったRate Estimatorsは時間の同じはめ殺し窓(AVG_INTERVAL)の上で帯域幅見積りで同様の結果をもたらすはずです。 Rate Estimation計画に関する例は: 指数の荷重している移動平均線(EWMA)と時間ベースのレート見積りアルゴリズムは[TON98]に提供されました。
Preferably, the Rate Estimator SHOULD maintain time-based history for its bandwidth estimation. However, the Rate Estimator MAY utilize weight-based history. In this case, the Estimator used should discuss how the weight translates into a time-window such as AVG_INTERVAL.
望ましくは、Rate Estimator SHOULDは帯域幅見積りのための時間ベースの歴史を維持します。 しかしながら、Rate Estimatorは重さのベースの歴史を利用するかもしれません。 この場合、使用されるEstimatorは重さにどうAVG_INTERVALなどのタイムウィンドウに翻訳されるかについて議論するはずです。
Since weight-based Estimators track bandwidth based on packet arrivals, a high-sending traffic stream will decay its past history faster than a low-sending traffic stream. The time-based Estimator is intended to address this problem. The latter Rate Estimator utilizes a low-pass filter decaying function. [FANG99] shows that this Rate Estimator decays past history independently of the traffic stream's packet arrival rate. The algorithm for the Rate Estimator from [TON98] is shown in Figure 2 below.
重さのベースのEstimatorsがパケット到着に基づく帯域幅を追跡するので、高く発信している交通の流れは低く発信している交通の流れより速く過去の歴史を腐食するでしょう。 時間ベースのEstimatorがこのその問題を訴えることを意図します。 後者のRate Estimatorはローパスフィルタ腐食機能を利用します。 [FANG99]は、このRate Estimatorが交通の流れのパケット到着率の如何にかかわらず過去の歴史を腐食するのを示します。 [TON98]からのRate Estimatorのためのアルゴリズムは以下の図2に示されます。
Fang, et al. Experimental [Page 3] RFC 2859 TSWTCM June 2000
牙、他 [3ページ]実験的なRFC2859TSWTCM2000年6月
======================================================================== |Initially: | | | | AVG_INTERVAL = a constant; | | avg-rate = CTR; | | t-front = 0; | | | |Upon each packet's arrival, the rate estimator updates its variables: | | | | Bytes_in_win = avg-rate * AVG_INTERVAL; | | New_bytes = Bytes_in_win + pkt_size; | | avg-rate = New_bytes/( now - t-front + AVG_INTERVAL); | | t-front = now; | | | |Where: | | now = The time of the current packet arrival | | pkt_size = The packet size in bytes of the arriving packet | | avg-rate = Measured Arrival Rate of traffic stream | | AVG_INTERVAL = Time window over which history is kept | | | | | | Figure 2. Example Rate Estimator Algorithm | | | ========================================================================
======================================================================== |初めは: | | | | AVG_INTERVALは定数と等しいです。 | | avg-レートはCTRと等しいです。 | | t-前部=0。 | | | |各パケットの到着のときに、レート見積り人は変数をアップデートします: | | | | _のバイト_は=avg-レート*AVG_INTERVALを獲得します。 | | _のバイト新しい_バイト=_は_サイズを+ pktに得ます。 | | 新しい_avg-レート=バイト/(今度は、+ AVG_INTERVALにtで向かってください)。 | | 現在のt-前部=。 | | | |どこ: | | =現在現在のパケット到着の時間| | pkt_サイズは到着パケットのバイトで表現されるパケットサイズと等しいです。| | avg-レート=は交通の流れのArrival Rateを測定しました。| | AVG_INTERVALは歴史が保管されるタイムウィンドウと等しいです。| | | | | | 図2。 例のレート見積り人アルゴリズム| | | ========================================================================
The Rate Estimator MAY operate in the Router Forwarding Path or as a background function. In the latter case, the implementation MUST ensure that the Estimator provides a reasonably accurate estimation of the sending rate over a window of time. The Rate Estimator MAY sample only certain packets to determine the rate.
Rate EstimatorはRouter Forwarding Pathかバックグラウンド機能として作動するかもしれません。 後者の場合では、実現は、Estimatorが送付レートの合理的に正確な見積りを時間の窓の上に供給するのを確実にしなければなりません。 Rate Estimatorは、レートを測定するためにあるパケットだけを抽出するかもしれません。
4.0 Marker
4.0 マーカー
The Marker determines the colour of a packet based on the algorithm presented in Figure 3. The overall effect of the marker on the packets of a traffic stream is to ensure that:
Markerは図3に提示されたアルゴリズムに基づくパケットの色を決定します。 交通の流れのパケットへのマーカーの総合的な効果は以下のことを保証することです。
- If the estimated average rate is less than or equal to the CTR,
packets of the stream are designated green.
- およそ平均相場が、よりCTR以下であるなら、流れのパケットは緑色に指定されます。
- If the estimated average rate is greater than the CTR but less
than or equal to the PTR, packets are designated yellow with
probability P0 and designated green with probability (1-P0).
P0 is the fraction of packets contributing to the measured
rate beyond the CTR.
- およそ平均相場がCTRにもかかわらず、よりPTRより大きいなら、パケットは、確率P0と共に黄色に指定されて、確率(1-P0)で緑色に指定されます。 P0はCTRを超えた従量制に貢献するパケットの部分です。
Fang, et al. Experimental [Page 4] RFC 2859 TSWTCM June 2000
牙、他 [4ページ]実験的なRFC2859TSWTCM2000年6月
=================================================================== | avg-rate = Estimated Avg Sending Rate of Traffic Stream | | | | if (avg-rate <= CTR) | | the packet is green; | | else if (avg-rate <= PTR) AND (avg-rate > CTR) | | (avg-rate - CTR) | | calculate P0 = ---------------- | | avg-rate | | with probability P0 the packet is yellow; | | with probability (1-P0) the packet is green; | | else | | (avg-rate - PTR) | | calculate P1 = ---------------- | | avg-rate | | (PTR - CTR) | | calculate P2 = ----------- | | avg-rate | | with probability P1 the packet is red; | | with probability P2 the packet is yellow; | | with probability (1-(P1+P2)) the packet is green; | | | | Figure 3. TSWTCM Marking Algorithm | ===================================================================
=================================================================== | Traffic StreamのAvg Sending Rateであると見積もられていたavg-レート=| | | | (avg-レート<=CTR)です。| | パケットは緑色です。 | | ほか、(avg-レート<=PTR)と(avg-レート>CTR)です。| | (avg評価してください--CTR) | | P0=について計算してください。---------------- | | avg-レート| | 確率P0と共に、パケットは黄色いです。 | | 確率(1-P0)に、パケットは緑色です。 | | ほか| | (avg評価してください--PTR) | | P1=について計算してください。---------------- | | avg-レート| | (PTR--CTR) | | P2=について計算してください。----------- | | avg-レート| | 確率P1と共に、パケットは赤いです。 | | 確率P2と共に、パケットは黄色いです。 | | 確率(1(P1+P2))に、パケットは緑色です。 | | | | 図3。 アルゴリズムをマークするTSWTCM| ===================================================================
- If the estimated average rate is greater than the PTR,
packets are designated red with probability P1, designated
yellow with probability P2 and designated green with probability
(1-(P1+P2)). P1 is the fraction of packets contributing
to the measured rate beyond the PTR. P2 is the fraction of
packets contributing to that part of the measured rate
between CTR and PTR.
- およそ平均相場がPTRより大きいなら、パケットは、確率P1と共に赤に指定されて、確率P2と共に黄色に指定されて、確率(1(P1+P2))で緑色に指定されます。 P1はPTRを超えた従量制に貢献するパケットの部分です。 P2はCTRとPTRの間の従量制のその部分に貢献するパケットの部分です。
The marker MUST operate in the forwarding path of all packets.
マーカーはすべてのパケットの推進経路で働かなければなりません。
5.0 Configuration
5.0 構成
5.1 Rate estimator
5.1 レート見積り人
If the Rate Estimator is time-based, it should base its bandwidth estimate on the last AVG_INTERVAL of time. AVG_INTERVAL is the amount of history (recent time) that should be used by the algorithm in estimating the rate. Essentially it represents the window of time included in the Rate Estimator's most recent result.
Rate Estimatorが時間ベースであるなら、それは帯域幅見積りを時間の最後のAVG_INTERVALに基礎づけるべきです。 AVG_INTERVALはレートを見積もる際にアルゴリズムで費やされるべきである歴史(最近の時間)の量です。 本質的にはそれはRate Estimatorの最新の結果に時間を含む窓を表します。
The value of AVG_INTERVAL SHOULD be configurable, and MAY be specified in either milliseconds or seconds.
AVG_INTERVAL SHOULDの値は、構成可能であり、ミリセカンドか秒のどちらかに指定されるかもしれません。
Fang, et al. Experimental [Page 5] RFC 2859 TSWTCM June 2000
牙、他 [5ページ]実験的なRFC2859TSWTCM2000年6月
[TON98] recommends that for the case where a single TCP flow constitutes the contracted traffic, AVG_INTERVAL be configured to approximately the same value as the RTT of the TCP flow. Subsequent experimental studies in [GLOBE99] utilized an AVG_INTERVAL value of 1 second for scenarios where the contracted traffic consisted of multiple TCP flows, some with different RTT values. The latter work showed that AVG_INTERVAL values larger than the largest RTT for a TCP flow in an aggregate can be used as long as the long-term bandwidth assurance for TCP aggregates is measured at a granularity of seconds. The AVG_INTERVAL value of 1 second was also used successfully for aggregates with UDP flows.
[TON98]は、AVG_INTERVAL、ただ一つのTCP流動が収縮した交通を構成するケースのためのそれがTCP流動のRTTとほとんど同じ値に構成されることを勧めます。 [GLOBE99]のその後の実証研究は収縮した交通が成った複数のTCP流れ(異なったRTT値があるいくつか)のシナリオに1秒のAVG_INTERVAL値を利用しました。 後者の仕事はTCP集合のための長期の帯域幅保証が秒の粒状で測定される限り、集合におけるTCP流動のための最も大きいRTTを使用できるより大きい値をそのAVG_INTERVALに示しました。 また、1秒のAVG_INTERVAL値は集合にUDP流れで首尾よく使用されました。
If the Rate Estimator is weight-based, the factor used in weighting history - WEIGHT - SHOULD be a configurable parameter.
Rate Estimatorが重さのベースであるなら、要素は歴史に重みを加える際に--WEIGHT--SHOULDを使用しました。構成可能なパラメタになってください。
The Rate Estimator measures the average sending rate of the traffic stream based on the bytes in the IP header and IP payload. It does not include link-specific headers in its estimation of the sending rate.
交通の平均した送付速度のRate Estimator測定はIPヘッダーとIPペイロードのバイトに基づいて流れます。 それは送付レートに関する見積りにリンク特有のヘッダーを含んでいません。
5.2 Marker
5.2 マーカー
The TSWTCM marker is configured by assigning values to its two traffic parameters: Committed Target Rate (CTR) and Peak Target Rate (PTR).
TSWTCMマーカーは2つの交通パラメタに値を割り当てることによって、構成されます: 遂行された目標金利(CTR)とピークはレート(PTR)を狙います。
The PTR MUST be equal to or greater than the CTR.
PTR MUST、CTRより等しいか、またはすばらしくいてください。
The CTR and PTR MAY be specifiable in bits per second or bytes per second.
CTRとPTR MAY、1秒あたりのbpsかバイトでは、明記できてください。
The TSWTCM can be configured so that it essentially operates with a single rate. If the PTR is set to the same value as the CTR then all packets will be coloured either green or red. There will be no yellow packets.
TSWTCMを構成できるので、それは単一賃率で本質的には作動します。 PTRがCTRと同じ値に用意ができていると、すべてのパケットが緑色か赤のどちらかに着色されるでしょう。 どんな黄色いパケットもないでしょう。
If the PTR is set to link speed and the CTR is set below the PTR then all packets will be coloured either green or yellow. There will be no red packets.
PTRが速度をリンクするように用意ができていて、CTRがPTRの下で用意ができていると、すべてのパケットが緑色か黄色のどちらかに着色されるでしょう。 どんな赤いパケットもないでしょう。
6.0 Scaling properties
6.0 スケーリングの特性
The TSWTCM can work with both sender-based service level agreements and receiver-based service level agreements.
TSWTCMは送付者ベースのサービスレベル協定と受信機ベースのサービスレベル協定の両方で働くことができます。
Fang, et al. Experimental [Page 6] RFC 2859 TSWTCM June 2000
牙、他 [6ページ]実験的なRFC2859TSWTCM2000年6月
7.0 Services
7.0 サービス
There are no restrictions on the type of traffic stream for which the TSWTCM can be utilized. It can be used to meter and mark individual TCP flows, aggregated TCP flows, aggregates with both TCP and UDP flows [UDPTCP] etc.
TSWTCMを利用できる交通の流れのタイプの上に制限が全くありません。 個々のTCP流れを計量して、マークするのにそれを使用できて、集められたTCPは流れて、TCPとUDP流れの両方[UDPTCP]がある集合はなどです。
The TSWTCM can be used in conjunction with the AF PHB to create a service where a service provider can provide decreasing levels of bandwidth assurance for packets originating from customer sites.
サービスプロバイダーがパケットのための減少しているレベルを帯域幅保証を提供できるところで顧客サイトから発しながらサービスを作成するのにAF PHBに関連してTSWTCMを使用できます。
With sufficient over-provisioning, customers are assured of mostly achieving their CTR. Sending rates beyond the CTR will have lesser assurance of being achieved. Sending rates beyond the PTR have the least chance of being achieved due to high drop probability of red packets.
十分な食糧を供給し過ぎることで、顧客は彼らのCTRをほとんど達成するのについて確信しています。 CTRを超えてレートを送るのにおいて、達成されることの、より少ない保証があるでしょう。 PTRを超えた送付レートに、赤いパケットの高い低下確率のため達成されるという最少の機会があります。
Based on the above, the Service Provider can charge a tiered level of service based on the final achieved rate.
上記に基づいて、Service Providerは最終的な達成されたレートに基づくtieredレベルのサービスを請求できます。
8.0 Security Considerations
8.0 セキュリティ問題
TSWTCM has no known security concerns.
TSWTCMには、知られている安全上の配慮が全くありません。
9.0 Acknowledgements
9.0 承認
The authors would like to thank Juha Heinanen, Kenjiro Cho, Ikjun Yeom and Jamal Hadi Salim for their comments on earlier versions of this document. Their suggestions are incorporated in this memo.
作者はこのドキュメントの以前のバージョンの彼らのコメントについてユハHeinanen、Kenjiro Cho、Ikjun Yeom、およびジャマル・ハディ・サリムに感謝したがっています。 彼らの提案はこのメモに組み込んでいます。
10.0 References
10.0の参照箇所
[TON98] D.D. Clark, W. Fang, "Explicit Allocation of Best Effort
Packet Delivery Service", IEEE/ACM Transactions on
Networking, August 1998, Vol 6. No. 4, pp. 362-373.
[TON98] D.D.クラーク、W.牙、「ベストエフォート型パケットデリバリ・サービスの明白な配分。」(1998年8月にVol6をネットワークでつなぐときのIEEE/ACM取引) No.4、ページ 362-373.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition
of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and
W. Weiss, "An Architecture for Differentiated Services",
RFC 2475, December 1998.
[RFC2475] 黒とD.とブレークとS.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。
[FANG99] Fang, W. "The 'Expected Capacity' Framework: Simulation
Results", Princeton University Technical Report, TR-601-99,
March, 1999.
[FANG99]牙、W.「'予想された容量'枠組み:、」 「シミュレーションの結果」、プリンストン大学技術報告書、TR-601-99、1999年3月。
Fang, et al. Experimental [Page 7] RFC 2859 TSWTCM June 2000
牙、他 [7ページ]実験的なRFC2859TSWTCM2000年6月
[YEOM99] I. Yeom, N. Reddy, "Impact of Marking Strategy on
Aggregated Flows in a Differentiated Services Network",
Proceedings of IwQoS, May 1999.
[YEOM99]I.Yeom、N.レディ、「微分されたサービスネットワークの集められた流れへのマーク戦略の影響」(IwQoSの議事)は1999がそうするかもしれません。
[AFPHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[AFPHB] HeinanenとJ.とベイカーとF.とウィスとW.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、1999年6月。
[UDPTCP] P. Pieda, N. Seddigh, B. Nandy, "The Dynamics of TCP and
UDP Interaction in IP-QoS Differentiated Service Networks",
Proceedings of the 3rd Canadian Conference on Broadband
Research (CCBR), Ottawa, November 1999
[UDPTCP] P.Pieda、N.Seddigh、B.ナンディ、「IP-QoSでのTCPとUDP相互作用の力学はサービスネットワークを微分した」(CCBR)、広帯域のResearchオタワの第3カナダのコンファレンスの議事、1999年11月
[GLOBE99] N. Seddigh, B. Nandy, P. Pieda, "Bandwidth Assurance Issues
for TCP flows in a Differentiated Services Network",
Proceedings of Global Internet Symposium, Globecom 99, Rio
De Janeiro, December 1999.
[GLOBE99]N.Seddigh、B.ナンディ、P.Pieda、「TCPのための帯域幅Assurance IssuesはDifferentiated Services Networkを流れます」、GlobalインターネットSymposiumのProceedings、Globecom99、リオDe Janeiro、1999年12月。
11.0 Authors' Addresses
11.0 作者のアドレス
Wenjia Fang Computer Science Dept. 35 Olden Street, Princeton, NJ08540
Wenjia牙のコンピュータサイエンス部 35のOlden通り、プリンストンNJ08540
EMail: wfang@cs.princeton.edu
メール: wfang@cs.princeton.edu
Nabil Seddigh Nortel Networks, 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada
Nabil Seddighノーテルネットワーク、3500縦梁Aveオタワ、オンK2H8の9Eのカナダ
EMail: nseddigh@nortelnetworks.com
メール: nseddigh@nortelnetworks.com
Biswajit Nandy Nortel Networks, 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada
Biswajitナンディノーテルネットワーク、3500縦梁Aveオタワ、オンK2H8の9Eのカナダ
EMail: bnandy@nortelnetworks.com
メール: bnandy@nortelnetworks.com
Fang, et al. Experimental [Page 8] RFC 2859 TSWTCM June 2000
牙、他 [8ページ]実験的なRFC2859TSWTCM2000年6月
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Fang, et al. Experimental [Page 9]
牙、他 実験的[9ページ]
一覧
スポンサーリンク
