RFC3290 日本語訳
3290 An Informal Management Model for Diffserv Routers. Y. Bernet, S.Blake, D. Grossman, A. Smith. May 2002. (Format: TXT=129443 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Bernet
Request for Comments: 3290 Microsoft
Category: Informational S. Blake
Ericsson
D. Grossman
Motorola
A. Smith
Harbour Networks
May 2002
Bernetがコメントのために要求するワーキンググループY.をネットワークでつないでください: 3290年のマイクロソフトカテゴリ: 情報のS.のD.グロースマンモトローラA.スミスブレークエリクソン港は2002年5月をネットワークでつなぎます。
An Informal Management Model for Diffserv Routers
Diffservルータのための非公式のマネジメント・モデル
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントはそれらの管理と構成における使用のためにDifferentiated Services(Diffserv)ルータの非公式のマネジメント・モデルを提案します。 このモデルは機能的なdatapath要素(メーター、動作、マークしていて、絶対の低下が数えられて、例えば、クラシファイアが多重送信して)、アルゴリズムの点滴器、待ち行列、およびスケジューラを定義します。 それはこれらの要素とそれらがトラフィック調節の範囲がわかるためにどうインタコネクトされることができるように可能な設定パラメータとDiffserv Architectureで説明された1ホップあたりの振舞い(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
1つの序論… 3 2用語集… 4 3概念モデル… 7 Diffservルータの3.1のコンポーネント… 7 3.1 .1Datapath… 7 3.1 .2構成と管理は連結します… 9 3.1 .3の任意のQoSエージェントモジュール… 10 3.2 Diffservはイングレスと出口で機能します… 10 3.3 形成して、取り締まります。 12 モデルの3.4の階層的な視点… 12 4つのクラシファイア… 13
Bernet, et. al. Informational [Page 1] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[1ページ]のRFC3290Diffserv
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
4.1定義… 13 4.1 .1 フィルターにかけます。 15 4.1 .2 フィルタを重ね合わせます… 15 4.2の例… 16 4.2 .1の振舞いの集合(Ba)クラシファイア… 16 4.2 .2マルチ分野(mf)クラシファイア… 17 4.2 .3自由形式クラシファイア… 17 4.2 他の.4の可能なクラシファイア… 18 5メーター… 19 5.1の例… 20 5.1 .1 レートメーターを平均してください… 20 5.1 .2の指数の荷重している移動平均線(EWMA)は計量します… 21 5.1 2パラメタの.3トークンバケットメーター… 21 5.1 .4マルチステージトークンバケットメーター… 22 5.1 ヌル.5個のメーター… 23 6 Action Elements… 23 6.1DSCPマーカー… 24 6.2の絶対点滴器… 24 6.3マルチプレクサー… 25 6.4 反対してください… 25 6.5 ヌル動作… 25 7 Elementsを列に並ばせます… 25 7.1待ち合わせモデル… 26 7.1 .1先入れ先出し法待ち行列… 27 7.1 .2スケジューラ… 28 7.1 .3のアルゴリズムの点滴器… 30 7.2 トラフィックの中で負荷を共有するのは列を作りを使用することで流れます… 33 7.2 .1負荷分割法… 34 7.2 .2 トラフィック優先権… 35 8 トラフィック調節は(TCBs)を妨げます… 35 8.1Tcb… 36 8.1 Queuingのための.1のブロック… 37 8.2 例のTCB… 37 8.3 複数の顧客をサポートする例のTCB… 42 Microflowベースのサービスをサポートする8.4TCBs… 44 8.5はTCBsをどっと落させました… 47 9 セキュリティ問題… 47 10の承認… 47 11の参照箇所… 47 トークンバケツと水漏れするバケツの付録A.議論… 50人の作者のアドレス… 55 完全な著作権宣言文… 56
Bernet, et. al. Informational [Page 2] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[2ページ]のRFC3290Diffserv
1. Introduction
1. 序論
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).
差別化されたServices(Diffserv)[DSARCH]はネットワークサービスプロバイダーが異種のネットワークサービスの質(QoS)目的があるサービスを異なった顧客と彼らのトラフィックストリームに提供できる1セットの技術です。このドキュメントは[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ネットワークの前提によるネットワークのコアの中のルータが異なったトラフィックストリームで1ホップあたりの異なった振舞い(PHBs)を使用することでそれらを進めることによってパケットを扱うということです。 適用されるべき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.
そのような体系の利点は多くのトラフィックストリームを少ない数の振舞い集合(BA)の1つまで集めることができるということです、その結果、処理と関連ストレージを簡素化します。集合は、ルータに同じPHBを使用することでそれぞれ進められます。 さらに、各パケットを必要としますが、QoSがパケットごとのベースに呼び出されるのでDiffservネットワークのコアで必要でない他のどんな関連する処理はDSCPでも運ばれるもの以外に、合図してはいけません。
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アーキテクチャはネットワークで配布することができたさまざまな可能なサービスを可能にします。 これらのサービスはService Level Specificationの形でDiffservネットワークの縁の顧客に反映されます(SLS--[NEWTERMS]を見てください)。 このドキュメントの範囲の外にそのようなサービスのさらなる議論がありますが([PDBDEF]を見てください)、これらのサービスを提供する能力は連携方法で支給に使用されて、1セットの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
このドキュメントは抑制するか、または実装代替手段を書き取るどんな方法でも意図しません。Diffservルータ。 ルータimplementersがそれらの実装における多くの可変性を示すと予想されます。 implementersができるという範囲に
Bernet, et. al. Informational [Page 3] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[3ページ]のRFC3290Diffserv
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ルータを取り入れるネットワークを、構成して、より容易に対処できるでしょう。
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ルータの基本のハイレベルのブロックについて説明することによって、始まります。 それで、モデルで使用される概念がわかります、Classifiersなどの低レベルである機能的なdatapath要素を使用するこれらのブロック階層的なマネジメント・モデルを含んでいて、Actions、Queues。
o Section 4 describes Classifier elements.
o セクション4はClassifier要素について説明します。
o Section 5 discusses Meter elements.
o セクション5はMeter要素について論じます。
o Section 6 discusses Action elements.
o セクション6はAction要素について論じます。
o Section 7 discusses the basic queuing elements of Algorithmic
Droppers, Queues, and Schedulers and their functional behaviors
(e.g., traffic shaping).
o セクション7はAlgorithmicドロッパーズ、Queues、およびSchedulersの基本的な列を作り要素と彼らの機能的な振舞い(例えば、トラフィック形成)について論じます。
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は管理目的の役に立つTraffic Conditioning Blocks(TCBs)と呼ばれるモジュールを築き上げるためにどう低レベルである要素を結合できるかを示しています。
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アーキテクチャの中でアルゴリズムがこのモデルで使用したトークンバケツと水漏れするバケツの簡潔な議論とトークンバケツの使用の実用的な影響のいくつかを制限します。
2. Glossary
2. 用語集
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
このドキュメントは[DSARCH]で定義される用語を使用します。 また、IETFのこの用語に対する現在の進行中の仕事があります、そして、その仕事からここに提供された定義のいくつかを取ります。 いくつか
Bernet, et. al. Informational [Page 4] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[4ページ]のRFC3290Diffserv
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.
これらから他の諸条件では、参照は追加詳細を明らかにするために再びここで定義されます、このドキュメントに特定のいくつかの新学期と共に。
Absolute A functional datapath element which simply discards all Dropper packets arriving at its input.
単に入力に到達するすべてのDropperパケットを捨てる絶対A機能的なdatapath要素。
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.
アルゴリズムのA機能的なdatapath要素、どれ、選択的に、Dropperは捨てるアルゴリズムに基づいて入力に到達するパケットを捨てるか。 それで、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.
合わせていて非合っているパケットを選択するフィルタから成るクラシファイアのA機能的なdatapath要素。 この選択に基づいて、ルータの中で適切なdatapathに沿ってパケットを進めます。 したがって、クラシファイアはただ一つの入って来るトラフィックストリームを複数の外向的なストリームに分けます。
Counter A functional datapath element which updates a packet
counter and also an octet counter for every
packet that passes through it.
それを通り抜けるあらゆるパケットのためにパケットカウンタと八重奏カウンタもアップデートするA機能的なdatapath要素を打ち返してください。
Datapath A conceptual path taken by packets with particular
characteristics through a Diffserv router. Decisions
as to the path taken by a packet are made by functional
datapath elements such as Classifiers and Meters.
Diffservルータを通して特定の特性がある状態でパケットによって取られたDatapathのA概念的な経路。 ClassifiersやMetersなどの機能的なdatapath要素でパケットによって取られた経路に関する決定をします。
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.
パケットのヘッダーか他のデータの内容、パケットに関連している暗黙の、または、派生している属性の上で仮面のワイルドカード、接頭語、範囲、そして/または、完全な一致状態のAセットをフィルターにかけてください。 各状態が満たされている場合にだけ、フィルタは合っていると言われます。
Functional A basic building block of the conceptual router. Datapath Typical elements are Classifiers, Meters, Actions, Element Algorithmic Droppers, Queues and Schedulers.
概念的なルータの機能的なA基本的なブロック。 Datapath Typical要素は、Classifiersと、Metersと、Actionsと、Element Algorithmicドロッパーズと、Queuesと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)トラフィックを合併するマルチプレクサーのA機能的なdatapath要素がただ一つのトラフィックストリーム(datapath)に(datapaths)を流します。
Bernet, et. al. Informational [Page 5] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[5ページ]のRFC3290Diffserv
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.
出力ストリームをconformantにするようにそれらを時のプロフィールに対してデータ・パケットの到着を比較して、進めるか、遅らせるか、または下げるプロセスをプロフィールまで取り締まります。
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.
トラフィックに属すパケットのトランスミッションを調節する機能的なdatapath要素BlockのA組み合わせを列に並ばせるのは、それらの注文を流して、決定します、ことによると一時それらを保存するか、またはそれらを捨てて。
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.
どれが列を作るかを決定する次に修理する待ち行列のセットアルゴリズムのAnアルゴリズムの計画をします。 これは待ち行列の相対的な優先権に基づくかもしれません、荷重している公正な帯域幅共有方針かある他の方針で。 そのようなアルゴリズムは、仕事を保存しているか、または仕事を非保存しているかもしれません。
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.
パラメタとそれらの値のサービスレベルAセット、どれ、Specificationは(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.
多くのConditioningの機能的なdatapath要素のトラフィックのA論理的なdatapath実体の成ることはBlock(TCB)のそのような方法で特定のセットのトラフィック調節機能を入って来るトラフィックストリームに実行するほど内部連絡されました。 1つの入力と1回以上の出力がある実体と管理パラメータのセットとしてTCBを考えることができます。
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)
Aが設定したパラメタとそれらの値のトラフィック、どれ、Conditioningは1セットのクラシファイア規則とトラフィックSpecificationプロフィールを一緒に、指定するか。 TCSはSLSの不可欠の要素です。 (TCS)
Bernet, et. al. Informational [Page 6] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[6ページ]のRFC3290Diffserv
Work- A property of a scheduling algorithm such that it
conserving services a packet, if one is available, at every
transmission opportunity.
スケジューリングアルゴリズムの特性を扱ってください。保存して、1つがあらゆるトランスミッションの機会で利用可能であるならパケットを調整するそのようなもの。
3. Conceptual Model
3. 概念モデル
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コアルータがこれらのコンポーネントの部分集合だけが必要でありそうであることを: ここに提示されたモデルがDiffserv縁とコアルータの両方に関するケースをカバーすることを意図します。
3.1. Components of a Diffserv Router
3.1. Diffservルータのコンポーネント
The conceptual model includes abstract definitions for the following:
概念モデルは以下のための抽象的な定義を入れます:
o Traffic Classification elements.
o トラフィックClassification要素。
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 Traffic Conditioning Blocks(TCBs)として知られているよりハイレベルのブロックへの上の機能的なdatapath要素のある組み合わせ。
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ルータに送るとどんな特定のパケットも経験する振舞いを条件として、列に並ばせるトラフィックについて説明する機能的なdatapath要素の接続指示された非循環のグラフ(DAG)の形にあります。 図1はDiffservルータの主要な機能ブロックを例証します。
3.1.1. Datapath
3.1.1. Datapath
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
イングレスインタフェース、ルーティングコア、および出口のインタフェースはダイヤグラムのセンターで例証されます。 実際のルータ実装には、インタフェースがルーティングコアでインタコネクトしたイングレスと出口の特殊活字の数字があるかもしれません。 ルーティング炉心構成要素はルータの正常なルーティングの抽象化として機能します。
Bernet, et. al. Informational [Page 7] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[7ページ]のRFC3290Diffserv
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などのパケット分野の使用を伴うのが、可能ですが、このモデルの範囲の外にこれはあります)。 特定のルータの切り換え骨組み/バックプレーンの実際の列を作り遅れとパケット損失の振舞いはルーティングコアによってモデル化されません。 これらは、後で説明された機能的なdatapath要素を使用することでモデル化されるべきです。 無限の帯域幅としてこのモデルのルーティングコアを考えることができます、インタフェースの間のゼロ遅延内部連絡--積みすぎられるとコアの振舞いのような特性が、それの周りでモデル化される(例えば、あまりに多くのトラフィックがいつ出口のインタフェースのコアの向こう側に指示されますか)列を作り要素に映し出される必要があって、どこかに過剰を下げられなければならないか、または列に並ばせなければなりません: これらの機能を実行する要素にかかわったインタフェースの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トラフィックが調節と1ホップあたり振舞い[DSARCH]であるとサポートする機能的なdatapath要素(例えば、Classifiers、Queuing要素)です。 これらは、Diffservルータを包括する基本要素であり、このモデルの焦点です。
Bernet, et. al. Informational [Page 8] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[8ページ]のRFC3290Diffserv
+---------------+
| 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
+---------------+ | Diffserv| 管理| 構成| <、-、-、--+-->| 管理|------------------+ SNMP| | インタフェース| | 巡査| +---------------+ | など | | | | | | | vに対して| +-------------+ +-------------+ | | イングレスi/f| +---------+ | 出口i/f| -------->| 分類| -->、| ルーティング| -->、| 分類|---->データ| | 計量してください。| | コア| | メーター|中で出ているデータ| | 動作| +---------+ | 動作| | | 列を作ります。| | 列を作ります。| | +-------------+ +-------------+ | ^ ^ | | | | | | | +------------+ | +-->| QOSエージェント| | -------->| (任意)です。 |---------------------+ QOS|(例えば、RSVP)| cntl+------------+ msgs
Figure 1: Diffserv Router Major Functional Blocks
図1: Diffservルータ主要な機能ブロック
3.1.2. Configuration and Management Interface
3.1.2. 構成と管理は連結します。
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サービスレベルで運ばれたトラフィックに関する統計を含んでいます。 会計目的追跡承諾に、これらの統計は顧客と交渉されたTraffic Conditioning Specifications(TCSs)に重要であるかもしれません。 食糧を供給されたパラメタは、ActionsとQueuing要素のためのClassifiersのための主としてTCSパラメタと、Metersと関連PHB設定パラメータです。 ネットワーク管理者はSNMPかCOPSなどの1つ以上の管理プロトコルの近く、または、連続の端末かtelnetコンソールなどの他のルータ構成ツールを通してDiffserv構成と管理インタフェースと対話します。
Specific policy rules and goals governing the Diffserv behavior of a router are presumed to be installed by policy management mechanisms. However, Diffserv routers are always subject to implementation limits
特定保険証券規則とルータのDiffservの振舞いを治める目標があえて政策管理メカニズムによってインストールされます。しかしながら、Diffservルータはいつも実装限界を受けることがあります。
Bernet, et. al. Informational [Page 9] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[9ページ]のRFC3290Diffserv
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.
ルータで首尾よく実施されることができる政策の種類を見ます。 そのような実装能力の外部の報告はこのドキュメントのために範囲から考えられます。
3.1.3. Optional QoS Agent Module
3.1.3. 任意のQoSエージェントモジュール
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要件[2EのE](例えば、RSVPプロトコルを使用する)のmicroflowか流れ単位で集めているシグナリングのどちらかに、詮索するか、または参加するかもしれません。 例えば、RSVPメッセージの詮索は、実際にRSVPプロトコル同輩として参加しないでトラフィックを分類する方法を学ぶのに使用されるかもしれません。 Diffservルータが、入場コントロールの手段をDiffservベースのサービスに提供するためにRSVP予約の要請を拒絶するか、認めるかもしれません、またはそれらは、Diffservネットワークで流れ集合のために変化に食糧を供給しながら、引き金となるこれらの要求を使用するかもしれません。 流れ集合がこのような関係においてはDiffserv BAに同等であるかもしれませんか、またはそれはきめ細かに粒状であるかもしれません、マルチ分野(MF)クラシファイア[DSARCH]を当てにして。 そのようなルータの概念モデルが[INTSERV]で説明されるようにIntegrated Services Modelを実装することに注意してください、データ飛行機で分類されて、条件とするデータに制御飛行機コントロールを適用して、[2EのE]で説明されるように。
Note that a QoS Agent component of a Diffserv router, if present, might be active only in the control plane and not in the data plane. In this scenario, RSVP could be used merely to signal reservation state without installing any actual reservations in the data plane of the Diffserv router: the data plane could still act purely on Diffserv DSCPs and provide PHBs for handling data traffic without the normal per-microflow handling expected to support some Intserv services.
存在しているならDiffservルータのQoSエージェントの部品がデータ飛行機でアクティブであるのではなく、制御飛行機だけでアクティブであるかもしれないことに注意してください。 このシナリオでは、単にDiffservルータのデータ飛行機にどんな実際の予約もインストールしないで予約状態に合図するのにRSVPを使用できました: データ飛行機は、いくつかのIntservサービスをサポートすると予想された1microflowあたりの通常の取り扱いなしで、まだ純粋にDiffserv DSCPsに影響していて、取り扱いデータ通信量にPHBsを提供するかもしれません。
3.2. Diffserv Functions at Ingress and Egress
3.2. イングレスと出口でのDiffserv機能
This document focuses on the Diffserv-specific components of the router. Figure 2 shows a high-level view of ingress and egress interfaces of a router. The diagram illustrates two Diffserv router interfaces, each having a set of ingress and a set of egress elements. It shows classification, metering, action and queuing functions which might be instantiated at each interface's ingress and egress.
このドキュメントはルータのDiffserv特有のコンポーネントに焦点を合わせます。 図2はイングレスのハイレベルの眺めとルータの出口のインタフェースを示しています。 それぞれ1セットのイングレスと1セットの出口要素を持っていて、ダイヤグラムは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
図2の簡単なダイヤグラムは、与えられたインタフェースでトラフィックで行われるべきDiffserv機能のセットが他のすべてのインタフェースでそれらの機能から独立していると仮定します。 いくつかのアーキテクチャがDiffserv機能が複数のインタフェース(例えば、プロセッサと横切ってルーティングコアを進める前に同じ系列カードの上の複数のインタフェースを扱うリソースをバッファリングする)の中で共有されるかもしれないところにあります。 本書では提示されたモデルはそのような場合を扱うために容易に広げられるかもしれません。 しかしながら、この話題はそうではありません。
Bernet, et. al. Informational [Page 10] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[10ページ]のRFC3290Diffserv
treated further here as it leads to excessive complexity in the explanation of the concepts.
概念に関する説明における過度の複雑さに通じて、さらにここに扱われます。
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 |
+-------------+ +-------------+
インタフェースB+を連結してください。-------------+ +---------+ +-------------+ | イングレス: | | | | 出口: | | 分類| | | | 分類| --->| 計量してください。|、-、-、--、>| |、-、-、--、>| 計量してください。|、-、--、>| 動作| | | | 動作| | 列を作ります。| | ルーティング| | 列を作ります。| +-------------+ | コア| +-------------+ | 出口: | | | | イングレス: | | 分類| | | | 分類| <--、| 計量してください。| <、-、-、--、| | <、-、-、--、| 計量してください。| <、-、--、| 動作| | | | 動作| | 列を作ります。| +---------+ | 列を作ります。| +-------------+ +-------------+
Figure 2. Traffic Conditioning and Queuing Elements
図2。 Elementsを条件として、列に並ばせる交通
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:
原則として、1つが完全に2ポートのルータ(LANか同様のメディアによって接続される)からネットワークを構成するなら、各ルータが各指示でdatapathでの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].
- 1セットの結果として起こる機能を実行してください、問題の分類と待ち行列に適切な低下方針を適用して、恐らくさらに、Differentiated Services Code Point(DSCP)[DSFIELD]を交通に付けるのを含んでいて。
- Enqueue the traffic for output in the appropriate queue. The
scheduling of output from this queue may lead to shaping of the
traffic or may simply cause it to be forwarded with some minimum
rate or maximum latency assurance.
- 適切な待ち行列における出力のための交通を待ち行列に入れてください。 この待ち行列からの出力のスケジューリングで、交通を形成するのに通じるか、または何らかの最低料率か最大の潜在保証と共にそれを単に進めるかもしれません。
If the network is now built out of N-port routers, the expected behavior of the network should be identical. Therefore, this model must provide for essentially the same set of functions at the ingress as on the egress of a router's interfaces. The one point of difference in the model between ingress and the egress is that all traffic at the egress of an interface is queued, while traffic at the ingress to an interface is likely to be queued only for shaping
ネットワークが現在N-ポートルータから造られるなら、ネットワークの予想された振舞いは同じであるべきです。 したがって、このモデルはルータのインタフェースの出口のようにイングレスにおける本質的には同じ関数群に備えなければなりません。 イングレスと出口の間のモデルの1ポイントの違いはインタフェースの出口のすべての交通が列に並ばせられるということです、インタフェースへのイングレスにおける交通が形成するためだけに列に並ばせられそうですが
Bernet, et. al. Informational [Page 11] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[11ページ]のRFC3290Diffserv
purposes, if at all. Therefore, equivalent functional datapath elements may be modeled at both the ingress to and egress from an interface.
せいぜい目的。 したがって、同等な機能的なdatapath要素は両方でモデル化されるかもしれません。インタフェースからのイングレスと出口。
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.
それぞれのこれらの機能的なdatapath要素がイングレスと出口の両方で実行されるのが、義務的でないことに注意してください。 等しく、モデルはこれらの要素の複数のセットがイングレスにおいて、または、出口に連続的に平行に置かれるかもしれないのをさせます。 要素のアレンジメントは特定のルータの特定のインタフェースに関するサービス要件に依存しています。 イングレスと出口の両方でこれらの要素をモデル化することによって、特定のルータでこのようにそれらを実行しなければならないのは含意されません。 例えば、ルータは、インタフェース出口に列を作るすべての形成と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の動機を誘導する綱領から)。
3.3. Shaping and Policing
3.3. 形成と取り締まり
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ノードは形成を当てはまるかもしれません、1つの交通の流れがリソースのシェアよりDiffservネットワークから止まるのを防ぐためにそれらのTCSの領域を超えている流れを交通に取り締まる、そして/または、マークして。 このモデルでは、TC動作であると時々みなされたShapingは要素を列に並ばせる機能として扱われます--セクション7を見てください。 それらがしばしば密接に待ち行列に関連づけられるので、アルゴリズムのDroppingのテクニック(例えば、RED)は同様に扱われます。 取り締まりはAbsolute DropperとのMeterの連結として、または、SchedulerとのAlgorithmic Dropperの連結としてモデル化されます。 これらの要素はTCSを超えているパケットを捨てるでしょう。
3.4. Hierarchical View of the Model
3.4. モデルの階層的な視点
From a device-level configuration management perspective, the following hierarchy exists:
装置レベル構成管理見解から、以下の階層構造は存在しています:
Bernet, et. al. Informational [Page 12] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[12ページ]のRFC3290Diffserv
At the lowest level considered here, there are individual
functional datapath elements, each with their own configuration
parameters and management counters and flags.
ここで考えられた中で最も低いレベルに、個々の機能的なdatapath要素があります、それぞれそれら自身の設定パラメータ、管理カウンタ、および旗で。
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でインタコネクトされたこれらの機能的なdatapath要素の組分けを管理します。 これらの機能的なdatapath要素はいくつかの必要なネットワーク政策を実施するのに使用される自己充足的なTCBsで組織化されます(セクション8を見てください)。 1TCBsが各インタフェースのイングレスか出口に例示されるかもしれません。 それらは連続的に前のTCBの複数の出力での平行な構成で接続されるかもしれません。 1つの入力と1回以上の出力(データ経路の)がある「ブラックボックス」としてTCBを考えることができます。 各インタフェースには異なった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.
ここで考えられた最上のレベルでは、ネットワーク管理者はインタフェースを管理します。 各インタフェースには、イングレスとそれぞれのこれらが1TCBsとして言い表されている出口の機能性があります。 階層構造のこのレベルは図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の中に他のワーキンググループで研究中であります。
4. Classifiers
4. クラシファイア
4.1. Definition
4.1. 定義
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論理的に別々の交通の流れを発生させます。 クラシファイアはフィルタと出力ストリームによってparameterizedされます。入力ストリームからのパケットはパケットのコンテンツを合わせるか、またはことによるとパケットに関連している他の属性に合っているフィルタによって様々な出力ストリームに分類されます。 異なったフィルタを使用している様々なタイプのクラシファイアが以下のセクションで説明されます。 出力が続く機能的なdatapath要素に接続するところで図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.
可能な限り簡単なClassifier要素は入力のときに適用されるすべてのパケットに合っているものです。 この場合、Classifier要素は、オプアートであるだけではなく、省略されるかもしれません。
Bernet, et. al. Informational [Page 13] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[13ページ]のRFC3290Diffserv
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.
私たちがClassifierの前のMultiplexor(セクション6.5を見る)に複数の交通の流れから入力を許させることに注意してください。例えば、複数のイングレスインタフェースから発する交通の流れが独身のClassifierを通して供給されるなら、インタフェース番号はClassifierによって使用されたパケット分類キーの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).
パケット属性に関する別の例はパケットの最も良い合っているルートに関連しているBGP共同体ストリングを表す整数であるかもしれません。 また、他の文脈上の情報はClassifierによって使用されるかもしれません(DSCPが存在しているかどうか決定するとき、特定のインタフェースがDiffservドメインか遺産IP TOSドメイン[DSARCH]に直面しているという例えば知識を使用できました)。
unclassified classified
traffic traffic
+------------+
| |--> match Filter1 --> OutputA
------->| classifier |--> match Filter2 --> OutputB
| |--> no match --> OutputC
+------------+
分類された交通交通+を非分類しました。------------+ | |-->マッチFilter1-->OutputA------->| クラシファイア|-->マッチFilter2-->OutputB| |--いいえが合っている>-->OutputC+------------+
Figure 3. An Example Classifier
図3。 例のクラシファイア
The following BA classifier separates traffic into one of three output streams based on matching filters:
フィルタを合わせることに基づいて以下のBAクラシファイアは3つの出力ストリームの1つに交通を切り離します:
Filter Matched Output Stream
-------------- ---------------
Filter1 A
Filter2 B
no match C
取り組んでいる出力ストリームをフィルターにかけてください。-------------- --------------- Filter1A Filter2Bノー、は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)
フィルタDSCP------ ------ Filter1 101010Filter2 111111Filter3******(ワイルドカード)
Bernet, et. al. Informational [Page 14] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[14ページ]のRFC3290Diffserv
4.1.1. Filters
4.1.1. フィルタ
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.
フィルタはパケットの分類キー(分類において、関連しているヘッダー値、コンテンツ、および属性)の成分値の1セットの状態から成ります。 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.
一般に、1セットの包含が強要する条件(接頭語、範囲)がマスクをかけた可能なコンポーネントとワイルドカードマッチがあります。 1セットの接頭語として範囲を表すことができて(より少ない効率で)、接頭語マッチがただともに仮面と範囲マッチの特別なケースであることに注意してください。
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
フィルタIPv4 Src Addr IPv4 Dest Addr TCP SrcPort TCP DestPort------ ------------- -------------- ----------- ------------ Filter4 172.31.8.1/32 172.31.3.X/24X5003
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ネットワークの適切な操作のための前提条件です。
4.1.2. Overlapping Filters
4.1.2. フィルタを重ね合わせます。
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
フィルタIPv4 Src Addr IPv4 Dest Addr------ ------------- -------------- Filter5 172.31.8.X/24X/0Filter6X/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
パケット含有、IP Dest Addr、172.31、.8、.1、IP Src Addr172.30.10.1、フィルタのこの組が唯一分類できないので、繋がりを壊すためにFilter5とFilter6の間で先行を確立しなければなりません。 この先行を確立しなければなりません。
Bernet, et. al. Informational [Page 15] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[15ページ]のRFC3290Diffserv
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.
ルータがこの特定の注文(例えば、報告された能力による)を達成できるのを知っているマネージャによる(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.
別の例として、人は、最初に、全くネットワークを使用するのからのあるアプリケーションを禁じたいか、またはDiffservが著しくない個々の交通の流れを分類したがっているかもしれません。 そして、それらのテストで分類されない交通はDSCPがないかどうか点検されるかもしれません。 「そして」という単語は、先行によって系列とこれを指定しなければならないのを含意します。
An unambiguous classifier requires that every possible classification key match at least one filter (possibly the wildcard default) and that any ambiguity between overlapping filters be resolved by precedence. Therefore, the classifiers on any given interface must be "complete" and will often include an "everything else" filter as the lowest precedence element in order for the result of classification to be deterministic. Note that this completeness is only required of the first classifier that incoming traffic will meet as it enters an interface - subsequent classifiers on an interface only need to handle the traffic that it is known that they will receive.
明白なクラシファイアは、あらゆる可能な分類キーが少なくとも1個のフィルタ(ことによるとワイルドカードデフォルト)に合って、フィルタを重ね合わせることの間のどんなあいまいさも先行で取り除かれているのを必要とします。 したがって、どんな与えられたインタフェースのクラシファイアも、「完全でなければならなく」、分類の結果が決定論的であるように最も低い先行要素としてしばしば「他の何もかも」フィルタを入れるでしょう。 インタフェースに入るとき、第1代入って来る交通が会うクラシファイアはこの完全性に要求されるだけです--インタフェースのその後のクラシファイアが、知られていた状態でそれがある交通を扱う必要があるだけであるという彼らが受け取るメモ。
This model of classifier operation makes the assumption that all filters of the same precedence be applied simultaneously. Whilst convenient from a modeling point-of-view, this may or may not be how the classifier is actually implemented - this assumption is not intended to dictate how the implementation actually handles this, merely to clearly define the required end result.
クラシファイア操作のこのモデルは同じ先行のすべてのフィルタが同時に適用されるという仮定をします。 モデル観点から便利である間、これはクラシファイアが実際にどう実行されるかということであるかもしれません--この仮定は、実現が実際にどうこれを扱うかを書き取って、単に明確に必要な結末を定義することを意図しません。
4.2. Examples
4.2. 例
4.2.1. Behavior Aggregate (BA) Classifier
4.2.1. 振舞いの集合(Ba)クラシファイア
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ビットのどんな部分集合も重要ではありません。
Bernet, et. al. Informational [Page 16] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[16ページ]のRFC3290Diffserv
The following defines a possible BA filter:
以下は可能なBAフィルタを定義します:
Filter8:
Type: BA
Value: 111000
Filter8: 以下をタイプしてください。 Ba値: 111000
4.2.2. Multi-Field (MF) Classifier
4.2.2. マルチ分野(mf)クラシファイア
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クラシファイアは、6に基づいてIPとTCPから分野を分類する6-tupleクラシファイアかUDPヘッダー(送付先アドレス、ソースアドレス、IPプロトコル、ソース港、仕向港、およびDSCP)です。 MFクラシファイアは他のフィールドでMACなどのアドレス、VLANタグ、リンク層の交通類体、または他の上位層プロトコル分野を分類するかもしれません。
The following defines a possible MF filter:
以下は可能なMFフィルタを定義します:
Filter9:
Type: IPv4-6-tuple
IPv4DestAddrValue: 0.0.0.0
IPv4DestAddrMask: 0.0.0.0
IPv4SrcAddrValue: 172.31.8.0
IPv4SrcAddrMask: 255.255.255.0
IPv4DSCP: 28
IPv4Protocol: 6
IPv4DestL4PortMin: 0
IPv4DestL4PortMax: 65535
IPv4SrcL4PortMin: 20
IPv4SrcL4PortMax: 20
Filter9: 以下をタイプしてください。 IPv4-6-tuple IPv4DestAddrValue: 0.0.0.0 IPv4DestAddrMask: 0.0.0.0 IPv4SrcAddrValue: 172.31.8.0 IPv4SrcAddrMask: 255.255.255.0 IPv4DSCP: 28IPv4Protocol: 6IPv4DestL4PortMin: 0IPv4DestL4PortMax: 65535IPv4SrcL4PortMin: 20IPv4SrcL4PortMax: 20
A similar type of classifier can be defined for IPv6.
IPv6のために同様のタイプのクラシファイアを定義できます。
4.2.3. Free-form Classifier
4.2.3. 自由形式クラシファイア
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}:
Free-フォームクラシファイアはビット分野サイズ、オフセット(パケットのヘッドからの)、マスクでそれぞれ作られた1セットのユーザの定義可能な任意のフィルタで作られます:
Classifier2:
Filter12: OutputA
Filter13: OutputB
Default: OutputC
Classifier2: Filter12: OutputA Filter13: OutputBはデフォルトとします: OutputC
Bernet, et. al. Informational [Page 17] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[17ページ]のRFC3290Diffserv
Filter12:
Type: FreeForm
SizeBits: 3 (bits)
Offset: 16 (bytes)
Value: 100 (binary)
Mask: 101 (binary)
Filter12: 以下をタイプしてください。 自由形状SizeBits: 3 (ビット)は相殺されます: 16 (バイト) 値: 100の(2進)のマスク: 101 (2進)です。
Filter13:
Type: FreeForm
SizeBits: 12 (bits)
Offset: 16 (bytes)
Value: 100100000000 (binary)
Mask: 111111111111 (binary)
Filter13: 以下をタイプしてください。 自由形状SizeBits: 12 (ビット)は相殺されます: 16 (バイト) 値: 100100000000の(2進)のマスク: 111111111111 (2進)です。
Free-form filters can be combined into filter groups to form very powerful filters.
非常に強力なフィルタを形成するために自由形式フィルタをフィルタグループに結合できます。
4.2.4. Other Possible Classifiers
4.2.4. 他の可能なクラシファイア
Classification may also be performed based on information at the datalink layer below IP (e.g., VLAN or datalink-layer priority) or perhaps on the ingress or egress IP, logical or physical interface identifier (e.g., the incoming channel number on a channelized interface). A classifier that filters based on IEEE 802.1p Priority and on 802.1Q VLAN-ID might be represented as:
また、分類はデータリンク層の情報に基づいてイングレス、または、恐らくIP(例えば、VLANかデータリンク層の優先権)か出口IP、論理的であるか物理的なインタフェース識別子(例えば、channelizedインタフェースの入って来る論理機番)に実行されるかもしれません。 フィルタがIEEE 802.1p Priorityと、そして、802.1Q VLAN-IDに基礎づけたクラシファイアは以下として代理をされるかもしれません。
Classifier3:
Filter14 AND Filter15: OutputA
Default: OutputB
Classifier3: Filter14とFilter15: OutputAはデフォルトとします: OutputB
Filter14: -- priority 4 or 5
Type: Ieee8021pPriority
Value: 100 (binary)
Mask: 110 (binary)
Filter14: -- 優先権4か5Type: Ieee8021pPriority値: 100の(2進)のマスク: 110 (2進)です。
Filter15: -- VLAN 2304
Type: Ieee8021QVlan
Value: 100100000000 (binary)
Mask: 111111111111 (binary)
Filter15: -- VLAN2304はタイプします: Ieee8021QVlan値: 100100000000の(2進)のマスク: 111111111111 (2進)です。
Such classifiers may be the subject of other standards or may be proprietary to a router vendor but they are not discussed further here.
そのようなクラシファイアは、他の規格の対象であるかもしれないかルータ業者にとって、独占であるかもしれませんが、ここでさらにそれらについて議論しません。
Bernet, et. al. Informational [Page 18] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[18ページ]のRFC3290Diffserv
5. Meters
5. Meters
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ネットワーク内の提供者は、サービスのために顧客が交通を提出する時(すなわち、レート)のプロフィールに基づく顧客に対するサービスを提供するのを選ぶかもしれません。 この出来事では、1個のメーターは、適切な次のステージ動作要素を通して非従っているパケットを発送することによってリアルタイムの交通調節動作(例えば、マーク)の引き金となるのに使用されるかもしれません。 あるいはまた、また、MeterのCounter要素川下を使用することで従う、そして/または、非の従う交通を数えることによって、それはバンドの外のための支払いアプリケーションなどのデータ管理機能を集めるのを手伝うのに使用されるかもしれません。
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(四方八方に広げる)装置(1メーターの正面でマルチプレクサーを使用できますが)。 メーターは時のプロフィールと順応レベルによってparameterizedされます。それはそれぞれ計器出力に関連しています。 各出力を別の機能要素に関連づけることができます。
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.
1メーターのこのモデルが[DSARCH]で説明されたそれと若干異なることに注意してください。 その記述では、メーターは、datapath要素ではありませんが、ダイナミックにパケットの順応に基づく彼らの振舞いを調節するために交通の流れをモニターして、制御信号を動作要素に送るのに代わりに使用されます。 記述のこの違いは1メーターの関数を変えません。 図4は3つのレベルの順応を1個のメーターに入れます。
In some Diffserv examples (e.g., [AF-PHB]), three levels of conformance are discussed in terms of colors, with green representing conforming, yellow representing partially conforming and red representing non-conforming. These different conformance levels may be used to trigger different queuing, marking or dropping treatment later on in the processing. Other example meters use a binary notion of conformance; in the general case N levels of conformance can be supported. In general there is no constraint on the type of functional datapath element following a meter output, but care must be taken not to inadvertently configure a datapath that results in packet reordering that is not consistent with the requirements of the relevant PHB specification.
いくつかのDiffservの例(例えば、[AF-PHB])では、色で順応の3つのレベルについて議論します、緑色が従うこと、従うことを部分的に表す黄色、および非の従うことを表す赤を表していて。 これらの異なった順応レベルは、後で、処理で異なった列を作り、マークまたは低下処理の引き金となるのに使用されるかもしれません。 他の例のメーターは順応の2進の概念を使用します。 一般的な場合では、Nレベルの順応を支持できます。 一般に、メーター出力に続く機能的なdatapath要素のタイプの上に規制が全くありませんが、うっかり関連PHB仕様の要件と一致していないパケット再命令をもたらすdatapathを構成しないように注意しなければなりません。
Bernet, et. al. Informational [Page 19] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[19ページ]のRFC3290Diffserv
unmetered metered
traffic traffic
+---------+
| |--------> conformance A
--------->| meter |--------> conformance B
| |--------> conformance C
+---------+
計量された交通交通+を非計量しました。---------+ | |-------->順応A--------->| メーター|-------->順応B| |-------->順応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.
このモデルに従って、1メーターは、交通の流れを作るパケットがそれを通過するレートを測定して、何らかのセットの敷居にレートをたとえて、何らかの数の潜在的結果(2以上)を生みます: 小川がパケットが調べられる時にそのレベルに関連しているプロフィールのためのレート限界の中にあるように見えるなら、与えられたパケットはメーターのレベルへの"conformant"であると言われます。 プロフィール(そして、これがスケジューラ上流に置く関連要件)を計量する順応の、よりふくよかな議論をAppendix Aに提供します。
5.1. Examples
5.1. 例
The following are some examples of possible meters.
↓これは可能なメーターに関するいくつかの例です。
5.1.1. Average Rate Meter
5.1.1. 平均相場メーター
An example of a very simple meter is an average rate meter. This type of meter measures the average rate at which packets are submitted to it over a specified averaging time.
非常に簡単なメーターに関する例は平均相場メーターです。 このタイプのメーターはパケットが指定された平均した時間それに提出される平均相場を測定します。
An average rate profile may take the following form:
平均相場プロフィールは以下の形を取るかもしれません:
Meter1:
Type: AverageRate
Profile: Profile1
ConformingOutput: Queue1
NonConformingOutput: Counter1
Meter1: 以下をタイプしてください。 AverageRateは以下の輪郭を描きます。 Profile1 ConformingOutput: Queue1 NonConformingOutput: Counter1
Profile1:
Type: AverageRate
AverageRate: 120 kbps
Delta: 100 msec
Profile1: 以下をタイプしてください。 AverageRate AverageRate: 120キロビット毎秒デルタ: 100 msec
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
このプロフィールに対するMeter測定は絶えず時間T(現在)と時間Tの間で到着する総数を示すカウント、そして/または、パケットの累積しているバイト・カウントを維持するでしょう--100msec。 到着パケットがmsec、パケットがそうする最後の100で12kbitsの上にカウントを押さない限り、従うと考えられてください。 どんなパケット
Bernet, et. al. Informational [Page 20] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[20ページ]のRFC3290Diffserv
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.
12kbitsの上のカウントがそうするプッシュは非従うと考えられます。 したがって、このMeterは、パケットが2つの順応レベルの1つに相当すると考えます: そして、従うか非の従う、適切なその後の処理のためにそれらを送ります。
5.1.2. Exponential Weighted Moving Average (EWMA) Meter
5.1.2. 指数の荷重している移動平均線(EWMA)メーター
The EWMA form of Meter is easy to implement in hardware and can be parameterized as follows:
MeterのEWMAフォームを、ハードウェアで実行するのが簡単であり、以下の通りparameterizedされることができます:
avg_rate(t) = (1 - Gain) * avg_rate(t') + Gain * rate(t)
t = t' + Delta
'avg_レート(t)=(1--利得)*avg_レート(t')+利得*レート(t)t=t'+デルタ
For a packet arriving at time t:
時間tに到着するパケットのために:
if (avg_rate(t) > AverageRate)
non-conforming
else
conforming
(avg_レート(t)>AverageRate)非の従うことのほかの従うこと
"Gain" controls the time constant (e.g., frequency response) of what is essentially a simple IIR low-pass filter. "Rate(t)" measures the number of incoming bytes in a small fixed sampling interval, Delta. Any packet that arrives and pushes the average rate over a predefined rate AverageRate is deemed non-conforming. An EWMA Meter profile might look something like the following:
「利得」は本質的には簡単なIIRローパスフィルタであることに関する時定数(例えば、周波数特性)を制御します。 「レート(t)」は小さい固定標本抽出間隔、デルタにおける、入って来るバイトの数を測定します。 到着して、事前に定義されたレートAverageRateの上に平均相場を押すどんなパケットも非従うと考えられます。 EWMA Meterプロフィールは以下のように見えるかもしれません:
Meter2:
Type: ExpWeightedMovingAvg
Profile: Profile2
ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1
Meter2: 以下をタイプしてください。 ExpWeightedMovingAvgは以下の輪郭を描きます。 Profile2 ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper1
Profile2:
Type: ExpWeightedMovingAvg
AverageRate: 25 kbps
Delta: 10 usec
Gain: 1/16
Profile2: 以下をタイプしてください。 ExpWeightedMovingAvg AverageRate: 25キロビット毎秒デルタ: 10usec Gain: 1/16
5.1.3. Two-Parameter Token Bucket Meter
5.1.3. 2パラメタの象徴バケットメーター
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
より高性能のMeterは象徴バケツ(TB)プロフィールに順応を測定するかもしれません。 一般に、TBプロフィールで、2つのパラメタ、平均した象徴レート、R、および放出量、B. TB Metersはパケット対TBプロフィールによって指定された平均相場の到着率を比較します。 論理的に、象徴は平均のときにバケツの中に蓄積します。
Bernet, et. al. Informational [Page 21] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[21ページ]のRFC3290Diffserv
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:
レート、R、放出量、B.Whenである最大のクレジットまで長さ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].
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].
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.
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.
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.
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 two-parameter TB meter has exactly two possible conformance levels (conforming, non-conforming). Such a meter might appear as follows:
A two-parameter TB meter has exactly two possible conformance levels (conforming, non-conforming). Such a meter might appear as follows:
Meter3:
Type: SimpleTokenBucket
Profile: Profile3
ConformanceType: loose
ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1
Meter3: Type: SimpleTokenBucket Profile: Profile3 ConformanceType: loose ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper1
Profile3:
Type: SimpleTokenBucket
AverageRate: 200 kbps
BurstSize: 100 kbytes
Profile3: Type: SimpleTokenBucket AverageRate: 200 kbps BurstSize: 100 kbytes
5.1.4. Multi-Stage Token Bucket Meter
5.1.4. Multi-Stage Token Bucket Meter
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
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
Bernet, et. al. Informational [Page 22] RFC 3290 Diffserv Informal Management Model May 2002
Bernet, et. al. Informational [Page 22] RFC 3290 Diffserv Informal Management Model May 2002
these multiple-conformance-level meters can sometimes be implemented using an appropriate sequence of multiple two-parameter TB meters.
these multiple-conformance-level meters can sometimes be implemented using an appropriate sequence of multiple two-parameter TB meters.
A profile for a multi-stage TB meter with three levels of conformance might look as follows:
A profile for a multi-stage TB meter with three levels of conformance might look as follows:
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
Profile4: Type: SimpleTokenBucket AverageRate: 100 kbps BurstSize: 20 kbytes
Profile5:
Type: SimpleTokenBucket
AverageRate: 100 kbps
BurstSize: 100 kbytes
Profile5: Type: SimpleTokenBucket AverageRate: 100 kbps BurstSize: 100 kbytes
5.1.5. Null Meter
5.1.5. Null Meter
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.
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.
Meter5:
Type: NullMeter
Output: Queue1
Meter5: Type: NullMeter Output: Queue1
6. Action Elements
6. Action Elements
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:
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
- Marking
- Absolute Dropping
- Absolute Dropping
Bernet, et. al. Informational [Page 23] RFC 3290 Diffserv Informal Management Model May 2002
Bernet, et. al. Informational [Page 23] RFC 3290 Diffserv Informal Management Model May 2002
- Multiplexing
- Multiplexing
- Counting
- Counting
- Null action - do nothing
- Null action - do nothing
The corresponding action elements are described in the following sections.
The corresponding action elements are described in the following sections.
6.1. DSCP Marker
6.1. DSCP Marker
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 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 Markers for Diffserv are normally parameterized by a single parameter: the 6-bit DSCP to be marked in the packet header.
DSCP Markers for Diffserv are normally parameterized by a single parameter: the 6-bit DSCP to be marked in the packet header.
Marker1:
Type: DSCPMarker
Mark: 010010
Marker1: Type: DSCPMarker Mark: 010010
6.2. Absolute Dropper
6.2. Absolute Dropper
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.
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.
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.
Bernet, et. al. Informational [Page 24] RFC 3290 Diffserv Informal Management Model May 2002
Bernet, et. al. Informational [Page 24] RFC 3290 Diffserv Informal Management Model May 2002
6.3. Multiplexor
6.3. Multiplexor
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.
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.
Mux1:
Type: Multiplexor
Output: Queue2
Mux1: Type: Multiplexor Output: Queue2
6.4. Counter
6.4. Counter
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.
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.
Counter1:
Type: Counter
Output: Queue1
Counter1: Type: Counter Output: Queue1
6.5. Null Action
6.5. Null Action
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.
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.
Null1:
Type: Null
Output: Queue1
Null1: Type: Null Output: Queue1
7. Queuing Elements
7. Queuing Elements
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:
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:
Bernet, et. al. Informational [Page 25] RFC 3290 Diffserv Informal Management Model May 2002
Bernet, et. al. Informational [Page 25] RFC 3290 Diffserv Informal Management Model May 2002
- 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).
- 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).
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.
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.
7.1. Queuing Model
7.1. Queuing Model
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 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.
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.
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.
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.
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.
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.
Bernet, et. al. Informational [Page 26] RFC 3290 Diffserv Informal Management Model May 2002
Bernet, et. al. Informational [Page 26] RFC 3290 Diffserv Informal Management Model May 2002
7.1.1. FIFO Queue
7.1.1. FIFO Queue
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.
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.
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.
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.
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.
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.
A FIFO might be represented using the following parameters:
A FIFO might be represented using the following parameters:
Queue1:
Type: FIFO
Output: Scheduler1
Queue1: Type: FIFO Output: 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.
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.
Bernet, et. al. Informational [Page 27] RFC 3290 Diffserv Informal Management Model May 2002
Bernet, et. al. Informational [Page 27] RFC 3290 Diffserv Informal Management Model May 2002
7.1.2. Scheduler
7.1.2. Scheduler
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.
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.
The service discipline (also known as a scheduling algorithm) is an algorithm which might take any of the following as its input(s):
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) static parameters such as relative priority associated with each of the scheduler's inputs.
b) absolute token bucket parameters for maximum or minimum rates
associated with each of the scheduler's inputs.
b) absolute token bucket parameters for maximum or minimum rates associated with each of the scheduler's inputs.
c) parameters, such as packet length or DSCP, associated with the
packet currently present at its input.
c) parameters, such as packet length or DSCP, associated with the packet currently present at its input.
d) absolute time and/or local state.
d) absolute time and/or local state.
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.
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.
[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] 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:
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) 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.
Bernet, et. al. Informational [Page 28] RFC 3290 Diffserv Informal Management Model May 2002
Bernet, et. al. Informational [Page 28] RFC 3290 Diffserv Informal Management Model May 2002
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) a service priority, used only after the minimum rate profiles of all inputs have been satisfied, to decide how to allocate any remaining bandwidth.
c) a maximum service rate profile, for use only with a non-work-
conserving service discipline.
c) a maximum service rate profile, for use only with a non-work- conserving service discipline.
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.
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.
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].
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].
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.
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:
For example, a non-work-conserving scheduler, allocating spare bandwidth equally between all its inputs, might be represented using the following parameters:
Scheduler1:
Type: Scheduler2Input
Scheduler1: Type: Scheduler2Input
Input1:
MaxRateProfile: Profile1
MinRateProfile: Profile2
Priority: none
Input1: MaxRateProfile: Profile1 MinRateProfile: Profile2 Priority: none
Input2:
MaxRateProfile: Profile3
MinRateProfile: Profile4
Priority: none
Input2: MaxRateProfile: Profile3 MinRateProfile: Profile4 Priority: none
A work-conserving scheduler might be represented using the following parameters:
A work-conserving scheduler might be represented using the following parameters:
Bernet, et. al. Informational [Page 29] RFC 3290 Diffserv Informal Management Model May 2002
Bernet, et. al. Informational [Page 29] RFC 3290 Diffserv Informal Management Model May 2002
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: none Priority: 3
7.1.3. Algorithmic Dropper
7.1.3. Algorithmic Dropper
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.
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.
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.
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.
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:
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:
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) 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.
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) 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.
Bernet, et. al. Informational [Page 30] RFC 3290 Diffserv Informal Management Model May 2002
Bernet, et. al. Informational [Page 30] RFC 3290 Diffserv Informal Management Model May 2002
Other packet selection methods could be added to this model in the form of a different type of datapath element.
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.
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.
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.
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.
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).
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).
Bernet, et. al. Informational [Page 31] RFC 3290 Diffserv Informal Management Model May 2002
Bernet, et. al. Informational [Page 31] RFC 3290 Diffserv Informal Management Model May 2002
+------------------+ +-----------+
| +-------+ | 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
+------------------+ +-----------+ | +-------+ | 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
Figure 5. Example of Algorithmic Dropper from Tail of a Queue
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).
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).
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 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の例は、低下がだれの尾から行われることになっているか、そして、だれの深さの特性がこのAlgorithmic Dropperによって使用されるかを先入れ先出し法Queue要素に示します。 また、それは、深さスムージング機能がどこに含まれるかもしれないかを示します: スムージング機能は、このドキュメントの範囲の外にあって、ここで明らかにモデル化されません、とそれらが加えられるかもしれないところで私たちは単に示します。
RED, RED-on-In-and-Out (RIO) and Drop-on-threshold are examples of dropping algorithms. Tail-dropping and head-dropping are effected by the location of the Algorithmic Dropper element relative to the FIFO
RED、中の存在REDとアウト(RIO)、および敷居のDropは滴下アルゴリズムに関する例です。テール低下とヘッド低下はAlgorithmic Dropper要素の位置で先入れ先出し法に比例して作用します。
Bernet, et. al. Informational [Page 32] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[32ページ]のRFC3290Diffserv
Queue element. As an example, a dropper using a RIO algorithm might be represented using 2 Algorithmic Droppers with the following parameters:
要素を列に並ばせてください。 例、表された使用2Algorithmicが以下のパラメタをもっているドロッパーズであったかもしれないならRIOアルゴリズムを使用する点滴器として:
AlgorithmicDropper1: (for in-profile traffic)
Type: AlgorithmicDropper
Discipline: RED
Trigger: Internal
Output: Fifo1
MinThresh: Fifo1.Depth > 20 kbyte
MaxThresh: Fifo1.Depth > 30 kbyte
SampleWeight .002
MaxDropProb 1%
AlgorithmicDropper1: (プロフィールの交通への) 以下をタイプしてください。 AlgorithmicDropper規律: 赤い引き金: 内部の出力: Fifo1 MinThresh: Fifo1.Depthの>の20キロバイトのMaxThresh: Fifo1.Depthの>の30キロバイトのSampleWeight.002MaxDropProb1%
AlgorithmicDropper2: (for out-of-profile traffic)
Type: AlgorithmicDropper
Discipline: RED
Trigger: Internal
Output: Fifo1
MinThresh: Fifo1.Depth > 10 kbyte
MaxThresh: Fifo1.Depth > 20 kbyte
SampleWeight .002
MaxDropProb 2%
AlgorithmicDropper2: (プロフィールの外のための交通) 以下をタイプしてください。 AlgorithmicDropper規律: 赤い引き金: 内部の出力: Fifo1 MinThresh: Fifo1.Depthの>の10キロバイトのMaxThresh: Fifo1.Depthの>の20キロバイトのSampleWeight.002MaxDropProb2%
Another form of Algorithmic Dropper, a threshold-dropper, might be represented using the following parameters:
Algorithmic Dropperの別の書式(敷居点滴器)は以下のパラメタを使用することで表されるかもしれません:
AlgorithmicDropper3:
Type: AlgorithmicDropper
Discipline: Drop-on-threshold
Trigger: Fifo2.Depth > 20 kbyte
Output: Fifo1
AlgorithmicDropper3: 以下をタイプしてください。 AlgorithmicDropper規律: 敷居での低下引き金: Fifo2.Depthの>の20キロバイトの出力: Fifo1
7.2. Sharing load among traffic streams using queuing
7.2. 交通の流れの中で列を作りを使用することで負荷を共有します。
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.
待ち行列は多くの目的にDifferentiated Servicesで使用されます。 本質では、それらは単にそれが伝えられるまで交通を格納する場所です。 しかしながら、いくつかの待ち行列が列を作りシステムで一緒に使用されるとき、それらはまた、それを超えて与えられた交通の流れのために効果を達成できます。遅れの変化を制限するのに使用されるか、いくつかの流れが準予測できるファッション(負荷分割法)でリンクを共有することを許可するために、最高率(形成)を課すことができます、またはいくつかから遅れの変化を動かすのは他の流れに流れます。
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
交通形成はしばしば状態交通に使用されます、炸裂に到着するパケットがその後の川下のメーターに従ってこれで従うか、他のノードであると「整えられ」て、考えられるように。 aによって制御されたaの列を作りとして記述された[DSARCH]整形器要素では、どれを計量してくださいか。
Bernet, et. al. Informational [Page 33] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[33ページ]のRFC3290Diffserv
defines its temporal profile. However, this representation of a shaper differs substantially from typical shaper implementations.
時のプロフィールを定義します。 しかしながら、整形器のこの表現は実質的に典型的な整形器実現と異なっています。
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.
ここで説明されたモデルでは、整形器は、仕事を非保存するSchedulerを使用することによって、実感されます。 いくつかの実現が、唯一の目的が形成されている待ち行列を持っているのを選ぶかもしれません、他のものはリソースへのアクセスに関連している他のバッファリング、捨てる、およびスケジューリングと形成機能を統合するかもしれませんが。 整形器は、整形器の最大のサービス率プロフィールに構成された1個のメーターに従って非従うと考えられるパケットの出発を遅らせることによって、作動します。 パケットは従うことのようになるくらいの時間ほど早くないときに、出発する予定です。
7.2.1. Load Sharing
7.2.1. 負荷分割法
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.
負荷分割法は、待ち行列の伝統的な使用であり、フロイドとジェーコブソン[FJ95]によって理論的に探られました、1970年代以来それは通信網で使用中ですが。
[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]はそれぞれの1セットの交通のクラスに交通のクラスで予想どおりにインタフェースを分割するか、または最低料率を適用すると負荷分割法について議論します。(クラスは絶対下界として交通の流れが実現するレートかインタフェースが提供するレートの部分の上で測定されるかもしれません)。 先入れ先出し法のセットの中の何らかのフォームの荷重している待ち行列アルゴリズムがすなわち、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つ以上のパケットを放つかもしれないということです。 視点には平均した振舞いがある場合では、これは完全に許容できます。 交通がジターで非常に偏狭であり、多くの競争しているクラスがある場合では、これは望ましくない結果を持っているかもしれません。
Bernet, et. al. Informational [Page 34] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[34ページ]のRFC3290Diffserv
7.2.2. Traffic Priority
7.2.2. 交通優先権
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.
交通Prioritizationは負荷分割法の特別なケースです。(それでそれには、ある交通のクラスがジターとても偏狭であると考えられるので、交通プレゼントがそれであるならあって、時間に可能な最も前半その交通を送らなければなりません)。 拡大で、いくつかのプライオリティが定義されるかもしれません、それぞれの数人のクラスの交通がいずれも取引するa労働者階級の与えられた優先のサービスオーバーであるように。 それは[RFC791]で802.1p交通のクラス[802.1D]、および他の同様の技術について説明されるようにIP Precedenceの明白な実現です。
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.
優先権は本当のネットワークでしばしば乱用されます。 人々は高いビジネス優先度を持っている交通がこの処理に値すると思って、本番適用要件よりビジネス命令に関して話す傾向があります。 これは厳しい結果を持つことができます。 ネットワークは構成されました(ルーティング・プロトコル交通より高い優先度にビジネス批判的な交通をみなしました)、ネットワークの管理か制御システムの崩壊をもたらして。しかしながら、それには、それが絶対に確かであるExpedited Forwarding(EF)PHBに基づくサービスの正統の使用があるかもしれません、交通の流れがレートを乱用しないで、本当に、アプリケーションがジター取り扱いのこのタイプに値することができるくらい偏狭であるという全く可能な交通エントリー・ポイントを取り締まることのおかげで。 そのような崩壊を引き起こすネットワークの警察に監督されていないコア部分の中によく取り締まられたイングレスポイントがある場合でさえ予期していなかった交通輪の可能性がまだあることに注意してください。
8. Traffic Conditioning Blocks (TCBs)
8. 交通調節ブロック(TCBs)
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.
Classifier、Meter、Action、Algorithmic Dropper、Queue、および要素が上で説明したSchedulerの機能的なdatapathをTraffic Conditioning Blocks(TCBs)に結合できます。 TCBは特定の交通調節の機能性の定義を容易にするのに使用されるかもしれない1セットの機能的なdatapath要素の抽象化(例えばそれは異なった交通の流れか異なった顧客のために複数の回模写できるテンプレートにたとえられるかもしれない)です。 それには、データ経路の実現におけるどんなありそうな具現もありません: それは使用のための抽象化として管理ツールによって純粋に発明されます。
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
このモデルは定義上ゼロを含むTCBか、より多くのClassifier、Meter、Action、Algorithmic Dropper、Queue、およびScheduler要素に関してDiffservインタフェースの構成と管理について説明します。 これらの要素は言い表される方針に応じて任意にアレンジされますが、いつもここのオーダーでアレンジされます。 交通は分類されるかもしれません。 分類された交通は計量されるかもしれません。 クラシファイアとメーターの組み合わせで特定された交通の各流れで何らかのセットの機能をそれに実行するかもしれません、低下が支えていて
Bernet, et. al. Informational [Page 35] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[35ページ]のRFC3290Diffserv
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か物理インターフェースへの外で予定されるかもしれません。 要素を省略するか、どんなタイプのヌル要素も含んでいる、または同じタイプの複数の機能的なdatapath要素を連結するのが許されています。
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処理が、そのようなブロックを繰り返させる必要があるとき、これは複数のTCBsをどっと落させることによって、実行されます: 1TCBの出力は続く1つの入力を追い立てるかもしれません。 例えば、1セットのクラスの交通が1セットのレートに形成されますが、またクラスのグループの総生産量率をレートに制限しなければならないケースを考えてください。 人は、1セットのネットニュースが食べられると想像するかもしれません、それぞれある最高率、およびそれらの集合が図的に超えないかもしれない方針で。 これは滝の2TCBsによって単に達成されるかもしれません。 1番目は交通を別々の給送に分類します、そして、待ち行列は別々にそれぞれ食べられます。 現在、給送(または、それらの部分集合)を第2のTCBに入れます。(TCBはある最高率ですべての入力(これらのニュース給送)をただ一つの待ち行列に置きます)。 実現では、人は適切で(複雑)の重さの計画、または他の多くのアプローチがあるいくつかの文字通りの待ち行列、CBQまたはWFQシステムとしてこれを想像できました。 しかし、まるでそれらが別々のTCBsと共に文字通り実行されたかのように彼らには交通への同じ外部的に測定できる効果があるでしょう。
8.1. TCB
8.1. 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.
各ステージがpipelined要素から成る平行なdatapathsの1セットから成るかもしれないところ。
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.
通常、ClassifierかMeterが1:N要素です、そして、通常、Action、Algorithmic Dropper、またはQueueが1:1要素です、そして、Schedulerはaです。N:1 要素。 しかしながら、完全なTCBは1:1か1:N抽象的な要素をもたらすはずです。 または、それに注意してください、ファン-イン、四方八方に広がる、要素はこの分類学の重要な定義の特性ではありません。
Bernet, et. al. Informational [Page 36] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[36ページ]のRFC3290Diffserv
8.1.1. Building blocks for Queuing
8.1.1. Queuingのためのブロック
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の中のQueuingステージの中で要素の注文に適用されます: 同じタイプの要素は一度、平行またはシリーズより多く見えるかもしれません。 列を作りステージで通常、比較的多くの要素が連続的に平行でわずかになるでしょう。 繰り返しと再帰は支持された構造物(要素は非循環のグラフに配置される)ではありません。 要素の以下の相互接続は許されています:
- 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.
- Queueの入力は列を作りブロックの入力であるかもしれませんかそれがAlgorithmic Dropperの出力、または、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.
- Schedulerの各入力はQueueの出力、または、Algorithmic Dropperの出力、または、別の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).
- Algorithmic Dropperの入力は列を作りステージの最初の要素であるかもしれません、別のAlgorithmic Dropperの出力、または、それがQueue(ヘッド低下を示す)の出力に関連づけられるかもしれません。
- The output of the queuing block may be the output of a Queue,
an Algorithmic Dropper, or a Scheduler.
- 列を作りブロックの出力はQueue、Algorithmic Dropper、または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.
スケジューリング評価基準のすべてが会われた後にだけ連結されたSchedulersに食べさせるQueueのヘッドのパケットが調整されるように、Schedulersが連続的にそのようなものを操作するかもしれないことに特に注意してください。 例えば、EF交通の流れを運ぶQueueは、流れを最高率に形成するためにそして、仕事を保存するSchedulerによって最初に、仕事を保存しないSchedulerによって役立たれています。EF交通の流れを他の交通の流れに混ぜるかもしれない、あるいはまた、2Schedulersの間には、Queue、そして/または、点滴器があるかもしれません。
Note also that some non-sensical scenarios (e.g., a Queue preceding an Algorithmic Dropper, directly feeding into another Queue), are prohibited.
また、それにいくつか注意してください、無意味なシナリオ、(例えば、直接別のQueueに食べて、Algorithmic Dropperに先行するa Queue)は禁止されています。
8.2. An Example TCB
8.2. 例のTCB
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によって定義されるように取り扱いを指定するプロバイダー) プロバイダーのネットワークで。 協定は以下のフォームのものであるかもしれません:
Bernet, et. al. Informational [Page 37] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[37ページ]のRFC3290Diffserv
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.
DSCP PHBプロフィール処理---- --- ------- ---------------------- 001001 EF Profile4 Discard非の従うこと。 001100 プロフィールへのAF11 Profile5 Shape、完全でありテール低下。 非従っているDSCPに001000、完全でありテール低下をAF21 Profile3 Reマークしてください。001101他は、低下することでのApply REDのようでないなにもです。
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は、顧客がこのプロフィールを超えているならEF処理をどれがProfile4に従いながら残っていて捨てられるかためにとても長くするDSCP001001のためにマークされたパケットを提出するかもしれないと指定します。 捨てられたパケットはこの例で数えられます、恐らくより大きいSLSを買うように顧客を説得することにおけるプロバイダーの営業部による使用のために。 DSCP001100のためにマークされたパケットは推進の前にProfile5に形成されるでしょう。 非の従うパケットが001000のDSCPと共に述べることによって「格下げされている」状態で、DSCP001101のためにマークされたパケットはProfile3に計量されるでしょう。 この合意では、元々パケットのDSCP分野によって示された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.
この例のClassificationステージは独身のBAクラシファイアから成ります。 BAクラシファイアは、顧客によって要求されたDiffservサービスレベルに基づく交通を切り離すのに使用されます(それぞれの提出されたパケットのIPヘッダーでDSCPによって示されるように)。 私たちは3つのDSCPフィルタ値を例証します: C. A、B、および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.
DSCP001001と001101のための経路は計量ステージを含んでいますが、DSCP001100のための経路は直接Dropper1に続きます。 他のすべての交通が直接Dropper3に流れます。 クラシファイア出力AとC.に対応するパケットの各セットのための別々のメーターがあります。Eachメーターは特定のプロフィールを使用します、TCSで指定されるように、対応するDiffservサービスレベルのために。 この例のメーターはそれぞれ2つの順応レベルの1つを示します: 従うか非の従うこと。
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.
Meteringステージに続くのは、ブランチのいくつかでActionステージです。 Meter1で非従うと考えられるDSCP001001(クラシファイア出力A)のために提出されたパケットは、数えられて、従っているパケットはQueue1に通過されますが、捨てられます。 Meter2で非従うと考えられるDSCP001101(クラシファイア出力C)のために提出されたパケットを述べさせます、そして、次に、Dropper2/Queue3に通る前に従うのと非従っているパケットの両方を一緒に多重送信します。
Bernet, et. al. Informational [Page 38] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[38ページ]のRFC3290Diffserv
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.
Algorithmic Dropping、Queuing、およびSchedulingステージは以下の通り実現されて、例証されて、7は中で計算します。 図が例えば、Algorithmic Dropperが続くQueueの現状を感じることができる要素の間の暗黙のコントロールリンケージのいずれも示さないことに注意してください。
+-----+
| 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
+-----+ | A|---------------------------Queue1+への>。>|、|、|、| B|--+ +-----+ +-----+ | +-----+ | | | | | | Meter1+>| |、-、--、>|、|、|、|、|、|、|、| +-----+ +-----+ | Counter1 Absoluteは+を提出しました。-----+ | Dropper1交通| A|-----+ --------->| B|--------------------------------------AlgDropper1への>。| C|-----+ | X|--+ | +-----+ | | +-----+ +-----+ Classifier1| | | A|、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|A| (Ba) | +->|、|、| |--AlgDrop2への>。| | B|--+ +-----+ +->|B| | +-----+ | | | | +-----+ | Meter2+>| |-+ Mux1| | | | +-----+ | Marker1+-----------------------------------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からの従うDSCP001001パケットは直接Queue1に通過されます: ここに低下するための要件が全くなくて、これらのパケットをQueue1の深さからはみ出させるように計量に合うように、以下のSchedulerの構成に従った道は全くありません。 テール点滴器、以下の待ち行列の深さを制限するのに役立つAlgDropper1をDSCP001100のためにマークされたパケットを通り抜けなければなりません、Queue2: 完全な待ち行列に到達するパケットは捨てられるでしょう。 これは誤り事件である傾向があります: 顧客は明らかに同意されたプロフィールに執着していません。 同様に、オリジナルのDSCP001101の流れ(或るものはこの段階によって述べられたかもしれない)からのすべてのパケットがAlgDropper2とQueue3に通過されます。 他のすべてのDSCPsのためにマークされたパケットはREDのようなAlgorithmic DropperであるAlgDropper3に通過されます: Queue4の現在の深さのフィードバックに基づいて、この点滴器は入力ストリームからの待ち行列の深さを抑えることができるくらいのパケットを捨てるべきです。
Bernet, et. al. Informational [Page 39] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[39ページ]のRFC3290Diffserv
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つのQueue要素がScheduler要素Scheduler1が調整されます: 適切な優先権、そして/または、帯域幅シェアをそれぞれの入力に与えるためにこれを構成しなければなりません。 収縮したプロフィールに、適切な帯域幅の保証を入力AとCに与えます。 この流れの必要な形成を達成するためにそれが使用できる帯域幅(すなわち、仕事を保存しない規律)における限界を入力Bに与えます。 どんな限界も他の待ち行列より低い優先度以外の保証も入力Dに与えません、ベストエフォート型状態において、適切です。 そして、交通はただ一つの規則的な流れでSchedulerを出ます。
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
Classifier1: FilterA: Meter1 FilterB: Dropper1 FilterC: Meter2はデフォルトとします: Dropper3
from Meter1 +-----+
------------------------------->| |----+
| | |
+-----+ |
Queue1 |
| +-----+
from Classifier1 +-----+ +-----+ +->|A |
---------------->| |------->| |------>|B |------->
| | | | +--->|C | exiting
+-----+ +-----+ | +->|D | traffic
AlgDropper1 Queue2 | | +-----+
| | Scheduler1
from Mux1 +-----+ +-----+ | |
---------------->| |------->| |--+ |
| | | | |
+-----+ +-----+ |
AlgDropper2 Queue3 |
|
from Classifier1 +-----+ +-----+ |
---------------->| |------->| |----+
| | | |
+-----+ +-----+
AlgDropper3 Queue4
Meter1+から-----+ ------------------------------->| |----+ | | | +-----+ | Queue1| | +-----+ Classifier1+から-----+ +-----+ +->|A| ---------------->| |、-、-、-、-、-、--、>| |、-、-、-、-、--、>|B|、-、-、-、-、-、--、>|、|、|、| +--->|C| +を出ます。-----+ +-----+ | +->|D| 交通AlgDropper1 Queue2| | +-----+ | | Mux1+からのScheduler1-----+ +-----+ | | ---------------->| |、-、-、-、-、-、--、>| |--+ | | | | | | +-----+ +-----+ | AlgDropper2 Queue3| | Classifier1+から-----+ +-----+ | ---------------->| |、-、-、-、-、-、--、>| |----+ | | | | +-----+ +-----+ AlgDropper3 Queue4
Figure 7: An Example Traffic Conditioning Block (Part 2)
図7: 例の交通調節ブロック(第2部)
Bernet, et. al. Informational [Page 40] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[40ページ]のRFC3290Diffserv
Meter1:
Type: AverageRate
Profile: Profile4
ConformingOutput: Queue1
NonConformingOutput: Counter1
Meter1: 以下をタイプしてください。 AverageRateは以下の輪郭を描きます。 Profile4 ConformingOutput: 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: 以下をタイプしてください。 AlgorithmicDropper規律: 敷居での低下引き金: Queue2.Depthの>の10キロバイトの出力: Queue2
AlgDropper2:
Type: AlgorithmicDropper
Discipline: Drop-on-threshold
Trigger: Queue3.Depth > 20kbyte
Output: Queue3
AlgDropper2: 以下をタイプしてください。 AlgorithmicDropper規律: 敷居での低下引き金: Queue3.Depthの>の20キロバイトの出力: Queue3
AlgDropper3:
Type: AlgorithmicDropper
Discipline: RED93
Trigger: Internal
Output: Queue3
MinThresh: Queue3.Depth > 20 kbyte
MaxThresh: Queue3.Depth > 40 kbyte
<other RED parms too>
AlgDropper3: 以下をタイプしてください。 AlgorithmicDropper規律: RED93は以下の引き金となります。 内部の出力: Queue3 MinThresh: Queue3.Depthの>の20キロバイトのMaxThresh: Queue3.Depthの>の40キロバイトの<他のRED parms、も>。
Bernet, et. al. Informational [Page 41] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[41ページ]のRFC3290Diffserv
Queue1:
Type: FIFO
Output: Scheduler1.InputA
Queue1: 以下をタイプしてください。 先入れ先出し法出力: Scheduler1.InputA
Queue2:
Type: FIFO
Output: Scheduler1.InputB
Queue2: 以下をタイプしてください。 先入れ先出し法出力: Scheduler1.InputB
Queue3:
Type: FIFO
Output: Scheduler1.InputC
Queue3: 以下をタイプしてください。 先入れ先出し法出力: Scheduler1.InputC
Queue4:
Type: FIFO
Output: Scheduler1.InputD
Queue4: 以下をタイプしてください。 先入れ先出し法出力: 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
Scheduler1: 以下をタイプしてください。 Scheduler4Input InputA: MaxRateProfile: MinRateProfileのいずれも:でない Profile4優先権: 20InputB: MaxRateProfile: Profile5 MinRateProfile: Priorityのいずれも:でない 40InputC: MaxRateProfile: MinRateProfileのいずれも:でない Profile3優先権: 20InputD: MaxRateProfile: MinRateProfileのいずれも:でない Priorityのいずれも:でない 10
8.3. An Example TCB to Support Multiple Customers
8.3. 複数の顧客を支持する例のTCB
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.
インタフェースが顧客に捧げられるなら、プロバイダー/顧客TCSを実行するために上で説明されたTCBはイングレスインタフェースにインストールできます。 しかしながら、単一のインタフェースが複数の顧客の間で共有されると、上の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
構成は、複数の以下のインタフェースあたりの顧客のケースを支えるように容易に変更されます。 まず最初に、各顧客がその顧客と共にTCSを反映するように、TCBは定義されます: TCB1、定義されて、顧客1のためのTCBが上にあります。 同様の要素は作成されます。
Bernet, et. al. Informational [Page 42] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[42ページ]のRFC3290Diffserv
TCB2 and for TCB3 which reflect the agreements with customers 2 and 3 respectively. These 3 TCBs may or may not contain similar elements and parameters.
TCB2とそれぞれ顧客2と3との協定を反映するTCB3のために。 これらの3TCBsが同様の要素とパラメタを含むかもしれません。
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人の異なった顧客と交通を切り離すためにフロントエンドに加えられます。 これは新しいTCB、TCB4を形成します。(TCB4は図8で例証されます)。
A representation of this multi-customer TCB might be:
このマルチ顧客TCBの表現は以下の通りです。
TCB4:
TCB4:
Classifier4:
Filter1: to TCB1
Filter2: to TCB2
Filter3: to TCB3
No Match: AbsoluteDropper4
Classifier4: Filter1: TCB1 Filter2に: TCB2 Filter3に: TCB3へのマッチがありません: AbsoluteDropper4
AbsoluteDropper4:
Type: AbsoluteDropper
AbsoluteDropper4: 以下をタイプしてください。 AbsoluteDropper
TCB1:
(as defined above)
TCB1: (上で定義されるように)
TCB2:
(similar to TCB1, perhaps with different
elements or numeric parameters)
TCB2: (恐らくTCB1と、異なった要素か数値パラメタについて同様)です。
TCB3:
(similar to TCB1, perhaps with different
elements or numeric parameters)
TCB3: (恐らくTCB1と、異なった要素か数値パラメタについて同様)です。
and the filters, based on each customer's source MAC address, could be defined as follows:
そして、以下の通り各顧客のソースMACアドレスに基づくフィルタは定義できました:
Filter1:
Filter1:
submitted +-----+
traffic | A|--------> TCB1
--------->| B|--------> TCB2
| C|--------> TCB3
| X|------+ +-----+
+-----+ +-->| |
Classifier4 +-----+
AbsoluteDrop4
+を提出します。-----+ 交通| A|-------->TCB1--------->| B|-------->TCB2| C|-------->TCB3| X|------+ +-----+ +-----+ +-->|、| Classifier4+-----+ AbsoluteDrop4
Figure 8: An Example of a Multi-Customer TCB
エイト環: マルチ顧客TCBに関する例
Bernet, et. al. Informational [Page 43] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[43ページ]のRFC3290Diffserv
Type: MacAddress
SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1)
SrcMask: FF-FF-FF-FF-FF-FF
DestValue: 00-00-00-00-00-00
DestMask: 00-00-00-00-00-00
以下をタイプしてください。 MacAddress SrcValue: 01-02-03-04-05-06(顧客1のソースMACアドレス)SrcMask: ff ff ff ff ff ff DestValue: 00-00-00-00-00-00DestMask: 00-00-00-00-00-00
Filter2:
(similar to Filter1 but with customer 2's source MAC address as
SrcValue)
Filter2: (Filter1にもかかわらず、2ソースMACがSrcValueとして演説する顧客について同様)です。
Filter3:
(similar to Filter1 but with customer 3's source MAC address as
SrcValue)
Filter3: (Filter1にもかかわらず、3ソース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は、すべての優れた交通を落としながら、ClassifierステージとAction要素ステージを実行させます。
8.4. TCBs Supporting Microflow-based Services
8.4. Microflowベースのサービスを支持するTCBs
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ネットワークに関するリソースを保護します。 それは顧客の個々のmicroflowsの間に少しの孤立も供給しません。
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構成であるかもしれません。 それは、独自に個々の顧客microflowsを認識して、それぞれをマークします。 また、それは、単一のmicroflowが顧客にとって、あるサービスレベルで利用可能なリソースの不公平なシェアを捕らえるのを防ぐために互いから顧客の個々のmicroflowsを隔離します。 これは図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
顧客がDSCP Aによってプロバイダーに特定されるように2つのサービスレベルを指定するSLSを持って、DSCP B.Trafficが最初に種々雑多な分類評価基準に基づく交通を分類するMFクラシファイアにあてられると仮定してください、個々の顧客microflowsを特定できるくらいの粒状に。 次に、特定のDSCPのために各microflowをマークできる、計量
Bernet, et. al. Informational [Page 44] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[44ページ]のRFC3290Diffserv
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.
要素はそれがマークされたサービスレベルへのそれぞれの顧客のmicroflowsの貢献を制限します。 microflowのために許容限界を超えているパケットが落とされます。
+-----+ +-----+
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.
+-----+ +-----+ Classifier1| | | |---------------+ (mf)+>| | -->、|、| +-----+ | +-----+ | | | | |、-、-、--、>|、|、|、| A|------ +-----+ +-----+ +-----+ | -->| B|-----+ Marker1 Meter1絶対的なもの| | C|---+ | Dropper1| +-----+ | X|-+ | | +-----+ +-----+ +-->|A| +-----+ | | | | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|B|、-、--、>|、| +->| | -->、|、| +-----+ +-->|C| TCB2に| | | | | |、-、-、--、>|、|、| +-----+ | | +-----+ +-----+ +-----+ | Mux1| | Marker2 Meter2絶対です。| | | Dropper2| | | +-----+ +-----+ | | | | | | |---------------+ | |、-、--、>| | -->、|、| +-----+ | | | | |、-、-、--、>|、|、| +-----+ +-----+ +-----+ | Marker3 Meter3絶対です。| Dropper3対など
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: Classifier1: (mf) FilterA: Marker1 FilterB: Marker2 FilterC: Marker3など
Marker1:
Output: Meter1
Marker1: 出力: Meter1
Marker2:
Output: Meter2
Marker2: 出力: Meter2
Marker3:
Output: Meter3
Marker3: 出力: Meter3
Bernet, et. al. Informational [Page 45] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[45ページ]のRFC3290Diffserv
Meter1:
ConformingOutput: Mux1.InputA
NonConformingOutput: AbsoluteDropper1
Meter1: ConformingOutput: Mux1.InputA NonConformingOutput: 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によって落とされるか、または個人的には2DSCPsで著しい状態で現れます。 そして、この交通は図10で例証されるTCB2に流れます。
TCB2 could then be specified as follows:
次に、以下の通りTCB2を指定できました:
Classifier2: (BA)
FilterA: Meter5
FilterB: Meter6
Classifier2: (Ba) FilterA: Meter5 FilterB: Meter6
+-----+
| |---------------> to Queue1
+->| | +-----+
+-----+ | | |---->| |
| A|---+ +-----+ +-----+
->| | Meter5 AbsoluteDropper4
| B|---+ +-----+
+-----+ | | |---------------> to Queue2
Classifier2 +->| | +-----+
(BA) | |---->| |
+-----+ +-----+
Meter6 AbsoluteDropper5
+-----+ | |---------------Queue1+への>。>|、| +-----+ +-----+ | | |、-、-、--、>|、|、| A|---+ +-----+ +-----+ ->|、| Meter5 AbsoluteDropper4| B|---+ +-----+ +-----+ | | |---------------Queue2 Classifier2+への>。>|、| +-----+ (Ba)| |、-、-、--、>|、| +-----+ +-----+ Meter6 AbsoluteDropper5
Figure 10: Additional Example: TCB2
図10: 追加例: TCB2
Meter5:
ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper4
Meter5: ConformingOutput: Queue1 NonConformingOutput: AbsoluteDropper4
Bernet, et. al. Informational [Page 46] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[46ページ]のRFC3290Diffserv
Meter6:
ConformingOutput: Queue2
NonConformingOutput: AbsoluteDropper5
Meter6: ConformingOutput: Queue2 NonConformingOutput: AbsoluteDropper5
8.5. Cascaded TCBs
8.5. どっと落しているTCBs
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).
このモデルの何もmicroflow TCBが別のもの(例えば、ソースと1セットの目的地に別々のTCSsを実行するTCBsのための)に先行するより複雑なシナリオを防ぎません。
9. Security Considerations
9. セキュリティ問題
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.
[DSARCH]でDiffservネットワーク操作のセキュリティの脆弱性について議論します。 このドキュメントはDiffservルータ要素の抽象的な機能論的モデルについて説明します。 リソース飢餓から生じるものなどのあるサービス不能攻撃はこれらのルータ要素の適切な構成によって緩和されるかもしれません。 例えば、ある交通の流れを制限するレートまたは、より高いサービスの質のために示される交通を認証することによって。
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を入手するのにゆるい象徴バケツpolicerを利用できるところにあるかもしれません。
10. Acknowledgments
10. 承認
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作業と方針管理のように。 それらのいくつかのドキュメントの作者に感謝申し上げます: 彼らの貢献のためのフレッド・ベイカー、マイケルFineのキースMcCloghrie、ジョンSeligson、クォック・チェン、スコット・ハーン、およびアンドレアWesterinen。
This document has benefited from the comments and suggestions of several participants of the Diffserv working group, particularly Shahram Davari, John Strassner, and Walter Weiss. This document could never have reached this level of rough consensus without the relentless pressure of the co-chairs Brian Carpenter and Kathie Nichols, for which the authors are grateful.
このドキュメントはDiffservワーキンググループ、特にShahram Davari、ジョンStrassner、およびウォルター・ウィスの数人の関係者のコメントと提案の利益を得ました。 このドキュメントは共同議長のブライアンCarpenterとキャシー・ニコルズの絶え間ないプレッシャーなしでこのレベルの荒いコンセンサスに決して達することができませんでした。(作者はそれに感謝しています)。
11. References
11. 参照
[AF-PHB] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[AF-PHB] HeinanenとJ.とベイカーとF.とウィスとW.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、1999年6月。
[DSARCH] Carlson, M., Weiss, W., Blake, S., Wang, Z., Black, D.
and E. Davies, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[DSARCH] カールソンとM.とウィスとW.とブレークとS.とワングとZ.と黒人とD.とE.デイヴィース、「微分されたサービスのための構造」、RFC2475、1998年12月。
Bernet, et. al. Informational [Page 47] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[47ページ]のRFC3290Diffserv
[DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[DSFIELD]ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[DSMIB] Baker, F., Smith, A., and K. Chan, "Management
Information Base for the Differentiated Services
Architecture", RFC 3289, May 2002.
[DSMIB]ベイカー(F.とスミス、A.とK.チェン、「微分されたサービス構造のための管理情報ベース」RFC3289)は2002がそうするかもしれません。
[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.
[2EのE] BernetとY.とYavatkarとR.とフォードとP.とベイカーとF.とチャンとL.とシュペーアとM.とニコルズとK.とブレーデンとR.とデイビーとB.とWroclawskiとJ.とE.Felstaine、「Diffservネットワークの上の統合サービス操作のための枠組み」、RFC2998、2000年11月。
[EF-PHB] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[EF-PHB] デイビーとB.とシャルニーとA.とベネットとJ.C.R.とベンソンとK.とLe BoudecとJ.Y.とコートニーとW.とDavariとS.とFiroiuとV.と2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[FJ95] Floyd, S. and V. Jacobson, "Link Sharing and Resource
Management Models for Packet Networks", IEEE/ACM
Transactions on Networking, Vol. 3 No. 4, August 1995l.
[FJ95] フロイド、S.、およびV.ジェーコブソンは「パケット網のために共有とリソースマネジメント・モデルをリンクします」、ネットワークのIEEE/ACM取引、Vol.3No.4、1995年8月l。
[INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", RFC
1633, June 1994.
[INTSERV] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネット構造における統合サービス:」 「概観」、RFC1633、1994年6月。
[NEWTERMS] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April, 2002
[NEWTERMS]グロースマン、D.と、「Diffservのための新しい用語と明確化」、RFC3260、2002年4月
[PDBDEF] K. Nichols and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules
for Their Specification", RFC 3086, April 2001.
[PDBDEF]K.ニコルズとB.は大工仕事をします、と「微分されることの定義は、ドメインの振舞い単位で修理して、それらの仕様のために統治します」、RFC3086、2001年4月。
[POLTERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J. and S. Waldbusser, "Policy Terminology", RFC 3198,
November 2001.
[POLTERM] WesterinenとA.とSchnizleinとJ.とStrassnerとJ.とScherlingとM.とクインとB.とハーツォグとS.とHuynhとA.とカールソンとM.とペリーとJ.とS.Waldbusser、「方針用語」、RFC3198、2001年11月。
[QOSDEVMOD] Strassner, J., Westerinen, A. and B. Moore, "Information
Model for Describing Network Device QoS Mechanisms", Work
in Progress.
[QOSDEVMOD] 「ネットワーク装置QoSメカニズムについて説明するための情報モデル」というStrassner、J.、Westerinen、A.、およびB.ムーアは進行中で働いています。
Bernet, et. al. Informational [Page 48] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[48ページ]のRFC3290Diffserv
[QUEUEMGMT] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, C.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J. and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[QUEUEMGMT]ブレーデンとR.とクラークとD.とクロウクロフトとJ.とデイビーとB.とデアリングとS.とEstrinとD.とフロイドとS.とジェーコブソンとV.とMinshallとC.とヤマウズラとC.とピーターソンとL.とRamakrishnanとK.、ShenkerとS.とWroclawskiとJ.とL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」RFC2309(1998年4月)。
[SRTCM] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999.
[SRTCM] HeinanenとJ.とR.ゲラン、「単一賃率Threeカラーマーカー」、RFC2697、1999年9月。
[TRTCM] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, September 1999.
[TRTCM] HeinanenとJ.とR.ゲラン、「2レートThreeカラーマーカー」、RFC2698、1999年9月。
[VIC] McCanne, S. and Jacobson, V., "vic: A Flexible Framework
for Packet Video", ACM Multimedia '95, November 1995, San
Francisco, CA, pp. 511-522.
<ftp://ftp.ee.lbl.gov/papers/vic-mm95.ps.Z>
[VIC] McCanne、S.、およびジェーコブソン(V.)は「以下をvicします」。 「Packet VideoのためのFlexible Framework」、ACM Multimedia95年、1995年11月、サンフランシスコ(カリフォルニア)のページ 511-522. <ftp://ftp.ee.lbl.gov/書類/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/IEC10038の改正です: 1993 802.1j-1992と802.6k-1992。 「P802.11c、P802.1p、およびP802.12e.を組み込む」ISO/IEC15802-3: 1998.
Bernet, et. al. Informational [Page 49] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[49ページ]のRFC3290Diffserv
Appendix A. Discussion of Token Buckets and Leaky Buckets
象徴バケツと水漏れするバケツの付録A.議論
"Leaky bucket" and/or "Token Bucket" models are used to describe rate control in several architectures, including Frame Relay, ATM, Integrated Services and Differentiated Services. Both of these models are, by definition, theoretical relationships between some defined burst size, B, a rate, R, and a time interval, t:
「水漏れするバケツ」、そして/または、「象徴バケツ」モデルはいくつかの構造における速度制御について説明するのに使用されます、Frame Relay、ATM、Integrated Services、およびDifferentiated Servicesを含んでいて。 これらのモデルの両方が定義上何らかの定義された放出量と、Bと、レートと、Rと、時間間隔、tとの理論上の関係です:
R = B/t
RはB/tと等しいです。
Thus, a token bucket or leaky bucket might specify an information rate of 1.2 Mbps with a burst size of 1500 bytes. In this case, the token rate is 1,200,000 bits per second, the token burst is 12,000 bits and the token interval is 10 milliseconds. The specification says that conforming traffic will, in the worst case, come in 100 bursts per second of 1500 bytes each and at an average rate not exceeding 1.2 Mbps.
したがって、象徴バケツか水漏れするバケツが1500バイトの放出量で1.2Mbpsの情報レートを指定するかもしれません。 この場合、象徴レートは120万のbpsです、そして、象徴炸裂は1万2000ビットです、そして、象徴間隔は10ミリセカンドです。 仕様は、交通を従わせるのがそれぞれ1500バイトの秒と1.2Mbpsを超えていない平均相場で最悪の場合には100回の炸裂に入ると言います。
A.1 Leaky Buckets
A.1水漏れするバケツ
A leaky bucket algorithm is primarily used for shaping traffic as it leaves an interface onto the network (handled under Queues and Schedulers in this model). Traffic theoretically departs from an interface at a rate of one bit every so many time units (in the example, one bit every 0.83 microseconds) but, in fact, departs in multi-bit units (packets) at a rate approximating the theoretical, as measured over a longer interval. In the example, it might send one 1500 byte packet every 10 ms or perhaps one 500 byte packet every 3.3 ms. It is also possible to build multi-rate leaky buckets in which traffic departs from the interface at varying rates depending on recent activity or inactivity.
水漏れするバケツアルゴリズムは、ネットワーク(このモデルでQueuesとSchedulersの下で扱われる)にインタフェースを残すので交通を形成するのに主として使用されます。 交通は、あらゆるとても多くのタイム・ユニット(0.83マイクロセカンド毎の例の1ビット)単位で1ビットのレートでインタフェースから理論的に出発しますが、事実上、理論上に近似しながら、マルチビットユニット(パケット)でレートで出発します、より長い間隔にわたって測定されるように。 例では、それは、1万1500バイトのパケットに10ms毎を送るか、またはまた原稿Itも最近の活動か不活発に依存するレートを変えながら交通がインタフェースから出発するマルチレート水漏れするバケツを造るのにおいて可能であるあらゆる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.
一般に、実現は達成可能であるのと同じくらい一定の通信速度を求めます。 理論上、10Mbpsがアルゴリズムの実現からトランスミッションの流れを形成しました、そして、ボトルネックリンクがイーサネットがリンクする10Mbpsであるので10Mbpsでの走行である流れは区別がつかないはずです。 構成によって、理論的滑らかへの近似は、1回の象徴間隔から別のものにMTU動くことによって、異なるかもしれません。 また、交通は同じトランスミッションリソースを競争する他の交通で押し合われるかもしれません。
A.2 Token Buckets
A.2象徴バケツ
A token bucket, on the other hand, measures the arrival rate of traffic from another device. This traffic may originally have been shaped using a leaky bucket shaper or its equivalent. The token bucket determines whether the traffic (still) conforms to the specification. Multi-rate token buckets (e.g., token buckets with
他方では、象徴バケツは別の装置からの交通の到着率を測定します。 この交通は、元々、水漏れするバケツ整形器かその同等物を使用することで形成されたかもしれません。 象徴バケツは、交通が(まだ)仕様に従っているかどうか決定します。 マルチレート象徴バケツ、(例えば、象徴バケツ
Bernet, et. al. Informational [Page 50] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[50ページ]のRFC3290Diffserv
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.
Simplisticallyに、流れが簡単な象徴バケツに従うために言われているaデータはシステムがどんな時間間隔、tでも受信される大部分((R*t)+Bを超えていないデータ量)でaでR、Bをparameterizedしました。
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交通)は関連「余分な」象徴バケツプロフィールと比較されるだけです。
A.3 Some Consequences
A.3はいくつかの結果です。
The fact that Internet Protocol data is organized into variable length packets introduces some uncertainty in the conformance decision made by any downstream Meter that is attempting to determine conformance to a traffic profile that is theoretically designed for fixed-length units of data.
インターネットプロトコルデータが可変長パケットに組織化されるという事実は固定長単位のデータのために理論的に設計されている交通プロフィールに順応を決定するのを試みているどんな川下のMeterによってもされた順応決定における何らかの不確実性を導入します。
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:
これは象徴バケツの作成者をジレンマがあるMeterに置き去りにします。 L、帯域幅象徴の数、b、象徴バケツの中の左が積極的ですが、操作されるパケットのサイズ以下がオンであるときに、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
(1) バケツからパケットの整数サイズを引き算できます、それを否定的において、単に「完全に」バケツを設定するより新しい象徴がバケツに加えられた状態で次であるときに、新しい象徴配分(B)をbに加えなければならなかったのをむしろ覚えていて。 このオプションは潜在的に次に以下をこの象徴バケツ間隔までのデータの必要な放出量よりさらに、対応する置きます。 しかしながら、それは、象徴炸裂と等しい象徴バケツ間隔単位で平均した量を受け入れ続けます。 パケットの何かビットがあったなら、このアプローチは交通を受け入れます。
Bernet, et. al. Informational [Page 51] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[51ページ]のRFC3290Diffserv
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回以上のその後の間隔から容量の最大1MTUを受け入れて、借ります。 そのような象徴バケツメーター実現は「ゆるい」順応を象徴バケツに提供すると言われています。
(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回以上の間隔から受け入れられて、容量の最大1MTUを借りる場合にだけ、このアプローチは交通を受け入れます。 そのような象徴バケツメーター実現は「厳しく」て(恐らく「より厳しい」)の順応を象徴バケツに提供すると言われています。 このオプションは、[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.
次に有色のバケツからパケットの最初の一部を占めるために合わせてくださいTB変数を設定できるゼロ(3)とパケットサイズの残りを取り出すことができます。 これには、別のバグがもちろんあります: 同じパケットは、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 Guaranteed Frame Rate(GFR)サービスのカテゴリ仕様とFrame Relayで観測されました。 多くの観測をするかもしれません:
o Operationally, a token bucket meter is reasonable for traffic
which has been shaped by a leaky bucket shaper or a serial line.
However, traffic in the Internet is rarely shaped in that way: TCP
applies no shaping to its traffic, but rather depends on longer-
range ACK-clocking behavior to help it approximate a certain rate
and explicitly sends traffic bursts during slow start,
retransmission, and fast recovery. Video-on-IP implementations
such as [VIC] may have a leaky bucket shaper available to them,
o 水漏れするバケツ整形器かシリアル・ラインによって形成された交通に、象徴バケットメーターは操作上、妥当です。 しかしながら、インターネットの交通はめったにそのように形成されません: TCPは交通への形成でないのを適用しますが、それが、あるレートに近似するのを助けるためにむしろより長い範囲ACK-時計の振舞いによって、遅れた出発、「再-トランスミッション」、および速い回復の間明らかに交通炸裂を送ります。 [VIC]などのIPのビデオ実現には、それらに、利用可能な水漏れするバケツ整形器があるかもしれません。
Bernet, et. al. Informational [Page 52] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[52ページ]のRFC3290Diffserv
but often do not, and simply enqueue the output of their codec for
transmission on the appropriate interface. As a result, in each
of these cases, a token bucket meter may reject traffic in the
short term (over a single token interval) which it would have
accepted if it had a longer time in view and which it needs to
accept for the application to work properly. To work around this,
the token interval, B/R, must approximate or exceed the RTT of the
session(s) in question and the burst size, B, must accommodate the
largest burst that the originator might send.
しかし、しばしばしてください、そして、単に適切におけるトランスミッションのためのそれらのコーデックの出力が連結するエンキュー。 その結果、それぞれのこれらの場合では、象徴バケットメーターはそれが視点で、より長い時間を過したなら受け入れて、アプリケーションが適切に動作するように受け入れる必要がある短期間(単一の象徴間隔にわたる)交通を拒絶するかもしれません。 象徴間隔(B/R)は、これの周りで働くために、問題のセッションの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とFrame Relayにおいて、ゆるい象徴バケツの働きは象徴バケツ記述とかなり異なっています。
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 本当の世界展開では、MTUsはリンクレイヤネットワークサービスプロバイダーによって提供された放出量よりしばしば大きいです。 そうだとすれば、次に、厳しい象徴バケットメーターが、交通が指定されたプロフィールに決して合っていないのがわかるのは、可能です: そのような仕様が使用されるのを許容しないことによって、これは避けられるかもしれません。 この状況は構成できる中で最もわずかな放出量が1ビットであるのでゆるい象徴バケツで起こることができません、定義上ゆるい象徴バケツを1MTUの放出量を持っているのに制限して。
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,
o [SRTCM]、[TRTCM]、およびゆるいもので指定される両方の厳しい象徴バケツ仕様はしつこい下の走行を受けることがあります。 これらは時間がたつにつれて、炸裂容量を最大の放出量まで蓄積します。 最大の放出量がちょうど送られるパケット(「最も厳しい」象徴バケツ実現を呼ぶかもしれない)のサイズであると仮定してください。 このような場合には、1つのパケットを受け入れたとき、象徴の深さは、ゼロになって、再び蓄積し始めます。 後で象徴間隔より早くいつでも次のパケットを受け取ると、それを受け入れないでしょう。 次のパケットがまさに定刻に到着すると、それは、受け入れて象徴の深さに再びゼロに設定されたなるでしょう。 しかしながら、後で到着するなら
Bernet, et. al. Informational [Page 53] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[53ページ]のRFC3290Diffserv
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.
それが最大の放出量によってふたをされるので、象徴の蓄積は止まってしまうでしょう: 完全になるバケツとパケットの実際の到着の間隔の間、どんな新しい象徴も加えられません。 その結果、ネットワークにおける複数のホップの向こう側に蓄積するジターは、実際の輸入手形決済相場を減少させるためにアルゴリズムを倒そうとします。 したがって、通常、それはジターのいくつかを吸収するためにMTUよりいくらか大きい最大の象徴バケツサイズを設定して、必要な理論上のレートに沿って実用的な輸入手形決済相場をさらに許容する意味になります。
A.4 Mathematical Definition of Strict Token Bucket Conformance
厳しい象徴バケツ順応のA.4の数学の定義
The strict token bucket conformance behavior defined in [SRTCM] and [TRTCM] is not mandatory for compliance with any current Diffserv standards, but we give here a mathematical definition of two- parameter token bucket operation which is consistent with those documents and which can also be used to define a shaping profile.
[SRTCM]と[TRTCM]で定義された厳しい象徴バケツ順応の振舞いはどんな現在のDiffserv規格への承諾にも義務的ではありませんが、私たちはそれらのドキュメントと一致していて、また形成プロフィールを定義するのに使用できる2パラメタ象徴バケツ操作の数学の定義をここに与えます。
Define a token bucket with bucket size B, token accumulation rate R and instantaneous token occupancy b(t). Assume that b(0) = B. Then after an arbitrary interval with no packet arrivals, b(t) will not change since the bucket is already full of tokens.
バケツサイズB、象徴蓄積率R、および瞬時に起こっている象徴占有b(t)で象徴バケツを定義してください。 b(0)がB.と等しいと仮定してください。パケット到着のない任意の間隔の後のThen、バケツが象徴で既にいっぱいであるので、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.Thenです、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:
次のパケットがこの前にB.サイズL'<=Justに届く前に'間隔_tデルタ=t--現在がtであると仮定してください'が経過するので時tにバケツが間隔の間、デルタ_t*R象徴を最大B象徴まで蓄積した、それ:
b(t-) = min{ B, b(t') + delta_t*R }
b(t)=分'B、b(t')+デルタ_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-);
}
'(b(t)--L'>=0)である、/、*パケットは*/b(t)=b(t)を従わせます--L'、ほかパケットがする/*は*/b(t)=b(t)を従わせません。
Bernet, et. al. Informational [Page 54] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[54ページ]のRFC3290Diffserv
This function can also be used to define a shaping profile. If a packet of size L arrives at time t, it will be eligible for transmission at time te given as follows (we still assume L <= B):
また、形成プロフィールを定義するのにこの機能を使用できます。 サイズLのパケットが時間tに到着すると、以下の通り与えられた時間Teでトランスミッションに適任になるでしょう(私たちは、L<が=Bであるとまだ思っています):
te = max{ t, t" }
Te=最大「t、t」
where t" = (L - b(t') + t'*R) / R and b(t") = L, the time when L credits have accumulated in the bucket, and when the packet would conform if the token bucket were a meter. te != t" only if t > t".
'「t」が(L--b(t')+t'*R)と等しいところで/Rとb(t」)はLと等しいです、Lクレジットがバケツの中に蓄積して、パケットが1メーターTe!t>tである場合にだけ象徴バケツが=t」であるなら従う時。」
A mathematical definition along these lines for loose token bucket conformance is left as an exercise for the reader.
ゆるい象徴バケツ順応のためのこれらの線に沿った数学の定義は読者のための運動として残されます。
Authors' Addresses
作者のアドレス
Yoram Bernet Microsoft One Microsoft Way Redmond, WA 98052
ヨラムBernetマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 936 9568 EMail: ybernet@msn.com
以下に電話をしてください。 +1 9568年の425 936メール: ybernet@msn.com
Steven Blake Ericsson 920 Main Campus Drive, Suite 500 Raleigh, NC 27606
NC スティーブンブレークエリクソン920の主なキャンパスドライブ、Suite500ローリー、27606
Phone: +1 919 472 9913 EMail: steven.blake@ericsson.com
以下に電話をしてください。 +1 9913年の919 472メール: steven.blake@ericsson.com
Daniel Grossman Motorola Inc. 20 Cabot Blvd. Mansfield, MA 02048
ダニエルグロースマンMotorola Inc.20カボーBlvd. マンスフィールド、MA 02048
Phone: +1 508 261 5312 EMail: dan@dma.isg.mot.com
以下に電話をしてください。 +1 5312年の508 261メール: dan@dma.isg.mot.com
Andrew Smith (editor) Harbour Networks Jiuling Building 21 North Xisanhuan Ave. Beijing, 100089 PRC
アンドリュー・スミス(エディタ)HarbourはJiulingビル21の北のXisanhuan Aveをネットワークでつなぎます。 北京、100089PRC
Fax: +1 415 345 1827 EMail: ah_smith@acm.org
Fax: +1 1827年の415 345メール: ah_smith@acm.org
Bernet, et. al. Informational [Page 55] RFC 3290 Diffserv Informal Management Model May 2002
et Bernet、アル。 マネジメント・モデル2002年5月に非公式の情報[55ページ]のRFC3290Diffserv
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bernet, et. al. Informational [Page 56]
et Bernet、アル。 情報[56ページ]
一覧
スポンサーリンク
