RFC4115 日本語訳
4115 A Differentiated Service Two-Rate, Three-Color Marker withEfficient Handling of in-Profile Traffic. O. Aboul-Magd, S. Rabie. July 2005. (Format: TXT=12131 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group O. Aboul-Magd
Request for Comments: 4115 S. Rabie
Category: Informational Nortel Networks
July 2005
Aboul-Magdがコメントのために要求するワーキンググループO.をネットワークでつないでください: 4115秒間Rabieカテゴリ: 情報のノーテルは2005年7月をネットワークでつなぎます。
A Differentiated Service Two-Rate, Three-Color Marker with
Efficient Handling of in-Profile Traffic
プロフィールの交通の効率的な取り扱いをもっている微分されたサービス2レートの、そして、三色のマーカー
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは配備されたプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実現と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
Abstract
要約
This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices.
このドキュメントはFrame Relayサービスを含むデータサービスに、使用中である2レートの、そして、三色のマーカーについて説明します。 現れているIPとL2 VPNサービスにおける1流れあたりの計量交通にこのマーカーを使用できます。 ここで定義されたマーカーは以前に定義されたマーカーとプロフィールの交通の取り扱いにおいて異なっています。 その上、このマーカーは顧客縁(CE)の装置にピークレート形成要件を課しません。
1. Introduction
1. 序論
The differentiated service defines a quality-of-service (QoS) architecture for the Internet [RFC2475]. Two integral components of this architecture are traffic metering and marking. This document describes a two-rate, three-color metering/marker algorithm that is
微分されたサービスはサービスの質(QoS)構造をインターネット[RFC2475]と定義します。 この構造の2つの不可欠の成分は、交通計量とマークです。 このドキュメントは2レートの、そして、三色の計量/マーカーアルゴリズムを説明します。
Aboul-Magd & Rabie Informational [Page 1] RFC 4115 Efficient Handling of in-Profile Traffic July 2005
プロフィールの交通2005年7月のAboul-Magd&Rabieの情報[1ページ]のRFC4115の効率的な取り扱い
suitable for the differentiated service applications such as IP and L2 VPNs. This algorithm has been in use for data services including Frame Relay Service.
IPやL2 VPNsなどの微分されたサービスアプリケーションに適しています。 Frame Relay Serviceを含むデータサービスに、このアルゴリズムは使用中です。
The metering/marker defined here is different from those in [RFC2697] and [RFC2698]. It is different from [RFC2697] in that it is a two- rate, three-color marker. In contrast, [RFC2697] is a single-rate marker. It is different from [RFC2698] in the way its parameters are defined, which allows a better handling of in-profile traffic for predominant service scenarios over a wider range of traffic parameters.
ここで定義された計量/マーカーは[RFC2697]と[RFC2698]のそれらと異なっています。 それは[RFC2697]とそれが2レート、三色のマーカーであるという点において異なっています。 対照的に、[RFC2697]は単一賃率マーカーです。 それは[RFC2698]とパラメタが定義される方法で異なっています。(それは、より広い範囲の交通パラメタにわたる支配的なサービスシナリオのためのプロフィールの交通の、より良い取り扱いを許します)。
Furthermore, the algorithm described here eliminates the need for the CE to shape its traffic to a certain peak information rate (PIR), as might be the case for the marker defined in [RFC2698] when the value for the peak burst size (PBS) is smaller than that for the committed burst size (CBS).
その上、ここで説明されたアルゴリズムはCEが、あるピーク情報レート(PIR)に交通を形成する必要性を排除します、ピーク放出量(PBS)のための値が遂行された放出量(CBS)のためのそれより小さいときに、[RFC2698]で定義されたマーカーのためにそうであるかもしれないように。
The marker described here operates for both color-blind and color- aware modes, as defined in [RFC2698].
ここで説明されたマーカーはともに色盲と色の意識しているモードのために[RFC2698]で定義されるように働いています。
2. Configuration
2. 構成
The operation of the marker is described by two rate values. The committed information rate (CIR) and the excess information rate (EIR). CIR and EIR define the token generation rate of a token bucket with size that is equal to committed burst size (CBS) and excess burst size (EBS), respectively.
マーカーの操作は2つのレート値によって説明されます。 認定情報速度(CIR)と余分な情報は(EIR)を評定します。 CIRとEIRはそれぞれ遂行された放出量(CBS)と等しいサイズがある象徴バケツ対過剰放出量(EBS)の象徴世代率を定義します。
The CBS and EBS are measured in bytes and must configure to be greater than the expected maximum length of the incoming PDU. The CIR and EIR are both measured in bits/s. The CIR and EIR can be set independently of each other. Alternatively, the CIR and EIR can be linked together by defining a burst duration parameter, T, where T=CBS/CIR=EBS/EIR.
CBSとEBSは、バイトで測定されて、入って来るPDUの予想された最大の長さよりすばらしいのを構成しなければなりません。 CIRとEIRはビット/sでともに測定されます。 CIRとEIRは互いの如何にかかわらず用意ができることができます。 あるいはまた、炸裂持続時間パラメタ、T、どこT=CBS/CIR=EBS/EIRを定義するかによって、CIRとEIRを結びつけることができます。
3. Metering and Marking
3. 計量とマーク
The behavior of the meter is defined in terms of its mode and two token buckets, C and E, with the rates, CIR and EIR, respectively, and maximum sizes CBS and EBS.
メーターの働きはレート、CIR、およびEIRがあるそのモードと2象徴バケツ、C、およびEに関してそれぞれ定義されます、そして、最大はCBSとEBSを大きさで分けます。
The token buckets C and E are initially (at time 0) full; i.e., the token count Tc(0) = CBS and Te(0) = EBS. Thereafter, the token count Tc is incremented by one CIR times per second (up to CBS), and the token count Te is incremented by one EIR times per second (up to EBS).
初めは(時0に)象徴バケツCとEがそうである、完全。 すなわち、象徴カウントTc(0)はCBSと等しいです、そして、Te(0)はEBSと等しいです。 その後、象徴カウントTcは秒(CBSまでの)あたり1CIR倍増加されます、そして、象徴カウントTeは秒(EBSまでの)あたり1EIR倍増加されます。
Aboul-Magd & Rabie Informational [Page 2] RFC 4115 Efficient Handling of in-Profile Traffic July 2005
プロフィールの交通2005年7月のAboul-Magd&Rabieの情報[2ページ]のRFC4115の効率的な取り扱い
In the color-aware operation, it is assumed that the algorithm can recognize the color of the incoming packet (green, yellow, or red). The color-aware operation of the metering is described below.
色の意識している操作では、アルゴリズムが入って来るパケット(緑色の、または、黄色いか、赤の)の色を認識できると思われます。 計量の色の意識している操作は以下で説明されます。
When a green packet of size B arrives at time t, then
次に、サイズBの緑色のパケットが時間tに到着する場合
o if Tc(t)- B > 0, the packet is green, and Tc(t) is decremented
by B; else
o B>0、パケットが緑色であり、Tc(t)がBで減少するというTc(t)です。 ほか
o if Te(t)- B > 0, the packet is yellow, and Te(t) is decremented
by B; else
o B>0、パケットが黄色く、Te(t)がBで減少するというTe(t)です。 ほか
o the packet is red.
o パケットは赤いです。
When a yellow packet of size B arrives at time t, then
次に、サイズBの黄色いパケットが時間tに到着する場合
o if Te(t)- B > 0, the packet is yellow, and Te(t) is decremented
by B; else
o B>0、パケットが黄色く、Te(t)がBで減少するというTe(t)です。 ほか
o the packet is red.
o パケットは赤いです。
Incoming red packets are not tested against any of the two token buckets and remain red.
入って来る赤いパケットは、2個の象徴バケツのどれかに対してテストされないで、赤いままで残っています。
In the color-blind operation, the meter assumes that all incoming packets are green. The operation of the meter is similar to that in the color-aware operation for green packets.
色盲の操作では、メーターは、すべての入って来るパケットが緑色であると仮定します。 メーターの操作は緑色のパケットのための色の意識している操作においてそれと同様です。
The salient feature of the algorithm described above is that traffic within the defined CIR is colored green directly, without the need to pass additional conformance tests. This feature is the main differentiator of this algorithm from that described in [RFC2698], where traffic is marked green after it passes two conformance tests (those for PIR and CIR). In either color-blind or color-aware mode, the need to pass two conformance tests could result in packets being dropped at the PIR token bucket even though they are perfectly within their CIR (in-profile traffic). Furthermore, in the color-aware mode of operation, the need to pass two conformance tests could make yellow traffic starve incoming in-profile green packets.
上で説明されたアルゴリズムに関する特徴は定義されたCIRの中の交通が直接緑色に着色されるということです、追加順応テストに合格する必要性なしで。 この特徴は2つの順応テスト(PIRとCIRのためのそれら)に合格した後に交通が緑色であることが示される[RFC2698]で説明されたそれからのこのアルゴリズムの主な識別因子です。 色盲の、または、色の意識しているモードで、2つの順応テストに合格する必要性はそれらのCIR(プロフィールの交通)の中でそれらが完全に落とされますが、PIR象徴バケツで落とされるパケットをもたらすかもしれません。 その上、操作の色の意識しているモードで、黄色い交通は2つの順応テストに合格する必要性でプロフィールの入って来る緑色のパケットを飢えさせるかもしれません。
Aboul-Magd & Rabie Informational [Page 3] RFC 4115 Efficient Handling of in-Profile Traffic July 2005
プロフィールの交通2005年7月のAboul-Magd&Rabieの情報[3ページ]のRFC4115の効率的な取り扱い
The operation of the algorithm is illustrated in the flow chart below:
アルゴリズムの操作は以下のフローチャートで例証されます:
+---------------------------------+
|periodically every T sec. |
| Tc(t+)=MIN(CBS, Tc(t-)+CIR*T) |
| Te(t+)=MIN(EBS, Te(t-)+EIR*T) |
+---------------------------------+
+---------------------------------+ |定期的である、あらゆるT秒 | | Tc(t+)=分(CBS、Tc(t)+CIR*T)| | Te(t+)=分(EBS、Te(t)+EIR*T)| +---------------------------------+
Packet of size
B arrives /----------------\
---------------->|color-blind mode|
| OR |YES +---------------+
| green packet |---->|packet is green|
| AND | |Tc(t+)=Tc(t-)-B|
| B <= Tc(t-) | +---------------+
\----------------/
|
| NO
v
/----------------\
|color-blind mode|
| OR |YES +----------------+
| NOT red packet |---->|packet is yellow|
| AND | |Te(t+)=Te(t-)-B |
| B <= Te(t-) | +----------------+
\----------------/
|
| NO
v
+---------------+
|packet is red |
+---------------+
サイズBのパケットが到着する、/----------------\ ---------------->|色盲のモード| | OR|はい+---------------+ | 緑色のパケット|、-、-、--、>|パケットは緑色です。| | AND| |Tc(t+)はTc(t)-Bと等しいです。| | B<はTc(t)と等しいです。| +---------------+ \----------------/ | | vがありません/。----------------\ |色盲のモード| | OR|はい+----------------+ | 赤いパケットでない|、-、-、--、>|パケットは黄色いです。| | AND| |Te(t+)はTe(t)-Bと等しいです。| | B<はTe(t)と等しいです。| +----------------+ \----------------/ | | +に対していいえ---------------+ |パケットは赤いです。| +---------------+
Figure 1: Traffic Metering/Marking Algorithm
図1: アルゴリズムを計量するか、またはマークする交通
In Figure 1, we have X(t-) and X(t+) to indicate the value of a parameter X right before and right after time t.
図1では、私たちは時間の前と時間t直後パラメタX権利の値を示すX(t)とX(t+)を持っています。
Aboul-Magd & Rabie Informational [Page 4] RFC 4115 Efficient Handling of in-Profile Traffic July 2005
プロフィールの交通2005年7月のAboul-Magd&Rabieの情報[4ページ]のRFC4115の効率的な取り扱い
4. Service Scenario
4. サービスシナリオ
The described marker can be used to mark an IP packet stream in a service where different, decreasing levels of assurances (either absolute or relative) are given to packets that are green, yellow, or red. For example, a service may discard all red packets because they exceeded the service rates, forward yellow packets as best effort, and forward green packets with low drop probability. The marker could also be used for metering L2 VPN services such as the emerging Ethernet transport over IP networks.
説明されたマーカーは、異なって、減少しているレベルを保証(絶対の、または、相対的な)を緑色であることのパケットに与えるところでサービスにおけるIPパケットの流れをマークするのにおいて中古であるか、黄色いか、または赤である場合があります。 例えば、サービス率、ベストエフォート型としての前進の黄色いパケット、および低低下確率がある前進の緑色のパケットを超えていたので、サービスはすべての赤いパケットを捨てるかもしれません。 また、IPネットワークの上の現れているイーサネット輸送などの計量L2 VPNサービスにマーカーを使用できました。
5. Security Considerations
5. セキュリティ問題
Security issues resulting from this document are similar to those mentioned in [RFC2697] and [RFC2698].
このドキュメントから生じる安全保障問題は[RFC2697]と[RFC2698]で言及されたものと同様です。
6. Informative References
6. 有益な参照
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated Service",
RFC 2475, December 1998.
[RFC2475] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「微分されたサービスのための構造」RFC2475、1998年12月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999.
[RFC2697] HeinanenとJ.とR.ゲラン、「単一賃率Threeカラーマーカー」、RFC2697、1999年9月。
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, September 1999.
[RFC2698] HeinanenとJ.とR.ゲラン、「2レートThreeカラーマーカー」、RFC2698、1999年9月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H.、「IESGとRFCエディタは以下を記録します」。 「手順」、BCP92、RFC3932、2004年10月。
Authors' Addresses
作者のアドレス
Osama Aboul-Magd Nortel Networks 3500 Carling Ave Ottawa, ON K2H8E9 EMail: osama@nortel.com
オサマAboul-Magdノーテルは3500縦梁AveオタワをK2H8E9メールにネットワークでつなぎます: osama@nortel.com
Sameh Rabie Nortel Networks 3500 Carling Ave Ottawa, ON K2H8E9 EMail: rabie@nortel.com
Sameh Rabieノーテルは3500縦梁AveオタワをK2H8E9メールにネットワークでつなぎます: rabie@nortel.com
Aboul-Magd & Rabie Informational [Page 5] RFC 4115 Efficient Handling of in-Profile Traffic July 2005
プロフィールの交通2005年7月のAboul-Magd&Rabieの情報[5ページ]のRFC4115の効率的な取り扱い
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Aboul-Magd & Rabie Informational [Page 6]
Aboul-Magd&Rabie情報です。[6ページ]
一覧
スポンサーリンク
