Network Working Group Y. Bernet
Request for Comments: 3290 Microsoft
Category: Informational S. Blake
Ericsson
D. Grossman
Motorola
A. Smith
Harbour Networks
May 2002
An Informal Management Model for Diffserv Routers
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture.
この文書では、彼らの管理と構成で使用するための差別化サービス（DiffServ）のルータの非公式の管理モデルを提案しています。このモデルは、機能的なデータ経路要素（例えば、分類、メートル、アクション、マーキング、絶対滴下、カウント、多重化）、アルゴリズム点滴、キューおよびスケジューラを定義します。それは、これらの要素のための可能な設定パラメータを記述し、それらはトラフィック調整の範囲とホップ単位動作（PHB）はDiffservアーキテクチャで説明の機能を実現するために相互接続されることがありますか。
Table of Contents
目次
1 Introduction ................................................. 3
2 Glossary ..................................................... 4
3 Conceptual Model ............................................. 7
3.1 Components of a Diffserv Router ............................ 7
3.1.1 Datapath ................................................. 7
3.1.2 Configuration and Management Interface ................... 9
3.1.3 Optional QoS Agent Module ................................ 10
3.2 Diffserv Functions at Ingress and Egress ................... 10
3.3 Shaping and Policing ....................................... 12
3.4 Hierarchical View of the Model ............................. 12
4 Classifiers .................................................. 13
4.1 Definition ................................................. 13
4.1.1 Filters .................................................. 15
4.1.2 Overlapping Filters ...................................... 15
4.2 Examples ................................................... 16
4.2.1 Behavior Aggregate (BA) Classifier ....................... 16
4.2.2 Multi-Field (MF) Classifier .............................. 17
4.2.3 Free-form Classifier ..................................... 17
4.2.4 Other Possible Classifiers ............................... 18
5 Meters ....................................................... 19
5.1 Examples ................................................... 20
5.1.1 Average Rate Meter ....................................... 20
5.1.2 Exponential Weighted Moving Average (EWMA) Meter ......... 21
5.1.3 Two-Parameter Token Bucket Meter ......................... 21
5.1.4 Multi-Stage Token Bucket Meter ........................... 22
5.1.5 Null Meter ............................................... 23
6 Action Elements .............................................. 23
6.1 DSCP Marker ................................................ 24
6.2 Absolute Dropper ........................................... 24
6.3 Multiplexor ................................................ 25
6.4 Counter .................................................... 25
6.5 Null Action ................................................ 25
7 Queuing Elements ............................................. 25
7.1 Queuing Model .............................................. 26
7.1.1 FIFO Queue ............................................... 27
7.1.2 Scheduler ................................................ 28
7.1.3 Algorithmic Dropper ...................................... 30
7.2 Sharing load among traffic streams using queuing ........... 33
7.2.1 Load Sharing ............................................. 34
7.2.2 Traffic Priority ......................................... 35
8 Traffic Conditioning Blocks (TCBs) ........................... 35
8.1 TCB ........................................................ 36
8.1.1 Building blocks for Queuing .............................. 37
8.2 An Example TCB ............................................. 37
8.3 An Example TCB to Support Multiple Customers ............... 42
8.4 TCBs Supporting Microflow-based Services ................... 44
8.5 Cascaded TCBs .............................................. 47
9 Security Considerations ...................................... 47
10 Acknowledgments ............................................. 47
11 References .................................................. 47
Appendix A. Discussion of Token Buckets and Leaky Buckets ...... 50
Authors' Addresses ............................................. 55
Full Copyright Statement........................................ 56
Differentiated Services (Diffserv) [DSARCH] is a set of technologies which allow network service providers to offer services with different kinds of network quality-of-service (QoS) objectives to different customers and their traffic streams. This document uses terminology defined in [DSARCH] and [NEWTERMS] (some of these definitions are included here in Section 2 for completeness).
差別化サービス（DiffServ）の[DSARCH]ネットワークサービスプロバイダーが異なる顧客とそのトラフィックストリームへのネットワークのサービス品質（QoS）の目的の異なる種類のサービスを提供できるようにする技術のセットです。この文書では、[DSARCH]と[NEWTERMS]（これらの定義のいくつかは、ここで完全なものにするため、セクション2に含まれている）で定義された用語を使用しています。
The premise of Diffserv networks is that routers within the core of the network handle packets in different traffic streams by forwarding them using different per-hop behaviors (PHBs). The PHB to be applied is indicated by a Diffserv codepoint (DSCP) in the IP header of each packet [DSFIELD]. The DSCP markings are applied either by a trusted upstream node, e.g., a customer, or by the edge routers on entry to the Diffserv network.
Diffservのネットワークの前提は、異なるホップごとの挙動（のPHB）を使用して転送することによって、異なるトラフィックストリームにおけるネットワークハンドルパケットのコア内のルータということです。適用されるPHBは、各パケット[DSFIELD]のIPヘッダ内のDiffservコードポイント（DSCP）で示されています。 DSCPマーキングは、信頼上流ノード、例えば、顧客によって、又はDiffservのネットワークへのエントリ上のエッジルータのいずれかによって適用されます。
The advantage of such a scheme is that many traffic streams can be aggregated to one of a small number of behavior aggregates (BA), which are each forwarded using the same PHB at the router, thereby simplifying the processing and associated storage. In addition, there is no signaling other than what is carried in the DSCP of each packet, and no other related processing that is required in the core of the Diffserv network since QoS is invoked on a packet-by-packet basis.
そのようなスキームの利点は、多くのトラフィックストリームが各て処理と関連するストレージを簡素化し、ルータに同じPHBを使用して転送される挙動凝集体（BA）、少数の一つに集約することができることです。加えて、各パケットのDSCP、およびQoSがパケットごとに呼び出されるためのDiffservネットワークのコアで必要とされない他の関連処理で実行されるものよりもシグナリング他方は存在しません。
The Diffserv architecture enables a variety of possible services which could be deployed in a network. These services are reflected to customers at the edges of the Diffserv network in the form of a Service Level Specification (SLS - see [NEWTERMS]). Whilst further discussion of such services is outside the scope of this document (see [PDBDEF]), the ability to provide these services depends on the availability of cohesive management and configuration tools that can be used to provision and monitor a set of Diffserv routers in a coordinated manner. To facilitate the development of such configuration and management tools it is helpful to define a conceptual model of a Diffserv router that abstracts away implementation details of particular Diffserv routers from the parameters of interest for configuration and management. The purpose of this document is to define such a model.
DiffServアーキテクチャは、ネットワーク内に展開することができ可能さまざまなサービスを可能にします。これらのサービスは、サービス・レベル仕様の形でのDiffservネットワークのエッジで顧客に反映されている（SLS - [NEWTERMS]を参照）。そのようなサービスのさらなる議論は、この文書の範囲外であるが、これらのサービスを提供する能力を提供するために使用され、中のDiffservルータのセットを監視することができる粘着性管理および設定ツールの可用性に依存する（[PDBDEF]参照）協調的。このような構成および管理ツールの開発を容易にするためには、構成および管理のための関心のパラメータから特定のDiffservルータの実装の詳細を抽象化のDiffservルーターの概念モデルを定義するために有用です。このドキュメントの目的は、このようなモデルを定義することです。
The basic forwarding functionality of a Diffserv router is defined in other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB].
Diffservルータの基本的な転送機能は、他の仕様で定義されています。例えば、[DSARCH、DSFIELD、AF-PHB、EF-PHB]。
This document is not intended in any way to constrain or to dictate the implementation alternatives of Diffserv routers. It is expected that router implementers will demonstrate a great deal of variability in their implementations. To the extent that implementers are able to model their implementations using the abstractions described in this document, configuration and management tools will more readily be able to configure and manage networks incorporating Diffserv routers of assorted origins.
この文書は、拘束するかのDiffservルータの実装の選択肢を決定するためにどのような方法で意図されていません。ルータの実装は、その実装の変動を大いに発揮することが期待されます。実装は、本文書に記載の抽象化を使用して実装をモデル化することができる程度に、構成および管理ツールがより容易に各種起源のDiffservのルータを組み込んだネットワークを構成および管理することができるであろう。
This model is intended to be abstract and capable of representing the configuration parameters important to Diffserv functionality for a variety of specific router implementations. It is not intended as a guide to system implementation nor as a formal modeling description. This model serves as the rationale for the design of an SNMP MIB [DSMIB] and for other configuration interfaces (e.g., other policy-management protocols) and, possibly, more detailed formal models (e.g., [QOSDEVMOD]): these should all be consistent with this model.
このモデルは、抽象的かつ具体的なルータのさまざまなインプリメンテーションのためのDiffservの機能に重要な設定パラメータを表現することができるように意図されます。これは、システム実装のガイドとしても正式なモデリングの説明として意図されていません。このモデルは、SNMP MIB [DSMIB]の設計および他の構成インターフェイス（例えば、他のポリシー管理プロトコル）と、おそらく、より詳細な正式なモデル（例えば、[QOSDEVMOD]）の根拠として役立つ：これらは、全てでなければなりませんこのモデルと一致。
o Section 3 starts by describing the basic high-level blocks of a Diffserv router. It explains the concepts used in the model, including the hierarchical management model for these blocks which uses low-level functional datapath elements such as Classifiers, Actions, Queues.
O部のDiffservルータの基本的なハイレベル・ブロックを記述することにより、3始めます。そのような分類子、アクション、キューのような低レベルの機能データパス要素を使用し、これらのブロックの階層管理モデルを含むモデルで使用される概念を説明します。
o Section 4 describes Classifier elements.
O部4は、分類子要素について説明します。
o Section 5 discusses Meter elements.
O部5は、メーターの要素について説明します。
o Section 6 discusses Action elements.
O部6は、アクション要素について説明します。
o Section 7 discusses the basic queuing elements of Algorithmic Droppers, Queues, and Schedulers and their functional behaviors (e.g., traffic shaping).
O部7は、アルゴリズムドロッパー、キューおよびスケジューラ及びそれらの機能的挙動（例えば、トラフィックシェーピング）の基本的な待ち行列要素について説明します。
o Section 8 shows how the low-level elements can be combined to build modules called Traffic Conditioning Blocks (TCBs) which are useful for management purposes.
O部8がローレベルの要素は、管理目的のために有用であるトラフィックコンディショニングブロック（のTCB）と呼ばれるモジュールを構築するために組み合わせることができる方法を示しています。
o Section 9 discusses security concerns.
O部9は、セキュリティ上の問題について説明します。
o Appendix A contains a brief discussion of the token bucket and leaky bucket algorithms used in this model and some of the practical effects of the use of token buckets within the Diffserv architecture.
O付録Aは、トークンバケットと、このモデルで使用されるリーキーバケットアルゴリズムとDiffServアーキテクチャ内のトークンバケットの使用の実用的な効果のいくつかの簡単な説明が含まれています。
This document uses terminology which is defined in [DSARCH]. There is also current work-in-progress on this terminology in the IETF and some of the definitions provided here are taken from that work. Some of the terms from these other references are defined again here in order to provide additional detail, along with some new terms specific to this document.
この文書では、[DSARCH]で定義される用語を使用します。現在作業中のIETFと、ここで提供された定義の一部では、この用語にその仕事から取られもあります。これらの他の文献からの用語のいくつかは、この文書に固有のいくつかの新しい用語と一緒に、追加の詳細を提供するために、再びここで定義されています。
Absolute A functional datapath element which simply discards all Dropper packets arriving at its input.
単にその入力に到着するすべてのスポイトパケットを破棄する機能データパス要素絶対。
Algorithmic A functional datapath element which selectively Dropper discards packets that arrive at its input, based on a discarding algorithm. It has one data input and one output.
アルゴリズム選択ドロッパーが廃棄アルゴリズムに基づいて、その入力に到着するパケットを廃棄機能データパス要素。これは、1つのデータ入力と1つの出力があります。
Classifier A functional datapath element which consists of filters that select matching and non-matching packets. Based on this selection, packets are forwarded along the appropriate datapath within the router. A classifier, therefore, splits a single incoming traffic stream into multiple outgoing streams.
クラシファイアマッチングおよび非マッチングパケットを選択するフィルタで構成されて機能データパス要素。この選択に基づいて、パケットは、ルータ内の適切なデータパスに沿って転送されます。分類器は、従って、複数の送信ストリームに単一の着信トラフィックストリームを分割します。
Counter A functional datapath element which updates a packet counter and also an octet counter for every packet that passes through it.
また、パケットカウンタと、それを通過するすべてのパケットのためのオクテットカウンタを更新する機能データパス要素に対抗。
Datapath A conceptual path taken by packets with particular characteristics through a Diffserv router. Decisions as to the path taken by a packet are made by functional datapath elements such as Classifiers and Meters.
データパスのDiffservルータを介して特定の特性を持つパケットによって取ら概念パス。パケットによって取られる経路についての決定は、分類器とメータとして機能データパス要素によって作られます。
Filter A set of wildcard, prefix, masked, range and/or exact match conditions on the content of a packet's headers or other data, and/or on implicit or derived attributes associated with the packet. A filter is said to match only if each condition is satisfied.
パケットのヘッダまたは他のデータの内容に、及び/又はパケットに関連付けられた暗黙的または派生属性のワイルドカードのセット、接頭辞、マスク、範囲及び/又は完全一致条件をフィルタリングします。フィルタは、各条件が満たされた場合にのみ一致するように言われています。
Functional A basic building block of the conceptual router. Datapath Typical elements are Classifiers, Meters, Actions, Element Algorithmic Droppers, Queues and Schedulers.
概念的なルータの機能の基本的なビルディングブロック。データパス典型的な要素は、要素のアルゴリズムドロッパー、キューおよびスケジューラクラシファイア、メーター、アクション、されています。
Multiplexer A multiplexor. (Mux)
マルチプレクサマルチプレクサ。 （MUX）
Multiplexor A functional datapath element that merges multiple (Mux) traffic streams (datapaths) into a single traffic stream (datapath).
単一のトラフィックストリーム（データパス）に複数（MUX）トラフィックストリーム（データパス）をマージ機能データパス要素をマルチプレクサ。
Non-work- A property of a scheduling algorithm such that it conserving services packets no sooner than a scheduled departure time, even if this means leaving packets queued while the output (e.g., a network link or connection to the next element) is idle.
スケジューリングアルゴリズムの非ワーク・プロパティように、それは、これが出力される（次の要素に例えば、ネットワークリンクまたは接続）がアイドル状態である間、パケットがキューイングさ残す手段としても、出発予定時刻よりも早くサービスパケットを保存します。
Policing The process of comparing the arrival of data packets against a temporal profile and forwarding, delaying or dropping them so as to make the output stream conformant to the profile.
、経時的プロファイル及び転送に対するデータパケットの到着を比較する工程をポリシングプロファイルへの出力ストリームを適合させるようにそれらを遅延またはドロップ。
Queuing A combination of functional datapath elements Block that modulates the transmission of packets belonging to a traffic streams and determines their ordering, possibly storing them temporarily or discarding them.
トラフィックストリームに属するパケットの送信を変調し、おそらく一時的に格納したり、それらを廃棄し、その順序を決定し、機能データパス要素ブロックの組み合わせをキューイング。
Scheduling An algorithm which determines which queue of a set algorithm of queues to service next. This may be based on the relative priority of the queues, on a weighted fair bandwidth sharing policy or some other policy. Such an algorithm may be either work-conserving or non-work-conserving.
次のサービスへのキューのセットアルゴリズムのどのキューを決定するアルゴリズムのスケジュール。これは、重み付けされた公平な帯域共有ポリシーまたは他のポリシーに、キューの相対的な優先順位に基づいてもよいです。このようなアルゴリズムは、作業保存または非作業保存のいずれであってもよいです。
Service-Level A set of parameters and their values which together Specification define the treatment offered to a traffic stream by a (SLS) Diffserv domain.
サービスレベル一緒に指定（SLS）のDiffservドメインによってトラフィックストリームに提供される治療を定義するパラメータとその値のセット。
Shaping The process of delaying packets within a traffic stream to cause it to conform to some defined temporal profile. Shaping can be implemented using a queue serviced by a non-work-conserving scheduling algorithm.
それはいくつかの定義された一時的なプロファイルに適合させるために、トラフィックストリーム内のパケットを遅延させるプロセスをシェーピング。シェーピングは、非作業保存スケジューリングアルゴリズムによってサービスキューを使用して実装することができます。
Traffic A logical datapath entity consisting of a number of Conditioning functional datapath elements interconnected in Block (TCB) such a way as to perform a specific set of traffic conditioning functions on an incoming traffic stream. A TCB can be thought of as an entity with one input and one or more outputs and a set of control parameters.
トラフィックブロック（TCB）に相互接続コンディショニング機能データパス要素着信トラフィック・ストリームのトラフィック調整機能の特定のセットを実行するような方法の数からなる論理データパスエンティティ。 TCBは、1つの入力と1つまたは複数の出力及び制御パラメータのセットを持つエンティティと考えることができます。
Traffic A set of parameters and their values which together Conditioning specify a set of classifier rules and a traffic Specification profile. A TCS is an integral element of a SLS. (TCS)
交通一緒にコンディショニングがクラシファイア規則のセットと、トラフィック仕様プロファイルを指定するパラメータとその値のセット。 TCSはSLSの不可欠な要素です。 （TCS）
Work- A property of a scheduling algorithm such that it conserving services a packet, if one is available, at every transmission opportunity.
1つが、すべての送信機会で、利用可能な場合には、パケットサービスを節約するようにスケジューリングアルゴリズムのプロパティをワーク・。
This section introduces a block diagram of a Diffserv router and describes the various components illustrated in Figure 1. Note that a Diffserv core router is likely to require only a subset of these components: the model presented here is intended to cover the case of both Diffserv edge and core routers.
このセクションでは、Diffservのルータのブロック図を紹介するとDiffservコアルータは、これらのコンポーネントのサブセットのみを必要とする可能性があることが図1注に示す様々な構成要素を説明します。ここに提示モデルは、両方のDiffservのケースをカバーすることが意図されていますエッジおよびコアルーター。
The conceptual model includes abstract definitions for the following:
概念モデルは、以下の抽象定義が含まれています。
o Traffic Classification elements.
トラフィック分類要素O。
o Metering functions.
測光機能O。
o Actions of Marking, Absolute Dropping, Counting, and Multiplexing.
マーキングのOアクション、絶対ドロップ、カウント、および多重化。
o Queuing elements, including capabilities of algorithmic dropping and scheduling.
Oアルゴリズムのドロップやスケジューリングの機能を含む要素を、キュー。
o Certain combinations of the above functional datapath elements into higher-level blocks known as Traffic Conditioning Blocks (TCBs).
トラフィックコンディショニングブロック（のTCB）として知られている高レベルのブロックに上記機能データパス要素の特定の組み合わせは、O。
The components and combinations of components described in this document form building blocks that need to be manageable by Diffserv configuration and management tools. One of the goals of this document is to show how a model of a Diffserv device can be built using these component blocks. This model is in the form of a connected directed acyclic graph (DAG) of functional datapath elements that describes the traffic conditioning and queuing behaviors that any particular packet will experience when forwarded to the Diffserv router. Figure 1 illustrates the major functional blocks of a Diffserv router.
Diffservの構成および管理ツールによって管理する必要があり、この文書のフォームのビルディングブロックに記載されている構成部品の部品との組み合わせ。このドキュメントの目標の一つは、Diffservのデバイスのモデルは、これらのコンポーネントのブロックを使用して構築することができる方法を示すことです。このモデルは、トラフィック調整とDiffservルータに転送する際、任意の特定のパケットが経験するキューイング動作を記述する機能データパス要素の接続された非循環有向グラフ（DAG）の形です。図1は、Diffservのルータの主要な機能ブロックを示します。
An ingress interface, routing core, and egress interface are illustrated at the center of the diagram. In actual router implementations, there may be an arbitrary number of ingress and egress interfaces interconnected by the routing core. The routing core element serves as an abstraction of a router's normal routing and switching functionality. The routing core moves packets between interfaces according to policies outside the scope of Diffserv (note: it is possible that such policies for output-interface selection might involve use of packet fields such as the DSCP but this is outside the scope of this model). The actual queuing delay and packet loss behavior of a specific router's switching fabric/backplane is not modeled by the routing core; these should be modeled using the functional datapath elements described later. The routing core of this model can be thought of as an infinite bandwidth, zero-delay interconnect between interfaces - properties like the behavior of the core when overloaded need to be reflected back into the queuing elements that are modeled around it (e.g., when too much traffic is directed across the core at an egress interface), the excess must either be dropped or queued somewhere: the elements performing these functions must be modeled on one of the interfaces involved.
入力インターフェイス、ルーティング・コア、及び出力インターフェイスは、図の中央に示されています。実際のルータの実装では、ルーティング・コアによって相互接続入力および出力インターフェースの任意の数が存在してもよいです。ルーティングコア要素は、ルータの通常のルーティングおよびスイッチング機能の抽象化として役立ちます。ルーティングコアのDiffservの範囲外のポリシーに従ってインタフェース間でパケットを移動させる（注意：出力インターフェイスの選択のためのこのようなポリシーは、DSCPなどのパケットフィールドの使用を伴うかもしれないが、これは、このモデルの範囲外である可能性があります）。特定のルータのスイッチングファブリック/バックプレーンの実際のキューイング遅延およびパケット損失挙動は、ルーティングコアによってモデル化されていません。これらは、後述する機能データパス要素を使用してモデル化されるべきです。コアの挙動などの特性過負荷必要が戻ってその周りにモデル化され、キューイング要素に反映される（例えば、あまりに - このモデルのルーティングコアは無限の帯域幅、インターフェイス間のゼロ遅延配線と考えることができ多くのトラフィック）を出力インターフェイスにコアを横切って向けられ、過剰のいずれか削除またはどこかキューに入れられなければならない。これらの機能を実行する要素が関与するインターフェイスのいずれかにモデル化されなければなりません。
The components of interest at the ingress to and egress from interfaces are the functional datapath elements (e.g., Classifiers, Queuing elements) that support Diffserv traffic conditioning and per-hop behaviors [DSARCH]. These are the fundamental components comprising a Diffserv router and are the focal point of this model.
インターフェイスからの入力および出力における関心の構成要素は、機能データパス要素のDiffservトラフィックコンディショニングとホップごとの振舞い[DSARCH]をサポートする（例えば、分類器、キュー要素）です。これらは、Diffservのルータを含む基本的なコンポーネントであり、このモデルの焦点です。
+---------------+
| Diffserv |
Mgmt | configuration |
<----+-->| & management |------------------+
SNMP,| | interface | |
COPS | +---------------+ |
etc. | | |
| | |
| v v
| +-------------+ +-------------+
| | ingress i/f | +---------+ | egress i/f |
-------->| classify, |-->| routing |-->| classify, |---->
data | | meter, | | core | | meter |data out
in | | action, | +---------+ | action, |
| | queuing | | queuing |
| +-------------+ +-------------+
| ^ ^
| | |
| | |
| +------------+ |
+-->| QOS agent | |
-------->| (optional) |---------------------+
QOS |(e.g., RSVP)|
cntl +------------+
msgs
Figure 1: Diffserv Router Major Functional Blocks
図1：Diffservのルータの主要機能ブロック
Diffserv operating parameters are monitored and provisioned through this interface. Monitored parameters include statistics regarding traffic carried at various Diffserv service levels. These statistics may be important for accounting purposes and/or for tracking compliance to Traffic Conditioning Specifications (TCSs) negotiated with customers. Provisioned parameters are primarily the TCS parameters for Classifiers and Meters and the associated PHB configuration parameters for Actions and Queuing elements. The network administrator interacts with the Diffserv configuration and management interface via one or more management protocols, such as SNMP or COPS, or through other router configuration tools such as serial terminal or telnet consoles.
Diffservの動作パラメータを監視し、このインタフェースを介してプロビジョニングされます。監視対象のパラメータは、各種のDiffservサービスレベルで伝送されるトラフィックに関する統計情報が含まれています。これらの統計は、および/または顧客と交渉トラフィック調整仕様TCSS（）への準拠を追跡するための会計目的のために重要であるかもしれません。プロビジョニングされたパラメータは、主にクラシファイアとメーターとアクションとキュー要素に関連付けられたPHBの設定パラメータのためのTCSパラメータです。ネットワーク管理者は、SNMPまたはCOPSなどの1つまたは複数の管理プロトコルを介して、又は、シリアル端末またはtelnetコンソールのような他のルータの構成ツールを介してのDiffserv設定および管理インタフェースと相互作用します。
Specific policy rules and goals governing the Diffserv behavior of a router are presumed to be installed by policy management mechanisms. However, Diffserv routers are always subject to implementation limits which scope the kinds of policies which can be successfully implemented by the router. External reporting of such implementation capabilities is considered out of scope for this document.
ルータのDiffservの行動を支配する特定のポリシールールや目標は、ポリシー管理メカニズムによってインストールされると推定されます。しかし、Diffservのルータは常に政策の種類が正常にルータで実現できる範囲の実装の制限の対象となっています。このような実装機能の外部への報告は、この文書の範囲外と考えられています。
Diffserv routers may snoop or participate in either per-microflow or per-flow-aggregate signaling of QoS requirements [E2E] (e.g., using the RSVP protocol). Snooping of RSVP messages may be used, for example, to learn how to classify traffic without actually participating as a RSVP protocol peer. Diffserv routers may reject or admit RSVP reservation requests to provide a means of admission control to Diffserv-based services or they may use these requests to trigger provisioning changes for a flow-aggregation in the Diffserv network. A flow-aggregation in this context might be equivalent to a Diffserv BA or it may be more fine-grained, relying on a multi-field (MF) classifier [DSARCH]. Note that the conceptual model of such a router implements the Integrated Services Model as described in [INTSERV], applying the control plane controls to the data classified and conditioned in the data plane, as described in [E2E].
DiffServのルータは、スヌープまたはマイクロ単位またはフロー集約QoS要件[E2E]のシグナリングのいずれかに参加することができる（例えば、RSVPプロトコルを使用して）。 RSVPメッセージのスヌーピングは、実際にはRSVPプロトコルピアとして参加せずにトラフィックを分類する方法を学ぶために、例えば、使用することができます。 Diffservのルータは拒否またはDiffservのベースのサービスへのアドミッション制御の手段を提供するために、RSVP予約要求を認めるか、彼らはDiffservのネットワークにおけるフロー集約のためのプロビジョニングの変更をトリガするためにこれらの要求を使用する場合があります。この文脈におけるフロー集合は、DiffservのBAに相当するかもしれないまたはそれがマルチフィールド（MF）クラシファイア[DSARCH]に依存する、より細かい粒度であってもよいです。 【のIntServ]、[E2E]に記載されているように、データプレーンに分類し、馴化データにコントロールプレーンコントロールを適用することに記載されているようなルータの概念モデルは、統合サービスモデルを実装することに留意されたいです。
Note that a QoS Agent component of a Diffserv router, if present, might be active only in the control plane and not in the data plane. In this scenario, RSVP could be used merely to signal reservation state without installing any actual reservations in the data plane of the Diffserv router: the data plane could still act purely on Diffserv DSCPs and provide PHBs for handling data traffic without the normal per-microflow handling expected to support some Intserv services.
DiffservルータのQoSのエージェント・コンポーネントは、存在する場合、制御プレーンにおいてのみではなく、データプレーンで働いている可能性がありますので注意してください。データプレーンは依然としてのDiffservのDSCPに純粋に作用し、正常ごとマイクロなく、データトラフィックを処理するためのPHBを提供することができる：このシナリオでは、RSVPは、Diffservのルーターのデータプレーン内の任意の実際の予約をインストールせずに予約状態を知らせるために単に使用することができますいくつかのイントサーブサービスをサポートすることが期待取り扱い。
This document focuses on the Diffserv-specific components of the router. Figure 2 shows a high-level view of ingress and egress interfaces of a router. The diagram illustrates two Diffserv router interfaces, each having a set of ingress and a set of egress elements. It shows classification, metering, action and queuing functions which might be instantiated at each interface's ingress and egress.
この文書では、ルータのDiffservの固有のコンポーネントに焦点を当てています。図2は、ルータの入力および出力インターフェースの高レベルの図を示しています。図は、それぞれが入口および出口要素のセットのセットを有する2つのDiffservルータインターフェイスを示す図です。これは、分類、計量、アクションおよび各インターフェイスの入力および出力でインスタンス化される可能性がありますキューイング機能を示しています。
The simple diagram of Figure 2 assumes that the set of Diffserv functions to be carried out on traffic on a given interface are independent of those functions on all other interfaces. There are some architectures where Diffserv functions may be shared amongst multiple interfaces (e.g., processor and buffering resources that handle multiple interfaces on the same line card before forwarding across a routing core). The model presented in this document may be easily extended to handle such cases; however, this topic is not treated further here as it leads to excessive complexity in the explanation of the concepts.
図2の簡単な図は、所定のインターフェイス上のトラフィック上で実行されるのDiffserv機能のセットは、他のすべてのインターフェイスでそれらの機能とは無関係であると仮定しています。 Diffservの機能は、複数のインタフェース間で共有することができるいくつかのアーキテクチャ（ルーティング・コアを横切って転送する前に、同じラインカード上に複数のインタフェースを扱う例えば、プロセッサおよびバッファリングリソース）があります。この文書で提示モデルを容易にそのようなケースを扱うように拡張することができます。しかし、この話題はここでさらに、それは概念の説明で過度の複雑さにつながるものとして扱われていません。
Interface A Interface B
+-------------+ +---------+ +-------------+
| ingress: | | | | egress: |
| classify, | | | | classify, |
--->| meter, |---->| |---->| meter, |--->
| action, | | | | action, |
| queuing | | routing | | queuing |
+-------------+ | core | +-------------+
| egress: | | | | ingress: |
| classify, | | | | classify, |
<---| meter, |<----| |<----| meter, |<---
| action, | | | | action, |
| queuing | +---------+ | queuing |
+-------------+ +-------------+
Figure 2. Traffic Conditioning and Queuing Elements
図2.トラフィックコンディショニングおよびキューイングの要素
In principle, if one were to construct a network entirely out of two-port routers (connected by LANs or similar media), then it might be necessary for each router to perform four QoS control functions in the datapath on traffic in each direction:
一つは、完全に（のLANまたは類似のメディアによって接続されている）、2ポートルータからネットワークを構築した場合、各ルータは、各方向にトラフィックデータパス内の4つのQoS制御機能を実行するために、原則的に、それは必要かもしれません。
- Classify each message according to some set of rules, possibly just a "match everything" rule.
- ルールのいくつかのセット、おそらくちょうど「すべてを一致」のルールに従って、各メッセージを分類します。
- If necessary, determine whether the data stream the message is part of is within or outside its rate by metering the stream.
- 必要に応じて、データメッセージがストリームを計量供給することによって、その速度範囲内又は外にあるの一部であるストリームかどうかを決定します。
- Perform a set of resulting actions, including applying a drop policy appropriate to the classification and queue in question and perhaps additionally marking the traffic with a Differentiated Services Code Point (DSCP) [DSFIELD].
- 問題の分類、キューにドロップポリシー適切に適用し、おそらくさらに差別化サービスコードポイント（DSCP）DSFIELD]とのトラフィックをマーキングを含む、得られた一連のアクションを実行します。
- Enqueue the traffic for output in the appropriate queue. The scheduling of output from this queue may lead to shaping of the traffic or may simply cause it to be forwarded with some minimum rate or maximum latency assurance.
- 適切なキューで出力のトラフィックをエンキュー。このキューからの出力のスケジューリングは、トラフィックのシェーピングにつながる可能性があり、あるいは単にそれはいくつかの最小レートまたは最大待ち時間の保証で転送される可能性があります。
If the network is now built out of N-port routers, the expected behavior of the network should be identical. Therefore, this model must provide for essentially the same set of functions at the ingress as on the egress of a router's interfaces. The one point of difference in the model between ingress and the egress is that all traffic at the egress of an interface is queued, while traffic at the ingress to an interface is likely to be queued only for shaping purposes, if at all. Therefore, equivalent functional datapath elements may be modeled at both the ingress to and egress from an interface.
ネットワークは現在、N-ポートルータの外に構築されている場合は、ネットワークの予想される動作は同一である必要があります。したがって、このモデルは、ルータのインターフェイスの出力にとして入力における機能の本質的に同じセットを提供しなければなりません。入口と出口との間のモデルの違いの一点は、インタフェースに入力でのトラフィックがすべての場合、成形の目的のためにだけキューに入れられる可能性があるながら、インターフェースの出力ですべてのトラフィックは、キューイングされることです。したがって、同等の機能データパス要素は、インターフェースからの入力と出力の両方でモデル化することができます。
Note that it is not mandatory that each of these functional datapath elements be implemented at both ingress and egress; equally, the model allows that multiple sets of these elements may be placed in series and/or in parallel at ingress or at egress. The arrangement of elements is dependent on the service requirements on a particular interface on a particular router. By modeling these elements at both ingress and egress, it is not implied that they must be implemented in this way in a specific router. For example, a router may implement all shaping and PHB queuing at the interface egress or may instead implement it only at the ingress. Furthermore, the classification needed to map a packet to an egress queue (if present) need not be implemented at the egress but instead might be implemented at the ingress, with the packet passed through the routing core with in-band control information to allow for egress queue selection.
これらの機能データパス要素のそれぞれが入口および出口の両方で実施することが必須ではないことに留意されたいです。同様に、モデルは、これらの要素の複数のセット及び/又は並列に入口で、または出口に直列に配置することができることを可能にします。要素の配置は、特定のルータ上の特定のインターフェイス上のサービス要件に依存しています。入力と出力の両方でこれらの要素をモデル化することにより、それらは、特定のルータでは、この方法で実装されなければならないことを意味するものではありません。例えば、ルータは、インターフェイス出口でキューイングすべての整形およびPHBを実装することができるか、代わりにのみ入力でそれを実現してもよいです。さらに、（存在する場合）出力キューにパケットをマッピングするために必要な分類は、出口で実現することはなく、パケットを可能にするためにインバンド制御情報をルーティング・コアを通過して、入口で実装されるかもしれない必要はありません出力キューの選択。
Specifically, some interfaces will be at the outer "edge" and some will be towards the "core" of the Diffserv domain. It is to be expected (from the general principles guiding the motivation of Diffserv) that "edge" interfaces, or at least the routers that contain them, will implement more complexity and require more configuration than those in the core although this is obviously not a requirement.
具体的には、いくつかのインターフェイスは、外側「エッジ」になり、いくつかのDiffservドメインの「コア」に向かってであろう。その「エッジ」インターフェース（のDiffservのモチベーションを導く一般的な原理から）予想される、または少なくともそれらを含むルータは、より多くの複雑さを実現し、これは明らかではないが、コアのものよりも多くの構成を必要とします要求。
Diffserv nodes may apply shaping, policing and/or marking to traffic streams that exceed the bounds of their TCS in order to prevent one traffic stream from seizing more than its share of resources from a Diffserv network. In this model, Shaping, sometimes considered as a TC action, is treated as a function of queuing elements - see section 7. Algorithmic Dropping techniques (e.g., RED) are similarly treated since they are often closely associated with queues. Policing is modeled as either a concatenation of a Meter with an Absolute Dropper or as a concatenation of an Algorithmic Dropper with a Scheduler. These elements will discard packets which exceed the TCS.
DiffServのノードは、整形ポリシングおよび/またはDiffServのネットワークからリソースのシェアよりも焼き付きからの1つのトラフィック・ストリームを防止するために、それらのTCSの境界を超えたトラフィックストリームにマーキングを適用することができます。このモデルでは、時にはTCアクションとして考えシェーピングは、要素をキューイングの関数として扱われる - 部7アルゴリズム滴下技術（例えば、RED）を参照、これらはしばしば密接にキューに関連付けられているので、同様に処理されます。ポリシングは絶対スポイトでまたはスケジューラとアルゴリズムドロッパーの連結として器の連結のいずれかとしてモデル化されます。これらの要素は、TCSを超えるパケットを破棄します。
From a device-level configuration management perspective, the following hierarchy exists:
デバイスレベルの構成管理の観点から、次の階層が存在します。
At the lowest level considered here, there are individual functional datapath elements, each with their own configuration parameters and management counters and flags.
ここで考えられる最低のレベルでは、個々の機能データパス要素、自身の設定パラメータと管理カウンターとフラグを持つそれぞれがあります。
At the next level, the network administrator manages groupings of these functional datapath elements interconnected in a DAG. These functional datapath elements are organized in self-contained TCBs which are used to implement some desired network policy (see Section 8). One or more TCBs may be instantiated at each interface's ingress or egress; they may be connected in series and/or in parallel configurations on the multiple outputs of a preceding TCB. A TCB can be thought of as a "black box" with one input and one or more outputs (in the data path). Each interface may have a different TCB configuration and each direction (ingress or egress) may too.
次のレベルでは、ネットワーク管理者は、DAGに相互接続され、これらの機能データパス要素のグループを管理します。これらの機能データパス要素は、（セクション8を参照）、いくつかの所望のネットワークポリシーを実装するために使用される自己完結型のTCBで編成されています。一の以上のTCBは、各インターフェイスの入力または出力でインスタンス化することができます。彼らは、直列におよび/または先行TCBの複数の出力に並列構成で接続されていてもよいです。 TCBは、1つの入力と1つ以上の出力（データ・パスにおける）と「ブラックボックス」と考えることができます。各インターフェースは、異なるTCB構成とよいすぎる各方向（入力または出力）を有していてもよいです。
At the topmost level considered here, the network administrator manages interfaces. Each interface has ingress and egress functionality, with each of these expressed as one or more TCBs. This level of the hierarchy is what was illustrated in Figure 2.
ここで考えて一番上のレベルでは、ネットワーク管理者は、インタフェースを管理します。各インタフェースは、一の以上のTCBとして表さこれらのそれぞれと、入力および出力機能を有しています。階層のこのレベルは、図2に示したものです。
Further levels may be built on top of this hierarchy, in particular ones for aiding in the repetitive configuration tasks likely for routers with many interfaces: some such "template" tools for Diffserv routers are outside the scope of this model but are under study by other working groups within IETF.
さらなるレベルは、多くのインターフェイスを持つルータの可能性が繰り返し設定作業を補助するために特定のもので、この階層の上に構築することができる：Diffservのルータのためのいくつかのように、「テンプレート」ツールは、このモデルの範囲外であるが、他で検討されていますIETF内のワーキンググループ。
Classification is performed by a classifier element. Classifiers are 1:N (fan-out) devices: they take a single traffic stream as input and generate N logically separate traffic streams as output. Classifiers are parameterized by filters and output streams. Packets from the input stream are sorted into various output streams by filters which match the contents of the packet or possibly match other attributes associated with the packet. Various types of classifiers using different filters are described in the following sections. Figure 3 illustrates a classifier, where the outputs connect to succeeding functional datapath elements.
分類はクラシファイア要素によって行われます。分類器は、1：N（ファンアウト）装置：彼らは、入力として単一のトラフィックストリームを取得し、論理的に別個のトラフィックが出力としてストリームNを生成します。クラシファイアはフィルタと出力ストリームによってパラメータ化されています。入力ストリームからのパケットは、パケットの内容と一致またはおそらくはパケットに関連付けられた他の属性と一致フィルタにより種々の出力ストリームに分類されます。異なるフィルタを用いた分類器の様々なタイプは、以下のセクションに記載されています。図3は、出力が機能データパス要素を後続に接続クラシファイアを示します。
The simplest possible Classifier element is one that matches all packets that are applied at its input. In this case, the Classifier element is just a no-op and may be omitted.
最も単純な分類子要素は、その入力で適用されるすべてのパケットに一致するものです。この場合、分類要素は単にノー・オペレーションであり、省略してもよいです。
Note that we allow a Multiplexor (see Section 6.5) before the Classifier to allow input from multiple traffic streams. For example, if traffic streams originating from multiple ingress interfaces feed through a single Classifier then the interface number could be one of the packet classification keys used by the Classifier. This optimization may be important for scalability in the management plane. Classifiers may also be cascaded in sequence to perform more complex lookup operations whilst still maintaining such scalability.
我々は、複数のトラフィックストリームからの入力を許可するように分類子の前にマルチプレクサを（6.5節を参照）を許可することに注意してください。複数の入力インターフェイスから発信されたトラフィックストリームは、単一の分類器を介して供給たとえば、インターフェイス番号が分類器によって使用されるパケット分類キーのいずれかとすることができます。この最適化は、経営面でのスケーラビリティのために重要であるかもしれません。クラシファイアもやはり、このような拡張性を維持しながら、より複雑なルックアップ操作を実行するために順番にカスケード接続することができます。
Another example of a packet attribute could be an integer representing the BGP community string associated with the packet's best-matching route. Other contextual information may also be used by a Classifier (e.g., knowledge that a particular interface faces a Diffserv domain or a legacy IP TOS domain [DSARCH] could be used when determining whether a DSCP is present or not).
パケット属性の別の例は、パケットの最高のマッチングルートに関連付けられたBGPコミュニティストリングを表す整数である可能性があります。他のコンテキスト情報は、分類によっても使用され得る（DSCPが存在するか否かを決定する際に、例えば、特定のインタフェースが[DSARCH]のDiffservドメインまたはレガシーIP TOS領域に対向する知識を使用することができます）。
unclassified classified
traffic traffic
+------------+
| |--> match Filter1 --> OutputA
------->| classifier |--> match Filter2 --> OutputB
| |--> no match --> OutputC
+------------+
Figure 3. An Example Classifier
図3.アン例クラシファイア
The following BA classifier separates traffic into one of three output streams based on matching filters:
以下BAクラシファイアは、一致フィルタに基づいて3つの出力ストリームの1つにトラフィックを分離します。
Filter Matched Output Stream
-------------- ---------------
Filter1 A
Filter2 B
no match C
Where the filters are defined to be the following BA filters ([DSARCH], Section 4.2.1):
フィルタは、次のBAフィルタ（[DSARCH]、セクション4.2.1）であると定義されます。
Filter DSCP
------ ------
Filter1 101010
Filter2 111111
Filter3 ****** (wildcard)
A filter consists of a set of conditions on the component values of a packet's classification key (the header values, contents, and attributes relevant for classification). In the BA classifier example above, the classification key consists of one packet header field, the DSCP, and both Filter1 and Filter2 specify exact-match conditions on the value of the DSCP. Filter3 is a wildcard default filter which matches every packet, but which is only selected in the event that no other more specific filter matches.
フィルタは、パケットの分類キーの成分値に関する条件のセットで構成さ（ヘッダ値、コンテンツ、および分類に関連する属性）。上記BAクラシファイアの例では、分類キーは、1つのパケットヘッダフィールドから構成DSCP、およびフィルター1とFILTER2両方はDSCPの値に正確に一致条件を指定します。 Filter3は、すべてのパケットに一致するワイルドカードのデフォルトのフィルタであるが、唯一のイベントがない他のより具体的なフィルタの試合で選択されています。
In general there are a set of possible component conditions including exact, prefix, range, masked and wildcard matches. Note that ranges can be represented (with less efficiency) as a set of prefixes and that prefix matches are just a special case of both masked and range matches.
一般的に正確含む可能成分条件のセット、接頭辞、範囲、マスクとワイルドカードの一致があります。プレフィックスの組と、そのプレフィックスと一致した（より少ない効率で）表すことができる範囲メモは、マスクされた範囲の一致の両方のちょうど特殊なケースです。
In the case of a MF classifier, the classification key consists of a number of packet header fields. The filter may specify a different condition for each key component, as illustrated in the example below for a IPv4/TCP classifier:
MF分類器の場合には、分類キーは、パケットヘッダフィールドの数で構成されています。 IPv4 / TCP分類器のために、以下の例に示すように、フィルタは、各キーコンポーネントの異なる条件を指定することができます。
Filter IPv4 Src Addr IPv4 Dest Addr TCP SrcPort TCP DestPort
------ ------------- -------------- ----------- ------------
Filter4 172.31.8.1/32 172.31.3.X/24 X 5003
In this example, the fourth octet of the destination IPv4 address and the source TCP port are wildcard or "don't care".
この例では、宛先のIPv4アドレスと送信元TCPポートの4番目のオクテットは、ワイルドカードであるか「気にしません」。
MF classification of IP-fragmented packets is impossible if the filter uses transport-layer port numbers (e.g., TCP port numbers). MTU-discovery is therefore a prerequisite for proper operation of a Diffserv network that uses such classifiers.
フィルタは、トランスポート層のポート番号（例えば、TCPポート番号）を使用している場合、IPフラグメントパケットのMF分類は不可能です。 MTUディスカバリは、したがって、このような分類を使用したDiffservネットワークの適切な動作のための前提条件です。
Note that it is easy to define sets of overlapping filters in a classifier. For example:
分類器での重複フィルターのセットを定義することは容易であることに注意してください。例えば：
Filter IPv4 Src Addr IPv4 Dest Addr
------ ------------- --------------
Filter5 172.31.8.X/24 X/0
Filter6 X/0 172.30.10.1/32
A packet containing {IP Dest Addr 172.31.8.1, IP Src Addr 172.30.10.1} cannot be uniquely classified by this pair of filters and so a precedence must be established between Filter5 and Filter6 in order to break the tie. This precedence must be established either (a) by a manager which knows that the router can accomplish this particular ordering (e.g., by means of reported capabilities), or (b) by the router along with a mechanism to report to a manager which precedence is being used. Such precedence mechanisms must be supported in any translation of this model into specific syntax for configuration and management protocols.
{IP取引先ADDR 172.31.8.1、IP ADDRのSrc 172.30.10.1}を含むパケットは、一意のフィルタのこのペアによって分類することができないので、優先順位がタイを破壊するためにFilter5とFilter6間で確立されなければなりません。この順位は、（a）は、ルータが（報告機能により、例えば）は、この特定の順序を達成することができることを知っている、または管理者が（b）のメカニズムとともに、ルータによってその優先管理者に報告するために設立されなければなりません使用されています。このような優先順位のメカニズムは、構成および管理プロトコルのために特定の構文には、このモデルのいずれかの翻訳でサポートされている必要があります。
As another example, one might want first to disallow certain applications from using the network at all, or to classify some individual traffic streams that are not Diffserv-marked. Traffic that is not classified by those tests might then be inspected for a DSCP. The word "then" implies sequence and this must be specified by means of precedence.
別の例として、1は、すべてのネットワークを使用してから特定のアプリケーションを許可しないように、またはDiffservの-マークされていないいくつかの個々のトラフィックストリームを分類する最初の場合があります。それらのテストによって分類されていないトラフィックは、DSCPのために検査することがあります。言葉は「それから」は、配列を意味し、これは優先順位によって指定する必要があります。
An unambiguous classifier requires that every possible classification key match at least one filter (possibly the wildcard default) and that any ambiguity between overlapping filters be resolved by precedence. Therefore, the classifiers on any given interface must be "complete" and will often include an "everything else" filter as the lowest precedence element in order for the result of classification to be deterministic. Note that this completeness is only required of the first classifier that incoming traffic will meet as it enters an interface - subsequent classifiers on an interface only need to handle the traffic that it is known that they will receive.
明確な分類器は、すべての可能な分類キーマッチ少なくとも1つのフィルタ（おそらくワイルドカードデフォルト）ということと、重複フィルタ間のいずれかの曖昧さを優先して解決されている必要があります。したがって、任意のインターフェイス上の分類は「完全」でなければならず、多くの場合、決定論的にする分類の結果ためには最低優先要素として「他のすべて」フィルタが含まれます。インターフェイス上で、その後の分類だけで、彼らが受け取ることが知られていることをトラフィックを処理する必要がある - この完成度だけ、それがインターフェイスに入ると、着信トラフィックが会う最初の分類器に要求されることに注意してください。
This model of classifier operation makes the assumption that all filters of the same precedence be applied simultaneously. Whilst convenient from a modeling point-of-view, this may or may not be how the classifier is actually implemented - this assumption is not intended to dictate how the implementation actually handles this, merely to clearly define the required end result.
分類器の操作のこのモデルは、同じ優先順位のすべてのフィルタを同時に適用することを前提になります。モデリングの視点から、便利な一方で、これはあるいは分類器が実際にどのように実装されるかであってもなくてもよい - この仮定は、実装が実際に明確に必要な最終結果を定義するだけで、これをどのように処理するかを指示するものではありません。
The simplest Diffserv classifier is a behavior aggregate (BA) classifier [DSARCH]. A BA classifier uses only the Diffserv codepoint (DSCP) in a packet's IP header to determine the logical output stream to which the packet should be directed. We allow only an exact-match condition on this field because the assigned DSCP values have no structure, and therefore no subset of DSCP bits are significant.
最も単純なDiffservの分類器は、行動集合体（BA）クラシファイア[DSARCH]です。 BAクラシファイアは、パケットが向けられる先の論理出力ストリームを決定するために、パケットのIPヘッダ内のみのDiffservコードポイント（DSCP）を使用します。割り当てられたDSCPの値は全く構造を有していないので、我々はこのフィールドにのみ完全一致条件を可能にし、したがって、DSCPビットのないサブセットは重要ではありません。
The following defines a possible BA filter:
以下は、可能なBAフィルタを定義します。
Filter8: Type: BA Value: 111000
Filter8：タイプ：BA値：111000
Another type of classifier is a multi-field (MF) classifier [DSARCH]. This classifies packets based on one or more fields in the packet (possibly including the DSCP). A common type of MF classifier is a 6-tuple classifier that classifies based on six fields from the IP and TCP or UDP headers (destination address, source address, IP protocol, source port, destination port, and DSCP). MF classifiers may classify on other fields such as MAC addresses, VLAN tags, link-layer traffic class fields, or other higher-layer protocol fields.
分類器の別のタイプは、マルチフィールド（MF）クラシファイア[DSARCH]です。これは、（おそらくDSCPを含む）は、パケット内の1つの以上のフィールドに基づいてパケットを分類します。 MF分類器の一般的なタイプは、IPとTCPまたはUDPヘッダ（宛先アドレス、ソースアドレス、IPプロトコル、送信元ポート、宛先ポート、およびDSCP）からの6つのフィールドに基づいて分類し、6タプル分類器です。 MF分類器は、MACアドレス、VLANタグ、リンクレイヤトラフィッククラスフィールド、または他の上位層プロトコルフィールドのような他の分野に分類することができます。
The following defines a possible MF filter:
以下は、可能なMFフィルタを定義します。
Filter9: Type: IPv4-6-tuple IPv4DestAddrValue: 0.0.0.0 IPv4DestAddrMask: 0.0.0.0 IPv4SrcAddrValue: 172.31.8.0 IPv4SrcAddrMask: 255.255.255.0 IPv4DSCP: 28 IPv4Protocol: 6 IPv4DestL4PortMin: 0 IPv4DestL4PortMax: 65535 IPv4SrcL4PortMin: 20 IPv4SrcL4PortMax: 20
Filter9：タイプ：IPv4-6タプルIPv4DestAddrValue：0.0.0.0 IPv4DestAddrMask：0.0.0.0 IPv4SrcAddrValue：172.31.8.0 IPv4SrcAddrMask：255.255.255.0 IPv4DSCP：28 IPv4Protocol：6 IPv4DestL4PortMin：0 IPv4DestL4PortMax：65535 IPv4SrcL4PortMin：20 IPv4SrcL4PortMax：20
A similar type of classifier can be defined for IPv6.
分類器の同様のタイプは、IPv6のために定義することができます。
A Free-form classifier is made up of a set of user definable arbitrary filters each made up of {bit-field size, offset (from head of packet), mask}:
自由形式の分類器はそれぞれ{（パケットの先頭からの）ビットオフセットフィールドサイズ、マスク}で構成されたユーザ定義可能な任意のフィルタの組で構成されています。
Classifier2: Filter12: OutputA Filter13: OutputB Default: OutputC
分類子2：Filter12：出力Filter13：出力デフォルト：出力
Filter12: Type: FreeForm SizeBits: 3 (bits) Offset: 16 (bytes) Value: 100 (binary) Mask: 101 (binary)
Filter12：タイプ：自由形SizeBits：3（ビット）オフセット：16（バイト）値：100（バイナリ）マスク：101（バイナリ）
Filter13: Type: FreeForm SizeBits: 12 (bits) Offset: 16 (bytes) Value: 100100000000 (binary) Mask: 111111111111 (binary)
Filter13：タイプ：自由形SizeBits：12（ビット）オフセット：16（バイト）値：1001億（バイナリ）マスク：111111111111（バイナリ）
Free-form filters can be combined into filter groups to form very powerful filters.
自由形式のフィルタは、非常に強力なフィルタを形成するために、フィルタグループにまとめることができます。
Classification may also be performed based on information at the datalink layer below IP (e.g., VLAN or datalink-layer priority) or perhaps on the ingress or egress IP, logical or physical interface identifier (e.g., the incoming channel number on a channelized interface). A classifier that filters based on IEEE 802.1p Priority and on 802.1Q VLAN-ID might be represented as:
分類はまた、IP以下のデータリンク層での情報に基づいて行われてもよい（例えば、VLANまたはデータリンク層優先）入力または出力IP、論理的または物理的なインタフェース識別子におそらく又は（例えば、チャネル化インターフェイスの着信チャネル番号） 。 IEEE 802.1pプライオリティにと802.1Q VLAN-IDに基づいてフィルタリングし、分類器は、次のように表現されることがあります。
Classifier3: Filter14 AND Filter15: OutputA Default: OutputB
クラシファイア3：Filter14とフィルタ15：出力デフォルト：出力
Filter14: -- priority 4 or 5 Type: Ieee8021pPriority Value: 100 (binary) Mask: 110 (binary)
Filter14 - プライオリティ4または5種類：Ieee8021pPriority値：100（バイナリ）マスク：110（バイナリ）
Filter15: -- VLAN 2304 Type: Ieee8021QVlan Value: 100100000000 (binary) Mask: 111111111111 (binary)
Filter15： - VLAN 2304タイプ：Ieee8021QVlan値：1001億（バイナリ）マスク：111111111111（バイナリ）
Such classifiers may be the subject of other standards or may be proprietary to a router vendor but they are not discussed further here.
このような分類は、他の規格の対象であってもよいし、ルータのベンダーに独自のかもしれないが、彼らはさらに、ここで議論されていません。
Metering is defined in [DSARCH]. Diffserv network providers may choose to offer services to customers based on a temporal (i.e., rate) profile within which the customer submits traffic for the service. In this event, a meter might be used to trigger real-time traffic conditioning actions (e.g., marking) by routing a non-conforming packet through an appropriate next-stage action element. Alternatively, by counting conforming and/or non-conforming traffic using a Counter element downstream of the Meter, it might also be used to help in collecting data for out-of-band management functions such as billing applications.
計量[DSARCH]で定義されています。 Diffservのネットワークプロバイダは、顧客がサービスのトラフィックを提出、その中の時間（すなわち、レート）プロファイルに基づいて顧客にサービスを提供することもできます。この場合、メータは適切な次段のアクション要素を介し不適合パケットをルーティングすることによって（例えば、マーキング）リアルタイムトラフィック調整アクションをトリガするために使用されるかもしれません。また、下流メーターのカウンター要素を使用してトラフィックを準拠および/または非準拠数えることによって、また、このような課金アプリケーションなどの帯域外管理機能のためのデータの収集に役立つために使用される可能性があります。
Meters are logically 1:N (fan-out) devices (although a multiplexor can be used in front of a meter). Meters are parameterized by a temporal profile and by conformance levels, each of which is associated with a meter's output. Each output can be connected to another functional element.
メーターは、論理的に1：N（ファンアウト）装置（マルチプレクサメーターの前に使用することができます）。メーターは時間プロファイルによって、およびメータの出力に関連付けられているそれぞれが適合レベルによってパラメータ化されます。各出力は、別の機能素子に接続することができます。
Note that this model of a meter differs slightly from that described in [DSARCH]. In that description the meter is not a datapath element but is instead used to monitor the traffic stream and send control signals to action elements to dynamically modulate their behavior based on the conformance of the packet. This difference in the description does not change the function of a meter. Figure 4 illustrates a meter with 3 levels of conformance.
計器のこのモデルは[DSARCH]に記載されたものとは若干異なることに注意してください。その説明ではメーターは、データパス要素ではなく、代わりに、トラフィックストリームを監視し、動的パケットの適合性に基づいて、その動作を調節するためにアクション要素に制御信号を送信するために使用されます。説明のこの差は、メーターの機能を変更しません。図4は、適合性の3つのレベルを有するメータを示します。
In some Diffserv examples (e.g., [AF-PHB]), three levels of conformance are discussed in terms of colors, with green representing conforming, yellow representing partially conforming and red representing non-conforming. These different conformance levels may be used to trigger different queuing, marking or dropping treatment later on in the processing. Other example meters use a binary notion of conformance; in the general case N levels of conformance can be supported. In general there is no constraint on the type of functional datapath element following a meter output, but care must be taken not to inadvertently configure a datapath that results in packet reordering that is not consistent with the requirements of the relevant PHB specification.
いくつかのDiffservの例では（例えば、[AF-PHB]）、適合性の3つのレベルが緑色表す適合、黄色表す部分的適合と赤を表す不適合と、色の観点から議論されています。これらの異なる適合レベルは、処理の後の処理をマーキングまたはドロップ、異なるキューイングをトリガするために使用されてもよいです。他の例示的なメーターは、適合のバイナリ概念を使用します。一般的な場合に適合性のNレベルをサポートすることができます。一般に、そこ計出力以下の機能データパス要素のタイプには制約はないが、注意が不注意に関連PHB仕様の要件と一致しないパケットの並び替えをもたらすデータパスを設定しないように注意しなければなりません。
unmetered metered
traffic traffic
+---------+
| |--------> conformance A
--------->| meter |--------> conformance B
| |--------> conformance C
+---------+
Figure 4. A Generic Meter
図4. Aジェネリックメーター
A meter, according to this model, measures the rate at which packets making up a stream of traffic pass it, compares the rate to some set of thresholds, and produces some number of potential results (two or more): a given packet is said to be "conformant" to a level of the meter if, at the time that the packet is being examined, the stream appears to be within the rate limit for the profile associated with that level. A fuller discussion of conformance to meter profiles (and the associated requirements that this places on the schedulers upstream) is provided in Appendix A.
メーターは、このモデルによれば、それを通るトラフィックのストリームを構成するパケット速度は、しきい値のいくつかのセットに速度を比較測定し、潜在的な結果（2つ以上）のいくつかの数を生成する：所与のパケットが言われていますもしメートルのレベルに「適合」であると、パケットが検査された時点で、ストリームがそのレベルに関連付けられたプロファイルの速度制限内にあるように見えます。 （アップストリームスケジューラにこの場所はと関連要件）付録Aに提供されるメータプロファイルへの適合のより完全な議論
The following are some examples of possible meters.
可能メートルのいくつかの例です。
An example of a very simple meter is an average rate meter. This type of meter measures the average rate at which packets are submitted to it over a specified averaging time.
非常にシンプルなメーターの例は、平均レートメーターです。メートルのこのタイプは、パケットが指定した平均時間をかけて、それに提出される平均レートを測定します。
An average rate profile may take the following form:
平均速度プロファイルは、以下の形態をとることができます。
Meter1: Type: AverageRate Profile: Profile1 ConformingOutput: Queue1 NonConformingOutput: Counter1
Meter1：タイプ：AverageRateプロフィール：というプロファイルConformingOutput：QUEUE1 NonConformingOutput：カウンタ
Profile1: Type: AverageRate AverageRate: 120 kbps Delta: 100 msec
プロファイル：タイプ：AverageRate AverageRate：120 kbpsのデルタ：100ミリ秒
A Meter measuring against this profile would continually maintain a count that indicates the total number and/or cumulative byte-count of packets arriving between time T (now) and time T - 100 msecs. So long as an arriving packet does not push the count over 12 kbits in the last 100 msec, the packet would be deemed conforming. Any packet that pushes the count over 12 kbits would be deemed non-conforming. Thus, this Meter deems packets to correspond to one of two conformance levels: conforming or non-conforming, and sends them on for the appropriate subsequent treatment.
100ミリ秒 - このプロファイルに対してメーター測定は継続時間T（現在）と時間tとの間に到着するパケットの総数および/または累積バイト数を示すカウント値を維持します。だから、長い到着したパケットは、最後の100ミリ秒に12人のキロビットの上に、カウントをプッシュしていないとして、パケットが準拠とみなされます。 12人のキロビットの上に、カウントをプッシュする任意のパケットが不適合とみなされます。適合または不適合、及び適切なその後の処理のためにそれらを送信する：従って、このメータは、二つの適合レベルの1つに対応するパケットを認めます。
The EWMA form of Meter is easy to implement in hardware and can be parameterized as follows:
メーターのEWMA形態は、ハードウェアで実装するのが容易であり、次のようにパラメータ化することができます。
avg_rate(t) = (1 - Gain) * avg_rate(t') + Gain * rate(t) t = t' + Delta
avg_rate（T）=（1 - ゲイン）* avg_rate（T '）+ゲイン*率（T）T = T' +デルタ
For a packet arriving at time t:
時刻tに到着したパケットの場合：
if (avg_rate(t) > AverageRate) non-conforming else conforming
（avg_rate（T）> AverageRate）は、他の非適合準拠している場合
"Gain" controls the time constant (e.g., frequency response) of what is essentially a simple IIR low-pass filter. "Rate(t)" measures the number of incoming bytes in a small fixed sampling interval, Delta. Any packet that arrives and pushes the average rate over a predefined rate AverageRate is deemed non-conforming. An EWMA Meter profile might look something like the following:
「ゲイン」は、本質的に、単純なIIRローパスフィルタであるものの時定数（例えば、周波数応答）を制御します。 「レート（t）が」小さな一定のサンプリング間隔、デルタの着信バイト数を測定します。到着しAverageRateが非準拠とみなされる予め定義された速度の平均速度を押す任意のパケット。 EWMAメータープロファイルは、次のようになります。
Meter2: Type: ExpWeightedMovingAvg Profile: Profile2 ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper1
Meter2：タイプ：ExpWeightedMovingAvgプロファイル：プロファイル2 ConformingOutput：QUEUE1 NonConformingOutput：AbsoluteDropper1
Profile2: Type: ExpWeightedMovingAvg AverageRate: 25 kbps Delta: 10 usec Gain: 1/16
プロファイル2：タイプ：ExpWeightedMovingAvg AverageRate：25 kbpsのデルタ：10マイクロ秒ゲイン：1/16
A more sophisticated Meter might measure conformance to a token bucket (TB) profile. A TB profile generally has two parameters, an average token rate, R, and a burst size, B. TB Meters compare the arrival rate of packets to the average rate specified by the TB profile. Logically, tokens accumulate in a bucket at the average rate, R, up to a maximum credit which is the burst size, B. When a packet of length L arrives, a conformance test is applied. There are at least two such tests in widespread use:
より洗練されたメーターは、トークンバケット（TB）プロファイルへの適合性を測定することがあります。 TBプロファイルは、一般的に二つのパラメータ、平均トークンレート、R、及びバーストサイズを有する、B. TBメータTBプロファイルで指定された平均速度にパケットの到着率を比較します。論理的に、トークンは最大バーストサイズ、長さLのパケットが到着するとB.、適合性テストが適用される最大信用に、平均速度、Rにてバケットに蓄積します。広く使用され、少なくとも二つのそのようなテストがあります。
Strict conformance Packets of length L bytes are considered conforming only if there are sufficient tokens available in the bucket at the time of packet arrival for the complete packet (i.e., the current depth is greater than or equal to L): no tokens may be borrowed from future token allocations. For examples of this approach, see [SRTCM] and [TRTCM].
いかなるトークンを借りなくてもよい。長さLバイトの厳密な適合パケットは完全なパケット（すなわち、現在の深さがより大きいかまたはLに等しい）のパケット到着時のバケットで利用可能な十分なトークンが存在する場合にのみ適合と見なされます将来のトークンの割り当てから。この方法の例については、[TRTCM] [SRTCM]参照。
Loose conformance Packets of length L bytes are considered conforming if any tokens are available in the bucket at the time of packet arrival: up to L bytes may then be borrowed from future token allocations.
任意のトークンは、パケット到着時のバケットに利用可能である場合、長さLバイトの緩い適合パケットが適合であると考えられる：Lバイトまでは、将来のトークンの割り当てから借用されてもよいです。
Packets are allowed to exceed the average rate in bursts up to the burst size. For further discussion of loose and strict conformance to token bucket profiles, as well as system and implementation issues, see Appendix A.
パケットがバーストサイズまでのバーストの平均速度を超えることが許されます。緩いと厳格なバケットプロファイルをトークンへの適合性だけでなく、システムや実装の問題のさらなる議論については、付録Aを参照してください。
A two-parameter TB meter has exactly two possible conformance levels (conforming, non-conforming). Such a meter might appear as follows:
2パラメータTB計は正確に二つの可能な適合レベル（適合、不適合）を有しています。次のようなメーターが表示されることがあります。
Meter3: Type: SimpleTokenBucket Profile: Profile3 ConformanceType: loose ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper1
Meter3：タイプ：SimpleTokenBucketプロファイル：プロファイル3 ConformanceType：緩いConformingOutput：QUEUE1 NonConformingOutput：AbsoluteDropper1
Profile3: Type: SimpleTokenBucket AverageRate: 200 kbps BurstSize: 100 kbytes
プロファイル3：タイプ：SimpleTokenBucket AverageRate：200 kbpsのBurstSize：100キロバイト
More complicated TB meters might define multiple burst sizes and more conformance levels. Packets found to exceed the larger burst size are deemed non-conforming. Packets found to exceed the smaller burst size are deemed partially-conforming. Packets exceeding neither are deemed conforming. Some token bucket meters designed for Diffserv networks are described in more detail in [SRTCM, TRTCM]; in some of these references, three levels of conformance are discussed in terms of colors with green representing conforming, yellow representing partially conforming, and red representing non-conforming. Note that these multiple-conformance-level meters can sometimes be implemented using an appropriate sequence of multiple two-parameter TB meters.
より複雑なTB計は、複数のバーストサイズとより適合性レベルを定義するかもしれません。大きなバーストサイズを超えることが見出されたパケットは、非準拠とみなされます。小さなバーストサイズを超えることが見出されたパケットは、部分的に準拠と見なされます。超過パケットはどちらが準拠するものとみなされます。 Diffservのネットワークのために設計されたいくつかのトークンバケットメートル[SRTCM、TRTCM]に詳細に記載されています。これらの参考文献のいくつかでは、適合性の三つのレベルは、適合表す緑色部分的に適合表す黄色、及び赤色不適合表すと色の観点から議論されています。これら複数の適合レベルメーターは、時々複数の2パラメータTBメーターの適切な配列を使用して実施することができることに留意されたいです。
A profile for a multi-stage TB meter with three levels of conformance might look as follows:
以下のようになります準拠の3つのレベルを持つ多段TBメーターのプロファイル：
Meter4: Type: TwoRateTokenBucket ProfileA: Profile4 ConformanceTypeA: strict ConformingOutputA: Queue1
Meter4：タイプ：TwoRateTokenBucketのプロファイルA：Profile4 ConformanceTypeA：厳密ConformingOutputA：QUEUE1
ProfileB: Profile5 ConformanceTypeB: strict ConformingOutputB: Marker1 NonConformingOutput: AbsoluteDropper1
プロファイルB：Profile5 ConformanceTypeB：厳密に準拠出力：MARKER1不適合出力：AbsoluteDropper1
Profile4: Type: SimpleTokenBucket AverageRate: 100 kbps BurstSize: 20 kbytes
Profile4：タイプ：SimpleTokenBucket AverageRate：100 kbpsのBurstSize：20キロバイト
Profile5: Type: SimpleTokenBucket AverageRate: 100 kbps BurstSize: 100 kbytes
Profile5：タイプ：SimpleTokenBucket AverageRate：100 kbpsのBurstSize：100キロバイト
A null meter has only one output: always conforming, and no associated temporal profile. Such a meter is useful to define in the event that the configuration or management interface does not have the flexibility to omit a meter in a datapath segment.
常に準拠し、無関連する時間的プロファイル：nullのメーターが1つの出力だけを持っています。そのような計器は、構成または管理インターフェイスはデータパスセグメントにメータを省略するための柔軟性を持っていない場合に定義することが有用です。
Meter5: Type: NullMeter Output: Queue1
Meter5：タイプ：ゼロメータ出力：QUEUE1
The classifiers and meters described up to this point are fan-out elements which are generally used to determine the appropriate action to apply to a packet. The set of possible actions that can then be applied include:
ここまで説明した分類器および計器は、一般的にパケットに適用するための適切なアクションを決定するために使用されるファンアウト要素です。その後、適用され得る可能なアクションのセットは、次のとおりです。
- Marking
- マーキング
- Absolute Dropping
- 絶対ドロップ
- Multiplexing
- 多重化
- Counting
- カウンティング
- Null action - do nothing
- ヌルアクション - 何もしません
The corresponding action elements are described in the following sections.
対応するアクション要素は、以下のセクションに記載されています。
DSCP Markers are 1:1 elements which set a codepoint (e.g., the DSCP in an IP header). DSCP Markers may also act on unmarked packets (e.g., those submitted with DSCP of zero) or may re-mark previously marked packets. In particular, the model supports the application of marking based on a preceding classifier match. The mark set in a packet will determine its subsequent PHB treatment in downstream nodes of a network and possibly also in subsequent processing stages within this router.
コードポイントを設定する1要素（例えば、IPヘッダ内のDSCP）：DSCPマーカーは1です。 DSCPマーカーはまた、（例えばゼロのDSCPとともに提出されるもの）マークされていないパケットに作用するまたは再マーク以前にパケットをマークしてもよいです。具体的には、モデルは、前の分類器一致に基づいて、マーキングのアプリケーションをサポートします。パケットに設定されたマークは、このルータ内の後続の処理段階で、おそらく、ネットワークの下流ノードにその後のPHB処理を決定します。
DSCP Markers for Diffserv are normally parameterized by a single parameter: the 6-bit DSCP to be marked in the packet header.
パケットヘッダーにマークする6ビットDSCP：DiffservのためのDSCPマーカーは、通常、単一のパラメータによってパラメータ化されます。
Marker1: Type: DSCPMarker Mark: 010010
MARKER1：タイプ：DSCPMarkerマーク：010010
Absolute Droppers simply discard packets. There are no parameters for these droppers. Because this Absolute Dropper is a terminating point of the datapath and has no outputs, it is probably desirable to forward the packet through a Counter Action first for instrumentation purposes.
絶対ドロッパーは、単にパケットを破棄します。これらのドロッパのためのパラメータはありません。この絶対的なドロッパーは、データパスの終点で、何の出力を持っていないので、計測のために、第1カウンタのアクションを介してパケットを転送するために、おそらく望ましいです。
AbsoluteDropper1: Type: AbsoluteDropper
AbsoluteDropper1：タイプ：AbsoluteDropper
Absolute Droppers are not the only elements than can cause a packet to be discarded: another element is an Algorithmic Dropper element (see Section 7.1.3). However, since this element's behavior is closely tied the state of one or more queues, we choose to distinguish it as a separate functional datapath element.
絶対ドロッパーは、パケットが破棄される可能性がありますよりも、唯一の要素ではありません。別の要素は、アルゴリズムのドロッパー要素である（7.1.3項を参照してください）。この要素の動作が密接に1つ以上のキューの状態を結ばれているのでしかし、我々は独立した機能データパス要素としてそれを区別することを選択しました。
It is occasionally necessary to multiplex traffic streams into a functional datapath element with a single input. A M:1 (fan-in) multiplexor is a simple logical device for merging traffic streams. It is parameterized by its number of incoming ports.
単一の入力を有する機能データパス素子にトラフィックストリームを多重化することが時折必要です。 M：1（ファンイン）マルチプレクサは、トラフィックストリームをマージするための単純な論理デバイスです。これは、着信ポートのその番号によってパラメータ化されます。
Mux1: Type: Multiplexor Output: Queue2
MUX1：タイプ：マルチプレクサ出力：キュー2
One passive action is to account for the fact that a data packet was processed. The statistics that result might be used later for customer billing, service verification or network engineering purposes. Counters are 1:1 functional datapath elements which update a counter by L and a packet counter by 1 every time a L-byte sized packet passes through them. Counters can be used to count packets about to be dropped by an Absolute Dropper or to count packets arriving at or departing from some other functional element.
一つの受動的アクションは、データパケットが処理されたという事実を考慮するためです。結果の統計は、顧客請求、サービスの検証やネットワークエンジニアリングの目的のために、後に使用されるかもしれません。 1によってその更新LによるカウンタとパケットカウンタLバイトサイズのパケットがそれらを通過するたびに1機能データパスエレメント：カウンタは1です。カウンターは絶対スポイトで廃棄されようとしてパケットをカウントしたり、パケットに到着するか、他のいくつかの機能要素から逸脱をカウントするために使用することができます。
Counter1: Type: Counter Output: Queue1
カウンタ1：タイプ：カウンタ出力：QUEUE1
A null action has one input and one output. The element performs no action on the packet. Such an element is useful to define in the event that the configuration or management interface does not have the flexibility to omit an action element in a datapath segment.
nullのアクションは、1つの入力と1つの出力があります。要素は、パケット上のアクションを実行しません。そのような要素は、構成または管理インターフェイスはデータパスセグメントに作用要素を省略するための柔軟性を持っていない場合に定義することが有用です。
Null1: Type: Null Output: Queue1
Null1：タイプ：ヌル出力：QUEUE1
Queuing elements modulate the transmission of packets belonging to the different traffic streams and determine their ordering, possibly storing them temporarily or discarding them. Packets are usually stored either because there is a resource constraint (e.g., available bandwidth) which prevents immediate forwarding, or because the queuing block is being used to alter the temporal properties of a traffic stream (i.e., shaping). Packets are discarded for one of the following reasons:
キューの要素は、異なるトラフィックストリームに属するパケットの伝送を調節し、おそらく一時的に格納したり、それらを廃棄し、その順序を決定します。即時転送を防ぐ、またはキューイングブロックは、トラフィックストリーム（すなわち、整形）の時間的特性を変化させるために使用されているため、リソースの制約（例えば、利用可能な帯域幅）があるので、パケットは通常のいずれかの記憶されています。パケットは、次のいずれかの理由で破棄されています。
- because of buffering limitations. - because a buffer threshold is exceeded (including when shaping is performed). - as a feedback control signal to reactive control protocols such as TCP. - because a meter exceeds a configured profile (i.e., policing).
- バッファリングの制限のため。 - バッファ閾値は、（整形が行われた場合を含む）を超えているからです。 - TCPのような反応性制御プロトコルにフィードバック制御信号として。 - メータが構成されたプロファイルを超えているため（すなわち、ポリシング）。
The queuing elements in this model represent a logical abstraction of a queuing system which is used to configure PHB-related parameters. The model can be used to represent a broad variety of possible implementations. However, it need not necessarily map one-to-one with physical queuing systems in a specific router implementation. Implementors should map the configurable parameters of the implementation's queuing systems to these queuing element parameters as appropriate to achieve equivalent behaviors.
このモデルにおけるキューイング要素はPHB関連のパラメータを設定するために使用される待ち行列システムの論理的な抽象化を表します。モデルは、可能な実装の幅広い種類を表すために使用することができます。しかし、それは必ずしも特定のルータの実装では、物理キューイング・システムとの1対1をマッピングする必要はありません。実装者は、同等の動作を実現するために、必要に応じてこれらのキューイング素子パラメータに実装のキューイング・システムの設定可能なパラメータをマップする必要があります。
Queuing is a function which lends itself to innovation. It must be modeled to allow a broad range of possible implementations to be represented using common structures and parameters. This model uses functional decomposition as a tool to permit the needed latitude.
キューイングは、技術革新に役立つ機能です。可能な実装の広い範囲は、共通の構造およびパラメータを使用して表すことができるようにするためにモデル化されなければなりません。このモデルは、必要な緯度を可能にするためのツールとして機能分解を使用しています。
Queuing systems perform three distinct, but related, functions: they store packets, they modulate the departure of packets belonging to various traffic streams and they selectively discard packets. This model decomposes queuing into the component elements that perform each of these functions: Queues, Schedulers, and Algorithmic Droppers, respectively. These elements may be connected together as part of a TCB, as described in section 8.
キューイングシステムは3、異なった、しかし関連の機能を実行します。彼らは、様々なトラフィックストリームに属するパケットの出発を調節し、彼らが選択的にパケットを破棄し、パケットを格納します。それぞれのキュー、スケジューラ、及びアルゴリズムドロッパー、このモデルは、これらの機能の各々を実行する構成要素にキューイング分解する。セクション8に記載されているようにこれらの要素は、TCBの一部として一緒に接続されていてもよいです。
The remainder of this section discusses FIFO Queues: typically, the Queue element of this model will be implemented as a FIFO data structure. However, this does not preclude implementations which are not strictly FIFO, in that they also support operations that remove or examine packets (e.g., for use by discarders) other than at the head or tail. However, such operations must not have the effect of reordering packets belonging to the same microflow.
このセクションの残りの部分は、FIFOキューの説明：一般的に、このモデルのキュー要素がFIFOデータ構造として実装されるであろう。しかしながら、これは、その中で彼らはまた、頭部または尾以外で（discardersで使用するために、例えば）を除去又はパケットを検査動作をサポートする、厳密にはFIFOではない実装を排除するものではありません。しかし、このような操作は同じマイクロフローに属するパケットの順序を変更する効果を持っていなければなりません。
Note that the term FIFO has multiple different common usages: it is sometimes taken to mean, among other things, a data structure that permits items to be removed only in the order in which they were inserted or a service discipline which is non-reordering.
時々とりわけ、意味するものと理解され、それらが挿入された順序または非並べ替えであるサービス規律にのみ削除するアイテムを許可するデータ構造を：用語がFIFOは、複数の異なる一般的な用法を持っていることに注意してください。
In this model, a FIFO Queue element is a data structure which at any time may contain zero or more packets. It may have one or more thresholds associated with it. A FIFO has one or more inputs and exactly one output. It must support an enqueue operation to add a packet to the tail of the queue and a dequeue operation to remove a packet from the head of the queue. Packets must be dequeued in the order in which they were enqueued. A FIFO has a current depth, which indicates the number of packets and/or bytes that it contains at a particular time. FIFOs in this model are modeled without inherent limits on their depth - obviously this does not reflect the reality of implementations: FIFO size limits are modeled here by an algorithmic dropper associated with the FIFO, typically at its input. It is quite likely that every FIFO will be preceded by an algorithmic dropper. One exception might be the case where the packet stream has already been policed to a profile that can never exceed the scheduler bandwidth available at the FIFO's output - this would not need an algorithmic dropper at the input to the FIFO.
このモデルでは、FIFOキュー・エレメントは、いつでもゼロまたはそれ以上のパケットを含むことができるデータ構造です。それは、それに関連する1つの以上の閾値を有することができます。 FIFOは、1つまたは複数の入力と正確に1つの出力を持っています。これは、キューの先頭からパケットを削除するキューとデキュー操作の末尾にパケットを追加するためにエンキュー操作をサポートしている必要があります。パケットは、エンキューされた順序でデキューする必要があります。 FIFOは、それが特定の時間に含まれたパケット及び/又はバイト数を示す現在の深さを有しています。 FIFOサイズの制限は、典型的には、その入力で、FIFOと関連アルゴリズムスポイトによりここにモデル化される：明らかに、これは実装の現実を反映していない - このモデルにおけるFIFOは、その深さに固有の制限なしでモデル化されます。すべてのFIFOは、アルゴリズムのドロッパーによって先行される可能性が極めて高いです。唯一の例外は、パケットストリームがすでにFIFOの出力で利用可能スケジューラ帯域幅を超えることはできませんプロファイルにポリシングされた場合であるかもしれない - これはFIFOへの入力でアルゴリズムのドロッパーを必要としません。
This representation of a FIFO allows for one common type of depth limit, one that results from a FIFO supplied from a limited pool of buffers, shared between multiple FIFOs.
FIFOのこの表現は、深さ制限の一つの共通のタイプ、複数のFIFOとの間で共有バッファの限られたプールから供給されるFIFOから生じるものを可能にします。
In an implementation, packets are presumably stored in one or more buffers. Buffers are allocated from one or more free buffer pools. If there are multiple instances of a FIFO, their packet buffers may or may not be allocated out of the same free buffer pool. Free buffer pools may also have one or more thresholds associated with them, which may affect discarding and/or scheduling. Other than this, buffering mechanisms are implementation specific and not part of this model.
実装では、パケットは、おそらく1つまたは複数のバッファに格納されています。バッファは、一つ以上の空きバッファ・プールから割り当てられます。 FIFOの複数のインスタンスがある場合、そのパケットバッファは、同じフリーバッファプールの外に割り当てられていてもいなくてもよいです。フリーバッファプールも廃棄および/またはスケジュールに影響を与える可能性がある、それらに関連する1つのまたは複数の閾値を有することができます。これ以外に、バッファリングメカニズムは、実装固有のではなく、このモデルの一部です。
A FIFO might be represented using the following parameters:
FIFOは、次のパラメータを使用して表現される場合があります。
Queue1: Type: FIFO Output: Scheduler1
QUEUE1：タイプ：FIFO出力：Scheduler1
Note that a FIFO must provide triggers and/or current state information to other elements upstream and downstream from it: in particular, it is likely that the current depth will need to be used by Algorithmic Dropper elements placed before or after the FIFO. It will also likely need to provide an implicit "I have packets for you" signal to downstream Scheduler elements.
特に、現在の深さは、FIFOの前または後に配置アルゴリズムスポイト要素によって使用される必要がある可能性がある：FIFOはそれから上流及び下流の他の要素にトリガおよび/または現在の状態情報を提供しなければならないことに注意してください。また、おそらく下流のスケジューラ要素に暗黙的に「私はあなたのためのパケットを持っている」信号を提供する必要があります。
A scheduler is an element which gates the departure of each packet that arrives at one of its inputs, based on a service discipline. It has one or more inputs and exactly one output. Each input has an upstream element to which it is connected, and a set of parameters that affects the scheduling of packets received at that input.
スケジューラは、ゲート要素サービス規律に基づいて、その入力の1つに到着した各パケットの出発です。これは、1つの以上の入力と正確に1つの出力を持っています。各入力は、それが接続された上流エレメント、およびパケットのスケジューリングは、その入力で受信した影響パラメータのセットを有します。
The service discipline (also known as a scheduling algorithm) is an algorithm which might take any of the following as its input(s):
（また、スケジューリング・アルゴリズムとして知られている）サービス規律は、その入力（S）として、次のいずれかを取るかもしれないアルゴリズムです。
a) static parameters such as relative priority associated with each of the scheduler's inputs.
A）そのようなスケジューラの入力のそれぞれに関連付けられた相対優先順位として静的パラメータ。
b) absolute token bucket parameters for maximum or minimum rates associated with each of the scheduler's inputs.
B）スケジューラの入力のそれぞれに関連付けられた最大値又は最小速度の絶対トークンバケットパラメータ。
c) parameters, such as packet length or DSCP, associated with the packet currently present at its input.
C）その入力に現在存在するパケットに関連付けられている、パケット長やDSCPなどのパラメータを、。
d) absolute time and/or local state.
D）絶対時間及び/又はローカル状態。
Possible service disciplines fall into a number of categories, including (but not limited to) first come, first served (FCFS), strict priority, weighted fair bandwidth sharing (e.g., WFQ), rate-limited strict priority, and rate-based. Service disciplines can be further distinguished by whether they are work-conserving or non-work-conserving (see Glossary). Non-work-conserving schedulers can be used to shape traffic streams to match some profile by delaying packets that might be deemed non-conforming by some downstream node: a packet is delayed until such time as it would conform to a downstream meter using the same profile.
可能なサービス分野では、最初に来る（これらに限定されない）を含む、いくつかのカテゴリに分類最初（FCFS）、厳密優先順位、加重公平な帯域幅の共有（例えば、WFQ）、レート制限厳格な優先順位、およびレートベースを務めました。サービス分野は、彼らが（用語集を参照してください）作業保存または非作業保存されているかどうかによって、さらに区別することができます。非作業保存スケジューラは、トラフィックをシェーピングするために使用することができるいくつかの下流のノードによって不適合とみなされるかもしれないパケットを遅延させ、いくつかのプロファイルに一致するようにストリーム：パケットは、それが同じものを使用して下流計器に適合なるような時間まで遅延されますプロフィール。
[DSARCH] defines PHBs without specifying required scheduling algorithms. However, PHBs such as the class selectors [DSFIELD], EF [EF-PHB] and AF [AF-PHB] have descriptions or configuration parameters which strongly suggest the sort of scheduling discipline needed to implement them. This document discusses a minimal set of queue parameters to enable realization of these PHBs. It does not attempt to specify an all-embracing set of parameters to cover all possible implementation models. A minimal set includes:
【DSARCH】必要なスケジューリング・アルゴリズムを指定せずにのPHBを定義します。しかし、そのようなクラスセレクタ[DSFIELD]などのPHBは、EF [EF-PHB]およびAF [AF-PHB]は強く、それらを実現するために必要なスケジューリング規律の並べ替えを示唆説明や設定パラメータを持っています。この文書では、これらのPHBの実現を可能にするためにキューパラメータの最小セットについて説明します。これは、すべての可能な実装モデルをカバーするためにすべてのパラメータ-抱擁セットを指定しようとしません。最小限のセットが含まれています：
a) a minimum service rate profile which allows rate guarantees for each traffic stream as required by EF and AF without specifying the details of how excess bandwidth between these traffic streams is shared. Additional parameters to control this behavior should be made available, but are dependent on the particular scheduling algorithm implemented.
A）次のトラフィックとの間の過剰帯域幅が共有されているストリーム方法の詳細を指定することなく、EF及びAFによって必要とされる各トラフィック・ストリームのためのレート保証を可能にする最小のサービス速度プロファイル。この動作を制御するための追加のパラメータが使用可能になりますが、実装され、特定のスケジューリング・アルゴリズムに依存するべきです。
b) a service priority, used only after the minimum rate profiles of all inputs have been satisfied, to decide how to allocate any remaining bandwidth.
b）にのみ、すべての入力の最小レートプロファイルが満たされた後で使用されるサービスの優先順位は、残りの帯域幅を割り当てる方法を決定します。
c) a maximum service rate profile, for use only with a non-work-conserving service discipline.
c）の最大サービス速度プロファイル、唯一の非作業保存サービス規律で使用します。
Any one of these profiles is composed, for the purposes of this model, of both a rate (in suitable units of bits, bytes or larger chunks in some unit of time) and a burst size, as discussed further in Appendix A.
付録Aでさらに議論されるようこれらのプロファイルのいずれかが、速度（ビットの適切な単位で、時間のいくつかの単位でチャンクバイト以上）とバーストサイズの両方で、このモデルの目的のために、構成されています
By way of example, for an implementation of the EF PHB using a strict priority scheduling algorithm that assumes that the aggregate EF rate has been appropriately bounded by upstream policing to avoid starvation of other BAs, the service rate profiles are not used: the minimum service rate profile would be defaulted to zero and the maximum service rate profile would effectively be the "line rate". Such an implementation, with multiple priority classes, could also be used for the Diffserv class selectors [DSFIELD].
一例として、集計EF率が適切他のBAの飢餓を避けるために、上流のポリシングによって囲まれていることを前提と完全優先スケジューリングアルゴリズムを使用して、EFのPHBの実装のために、サービスの速度プロファイルが使用されない：最小サービスを速度プロファイルは、ゼロにデフォルト設定されるだろうと、最大サービス速度プロファイルは、実質的に「ラインレート」になります。そのような実装は、複数の優先度クラスと、DiffServクラスセレクタ[DSFIELD]のために使用することもできます。
Alternatively, setting the service priority values for each input to the scheduler to the same value enables the scheduler to satisfy the minimum service rates for each input, so long as the sum of all minimum service rates is less than or equal to the line rate.
あるいは、同じ値にスケジューラにそれぞれ入力するためのサービス優先順位値を設定すると、すべての最小のサービス料金の合計が回線レート以下である限り、各入力の最小サービスレートを満たすためにスケジューラを可能にします。
For example, a non-work-conserving scheduler, allocating spare bandwidth equally between all its inputs, might be represented using the following parameters:
例えば、非作業保存、スケジューラをそのすべての入力の間に均等に予備の帯域幅を割り当てるには、次のパラメータを使用して表現される場合があります。
Scheduler1: Type: Scheduler2Input
Scheduler1：タイプ：Scheduler2Input
Input1: MaxRateProfile: Profile1 MinRateProfile: Profile2 Priority: none
Inpyt1：MachRateProfili：というプロファイルMinRateProfile：プロファイル2優先度：キノン
Input2: MaxRateProfile: Profile3 MinRateProfile: Profile4 Priority: none
Inpyt2：MachRateProfili：Profilex MinRateProfili：Profile4優先度：キノン
A work-conserving scheduler might be represented using the following parameters:
作業保存スケジューラは、以下のパラメータを使用して表現される場合があります。
Scheduler2: Type: Scheduler3Input Input1: MaxRateProfile: WorkConserving MinRateProfile: Profile5 Priority: 1
Scheduler2：タイプ：Scheduler3Input入力1：MaxRateProfile：WorkConserving MinRateProfile：Profile5優先度：1
Input2: MaxRateProfile: WorkConserving MinRateProfile: Profile6 Priority: 2
Inpyt2：MachRateProfili：OorkSonserving MinRateProfili：Profile6優先度：2
Input3: MaxRateProfile: WorkConserving MinRateProfile: none Priority: 3
Inpytx：MachRateProfili：OorkSonserving MinRateProfili：キノンPrioriti：O
An Algorithmic Dropper is an element which selectively discards packets that arrive at its input, based on a discarding algorithm. It has one data input and one output. In this model (but not necessarily in a real implementation), a packet enters the dropper at its input and either its buffer is returned to a free buffer pool or the packet exits the dropper at the output.
アルゴリズムドロッパーは選択廃棄アルゴリズムに基づいて、その入力に到着するパケットを廃棄元素です。これは、1つのデータ入力と1つの出力があります。このモデルでは（必ずしもそうではない実際の実装で）、パケットがその入力でドロッパーに入り、そのバッファは空きバッファ・プールに戻されるか、またはパケットが出力でドロッパーを出るのいずれか。
Alternatively, an Algorithmic Dropper can be thought of as invoking operations on a FIFO Queue which selectively remove a packet and return its buffer to the free buffer pool based on a discarding algorithm. In this case, the operation could be modeled as being a side-effect on the FIFO upon which it operated, rather than as having a discrete input and output. This treatment is equivalent and we choose the one described in the previous paragraph for this model.
あるいは、アルゴリズムスポイトを選択パケットを除去し、廃棄アルゴリズムに基づいて、空きバッファ・プールにそのバッファを返すFIFOキューに対する操作を呼び出すと考えることができます。この場合、操作はなく、離散的な入力及び出力を有するように、それが操作その上にFIFOに副作用であるとしてモデル化することができます。この処理は同等であり、我々はこのモデルの前の段落で説明したものを選択してください。
One of the primary characteristics of an Algorithmic Dropper is the choice of which packet (if any) is to be dropped: for the purposes of this model, we restrict the packet selection choices to one of the following and we indicate the choice by the relative positions of Algorithmic Dropper and FIFO Queue elements in the model:
アルゴリズムのドロッパーの主な特徴の一つは廃棄されるべきパケット（もしあれば）の選択です。このモデルの目的のために、私たちは、次のいずれかにパケット選択の選択肢を制限し、我々は相対的で選択肢を示しモデルにおけるアルゴリズムドロッパーとFIFOキュー要素の位置：
a) selection of a packet that is about to be added to the tail of a queue (a "Tail Dropper"): the output of the Algorithmic Dropper element is connected to the input of the relevant FIFO Queue element.
キューのテール（「テールドロッパー」）に追加されようとしているパケットのA）選択：アルゴリズムドロッパー要素の出力は、関連するFIFOキュー要素の入力に接続されています。
b) a packet that is currently at the head of a queue (a "Head Dropper"): the output of the FIFO Queue element is connected to the input of the Algorithmic Dropper element.
b）は、キュー（「ヘッドドロッパー」）の先頭に現在パケット：FIFOキュー要素の出力は、アルゴリズムスポイト要素の入力に接続されています。
Other packet selection methods could be added to this model in the form of a different type of datapath element.
他のパケットの選択方法は、データパス要素の異なる種類の形態では、このモデルに加えることができます。
The Algorithmic Dropper is modeled as having a single input. It is possible that packets which were classified differently by a Classifier in this TCB will end up passing through the same dropper. The dropper's algorithm may need to apply different calculations based on characteristics of the incoming packet (e.g., its DSCP). So there is a need, in implementations of this model, to be able to relate information about which classifier element was matched by a packet from a Classifier to an Algorithmic Dropper. In the rare cases where this is required, the chosen model is to insert another Classifier element at this point in the flow and for it to feed into multiple Algorithmic Dropper elements, each one implementing a drop calculation that is independent of any classification keys of the packet: this will likely require the creation of a new TCB to contain the Classifier and the Algorithmic Dropper elements.
アルゴリズムドロッパーは単一の入力を有するものとしてモデル化されます。このTCBに分類器によって異なっ分類されたパケットが同じスポイトを通過することになります可能性があります。ドロッパーのアルゴリズムは、着信パケット（例えば、そのDSCP）の特性に基づいて異なる計算を適用する必要があるかもしれません。したがって、このモデルの実装に必要、アルゴリズムスポイトに分類からのパケットにマッチした分類子要素についての情報を関連付けることができるようにするがあります。これが必要とされるまれなケースでは、選択されたモデルは、流れの中でそれが複数のアルゴリズムドロッパー素子に供給するために、この時点での任意の分類キーから独立しているドロップ計算を実施それぞれを別の分類の要素を挿入することですパケット：これはおそらくクラシファイアとアルゴリズムのドロッパー要素を含むように、新たなTCBの作成が必要になります。
NOTE: There are many other formulations of a model that could represent this linkage that are different from the one described above: one formulation would have been to have a pointer from one of the drop probability calculation algorithms inside the dropper to the original Classifier element that selects this algorithm. Another way would have been to have multiple "inputs" to the Algorithmic Dropper element fed from the preceding elements, leading eventually back to the Classifier elements that matched the packet. Yet another formulation might have been for the Classifier to (logically) include some sort of "classification identifier" along with the packet along its path, for use by any subsequent element. And yet another could have been to include a classifier inside the dropper, in order for it to pick out the drop algorithm to be applied. These other approaches could be used by implementations but were deemed to be less clear than the approach taken here.
注：上記のものとは異なるこの結合を表すことができるモデルの多くの他の製剤がある：1つの製剤は、その元の分類の要素にスポイト内部ドロップ確率の計算アルゴリズムの一つからポインタを有するようにされているでしょうこのアルゴリズムを選択します。別の方法は、最終的に戻ってパケットをマッチクラシファイア要素をもたらす、先行する要素から供給されるアルゴリズムスポイト要素に複数の「入力」を有するとされているでしょう。さらに別の処方物は、（論理的）に分類するためであったかもしれない任意の後続の要素で使用するため、その経路に沿ってパケットと共に「分類識別子」のいくつかの並べ替えを含みます。そして、さらに別のは、それが適用されるドロップアルゴリズムを選び出すようにするために、スポイト内部分類子を含めることだったかもしれません。これらの他のアプローチは、実装で使用することができますが、ここで採用するアプローチよりもそれほど明確であると見なされました。
An Algorithmic Dropper, an example of which is illustrated in Figure 5, has one or more triggers that cause it to make a decision whether or not to drop one (or possibly more than one) packet. A trigger may be internal (the arrival of a packet at the input to the dropper) or it may be external (resulting from one or more state changes at another element, such as a FIFO Queue depth crossing a threshold or a scheduling event). It is likely that an instantaneous FIFO depth will need to be smoothed over some averaging interval before being used as a useful trigger. Some dropping algorithms may require several trigger inputs feeding back from events elsewhere in the system (e.g., depth-smoothing functions that calculate averages over more than one time interval).
アルゴリズムドロッパー、図5に示されている例では、それが1つ（またはよりもおそらくそれ以上）のパケットをドロップするか否かの決定を行うさせる一つまたは複数のトリガを有します。トリガは内部（点滴器への入力におけるパケットの到着）であってもよく、またはそれは、（しきい値またはスケジューリングイベントを横切るようなFIFOキューの深さのような他の要素に1つの以上の状態変化に起因する）の外部であってもよいです。瞬間的なFIFOの深さは便利なトリガとして使用される前に、いくつかの平均間隔にわたって平滑化する場合が多くなります。一部滴下アルゴリズムは、他の場所でシステム内のイベント（複数の時間間隔にわたる平均を計算例えば、奥行き平滑化関数）からのフィードバックいくつかのトリガ入力を必要とするかもしれません。
+------------------+ +-----------+
| +-------+ | n |smoothing |
| |trigger|<----------/---|function(s)|
| |calc. | | |(optional) |
| +-------+ | +-----------+
| | | ^
| v | |Depth
Input | +-------+ no | ------------+ to Scheduler
---------->|discard|--------------> |x|x|x|x|------->
| | ? | | ------------+
| +-------+ | FIFO
| |yes |
| | | | |
| | v | count + |
| +---+ bit-bucket|
+------------------+
Algorithmic
Dropper
Figure 5. Example of Algorithmic Dropper from Tail of a Queue
キューの末尾からアルゴリズムドロッパーの5例を図
A trigger may be a boolean combination of events (e.g., a FIFO depth exceeding a threshold OR a buffer pool depth falling below a threshold). It takes as its input some set of dynamic parameters (e.g., smoothed or instantaneous FIFO depth), and some set of static parameters (e.g., thresholds), and possibly other parameters associated with the packet. It may also have internal state (e.g., history of its past actions). Note that, although an Algorithmic Dropper may require knowledge of data fields in a packet, as discovered by a Classifier in the same TCB, it may not modify the packet (i.e., it is not a marker).
トリガは、イベント（例えば、閾値又は閾値を下回るバッファプールの深さを超えてFIFOの深さ）のブール組み合わせであってもよいです。それは、その入力として、動的パラメータ（例えば、平滑又は瞬時FIFOの深さ）のいくつかのセット、及び静的パラメータのいくつかのセット（例えば、閾値）、およびパケットに関連付けられている可能性の他のパラメータを取ります。また、内部状態（例えば、その過去の行動の歴史）を有することができます。 （すなわち、それがマーカーではない）アルゴリズムドロッパーは、パケットのデータフィールドの知識を必要とするかもしれない同じTCBに分類することによって発見されるように、それはパケットを変更しないかもしれないが、なお。
The result of the trigger calculation is that the dropping algorithm makes a decision on whether to forward or to discard a packet. The discarding function is likely to keep counters regarding the discarded packets (there is no appropriate place here to include a Counter Action element).
トリガ計算の結果は、落下アルゴリズムを転送するか、パケットを破棄するかどうかの判定を行うことです。廃棄機能は、廃棄されたパケット（カウンターアクション要素を含むようにここには、適切な場所はありません）に関するカウンタを維持する可能性があります。
The example in Figure 5 also shows a FIFO Queue element from whose tail the dropping is to take place and whose depth characteristics are used by this Algorithmic Dropper. It also shows where a depth-smoothing function might be included: smoothing functions are outside the scope of this document and are not modeled explicitly here, we merely indicate where they might be added.
図5の例では、ドロップが行われると、その深さ特性は、このアルゴリズムのドロッパーで使用されることである、その尾からFIFOキューの要素を示します。また、奥行き平滑化機能が含まれている場合があります場所を示しています。スムージング機能は、この文書の範囲外であり、ここで明示的にモデル化されていない、彼らは追加される可能性がありますどこ我々は単に示しています。
RED, RED-on-In-and-Out (RIO) and Drop-on-threshold are examples of dropping algorithms. Tail-dropping and head-dropping are effected by the location of the Algorithmic Dropper element relative to the FIFO
落下アルゴリズムの一例であるREDオン・イン・アンド・アウト（RIO）とドロップ・オン・スレッショルドRED、。テールドロップとヘッド落下をFIFOに対してアルゴリズムスポイト要素の位置によって行われます
Queue element. As an example, a dropper using a RIO algorithm might be represented using 2 Algorithmic Droppers with the following parameters:
キューの要素。一例として、RIOのアルゴリズムを使用してドロッパーは以下のパラメータを2つのアルゴリズムドロッパーを使用して表されるかもしれません。
AlgorithmicDropper1: (for in-profile traffic) Type: AlgorithmicDropper Discipline: RED Trigger: Internal Output: Fifo1 MinThresh: Fifo1.Depth > 20 kbyte MaxThresh: Fifo1.Depth > 30 kbyte SampleWeight .002 MaxDropProb 1%
AlgorithmicDropper1：（インプロファイルトラフィック用）タイプ：AlgorithmicDropper規律：REDトリガ：内部出力：FIFO1 MinThresh：Fifo1.Depth> 20キロバイトMaxThresh：Fifo1.Depth> 30キロバイトSampleWeight 0.002 MaxDropProb 1％
AlgorithmicDropper2: (for out-of-profile traffic) Type: AlgorithmicDropper Discipline: RED Trigger: Internal Output: Fifo1 MinThresh: Fifo1.Depth > 10 kbyte MaxThresh: Fifo1.Depth > 20 kbyte SampleWeight .002 MaxDropProb 2%
AlgorithmicDropper2：（アウトオブプロファイルトラフィック用）タイプ：AlgorithmicDropper規律：REDトリガ：内部出力：FIFO1 MinThresh：Fifo1.Depth> 10キロバイトMaxThresh：Fifo1.Depth> 20キロバイトSampleWeight 0.002 MaxDropProb 2％
Another form of Algorithmic Dropper, a threshold-dropper, might be represented using the following parameters:
アルゴリズムドロッパー、閾値点滴器の別の形態は、以下のパラメータを使用して表されるかもしれません。
AlgorithmicDropper3: Type: AlgorithmicDropper Discipline: Drop-on-threshold Trigger: Fifo2.Depth > 20 kbyte Output: Fifo1
AlgorithmicDropper3：タイプ：AlgorithmicDropper調教：ドロップ・オン・スレッシュホールドトリガー：Fifo2.Depth> 20 Kバイト出力：FIFO1
Queues are used, in Differentiated Services, for a number of purposes. In essence, they are simply places to store traffic until it is transmitted. However, when several queues are used together in a queuing system, they can also achieve effects beyond that for given traffic streams. They can be used to limit variation in delay or impose a maximum rate (shaping), to permit several streams to share a link in a semi-predictable fashion (load sharing), or to move variation in delay from some streams to other streams.
キューは、多数の目的のために、差別化サービスでは、使用されています。要するに、彼らは単にそれが送信されるまでトラフィックを格納する場所です。しかし、いくつかのキューがキューイングシステムで一緒に使用されている場合、彼らはまた、特定のトラフィックストリームのためにそれを超えた効果を得ることができます。それらは、半予測可能な方法（負荷分散）内のリンクを共有する複数のストリームを可能にするために、または他のストリームへのいくつかのストリームからの遅延のばらつきを移動させるために、遅延の変動を制限または最大速度（シェーピング）を課すために使用することができます。
Traffic shaping is often used to condition traffic, such that packets arriving in a burst will be "smoothed" and deemed conforming by subsequent downstream meters in this or other nodes. In [DSARCH] a shaper is described as a queuing element controlled by a meter which defines its temporal profile. However, this representation of a shaper differs substantially from typical shaper implementations.
トラフィックシェーピングはしばしばバーストで到着するパケットを「平滑化」し、このまたは他のノードに、後続の下流メートル合致とみなされるように、条件トラフィックに使用されます。 【DSARCH]で整形器は、その時間プロファイルを定義計で制御キューイング要素として記載されています。しかしながら、シェーパのこの表現は、典型的な整形器の実装は実質的に異なります。
In the model described here, a shaper is realized by using a non-work-conserving Scheduler. Some implementations may elect to have queues whose sole purpose is shaping, while others may integrate the shaping function with other buffering, discarding, and scheduling associated with access to a resource. Shapers operate by delaying the departure of packets that would be deemed non-conforming by a meter configured to the shaper's maximum service rate profile. The packet is scheduled to depart no sooner than such time that it would become conforming.
ここで説明したモデルでは、シェーパは、非作業保存スケジューラを用いて実現されます。他の人がリソースへのアクセスに関連する他のバッファリング、廃棄、およびスケジューリングとシェーピング機能を統合することができる一方、いくつかの実装は、その唯一の目的の成形されたキューを持つように選ぶことができます。シェイパーは、シェーパーの最大サービスレートプロファイルに構成されたメータで不適合とみなされるパケットの出発を遅らせることによって作動します。パケットは、それが準拠になるような時間よりも、何も早く出発する予定はありません。
Load sharing is the traditional use of queues and was theoretically explored by Floyd & Jacobson [FJ95], although it has been in use in communications systems since the 1970's.
負荷分散は、キューの伝統的な使用であり、それは1970年代以来、通信システムで使用されているが、理論的に、フロイド＆ヤコブソン[FJ95]によって調査しました。
[DSARCH] discusses load sharing as dividing an interface among traffic classes predictably, or applying a minimum rate to each of a set of traffic classes, which might be measured as an absolute lower bound on the rate a traffic stream achieves or a fraction of the rate an interface offers. It is generally implemented as some form of weighted queuing algorithm among a set of FIFO queues i.e., a WFQ scheme. This has interesting side-effects.
【DSARCH】予想トラフィッククラス間のインタフェースを分割するように負荷分散を説明し、またはトラフィッククラスのセットの各々に最小レートを適用し、下限トラフィックストリームが達成率または分数に絶対として測定されるかもしれませんインタフェースの提供を評価。これは、一般的に、すなわちFIFO待ち行列の組のうち、重み付けキューイングアルゴリズムのいくつかの形態、WFQ方式として実装されます。これは興味深い副作用があります。
A key effect sought is to ensure that the mean rate the traffic in a stream experiences is never lower than some threshold when there is at least that much traffic to send. When there is less traffic than this, the queue tends to be starved of traffic, meaning that the queuing system will not delay its traffic by very much. When there is significantly more traffic and the queue starts filling, packets in this class will be delayed significantly more than traffic in other classes that are under-using their available capacity. This form of queuing system therefore tends to move delay and variation in delay from under-used classes of traffic to heavier users, as well as managing the rates of the traffic streams.
求めたキーの効果は平均がストリーム経験にトラフィックを評価することを確実にするためである送信するために、少なくともそのくらいのトラフィックがある場合には、ある閾値よりも低くなることはありません。これより少ないトラフィックがある場合は、キューがキューイング・システムは非常にすることによって、そのトラフィックを遅らせないことを意味し、トラフィックが不足する傾向にあります。そこにかなり多くのトラフィックがあると待ち行列が充填を開始すると、このクラスのパケットは、その利用可能な容量を過小使用している他のクラスのトラフィックよりも大幅に遅れることになります。待ち行列システムのこの形態は、従って、トラフィックストリームの速度を管理するだけでなく、より重いユーザへのトラフィックの下、使用するクラスの遅延で遅延変動を移動する傾向があります。
A side-effect of a WRR or WFQ implementation is that between any two packets in a given traffic class, the scheduler may emit one or more packets from each of the other classes in the queuing system. In cases where average behavior is in view, this is perfectly acceptable. In cases where traffic is very intolerant of jitter and there are a number of competing classes, this may have undesirable consequences.
WRRまたはWFQ実装の副作用は、所定のトラフィック・クラス内の任意の2つのパケット間に、スケジューラは、待ち行列システム内の他のクラスの各々から1つ以上のパケットを放出することができるということです。平均的行動が表示されている場合、これは完全に許容可能です。トラフィックは、ジッタの非常に不寛容であると競合するクラスの数がある場合、これは望ましくない結果をもたらす可能性があります。
Traffic Prioritization is a special case of load sharing, wherein a certain traffic class is deemed so jitter-intolerant that if it has traffic present, that traffic must be sent at the earliest possible time. By extension, several priorities might be defined, such that traffic in each of several classes is given preferential service over any traffic of a lower class. It is the obvious implementation of IP Precedence as described in [RFC 791], of 802.1p traffic classes [802.1D], and other similar technologies.
トラフィックの優先順位付けは、特定のトラフィッククラスがジッタ不耐性、トラフィックが存在している場合、そのトラフィックは、できるだけ早い時点で送信されなければならないようにみなされる前記負荷分散の特別な場合です。延長することにより、いくつかの優先順位は、いくつかのクラスのそれぞれにおけるトラフィックは下のクラスのいずれかのトラフィックより優先的にサービスを与えているように、定義されるかもしれません。 [RFC 791]に記載されているようなの802.1pトラフィッククラス[802.1D]、および他の同様の技術で、IP優先順位の明確な実装です。
Priority is often abused in real networks; people tend to think that traffic which has a high business priority deserves this treatment and talk more about the business imperatives than the actual application requirements. This can have severe consequences; networks have been configured which placed business-critical traffic at a higher priority than routing-protocol traffic, resulting in collapse of the network's management or control systems. However, it may have a legitimate use for services based on an Expedited Forwarding (EF) PHB, where it is absolutely sure, thanks to policing at all possible traffic entry points, that a traffic stream does not abuse its rate and that the application is indeed jitter-intolerant enough to merit this type of handling. Note that, even in cases with well-policed ingress points, there is still the possibility of unexpected traffic loops within an un-policed core part of the network causing such collapse.
優先順位は、多くの場合、実際のネットワークに虐待されています。人々は、高いビジネスの優先順位を持つトラフィックがこの治療に値すると考える傾向があり、実際のアプリケーションの要件よりもビジネスの緊急課題についての詳細を話しています。これは深刻な結果を持つことができます。ネットワークは、ネットワークの管理や制御システムの崩壊をもたらす、ルーティングプロトコルトラフィックよりも高い優先度でビジネスクリティカルなトラフィックを置かれるように構成されています。しかし、それは、アプリケーションがあることを、トラフィックストリームがそのレートを乱用しないことを、すべての可能なトラフィックのエントリポイントでのポリシングのおかげで、それが絶対的に確信して緊急転送（EF）PHBに基づくサービスのための合法的な使用を有していてもよく、確かにジッタを許容しないハンドリング、このタイプのに値するのに十分な。よくポリシング入口点とケースでは、予期しないトラフィックの可能性がそのような崩壊を引き起こすネットワークの未ポリシングコア部内でループが依然として存在することに留意されたいです。
The Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler functional datapath elements described above can be combined into Traffic Conditioning Blocks (TCBs). A TCB is an abstraction of a set of functional datapath elements that may be used to facilitate the definition of specific traffic conditioning functionality (e.g., it might be likened to a template which can be replicated multiple times for different traffic streams or different customers). It has no likely physical representation in the implementation of the data path: it is invented purely as an abstraction for use by management tools.
分類器は、上記メーター、アクション、アルゴリズムドロッパー、キューおよびスケジューラ機能データパス要素は、トラフィックコンディショニングブロック（のTCB）に結合することができます。 TCBは、特定のトラフィック調整機能の定義を容易にするために使用することができる機能データパス要素の集合の抽象化である（例えば、それは、異なるトラフィックストリームまたは異なる顧客のために複数回複製することができるテンプレートに例えることがあります）。これは、データパスの実装には可能性の高い物理的な表現を持っていない：それは純粋な管理ツールで使用するための抽象化として考案されました。
This model describes the configuration and management of a Diffserv interface in terms of a TCB that contains, by definition, zero or more Classifier, Meter, Action, Algorithmic Dropper, Queue and Scheduler elements. These elements are arranged arbitrarily according to the policy being expressed, but always in the order here. Traffic may be classified; classified traffic may be metered; each stream of traffic identified by a combination of classifiers and meters may have some set of actions performed on it, followed by drop algorithms; packets of the traffic stream may ultimately be stored into a queue and then be scheduled out to the next TCB or physical interface. It is permissible to omit elements or include null elements of any type, or to concatenate multiple functional datapath elements of the same type.
このモデルは、定義により、含まTCBの点でのDiffservインタフェースの構成および管理について説明し、ゼロまたはそれ以上の分類、メータ、アクション、アルゴリズムドロッパー、キューおよびスケジューラ素子。これらの要素は常に、ここために、発現されたポリシーに応じて任意に配置されています。トラフィックは分類することができます。分類されたトラフィックを計量することができます。クラシファイアとメーターとの組み合わせによって識別されたトラフィックの各ストリームは、ドロップアルゴリズム続いてその上に実行される動作のいくつかのセットを有していてもよいです。トラフィック・ストリームのパケットは、最終的にキューに格納されてもよいし、次いで、次のTCBまたは物理インタフェースにアウトスケジュールされます。要素を省略するか、任意のタイプのヌル要素を含む、または同じタイプの複数の機能データパス要素を連結するために許容されます。
When the Diffserv treatment for a given packet needs to have such building blocks repeated, this is performed by cascading multiple TCBs: an output of one TCB may drive the input of a succeeding one. For example, consider the case where traffic of a set of classes is shaped to a set of rates, but the total output rate of the group of classes must also be limited to a rate. One might imagine a set of network news feeds, each with a certain maximum rate, and a policy that their aggregate may not exceed some figure. This may be simply accomplished by cascading two TCBs. The first classifies the traffic into its separate feeds and queues each feed separately. The feeds (or a subset of them) are now fed into a second TCB, which places all input (these news feeds) into a single queue with a certain maximum rate. In implementation, one could imagine this as the several literal queues, a CBQ or WFQ system with an appropriate (and complex) weighting scheme, or a number of other approaches. But they would have the same externally measurable effect on the traffic as if they had been literally implemented with separate TCBs.
所与のパケットのDiffservの処理が繰り返されるようなビルディングブロックを有する必要がある場合、これは、複数のTCBをカスケード接続することによって実行される一のTCBの出力は、後続の一方の入力を駆動することができます。例えば、一連のクラスのトラフィックがレートのセットに整形されていますが、クラスのグループの総出力速度も割合に制限されなければならない場合を考えます。一つは、ネットワークのニュースフィードのセット、特定の最大速度でそれぞれ、およびその集合体は、いくつかの数値を超えてはならない政策を想像するかもしれません。これは単純に2つのTCBをカスケード接続することによって達成することができます。最初は、その個別のフィードにトラフィックを分類し、個別に各フィードをキューに入れます。フィード（またはそれらのサブセット）が、特定の最大速度で単一のキューにすべての入力（これらニュースフィード）を置く第二TCB、に供給されます。インプリメンテーションでは、一つはいくつかのリテラルキュー、適切な（および錯体）重み付け方式、または他の多くのアプローチとCBQまたはWFQシステムとしてこれを想像できます。彼らは文字通り、別のTCBで実装されたかのようにしかし、彼らはトラフィックに同じ外部から測定可能な効果を持っているでしょう。
A generalized TCB might consist of the following stages:
一般TCBは以下のステージから構成されることがあります。
- Classification stage
- 分類段階
- Metering stage
- 計量段階
- Action stage (involving Markers, Absolute Droppers, Counters, and Multiplexors)
- アクション段階（マーカー、絶対ドロッパー、カウンタ、およびマルチプレクサを含みます）
- Queuing stage (involving Algorithmic Droppers, Queues, and Schedulers)
- キューイング段階（アルゴリズムのドロッパー、キュー、およびスケジューラを含みます）
where each stage may consist of a set of parallel datapaths consisting of pipelined elements.
ここで、各ステージは、パイプライン化元素からなるパラレルデータパスの集合から構成されてもよいです。
A Classifier or a Meter is typically a 1:N element, an Action, Algorithmic Dropper, or Queue is typically a 1:1 element and a Scheduler is a N:1 element. A complete TCB should, however, result in a 1:1 or 1:N abstract element. Note that the fan-in or fan-out of an element is not an important defining characteristic of this taxonomy.
分類器又はメータは、典型的には、1：N要素、アクション、アルゴリズムドロッパー、またはキューは、典型的には1：1要素とスケジューラがNである：1つの要素。 1又は1：N抽象要素完全TCBは、しかし、1をもたらすはずです。要素のファンインまたはファンアウトは、この分類の重要な決定的な特徴ではないことに注意してください。
Some particular rules are applied to the ordering of elements within a Queuing stage within a TCB: elements of the same type may appear more than once, either in parallel or in series. Typically, a queuing stage will have relatively many elements in parallel and few in series. Iteration and recursion are not supported constructs (the elements are arranged in an acyclic graph). The following inter-connections of elements are allowed:
いくつかの特定の規則は、TCB内にキューイングステージ内の要素の順序付けに適用される：同じタイプの要素は、並列または直列のいずれかで、複数回表示されることがあります。典型的には、キューイングステージは、直列、並列及び少数で比較的多くの要素を有することになります。反復と再帰は（要素が非環式グラフで配置されている）コンストラクトをサポートしていません。要素の以下の相互接続が許可されています。
- The input of a Queue may be the input of the queuing block, or it may be connected to the output of an Algorithmic Dropper, or to an output of a Scheduler.
- キューの入力は、待ち行列ブロックの入力であってもよいし、アルゴリズムドロッパーの出力に、またはスケジューラの出力に接続されてもよいです。
- Each input of a Scheduler may be connected to the output of a Queue, to the output of an Algorithmic Dropper, or to the output of another Scheduler.
- スケジューラの各入力は、キューの出力に、アルゴリズムスポイトの出力に、または別のスケジューラの出力に接続されてもよいです。
- The input of an Algorithmic Dropper may be the first element of the queuing stage, the output of another Algorithmic Dropper, or it may be connected to the output of a Queue (to indicate head-dropping).
- アルゴリズムドロッパーの入力キューイングステージの最初の要素、他のアルゴリズムスポイトの出力であってもよいし、（ヘッド落下を示すために）キューの出力に接続されてもよいです。
- The output of the queuing block may be the output of a Queue, an Algorithmic Dropper, or a Scheduler.
- キューイングブロックの出力キュー、アルゴリズムドロッパー、またはスケジューラの出力であってもよいです。
Note, in particular, that Schedulers may operate in series such so that a packet at the head of a Queue feeding the concatenated Schedulers is serviced only after all of the scheduling criteria are met. For example, a Queue which carries EF traffic streams may be served first by a non-work-conserving Scheduler to shape the stream to a maximum rate, then by a work-conserving Scheduler to mix EF traffic streams with other traffic streams. Alternatively, there might be a Queue and/or a dropper between the two Schedulers.
連結されたスケジューラを供給待ち行列の先頭のパケットがスケジューリング基準の全てが満たされた後にのみサービスされるように、スケジューラは、直列で動作してもよいことは、特に注意してください。例えば、EFトラフィックストリームを運ぶキュースケジューラがEFトラフィックを混合すること、次いで作業節約スケジューラによって、最大速度にストリームを整形する非作業保存することにより、第1配信することができる他のトラフィックストリームとストリーム。あるいは、キュー及び/又は二スケジューラ間ドロッパーがあるかもしれません。
Note also that some non-sensical scenarios (e.g., a Queue preceding an Algorithmic Dropper, directly feeding into another Queue), are prohibited.
注また、いくつかの無意味なシナリオ（直接別のキューに供給アルゴリズムドロッパーを、先行例えば、キュー）が、禁止されていること。
A SLS is presumed to have been negotiated between the customer and the provider which specifies the handling of the customer's traffic, as defined by a TCS) by the provider's network. The agreement might be of the following form:
SLSは、TCSで定義されているプロバイダのネットワークによって）、顧客と顧客のトラフィックの取り扱いを指定するプロバイダとの間で交渉されていると推定されます。契約には、次の形式であるかもしれません。
DSCP PHB Profile Treatment
---- --- ------- ----------------------
001001 EF Profile4 Discard non-conforming.
001100 AF11 Profile5 Shape to profile, tail-drop when full.
001101 AF21 Profile3 Re-mark non-conforming to DSCP 001000,
tail-drop when full.
other BE none Apply RED-like dropping.
This SLS specifies that the customer may submit packets marked for DSCP 001001 which will get EF treatment so long as they remain conforming to Profile4, which will be discarded if they exceed this profile. The discarded packets are counted in this example, perhaps for use by the provider's sales department in convincing the customer to buy a larger SLS. Packets marked for DSCP 001100 will be shaped to Profile5 before forwarding. Packets marked for DSCP 001101 will be metered to Profile3 with non-conforming packets "downgraded" by being re-marked with a DSCP of 001000. It is implicit in this agreement that conforming packets are given the PHB originally indicated by the packets' DSCP field.
このSLSは、顧客は、彼らがこのプロファイルを超えた場合に破棄されますProfile4、に準拠したまま限り、EF治療を取得しますDSCP 001001用にマークされたパケットを提出することができることを指定します。廃棄されたパケットは、より大きなSLSを購入する顧客を納得させるには、プロバイダの営業部門で、おそらく使用するため、この例ではカウントされます。 DSCP 001100用にマークされたパケットは、転送する前にProfile5に整形されます。 DSCP 001101のためにマークされたパケットは、「ダウングレード」001000.のDSCPで再マークされることにより、それが準拠するパケットがパケットのDSCPフィールドによってもともとPHBを与え示され、本契約に内在する非準拠のパケットとプロファイル3に計量されます。
Figures 6 and 7 illustrates a TCB that might be used to handle this SLS at an ingress interface at the customer/provider boundary.
図6および図7は、これが顧客/プロバイダ境界における入力インターフェイスにSLS処理するために使用されるかもしれないTCBを示します。
The Classification stage of this example consists of a single BA classifier. The BA classifier is used to separate traffic based on the Diffserv service level requested by the customer (as indicated by the DSCP in each submitted packet's IP header). We illustrate three DSCP filter values: A, B, and C. The 'X' in the BA classifier is a wildcard filter that matches every packet not otherwise matched.
この例の分類段階は、単一のBA分類器から構成されています。 BAクラシファイアは、顧客から要求されたDiffservのサービスレベル（各送信パケットのIPヘッダ内のDSCPによって示されるように）に基づいてトラフィックを分離するために使用されます。我々は、三のDSCPフィルタ値を示す：BAクラシファイアにおけるA、B、およびCザ「X」は、そうでない場合は一致しないすべてのパケットに一致するワイルドカードフィルタです。
The path for DSCP 001100 proceeds directly to Dropper1 whilst the paths for DSCP 001001 and 001101 include a metering stage. All other traffic is passed directly on to Dropper3. There is a separate meter for each set of packets corresponding to classifier outputs A and C. Each meter uses a specific profile, as specified in the TCS, for the corresponding Diffserv service level. The meters in this example each indicate one of two conformance levels: conforming or non-conforming.
DSCP 001001と001101のパス一方DSCPのパス直接Dropper1へ001100進み、計量ステージを含みます。他のすべてのトラフィックはDropper3の上に直接渡されます。対応するDiffservのサービスレベルのため、TCSに指定された各メータは、特定のプロファイルを使用して分類器出力A及びCに対応するパケットの各セットに対して個別の計器があります。この例の計器はそれぞれ2つの適合レベルのいずれかを示す：適合又は不適合。
Following the Metering stage is an Action stage in some of the branches. Packets submitted for DSCP 001001 (Classifier output A) that are deemed non-conforming by Meter1 are counted and discarded while packets that are conforming are passed on to Queue1. Packets submitted for DSCP 001101 (Classifier output C) that are deemed non-conforming by Meter2 are re-marked and then both conforming and non-conforming packets are multiplexed together before being passed on to Dropper2/Queue3.
測光段階に続いて、枝の一部でアクションステージです。適合されているパケットがQUEUE1に渡されながらMeter1により不適合とみなされるDSCP 001001（クラシファイア出力A）のために提出パケットがカウントされ、廃棄されます。 Meter2により不適合とみなされるDSCP 001101（クラシファイア出力C）のために提出されたパケットを再マークされ、両方の準拠および非準拠のパケットはDropper2 / Queue3に渡される前に一緒に多重化されます。
The Algorithmic Dropping, Queuing and Scheduling stages are realized as follows, illustrated in figure 7. Note that the figure does not show any of the implicit control linkages between elements that allow e.g., an Algorithmic Dropper to sense the current state of a succeeding Queue.
次のようにアルゴリズムの削除、キューイングおよびスケジューリング段が実現され、図は、後続キューの現在の状態を感知するために、例えば可能要素間の暗黙的な制御結合、アルゴリズムスポイトのいずれかを示さないことが図7注意に示します。
+-----+
| A|---------------------------> to Queue1
+->| |
| | B|--+ +-----+ +-----+
| +-----+ | | | | |
| Meter1 +->| |--->| |
| | | | |
| +-----+ +-----+
| Counter1 Absolute
submitted +-----+ | Dropper1
traffic | A|-----+
--------->| B|--------------------------------------> to AlgDropper1
| C|-----+
| X|--+ |
+-----+ | | +-----+ +-----+
Classifier1| | | A|--------------->|A |
(BA) | +->| | | |--> to AlgDrop2
| | B|--+ +-----+ +->|B |
| +-----+ | | | | +-----+
| Meter2 +->| |-+ Mux1
| | |
| +-----+
| Marker1
+-----------------------------------> to AlgDropper3
Figure 6: An Example Traffic Conditioning Block (Part 1)
図6：例トラフィックコンディショニングブロック（その1）
Conforming DSCP 001001 packets from Meter1 are passed directly to Queue1: there is no way, with configuration of the following Scheduler to match the metering, for these packets to overflow the depth of Queue1, so there is no requirement for dropping at this point. Packets marked for DSCP 001100 must be passed through a tail-dropper, AlgDropper1, which serves to limit the depth of the following queue, Queue2: packets that arrive to a full queue will be discarded. This is likely to be an error case: the customer is obviously not sticking to its agreed profile. Similarly, all packets from the original DSCP 001101 stream (some may have been re-marked by this stage) are passed to AlgDropper2 and Queue3. Packets marked for all other DSCPs are passed to AlgDropper3 which is a RED-like Algorithmic Dropper: based on feedback of the current depth of Queue4, this dropper is supposed to discard enough packets from its input stream to keep the queue depth under control.
Meter1から適合DSCP 001001パケットがQUEUE1に直接渡される。これらのパケットはQUEUE1の深さをオーバーフローするための方法は、計量に合わせて、次のスケジューラの構成では、存在しないので、この時点でドロップする必要はありません。 DSCP 001100のマークが付けられたパケットは、次のキューの深さを制限するのに役立つテールスポイト、AlgDropper1を通過しなければならない、キュー2は：フルキューに到着したパケットが破棄されます。これは、エラーケースである可能性が高い：顧客が明らかに合意されたプロファイルにこだわっていません。同様に、元のDSCP 001101ストリーム（いくつかは、この段階で再度マークされていてもよい）からのすべてのパケットがAlgDropper2とQueue3に渡されます。他のすべてのDSCPのためにマークされたパケットがREDのようなアルゴリズムのドロッパーですAlgDropper3に渡されます。Queue4の現在の深さのフィードバックに基づいて、このドロッパーは、制御の下でキューの深さを保つために、その入力ストリームから十分なパケットを廃棄することになっています。
These four Queue elements are then serviced by a Scheduler element Scheduler1: this must be configured to give each of its inputs an appropriate priority and/or bandwidth share. Inputs A and C are given guarantees of bandwidth, as appropriate for the contracted profiles. Input B is given a limit on the bandwidth it can use (i.e., a non-work-conserving discipline) in order to achieve the desired shaping of this stream. Input D is given no limits or guarantees but a lower priority than the other queues, appropriate for its best-effort status. Traffic then exits the Scheduler in a single orderly stream.
これら四つのキューエレメントは、スケジューラ素子Scheduler1によってサービスされている：これは、適切な優先度および/または帯域幅を共有し、その入力の各々を与えるように構成されなければなりません。入力AおよびCは、収縮プロファイルに応じて、帯域幅の保証を与えられています。入力Bは、このストリームの所望の成形を達成するためにそれが使用できる帯域幅（すなわち、非作業保存規律）に制限を与えています。入力Dはベストエフォート型の状態に適した他のキューよりも制限や保証が、低い優先順位を、与えられていません。トラフィックは、単一の整然としたストリームでスケジューラを終了します。
The interconnections of the TCB elements illustrated in Figures 6 and 7 can be represented textually as follows:
次のように図6及び図7に示すTCB要素の相互接続は、テキストで表すことができます。
TCB1:
TCB1：
Classifier1: FilterA: Meter1 FilterB: Dropper1 FilterC: Meter2 Default: Dropper3
クラシファイア1：ます。FilterA：メーター1 FilterB：Dropper1 FilterC：Meter2デフォルト：ドロッパー3
from Meter1 +-----+
------------------------------->| |----+
| | |
+-----+ |
Queue1 |
| +-----+
from Classifier1 +-----+ +-----+ +->|A |
---------------->| |------->| |------>|B |------->
| | | | +--->|C | exiting
+-----+ +-----+ | +->|D | traffic
AlgDropper1 Queue2 | | +-----+
| | Scheduler1
from Mux1 +-----+ +-----+ | |
---------------->| |------->| |--+ |
| | | | |
+-----+ +-----+ |
AlgDropper2 Queue3 |
|
from Classifier1 +-----+ +-----+ |
---------------->| |------->| |----+
| | | |
+-----+ +-----+
AlgDropper3 Queue4
Figure 7: An Example Traffic Conditioning Block (Part 2)
図7：例トラフィックコンディショニングブロック（その2）
Meter1: Type: AverageRate Profile: Profile4 ConformingOutput: Queue1 NonConformingOutput: Counter1
Meter1：タイプ：AverageRateプロフィール：Profile4 ConformingOutput：QUEUE1 NonConformingOutput：カウンタ
Counter1: Output: AbsoluteDropper1
カウンタ：出力：AbsoluteDropper1
Meter2: Type: AverageRate Profile: Profile3 ConformingOutput: Mux1.InputA NonConformingOutput: Marker1
Meter2：タイプ：AverageRateプロフィール：出力を準拠プロフィール：Mux1.InputAは出力を不適合：MARKER1
Marker1: Type: DSCPMarker Mark: 001000 Output: Mux1.InputB
MARKER1：タイプ：DSCPMarkerマーク：001000出力：Mux1.InputB
Mux1: Output: Dropper2
MUX1：出力：Dropper2
AlgDropper1: Type: AlgorithmicDropper Discipline: Drop-on-threshold Trigger: Queue2.Depth > 10kbyte Output: Queue2
AlgDropper1：タイプ：AlgorithmicDropper調教：ドロップ・オン・スレッシュホールドトリガー：Queue2.Depth> 10kbyte出力：キュー2
AlgDropper2: Type: AlgorithmicDropper Discipline: Drop-on-threshold Trigger: Queue3.Depth > 20kbyte Output: Queue3
AlgDropper2：タイプ：AlgorithmicDropper調教：ドロップ・オン・スレッシュホールドトリガー：Queue3.Depth> 20kbyte出力：Queue3
AlgDropper3: Type: AlgorithmicDropper Discipline: RED93 Trigger: Internal Output: Queue3 MinThresh: Queue3.Depth > 20 kbyte MaxThresh: Queue3.Depth > 40 kbyte <other RED parms too>
AlgDropper3：タイプ：AlgorithmicDropper調教：RED93トリガー：内部出力：Queue3 MinThresh：Queue3.Depth> 20キロバイトMaxThresh：あまりにQueue3.Depth> 40キロバイトの<その他RED PARMS>
Queue1: Type: FIFO Output: Scheduler1.InputA
キュー1：タイプ：FIFO出力：Scheduler1.Input
Queue2: Type: FIFO Output: Scheduler1.InputB
キュー2：タイプ：FIFO出力：Scheduler1.InputB
Queue3: Type: FIFO Output: Scheduler1.InputC
Queue3：タイプ：FIFO出力：Scheduler1.InputC
Queue4: Type: FIFO Output: Scheduler1.InputD
キュー4：タイプ：FIFO出力：Scheduler1.Input
Scheduler1: Type: Scheduler4Input InputA: MaxRateProfile: none MinRateProfile: Profile4 Priority: 20 InputB: MaxRateProfile: Profile5 MinRateProfile: none Priority: 40 InputC: MaxRateProfile: none MinRateProfile: Profile3 Priority: 20 InputD: MaxRateProfile: none MinRateProfile: none Priority: 10
Scheduler1：タイプ：Scheduler4Input InputA：MaxRateProfile：なしMinRateProfile：Profile4優先度：20 INPUTB：MaxRateProfile：Profile5 MinRateProfile：なし優先：40 InputC：MaxRateProfile：なしMinRateProfile：プロファイル3優先度：20 InputD：MaxRateProfile：なしMinRateProfile：なし優先順位：10
The TCB described above can be installed on an ingress interface to implement a provider/customer TCS if the interface is dedicated to the customer. However, if a single interface is shared between multiple customers, then the TCB above will not suffice, since it does not differentiate among traffic from different customers. Its classification stage uses only BA classifiers.
上記TCBはインターフェースが顧客に特化されている場合、プロバイダ/顧客TCSを実装するために入力インターフェイス上にインストールすることができます。単一のインタフェースが複数の顧客間で共有されている場合、それは別の顧客からのトラフィックを区別しませんので、しかし、その後、上記TCBは、十分ではありません。その分類段階はBAの分類器を使用しています。
The configuration is readily modified to support the case of multiple customers per interface, as follows. First, a TCB is defined for each customer to reflect the TCS with that customer: TCB1, defined above is the TCB for customer 1. Similar elements are created for
以下のような構成は、容易に、インターフェイスごとに複数の顧客のケースをサポートするように変更されます。まず、TCBは、その顧客とTCSを反映するために、各顧客のために定義される：上記に定義TCB1は、顧客1のTCBであり、同様の要素をするために作成されます
TCB2 and for TCB3 which reflect the agreements with customers 2 and 3 respectively. These 3 TCBs may or may not contain similar elements and parameters.
TCB2と、それぞれの顧客2と3との合意を反映TCB3ため。これらの3つのTCBは又は類似の要素およびパラメータを含んでも含まなくてもよいです。
Finally, a classifier is added to the front end to separate the traffic from the three different customers. This forms a new TCB, TCB4, which is illustrated in Figure 8.
最後に、分類器は、3人の異なる顧客からのトラフィックを分離するために、フロントエンドに追加されます。これは、図8に示されている新たなTCB、TCB4を形成します。
A representation of this multi-customer TCB might be:
このマルチ顧客TCBの表現は次のようになります。
TCB4:
TCB4：
Classifier4: Filter1: to TCB1 Filter2: to TCB2 Filter3: to TCB3 No Match: AbsoluteDropper4
Classifier4：FILTER1：TCB1 FILTER2へ：TCB2 Filter3へ：TCB3ないマッチへ：AbsoluteDropper4
AbsoluteDropper4: Type: AbsoluteDropper
AbsoluteDropper4：タイプ：AbsoluteDropper
TCB1: (as defined above)
TCB1：（上記で定義した通り）
TCB2: (similar to TCB1, perhaps with different elements or numeric parameters)
TCB2：（おそらく異なる要素または数値パラメータと、TCB1と同様）
TCB3: (similar to TCB1, perhaps with different elements or numeric parameters)
TCB3：（おそらく異なる要素または数値パラメータと、TCB1と同様）
and the filters, based on each customer's source MAC address, could be defined as follows:
次のようにフィルタは、各顧客の元MACアドレスに基づいて、定義することができます：
Filter1:
フィルタ1：
submitted +-----+
traffic | A|--------> TCB1
--------->| B|--------> TCB2
| C|--------> TCB3
| X|------+ +-----+
+-----+ +-->| |
Classifier4 +-----+
AbsoluteDrop4
Figure 8: An Example of a Multi-Customer TCB
図8：マルチ顧客TCBの例
Type: MacAddress SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1) SrcMask: FF-FF-FF-FF-FF-FF DestValue: 00-00-00-00-00-00 DestMask: 00-00-00-00-00-00
タイプ：MacAddressのSrcValue：SRCMASK 01-02-03-04-05-06（顧客1の送信元MACアドレス）：FF-FF-FF-FF-FF-FF DestValue：00-00-00-00-00-00 DESTMASK：00-00-00-00-00-00
Filter2: (similar to Filter1 but with customer 2's source MAC address as SrcValue)
FILTER2：（SrcValueとしてフィルタ1に似ていますが、顧客2のソースとMACアドレス）
Filter3: (similar to Filter1 but with customer 3's source MAC address as SrcValue)
Filter3：（SrcValueとしてフィルタ1に似ていますが、顧客3のソースとMACアドレス）
In this example, Classifier4 separates traffic submitted from different customers based on the source MAC address in submitted packets. Those packets with recognized source MAC addresses are passed to the TCB implementing the TCS with the corresponding customer. Those packets with unrecognized source MAC addresses are passed to a dropper.
この例では、Classifier4は、提出されたパケットの送信元MACアドレスに基づいて、異なる顧客から提出されたトラフィックを分離します。認識された送信元MACアドレスを持つこれらのパケットは、対応する顧客とTCSを実装TCBに渡されます。認識されていない送信元MACアドレスを持つこれらのパケットは、ドロッパーに渡されます。
TCB4 has a Classifier stage and an Action element stage performing dropping of all unmatched traffic.
TCB4は、段階分類器と、すべての比類のないトラフィックのドロップを実行するアクション要素の段階があります。
The TCB illustrated above describes a configuration that might be suitable for enforcing a SLS at a router's ingress. It assumes that the customer marks its own traffic for the appropriate service level. It then limits the rate of aggregate traffic submitted at each service level, thereby protecting the resources of the Diffserv network. It does not provide any isolation between the customer's individual microflows.
上に示したTCBは、ルータの入口でSLSを実施するのに適したかもしれない構成について説明します。これは、顧客が適切なサービスレベルのために、独自のトラフィックをマークすることを前提としています。これは、それによりDiffservのネットワークのリソースを保護し、各サービスレベルで送信集約トラフィックのレートを制限します。これは、顧客の個々のマイクロフロー間の任意のアイソレーションを提供していません。
A more complex example might be a TCB configuration that offers additional functionality to the customer. It recognizes individual customer microflows and marks each one independently. It also isolates the customer's individual microflows from each other in order to prevent a single microflow from seizing an unfair share of the resources available to the customer at a certain service level. This is illustrated in Figure 9.
より複雑な例では、顧客への追加機能を提供していますTCB構成であるかもしれません。これは、個々の顧客マイクロフローを認識し、独立してそれぞれをマークします。また、特定のサービスレベルで顧客に利用可能なリソースの不公平なシェアを押収から、単一のマイクロフローを防止するために、互いから顧客の個々のマイクロフローを分離します。これは図9に示されています。
Suppose that the customer has an SLS which specifies 2 service levels, to be identified to the provider by DSCP A and DSCP B. Traffic is first directed to a MF classifier which classifies traffic based on miscellaneous classification criteria, to a granularity sufficient to identify individual customer microflows. Each microflow can then be marked for a specific DSCP The metering elements limit the contribution of each of the customer's microflows to the service level for which it was marked. Packets exceeding the allowable limit for the microflow are dropped.
最初の個人を識別するのに十分な粒度に、その他の分類基準に基づいてトラフィックを分類MF分類器に向けられているDSCP AとDSCP B.トラフィックによってプロバイダに識別することが、顧客が2つのサービスレベルを指定SLSを有すると仮定する顧客マイクロフロー。各マイクロフローは、計量要素は、それがマークされているサービスレベルに対する顧客のマイクロフローのそれぞれの寄与を制限し、特定のDSCPのためにマークすることができます。マイクロフローの許容限度を超えたパケットは廃棄されています。
+-----+ +-----+
Classifier1 | | | |---------------+
(MF) +->| |-->| | +-----+ |
+-----+ | | | | |---->| | |
| A|------ +-----+ +-----+ +-----+ |
-->| B|-----+ Marker1 Meter1 Absolute |
| C|---+ | Dropper1 | +-----+
| X|-+ | | +-----+ +-----+ +-->|A |
+-----+ | | | | | | |------------------>|B |--->
| | +->| |-->| | +-----+ +-->|C | to TCB2
| | | | | |---->| | | +-----+
| | +-----+ +-----+ +-----+ | Mux1
| | Marker2 Meter2 Absolute |
| | Dropper2 |
| | +-----+ +-----+ |
| | | | | |---------------+
| |--->| |-->| | +-----+
| | | | |---->| |
| +-----+ +-----+ +-----+
| Marker3 Meter3 Absolute
| Dropper3
V etc.
Figure 9: An Example of a Marking and Traffic Isolation TCB
図9：マーキングとトラフィック分離TCBの例
This TCB could be formally specified as follows:
次のようにこのTCBは、正式に指定することができます。
TCB1: Classifier1: (MF) FilterA: Marker1 FilterB: Marker2 FilterC: Marker3 etc.
TCB1：分類1：（MF）フィルター：MARKER1 FilterB：MARKER2 FilterC：Marker3等
Marker1: Output: Meter1
MARKER1：出力：Meter1
Marker2: Output: Meter2
MARKER2：出力：Meter2
Marker3: Output: Meter3
Marker3：出力：Meter3
Meter1: ConformingOutput: Mux1.InputA NonConformingOutput: AbsoluteDropper1
Meter1：準拠出力：Mux1.Input不適合出力：AbsoluteDropper1
Meter2: ConformingOutput: Mux1.InputB NonConformingOutput: AbsoluteDropper2
Meter2：準拠出力：Mux1.Input不適合出力：AbsoluteDropper2
Meter3: ConformingOutput: Mux1.InputC NonConformingOutput: AbsoluteDropper3
Meter3：ConformingOutput：Mux1.InputC NonConformingOutput：AbsoluteDropper3
etc.
等
Mux1: Output: to TCB2
MUX1：出力：TCB2へ
Note that the detailed traffic element declarations are not shown here. Traffic is either dropped by TCB1 or emerges marked for one of two DSCPs. This traffic is then passed to TCB2 which is illustrated in Figure 10.
詳細なトラフィック要素宣言は、ここで示されていないことに注意してください。トラフィックは、どちらかTCB1によってドロップされたか、2つのDSCPの1のためにマーク出てきます。このトラフィックは、その後、図10に示されているTCB2に渡されます。
TCB2 could then be specified as follows:
次のようにTCB2は、指定することができます。
Classifier2: (BA) FilterA: Meter5 FilterB: Meter6
クラシファイア2：（BA）フィルタ：計5 FilterB：Meter6
+-----+
| |---------------> to Queue1
+->| | +-----+
+-----+ | | |---->| |
| A|---+ +-----+ +-----+
->| | Meter5 AbsoluteDropper4
| B|---+ +-----+
+-----+ | | |---------------> to Queue2
Classifier2 +->| | +-----+
(BA) | |---->| |
+-----+ +-----+
Meter6 AbsoluteDropper5
Figure 10: Additional Example: TCB2
図10：追加例：TCB2
Meter5: ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper4
Meter5：ConformingOutput：QUEUE1 NonConformingOutput：AbsoluteDropper4
Meter6: ConformingOutput: Queue2 NonConformingOutput: AbsoluteDropper5
Meter6：ConformingOutput：キュー2 NonConformingOutput：AbsoluteDropper5
Nothing in this model prevents more complex scenarios in which one microflow TCB precedes another (e.g., for TCBs implementing separate TCSs for the source and for a set of destinations).
このモデルでは何も1マイクロTCBは別の（例えば、ソースに対して別々のTCSsを実現するためのTCBと宛先のセットのための）先行するより複雑なシナリオを妨げるものはありません。
Security vulnerabilities of Diffserv network operation are discussed in [DSARCH]. This document describes an abstract functional model of Diffserv router elements. Certain denial-of-service attacks such as those resulting from resource starvation may be mitigated by appropriate configuration of these router elements; for example, by rate limiting certain traffic streams or by authenticating traffic marked for higher quality-of-service.
Diffservのネットワーク操作のセキュリティの脆弱性は、[DSARCH]で議論されています。この文書では、Diffservのルータ要素の抽象的機能モデルについて説明します。そのようなリソース不足から生じるもののようなある種のDoS攻撃は、これらのルータ要素の適切な構成によって、緩和することができます。例えば、特定のトラフィックストリームレート制限によって、またはトラフィックを認証することによって、より高品質のサービス用にマーク。
There may be theft-of-service scenarios where a malicious host can exploit a loose token bucket policer to obtain slightly better QoS than that committed in the TCS.
悪質なホストがTCSにコミットしているよりもわずかに良いQoSを得るために、緩いトークンバケットポリサーを活用できるサービスの窃盗のシナリオがあるかもしれません。
Concepts, terminology, and text have been borrowed liberally from [POLTERM], as well as from other IETF work on MIBs and policy-management. We wish to thank the authors of some of those documents: Fred Baker, Michael Fine, Keith McCloghrie, John Seligson, Kwok Chan, Scott Hahn, and Andrea Westerinen for their contributions.
概念、用語、およびテキストは、[POLTERM]から、だけでなく、MIBとポリシー管理上の他のIETF仕事から寛大に借りてきました。フレッド・ベイカー、マイケル・ファイン、キースMcCloghrie、ジョンSeligson、コック・チャン、スコット・ハーン、そしてアンドレアWesterinen彼らの貢献のために：私たちは、これらのドキュメントのいくつかの作者に感謝したいです。
This document has benefited from the comments and suggestions of several participants of the Diffserv working group, particularly Shahram Davari, John Strassner, and Walter Weiss. This document could never have reached this level of rough consensus without the relentless pressure of the co-chairs Brian Carpenter and Kathie Nichols, for which the authors are grateful.
この文書では、Diffservのワーキンググループの複数の参加者、特にShahram Davari、ジョンStrassner、とウォルターワイスのコメントや提案の恩恵を受けています。この文書では、著者は感謝している共同議長ブライアン・カーペンターとキャシーニコルズ、の執拗な圧力なしでラフコンセンサスのこのレベルに達したことがない可能性があります。
[AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[AF-PHB] Heinanen、J.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[DSARCH] Carlson, M., Weiss, W., Blake, S., Wang, Z., Black, D. and E. Davies, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[DSARCH]カールソン、M.、ワイス、W.、ブレイク、S.、王、Z.、ブラック、D.およびE.デイヴィス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[DSFIELD] 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.
[DSFIELD]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[DSMIB] Baker, F., Smith, A., and K. Chan, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
[DSMIB]ベイカー、F.、スミス、A.、およびK.チャン、 "差別化サービスアーキテクチャのための管理情報ベース"、RFC 3289、2002年5月。
[E2E] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer, M., Nichols, K., Braden, R., Davie, B., Wroclawski, J. and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[E2E] Bernet、Y.、Yavatkar、R.、フォード、P.、ベイカー、F.、チャン、L.、シュペーア、M.、ニコルズ、K.、ブレーデン、R.、デイビー、B.、Wroclawski、 J.およびE. Felstaine、 "Diffservのネットワーク経由の統合サービス操作のための枠組み"、RFC 2998、2000年11月。
[EF-PHB] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[EF-PHB]デイビー、B.、Charny、A.、ベネット、JCR、ベンソン、K.、ルBoudec、JY、コートニー、W.、Davari、S.、Firoiu、V.およびD. Stiliadis、「アン緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[FJ95] Floyd, S. and V. Jacobson, "Link Sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3 No. 4, August 1995l.
[FJ95]フロイド、S.とV. Jacobson氏、「パケットネットワークのリンクを共有し、リソース管理モデル」、ネットワーキング、巻上のIEEE / ACM取引。 3番号4 8月1995リットル。
[INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[イントサーブ]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[NEWTERMS] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April, 2002
[NEWTERMS]グロスマン、D.、 "Diffservのための新しい用語と明確化"、RFC 3260、2002年4月
[PDBDEF] K. Nichols and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for Their Specification", RFC 3086, April 2001.
[PDBDEF] K.ニコルズとB.大工、「彼らの仕様のための差別化サービスドメイン単位の行動とルールの定義」、RFC 3086、2001年4月。
[POLTERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Policy Terminology", RFC 3198, November 2001.
【POLTERM] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、J.、およびS. Waldbusser、 "ポリシーの用語"、RFC 3198、2001年11月。
[QOSDEVMOD] Strassner, J., Westerinen, A. and B. Moore, "Information Model for Describing Network Device QoS Mechanisms", Work in Progress.
進行中で働いて "ネットワークデバイスのQoSメカニズムを記述するための情報モデル" [QOSDEVMOD] Strassner、J.、Westerinen、A.およびB.ムーア、。
[QUEUEMGMT] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, C., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
【QUEUEMGMT]ブレーデン、R.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、C.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.とL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[SRTCM] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[SRTCM] Heinanen、J.とR.ゲラン、 "シングルレート3カラーマーカー"、RFC 2697、1999年9月。
[TRTCM] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, September 1999.
[TRTCM] Heinanen、J.とR.ゲラン、 "二つのレート3カラーマーカー"、RFC 2698、1999年9月。
[VIC] McCanne, S. and Jacobson, V., "vic: A Flexible Framework for Packet Video", ACM Multimedia '95, November 1995, San Francisco, CA, pp. 511-522. <ftp://ftp.ee.lbl.gov/papers/vic-mm95.ps.Z>
[VIC] McCanne、S.とヤコブソン、V.、 "VIC：パケットビデオのための柔軟なフレームワーク"、ACMマルチメディア'95、1995年11月、サンフランシスコ、CA、頁511から522まで。 <ftp://ftp.ee.lbl.gov/papers/vic-mm95.ps.Z>
[802.1D] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e.", ISO/IEC 15802-3: 1998.
[802.1D]「情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - 第3部：1993、802.1：メディアアクセス制御（MAC）はブリッジ：これは、ISO / IEC 10038の改訂版改訂でありますJ-1992と802.6k-1992はP802.11c、P802.1pとP802.12eを組み込んだ "、ISO / IEC 15802-3：1998。
Appendix A. Discussion of Token Buckets and Leaky Buckets
トークンバケットとのリーキーバケットの付録A.ディスカッション
"Leaky bucket" and/or "Token Bucket" models are used to describe rate control in several architectures, including Frame Relay, ATM, Integrated Services and Differentiated Services. Both of these models are, by definition, theoretical relationships between some defined burst size, B, a rate, R, and a time interval, t:
「リーキーバケット」および/または「トークンバケット」モデルは、フレームリレー、ATM、統合サービスと差別化サービスを含め、いくつかのアーキテクチャでレート制御を記述するために使用されています。これらのモデルの両方であり、定義によって、いくつかの定義されたバーストサイズ、B、レート、R、および時間間隔の間の理論的関係、T。
R = B/t
R = B / T
Thus, a token bucket or leaky bucket might specify an information rate of 1.2 Mbps with a burst size of 1500 bytes. In this case, the token rate is 1,200,000 bits per second, the token burst is 12,000 bits and the token interval is 10 milliseconds. The specification says that conforming traffic will, in the worst case, come in 100 bursts per second of 1500 bytes each and at an average rate not exceeding 1.2 Mbps.
したがって、トークン・バケットまたはリーキー・バケットは1500バイトのバーストサイズで1.2 Mbpsでの情報レートを指定するかもしれません。この場合には、トークンレートは、毎秒120万ビットであり、トークンバーストは12,000ビットであり、トークンの間隔は10ミリ秒です。仕様は、適合トラフィックは、最悪の場合、1500バイト毎の秒あたり100回のバーストで来て、平均速度で1.2 Mbpsのを超えないことを述べています。
A.1 Leaky Buckets
A.1のリーキーバケット
A leaky bucket algorithm is primarily used for shaping traffic as it leaves an interface onto the network (handled under Queues and Schedulers in this model). Traffic theoretically departs from an interface at a rate of one bit every so many time units (in the example, one bit every 0.83 microseconds) but, in fact, departs in multi-bit units (packets) at a rate approximating the theoretical, as measured over a longer interval. In the example, it might send one 1500 byte packet every 10 ms or perhaps one 500 byte packet every 3.3 ms. It is also possible to build multi-rate leaky buckets in which traffic departs from the interface at varying rates depending on recent activity or inactivity.
リーキーバケットアルゴリズムは、主として、それが（このモデルでキューおよびスケジューラの下で取り扱わ）ネットワークへのインターフェースを離れるようにトラフィックをシェーピングするために使用されます。トラフィックは、理論的には1ビットの割合で界面からのすべての非常に多くの時間単位（この例では、1ビット毎に0.83マイクロ秒）を出発しかし、実際には、理論的に近似した速度でマルチビット単位（パケット）で出発し、として長い期間に渡って測定。例では、1つの1500バイトのパケットごとに10ミリ秒または多分1つの500バイトのパケットごとに3.3ミリ秒を送信することがあります。トラフィックが最近の活動または不活動によって異なるレートでインターフェイスから出発したマルチレートリーキーバケットを構築することも可能です。
Implementations generally seek as constant a transmission rate as achievable. In theory, a 10 Mbps shaped transmission stream from an algorithmic implementation and a stream which is running at 10 Mbps because its bottleneck link has been a 10 Mbps Ethernet link should be indistinguishable. Depending on configuration, the approximation to theoretical smoothness may vary by moving as much as an MTU from one token interval to another. Traffic may also be jostled by other traffic competing for the same transmission resources.
実装は、一般的に達成できる限り一定の伝送速度を求めます。理論的には、そのボトルネックリンクが10Mbpsのイーサネットリンクされているため、アルゴリズムの実装と10Mbpsで動作しているストリームから伝送ストリームを整形10Mbpsでは区別できなければなりません。構成に応じて、理論的な滑らかに近似は別のトークン間隔からMTU限り移動させることによって変えることができます。トラフィックは、同じ送信リソースを競合する他のトラフィックによってもますることができます。
A.2 Token Buckets
A.2トークンバケット
A token bucket, on the other hand, measures the arrival rate of traffic from another device. This traffic may originally have been shaped using a leaky bucket shaper or its equivalent. The token bucket determines whether the traffic (still) conforms to the specification. Multi-rate token buckets (e.g., token buckets with both a peak rate and a mean rate, and sometimes more) are commonly used, such as those described in [SRTCM] and [TRTCM]. In this case, absolute smoothness is not expected, but conformance to one or more of the specified rates is.
トークンバケットは、他の一方で、別のデバイスからのトラフィックの到着率を測定します。このトラフィックは、もともと漏れバケット整形またはそれと同等を用いて成形された可能性があります。トークンバケットは、トラフィックが（まだ）仕様に準拠しているかどうかを決定します。マルチレートトークンバケット（ピーク速度と平均速度の両方を有する、例えば、トークンバケット、時にはそれ以上）が一般的に使用され、このように記載されているような[SRTCM]および[TRTCM]。この場合、絶対的な滑らかさが予想されるが、指定したレートの1つまたはそれ以上への適合性があるされていません。
Simplistically, a data stream is said to conform to a simple token bucket parameterized by a {R, B} if the system receives in any time interval, t, at most, an amount of data not exceeding (R * t) + B.
単純化し、データ・ストリームは、{R、B}システムは、任意の時間間隔で受信する場合、Tは、最大で、データの量は超えない（式中、R *のT）+ B.によってパラメータ単純トークンバケットに適合するように言われています
For a multi-rate token bucket case, the data stream is said to conform if, for each of the rates, the stream conforms to the token-bucket profile appropriate for traffic of that class. For example, received traffic that arrives pre-classified as one of the "excess" rates (e.g., AF12 or AF13 traffic for a device implementing the AF1x PHB) is only compared to the relevant "excess" token bucket profile.
マルチレートのトークンバケットの場合、データストリームは、レートのそれぞれについて、ストリームがそのクラスのトラフィックに対して適切なトークンバケットプロファイルに準拠し、あれば一致するように言われています。例えば、「過剰」料金（AF1x PHBを実装するデバイスのための、例えば、AF12又はAF13トラフィック）の一つとして予め分類到着するトラフィックは、関連する「過剰」トークンバケットプロファイルと比較だけで受信します。
A.3 Some Consequences
いくつかの結果A.3
The fact that Internet Protocol data is organized into variable length packets introduces some uncertainty in the conformance decision made by any downstream Meter that is attempting to determine conformance to a traffic profile that is theoretically designed for fixed-length units of data.
インターネットプロトコルデータが可変長パケットに編成されているという事実は、理論的には、データの固定長の単位のために設計されたトラフィックプロファイルへの適合性を決定しようとしている任意の下流メーターによる適合性の決定におけるいくつかの不確実性を導入しています。
When used as a leaky bucket shaper, the above definition interacts with clock granularity in ways one might not expect. A leaky bucket releases a packet only when all of its bits would have been allowed: it does not borrow from future capacity. If the clock is very fine grain, on the order of the bit rate or faster, this is not an issue. But if the clock is relatively slow (and millisecond or multi-millisecond clocks are not unusual in networking equipment), this can introduce jitter to the shaped stream.
漏れバケット整形として使用する場合は、上記の定義は1つが期待していない可能性がある方法で、クロックの粒度と対話します。それは、将来の容量から借りていません：リーキーバケットは、そのビットのすべてが許可されていたパケットのみを解放します。クロックは非常に細かい粒子である場合には、ビットレート以上の速度の順に、これは問題ではありません。クロックが比較的遅い（ミリ秒またはマルチミリ秒クロックはネットワーク機器で珍しいことではないです）場合でも、これは、成形ストリームにジッタを導入することができます。
This leaves an implementor of a token bucket Meter with a dilemma. When the number of bandwidth tokens, b, left in the token bucket is positive but less than the size of the packet being operated on, L, one of three actions can be performed:
これはジレンマとトークンバケットメーターの実装を残します。トークンバケットに残った帯域幅トークン、Bの数は、オン操作されて陽性であるが、パケットのサイズ未満である場合、Lは、3つのアクションのいずれかを行うことができます。
(1) The whole size of the packet can be subtracted from the bucket, leaving it negative, remembering that, when new tokens are next added to the bucket, the new token allocation, B, must be added to b rather than simply setting the bucket to "full". This option potentially puts more than the desired burst size of data into this token bucket interval and correspondingly less into the next. It does, however, keep the average amount accepted per token bucket interval equal to the token burst. This approach accepts traffic if any one bit in the packet would have been accepted and borrows up to one MTU of capacity from one or more subsequent intervals when necessary. Such a token bucket meter implementation is said to offer "loose" conformance to the token bucket.
（1）パケットの全体サイズは、新しいトークンが次のバケットに追加されると、新しいトークン割当て、Bは、単純に設定ではなく、bに加えなければならないことを思い出して、負のそれを残して、バケットから差し引くことができます「フル」にバケツ。このオプションは、潜在的にこのトークンバケット間隔へのデータの所望のバーストサイズ以上のものを置き、それに応じて以下の次に。しかしながら、トークンバーストに等しいトークンバケット間隔ごとに受け入れ平均量を維持しません。パケット内の任意の1ビットが受け入れられ、必要なときに、1つまたは複数の後続の間隔から容量の1 MTUまで借りてきたならば、このアプローチは、トラフィックを受け入れます。このようなトークンバケットメートルの実装は、トークンバケットに「緩い」の適合性を提供すると言われています。
(2) Alternatively, the packet can be rejected and the amount of tokens in the bucket left unchanged (and maybe an attempt could be made to accept the packet under another threshold in another bucket), remembering that, when new tokens are next added to the bucket, the new token allocation, B, must be added to b rather than simply setting the bucket to "full". This potentially puts less than the permissible burst size of data into this token bucket interval and correspondingly more into the next. Like the first option, it keeps the average amount accepted per token bucket interval equal to the token burst. This approach accepts traffic only if every bit in the packet would have been accepted and borrows up to one MTU of capacity from one or more previous intervals when necessary. Such a token bucket meter implementation is said to offer "strict" (or perhaps "stricter") conformance to the token bucket. This option is consistent with [SRTCM] and [TRTCM] and is often used in ATM and frame-relay implementations.
（2）また、パケットは拒否することができ、バケット内のトークンの量は変更されないまま（そしておそらく試みは、別のバケット内の別のしきい値の下でパケットを受け入れるように作ることができる）新しいトークンが次に追加されたとき、それを思い出して、バケツ、新しいトークン割り当て、BはA、Bではなく、単に「フル」にバケットを設定するために追加する必要があります。これは、潜在的に次にそれだけこのトークンバケット間隔へのデータの許容バーストサイズ未満となります。最初のオプションのように、それはトークンバーストに等しいトークンバケット間隔ごとに受け入れられた平均量を保持します。このアプローチは、パケット内のすべてのビットが承認された場合にのみ、トラフィックを受け入れ、必要なときに、1つのまたは複数の前の間隔から容量の1 MTUまで借ります。そのようなトークンバケットメータ実装は、トークンバケットに「厳格」（あるいは「厳しい」）適合性を提供すると言われています。このオプションは、[SRTCM]と一致し、[TRTCM]としばしばATMおよびフレーム・リレーの実装に使用されます。
(3) The TB variable can be set to zero to account for the first part of the packet and the remainder of the packet size can be taken out of the next-colored bucket. This, of course, has another bug: the same packet cannot have both conforming and non-conforming components in the Diffserv architecture and so is not really appropriate here and we do not discuss this option further here.
（3）TB変数は、パケットの最初の部分を説明するためにゼロに設定することができ、パケット・サイズの残りは次色のバケットから取り出すことができます。これは、当然のことながら、別のバグがあります。同じパケットは、両方の準拠とDiffServアーキテクチャでコンポーネントを非適合していないので、ここで本当に適切ではないと私たちは、ここでは、このオプションを議論していないことができます。
Unfortunately, the thing that cannot be done is exactly to
fit the token burst specification with random sized packets:
therefore token buckets in a variable length packet
environment always have a some variance from theoretical
reality. This has also been observed in the ATM Guaranteed
Frame Rate (GFR) service category specification and Frame
Relay. A number of observations may be made:
o Operationally, a token bucket meter is reasonable for traffic which has been shaped by a leaky bucket shaper or a serial line. However, traffic in the Internet is rarely shaped in that way: TCP applies no shaping to its traffic, but rather depends on longer-range ACK-clocking behavior to help it approximate a certain rate and explicitly sends traffic bursts during slow start, retransmission, and fast recovery. Video-on-IP implementations such as [VIC] may have a leaky bucket shaper available to them,
O操作上、トークンバケットメーターは漏れバケット整形またはシリアルラインによって形成されたトラフィックのための合理的です。しかし、インターネットにおけるトラフィックはめったにそのように整形されていない：TCPは、そのトラフィックに何のシェーピングを適用していないのではなく、それは一定の割合を近似助けるために長いレンジのACKクロッキング動作に依存して明示的にスロースタート、再送信時にトラフィックバーストを送信し、そして高速回復。こうした[VIC]として、ビデオ・オン・IPの実装は、それらに利用可能な漏れバケット整形を有していてもよく、
but often do not, and simply enqueue the output of their codec for transmission on the appropriate interface. As a result, in each of these cases, a token bucket meter may reject traffic in the short term (over a single token interval) which it would have accepted if it had a longer time in view and which it needs to accept for the application to work properly. To work around this, the token interval, B/R, must approximate or exceed the RTT of the session(s) in question and the burst size, B, must accommodate the largest burst that the originator might send.
しかし頻繁にない、と単純に適切なインターフェイス上での送信のために彼らのコーデックの出力をエンキュー。その結果、これらの各場合には、トークンバケットメーターは、それがビューに長い時間を持っていたし、それはアプリケーションのために受け入れるために必要がある場合、それが受け入れられているだろう（単一のトークン間隔にわたる）短期的にトラフィックを拒否することができます正常に動作します。この問題を回避するために、トークン間隔、B / Rは、発信者が送るかもしれない最大バーストを収容しなければならない、近似又は当該セッション（S）とバーストサイズ、BのRTTを超えなければなりません。
o The behavior of a loose token bucket is significantly different from the token bucket description for ATM and for Frame Relay.
O緩いトークンバケットの動作は、ATM用とフレームリレーのためのトークンバケットの記述とは大きく異なります。
o A loose token bucket does not accept packets while the token count is negative. This means that, when a large packet has just borrowed tokens from the future, even a small incoming packet (e.g., a 40-byte TCP ACK/SYN) will not be accepted. Therefore, if such a loose token bucket is configured with a burst size close to the MTU, some discrimination against smaller packets can take place: use of a larger burst size avoids this problem.
トークン数が負のまま、o緩いトークンバケットは、パケットを受け入れません。これは、大きなパケットは単に将来、小さな着信パケットからトークンを借りたときに（例えば、40バイトのTCPのACK / SYN）が受け入れられないであろう、ということを意味します。そのような緩いトークンバケットがMTUに近いバーストサイズで構成されている場合、したがって、小さいパケットに対するいくつかの判別を行うことができる：より大きなバーストサイズの使用は、この問題を回避します。
o The converse of the above is that a strict token bucket sometimes does not accept large packets when a loose one would do so. Therefore, if such a strict token bucket is configured with a burst size close to the MTU, some discrimination against larger packets can take place: use of a larger burst size avoids this problem.
O上記の逆は緩ん1がそうだろうというとき、厳密なトークンバケットは時々大きなパケットを受け入れないということです。そのような厳密なトークンバケットがMTUに近いバーストサイズで構成されている場合、したがって、より大きなパケットに対するいくつかの判別を行うことができる：より大きなバーストサイズの使用は、この問題を回避します。
o In real-world deployments, MTUs are often larger than the burst size offered by a link-layer network service provider. If so then it is possible that a strict token bucket meter would find that traffic never matches the specified profile: this may be avoided by not allowing such a specification to be used. This situation cannot arise with a loose token bucket since the smallest burst size that can be configured is 1 bit, by definition limiting a loose token bucket to having a burst size of greater than one MTU.
O現実世界の展開では、MTUのは、多くの場合、リンク層、ネットワークサービスプロバイダによって提供されるバースト・サイズよりも大きいです。これは、そのような仕様が使用できるようにすることではないことで回避することができる。もしそうなら、厳格なトークンバケットメーターは、トラフィックが指定されたプロファイルと一致しないことを見つけるだろうということも可能です。構成可能な最小バーストサイズが1つのより大きいMTUのバーストサイズを有することにルーズトークンバケットを制限する定義により、1ビットであるので、この状況は緩いトークンバケットで発生することができません。
o Both strict token bucket specifications, as specified in [SRTCM] and [TRTCM], and loose ones, are subject to a persistent under-run. These accumulate burst capacity over time, up to the maximum burst size. Suppose that the maximum burst size is exactly the size of the packets being sent - which one might call the "strictest" token bucket implementation. In such a case, when one packet has been accepted, the token depth becomes zero and starts to accumulate again. If the next packet is received any time earlier than a token interval later, it will not be accepted. If the next packet arrives exactly on time, it will be accepted and the token depth again set to zero. If it arrives later, however, accumulation of tokens will have stopped because it is capped by the maximum burst size: during the interval between the bucket becoming full and the actual arrival of the packet, no new tokens are added. As a result, jitter that accumulates across multiple hops in the network conspires against the algorithm to reduce the actual acceptance rate. Thus it usually makes sense to set the maximum token bucket size somewhat greater than the MTU in order to absorb some of the jitter and allow a practical acceptance rate more in line with the desired theoretical rate.
【SRTCM]および[TRTCM]、及び緩いものに指定されているO両方厳密トークンバケット仕様は、永続的なアンダーランの対象となっています。これらは、最大バーストサイズまで、経時的にバースト能力を蓄積します。 1は「厳しい」トークンバケットの実装を呼ぶかもしれない - 最大バーストサイズは、送信されるパケットの正確大きさであると仮定します。このような場合には、一つのパケットを受け付けた場合、トークン深さがゼロになると再び蓄積し始めます。次のパケットは、トークン間隔後でより前の時間を受信した場合、それが受理されません。次のパケットが時間通りに正確に到着した場合、それが受け入れられ、トークンの深さは再びゼロに設定します。それはそれは最大バーストサイズでキャップされているので、後に、しかし、トークンの蓄積が停止しています到着した場合：バケットの間隔が一杯になって、パケットの実際の到着時に、新しいトークンが追加されません。結果として、ネットワーク内の複数のホップを横切る累積ジッタは実際の受入率を低減するためのアルゴリズムに対して共謀します。したがって、通常のジッタの一部を吸収し、より多くの所望の理論的な速度に合わせて実用的な受け入れ率を可能にするために、MTUよりも幾分大きい最大トークンバケットサイズを設定するために理にかなっています。
A.4 Mathematical Definition of Strict Token Bucket Conformance
厳格なトークンバケット適合性のA.4数学的な定義
The strict token bucket conformance behavior defined in [SRTCM] and [TRTCM] is not mandatory for compliance with any current Diffserv standards, but we give here a mathematical definition of two-parameter token bucket operation which is consistent with those documents and which can also be used to define a shaping profile.
[SRTCM]で定義された厳格なトークンバケット適合性行動と[TRTCM]任意の現在のDiffserv標準に準拠するため必須ではありませんが、我々はここにも、それらの文書と一致しているとことができる2つのパラメータトークンバケット操作の数学的な定義を与えますシェーピングプロファイルを定義するために使用されます。
Define a token bucket with bucket size B, token accumulation rate R and instantaneous token occupancy b(t). Assume that b(0) = B. Then after an arbitrary interval with no packet arrivals, b(t) will not change since the bucket is already full of tokens.
バケットサイズB、トークン蓄積率Rと瞬時トークン占有B（T）とトークンバケットを定義します。バケットが既にトークンに満ちているので（0）= Bでそしてなしパケットの到着との任意の間隔の後、B（t）が変更されないこと、Bを想定します。
Assume a packet of size L bytes arrives at time t'. The bucket occupancy is still B. Then, as long as L <= B, the packet conforms to the meter, and afterwards
想定サイズLバイトのパケットは、「時刻tに到着します。バケット占有率は、L <= Bは、パケットがメータに準拠している限り、そして依然としてB.であり、そしてその後
b(t') = B - L.
B（T '）= B - L.
Assume now an interval delta_t = t - t' elapses before the next packet arrives, of size L' <= B. Just before this, at time t-, the bucket has accumulated delta_t*R tokens over the interval, up to a maximum of B tokens so that:
T <= B.ちょうどこの前、時間T-で、バケットが蓄積してきたdelta_Tの* Rトークン間隔で、最大値まで「次のパケットは、サイズLのため、到着が経過する前に」 - 今= tのdelta_Tの間隔を想定Bトークンのように：
b(t-) = min{ B, b(t') + delta_t*R }
B（T-）=分{B、B（T '）+ delta_Tの* R}
For a strict token bucket, the conformance test is as follows:
次のように厳格なトークンバケットについて、適合性試験は次のようになります。
if (b(t-) - L' >= 0) {
/* the packet conforms */
b(t) = b(t-) - L';
}
else {
/* the packet does not conform */
b(t) = b(t-);
}
This function can also be used to define a shaping profile. If a packet of size L arrives at time t, it will be eligible for transmission at time te given as follows (we still assume L <= B):
この機能は、シェーピングプロファイルを定義するために使用することができます。サイズLのパケットが時刻tに到着した場合、それは次のように与えられた時間Teでの送信の対象となります（我々はまだLを想定<= B）：
te = max{ t, t" }
TE =最大{T、T「}
where t" = (L - b(t') + t'*R) / R and b(t") = L, the time when L credits have accumulated in the bucket, and when the packet would conform if the token bucket were a meter. te != t" only if t > t".
ここで、t "=（L - B（T '）+ tは' * R）/ RとB（T" トークンバケット場合）= L、Lのクレジットはバケツに蓄積してきた時、パケットは適合しますメートルでした。 TE！= T "だけT> Tであれば"。
A mathematical definition along these lines for loose token bucket conformance is left as an exercise for the reader.
緩いトークンバケット準拠のため、これらの線に沿って数学的な定義は読者の課題として残されています。
Authors' Addresses
著者のアドレス
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
よらｍ べｒねｔ みｃろそｆｔ おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２
Phone: +1 425 936 9568 EMail: ybernet@msn.com
電話：+1 425 936 9568 Eメール：ybernet@msn.com
Steven Blake Ericsson 920 Main Campus Drive, Suite 500 Raleigh, NC 27606
スティーブ・ブレイク・エリクソン920メインキャンパスドライブ、スイート500ローリー、ノースカロライナ27606
Phone: +1 919 472 9913 EMail: steven.blake@ericsson.com
電話：+1 919 472 9913 Eメール：steven.blake@ericsson.com
Daniel Grossman Motorola Inc. 20 Cabot Blvd. Mansfield, MA 02048
ダニエル・グロスマンモトローラ20カボットブルバードマンスフィールド、MA 02048
Phone: +1 508 261 5312 EMail: dan@dma.isg.mot.com
電話：+1 508 261 5312 Eメール：dan@dma.isg.mot.com
Andrew Smith (editor) Harbour Networks Jiuling Building 21 North Xisanhuan Ave. Beijing, 100089 PRC
アンドリュー・スミス（エディタ）ハーバー・ネットワークJiulingビル21北Xisanhuanアベニュー。北京、100089 PRC
Fax: +1 415 345 1827 EMail: ah_smith@acm.org
ファックス：+1 415 345 1827 Eメール：ah_smith@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。