[要約] RFC 4115は、効率的なインプロファイルトラフィックの処理を行うための異なるサービスの2レート、3色のマーカーについての規格です。このRFCの目的は、ネットワークトラフィックの優先順位付けと品質の向上を実現するためのマーキングメカニズムを提供することです。

Network Working Group                                      O. Aboul-Magd
Request for Comments: 4115                                      S. Rabie
Category: Informational                                  Nortel Networks
                                                               July 2005
        

A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic

プロファイルトラフィックの効率的な取り扱いを伴う2レート、3色マーカー

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)The Internet Society(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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932を参照してください。

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.

このドキュメントでは、フレームリレーサービスを含むデータサービスに使用されている2レートの3色マーカーについて説明します。このマーカーは、新興IPおよびL2 VPNサービスの流量ごとのトラフィックを測定するために使用できます。ここで定義されているマーカーは、プロファイルのトラフィックの取り扱いにおいて、以前に定義されたマーカーとは異なります。さらに、このマーカーは、顧客エッジ(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 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.

差別化されたサービスは、インターネットのサービス品質(QOS)アーキテクチャを定義します[RFC2475]。このアーキテクチャの2つの不可欠なコンポーネントは、トラフィックメーターとマーキングです。このドキュメントでは、IPやL2 VPNSなどの差別化されたサービスアプリケーションに適した2レートの3色計測/マーカーアルゴリズムについて説明します。このアルゴリズムは、フレームリレーサービスを含むデータサービスに使用されています。

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レートの3色マーカーであるという点です。対照的に、[RFC2697]は単一率マーカーです。[RFC2698]のパラメーターの定義方法では、[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).

さらに、ここで説明するアルゴリズムは、ピークバーストサイズ(PBS)の値が[RFC2698]で定義されているマーカーの場合に当てはまるように、CEが特定のピーク情報レート(PIR)にトラフィックを形作る必要性を排除します。コミットされたバーストサイズ(CBS)の場合よりも小さくなっています。

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は、互いに独立して設定できます。あるいは、CIRとEIRは、バースト期間パラメーターT、t = CBS/CIR = EBS/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.

メーターの動作は、そのモードと2つのトークンバケツ、CおよびEの観点から定義され、それぞれレート、CIRとEIR、および最大サイズのCBSおよびEBがあります。

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).

トークンバケットCとEは、最初は(時間0で)いっぱいです。つまり、トークンカウントTC(0)= CBSおよびTE(0)= EBS。その後、トークンカウントTCは1秒あたり1回(CBSまで)増加し、トークンカウントTEは1秒あたり1回のEIR時間(EBまで)増加します。

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 TC(T)-B> 0の場合、パケットは緑色で、TC(T)はBによって減少します。それ以外

o if Te(t)- B > 0, the packet is yellow, and Te(t) is decremented by B; else

o te(t)-b> 0の場合、パケットは黄色で、te(t)はbによって減少します。それ以外

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 te(t)-b> 0の場合、パケットは黄色で、te(t)はbによって減少します。それ以外

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内のトラフィックは、追加の適合テストに合格する必要がなく、直接緑色になっていることです。この機能は、[RFC2698]に記載されているものからのこのアルゴリズムの主な差別化要因であり、2つの適合テスト(PIRとCIRのもの)に合格した後、トラフィックが緑色にマークされています。色覚異常モードまたはカラーアウェアモードのいずれかで、2つの適合テストに合格する必要があるため、PIRトークンバケットにパケットがドロップされる可能性があります。さらに、カラーアウェアの動作モードでは、2つの適合テストに合格する必要があるため、黄色のトラフィックが侵入している緑のパケットを飢えさせる可能性があります。

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)   |
                   +---------------------------------+
        
          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  |
                          +---------------+
        

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には、x(t-)とx(t)があり、時間tの直前と直後にパラメーターxの値を示します。

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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「Distementiated Serviceの建築」、RFC 2475、1998年12月。

[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.

[RFC2697] Heinanen、J。およびR. Guerin、「単一レート3色マーカー」、RFC 2697、1999年9月。

[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, September 1999.

[RFC2698] Heinanen、J。およびR. Guerin、「A Rate Three Color Marker」、RFC 2698、1999年9月。

[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.

[RFC3932] Alvestrand、H。、「IESGおよびRFCエディタードキュメント:手順」、BCP 92、RFC 3932、2004年10月。

Authors' Addresses

著者のアドレス

Osama Aboul-Magd Nortel Networks 3500 Carling Ave Ottawa, ON K2H8E9 EMail: osama@nortel.com

Osama Aboul-Magd Nortel Networks 3500 Carling Ave Ottawa、on K2H8e9メール:osama@nortel.com

Sameh Rabie Nortel Networks 3500 Carling Ave Ottawa, ON K2H8E9 EMail: rabie@nortel.com

同一rabie nortelネットワーク3500カーリングアベニューオタワ、k2h8e9メール:rabie@nortel.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2005).

Copyright(c)The Internet Society(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.

この文書は、BCP 78および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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

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エディター機能の資金は現在、インターネット協会によって提供されています。