サービス品質(QoS) : QoS ポリシング

帯域幅制限に関するトラフィック ポリシングとトラフィック シェーピングの比較

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2005 年 8 月 10 日) | 英語版 (2015 年 4 月 23 日) | フィードバック


目次


概要

この文書では、シェーピングとポリシングの機能的な相違点を明らかにします。 どちらのメカニズムもトークン バケットをトラフィック メータとして使用してパケット レートを測定しますが、機能面で重要な違いがあります。 (トークン バケットについては、『トークン バケットとは』を参照してください)。

はじめに

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

前提条件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

ポリシングかシェーピングか

次の図は、その主な違いを示しています。 トラフィック ポリシングはバーストを伝搬します。 トラフィック レートが最大レートの設定値に達すると、超過トラフィックが廃棄(またはマーキング)されます。 その結果、出力レートは頂上と谷間のある鋸歯状になります。 ポリシングと異なり、トラフィック シェーピングでは、超過パケットはキューまたは漏出バケットに保持され、一定の時間間隔でスケジュールされてから遅れて伝送されます。 トラフィック シェーピングの結果、パケットの出力レートは平滑化されます。

policevsshape-a.gif

シェーピングでは遅延パケットをバッファリングするためのキューと十分なメモリが存在する必要がありますが、ポリシングではそれらは必要ありません。 キューイングは送信概念です; 出かけるパケットはインターフェイス キューイングされ、形づくことができます。 インターフェイスでは着信トラフィックに対してポリシングだけを適用できます。 シェーピングを有効にする場合は十分なメモリがあることを確認してください。 また、シェーピングには遅延パケットを後で伝送するためのスケジューリング機能が必要です。 このスケジューリング機能を使用すると、シェーピング キューを別々のキューに編成できます。 スケジューリング 機能の例は Class Based Weighted Fair Queuing (CBWFQ)および低遅延キューイング (LLQ)です。

選択基準

次の表はシェーピングとポリシングの相違点をまとめたもので、最適なソリューションを選択する際に役立ちます。

  シェーピング ポリシング
目標 認定レートを超える超過パケットをバッファリングし、キューに格納する。 認定レートを超える超過パケットを廃棄(またはマーキング)する。 バッファリングしない。
トークンのリフレッシュ レート 時間間隔の開始時に補充される。 (最小の数の時間間隔が必要) 数式に基づく連続的: 1/認定情報レート
トークン値 ビット/秒で設定する。 バイトで設定する。
設定オプション
  • クラスベース シェーピングを実装する場合は、モジュラ Quality of Service(QoS)Command-Line Interface(CLI; コマンド行インターフェイス)で shape コマンドを使用する。
  • Frame Relay Traffic Shaping(FRTS; フレームリレー トラフィック シェーピング)を実装する場合は、frame-relay traffic-shape コマンドを使用する。
  • Generic Traffic Shaping(GTS; ジェネリック トラフィック シェーピング)を実装する場合は、traffic-shape コマンドを使用する。
  • クラスベース シェーピングを実装する場合は、MQC で police コマンドを使用する。
  • Committed Access Rate(CAR; 専用アクセス レート)を実装する場合は、rate-limit コマンドを使用する。
着信時の適用 いいえ はい
発信時の適用 はい はい
バースト 8 回の時間間隔以上にわたって出力レートを平滑化することにより、バーストを制御する。 漏出バケットを使用してトラフィックを遅らせることで、平滑化効果を達成する。 バーストを伝搬する。 平滑化は行わない。
利点 超過パケットがバッファリングされるため、超過パケットが廃棄される可能性は少ない (パケットは最大でキューの長さまでバッファリングされる。 超過トラフィックが高いレートで持続した場合は廃棄される可能性がある)。 一般に、パケットの廃棄による再転送が起こらなくなる。 パケットの廃棄によって出力レートを制御する。 キューイングによる遅延が起こらなくなる。
短所 キューイングによる遅延が発生するおそれがある(特にキューが深い場合)。 超過パケットが廃棄され(設定している場合)、TCP ウィンドウ サイズが絞られて、該当するトラフィック ストリームの全体的な出力レートが下がる。 バースト サイズをあまりにも大きく設定すると、超過パケットの廃棄が起こり、特に TCP ベースのフローの場合に全体的な出力レートが抑制されるおそれがある。
オプションのパケット マーキング いいえ (レガシー CAR 機能使用時)

* ポリシングではバッファリングは行われませんが、物理インターフェイスでシリアライズされるのを待つ間キューに入れる必要がある「適合」パケットには、設定されたキューイング メカニズムが適用されます。

トークンのリフレッシュ レート

