[要約] RFC 3290は、Diffservルーターの非公式な管理モデルについての要約です。このRFCの目的は、Diffservルーターの管理を効果的に行うためのガイドラインを提供することです。
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
Diffservルーターの非公式管理モデル
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.
Copyright（c）The Internet Society（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）ルーターの非公式管理モデルを提案しています。このモデルでは、機能的なデータパス要素（分類器、メーター、アクション、マーキング、絶対ドロップ、カウント、多重化、多重化）、アルゴリズムドロッパー、キュー、スケジューラーを定義します。これらの要素の可能な構成パラメーターと、それらがどのように相互接続されて、DiffServアーキテクチャで説明されているトラフィックコンディショニングとホップごとの動作（PHB）機能の範囲を実現する方法について説明します。
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 CodePoint（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）の1つに集約できるため、処理と関連するストレージを簡素化できることです。さらに、各パケットの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アーキテクチャにより、ネットワークに展開できるさまざまなサービスが可能になります。これらのサービスは、サービスレベルの仕様（SLS -[Newterms]を参照）の形でDiffServネットワークの端にある顧客に反映されます。このようなサービスのさらなる議論はこのドキュメントの範囲外（[PDBDEF]を参照）の外側にありますが、これらのサービスを提供する機能は、Diffservルーターのセットをプロビジョニングおよび監視するために使用できるまとまりのある管理および構成ツールの可用性に依存します。調整された方法。このような構成および管理ツールの開発を容易にするために、構成と管理のために対象のパラメーターから特定の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 セクション3は、DiffServルーターの基本的な高レベルブロックを説明することから始めます。モデルで使用される概念を説明します。これには、分類子、アクション、キューなどの低レベルの機能データパス要素を使用するこれらのブロックの階層管理モデルを含む。
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.
DataPath 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)
マルチプレクサーAマルチプレクサー。（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) Work- A property of a scheduling algorithm such that it conserving services a packet, if one is available, at every transmission opportunity.
トラフィックパラメーターのセットと、条件付けが分類器ルールのセットとトラフィック仕様プロファイルを指定する値。TCSは、SLSの不可欠な要素です。（TCS）ワーク - すべての送信機会で、利用可能な場合、パケットを保存するようにスケジューリングアルゴリズムのプロパティ。
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ルーターのブロック図を紹介し、図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).
o 上記の機能的データパス要素の特定の組み合わせは、トラフィックコンディショニングブロック（TCB）として知られる高レベルのブロックへの要素です。
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構成および管理ツールで管理可能である必要があるビルディングブロックを構成します。このドキュメントの目標の1つは、これらのコンポーネントブロックを使用して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などのパケットフィールドの使用が含まれる可能性がありますが、これはこのモデルの範囲外です）。特定のルーターのスイッチングファブリック/バックプレーンの実際のキューイング遅延とパケット損失の動作は、ルーティングコアによってモデル化されていません。これらは、後で説明する機能的なデータパス要素を使用してモデル化する必要があります。このモデルのルーティングコアは、インターフェイス間の無限の帯域幅、ゼロデレイインターコネクト - オーバーロードされたときのコアの動作のようなプロパティと考えることができます。Eugressインターフェイスのコアを越えて多くのトラフィックが向けられています）、過剰をどこかにドロップまたはキューに留めなければなりません。これらの機能を実行する要素は、関連するインターフェイスの1つでモデル化する必要があります。
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）へのコンプライアンスを追跡するために重要な場合があります。プロビジョニングされたパラメーターは、主に分類器とメーターのTCSパラメーター、およびアクションおよびキューイング要素の関連するPHB構成パラメーターです。ネットワーク管理者は、SNMPやCOPなどの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]のシグナル伝達ごとのマイクロフロウまたは1枚あたりの凝集シグナルのいずれかにスヌープまたは関与する場合があります（たとえば、RSVPプロトコルの使用）。たとえば、RSVPメッセージのスヌーピングを使用して、RSVPプロトコルピアとして実際に参加せずにトラフィックを分類する方法を学ぶことができます。DiffServルーターは、RSVP予約リクエストを拒否または認めて、Diffservベースのサービスに入学制御の手段を提供するか、これらの要求を使用して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エージェントコンポーネントは、存在する場合、データプレーンではなく制御プレーンでのみアクティブである可能性があることに注意してください。このシナリオでは、RSVPを使用して、Diffservルーターのデータプレーンに実際の予約を設置せずに予約状態を信号するだけで使用できます。データプレーンは、純粋にDiffserv DSCPで作用し、通常の1人の微生物群なしでデータトラフィックを処理するためのPHBを提供できます。いくつかのIntServサービスをサポートすることが期待されるハンドリング。
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:
原則として、2ポートルーター（LANまたは同様のメディアで接続されている）から完全にネットワークを構築する場合、各ルーターが各方向のトラフィックでデータパスで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.
- 適切なキューの出力のトラフィックをenqueueします。このキューからの出力のスケジューリングは、トラフィックの形成につながる可能性があるか、単に最小レートまたは最大遅延保証で転送される可能性があります。
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ポートルーターから構築された場合、ネットワークの予想される動作は同一である必要があります。したがって、このモデルは、ルーターのインターフェイスの出口と同じように、入り口で本質的に同じ一連の関数を提供する必要があります。イングレスと出口のモデルの違いの1つのポイントは、インターフェイスの出口でのすべてのトラフィックがキューに巻かれているのに対し、インターフェースへのイングレスのトラフィックは、たとえあったとしても、形成目的のためにのみキューに巻かれる可能性が高いことです。したがって、インターフェイスからの侵入と出口の両方で、同等の機能的データパス要素をモデル化することができます。
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を参照してください。ポリシングは、絶対ドロッパーを使用したメーターの連結、またはスケジューラとのアルゴリズムドロッパーの連結のいずれかとしてモデル化されています。これらの要素は、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に相互接続されたこれらの機能的なデータパス要素のグループ化を管理します。これらの機能的なデータパス要素は、いくつかの望ましいネットワークポリシーを実装するために使用される自己完結型TCBで編成されています（セクション8を参照）。1つ以上の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.
ここで考慮される最上位レベルでは、ネットワーク管理者がインターフェイスを管理します。各インターフェイスには機能性があり、それぞれが1つ以上の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.
可能な限り単純な分類子要素は、入力で適用されるすべてのパケットに一致するものです。この場合、分類子要素は単なるNO-OPであり、省略される場合があります。
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を参照）を許可して、複数のトラフィックストリームからの入力を許可することに注意してください。たとえば、複数のIngressインターフェイスに由来するトラフィックストリームが単一の分類器を介してフィードする場合、インターフェイス番号は、分類器が使用するパケット分類キーの1つになる可能性があります。この最適化は、管理面でのスケーラビリティにとって重要かもしれません。また、分類器を順番にカスケードして、より複雑なルックアップ操作を実行しながら、そのようなスケーラビリティを維持することもできます。
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).
パケット属性のもう1つの例は、パケットの最適なルートに関連付けられたBGPコミュニティの文字列を表す整数です。他のコンテキスト情報は、分類子によっても使用される場合があります（たとえば、DSCPが存在するかどうかを判断する際に、特定のインターフェイスがDiffServドメインまたはレガシーIP TOSドメイン[DSARCH]に直面するという知識）。
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つの出力ストリームのいずれかに分離します。
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で構成され、Filter1と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アドレスの4番目のオクテットとソースTCPポートは、ワイルドカードまたは「気にしない」です。
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 Dest Addr 172.31.8.1、IP SRC Addr 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.
別の例として、最初に特定のアプリケーションがネットワークを使用することを許可したり、拡散していない個々のトラフィックストリームを分類したりすることを望むかもしれません。これらのテストによって分類されていないトラフィックは、DSCPについて検査される場合があります。「Then」という言葉はシーケンスを意味し、これは優先順位によって指定する必要があります。
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つのフィルター（おそらくWildCardのデフォルト）を一致させ、重複するフィルター間のあいまいさを優先順位で解決する必要があります。したがって、特定のインターフェイスの分類器は「完全」でなければならず、多くの場合、分類の結果が決定論的であるために、最低の優先順位要素として「他のすべて」フィルターを含めます。この完全性は、インターフェイスに入るときに入ってくるトラフィックが満たす最初の分類器にのみ必要であることに注意してください - インターフェイス上の後続の分類子は、受け取ることが知られているトラフィックを処理するだけです。
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 CodePoint（DSCP）のみを使用して、パケットを指示する論理出力ストリームを決定します。割り当てられたDSCP値には構造がないため、DSCPビットのサブセットは有意ではないため、このフィールドでの正確な試合条件のみを許可します。
The following defines a possible BA filter:
以下は、可能なBAフィルターを定義しています。
Filter8: Type: BA Value: 111000
フィルター8：タイプ：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]です。これは、パケット内の1つ以上のフィールド（DSCPを含む）に基づいてパケットを分類します。一般的なタイプの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
フィルター：タイプ：IPv4-6-Tuple IPv4DestadDrvalue：0.0.0.0 IPv4Destaddrmask：0.0.0.0 IPv4Srcaddrvalue：172.31.8.0 IPv4SrCADDRMASK：255.255.255.0 IPV4DSCP：IPV4PROTL4DESTPDESTPDSCOL ax：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 Filter12: Type: FreeForm SizeBits: 3 (bits) Offset: 16 (bytes) Value: 100 (binary) Mask: 101 (binary)
classifier2：filter12：outputa filter13：outputbデフォルト：outputc filter12：タイプ：フリーフォームサイズビット：3（ビット）オフセット：16（バイト）値：100（バイナリ）マスク：101（バイナリ）
Filter13: Type: FreeForm SizeBits: 12 (bits) Offset: 16 (bytes) Value: 100100000000 (binary) Mask: 111111111111 (binary)
filter13：タイプ：フリーフォームサイズビット：12（ビット）オフセット：16（バイト）値：100100000000（バイナリ）マスク：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の下のDatalinkレイヤー（VLANやDatalink-Layerの優先度など）の情報または出口IP、論理または物理インターフェイス識別子（チャネル化されたインターフェイスの着信チャネル番号など）に基づいて実行できます。。IEEE 802.1pの優先順位と802.1Q VLAN-IDに基づいてフィルターを使用する分類器は、次のように表される場合があります。
Classifier3: Filter14 AND Filter15: OutputA Default: OutputB
分類子3：Filter14およびFilter15：出力デフォルト：出力
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値：100100000000（バイナリ）マスク：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.
いくつかの違いの例（例：[AF-PHB]）では、3つのレベルの適合性が色の観点から議論されています。これらの異なる適合レベルを使用して、処理の後半で治療を後のキューイング、マーキング、またはドロップすることをトリガーできます。他の例メーターは、適合のバイナリ概念を使用しています。一般的な場合、nの適合レベルをサポートできます。一般に、メーター出力に続く機能データパス要素のタイプに制約はありませんが、関連するPHB仕様の要件と一致しないパケット再注文をもたらすデータパスを不注意に構成しないように注意する必要があります。
unmetered metered
traffic traffic
+---------+
| |--------> conformance A
--------->| meter |--------> conformance B
| |--------> conformance C
+---------+
Figure 4. A Generic Meter
図4.一般的なメーター
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：タイプ：平均プロファイル：Profile1 conformingoutput：queue1 nonconformingoutput：counter1
Profile1: Type: AverageRate AverageRate: 120 kbps Delta: 100 msec
プロファイル1：タイプ：平均測定平均：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.
このプロファイルに対して測定するメーターは、時間t（現在）と時間t -100ミリ秒の間に到着するパケットの総数および/または累積バイトカウントを示すカウントを継続的に維持します。到着するパケットが過去100ミリ秒で12 kBを超えるカウントをプッシュしない限り、パケットは適合と見なされます。カウントを12 kビット以上のプッシュするパケットは、不適合とみなされます。したがって、このメーターは、パケットが適合または不適合の2つの適合レベルのいずれかに対応すると見なされ、適切な後続の治療のためにそれらを送信します。
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
For a packet arriving at time t:
時間に到着するパケットの場合：
if (avg_rate(t) > AverageRate) non-conforming else conforming
if（avg_rate（t）> ververagerate）nonconforming else conforming
"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）」は、小さな固定サンプリング間隔であるDeltaの入ってくるバイトの数を測定します。到着して平均レートをプッシュするパケットは、定義済みのレートの平均レートにわたってプッシュされます。EWMAメーターのプロファイルは、次のように見えるかもしれません：
Meter2: Type: ExpWeightedMovingAvg Profile: Profile2 ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper1
Meter2：Type：ExpweightedMovingAvgプロファイル：Profile2 conformingOutput：queue1 nonconformingOutput：absolutedropper1
Profile2: Type: ExpWeightedMovingAvg AverageRate: 25 kbps Delta: 10 usec Gain: 1/16
プロファイル2：タイプ：ExpweightedMovingavg Averagerate：25 kbpsデルタ：10 USECゲイン：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プロファイルには、一般に2つのパラメーター、平均トークンレート、R、およびバーストサイズの2つのパラメーターがあります。TBメーターは、パケットの到着率をTBプロファイルで指定された平均レートと比較します。論理的には、トークンは平均レートr、バーストサイズの最大クレジットまでバケツに蓄積します。長さlのパケットが到着すると、適合テストが適用されます。広く使用されているこのようなテストは少なくとも2つあります。
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以上です）：トークンは借用していない場合があります将来のトークンの割り当てから。このアプローチの例については、[SRTCM]および[TRTCM]を参照してください。
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メーターには、正確に2つの可能な適合レベル（適合、不適合）があります。このようなメーターは次のように表示される場合があります。
Meter3: Type: SimpleTokenBucket Profile: Profile3 ConformanceType: loose ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper1
Meter3：Type：SimpleTokenBucketプロファイル：Profile3 ConformanceType：loose conformingOutput：queue1 nonconformingoutput：absolutedropper1
Profile3: Type: SimpleTokenBucket AverageRate: 200 kbps BurstSize: 100 kbytes
プロファイル3：タイプ：SimpleTokenBucket Averagerate：200 kbpsバーストサイズ：100 kbytes
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]でより詳細に説明されています。これらの参考文献のいくつかでは、3つのレベルの適合性が、緑を表す緑色、部分的に適合する黄色、および不適合を表す赤の観点から議論されています。これらの複数コンフォーマンスレベルのメーターは、複数の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：Type：Tworatetokenbucket Profilea：Profile4 ConformanceTypea：Strict ConformingOutputa：Queue1
ProfileB: Profile5 ConformanceTypeB: strict ConformingOutputB: Marker1 NonConformingOutput: AbsoluteDropper1
ProfileB：Profile5 ConformanceTypeb：Strict ConformingOutputB：Marker1 nonconformingOutput：absolutedropper1
Profile4: Type: SimpleTokenBucket AverageRate: 100 kbps BurstSize: 20 kbytes
プロファイル4：タイプ：SimpleTokenBucket Averagerate：100 kbpsバーストサイズ：20 kbytes
Profile5: Type: SimpleTokenBucket AverageRate: 100 kbps BurstSize: 100 kbytes
プロファイル5：タイプ：SimpleTokenBucket Averagerate：100 kbpsバーストサイズ：100 kbytes
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.
ヌルメーターには、常に適合し、関連する時間プロファイルがないという出力が1つしかありません。このようなメーターは、構成または管理インターフェイスがデータパスセグメントでメーターを省略する柔軟性がない場合に定義するのに役立ちます。
Meter5: Type: NullMeter Output: Queue1
Meter5：タイプ：nullmeter出力：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.
DSCPマーカーは、コードポイントを設定する1：1要素です（例：IPヘッダーのDSCP）。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.
DIFFSERVのDSCPマーカーは、通常、単一のパラメーターでパラメーター化されます。パケットヘッダーにマークされる6ビット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.
絶対ドロッパーは単にパケットを破棄します。これらのドロッパーのパラメーターはありません。この絶対的なドロッパーはデータパスの終了点であり、出力がないため、計装目的のために最初にカウンターアクションを通じてパケットを転送することがおそらく望ましいです。
AbsoluteDropper1: Type: AbsoluteDropper
AbsoluteDropper1：Type：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.
単一の入力を使用して、トラフィックをマルチプレックスすることが機能的なデータパス要素にストリーミングされることがあります。A M：1（ファンイン）マルチプレクサは、トラフィックストリームを統合するための単純な論理デバイスです。着信ポートの数によってパラメーター化されています。
Mux1: Type: Multiplexor Output: Queue2
Mux1：タイプ：マルチプレクサー出力：queue2
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つの受動的なアクションは、データパケットが処理されたという事実を説明することです。結果の統計は、後で顧客請求、サービス検証、またはネットワークエンジニアリングの目的で使用される可能性があります。カウンターは1：1の機能的なデータパス要素であり、Lバイトサイズのパケットがそれらを通過するたびに、Lとパケットカウンターを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：タイプ：null出力：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データ構造として実装されます。ただし、これは、厳密に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つの出力が正確です。キューのテールにパケットを追加するエンキュー操作と、キューのヘッドからパケットを削除するためのデクエ操作をサポートする必要があります。パケットは、それらがenquedされた順序でデキュートする必要があります。FIFOには現在の深さがあり、特定の時間に含まれるパケットおよび/またはバイトの数を示します。このモデルのFIFOは、深さに固有の制限なしにモデル化されています。明らかに、これは実装の現実を反映していません。FIFOサイズの制限は、ここではFIFOに関連付けられたアルゴリズムドロッパー、通常はその入力でモデル化されます。すべてのFIFOの前にアルゴリズムドロッパーが先行する可能性が非常に高いです。1つの例外は、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に起因する1つの一般的なタイプの深度制限を可能にします。
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つ以上のバッファーに保存されます。バッファーは、1つ以上の無料バッファープールから割り当てられます。FIFOの複数のインスタンスがある場合、それらのパケットバッファーは、同じ無料バッファープールから割り当てられている場合とは割り当てられない場合があります。無料のバッファープールには、それらに関連する1つ以上のしきい値がある場合があり、廃棄やスケジューリングに影響する場合があります。これ以外に、バッファリングメカニズムは実装固有であり、このモデルの一部ではありません。
A FIFO might be represented using the following parameters:
FIFOは、次のパラメーターを使用して表現される場合があります。
Queue1: Type: FIFO Output: Scheduler1
Queue1：Type：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):
サービスの規律（スケジューリングアルゴリズムとも呼ばれます）は、以下のいずれかを入力としてとる可能性のあるアルゴリズムです。
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]、EF [EF-PHB]、AF [AF-PHB]などの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 PHBの実装では、他のBASの飢starを避けるために、総EFレートが上流のポリシングによって適切に制限されていると仮定する厳密な優先スケジューリングアルゴリズムを使用して、サービスレートプロファイルは使用されません。最小サービスは使用されません。レートプロファイルはデフォルトでゼロになり、最大サービスレートプロファイルは事実上「ラインレート」になります。複数の優先度クラスを備えたこのような実装は、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
スケジューラ1：タイプ：Scheduler2Input
Input1: MaxRateProfile: Profile1 MinRateProfile: Profile2 Priority: none
input1：maxrateprofile：profile1 minrateprofile：profile2優先度：なし
Input2: MaxRateProfile: Profile3 MinRateProfile: Profile4 Priority: none
input2：maxrateprofile：profile3 minrateprofile：profile4優先度：なし
A work-conserving scheduler might be represented using the following parameters:
以下のパラメーターを使用して、作業制度のスケジューラを表現することができます。
Scheduler2: Type: Scheduler3Input Input1: MaxRateProfile: WorkConserving MinRateProfile: Profile5 Priority: 1
Scheduler2：Type：Scheduler3Input input1：MaxrateProfile：WorkConserving MinrateProfile：Profile5 Priority：1
Input2: MaxRateProfile: WorkConserving MinRateProfile: Profile6 Priority: 2
input2：maxrateprofile：workconserving minrateprofile：profile6 priority：2
Input3: MaxRateProfile: WorkConserving MinRateProfile: none Priority: 3
input3：maxrateprofile：workconserving minrateprofile：なし優先度：3
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:
アルゴリズムドロッパーの主な特性の1つは、どのパケット（もしあれば）を削除するかの選択です。このモデルの目的のために、パケット選択の選択肢を次のいずれかに制限し、相対的な選択を示します。モデル内のアルゴリズムドロッパーおよび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の分類器によって分類されたパケットが同じドロッパーを通過することになる可能性があります。Dropperのアルゴリズムは、着信パケットの特性（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つの定式化は、ドロッパー内のドロップ確率計算アルゴリズムの1つから元の分類子要素までのポインターを持つことでした。このアルゴリズムを選択します。別の方法は、前の要素から供給されたアルゴリズムのドロッパー要素に複数の「入力」を持つことであり、最終的にパケットに一致する分類子要素に戻ることでした。さらに別の定式化は、分類器が（論理的に）、後続の要素で使用するために、そのパスに沿ったパケットとともに、何らかの「分類識別子」を含めることであったかもしれません。また、もう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つ以上のトリガーが1つ以上のトリガーをドロップするかどうかを決定します。トリガーは内部（ドロッパーへの入力へのパケットの到着）または外部（しきい値を横切るFIFOキューの深さやスケジューリングイベントを横切るなど、別の要素の1つ以上の状態の変更に起因する）である場合があります。有用なトリガーとして使用される前に、平均的な間隔で瞬時にFIFO深さを滑らかにする必要がある可能性があります。一部のドロップアルゴリズムには、システム内の他の場所のイベントからフィードバックするいくつかのトリガー入力が必要になる場合があります（たとえば、平均を1回以上の間隔で計算する深度スムージング関数）。
+------------------+ +-----------+
| +-------+ | 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 Queue element. As an example, a dropper using a RIO algorithm might be represented using 2 Algorithmic Droppers with the following parameters:
赤、レッドオンイン - アンドアウト（RIO）、ドロップオンスレッジョンは、アルゴリズムのドロップの例です。テールドロップとヘッドドロップは、FIFOキュー要素に対するアルゴリズム滴下要素の位置によって行われます。例として、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%
アルゴリズムドロップパル1 ：（プロファイルのトラフィック用）タイプ：アルゴリズムドロッパー分野：レッドトリガー：内部出力：fifo1 minthresh> 20 kbyte maxthresh：fifo1.depth> 30 kbyteサンプル級.00
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 ：（プロファイル外のトラフィック用）タイプ：アルゴリズムドロッパー分野：赤いトリガー：内部出力：fifo1 minthresh：fifo1.deph> 10 kbyte maxthresh：fifo1.depth> 20 kbyteサンプル級
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：Type：AlgorithmicDropper Discipline：Drop-on-Thresholdトリガー：FIFO2.DEPTH> 20 KBYTE出力：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]、およびその他の同様のテクノロジーの[RFC 791]に記載されている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をカスケードすることによって実行されます。1つのTCBの出力は、後続の入力の入力を駆動する場合があります。たとえば、クラスのセットのトラフィックがレートのセットに形作られる場合を考えてみましょうが、クラスグループの合計出力率もレートに制限する必要があります。それぞれが一定の最大レートを持つ一連のネットワークニュースフィードと、それらの集合体がいくつかの数値を超えないかもしれないというポリシーを想像するかもしれません。これは、2つのTCBをカスケードすることで単純に実現できます。最初のものは、個別のフィードへのトラフィックを分類し、各フィードを個別にキューにします。フィード（またはそれらのサブセット）は2番目の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要素です。ただし、完全なTCBは、1：1または1：n抽象要素になるはずです。要素のファンインまたはファンアウトは、この分類法の重要な定義特性ではないことに注意してください。
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トラフィックストリームと他のトラフィックストリームを混合することができます。または、2つのスケジューラ間にキューおよび/またはドロッパーがある場合があります。
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は、顧客がDSCP 001001にマークされたパケットを送信できることを指定します。これは、プロファイル4に適合し続ける限りEF治療を受けることができます。これは、このプロファイルを超えると破棄されます。廃棄されたパケットは、この例でカウントされています。おそらく、プロバイダーの販売部門が、より大きなSLSを購入するよう顧客に説得するために使用するためです。DSCP 001100にマークされたパケットは、転送前にProfile5に形作られます。DSCP 001101にマークされたパケットは、001000のDSCPを再マ化することにより、「格下げ」されていない不適当なパケットを使用してプロファイル3に計算されます。これは、パケットのDSCPフィールドによって元々PHBが指定されたPHBが与えられることをこの契約に暗黙的に示しています。。
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分類器は、顧客が要求したDIFSERVサービスレベルに基づいてトラフィックを分離するために使用されます（提出された各パケットのIPヘッダーのDSCPで示されています）。3つのDSCPフィルター値を示します：A、B、およびC. BA分類器の「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 001100のパスはDROPPer1に直接進み、DSCP 001001および001101のパスには計測ステージが含まれます。他のすべてのトラフィックは、Dropper3に直接渡されます。分類器出力AおよびCに対応するパケットの各セットには、各メーターが対応するDiffServサービスレベルに対して、TCSで指定されているように特定のプロファイルを使用して、個別のメーターがあります。この例のメーターは、それぞれ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.
計量段階に従うことは、一部のブランチのアクション段階です。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に渡す必要があります。これはエラーのケースである可能性があります。顧客は明らかに合意されたプロファイルに固執していません。同様に、元のDSCP 001101ストリームからのすべてのパケット（この段階で再マ化されたものもあります）は、algdropper2およびqueue3に渡されます。他のすべてのDSCPにマークされたパケットは、赤いアルゴリズムのドロッパーである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.
これらの4つのキュー要素は、スケジューラ要素スケジューラ1で使用されます。これは、各入力に適切な優先度および/または帯域幅共有を与えるように構成する必要があります。入力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：フィルター：Meter1 filterb：dropper1 filterc：meter2デフォルト：dropper 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) Meter1: Type: AverageRate Profile: Profile4 ConformingOutput: Queue1 NonConformingOutput: Counter1
図7：トラフィックコンディショニングブロックの例（パート2）メートル：タイプ：平均プロファイル：プロファイル4適合するアウトプット：queue1 nonconformingoutput：counter1
Counter1: Output: AbsoluteDropper1
Counter1：出力：AbsoluteDropper1
Meter2: Type: AverageRate Profile: Profile3 ConformingOutput: Mux1.InputA NonConformingOutput: Marker1
Meter2：タイプ：AverageRateプロファイル：Profile3 conformingOutput：mux1.inputa nonconformingOutput：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：Type：AlgorithmicDropper Discipline：Drop-on-Thresholdトリガー：queue2.depth> 10kbyte出力：queue2
AlgDropper2: Type: AlgorithmicDropper Discipline: Drop-on-threshold Trigger: Queue3.Depth > 20kbyte Output: Queue3
algdropper2：Type：AlgorithmicDropper Discipline：Drop-on-Thresholdトリガー：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>
Queue1: Type: FIFO Output: Scheduler1.InputA
キュー1：タイプ：FIFO出力：Scheduler1.input
Queue2: Type: FIFO Output: Scheduler1.InputB
Queue2：タイプ：FIFO出力：Scheduler1.inputB
Queue3: Type: FIFO Output: Scheduler1.InputC
Queue3：タイプ：FIFO出力：Scheduler1.inputc
Queue4: Type: FIFO Output: Scheduler1.InputD
Queue4：タイプ：FIFO出力：Scheduler1.inputd
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
スケジューラ1：タイプ：スケジューラ4Input入力：MaxrateProfile：なしMinrateProfile：Profile4 Priority：20 inputb：MaxrateProfile：Profile5 MinrateProfile：なし優先度：40 InputC：MaxrateProfile：None MinrateProfile：NONE MINRATEPROFILE：PROFIME3 PRUYTY：MAXRATEPROFILITY：NONE MINRATEPROFILITY
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 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.
次のように、構成は容易に変更されます。インターフェイスごとに複数の顧客のケースをサポートします。まず、各顧客がその顧客とTCSを反映するためにTCBが定義されます。上記で定義されたTCB1は、顧客1のTCBです。TCB2およびTCB3の同様の要素は、それぞれ顧客2と3との合意を反映しています。これらの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：to tcb1 filter2：tcb2 filter3：tcb3への一致なし：absolutedropper4
AbsoluteDropper4: Type: AbsoluteDropper
AbsoluteDropper4：Type：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 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
図8：マルチカスタマーTCBタイプの例：MacAddress SRCValue：01-02-03-04-05-06（顧客のソースMACアドレス）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 ：（ filter1に似ていますが、customer2のソースMacアドレスがsrcvalueとして）
Filter3: (similar to Filter1 but with customer 3's source MAC address as SrcValue)
filter3 ：（ filter1に似ていますが、customer3のソースMacアドレスがsrcvalueとして）
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.
顧客が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 Meter1: ConformingOutput: Mux1.InputA NonConformingOutput: AbsoluteDropper1
Marker3：出力：Meter3 Meter1：適合出力：mux1.input nonconforming出力：Absolutedropper1
Meter2: ConformingOutput: Mux1.InputB NonConformingOutput: AbsoluteDropper2
Meter2：conformingoutput：mux1.inputb nonconformingoutput：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のいずれかに対してマークされています。このトラフィックは、図10に示すTCB2に渡されます。
TCB2 could then be specified as follows:
TCB2は次のように指定できます。
Classifier2: (BA) FilterA: Meter5 FilterB: Meter6
分類器2：（BA）フィルター：メーターフィルター：メーター
+-----+
| |---------------> to Queue1
+->| | +-----+
+-----+ | | |---->| |
| A|---+ +-----+ +-----+
->| | Meter5 AbsoluteDropper4
| B|---+ +-----+
+-----+ | | |---------------> to Queue2
Classifier2 +->| | +-----+
(BA) | |---->| |
+-----+ +-----+
Meter6 AbsoluteDropper5
Figure 10: Additional Example: TCB2
図10：追加例：TCB2
Meter5: ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper4 Meter6: ConformingOutput: Queue2 NonConformingOutput: AbsoluteDropper5
Meter5：conformingOutput：queue1 nonconformingOutput：absolutedropper4 meter6：conformingoutput：queue2 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が別のマイクロフロー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ルーター要素の抽象的な機能モデルについて説明します。リソースの飢vから生じるものなどの特定のサービス拒否攻撃は、これらのルーター要素の適切な構成によって軽減される場合があります。たとえば、特定のトラフィックストリームを制限するレート、またはより高いサービス品質のためにマークされたトラフィックを認証することにより。
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]、およびMIBSおよび政策管理に関する他のIETF作業から自由に借用されています。これらの文書のいくつかの著者に感謝したいと思います：フレッド・ベイカー、マイケル・ファイン、キース・マクログリー、ジョン・セリグソン、クウォック・チャン、スコット・ハーン、アンドレア・ウェスリネンの貢献。
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、John Strassner、およびWalter Weissの数人の参加者のコメントと提案から恩恵を受けています。この文書は、共同議長のブライアン・カーペンターとキャシー・ニコルズの容赦ない圧力なしに、このレベルの大まかなコンセンサスに到達することはなかったでしょう。
[AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[AF-PHB] Heinanen、J.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、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] Carlson、M.、Weiss、W.、Blake、S.、Wang、Z.、Black、D。、およびE. Davies、「差別化されたサービスの建築」、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Baker、F.、Smith、A。、およびK. Chan、「差別化されたサービスアーキテクチャの管理情報ベース」、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.、Ford、P.、Baker、F.、Zhang、L.、Speer、M.、Nichols、K.、Braden、R.、Davie、B.、Wroclawski、J.およびE. Felstaine、「Diffserv Networksを介した統合サービス操作のフレームワーク」、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] Davie、B.、Charny、A.、Bennett、J.C.R.、Benson、K.、Le Boudec、J.Y.、Courtney、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] Floyd、S。およびV. Jacobson、「パケットネットワークのリンク共有およびリソース管理モデル」、IEEE/ACM Transactions on Networking、Vol。3 No. 4、19955年8月。
[INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[Intserv] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[NEWTERMS] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April, 2002
[Newterms] Grossman、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. NicholsおよびB. Carpenter、「ドメインの動作ごとの差別化されたサービスの定義とその仕様の規則」、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.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J. and 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.
[Qosdevmod] Strassner、J.、Westerinen、A。、およびB. Moore、「ネットワークデバイスQoSメカニズムを説明するための情報モデル」、進行中の作業。
[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] 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、「インターネットでのキュー管理と混雑回避に関する推奨事項」、RFC 2309、1998年4月。
[SRTCM] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[SRTCM] Heinanen、J。およびR. Guerin、「単一のレート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. Guerin、「Two Rate Three Color Marker」、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。およびJacobson、V。、「Vic：パケットビデオの柔軟なフレームワーク」、ACM Multimedia '95、1995年11月、カリフォルニア州サンフランシスコ、pp。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：メディアアクセス制御（MAC）ブリッジ：改訂。これはISO/IEC 10038：1993、802.11の改訂です。J-1992および802.6K-1992。P802.11C、P802.1PおよびP802.12E。 "、ISO/IEC 15802-3：1998が組み込まれています。
"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、aレート、R、および時間間隔の間の理論的な関係です。
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の情報レートを指定する場合があります。この場合、トークンレートは1秒あたり1,200,000ビット、トークンバーストは12,000ビット、トークン間隔は10ミリ秒です。仕様では、最悪の場合、適合トラフィックはそれぞれ1500バイトの1秒あたり100バーストで、1.2 Mbpsを超えない平均速度で行われると述べています。
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.
漏れやすいバケットアルゴリズムは、主にインターフェイスをネットワークに残すため、トラフィックを形作るために使用されます（このモデルのキューとスケジューラーで処理されます）。トラフィックは、理論的には、非常に多くの時間単位（例では0.83マイクロ秒ごとに1ビット）ごとに1ビットの速度でインターフェイスから出発しますが、実際には、理論的に近似するレートでマルチビット単位（パケット）で出発します。より長い間隔で測定されます。この例では、10ミリ秒ごとに1500バイトのパケット、または3.3ミリ秒ごとに1つの500バイトパケットを送信する場合があります。また、最近のアクティビティまたは非アクティブに応じて、トラフィックがさまざまな速度でインターフェイスから出発する多価漏れバケツを構築することも可能です。
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.
通常、実装は、達成可能なものとして一定の伝送速度を求めています。理論的には、ボトルネックリンクが10 Mbpsイーサネットリンクであるため、アルゴリズムの実装から10 Mbpsの形状の伝送ストリームと10 Mbpsで実行されるストリームは区別できないはずです。構成に応じて、理論的滑らかさの近似は、あるトークン間隔から別のトークン間隔にMTUと同じくらい移動することで異なる場合があります。また、同じトランスミッションリソースを競う他のトラフィックによってトラフィックが押し込まれる場合があります。
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.
単純なことに、データストリームは、システムがいつでもt、t、（r * t）Bを超えないデータの量をいつでも受信した場合、A {r、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.
多額のトークンバケットケースの場合、レートごとに、そのクラスのトラフィックに適したトークンバケットプロファイルに順応する場合、データストリームは適合すると言われています。たとえば、「過剰」レートの1つ（たとえば、AF1x PHBを実装するデバイスのAF12またはAF13トラフィックなど）として事前に分類されたトラフィックを受け取ったトラフィックは、関連する「過剰」トークンバケットプロファイルとのみ比較されます。
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.
漏れやすいバケットシェーパーとして使用する場合、上記の定義は、予期しない方法で時計の粒度と相互作用します。漏れやすいバケットは、すべてのビットが許可されていた場合にのみパケットをリリースします。将来の容量から借りることはありません。クロックが非常に細かい穀物である場合、ビットレートの順序またはより速い場合、これは問題ではありません。ただし、クロックが比較的遅い場合（およびネットワーク機器ではミリ秒または複数ミリ秒のクロックが珍しいことではありません）、これによりジッターが形成されたストリームを導入できます。
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:
これにより、トークンバケットメーターの実装者にジレンマが残ります。トークンバケットに残っている帯域幅のトークンの数がプラスであるが、操作されているパケットのサイズよりも少ない場合、3つのアクションの1つを実行できます。
(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は、単にバケットを「完全」に設定するのではなく、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:
残念ながら、できないことは、トークンバーストの仕様をランダムサイズのパケットに適合させることです。したがって、可変長さのパケット環境のトークンバケットは、常に理論的現実からある程度の違いがあります。これは、ATM保証フレームレート（GFR）サービスカテゴリの仕様とフレームリレーでも観察されています。多くの観察が行われる場合があります：
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, 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.
o 操作的には、トークンバケットメーターは、漏れやすいバケットシェーパーまたはシリアルラインによって形作られたトラフィックにとって合理的です。ただし、インターネット内のトラフィックがそのように形成されることはめったにありません。TCPはトラフィックに形作られませんが、むしろ長距離ACKクロック動作に依存して、特定のレートを近似し、スロースタート中にトラフィックバーストを明示的に送信します。迅速な回復。[VIC]などのビデオオンイップの実装では、漏れやすいバケットシェーパーが利用可能になる場合がありますが、多くの場合、適切なインターフェイスでの送信のためにコーデックの出力を単純に使用できます。その結果、これらの各ケースでは、トークンバケットメーターが短期的にトラフィックを拒否する可能性があります（単一のトークン間隔）。適切に動作する。これを回避するには、トークン間隔b/rは、問題のセッションのRTTを近似または超過する必要があり、バーストサイズのBは、オリジネーターが送信する最大のバーストに対応する必要があります。
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 上記の逆は、厳格なトークンバケットがゆるいパケットがそうするときに大きなパケットを受け入れないことがあるということです。したがって、このような厳格なトークンバケットが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ビットであるため、この状況はゆるいトークンバケットで発生することはできません。定義により、ゆるいトークンバケットを1 MTUを超えるバーストサイズに制限します。
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.
o [srtcm]と[trtcm]で指定されている厳格なトークンバケット仕様、およびゆるいものの両方は、持続的なアンダーランの影響を受けます。これらは、最大バーストサイズまで、時間の経過とともにバースト容量を蓄積します。最大バーストサイズが送信されるパケットのサイズで正確にサイズであると仮定します。これは、「最も厳格な」トークンバケットの実装と呼ばれる可能性があります。そのような場合、1つのパケットが受け入れられると、トークンの深さがゼロになり、再び蓄積し始めます。次のパケットが後でトークン間隔よりも早く受信された場合、受け入れられません。次のパケットが正確に時間通りに到着すると、受け入れられ、トークンの深さが再びゼロに設定されます。ただし、後で到着した場合、トークンの蓄積は最大バーストサイズで締めくくられているため停止します。バケツがいっぱいになる間の間隔とパケットの実際の到着の間に、新しいトークンは追加されません。その結果、ネットワーク内の複数のホップに蓄積するジッターは、アルゴリズムに対して共謀して、実際の受け入れ率を減らします。したがって、通常、ジッターの一部を吸収し、目的の理論的速度に沿って実用的な受け入れ速度をより多く吸収するために、最大トークンバケットサイズをMTUよりもやや大きく設定することは理にかなっています。
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）でトークンバケットを定義します。B（0）= Bであると仮定します。その後、パケットの到着がない任意の間隔の後、バケットはすでにトークンでいっぱいであるため、B（t）は変わりません。
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 'に到着すると仮定します。バケット占有率はまだBです。その場合、l <= 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:
次のパケットが到着する前に間隔Delta_t = t -t 'が経過すると仮定します。サイズl' <= Bです。この直前に、時間t-では、バケツが間隔でdelta_t*rトークンを蓄積し、最大まで最大まで蓄積しました。bトークンのように：
b(t-) = min{ 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" }
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".
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
Yoram Bernet Microsoft One Microsoft Way Redmond、WA 98052
Phone: +1 425 936 9568
EMail: 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
Daniel Grossman Motorola Inc. 20 Cabot Blvd. Mansfield, MA 02048
Daniel Grossman Motorola Inc. 20 Cabot Blvd.マンスフィールド、マサチューセッツ州02048
Phone: +1 508 261 5312
EMail: dan@dma.isg.mot.com
Andrew Smith (editor) Harbour Networks Jiuling Building 21 North Xisanhuan Ave. Beijing, 100089 PRC
アンドリュー・スミス（編集者）ハーバーネットワークジューリングビル21ノースXisanhuan Ave. Beijing、100089 PRC
Fax: +1 415 345 1827
EMail: ah_smith@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。