Network Working Group W. Fang
Request for Comments: 2859 Princeton University
Category: Experimental N. Seddigh
B. Nandy
Nortel Networks
June 2000
A Time Sliding Window Three Colour Marker (TSWTCM)
Status of this 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.
著作権（C）インターネット協会（2000）。全著作権所有。
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).
このメモは、差分-SERVトラフィックコンディショナ[RFC2475、RFC2474]の成分として使用することができるウィンドウスリーカラーマーカー（TSWTCM）を、スライディング時間を定義します。マーカーは、下流のルータにホップ挙動当たり保証転送（AF）（PHB）[AFPHB]によって扱われるパケットをマークすることを意図しています。 TSWTCMメートルトラフィックストリームとマーク・パケットを指定された2つの速度の測定されたスループットの相対的に基づいて、緑色、黄色、または赤色のいずれかに：コミット目標レート（CTR）とピーク目標レート（PTR）。
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.
タイムウィンドウスリーカラーマーカーをスライド（TSWTCM）は、赤、黄、緑の色でIPトラフィックストリームのパケットをマークするように設計されています。マーキングがコミット目標レート（CTR）とピーク目標レート（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に基づいて転送されるトラフィックストリームのために設計されています。
The TSWTCM operates based on simple control theory principles of proportionally regulated feedback control.
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つの独立したコンポーネントで構成されています。 AF PHBと共に使用されるマーカーは、各色ドロップ優先順位のレベルに対応する場合、マーカーは、セクション4で指定されたアルゴリズムを使用します。
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.
速度推定器は、移動平均の帯域幅の推定値を提供します。これは、アカウントのバースト性を考慮に入れると、トラフィックストリームの送信レート測定し、長期的に近似し、その推定値を平滑化します。
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.
マーカーは、確率的に3色のいずれかにパケットを関連付ける推定レートを使用しています。マーカーにおける確率関数を使用することは、TCPウィンドウ内で複数のパケットをドロップする可能性を低減するようにTCPフローに有益です。マーカーはまた、フローが収縮率上記持続レベルで送信する場合、すなわち、それはマーキング黄色または赤色とUDPパケットの適切な部分を対応付け、UDPトラフィックで正常に動作します。
+---------+
| Rate | Rate
|estimator| ==========
| | |
+---------+ |
^ V
| +---------+
| | |
Packet ====================>| Marker |====> Marked packet stream
Stream | | (Green, Yellow and Red)
+---------+
Figure 1. Block diagram for the TSWTCM
TSWTCM図1.ブロック図
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フィールドパケットに変換されます。 、赤、黄、緑の色は、それぞれ、単一のAFクラスのドロップ優先順位2、1及び0を表すDSコードポイントに変換します。
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は転送エンジンの性質に応じてソフトウェアまたはハードウェアで実装することができます。
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).
レート推定器は、トラフィックストリームの到着率の推定値を提供します。この速度は、特定の期間（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].
このメモはレート推定のための特定のアルゴリズムが指定されていません。しかし、異なるレート推定器は、時間の同じ固定窓（AVG_INTERVAL）を超える帯域幅推定の観点から同様の結果が得られるはずです。レート推定方式の例としては、指数加重移動平均（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.
好ましくは、速度推定器は、その帯域幅推定のための時間ベースの履歴を維持すべきです。しかし、速度推定器は、重量ベースの歴史を利用することができます。この場合、使用見積もりは重量が、そのような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.
重量ベースの推定量は、パケットの到着に基づいて帯域幅を追跡するので、高送信トラフィックストリームは、より高速、低送信トラフィックストリームよりもその過去の歴史を減衰します。時間ベースの見積もりは、この問題に取り組むことです。後者のレート推定は、ローパスフィルタの減衰機能を利用しています。 [FANG99]このレート見積もりが独立トラフィックストリームのパケット到達率の過去の歴史を減衰することを示しています。 【TON98]から速度推定アルゴリズムは、以下の図2に示されています。
========================================================================
|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 |
| |
========================================================================
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.
レート推定器は、ルータのフォワーディングパスやバックグラウンド機能として動作することができます。後者の場合、実装は、推定器は、時間のウィンドウにわたって送信レートの合理的に正確な推定を提供することを保証しなければなりません。レート推定器は、速度を決定するためにのみ、特定のパケットをサンプリングしてもよいです。
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:
マーカーは、図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を超えた測定率に貢献するパケットの割合です。
===================================================================
| 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 |
===================================================================
- 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.
マーカーは、すべてのパケットの転送パスで動作する必要があります。
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.
レート推定器は、時間ベースの場合、それは時間の最後AVG_INTERVALにその帯域幅推定値をベースにする必要があります。 AVG_INTERVALは率の推定にアルゴリズムによって使用されるべき歴史（最近の時間）の量です。基本的にそれは速度推定の最新の結果に含まれる時刻の窓を表しています。
The value of AVG_INTERVAL SHOULD be configurable, and MAY be specified in either milliseconds or seconds.
AVG_INTERVALの値が設定可能であるべきであり、ミリ秒または秒のどちらかで指定することができます。
[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】単一のTCPフローが契約トラフィックを構成する場合について、AVG_INTERVALは、TCPフローのRTTとほぼ同じ値に設定することをお勧めします。 【GLOBE99]における後続の実験的研究は、契約トラフィックが複数のTCPフロー、異なるRTT値の一部から構成シナリオの1秒のAVG_INTERVAL値を利用します。後者の作業はAVG_INTERVAL集約におけるTCPフローの最大RTTよりも大きい値であればTCP凝集体の長期的な帯域保証を秒の単位で測定されるように使用することができることを示しました。 1秒のAVG_INTERVAL値もUDPフローとの凝集のために首尾よく使用しました。
If the Rate Estimator is weight-based, the factor used in weighting history - WEIGHT - SHOULD be a configurable parameter.
レート推定器は重量ベースである場合、重み歴史の中で使用される因子 - 重量 - 設定可能なパラメータであるべきです。
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.
速度推定は、IPヘッダとIPペイロード内のバイトに基づいてトラフィック・ストリームの平均送信速度を測定します。これは、送信レートのその推定にリンク固有のヘッダが含まれていません。
The TSWTCM marker is configured by assigning values to its two traffic parameters: Committed Target Rate (CTR) and Peak Target Rate (PTR).
コミット目標レート（CTR）とピーク目標レート（PTR）：TSWTCMマーカーは、その2つのトラフィックパラメータに値を割り当てることによって構成されています。
The PTR MUST be equal to or greater than the CTR.
PTRは、CTR以上でなければなりません。
The CTR and PTR MAY be specifiable in bits per second or bytes per second.
CTRとPTRは、第二又は第二あたりのバイトあたりのビットで指定可能であるかもしれ。
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以下に設定されている場合は、すべてのパケットがいずれかの緑や黄色に着色されます。赤いパケットはありません。
The TSWTCM can work with both sender-based service level agreements and receiver-based service level agreements.
TSWTCMは、センダベースのサービス・レベル・アグリーメントとレシーバベースのサービスレベル契約の両方で動作することができます。
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.
TSWTCMは、サービスプロバイダが顧客サイトから発信するパケットのための帯域保証の減少レベルを提供することができるサービスを作成するAF PHBと組み合わせて使用することができます。
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.
上記に基づき、サービスプロバイダは、最終的な達成率に基づいて、サービスの階層レベルを充電することができます。
TSWTCM has no known security concerns.
TSWTCMには、既知のセキュリティ上の懸念を持っていません。
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、健次郎チョー、Ikjunヨムとジャマルハディサリムに感謝したいと思います。彼らの提案は、このメモに組み込まれています。
[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月にIEEE / ACM取引、巻6号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分野）の定義"、RFC 2474、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.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、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月。
[YEOM99] I. Yeom, N. Reddy, "Impact of Marking Strategy on Aggregated Flows in a Differentiated Services Network", Proceedings of IwQoS, May 1999.
[YEOM99] I.ヨム、N.レディ、IwQoS、1999年5月の、会報「集約に戦略をマーキングの影響は、差別化サービスネットワークに流れます」。
[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グループ"、RFC 2597、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. Nandy、 "TCPとIP-QoSの差別化されたサービスネットワークにおけるUDPの相互作用のダイナミクス"、ブロードバンド・リサーチ（CCBR）、オタワ、1999年11月に第3回カナダの会議議事録
[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. Nandy、P. Piedaは、グローバルインターネットシンポジウム、GLOBECOM 99、リオ・デ・ジャネイロ、1999年12月 "TCPのための帯域保証の問題は、差別化サービスネットワークに流れます"。
Wenjia Fang Computer Science Dept. 35 Olden Street, Princeton, NJ08540
N通りのWENホームファンGコンピュータサイエンス学科35 OL、プリンストン、NJ08540
EMail: wfang@cs.princeton.edu
メールアドレス：wfang@cs.princeton.edu
Nabil Seddigh Nortel Networks, 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada
ナビルSeddighノーテルネットワークス、3500カーリングアベニューオタワ、ON、K2H 8E9カナダ
EMail: nseddigh@nortelnetworks.com
メールアドレス：nseddigh@nortelnetworks.com
Biswajit Nandy Nortel Networks, 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada
Biswajit Nandyノーテルネットワークス、3500カーリングアベニューオタワ、ON、K2H 8E9カナダ
EMail: bnandy@nortelnetworks.com
メールアドレス：bnandy@nortelnetworks.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。