シェーピングとポリシングの主な違いはトークンが補充される速度にあります。 この項では、その違いについて見ていきます。

簡単に言えば、シェーピングとポリシングはどちらもトークン バケット メタファを使用します。 トークン バケット自体は、廃棄ポリシーも優先順位ポリシーも持ちません。 トークン バケット メタファは次のように動作します。

  • トークンはある一定のレートでバケットに入れられます。

  • 各トークンは、発信元がある一定のビット数をネットワークに送信するための許可を表します。

  • パケットを送信するには、トラフィック調整機能によって、パケット サイズと表現上等しい数のトークンをバケットから削除できる必要があります。

  • パケットを送信するために十分なトークンがバケットにない場合は、バケットに十分な数のトークンが溜まるまで待機するか(シェーパの場合)、廃棄またはマークダウンされます(ポリサーの場合)。

  • バケット自体には指定された容量があります。 バケットの容量がいっぱいになると、新しく着信したトークンは廃棄されて、今後のパケットのためにそれらのトークンを使用できなくなります。 したがって、発信元がネットワークに送信できる最大のバーストは常にバケットのサイズにほぼ比例します。 トークン バケットでは、バーストが許可されますが、制限があります。

トークン バケット メタファを念頭に置きながら、シェーピングとポリシングがどのようにしてバケットにトークンを追加するのかを見ていきましょう。

シェーピングでは、ビット/秒(bps)値によって定められた時間間隔でトークン バケットが補充されます。 シェーパは次の数式を使用します。

Tc = Bc/CIR (in seconds)

この同等化では、BC は認定情報レートのための認定バーストおよび CIR 立場を表します。 (詳細は、『フレームリレー トラフィック シェーピングの設定』を参照してください)。 Tc の値は、秒単位での CIR の平均レートを維持するために Bc ビットを送信する時間間隔を定義します。

Tc の範囲は、10 ミリ秒から 125 ミリ秒の間です。 の Distributed Traffic Shaping (DTS)によって Cisco 7500 シリーズ、最小値 Tc は 4 ms です。 内部で ルータは CIR および BC 値に基づいてこの値を計算します。 Bc/CIR が 125 ミリ秒よりも小さい場合は、この式から算出された Tc が使用されます。 Bc/CIR が以上 125 ms である場合、内部 Tc 値を Cisco IOS なら使用しますか。 トラフィックフローがより小さい間隔とより安定 して いることを判別します。 ルータで Tc の内部値と管理者がコマンドラインで設定した値のどちらが使用されているかを確認するには、show traffic-shape コマンドを使用します。 次の show traffic-shape コマンドの出力例に関する詳細は、『フレームリレー トラフィック シェーピングのための show コマンド』を参照してください。

policevsshape-b.gif

超過バースト(Be)がゼロ以外の値に設定されている場合、シェーパは Bc + Be に達するまでトークンをバケットに保持します。 トークン バケットの上限値は Bc + Be であり、オーバーフローしたトークンは廃棄されます。 Bc を超えるトークンをバケットに保持する唯一の方法は、1 回または複数回の Tc の間にすべての Bc トークンを使用しないようにすることです。 トークン バケットには Bc のトークンが Tc ごとに補充されるため、未使用のトークンを Bc + Be まで蓄積して後で使用できます。

それに対して、クラスベースのポリシングでは、トークンがバケットに継続的に追加されます。 具体的には、トークン到達レートは次のようにして計算されます。

(time between packets<which is equal to t-t1>* policer rate)/8 bits per byte

つまり、前のパケットが到達した時間を t1、現在の時間を t とした場合、トークン到達レートに基づいて t-t1 に相当するバイト数だけバケットが更新されます。 トラフィック ポリサーはバイトで指定されたバースト値を使用するため、上記の数式ではビットからバイトに換算されている点に注意してください。

CIR(つまり、ポリサー レート)として 8000 bps、通常バーストとして 1000 バイトを使用した例を次に示します。

Router(config)# policy-map police-setting 
Router(config-pmap)# class access-match 
Router(config-pmap-c)# police 8000 1000 conform-action transmit exceed-action drop 

トークン バケットには最初 1000 バイト満たされています。 450 バイトのパケットが到達した場合、トークン バケットには十分なバイト数があるため、パケットは適合します。 したがって適合アクション(伝送)が実行され、トークン バケットから 450 バイトが削除されます(残り 550 バイト)。 次のパケットが .25 秒後に到達したとすると、次の数式に基づいてトークン バケットに 250 バイトが追加されます。

(0.25 * 8000)/8

