[要約] RFC 2859は、Time Sliding Window Three Colour Marker（TSWTCM）に関する要約と目的を提供します。TSWTCMは、トラフィックエンジニアリングやQoS管理に使用されるマーキングアルゴリズムです。
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)
タイムスライディングウィンドウ3色マーカー（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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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).
このメモは、時間のスライディングウィンドウ3色マーカー（TSWTCM）を定義します。これは、Diff-Servトラフィックコンディショナー[RFC2475、RFC2474]のコンポーネントとして使用できます。マーカーは、下流ルーターのホップあたりの保証式（AF）[AFPHB] [AFPHB]によって処理されるパケットをマークすることを目的としています。TSWTCMは、指定された2つのレート（COMTITED TARATE REATE（CTR）とPEAKターゲットレート（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.
タイムスライディングウィンドウ3色マーカー（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つの独立したコンポーネントで構成されています。レート推定器と、色を各パケットに関連付けるマーカーです。マーカーは、セクション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.
レート推定器は、実行平均帯域幅の推定値を提供します。それは、トラフィックストリームの長期測定された送信率に近似するために、破裂を考慮し、その推定値をスムーズにします。
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
図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フィールドパケットマーキングに変換されます。赤、黄色、緑の色は、それぞれ単一の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）の帯域幅推定に関して、同様の結果をもたらす必要があります。レート推定スキームの例には、[Ton98]で提供される指数加重移動平均（EWMA）と時間ベースのレート推定アルゴリズムが含まれます。
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フローで構成されているシナリオで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.
レート推定器が重量ベースの場合、重み付け履歴で使用される因子 - 重量 - は構成可能なパラメーターである必要があります。
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).
TSWTCMマーカーは、値を2つのトラフィックパラメーターに割り当てることによって構成されています：コミットされたターゲットレート（CTR）とピーク目標レート（PTR）。
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は、1秒あたりのビットまたは1秒あたりのバイトで指定される場合があります。
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.
著者は、この文書の以前のバージョンに関するコメントについて、Juha Heinanen、Kenjiro Cho、Ikjun Yeom、Jamal Hadi Salimに感謝したいと思います。彼らの提案はこのメモに組み込まれています。
[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.Clark、W。Fang、「Best Effect Effect Packet Delivery Serviceの明示的な割り当て」、IEEE/ACM Transactions on Networking、1998年8月、Vol 6. No. 4、pp。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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Black、D.、Blake、S.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[FANG99] Fang, W. "The 'Expected Capacity' Framework: Simulation Results", Princeton University Technical Report, TR-601-99, March, 1999.
[Fang99] Fang、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. Yeom、N。Reddy、「差別化されたサービスネットワークでの集約されたフローに対するマーキング戦略の影響」、1999年5月、IWQOSの議事録。
[AFPHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[AFPHB] Heinanen、J.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、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、「IP-QOS差別化されたサービスネットワークにおけるTCPおよびUDP相互作用のダイナミクス」、1999年11月、オタワ、ブロードバンド研究に関する第3カナダ会議（CCBR）の議事録
[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、「差別化されたサービスネットワークでのTCPフローの帯域幅保証の問題」、グローバルインターネットシンポジウムの議事録、Globecom 99、Rio de Janeiro、1999年12月。
Wenjia Fang Computer Science Dept. 35 Olden Street, Princeton, NJ08540
Wenjia Fang Computer Science Dept. 35 Olden Street、プリンストン、NJ08540
EMail: wfang@cs.princeton.edu
Nabil Seddigh Nortel Networks, 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada
Nabil Seddigh Nortel Networks、3500 Carling Ave Ottawa、ON、K2H 8E9カナダ
EMail: nseddigh@nortelnetworks.com
Biswajit Nandy Nortel Networks, 3500 Carling Ave Ottawa, ON, K2H 8E9 Canada
Biswajit Nandy Nortel Networks、3500 Carling Ave Ottawa、on、K2H 8e9 Canada
EMail: bnandy@nortelnetworks.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。