Quality of Service（QoS） : QoS ポリシング

ライター翻訳版 - August 10, 2005

Document ID: 19645

ダウンロード: PDF

目次

概要
はじめに
      表記法
      前提条件
      使用するコンポーネント
ポリシングとシェーピング
選択の基準
トークン リフレッシュ レート
トラフィック シェーピング
トラフィック ポリシング
最低帯域幅および最大帯域幅の制御
関連情報

概要

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

はじめに

表記法

文書表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

前提条件

この文書に適用される特定の前提条件はありません。

使用するコンポーネント

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

この文書の情報は、特定のラボ環境にあるデバイスに基づいて作成されています。 この文書内で使用されているデバイスはすべて、クリアな状態（デフォルト）から設定作業を始めています。 実稼動中のネットワークで作業する場合は、コマンドの実行によって生じる影響について、事前に理解しておいてください。

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

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

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

選択の基準

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

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

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

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

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

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

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

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

• パケットを送信できるだけの十分なトークンがバケット内に存在しない場合、パケットは、バケットに十分な量のトークンが蓄積されるまで送信待ちの状態になるか（シェーパの場合）、廃棄またはマークダウンされます（ポリサーの場合）。

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

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

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

Tc = Bc/CIR (in seconds)
 

この数式の Bc は Burst Committed（認定バースト）を表し、CIR は Committed Information Rate（認定情報レート）を表します。 （詳細は、『フレームリレー トラフィック シェーピングの設定』を参照してください）。 Tc の値は、CIR の平均レート（秒）を維持するために Bc ビットを送信する時間間隔を定義します。

Tc の範囲は 10 ミリ秒〜 125 ミリ秒です。Cisco 7500 シリーズの Distributed Traffic Shaping（DTS; 分散トラフィック シェーピング）の最低 Tc は 4 ミリ秒です。この値は CIR と Bc の値に基づいてルータの内部で計算されます。 Bc/CIR が 125 ミリ秒未満の場合は、上記の式で計算された Tc が使用されます。 Bc/CIR が 125 ミリ秒以上で、より小さい間隔を使用した方がトラフィック フローが安定すると Cisco IOS^(R) が判断した場合は、内部の Tc 値が使用されます。 ルータが内部の Tc 値を使用しているか、コマンドラインで設定された値を使用しているかを確認するには、show traffic-shape コマンドを使用します。 次の show traffic-shape コマンドの出力例に関する詳細は、『フレームリレー トラフィック シェーピングのための show コマンド』を参照してください。

超過バースト（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 に相当するバイト数だけバケットが更新されます。 トラフィック ポリサーはバイトで指定されたバースト値を使用するため、上記の数式ではビットからバイトに換算されている点に注意してください。

8000 bps の CIR（またはポリサー レート）と 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 ポリシーがトラフィックをクラスに分類し、設定されたシェーピング レートを超えるパケットをキューイングするかを示しています。

トラフィック ポリシング

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

• 認定アクセス レート

• クラスベース ポリシング

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

トラフィックのクラスで適用される最大レートを指定するには police コマンドを使用します。このレートを超過した場合は、ただちに措置を講じる必要があります。 つまり、shape コマンドの場合とは異なり、police コマンドでは、パケットをバッファリングして後で送出するというオプションはないという点に注意してください。

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

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

最低帯域幅および最大帯域幅の制御

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

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

次の設定は、トラフィック集約（この例では class-default）を最大レートに制限する際の police コマンドと shape コマンドの相違点を示すために掲載されているものであり、最適な設定ではありません。 この設定の police コマンドは、パケットのサイズと、適合トークン バケットおよび超過トークン バケットに残っているバイト数に基づいて、子クラスからのパケットを送信します （『トラフィック ポリシング』を参照してください）。 priority 機能による保証は police 機能により無効にされるため、Voice over IP（VoIP）クラスおよび Internet Protocol（IP）クラスに適用されるレートが保証されない可能性があります。

それに対し、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

親ポリシーおよび子ポリシーの詳細については、『GTS での CBWFQ の設定』を参照してください。

関連情報

• QoS に関するサポート ページ