この計算により、トークン バケットの内容は 700 バイトになります。 次のパケットが 800 バイトであれば、パケットは超過し、超過アクション(廃棄)が実行されます。 トークン バケットからは 1 バイトも削除されません。

トラフィック シェーピング

Cisco IOS は次のトラフィック シェーピング方式をサポートしています。

どのトラフィック シェーピング方式も実装の点ではよく似ていますが、それぞれの Command Line Interface(CLI; コマンド行インターフェイス)は若干異なります。各方式は遅延されるトラフィックを格納およびシェーピングするために異なるタイプのキューを使用します。 シスコでは、クラスベース シェーピングと分散シェーピングを推奨しています。これらはモジュラ QoS CLI を使用して設定されます。

次の図は、どのようにして QoS ポリシーがトラフィックをクラスに分類し、設定されたシェーピング レートを超えるパケットをキューイングするかを示しています。

/image/gif/paws/19645/policevsshape-c.gif

トラフィック ポリシング

Cisco IOS は次のトラフィック ポリシング方式をサポートしています。

クラスベース ポリシングおよび専用アクセスレートの比較』で説明されているようには、これらの 2 つのメカニズムには、機能面で重要な違いがあります。 シスコでは、QoS ポリシーを適用する際は、クラスベース ポリシングと、モジュラ QoS CLI の他の機能を推奨しています。

トラフィックのクラスに課された最大レートと、そのレートを超えたときにただちに実行されるアクションを指定するには、police コマンドを使用します。 つまり、police コマンドには、shape コマンドとは異なり、パケットをバッファリングして後で送出するためのオプションはありません。

また、ポリシングでは、パケットが適用レートを超えているか、または適用レートに適合しているかは、トークン バケットによって決まります。 どちらの場合でも、IP 優先順位や Differentiated Services Code Point(DSCP)の設定などの設定可能なアクションが実装されます。

次の図は、輻輳ポイント(QoS 機能は一般にこのポイントで適用される)でのトラフィック ポリシングの一般的な適用方法を示しています。

/image/gif/paws/19645/policevsshape-d.gif

最小帯域幅制御と最大帯域幅制御

shape コマンドと police コマンドはどちらも、出力レートを最大の kbps 値に制限します。 重要なのは、どちらのメカニズムも輻輳時に最小帯域幅を保証しない点です。 この種の保証を提供するには、bandwith または priority コマンドを使用します。

階層型ポリシーは 2 つのサービス ポリシーを–フローに QoS メカニズムか集約のサブセットを適用するためにトラフィック の 集約および子ポリシーに QoS メカニズムを適用するのに親ポリシー使用します。 サブインターフェイスやトンネル インターフェイスなどの論理インターフェイスには、親レベルでのトラフィック制限機能とそれよりも低いレベルでのキューイングを使用した階層ポリシーが必要です。 トラフィック制限機能を使用すると、超過パケットをキューイングしたときに見られるように、出力レートが低下し、(おそらく)輻輳が発生します。

次の設定は–最大レートへの…トラフィック の 集約を–この場合 class-default 制限するとき最適でなく、ポリシングする間の相違点を vs shape コマンド説明するために示されています。 この設定では、police コマンドは準拠に残るパケットおよびバイト数のサイズに基づいて子クラスからのパケットを送信し、トークンバケットを超過します。 (『トラフィック ポリシング』を参照してください)。 その結果、Voice over IP(VoIP)クラスと Internet Protocol(IP; インターネット プロトコル)クラスに設定されたレートは保証されない可能性があります。これは、priority 機能によって与えられた保証が、police 機能によって無効になるためです。

しかし、shape コマンドを使用すると、階層的キューイング システムが実現され、すべての保証が守られます。 つまり、シェープ レートを超える負荷が発生すると、VoIP および IP クラスはそれぞれのレートが保証され、class-default トラフィックが(子レベルで)廃棄されます。

注意 注意: この設定を使用することは推奨されません。この設定は、トラフィック集約を制限する際の、police コマンドと shape コマンドの違いを示す目的で記載されているだけです。

class-map match-all IP 
   match ip precedence 3 
class-map match-all VoIP 
   match ip precedence 5 
  
policy-map child 
  class VoIP 
     priority 128 
   class IP 
     priority 1000 
 
 policy-map parent 
   class class-default 
     police 3300000 103000 103000 conform-action transmit exceed-action drop 
     service-policy child

理にかなう上の設定のためにポリシングはシェーピングと取替える必要があります。 次に、例を示します。

policy-map parent
    class class-default
     shape average 3300000 103000 0
      service-policy child

詳細を親および子ポリシーについて学ぶために、プライオリティクラスのための QoS 子 サービス ポリシーを参照して下さい。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 19645