Cisco IOS サービス品質(QoS)ソリューション コ ンフィギュレーション ガイド
輻輳管理の概要
輻輳管理の概要
発行日;2012/02/04 | 英語版ドキュメント(2011/03/15 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 8MB) | フィードバック

目次

輻輳管理の概要

輻輳管理を使用する理由とは

使用するキューイング ポリシーの決定

FIFO キューイング

重み付け均等化キューイング

フローベース重み付け均等化キューイング

制約事項

WFQ および IP Precedence

WFQ と RSVP

分散型重み付け均等化キューイング

ドロップ ポリシー

制約事項

クラスベース重み付け均等化キューイング

CBWFQ 帯域割り当て

CBWFQ を使用する理由とは

CBWFQ および RSVP

制約事項

分散型クラスベース WFQ

RSVP の DCBWFQ との対話

利点

制約事項

前提条件

IP RTP プライオリティ

IP RTP プライオリティ帯域割り当て

制約事項

フレームリレー IP RTP プライオリティ

フレームリレー PVC インターフェイス プライオリティ キューイング

制約事項

前提条件

低遅延キューイング

LLQ 帯域割り当て

LLQ および認定バースト サイズ

ATM アダプタでの LLQ および VC 単位ホールド キューのサポート

LLQ を使用する理由とは

制約事項

分散型低遅延キューイング

priority コマンドを使用した帯域幅の保証

利点

制約事項

前提条件

フレームリレー向け低遅延キューイング

制約事項

前提条件

機能のしくみ

カスタム キューイング

機能のしくみ

キューのバイト カウント値の決定

バイト カウントの使用方法

バイト カウントの決定

ウィンドウ サイズ

CQ を使用する理由とは

制約事項

プライオリティ キューイング

機能のしくみ

パケットのプライオリティ キューイングへの分類方法

プライオリティ キューイングを使用する理由

制約事項

帯域幅管理

輻輳管理の概要

輻輳管理機能で、パケットがインターフェイスに送信される順番を、これらのパケットに割り当てられた優先順位を基に決定することで輻輳をコントロールできます。輻輳管理は、キューを作成し、そのキューにパケットの分類に基づいてパケットを割り当て、キューにあるパケットの送信をスケジューリングする必要があります。輻輳管理 QoS 機能で、4 種類のキューイング プロトコルガ実現します。プロトコルのそれぞれで、異なる番号のキューの作成を指定し、トラフィックの差別の度合いを大きくまたは小さくでき、トラフィックが送信される順番を指定できます。

軽トラフィックの処理中、つまり輻輳が存在しないときは、パケットは、到着するとすぐにインターフェイスに送信されます。発信インターフェイスでの送信輻輳中は、パケットは、インターフェイスが送信可能な速度よりも速く到着します。輻輳管理機能を使用すると、インターフェイスに蓄積しているパケットが、インターフェイスでパケットを送信されできるようになるまでキューイングされます。その後、パケットに割り当てられた優先順位と、インターフェイスに設定されたキューイング メカニズムに従って送信がスケジューリングされます。ルータで、どのパケットをどのキューに配置するかや、キューをそれぞれどのように処理するかをコントロールすることで、パケット送信の順番が決定されます。

この章では、4 種類のキューイングについて説明します。これには次の輻輳管理 QoS 機能が含まれています。

First-In, First-Out(FIFO)。FIFO は、トラフィックの優先順位や分類といった概念を伴いません。FIFO では、パケットのインターフェイスへの送信は、パケットの到着順に行われます。

Weighted fair queueing(WFQ; 重み付け均等化キューイング)。WFQ で、帯域幅をトラフィックの重み付けに基づいたキューで分割する、ダイナミックな均等化キューイングを行えます (WFQ ではすべてのトラフィックが、重み付けされて均等に扱われます)。WFQ の動作について理解するためには、一連の File Transfer Protocol(FTP; ファイル転送プロトコル)パケットに対するキューを、集合体に対するキューとして考え、個別のインタラクティブ トラフィック パケットに対するキューを、個別のキューとして考えます。キューの重み付けを行い、WFQ は、集合体として送信されたすべての FTP パケットに対し、個別のインタラクティブ トラフィック パケットが同じ数だけ送信されるようにします。

この処理が行われると、WFQ で、インタラクティブ、トランザクションベースのアプリケーションなどの、パフォーマンスの低下が許されない重要なアプリケーションに対する十分な応答時間が確保されます。E1(2.048 Mbps)以下のシリアル インターフェイスでは、フローベースの WFQ がデフォルトで使用されます。他のキューイング戦略を設定しない場合、他のすべてのインターフェイスは、デフォルトで FIFO を使用します。

WFQ には、次の 4 種類があります。

フローベース WFQ(WFQ)

分散型 WFQ(DWFQ)

クラスベース WFQ(CBWFQ)

分散型クラスベース WFQ(DCBWFQ)

Custom Queueing(CQ; カスタム キューイング) CQ を使用すると、帯域幅は、トラフィックの異なるクラスに応じて割り当てられます。CQ で、キューから送信されるバイト数またはパケット数を指定できます。これは、特に低速のインターフェイスで有用です。

Priority Queueing(PQ; プライオリティ キューイング)。PQ を使用すると、1 つのプライオリティ クラスのトラフィックに属するパケットが、これより低い優先順位のすべてのトラフィックより先に送信され、これらのパケットが時間通りに送信されるようにします。


) キューイング メカニズムの種類を 1 つだけ、インターフェイスに割り当てられます。



) 各種キューイング メカニズムは、Multichassis Multilink PPP(MMP; マルチシャーシ マルチリンク PPP)などのマルチリンクを使用して設定できます。ただし、PPP のみがトンネルされたインターフェイスに使用されている場合、たとえば Virtual Private Dial-up Network(VPDN; 仮想プライベート ダイヤルアップ ネットワーク)、PPP over Ethernet(PPPoE)、PPP over Frame Relay(PPPoFR)などの場合は、仮想インターフェイスでキューイングは設定されません。


輻輳管理を使用する理由とは

異種ネットワークには、アプリケーションが使用する多くの異なるプロトコルが含まれており、これにより、ファイル転送などの時間依存が比較的少ないアプリケーションのニーズに対処しながら、タイムクリティカルなアプリケーションに応えるためにトラフィックの優先順位を付ける必要がでてきています。ネットワーク経由のデータ パスを共有する、異なる種類のトラフィックが、アプリケーションのパフォーマンスに影響を与える方法で互いに通信する可能性があります。ネットワークが、1 つのデータ パスをルータ間で共有する異なる種類のトラフィックをサポートするよう設計されている場合は、輻輳管理技術を使用して、さまざまな種類のトラフィック全体の処理の公平性を確保することを考慮しなければなりません。

輻輳管理 QoS を設定するかどうかを決定する際に考慮すべき幅広い要因の一部には次のようなものがあります。

トラフィックの優先順位付けは、遅延に影響されやすい、たとえばデスクトップ ビデオ会議などの、ファイル転送アプリケーションよりも優先順位の高いインタラクティブ トランザクションベースのアプリケーションで特に重要です。ただし、WFQ を使用すると、すべてのトラフィックが、均等に、重み付けされ、ダイナミックな方法で扱われます。たとえば、WFQ はインタラクティブ アプリケーションの要件に対し、FTP アプリケーションにペナルティを科さずに対応します。

優先順位は、一時的な輻輳が起こる可能性がある、バースト性トラフィックおよび相対的に低いデータ レートが組み合わさる WAN リンクで最も効果的です。

平均パケット サイズによっては、優先順位付けは、T1/E1 帯域幅速度またはそれ以下の速度のリンクに適用する場合が最も効果的です。

ネットワーク上で実行されているアプリケーションのユーザが、応答時間が遅いと感じたら、輻輳管理機能を使用することを考えるべきです。輻輳管理機能はダイナミックで、既存のネットワーク条件に合わせて使用できます。ただし、WAN リンクが常に輻輳している場合、トラフィックの優先順位付けでは、問題は解決 しません 。帯域幅を追加するのが適切な対処である場合があります。

WAN リンクに輻輳がない場合、トラフィックの優先順位付けを実装する理由はありません。

次のリストで、ネットワークでキューイング ポリシーを設定し、実施するかどうかを決定する際に考えるべき点をまとめています。

WAN が輻輳しているかどうか、つまり特定のアプリケーションのユーザが、パフォーマンスの低下を感じているかどうか判断します。

目的と目標を、管理の必要があるトラフィックの統合と、ネットワーク トポロジおよび設計に基づいて決定します。実現したいことを特定する際に、目的が次の中にあるかどうかを考えます。

特定したすべての種類のトラフィック全体での帯域幅割り当ての均等な配信を設定するため。

提供する特殊なアプリケーション、たとえばインタラクティブ マルチメディア アプリケーションなどから順に、場合によっては他にサポートしている重要度の低いトラフィックを犠牲にして、絶対優先をトラフィックに与えるため。

それぞれが指定した特定の帯域幅要件を持つ、提供しているすべてのアプリケーションでネットワーク リソースが共有されるよう、帯域幅割り当てをカスタマイズするため。

効果的にキューイングを設定するため。トラフィックの種類を、インターフェイスを使用して解析し、どのように区別するかを決定する必要があります。パケットの分類方法の説明については、『 Classification Overview 』モジュールを参照してください。

ニーズを評価したら、この章で説明した使用可能な輻輳管理キューイング メカニズムを確認し、要件と目的に最もよく対応できるアプローチを決定します。

選択したキューイング戦略の種類に対するインターフェイスを設定し、結果を観察します。

トラフィックのパターンは時間とともに変わるため、2 つ目の箇条書きで説明した解析プロセスを定期的に繰り返し、これに従ってキューイング設定を適用する必要があります。

さまざまなキューイング メカニズムの違いの詳細については、次のセクション「使用するキューイング ポリシーの決定」を参照してください。

使用するキューイング ポリシーの決定

このセクションでは、キューイングの種類による違いの一部を簡単に説明し、主なキューイング戦略を比較する表を記載します。

FIFO キューイングは、ユーザ データ トラフィックで優先順位付けを行いません。FIFO は、トラフィックの優先順位や分類といった概念を伴いません。FIFO を使用すると、不適切なソースが使用可能帯域幅を消費し、バーストしたソースが時間依存または重要なトラフィックに遅延を発生させる可能性があります。そして、重要なトラフィックが、重要度の低いトラフィックでキューがいっぱいになるためにドロップする可能性があります。

CQ または PQ のどちらを使うかを決定する際に、次に示す違いを考慮してください。

CQ は、帯域幅をすべてのクラスのトラフィックに割り当てられるため、一定のレベルのサービスをすべてのトラフィックに保証します。キューのサイズを、設定済みパケットカウント 容量を決定することにより定義できます。その結果、帯域幅のアクセスをコントロールします。

PQ は、1 つの種類のトラフィックが確実に送信される際に、場合によっては他のすべてのトラフィックを犠牲にして、絶対優先順位を保証します。PQ では、低プライオリティ キューは悪影響を受けることがあり、最悪の場合、帯域幅の一部が使用可能な場合や、クリティカルなトラフィックの伝送レートが高い場合に、そのパケットが送信できなくなります。

WFQ を使用するか、この 2 種類のキューイングのうち 1 つを使用するかを決定する際は、次の WFQ、PQ、CQ の違いを考慮してください。

WFQ は、シリアル インターフェイス上の優先トラフィックを決定するアクセス リストの設定が不要です。むしろ、均等なキュー アルゴリズムにより、トラフィックがカンバセーションの一部のメッセージに動的に分類されます。

低ボリュームの、インタラクティブ トラフィックは、ファイル転送のような高ボリュームのトラフィックと同様、WFQ で均等に帯域幅を割り当てられます。

完全プライオリティ キューイングは、IP RTP プライオリティ、フレームリレー IP RTP プライオリティ、Low Latency Queueing(LLQ; 低遅延キューイング)、またはフレームリレー PVC インターフェイス プライオリティ キューイング機能を使用して WFQ で実施できます。完全 PQ では、音声などの遅延に敏感なデータを、他のキューのパケットをキューから取り出す前にキューから取り出して送信できます。

表 1 で、フローベースの WFQ、CBWFQ および DCBWFQ、CQ、および PQ の特徴的な機能を比較しています。

 

表 1 キューイングの比較

フローベース WFQ
CBWFQ/DCBWFQ
CQ
PQ

キューの数

設定可能なキュー数(デフォルトでは 256 ユーザ キュー)

クラスあたり 1 つのキュー、最大 64 クラス

16 ユーザ キュー

4 キュー

サービスの種類

重み付けに基づいた、すべてのトラフィック フロー間の均等性の確保

完全プライオリティ キューイングが、IP RTP プライオリティまたはフレームリレー IP RTP プライオリティ機能の使用により使用可能

ユーザ定義のトラフィック クラスでクラス帯域幅の保証を実現

ユーザ定義以外のトラフィック クラスでフローベースの WFQ サポートを実現

完全プライオリティ キューイングは、IP RTP プライオリティ、フレームリレー IP RTP プライオリティ、LLQ、分散型 LLQ、およびフレームリレー機能向け LLQ の使用により使用可能

ラウンドロビン サービス

高プライオリティ キューが最初に処理される

絶対優先順位付け。フレームリレー PVC インターフェイス プライオリティ キューイング機能の使用により、クリティカル トラフィックに最高優先順位を保証

設定

設定は不要

設定が必要

設定が必要

設定が必要

FIFO キューイング

FIFO キューイングは、First-Come, First-Served(FCFS)としても知られており、最も簡単な形式で、パケットの到着順のバッファリングとフォワーディングが行われます。

FIFO は、トラフィックの優先順位やクラスという概念がなく、したがってパケットの優先順位に関して何も決定しません。キューが 1 つのみあり、すべてのパケットが平等に処理されます。パケットは、到着順にインターフェイスに送信されます。

FIFO を使用すると、不適切なソースがすべての帯域幅を消費し、バーストしたソースが時間依存または重要なトラフィックに遅延を発生させる可能性があります。そして、重要なトラフィックが、重要度の低いトラフィックでキューがいっぱいになるためにドロップする可能性があります。

他のキューイング戦略が設定されていない場合、E1(2.048 Mbps)以下のシリアル インターフェイスを除くすべてのインターフェイスで、FIFO がデフォルトで使用されます (E1 以下のシリアル インターフェイスはデフォルトで WFQ を使用します)。

FIFO は、最も速いキューイング方式で、遅延がほとんどなく輻輳が最小の大きなリンクで効果的です。リンクに輻輳がほとんどない場合は、使用する必要があるキューイングは FIFO キューイングのみである場合があります。

重み付け均等化キューイング

このセクションでは、次のセクションで説明した 4 種類の WFQ について説明します。

フローベース重み付け均等化キューイング

分散型重み付け均等化キューイング

クラスベース重み付け均等化キューイング

分散型クラスベース WFQ

また、このセクションでは、次のセクションで説明した 6 つの関連機能についても説明します。

IP RTP プライオリティ

フレームリレー IP RTP プライオリティ

フレームリレー PVC インターフェイス プライオリティ キューイング

低遅延キューイング

分散型低遅延キューイング

フレームリレー向け低遅延キューイング

表 2 で、WFQ、DWFQ、CBWFQ、および DCBWFQ の違いをまとめています。

 

表 2 WFQ、DWFQ、CBWFQ、および DCBWFQ の比較

WFQ
DWFQ
CBWFQ
DCBWFQ

フローベース WFQ

パケットが分類されている場合は重み付けされる。たとえば、Resource Reservation Protocol(RSVP; リソース予約プロトコル)など。

パケットが分類されていない場合は Fair Queued(FQ)(たとえば、ベストエフォート トラフィックなど)

フローベース DWFQ

FQ、重み付けなし

クラスベース DWFQ

重み付け

QoS グループベース

Type of Service(ToS; タイプ オブ サービス)ベース

クラスベース WFQ

重み付け

帯域幅の割り当てを特定のトラフィック クラスで指定可能

クラスベース分散型 WFQ

重み付け

帯域幅の割り当てを特定のトラフィック クラスで指定可能

標準の Cisco IOS プラットフォームで実行

Versatile Interface Processor(VIP; バーサタイル インターフェイス プロセッサ)で実行(より高速なパフォーマンス)

標準の Cisco IOS プラットフォームで実行

VIP で実行(より高速なパフォーマンス)

DWFQ および DCBWFQ では、すべてのキューイングが VIP によって処理されます。VIP では、すべてのパケットが直接インターフェイスに送られます。Route Switch Processor(RSP; ルート スイッチ プロセッサ)が VIP と同じプラットフォームに常駐します。RSP はシステム管理およびルーティングに関連付けられたすべてのタスクを処理します。VIP および RSP はそれぞれある程度スケジューリングを扱います。デュアルプロセッサのサポートにより、標準の Cisco IOS プラットフォームで実行する WFQ 上で、DWFQ および DCBWFQ がより高速になります。

WFQ、DWFQ、CBWFQ、および DCBWFQ の設定方法については、『 Configuring Weighted Fair Queueing 』モジュールを参照してください。VC 単位 WFQ と CBWFQ の設定方法については、『 Configuring IP to ATM Class of Service 』モジュールを参照してください。

フローベース重み付け均等化キューイング

WFQ はダイナミックなスケジューリング方式で、すべてのネットワーク トラフィックに均等に帯域幅を割り当てます。WFQ は、識別したトラフィックに優先順位(または重み)を適用して、トラフィックをカンバセーションに分類し、各カンバセーションに許可する帯域幅を、他のカンバセーションとの関係で決定します。WFQ は、フローベースのアルゴリズムで、インタラクティブ トラフィックをキューの先頭にして応答時間を減らし、残りの帯域を高帯域幅のフローで均等に共有するよう、同時にスケジューリングします。つまり、WFQ は Telnet セッションなどの低ボリュームのトラフィックに FTP セッションなどの高ボリュームのトラフィックより高い優先順位を与えることができます。WFQ は、リンク容量をバランスよく使用した並列ファイル転送を行います。つまり、複数のファイル転送が発生すると、転送は同程度の帯域幅で行われます。図 1 に、WFQ の動作方法について示します。

図 1 重み付け均等化キューイング

 

WFQ で、FIFO キューイングの重大な制限が解消されます。FIFO が有効になると、帯域幅の消費や関連する遅延に関係なく、トラフィックが受信した順に送信されます。結果として、ファイル転送および他の高ボリュームのネットワーク アプリケーションにより、関連付けられたデータのパケットが連続して作成されることが多くあります。これらの関連パケットは、パケット トレインと呼ばれます。パケット トレインはパケットのグループで、ネットワーク上を一緒に移動する傾向があります。これらのパケット トレインは、使用可能なすべての帯域幅を消費してしまい、他のトラフィックの帯域幅を奪う可能性があります。

WFQ は、トラフィックを、動的にカンバセーションを構成するメッセージに並べ替えてトラフィックの優先順位を管理します。WFQ は、パケットのトレインをカンバセーションに分割し、個々のカンバセーション間で確実に帯域幅が均等に共有されるようにし、低ボリュームのトラフィックがタイミングよく転送されるようにします。

WFQ は、ソースの特性や宛先ネットワークまたは MAC アドレス、プロトコル、ソースおよび宛先ポートおよびセッションのソケット ナンバー、フレームリレー Data-Link Connection Identifier(DLCI; データリンク接続識別子)の値、および ToS 値を含むパケット ヘッダー アドレッシングに基づいて、トラフィックを異なるフローに分類します。フローには、広帯域セッションおよび低帯域セッションの 2 つのカテゴリがあります。低帯域幅のトラフィックは、広帯域幅のトラフィックよりも有効な優先順位を持ち、高帯域幅のトラフィックは転送サービスを、割り当てられた重み付けに従って比例的に共有します。低帯域幅のトラフィック ストリームは、トラフィックの大部分を占め、優先的にサービスを受け、発生する負荷全体をタイミングよく送信できます。高ボリュームのトラフィック ストリームは、残りの容量を、高ボリュームのトラフィック間で比例的に共有します。

WFQ はさまざまなカンバセーションのパケットを、送信の前に均等なキューに配置します。均等なキューから削除する順番は、各到着パケットの最終ビットの仮想送信時間により決定されます。

広帯域幅フローの新しいメッセージが、輻輳メッセージしきい値に適合した後で破棄されます。ただし、低帯域幅のフローは、コントロールメッセージ カンバセーションが含まれており、入力キュー データにとどまります。結果、均等化キューで、しきい値数で指定された数よりも多くのメッセージを保持する場合があります。

WFQ は、アプリケーションのペア間などのデュプレクス データ ストリームや、音声やビデオなどの簡単なデータ ストリームを管理できます。

また、WFQ アルゴリズムは、往復遅延変動性にも対処できます。複数の高ボリュームのカンバセーションがアクティブな場合、転送レートと時間間隔の長さがより予測可能になります。WFQ は Systems Network Architecture(SNA; システム ネットワーク アーキテクチャ)、Logical Link Control(LLC; 論理リンク制御)および TCP 輻輳管理とスロー スタート機能などのアルゴリズムを大幅に拡張します。

フローベース WFQ は、E1 速度(2.048 Mbps)以下で実行するよう設定されたシリアル インターフェイスのほとんどで、デフォルトのキューイング モードとして使用されます。

WFQ は、高負荷および低負荷のネットワーク ユーザに、過度の地域幅を追加せずに、同様に一貫した応答時間を実現することが望ましい状況に対処します。WFQ は自動的に、ネットワーク トラフィック条件の変更に対応します。

制約事項

WFQ は、トンネリングおよび暗号化ではサポートされていません。これらの機能は、分類を行うために、WFQ で必要なパケット コンテンツ情報を修正するためです。

WFQ は自動的にネットワーク トラフィック条件の変化に対応しますが、CQ や CBWFQ が提供する、帯域幅全体の割り当ての詳細なコントロールは行いません。

WFQ および IP Precedence

WFQ は、IP precedence を意識します。IP Forwarder で優先とマークされたより高い優先順位のパケットを検出し、それらをより速くスケジューリングできます。これにより、このトラフィックに対しすぐれた応答時間を実現します。このように、優先度が増すと、WFQ は輻輳期間中のカンバセーションにより多くの帯域幅を割り当てます。

WFQ は各フローに重み付けを割り当て、キューイングされたパケットの転送順を決定します。この方式では、重み付けが低いパケットが最初に処理されます。標準の Cisco IOS WFQ では、IP precedence はこの重み付け係数の除数として扱われます。

CQ と同様、WFQ は特定のバイト数を各キューから送信します。WFQ を使用して、各キューは異なるフローに対応します。すべてのフローを通した各サイクルで、WFQ は、フローの優先度に 1 を足した数に等しいバイト数を効率的に送信します。この数は、送信する 1 パケットあたりのバイト数を決定する比率としてのみ使用されます。ただし、WFQ を理解するという目的では、この数をバイト カウントとして使用して差し支えありません。たとえば、IP Precedence 値が 7 のトラフィックは、IP Precedence 値が 3 のトラフィックよりも、より重みが低くなり、これが転送順の優先順位となります。重みは、IP Precedence 値に反比例します。

各キューへの帯域幅の割り当てを決定するには、すべてのフローの総バイト カウントで、フローのバイト カウントを割ります。たとえば、各優先レベルでフローが 1 つある場合、各フローはリンクの優先度 + 1 の部分になります。

1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 = 36

したがって、優先度 0 のトラフィックは帯域幅の 1/36、優先度 1 のトラフィックは 2/36、優先度 7 のトラフィックは 8/36 となります。

しかし、優先度 1 のフローが 18 個と、残りのそれぞれが 1 つの場合、合計は次のようになります。

1 + 2(18) + 3 + 4 + 5 + 6 + 7 + 8 = 70

優先度 0 のトラフィックは 1/70、優先度 1 のフローがそれぞれ 2/70 のようになります。

フローが追加されたり終了したりすると、実際に割り当てられる帯域幅は連続的に変化します。

WFQ と RSVP

RSVP は WFQ を使用して、バッファ領域とスケジュール パケットを割り当て、予約されたフローへの帯域幅を保証します。WFQ は RSVP と連動し、差別化され保証された QoS を使用できるようにします。

RSVP は、アプリケーションでネットワーク帯域幅を動的に予約できるようにする Internet Engineering Task Force(IETF インターネット技術特別調査委員会)インターネット規格(RFC 2205)プロトコルです。RSVP により、アプリケーションはデータ フローに対する特定の QoS を要求できます。シスコの実装では、設定されたプロキシ RSVP を使用して RSVP をネットワーク内で開始できます。

RSVP は、IP ネットワークのエンドツーエンドでネットワーク帯域幅を保証する唯一の標準シグナリング プロトコルです。ホストとルータは、RSVP を使用して、データ ストリームのパスに沿って QoS 要求をルータに配信したり、ルータとホストの状態を維持して要求されたサービス(その多くは帯域幅や遅延)を提供したりします。RSVP は平均データ レート、ルータがキューに保持する最大量のデータ、および予約する帯域幅を決定する最小 QoS を使用します。

WFQ または Weighted Random Early Detection(WRED; 重み付けランダム早期検出)は、RSVP の作成元として動作し、パケットの分類を設定して予約フローで必要なスケジューリングを行います。WFQ を使用して、RSVP はサービス統合型品質保証型サービスを提供します。

分散型重み付け均等化キューイング

DWFQ は、VIP 上で実行する WFQ の特殊な高速バージョンです。次の、VIP2-40 以降のインターフェイス プロセッサのあるルータでサポートされます。

RSP7000 搭載の Cisco 7000 シリーズ

Cisco 7500 シリーズ

VIP のポート アダプタの集約ライン レートが DS3 を上回る場合は、VIP2-50 インターフェイス プロセッサをお勧めします。OC-3 レートでは VIP2-50 カードが必要です。

DWFQ を使用するには、distributed Cisco Express Forwarding(dCEF; 分散型シスコ エクスプレス フォワーディング)スイッチングがインターフェイスでイネーブルになっている必要があります。CEF については、『 Cisco Express Forwarding Features Roadmap 』モジュールを参照してください。


) VIP 分散型 WFQ の実装は、他のすべてのプラットフォームで実行する WFQ とは異なります。


分散型 WFQ には次の 2 つの形式があります。

フローベース。この形式では、パケットはフローで分類されます。同じ発信元の IP アドレスを持つパケット、宛先 IP アドレス、発信元 TCP またはユーザ データグラム プロトコル(UDP)ポート、宛先 TCP または UDP ポート、プロトコル、および同じフローに属する ToS フィールドです (すべての非 IP パケットは、フロー 0 として処理されます)。

各フローは、個別の出力キューに対応します。パケットがフローに割り当てられると、そのフローのキューに配置されます。輻輳中、DWFQ はアクティブなキューそれぞれに、等しい帯域幅の共有を割り当てます。

また、フローベース DWFQ は、均等化キューイングとも呼ばれます。すべてのフローが等しく重み付けされ、均等な帯域幅に割り当てられるためです。DWFQ の現在の実装では、重みはフローには割り当てられません。DWFQ で、正常に動作するホストは不適切なホストから保護されます。

クラスベース。この形式では、パケットは QoS グループまたは ToS フィールドの IP precedence を基に、異なるキューに割り当てられます。

QoS グループでは、QoS ポリシーをカスタマイズできます。QoS グループは、パケットを DWFQ および Committed Access Rate(CAR; 専用アクセス レート)などの特定の QoS 機能でどのように処理するかを決定するためにルータが使用する、パケットの内部の分類です。Border Gateway Protocol(BGP; ボーダー ゲートウェイ プロトコル)機能経由の CAR ポリシーまたは QoS ポリシーの伝播に使用し、パケットを QoS グループに割り当てます。

パケットを、2 種類の低順位 IP Precedence ビットのみを基にパケットを分類する場合は、ToS ベースの DWFQ を使用します。各クラスの重みを指定します。輻輳期間では、各グループはクラスの重み付けに等しい出力帯域幅の割合が割り当てられます。たとえば、クラスに 50 の重みが割り当てられている場合、このクラスからのパケットには、輻輳中、発信帯域幅の最低 50 パーセントが割り当てられます。インターフェイスが輻輳していないときは、キューは使用可能帯域幅をすべて使用できます。

「ドロップ ポリシー」セクションで、この両方の形式で使用されるドロップ ポリシーについて説明します。

ドロップ ポリシー

DWFQ では、それぞれのキューにパケットの数のトラックと、すべてのキューにパケットの合計数を保持しています。

パケットの合計数が集約制限より少ない場合、キューは個々のキュー制限よりも多くのパケットをバッファできます。

パケットの合計数が集約制限に達すると、インターフェイスは個々のキュー制限が強制的に適用されます。新しいパケットの到着で個々のキュー制限を越えると、そのパケットはドロップします。すでにキューにあるパケットは、キューが個々の制限を超えていてもドロップしません。

場合によっては、すべてのキューにあるパケットの合計数が集約制限を超えてしまう場合があります。

制約事項

DWFQ は IP トラフィックと一緒に使用してください。非 IP トラフィックは、単一フローとして処理され、同じキューに配置されます。

DWFQ には、次の制約事項があります。

インターフェイスで設定できますが、サブインターフェイスでは設定できません。

ATM カプセル化の AAL5-MUX および AAL5-NLPID はサポートされません。

Fast EtherChannel、トンネル インターフェイス、またはその他の Multilink PPP(MLP; マルチリンク PPP)などの論理(仮想)インターフェイスではサポートされません。

RSP ベース PQ、CQ または WFQ と同じインターフェイスでは設定できません。

クラスベース重み付け均等化キューイング

CBWFQ は標準の WFQ 機能性を拡張し、ユーザ定義のトラフィッククラスをサポートしています。CBWFQ では、プロトコル、Access Control List(ACL; アクセス コントロール リスト)、および入力インターフェイスなどの一致基準を基にトラフィック クラスを定義します。クラスの一致基準を満たすパケットは、そのクラスのトラフィックの一部となります。FIFO キューはそれぞれのクラスで予約され、クラスに属するトラフィックはそのクラスのキューに誘導されます。

クラスが一致基準によって定義されると、それに特性を割り当てることができます。クラスに特性を持たせるには、帯域幅、重み、最大パケット制限を割り当てます。クラスに割り当てられた帯域幅は、輻輳中のクラスに適用する保証帯域幅です。

クラスに特性を持たせるには、そのクラスのキュー制限も指定します。これは、クラスのキューに集めることができる最大パケット数です。クラスに属するパケットは、そのクラスの特性の帯域幅とキュー制限に対応しています。

キューが設定されたキュー制限に達した後、そのクラスに追加パケットが入力されると、設定されているクラス ポリシーに応じてテール ドロップまたはパケット ドロップが発生します。

テール ドロップは、CBWFQ クラスで、クラスに輻輳を回避する手段として WRED を使用してパケットをドロップするよう、明示的にポリシーを設定しない限り使用されます。ポリシー マップを構成する 1 つまたは複数のクラスで、テール ドロップの代わりに WRED パケット ドロップを使用する場合、そのサービス ポリシーを適用するインターフェイスに WRED が設定されていないことを確認してください。

デフォルトのクラスが、 bandwidth policy-map class コンフィギュレーション コマンドを使用して設定されている場合、すべての未分類のトラフィックが 1 つの FIFO キューに格納され、設定された帯域幅に従って処理されます。デフォルトのクラスが、 fair-queue コマンドを使用して設定されている場合、すべての未分類のトラフィックがフロー分類となり、ベストエフォート扱いとなります。デフォルトのクラスが設定されていない場合、デフォルトでは設定されているどのクラスにも一致しないトラフィックはフロー分類となり、ベストエフォート扱いとなります。パケットが分類されると、クラスのディファレンシエーテッド サービスで使用可能なすべての標準メカニズムを適用します。

フロー分類は、標準 WFQ 扱いになります。つまり、同じ発信元 IP アドレス、宛先 IP アドレス、発信元 TCP または UDP ポート、または宛先 TCP または UDP ポートが、同じフローに属するものとして分類されます。WFQ は、各フローに、帯域幅の共有を均等に割り当てます。また、フローベース WFQ は、すべてのフローが等しく重み付けされるため、均等化キューイングとも呼ばれます。

CBWFQ では、そのクラスに指定された重みは、そのクラスの一致基準を満たすそれぞれのパケットの重みとなります。出力インターフェイスに到着したパケットは、定義した一致基準フィルタによって分類され、それぞれに適切な重みが割り当てられます。特定のクラスに属するパケットの重み付けは、クラス設定したときにクラスに割り当てた帯域幅から適用されます。そういった意味では、クラスの重み付けはユーザ定義可能です。

パケットの重みが割り当てられると、そのパケットは適切なクラス キューに入力されます。CBWFQ は、キューイングされたパケットに割り当てられた重み付けを使用し、クラス キューが確実に均等に提供されるようにします。

クラス ポリシーの設定、つまり CBWFQ の設定は、次の 3 つの処理を伴います。

トラフィック クラスを定義して分類ポリシー(クラス マップ)を指定する。

このプロセスによって、何種類のパケットを区別するかが決まります。

ポリシー、つまりクラス特性を各トラフィック クラスに関連付ける(ポリシー マップ)。

このプロセスでは、クラス マップで定義済みのクラスの 1 つに属するパケットに適用されるポリシーの設定が必要です。このため、各トラフィック クラスでポリシーを指定するポリシー マップを設定します。

ポリシーをインターフェイスへ適用する(サービス ポリシー)。

このプロセスでは、既存のポリシー マップ、またはサービス ポリシーを、インターフェイスに関連付け、マップに対する特定のポリシー セットをそのインターフェイスに適用する必要があります。

CBWFQ 帯域割り当て

1 つのインターフェイスのすべての帯域割り当ての合計が、使用可能なインターフェイス帯域幅の総計の 75 パーセントを超えることはできません。残りの 25 パーセントは、レイヤ 2 オーバーヘッドを含む他のオーバーヘッド、ルーティング トラフィック、およびベストエフォート トラフィックに使用されます。たとえば CBWFQ クラスデフォルト クラスの帯域幅は、残りの 25 パーセントから使用されます。しかし、クラスにインターフェイス帯域幅の 75 パーセント以上を設定する必要があるアグレッシブな環境の下では、すべてのクラスまたはフローに割り当てられた、この 75 パーセントという 最大合計値を max-reserved-bandwidth コマンドで上書きできます。デフォルトの 75 パーセントを上書きする場合は、注意し、ベストエフォートおよびコントロール トラフィック、レイヤ 2 オーバーヘッドをサポートするのに十分な帯域幅を残すようにしてください。

ATM が使用されている場合、ATM セル タックス オーバーヘッドが含まれないということを考慮する必要があります。たとえば、ATM Permanent Virtual Circuit(PVC; 相手先固定接続)で保証帯域幅がクラスに必要な場合を考えます。このクラスの平均パケット サイズが 256 バイトで、このクラスに 100 kbps(1 秒あたり 49 パケット相当)の帯域幅が保証されているとします。256 バイトごとのパケットが、VC に送信するため 6 つのセルに分割され、合計 6 × 53 = 318 バイトになります。この場合、ATM セル タックス オーバーヘッドは、62 バイトまたは 49 × 62 × 8 = 24.34 kbps になります。この例において CBWFQ を設定する場合、要求されたペイロード保証を設定されたクラスで確実にするには、すべての設定済みクラス帯域幅(この例では、1 つのクラスのみ)の合計が、最低 24.34 kbps で、VC 帯域幅未満になるようにします。複数のクラスがある場合、すべてのクラスのオーバーヘッドの合計を推測し、すべての設定済みクラス帯域幅の合計に追加する必要があります。要求されたペイロード保証を確実にするには、この合計を VC 帯域幅よりも少なくしてください。

CBWFQ を使用する理由とは

CBWFQ を設定する必要があるかどうかを決定する際に考慮すべき一般的な要素の一部には次のようなものがあります。

帯域割り当て。CBWFQ を使用すると、特定のトラフィック クラスに対して割り当てる帯域幅の正確な量を指定できます。インターフェイス上の使用可能な帯域幅を考慮し、クラスを 64 まで設定して、それらの間で分配できます。これは、フローベース WFQ には当てはまりません。フローベース WFQ は、重み付けを特定のトラフィックに適用し、トラフィックをカンバセーションに分類して、各カンバセーションで、どのくらいの帯域幅が許可されるかを他のカンバセーションと相対的に決定します。フローベース WFQ では、重み付けとトラフィック分類は、7 つの IP Precedence レベルによって行われ、制限されます。

より粗い粒度とスケーラビリティ。CBWFQ で、フローの制限を超えた基準に基づいてどのクラスを含めるかを定義できます。CBWFQ では、トラフィックの分類方法を定義するための ACL や、プロトコルまたは入力インターフェイス名を使用でき、これによってより粗い粒度を実現します。トラフィック分類をフロー ベースで管理する必要はありません。さらに、サービス ポリシーに最大 64 の個別クラスを設定できます。

CBWFQ および RSVP

RSVP は、CBWFQ と併用できます。RSVP および CBWFQ の両方がインターフェイスで設定されている場合、RSVP および CBWFQ は独立して動作し、それぞれが単体で実行されている場合と同様の動作を行います。RSVP は、帯域幅の可用性のアセスメントと割り当てに関しても、CBWFQ が有効でない場合の動作と同様の動作を継続します。

制約事項

物理インターフェイスでの CBWFQ は、インターフェイスがデフォルトのキューイング モードにある場合のみ設定可能です。E1(2.048 Mbps)以下でのシリアル インターフェイスでは、デフォルトで WFQ が使用されます。他のインターフェイスでは、デフォルトで FIFO が使用されます。物理インターフェイスで CBWFQ をイネーブルにすると、デフォルトのインターフェイス キューイング方式が上書きされます。ATM PVC で CBWFQ をイネーブルにしても、デフォルトのキューイング方式は上書きされません。

ポリシー マップで、パケットのドロップにテール ドロップではなく WRED を使用するようクラスを設定する場合、このサービス ポリシーを適用しようとしているインターフェイスで WRED が設定されないようにしてください。

トラフィック シェーピングおよびポリシングは、現在 CBWFQ ではサポートされていません。

CBWFQ は Variable Bit Rate(VBR; 可変ビット レート)および Available Bit Rate(ABR; 使用可能ビット レート) ATM 接続でサポートされています。Unspecified Bit Rate(UBR; 未指定ビット レート)接続ではサポートされません。

CBWFQ はイーサネット サブインターフェイスではサポートされません。

分散型クラスベース WFQ

既に説明したように、WFQ で、トラフィックの重み付けに基づいたキューで帯域幅を分割する、ダイナミックな均等化キューイングを行えます。WFQ は、すべてのトラフィックが、その重み付けを考慮して均等に処理されるようにします。WFQ の詳細については、このモジュールの「重み付け均等化キューイング」セクションを参照してください。

DCBWFQ 機能で、標準 WFQ の機能性を拡張し、VIP でのユーザ定義のトラフィック クラスのサポートを実現します。これらのユーザ定義トラフィック クラスは、Modular Quality of Service Command-Line Interface(Modular QoS CLI)機能で設定します。Modular QoS CLI で QoS を設定する方法については、『 Applying QoS Features Using the MQC 』モジュールを参照してください。

トラフィック クラス キューで集められる最大パケット数は、キュー制限と呼ばれ、 policy-map コマンドを使用してサービス ポリシーを作成する際に、 queue-limit コマンドで指定します。トラフィック クラスに属するパケットは、保証帯域割り当てと、トラフィック クラスの特性であるキュー制限に対応しています。

キューが設定されたキュー制限に達した後、そのトラフィッククラスに追加パケットが入力されると、サービス ポリシーの設定方法に応じてテール ドロップまたは WRED ドロップが発生します (テール ドロップは、すべてのトラフィックを等しく扱い、サービスのクラス間で区別をしない、輻輳を回避する手段です。輻輳期間中はキューが一杯になります。出力キューが一杯でテール ドロップが有効な場合、輻輳が解消されてキューが一杯でなくなるまでパケットはドロップされます)。

テール ドロップは、DCBWFQ トラフィック クラスで、輻輳を回避する手段として WRED を使用してパケットをドロップするよう、明示的にサービス ポリシーを設定しない限り使用されます。サービス ポリシーを構成する 1 つまたは複数のトラフィック クラスで、テール ドロップの代わりに WRED パケット ドロップを使用する場合、そのサービス ポリシーを適用するインターフェイスに WRED が設定されていないことを確認してください。

DCBWFQ の設定方法については、『 Configuring Weighted Fair Queueing 』モジュールを参照してください。

RSVP の DCBWFQ との対話

RSVP および DCBWFQ が設定されている場合、RSVP および DCBWFQ は互いに独立して動作します。RSVP および DCBWFQ は、輻輳している点で使用可能な未割り当ての帯域幅に応じて、トラフィック クラスおよびフロー間で帯域幅を割り当てます。

RSVP フローが作成されると、VIP キューイング システムで、RSVP キューの帯域割り当てのユニットが予約されます。これは、トラフィック クラス キューが DCBWFQ トラフィック クラスに割り当てられる方法と同様です。DCBWFQ トラフィック クラスは RSVP フローにより影響を受けません。

利点

帯域割り当て

DCBWFQ で、トラフィック クラスで割り当てられる保証帯域幅を指定できます。インターフェイス上で使用できる帯域幅を考慮し、最大 64 のトラフィック クラスを設定でき、それらで帯域割り当てをコントロールできます。超過帯域幅が使用できる場合、超過帯域幅は、設定済み帯域幅に比例して、トラフィック クラス間で分割されます。

フローベース WFQ は、すべてのフロー間で等しく帯域幅を割り当てます。

より粗い粒度とスケーラビリティ

DCBWFQ で、フローの制限を超えた基準に基づいてどのトラフィック クラスを含めるかを定義できます。DCBWFQ では、トラフィックの分類方法を定義するための ACL や、プロトコルまたは入力インターフェイス名を使用でき、これによってより粗い粒度を実現します。トラフィック分類をフロー ベースで管理する必要はありません。さらに、サービス ポリシーで最大 64 の個別のトラフィック クラスを設定できます。

制約事項

bandwidth コマンドの VIP デフォルト トラフィック クラスでの使用

VIP では、ユーザ定義クラスと一致しないすべてのトラフィックは、デフォルトのトラフィック クラスの一部として分類されます。VIP のデフォルトのトラフィック クラスに暗黙的に割り当てられた帯域幅は、リンク帯域幅からユーザ定義のトラフィック クラス( bandwidth コマンドを使用)に指定したすべてのユーザ定義帯域幅をマイナスした帯域幅に等しくなります。リンク帯域幅の最低 1 パーセントは、常にデフォルトのトラフィック クラスで予約されます。

VIP のデフォルトのトラフィック クラスの帯域幅は暗黙的(デフォルトのトラフィック クラスは、ユーザ定義トラフィック クラスに使用された以外の残りすべての帯域幅を使用します)なため、 bandwidth コマンドでは、VIP を設定する際にデフォルトのトラフック クラスを使用できません。

match protocol コマンドの VIP での使用

一致基準として非 IP プロトコルを使用したトラフィック クラスの作成に、 match protocol コマンドは使用しないでください。VIP は、非 IP プロトコルのマッチングをサポートしません。

PA-A3-8T1IMA モジュール

DCBWFQ は、PA-A3-8T1IMA モジュール付き Cisco 7500 シリーズ ルータをサポートしません。

前提条件

WFQ

サービス ポリシーをインターフェイスに適用すると、WFQ がそのインターフェイスに設定されている場合、その WFQ はディセーブルになります。このため、このようなインターフェイスで WFQ をイネーブルにしないようにしてください。

WFQ については、『 Configuring Weighted Fair Queueing 』モジュールを参照してください。

ACL

番号を付けたアクセス リストを、作成した任意のトラフィック クラスの一致基準として指定できます。したがって、アクセス リストの設定方法を知っておく必要があります。

Modular QoS CLI

Modular QoS CLI を使用して、DCBWFQ を設定できます。

Modular QoS CLI での QoS の設定については、『 Applying QoS Features Using the MQC 』モジュールを参照してください。

IP RTP プライオリティ

IP RTP プライオリティ機能で、遅延に影響されやすい音声などのデータに対する完全プライオリティ キューイング方式を実現します。音声トラフィックは、自身の Real-Time Transport Protocol(RTP; リアルタイム転送プロトコル)のポート番号で識別され、 ip rtp priority コマンドで設定されたプライオリティ キューに分類されます。その結果、音声は他の非音声トラフィックよりも優先度が高い絶対優先として扱われます。


) このセクションでは、主に音声トラフィックについて説明しますが、IP RTP プライオリティはどのような RTP トラフィックにも使用できます。


IP RTP プライオリティ機能は、同じ出力インターフェイスを使用した他のキューやクラスに対する絶対優先サービスがトラフィックに保証されている UDP/RTP ポートの範囲を指定可能にすることで、 ip rtp reserve コマンドで提供される機能性を拡張、改良します。絶対優先とは、パケットがプライオリティ キューに存在する場合、そのパケットは他のキューのパケットがキュー解除される前にキュー解除されることを意味します。音声コンフィギュレーションには、 ip rtp reserve コマンドの代わりに ip rtp priority コマンドを使用することを推奨します。

IP RTP プライオリティ機能では、音声通話のポートを知っている必要はありません。むしろ、この機能で、トラフィックがプライオリティ キューに配置されているポート範囲を識別できます。さらに、全体の音声ポート範囲(16384 ~ 32767)を指定し、すべての音声トラフィックが絶対優先サービスとして指定されるようにできます。IP RTP プライオリティは特に、速度が 1.544 Mbps 未満のリンクで有用です。

この機能は、同じ発信インターフェイスの WFQ または CBWFQ のいずれかで使用できます。いずれの場合にも、プライオリティ キューに対して指定された範囲のポートに一致するトラフィックは、他の CBWFQ クラスまたは WFQ フローよりも確実に優先されることが保証され、プライオリティ キュー内のパケットは常に最初に処理されます。次の、 ip rtp priority コマンドの条件に注意してください。

WFQ と併用する場合、 ip rtp priority コマンドで音声に絶対優先を与え、WFQ スケジューリングは残りのキューに適用されます。

CBWFQ と併用する場合、 ip rtp priority コマンドで音声に絶対優先を与えます。CBWFQ は、専用帯域幅が必要な、またベストエフォートよりは優先する必要があるが絶対優先は必要ではない、他の種類のトラフィック(SNA など)の設定に使用できます。非音声トラフィックは、キューに入力れたパケットに割り当てられた重みに基づいて均等に処理されます。また CBWFQ は、設定されている場合、デフォルトの CBWFQ クラスでフローベース WFQ をサポートします。

音声パケットはサイズが小さく、インターフェイスは大きなパケットも送出できるため、Link Fragmentation and Interleaving(LFI)機能もより低速のインターフェイスで設定できます。LFI をイネーブルにすると、大きなデータ パケットは分割され、小さい音声パケットが大きなデータ パケットからできたデータ フラグメントの間にインターリーブできるようになります。LFI は、大きいパケットが送信されるまで音声パケットが待機せずにすむようにします。代わりに、音声パケットはより短時間で送信できます。

IP RTP プライオリティの設定方法については、『 Configuring Weighted Fair Queueing 』モジュールを参照してください。

IP RTP プライオリティ帯域割り当て

IP RTP 機能の動作と適切な使用について理解しようとする場合、アドミッション コントロールとポリシング特性について考えることが重要です。 ip rtp priority コマンドを音声のプライオリティ キューの設定に使用する場合、絶対帯域幅制限を指定します。この帯域幅の大きさは、プライオリティ キューに入力された音声トラフィックに保証されます (これは、IP RTP プライオリティ機能を CBWFQ または WFQ と併用している場合です)。


) IP RTP プライオリティは、コール単位のアドミッション コントロールは行いません。アドミッション コントロールは、集約ベースです。たとえば、96 kbps で設定されている場合、IP RTP プライオリティで、96 kbps が予約に使用できることが保証されます。これは、24 kbps のコールが 4 つだけ許可されるということではありません。5 つ目の 24 kbps のコールも許可される場合がありますが、5 つのコールが 96 kbps を分け合うため、通話品質は低下します (それぞれのコールで 96/5 = 19.2 kbps ずつ使用します)。この例では、1 度に処理されるコールが必ず 4 つだけになるようにするのは、ユーザの責任です。


IP RTP プライオリティは、プライオリティ キューの帯域の使用に関する詳細なポリシーで、割り当て量を輻輳時に超えないようにします。実際、IP RTP プライオリティは、フローを毎秒ポリシングします。IP RTP プライオリティは、割り当てられた帯域幅が使用されると、追加のパケットの送信を禁止します。設定された帯域幅の大きさを超えることがわかると、IP RTP プライオリティは、音声トラフィックにより受け入れが不完全になるパケットをドロップします (この状態を監視するためにデバッグをイネーブルにします)。詳細なポリシー設定により、他の CBWFQ または WFQ キューに入力されたパケットの均等な処理が可能になります。パケットのドロップを避けるためには、プライオリティ キューに、使用されるコーデックとインターフェイス特性のタイプを考慮しながら、最適な帯域幅量を割り当てるようにします。IP RTP プライオリティは、割り当てられた量を超えるトラフィックは許可しません。

プライオリティ キューに、必要だとわかっている帯域幅より少し多めに割り当てるのが最も安全です。たとえば、音声送信に通常必要な 24 kbps の帯域幅をプライオリティ キューに割り当てたとします。この割り当ては、音声パケットの送信が固定ビット レートで発生するため安全に思えます。しかし、ネットワークとルータまたはスイッチが帯域幅の一部を使用する場合があり、これがジッタや遅延を生じさせます。そのため、必要な帯域幅より少し多め(25 kbps など)に割り当て、一定性と可用性を確実にします。

IP RTP プライオリティ アドミッション コントロール ポリシーは、RTP ヘッダー圧縮を考慮します。したがって、 ip rtp priority コマンドの bandwidth パラメータを設定している間は、圧縮コールの帯域幅の設定のみが必要です。たとえば、G.729 音声コールで 24 kbps 非圧縮帯域幅(レイヤ 2 ペイロードを含まず)が必要なのに対し、12 kbps の圧縮帯域幅のみの場合、12 kbps の帯域幅のみを設定する必要があります。複数のコールがある場合は、すべてのコールに十分な帯域幅を割り当てる必要があります。

インターフェイス上の音声およびデータ フローに割り当てたすべての帯域幅の合計は、使用可能帯域幅全体の 75 パーセントを超えることはできません。音声パケットへの帯域割り当ては、ペイロードに加えて IP、RTP、UDP ヘッダーを考慮しますが、レイヤ 2 ヘッダーは考慮しません。他のオーバーヘッドに対し 25 パーセントの帯域幅を割り当てるのが、慎重で安全です。PPP リンクでは、たとえば、レイヤ 2 ヘッダーのオーバーヘッドが 4 kbps だと推定します。IP RTP プライオリティで設定可能な帯域幅は、インターフェイスの max-reserved-bandwidth コマンドで変更可能です。

リンクの追加オーバーヘッドで、どのくらいの帯域幅が必要かがわかれば、音声トラフィックにできるかぎり多くの帯域幅を割り当てたいアグレッシブな環境下では、すべてのクラスまたはフローに割り当てられた帯域合計の 75 パーセントという最大割り当て量を、 max-reserved-bandwidth コマンドを使用して上書きできます。固定帯域幅を上書きする場合は、注意し、ベストエフォートおよびコントロール トラフィック、レイヤ 2 オーバーヘッドをサポートするのに十分な帯域幅を残すようにしてください。

他の代替手段として、音声トラフィックが、データよりもはるかに重要な場合、フローやクラスに使用されている帯域の 75 パーセントのほとんどを音声プライオリティ キューに割り当てることができます。指定したいずれの点でも使用されない帯域幅は、他のフローまたはクラスで使用可能になります。

制約事項

ip rtp priority コマンドは他のトラフィックよりも高い絶対優先度を指定するため、注意して使用してください。輻輳時に、トラフィックが設定した帯域幅を超えた場合、その超過したトラフィックはすべてドロップします。

ip rtp reserve および ip rtp priority コマンドは、同じインターフェイス上に設定できます。

フレームリレー IP RTP プライオリティ

フレームリレー IP RTP プライオリティ機能で、遅延に影響されやすい音声などのデータに対する完全プライオリティ キューイング方式をフレームリレー PVC 上で実現できます。音声トラフィックは、自身の RTP のポート番号で識別され、 frame-relay ip rtp priority コマンドで設定されたプライオリティ キューに分類されます。この機能を使用すると、音声は他の非音声トラフィックよりも高い優先順位の絶対優先として扱われます。

この機能は、フレームリレー PVC でサポートする ip rtp priority コマンドの機能性を拡張します。この機能で、同じ出力インターフェイス上の他のすべてのキューまたはクラスより高い絶対優先が音声トラフィックに保証される UDP ポートの範囲を指定できます。絶対優先とは、パケットがプライオリティ キューに存在する場合、そのパケットは他のキューのパケットがキュー解除される前にキュー解除され、送信されることを意味します。この処理は、インターフェイス レベルではなく、PVC 単位ベースで実行されます。

フレームリレー IP RTP プライオリティの設定方法については、『 Configuring Weighted Fair Queueing 』モジュールを参照してください。

フレームリレー PVC インターフェイス プライオリティ キューイング

フレームリレー PVC Interface Priority Queueing(PIPQ; PVC インターフェイス プライオリティ キューイング)機能で、パケット コンテンツではなく宛先 PVC に基づく優先順位付けの、インターフェイスレベルのプライオリティ キューイング方式を実現します。たとえば、Frame Relay(FR; フレームリレー)PIPQ で、音声トラフィック伝送 PVC がシグナリング トラフィック伝送 PVC よりも高い絶対優先順位を持つよう設定でき、シグナリング トラフィック伝送 PVC がデータ伝送 PVC よりも高い絶対優先順位を持つよう設定できます。

フレームリレー PIPQ の設定方法については、『 Configuring Weighted Fair Queueing 』モジュールを参照してください。フレームリレーの情報については、『 Configuring Frame Relay 』モジュールを参照してください。

フレームリレー PIPQ には、高、中、普通、低の 4 レベルの優先順位があります。インターフェイスでは、フレームリレー パケットの Data-Link Connection Identifier(DLCI; データリンク接続識別子)の値が調べられます。その後、パケットは、その DLCI に設定されている優先順位レベルに基づいて正しいプライオリティ キューに送信されます。


) フレームリレー PIPQ を使用する場合、異なる種類のトラフィックが別々の PVC で伝送されるよう、ネットワークを設定します。フレームリレー PIPQ は、個々の PVC が異なる QoS 要件を持つ異なるトラフィックの種類を伝送する際に使用されることを目的としていません。


PVC には、フレームリレー マップ クラス内で優先順位を割り当てます。そのマップ クラスを使用、または継承するすべての PVC が、設定した優先順位に従ってクラス分けされます。PVC に関連付けられているマップ クラスがない場合や、関連付けられているマップに優先順位が明示的に設定されていない場合は、その PVC のパケットはデフォルトの「普通」プライオリティ キューにキューイングされます。

インターフェイス コンフィギュレーション モードで frame-relay interface-queue priority コマンドを使用してインターフェイスでフレームリレー PIPQ をイネーブルにしないと、マップ クラス内の PVC プライオリティの設定は有効になりません。このとき、4 つのプライオリティ キューのサイズ(最大パケット数)を設定することもできます。

フレームリレー PIPQ は、Frame Relay Traffic Shaping(FRTS; フレームリレー トラフィック シェーピング)および FRF.12(またはそれより上位)と併用することも、単独で使用することもできます。インターフェイスレベルのプライオリティ キューイングは、FRTS および RFF.12(またはそれより上位)で通常使用される FIFP キューイングまたはデュアル FIFO キューイングの代わりとなります。FR PIPQ で割り当てられた PVC プライオリティは、FRF.12 プライオリティよりも優先されます。つまり、同じ PVC 宛のすべてのパケットは、フラグメント化されているかどうかに関わらず、同じインターフェイス キューでキューイングされます。


) 高優先順位の PVC は、音声トラフィックの小さなパケットのみ伝送することがほとんどですが、想定外の大きなパケットから保護するため、これらの PVC で FRF.12(またはそれより上位)を設定することもできます。


制約事項

フレームリレー PIPQ には次のような制約事項が適用されます。

ループバックまたはトンネル インターフェイス、または明示的にプライオリティ キューイングを許可していないインターフェイスではサポートされません。

ハードウェア圧縮ではサポートされません。

すでに FIFO キューイング以外のキューイングが設定されているインターフェイスではイネーブルにできません。FR PIPQ は、WFQ が設定されている場合、WFQ がデフォルトのインターフェイス キューイング方式である限り、イネーブルになります。

前提条件

次の前提条件が、フレームリレー PIPQ に適用されます。

PVC は単一種類のトラフィックを伝送するよう設定する必要があります。

ネットワークは、適切なコール アドミッション コントロールを用いて、プライオリティ キューのいずれかが足りなくならないようにする必要があります。

低遅延キューイング

LLQ 機能で、完全 PQ が CBWFQ に導入されます。完全 PQ では、音声などの遅延に敏感なデータを、他のキューのパケットをキューから取り出す前にキューから取り出して送信できます。

LLQ を使用しないと、CBWFQ はリアルタイム トラフィックで使用可能な完全プライオリティ キューがない、定義済みクラスに基づいて WFQ を実施します。CBWFQ で、トラフィック クラスを定義でき、そのクラスに特性を割り当てられます。たとえば、輻輳中にクラスに適用する最小帯域幅を指定できます。

CBWFQ では、特定のクラスに属するパケットの重みは、設定時にそのクラスに割り当てた帯域幅から適用されます。したがって、クラスのパケットに割り当てた帯域幅で、パケットの送信順が決定されます。すべてのパケットは、重み付けに基づいて均等に処理されます。パケットにクラスがない場合は、絶対優先を付与できます。この方式では、大きな遅延、特に遅延の変化が許されない音声トラフィックに問題が起こります。音声トラフィックでは、遅延の変動により、カンバセーションの聞き取りにおいてジッタとして現れる転送の不規則性が生じます。

LLQ は、CBWFQ で完全プライオリティ キューイングを実現し、音声カンバセーションでのジッタを減らします。 priority コマンドで設定すると、LLQ は CBWFQ 内の単一の、完全プライオリティ キューをクラス レベルでイネーブルにし、クラスに属するトラフィックを CBWFQ 完全プライオリティ キューに誘導できます。クラス トラフィックを完全プライオリティ キューに入力するには、ポリシー マップの名前が付いたクラスを指定し、 priority コマンドをクラスに設定します ( priority コマンドが適用されるクラスは、プライオリティ クラスだと見なされます)。ポリシー マップで、1 つまたは複数の優先ステータスを指定できます。1 つのポリシー マップに複数のクラスがプライオリティ クラスとして設定されている場合、これらのクラスからのトラフィックはすべて、同じ単一の完全プライオリティ キューに入力されます。

CBFWQ で使用される完全 PQ と CBWFQ 外で使用される完全 PQ との違いの 1 つに、パラメータの取る値があります。CBWFQ 外では、 ip rtp priority コマンドを使用して音声トラフィック フローで特定の優先処理が行われる UDP ポートの範囲を指定できます。 priority コマンドを使用すると、優先フローを規定する UDP ポート番号に制限がなくなります。CBWFQ 内でクラスに優先ステータスを設定できるためです。その代わり、クラスのトラフィックの指定に使用される有効な一致基準はすべて、プライオリティ トラフィックに適用されるようになります。クラスへのトラフィックの指定方式には、アクセス リスト、プロトコル、入力インターフェイスの一致などがあります。さらに、アクセス リストで、トラフィックの一致が、IP ヘッダーの ToS バイトの最初の 6 ビットを使用して設定した IP Differentiated Services Code Point(DSCP; IP DiffServ コード ポイント)値に基づいたトラフィックの一致が可能になるよう指定できます。

さまざまな種類のリアルタイム トラフィックを完全プライオリティ キューに入力できますが、音声トラフィックのみを指定することを強く推奨します。音声トラフィックは正常に動作し、他の種類のリアルタイム トラフィックはそうではないためです。また、音声トラフィックは、ジッタを回避するため遅延が変動しない必要があります。ビデオなどのリアルタイム トラフィックは遅延による変動が生じ、正常な音声トラフィック伝送に必要な、遅延の安定性を妨げます。

LLQ の設定方法については、『 Configuring Weighted Fair Queueing 』モジュールを参照してください。

LLQ 帯域割り当て

クラスに priority コマンドを指定すると、このコマンドは最大帯域幅を kbps で指定する bandwidth 引数を取ります。このパラメータを使用して、 priority コマンドで設定されたクラスに属したパケットに割り当てる最大帯域幅を指定します。帯域幅パラメータは、プライオリティ クラスへの帯域幅を保証し、プライオリティ クラスからのパケットのフローを抑制します。

輻輳時には、帯域幅を超えた場合にパケットをドロップするためにポリシングが使用されます。プライオリティ キューに入力された音声トラフィックは UDP ベースのため、WRED の早期パケット ドロップ特性には対応しません。WRED が無効なため、WRED の random-detect コマンドは priority コマンドと併用できません。さらに、パケットのドロップにポリシングが使用され、キュー制限が行われないため、 queue-limit コマンドは priority と併用できません。

輻輳が起こると、プライオリティ キュー宛のトラフィックはそのトラフィックが属するクラスに設定された帯域割り当てに超過していないか測定されます。

プライオリティ トラフィック測定には次の特性があります。

CAR のレート制限機能と非常に似ていますが、プライオリティ トラフィック測定は輻輳状態下でのみ実行されます。デバイスが輻輳していない場合、プライオリティ クラス トラフィック は割り当てられた帯域幅を超えることができます。デバイスが輻輳している場合、割り当てられた帯域幅を超えるプライオリティ クラス トラフィックは破棄されます。

これはパケット単位ベースで行われ、トークンはパケットが送信されるにつれいっぱいになります。パケット送信に使用できるトークンが十分でない場合、ドロップします。

プライオリティ トラフィックを割り当てられた帯域幅に抑制して、ルーティング パケットやその他のデータなどの非プライオリティ トラフィックが不足しないようにします。

測定をしたクラスは個別にポリシングされレート制限されます。つまり、単一のポリシー マップは 4 つのプライオリティ クラスを含むことができますが、単一のプライオリティ キューに入力されたものはすべて、それぞれ個別の帯域割り当てと制限を持つ個別のフローとして処理されます。

プライオリティ クラスの帯域幅は priority コマンドのパラメータとして指定されるため、同時に bandwidth ポリシーマップ クラス コンフィギュレーション コマンドをプライオリティ クラスに設定することはできません。2 つ同時に設定すると、割り当てる帯域幅の大きさに関して混乱を招くだけの設定違反となります。

プライオリティ キューに割り当てられた帯域幅には、常にレイヤ 2 カプセル化ヘッダーが含まれます。しかし、ATM セル タックス オーバーヘッドなどの他のヘッダーは含まれません。特定のプライオリティ クラスに割り当てる帯域幅を計算する際は、レイヤ 2 ヘッダーもそれに含まれるということを考慮する必要があります。ATM が使用されている場合、ATM セル タックス オーバーヘッドが含まれないということを考慮する必要があります。また、音声パスのルータによって生じるジッタの可能性も帯域幅に考慮する必要があります。

これは、ATM を使用する場合に考慮します。1 秒あたり 50 パケット送出する 60 バイトの音声ストリームが、G.729 を使用してエンコードされるとします。音声ストリームをセルに変換する前に、音声ストリームで使用されるプライオリティ キューのメートルで、レイヤ 2 Logical Link Control(LLC; 論理リンク制御)ヘッダーが追加された後のパケット長を計ります。

8 バイト レイヤ 2 LLC ヘッダーの場合、メートルで 68 バイト パケットが考慮されます。ATM セルの長さが標準の 53 バイトのため、68 バイトのパケットは、回線上に送信される前に 2 つの 53 バイトの ATM セルに分割されます。結果、このフローで使われる帯域幅はパケットあたり 106 バイトです。

この場合、次に、帯域幅が最低 27.2 kbps(68 × 50 × 8 = 27.2 kbps)となるように設定する必要があります。しかし、ATM セル タックス オーバーヘッドも考慮しなければならないことを思い出してください。このオーバーヘッドは、設定された帯域幅に含まれていません。つまり、すべてのクラスの帯域幅合計は、最低 15.2 kbps([106 - 68] × 50 × 8 = 15.2 kbps)のインターフェイス帯域幅よりも少なくなければなりません。また、ルータが生み出すジッタの帯域幅も考慮する必要があります。


) 1 つのインターフェイスのすべての帯域割り当ての合計が、使用可能なインターフェイス帯域幅の総計の 75 パーセントを超えることはできません。しかし、クラスにインターフェイス帯域幅の 75 パーセント以上を設定する必要があるアグレッシブな環境の下では、すべてのクラスまたはフローに割り当てられた、この 75 パーセントという 最大合計値を max-reserved-bandwidth コマンドで上書きできます。max-reserved-bandwidth コマンドは、メイン インターフェイスのみでの使用を目的としています。Virtual Circuit(VC; 仮想回線)または ATM Permanent Virtual Circuit(PVC; 相手先固定接続)では無効です。


LLQ と IP RTP プライオリティの併用

LLQ と IP RTP プライオリティは同時に設定できますが、IP RTP プライオリティが優先されます。併用することでどのように動作するかを示すため、次の設定を考えます。

policy-map llqpolicy
class voice
priority 50
 
ip rtp priority 16384 20000 40
service-policy output llqpolicy
 

この例では、16384 ~ 20000 ポート範囲に一致するパケットは 40 kbps の帯域幅のプライオリティが付与されます。音声クラスに一致するパケットは 50 kbps の帯域幅のプライオリティが付与されます。輻輳時は、16384 ~ 20000 ポート範囲に一致するパケットは 40 kbps を超えて帯域幅を使用できず、音声クラスに一致するパケットは 50 kbps を超えて帯域幅を使用できません。

両方の基準に一致するパケット(ポートが 16384 ~ 20000 でクラスが音声)の場合、IP RTP プライオリティが優先されます。この例では、パケットは 16384 ~ 20000 のポート範囲で 40 kbps の帯域幅に含まれています。

LLQ および認定バースト サイズ

LLQ の機能が拡張され、Committed Burst(Bc; 認定バースト)サイズを LLQ で指定できるようになりました。この機能は、低遅延キューイング機能のバースト サイズの設定で行います。この新機能を使用すると、ネットワークで一時的なトラフィックのバーストに対応でき、ネットワーク トラフィックをより効率的に扱えます。


) LLQ で使用されるデフォルトの Bc サイズは、音声タイプのバーストなしのトラフィックを扱うことを目的としています。LLQ を設定して非音声アプリケーションのトラフィックを処理したい場合、ネットワークで使用するアプリケーションに基づき、それに応じてバースト サイズを増やす必要があります。


ATM アダプタでの LLQ および VC 単位ホールド キューのサポート

デフォルトで、使用するキューイング メカニズムで、ホールド キューのサイズを決定し、それに伴ってキューに保持するパケット数を決定します。ATM アダプタでの VC 単位ホールド キューのサポートを設定できる機能で、デフォルトのホールド キュー サイズを拡張し、キューが保持できるパケット数を変更する(または多様にする)ことができます。この新機能で、ホールド キューで最大 1024 パケット保持できます。

この機能で、ホールド キューに保持されるパケット数を VC 単位で、VC 単位キューイングをサポートする ATM アダプタで指定できます。


) この機能は、Cisco 7200 シリーズ ルータと、VC 単位キューイングをサポートする Cisco 2600 および 3600 シリーズのアダプタのみでサポートされます。


VC 単位および ATM 設定に関連する情報については、『 IP to ATM Class of Service Overview 』モジュールおよび『 Configuring IP to ATM Class of Service 』モジュールを参照してください。

LLQ を使用する理由とは

LLQ を設定する必要があるかどうかを決定する際に考慮すべき一般的な要素の一部には次のようなものがあります。

LLQ は、ATM VC とシリアル インターフェイス上で厳密な優先サービスを提供します (RTP プライオリティ機能では、インターフェイスでのみプライオリティ キューイングが可能になります)。

LLQ は、UDP ポート番号に制限されません。プライオリティ ステータスを CBWFQ のクラスに設定できるため、優先フローを規定する際、UDP ポート番号による制限がなくなります。その代わり、クラスのトラフィックの指定に使用される有効な一致基準はすべて、プライオリティ トラフィックに適用されるようになります。

クラスに属するパケットに割り当てる最大帯域幅を設定することにより、非プライオリティ トラフィックの帯域幅が不足しないようにできます。

制約事項

LLQ には、次のような制約事項が適用されます。

アクセス リストを使用してマッチング ポート番号を設定する場合、この機能で奇数も偶数も含めすべてのポート番号に対するプライオリティ マッチングを実現します。音声は一般に偶数のポート番号に存在し、コントロール パケットは奇数のポート番号に生成されるため、コントロール パケットにも、この機能を使用して優先順位を付与することができます。非常に低速なリンクでは、音声とコントロール パケットの量号に優先順位を付与することで、音声品質が低下する場合があります。したがって、ポート番号に基づいてプライオリティの割り当てのみを行う場合は、 priority コマンドではなく ip rtp priority コマンドを使用してください ( ip rtp priority コマンドでは、偶数のポート番号にのみプライオリティを付与します)。

random-detect コマンド、 queue-limit コマンド および bandwidth ポリシーマップ クラス コンフィギュレーション コマンドは priority コマンドが設定されているときは使用できません。

priority コマンドは複数のクラスで設定できますが、音声タイプの Constant Bit Rate(CBR; 固定ビット レート)トラフィックでのみ使用してください。

分散型低遅延キューイング

分散型 LLQ 機能で、VIP ベースの Cisco 7500 シリーズ ルータ(PA-A3-8T1IMA モジュール搭載のものを除く)で、トラフィック クラスの低遅延動作を指定できます。LLQ では、音声などの遅延に敏感なデータを、他のキューのパケットをキューから取り出す前にキューから取り出して送信できます。

分散型 LLQ 機能では、デバイス送信リングの深さを制限することもできます。分散型 LLQ を導入する前は、最大送信リングの深度はユーザが定義できないパラメータでした。したがって、粒子を送信リングに無制限に蓄積する可能性があり、高い遅延が避けられなくなることがありました。分散型 LLQ 機能で、ユーザが送信リングに存在する粒子の数を制限でき、その送信リングにあるパケットにより引き起こされる遅延を効果的に低下できます。

遅延に影響されやすいデータが最初にキュー解除され、送信されるようにするには、 priority コマンドを使用します。LLQ で、個々のトラフィックのクラスを配置できる単一のプライオリティ キューを使用できるようになります。クラス トラフィックをプライオリティ キューに入力するには、 priority コマンドを、ポリシー マップでネームド クラスを指定してから設定します。プライオリティ キューで使用できる帯域幅は、帯域幅を kbps で設定するか、すべての使用可能帯域幅の割合(Cisco IOS Release 12.1(5)T 以降)のどちらかで指定できます。

ポリシー マップで、1 つまたは複数のクラスにプライオリティ ステータスを指定できます。1 つのポリシー マップに複数のクラスがプライオリティ クラスとして設定されている場合、これらのクラスからのトラフィックはすべて、同じ単一のプライオリティ キューに入力されます。

tx-ring-limit コマンドで、ユーザが送信リングで保持できる粒子数を指定でき、その送信リングの遅延を効果的に低下できます。1 つのパケットに複数の粒子を含むことができ、一般的な粒子は、サイズが 512 バイトです(このサイズは、インターフェイスの種類によって異なります。インターフェイスの種類によっては、一般的な粒子サイズは 256 バイトです)。これらの粒子は、送信リングに蓄積されず、避けられない高遅延を引き起こすこともなくなります。

分散型 LLQ は、VIP 搭載の Cisco 7500 RSP シリーズ ルータ(PA-A3-8T 1IMA モジュールが設定されている場合を除く)でサポートされています。

また、この機能は クラスベース Quality of Service MIB もサポートします。

分散型 LLQ の設定方法については、『 Configuring Weighted Fair Queueing 』モジュールを参照してください。

priority コマンドを使用した帯域幅の保証

トラフィック クラスに priority コマンドを使用する方法の 1 つに、最大帯域幅を kbps で指定する、 bandwidth 引数を指定する方法があります。トラフィック クラスに priority コマンドを使用する方法には他に、Cisco IOS Release 12.1(5)T で導入された、プライオリティ キューに予約する使用可能帯域幅の割合を指定する方法もあります。 bandwidth の値または割合により、設定した帯域幅を、最悪の輻輳シナリオでもプライオリティ クラスに保証します。超過した帯域幅が使用可能な場合、プライオリティ クラスは、その帯域幅を使用できます。超過帯域幅が使用できない場合、プライオリティ トラフィックは、パケットをドロップして設定されたレートに抑制されます。帯域幅の値に設定された個々のクラスごとに、個々のレートに抑制されるトラフィックがあります。クラスがその個々のレートで抑制されると、そのトラフィックは、トークン バケット メカニズムがストリームをポリシングするため、一定のバースト性が許可されます。このバースト性は、 priority コマンドのオプションの burst パラメータでコントロールします(このバースト性は、使用可能帯域幅の割合に基づいてプライオリティ キューが指定されている場合は、指定できません)。 burst パラメータで、トークン バケット ドロップ パラメータを超えてワンタイム バーストとしてトークン バケットを通過できるトラフィック量をバイトで指定します。デフォルトのバースト値は、設定されたトークン バケット ドロップ パラメータで 200 ミリセカンドのトラフィックです。

プライオリティ クラスの帯域幅は priority コマンドのパラメータとして指定されるため、同時に bandwidth コマンドをプライオリティ クラスに設定することはできません。2 つ同時に設定すると、割り当てる帯域幅の大きさに関して混乱を招くだけの設定違反となります。

プライオリティ キューに割り当てられた帯域幅には、常にレイヤ 2 カプセル化ヘッダーが含まれます。しかし、ATM セル タックス オーバーヘッドなどの他のヘッダーは含まれません。特定のプライオリティ クラスに割り当てる帯域幅を計算する際は、レイヤ 2 ヘッダーもそれに含まれるということを考慮する必要があります。ATM が使用されている場合、ATM セル タックス オーバーヘッドが含まれないということを考慮する必要があります。また、音声パスのルータによって生じるジッタの可能性も帯域幅に考慮する必要があります。

ATM を使用する場合を考えます。1 秒に 50 パケット送信する 60 バイトの音声ストリームが、G.729 を使用してエンコードされています。音声ストリームをセルに変換する前に、音声ストリームで使用されるプライオリティ キューのメートルで、レイヤ Logical Link Control(LLC; 論理リンク制御)ヘッダーが追加された後のパケット長を計ります。

8 バイト レイヤ 2 LLC ヘッダーの場合、メートルで 68 バイト パケットが考慮されます。ATM セルの長さが標準の 53 バイトのため、68 kbps のパケットは、回線上に送信される前に 2 つの 53 バイトの ATM セルに分割されます。結果、このフローで使われる帯域幅はパケットあたり 106 バイトです。

この場合、次に、帯域幅が最低 27.2 kbps(68 × 50 × 8 = 27.2 kbps)となるように設定する必要があります。しかし、ATM セル タックス オーバーヘッドも考慮しなければならないことを思い出してください。このオーバーヘッドは、設定された帯域幅に含まれていません。つまり、すべてのクラスの帯域幅合計は、最低 15.2 kbps([106 - 68] × 50 × 8 = 15.2 kbps)のインターフェイス帯域幅よりも少なくなければなりません。また、ルータが生み出すジッタの帯域幅も考慮する必要があります。

利点

ATM VC およびシリアル インターフェイスにプライオリティ サービスを実現

PQ 方式では、音声などの遅延に敏感なデータを、他のキューのパケットをキューから取り出す前にキューから取り出して送信できます。この機能は、ATM VC の PQ で使用できます。

アドミッション コントロール

クラスに属するパケットに割り当てる最大帯域幅を設定することにより、非プライオリティ トラフィックの帯域幅が不足しないようにできます。

送信リング上の粒子の制限

分散型 LLQ 機能で、送信リングの粒子制限も導入されます。分散型 LLQ を導入する前は、送信リングの深度はユーザが定義できませんでした。したがって、送信リングでの高遅延の発生は避けられませんでした。

分散型 LLQ 機能で、送信リング状の粒子数を事前設定した制限に限定でき、送信リング上の遅延を効果的に減らせます。

制約事項

分散型 LLQ 機能には、次のような制約事項が適用されます。

アクセス リストを使用してマッチング ポート番号を設定する場合、この機能ですべてのポート番号に対するプライオリティ マッチングを実現します。音声は一般に偶数のポート番号に存在し、コントロール パケットは奇数のポート番号に生成されるため、コントロール パケットにも、この機能を使用して優先順位を付与することができます。非常に低速なリンクでは、音声とコントロール パケットの量号に優先順位を付与することで、音声品質が低下する場合があります。

priority コマンドは、 set コマンドと併用できます。 priority コマンドは、 random-detect queue-limit 、および bandwidth コマンドなどの、その他のコマンドとは併用できません。

priority コマンドは、複数のトラフィック クラスで設定できます。トラフィックが CBR トラフィックではない場合、 bandwidth-kbps パラメータを、データのバーストを吸収できるくらい十分に大きく設定する必要があります。

使用可能帯域幅の 1 パーセントが、デフォルトのトラフィック クラスで予約されるため、 bandwidth percent および priority percent コマンドでは、99 パーセントを超えて予約することはできません。

プライオリティ キューは、サイズまたは割合の値のいずれかにより予約できますが、両方を同じポリシー マップで使用することはできません。したがって、 priority コマンドがポリシー マップで percent オプションなしで使用されている場合、 bandwidth コマンドも、使用されている場合は、 percent オプションなしで使用する必要があります。また、その反対も同様です。同様に、 priority percent コマンド がポリシー マップで使用されている場合、 bandwidth percent コマンドを使用して、クラスの帯域割り当てを指定する必要があります。また、その反対も同様です。 priority および priority percent コマンドも、同じポリシー マップでは使用できません。

bandwidth および priority コマンドは、同じクラス マップで使用できません。しかしこれらのコマンドは、同じポリシー マップでは一緒に使用できます。

次のコマンドは、 priority コマンドと同じクラスまたはポリシー マップで使用できません。

priority percent

bandwidth percent

次のコマンドは、 priority percentage コマンドと同じクラスまたはポリシー マップで使用できません。

priority percent オプションなし)

bandwidth percent オプションなし)

tx-ring-limit コマンドは、PA-A3 ポート アダプタの VBR VC でのみ影響があります。 tx-ring-limit コマンドは、UBR VC には影響を与えません。

DLLQ は、PA-A3-8T1IMA モジュール付き Cisco 7500 シリーズ ルータをサポートしません。

前提条件

この機能を使用するには、次の内容を理解している必要があります。

ACL

ATM PVC

帯域幅管理

CBWFQ

LFI

バーチャル テンプレートおよびバーチャル アクセス インターフェイス

フレームリレー向け低遅延キューイング

フレームリレー向け LLQ で、音声トラフィックへの完全プライオリティ キューイングおよび他のトラフィックのクラスへの重み付け均等化キューイングを行えます。この機能で、LLQ は、FRTS が設定されている場合にフレームリレー VC レベルで使用できます。

LLQ は PQ/CBWFQ とも呼ばれ、特に RTP 優先順位付けや PQ/WFQ において以前のフレームリレー QoS が提供する機能よりも上位集合でフレキシブルです。

RTP 優先順位付けおよび PQ/WFQ を使用すると、特定の UDP/RTP ポート範囲に一致するトラフィックは、高優先順位であると見なされ、Priority Queue(PQ; プライオリティ キュー)に割り当てられます。フレームリレー向け LLQ で、プロトコル、インターフェイス、またはアクセス リストに従ってトラフィックのクラスを設定し、ポリシー マップを定義して、プライオリティ キューおよび重み付け均等化キューでのクラスの処理方法を設定します。

キューは、per-PVC ベースで設定されます。それぞれの PVC に PQ があり、均等化キューの割り当て数があります。均等化キューは、各クラスに必要な帯域幅に比例して重みが割り当てられます。他の帯域幅よりも 2 倍の帯域幅を必要とするクラスは、重みが半分になります。帯域幅の引き受け超過は、許可されません。CLI は、合計帯域幅が超過するような変更は拒否します。この機能は、IP precedence に基づいてフローに重みが割り当てられる WFQ と異なります。WFQ では、高優先トラフィックがより多くの帯域幅を比例的に取得できますが、フローが多くなるほど、各フローで使用できる帯域幅は少なくなります。

PQ は、均等化キューで帯域幅が不足しないようにポリシングされます。PQ を設定する場合、そのキューで使用できる最大帯域幅を kbps で指定します。最大帯域幅を超えるパケットはドロップされます。均等化キューのポリシングはありません。

フレームリレー向け LLQ は、 class-map policy-map 、およびフレームリレー マップ クラス コマンドを組み合わせて使用し、設定されます。 class-map コマンドで、プロトコル、インターフェイス、アクセス リストに従ってトラフィック クラスを定義します。 policy-map コマンドで、帯域幅、優先順位、キュー制限、または WRED に従って各クラスのキューイング システムでの処理方法を定義します。 service-policy output マップ クラス コマンドで、ポリシー マップをフレームリレー VC に適用します。

トラフィック シェーピング、IP precedence の設定、ポリシングなどの、LLQ に直接関係のないポリシーは、フレームリレー VC の class-map および policy-map コマンドではサポートされません。これらのポリシーを設定するには、マップ クラス コマンドなどの他の設定メカニズムを使用する必要があります。

フレームリレー 向け LLQ の設定方法については、『 Configuring Weighted Fair Queueing 』モジュールを参照してください。

制約事項

次のクラス マップおよびポリシー マップのみがサポートされます。

match クラスマップ コンフィギュレーション コマンド

priority bandwidth queue-limit random-detect 、および fair-queue ポリシーマップ コンフィギュレーション コマンド

前提条件

次のタスクを完了してから、フレームリレー向け LLQ をイネーブルにしてください。

FRTS をインターフェイスでイネーブルにする。

出力サービス ポリシーを、インターフェイス、サブインターフェイス、または DLCI に関連付けられたマップ クラスで設定する。

マップ クラスで設定されている FIFO キュー以外のキューをすべて削除する。フレームリレー向け LLQ は、すでに非 FIFO キューが設定されている場合は、フラグメンテーションがイネーブルになっている場合に作成されたデフォルトのキューを除いて、設定できません。

機能のしくみ

フレームリレー向け LLQ は、次のセクションで説明する機能と併用されます。

RTP 優先順位付け

Voice over Frame Relay

Frame Relay Fragmentation(FRF; フレームリレー フラグメンテーション)

IP シスコ エクスプレス フォワーディング スイッチング

RTP 優先順位付け

RTP 優先順位付けで、音声トラフィックに対する完全 PQ 方式を実施します。音声トラフィックは、自身の RTP のポート番号で識別され、 frame-relay ip rtp priority マップクラス コンフィギュレーション コマンドで設定されたプライオリティ キューに分類されます。RTP ポート番号の範囲を指定して、トラフィックを音声として分類します。トラフィックが指定した範囲と一致すると、音声として分類され、LLQ PQ およびインターフェイス プライオリティ キューにキューイングされます。トラフィックが指定された RTP ポート範囲内にない場合、LLQ 方式のサービス ポリシーで分類されます。

ip rtp priority コマンドが、インターフェイス コンフィギュレーション モードとマップクラス コンフィギュレーション モードの両方で使用できます。この機能では、 frame relay ip rtp priority マップクラス コンフィギュレーション コマンドのみがサポートされます。

Voice over Frame Relay

Voice over Frame Relay(VoFR)では、自身の PQ メカニズムではなく LLQ Priority Queue(PQ; プライオリティ キュー)を使用します。 frame-relay voice bandwidth マップクラス コンフィギュレーション コマンドで、VoFR トラフィックで使用可能な合計帯域幅を設定します。帯域幅を可視化することで、他のキューを最低 Committed Information Rate(CIR; 認定情報レート)から音声帯域幅を除いた大きさにすることができます。

frame-relay voice bandwidth マップクラス コンフィギュレーション コマンドで、コール アドミッション制御機能を設定することもできます。これにより、コールの許可の前に十分な VoFR 帯域幅が残っているようにします。コールが確立すると、音声トラフィックのポリシングはありません。

データがない VoFR では、すべての音声と呼制御パケットは、LLQ Priority Queueing(PQ)でキューイングされます。データがある VoFR では、VoFR PVC は、音声およびデータ パケットを異なるサブチャネルで伝送できます。VoFR データ パケットは、音声パケットの遅延と音声およびデータ トラフィックのスケーラビリティを良好に保つため、フラグメント化され音声パケットにインターリーブされます。

VoFR がイネーブルの場合、音声にプライオリティ クラスマップを設定する必要がないことに注意してください。フレームリレー向け LLQ で使用する VoFR コマンドは、 frame-relay voice bandwidth マップクラス コンフィギュレーション コマンドと vofr data フレームリレー DLCI コンフィギュレーション コマンドのみです。


) 推奨されませんが、PQ の他のトラフィックを、VoFR と同時に設定することも可能です。これを行うと、PQ の非 VoFR パケットのインターリーブができなくなるため遅延が起こり、PQ(およびそこにある VoFR パケット)が、フラグメント化されたパケット全体が送信されるまで、フラグメンテーション中のままになります。


Frame Relay Fragmentation(FRF; フレームリレー フラグメンテーション)

Frame Relay fragmentation(FRF.12)の目的は、音声パケットに過度の遅延を発生させずに、より低速のリンクでの音声およびデータ パケットをサポートすることです。大きいデータ パケットは、フラグメント化され、音声パケットにインターリーブされます。

FRF.12 が LLQ で設定されると、PQ に分類された小さなパケットは、LLQ PQ および高優先順位のインターフェイス キューの両方を、フラグメント化されずに通過します。PQ 宛の大きなパケットは、キュー解除されるとシェーピングされ、フラグメント化されます。

frame-relay fragment および service-policy マップクラス コンフィギュレーション コマンドを使用して、LLQ の FRF.12 の設定をイネーブルにします。

IP シスコ エクスプレス フォワーディング スイッチング

LLQ 機能は、IP CEF スイッチングに影響を与えません。

カスタム キューイング

CQ で、特定のバイト数を指定して、キューが処理されるたびにキューから転送でき、特定の最低帯域幅または遅延要求を使用するアプリケーション間でネットワーク リソースを共有できます。また、各キューの最大パケット数を指定することもできます。

CQ の設定方法については、『 Configuring Custom Queueing 』モジュールを参照してください。

機能のしくみ

CQ では、トラフィックの各クラスで使用できるパケット数またはバイト数を指定して、トラフィックを処理します。ラウンドロビン方式でキューを繰り返し、次のキューに移動する前に各キューに割り当てられた帯域幅の一部を送信することでキューを処理します。1 つのキューが空の場合、ルータは、パケットをパケットの送信準備ができている次のキューから送信します。

インターフェイスで CQ がイネーブルの場合、システムで、そのインターフェイスで 17 の出力キューが保持されます。1 から 16 までのキューを指定できます。それぞれの出力キューに関連付けられるのは設定可能なバイト カウントで、次のキューに移動する前に現在のキューから送信すべきバイト数を指定します。

キュー番号 0 は、システム キューです。これは、1 から 16 までの番号が付けられたキューのいずれかが処理されるまでは空です。システムは、キープアライブ パケットやシグナリング パケットなどの高優先順位のパケットを、このキューにキューイングします。他のトラフィックがこのキューを使用するようには設定できません。

1 から 16 までの番号は、連続してキューに順番に付けます(ラウンドロビン方式)。1 サイクルごとに各キューから、設定されたバイト カウントをキュー解除し、次のキューに移動する前に現在のキューのパケットを送信します。特定のキューが処理されている間は、パケットは、送信されたバイト数がキューのバイト カウントを超えるまで、またはキューが空になるまで送信されます。特定のキューで使用される帯域幅は、間接的に、バイト カウントとキューの長さで指定できます。

図 2 に、CQ の動作を示します。

図 2 カスタム キューイング

 

CQ で、回線がストレス下にある場合、アプリケーションまたは指定したアプリケーション グループが、事前設定した全容量の比率を超えて使用しないようにします。CQ は PQ と同様、スタティックに設定され、ネットワーク条件の変化に自動的に対応はしません。

大抵のプラットフォームでは、すべてのプロトコルは、この高速スイッチング パスに分類されます。

キューのバイト カウント値の決定

帯域幅を異なるキューに割り当てるためには、各キューにバイト カウントを指定する必要があります。

バイト カウントの使用方法

ルータは、バイト カウントを超えるまで、特定のキューにパケットを送信します。バイト カウント値を超えると、現在送信中のパケットは完全に送信されます。したがって、バイト カウントを 100 バイトに設定し、プロトコルのパケット サイズが 1024 バイトの場合、このキューは毎回の処理で、100 バイトではなく 1024 バイトを受信します。

たとえば、あるプロトコルに 500 バイトのパケットがあり、他のプロトコルに 300 バイトのパケットがあり、3 つ目のプロトコルに 100 バイトのパケットがあるとします。帯域幅を、この 3 つのプロトコルで平等に分割する場合、キューに 200、200、200 のバイト カウントをそれぞれ指定することができます。しかし、この設定では、33/33/33 の比率になります。ルータが最初のキューを処理する際に 500 バイトのパケットを 1 つ送信します。2 番目のキューを処理する際に 300 バイトのパケットを 1 つ送信します。3 番目のキューを処理する際は 2 つの 100 バイトのパケットを送信します。効率的な比率は、50/30/20 になります。

このように、バイト カウントの設定が低すぎると、意図しない帯域割り当てとなることがあります。

しかし、バイト カウントが大きすぎると、「ぎくしゃくした」配信になります。つまり、上記の例で、3 つのキューに 10 KB、10 KB、10 KB と割り当てると、キューが処理可能になるとそれぞれのプロトコルがすぐに処理されますが、キューがまた処理可能になるまで、時間がかかることがあります。より良い対処方法は、500 バイト、600 バイト、500 バイトカウントをキューに指定する方法です。この設定では、比率は 31/38/31 となり、許容範囲内といえます。

タイミングよくキューを処理し、設定した帯域割り当てを、要求される帯域割り当てとできるだけ近づけるようにするため、各プロトコルのパケット サイズに基づいて、バイト カウントを決定する必要があります。そうしないと、その割合と設定が合わなくなることがあります。


) CQ は、Cisco IOS Release 12.1 で修正されました。キューがすぐにすべて使用されてしまった場合や、キューからの最後のパケットが設定されたバイト カウントと正確に一致しない場合、不足分が記憶され、次にそのキューが処理される時に処理されます。Cisco IOS Release 12.1 から、以前の、キューの不足を考慮しない Cisco IOS リリースを使用する際に行っていたように、バイト カウントを正確に指定しなくてもよくなりました。



) Internetwork Packet Exchange(IPX)などの 一部のプロトコルでは、セッションの開始時にフレーム サイズをネゴシエートします。


バイト カウントの決定

正しいバイト カウントを決定するには、次の手順を実行します。


ステップ 1 各キューで、キューに割り当てたい帯域幅の割合を、パケット サイズに応じてバイトで分割します。たとえば、プロトコル A のパケット サイズが 1086 バイト、プロトコル B が 291 バイト、プロトコル C が 831 バイトだとします。A に 20 パーセント、B に 60 パーセント、C に 20 パーセントを割り当てます。比率は、次のようになります。

20/1086、60/291、20/831 または

0.01842, 0.20619, 0.02407

ステップ 2 数字を、最も低い数字で割って標準化します。

1, 11.2, 1.3

この結果は、各プロトコルが使用する帯域幅の割合が約 20、60、20 パーセントになるような、送信されるパケット数の比率です。

ステップ 3 このいずれかの比率の端数は、追加のパケットが送信されることを意味します。数字の端数を切り上げ、1 つ上の整数にして実際のパケット カウントを取得します。

この例では、実際の比率は 1 パケット、12 パケット、2 パケットになります。

ステップ 4 各パケット カウントに対応するパケット サイズを乗じて、このパケット数の比率をバイト カウントに変換します。

この例では、各キューから送信されるパケット数はそれぞれ、1086 バイトのパケットが 1 つ、291 バイトのパケットが 12 個、831 バイトのパケットが 2 つ、または 1086、3492、1662 バイトになります。これらが、CQ 設定で指定するバイト カウントです。

ステップ 5 この比率が示す帯域幅の分配を決定するため、最初に 3 つすべてのキューが処理された後に送信されるバイトの合計数を決定します。

(1 × 1086) + (12 × 291) + (2 × 831) = 1086 + 3492 + 1662 = 6240

ステップ 6 その後、各キューから送信される合計バイト数の割合を決定します。この割合は次のようになります。

1086/6240、3492/6240、1662/6240 = 17.4、56、26.6 パーセント

この結果は、目的の比率の 20/60/20 に近い値になっています。

ステップ 7 実際の帯域幅が、目的の帯域幅に近くない場合、元の比率の 1:11.2:1.3 を最良値で乗じ、3 つの整数値ができるだけ近づくようにします。使用する乗数は、整数である必要はありません。たとえば、この比率を 2 で乗ずると、2:22.4:2.6 となります。このとき、1086 バイトのパケットを 2 つ、291 バイトのパケットを 23 個、831 バイトのパケットを 3 つ、すなわち 2172/6693/2493 の合計 11,358 バイトを送信します。結果、比率は 19/59/22 パーセントになります。これは、前回よりも目的の比率に近づいた値です。


 

カスタム キューに割り当てる帯域幅は、次の式で計算されます。

(queue byte count / total byte count of all queues) * bandwidth capacity of the interface
 

ここで、帯域幅容量は、インターフェイスの帯域幅からプライオリティ キューの帯域幅を除いたものと等しくなります。

ウィンドウ サイズ

ウィンドウ サイズも、帯域幅の分配に影響を与えます。特定のプロトコルのウィンドウ サイズが 1 に設定されている場合、そのプロトコルは、確認応答を受信しない限り、キューに他のパケットを配置しません。CQ アルゴリズムでは、バイト カウントを超えたり、パケットがキューにない場合に、次のキューに移動します。

したがって、ウィンドウ サイズが 1 では、1 つのフレームのみが毎回送信されます。フレーム カウントを 2 キロバイトに設定し、フレーム サイズが 256 バイトの場合、キューが処理されるごとに 256 バイトのみが送信されます。

CQ を使用する理由とは

Cisco IOS QoS CQ 機能を使用して、使用可能帯域幅の固定比率をトラフィックに保証し、残りの帯域幅を他のトラフィックに残しておくようにして、潜在的な輻輳ポイントで特定のトラフィックに帯域幅を保証するようにします。たとえば、帯域幅の半分を SNA データに予約し、残りの半分を他のプロトコルで使用するようにできます。

特定の種類のトラフィックが、予約されている帯域幅を使用しない場合、未使用の帯域幅は、動的に他の種類のトラフィックに割り当てられます。

制約事項

CQ は、スタティックに設定され、ネットワーク条件の変化に対応はしません。CQ をイネーブルにすると、FIFO よりもパケットのスイッチに時間がかかります。これは、パケットがプロセッサ カードで分類されるためです。

プライオリティ キューイング

PQ で、ネットワークのトラフィックの優先順位付けの方法を定義できます。4 つのトラフィックの優先順位を設定します。パケットの特性に基づいて、ルータがトラフィックをこの 4 つのキューに格納するための一連のフィルタを定義できます。最高優先順位のキューは、最初にキューが空になるまで処理されます。その後、次に優先順位の高いキューが、続けて処理されます。

PQ の設定方法については、『 Configuring Priority Queueing 』モジュールを参照してください。

機能のしくみ

転送中、PQ は、プライオリティ キューを、低いプライオリティ キューよりも優先度が高い絶対優先扱いとします。高い優先度が指定された重要なトラフィックは、常に、より重要度の低いトラフィックよりも優先されます。パケットは、ユーザ指定の基準に基づいて分類され、高、中、普通、低の 4 つの出力キューのいずれかに、割り当てられた優先順位を基に配置されます。優先順位付けで分類されないパケットは、普通のキューに分類されます。図 3 で、この処理を図示します。

図 3 プライオリティ キューイング

 

パケットがインターフェイスに送出されると、そのインターフェイス上のプライオリティ キューが、優先順位の降順にパケットの有無を調査されます。高優先順位のキューが最初に調査され、その後、中優先順位が調査されるといったように調査されます。最高優先順位の先頭にあるパケットが選択され送信されます。この処理は、パケットが送信されるたびに繰り返されます。

キューの最大長は、長さ制限により定義されます。キューが、キュー制限よりも長い場合、制限外のパケットはすべてドロップします。


) プライオリティ出力キューイング メカニズムは、すべてのネットワーキング プロトコルからのトラフィックを管理するために使用できます。IP でパケット サイズの境界を設定することで、さらに詳細な調整を行うことができます。


パケットのプライオリティ キューイングへの分類方法

プライオリティ リストとは、パケットがプライオリティ キューに割り当てられる方法を記述したルールのセットです。プライオリティ リストは、さまざまなプライオリティ キューのデフォルトの優先順位やキュー サイズ制限も記述できます。

パケットは、次の基準で分類できます。

プロトコルまたはサブプロトコルの種類

着信インターフェイス

パケット サイズ

フラグメント

アクセス リスト

ネットワーク サーバからのキープアライブは、常に高いプライオリティ キューに割り当てられます。他のすべての管理トラフィック(Interior Gateway Routing Protocol(IGRP)のアップデートなど)を設定する必要があります。プライオリティ リスト メカニズムで分類されないパケットは、普通のキューに割り当てられます。

プライオリティ キューイングを使用する理由

PQ で、高優先順位のトラフィックを絶対優先扱いにでき、さまざまな WAN リンクを通過するミッションクリティカルなトラフィックが優先扱いを受けるようにします。さらに、PQ で、他のキューイング方式よりも速い応答時間を得られます。

どのインターフェイスでも、プライオリティ出力キューイングをイネーブルにできますが、輻輳があるシリアル インターフェイスの低帯域幅で使用するのが最良です。

制約事項

PQ の使用を選択する場合、低優先順位のトラフィックは、高優先順位のトラフィックが優先され、帯域幅が使用できないことが多いため、PQ を使用することで最悪の場合、低優先順位のトラフィックがまったく送信されない結果となる可能性を考慮してください。低優先順位のトラフィックがこのようなことにならないよう、高優先順位のトラフィックをレート制限するトラフィック シェーピングや CAR を使用できます。

PQ で、低速のインターフェイスで許容される追加オーバーヘッドが導入されますが、イーサネットのような高速のインターフェイスでは許容されない場合があります。PQ をイネーブルにすると、パケットのスイッチに時間がかかります。これは、パケットがプロセッサ カードによって分類されるためです。

PQ はスタティックな設定を使用しており、ネットワーク条件の変化に対応しません。

PQ は、トンネルではサポートされません。

帯域幅管理

RSVP、CBWFQ、LLQ、IP RTP プライオリティ、フレームリレー IP RTP プライオリティ、およびフレームリレー PIPQ はすべて、帯域幅を予約し、インターフェイスで予約された最大帯域幅まで使用できます。

帯域幅を割り当てるには、次のコマンドのいずれかを使用します。

RSVP では、 ip rsvp bandwidth コマンドを使用します。

CBWFQ では、 bandwidth ポリシーマップ クラス コンフィギュレーション コマンドを使用します。CBWFQ 帯域幅割り当ての詳細については、この章のセクション 「クラスベース重み付け均等化キューイング」 を参照してください。LLQ では、帯域幅を priority コマンドを使用して割り当てられます。LLQ 帯域幅割り当ての詳細については、この章のセクション「フレームリレー PVC インターフェイス プライオリティ キューイング」を参照してください。

IP RTP プライオリティでは、 ip rtp priority コマンドを使用します。IP RTP プライオリティの帯域幅割り当ての詳細については、この章のセクション「IP RTP プライオリティ」を参照してください。

フレームリレー IP RTP プライオリティでは、 frame-relay ip rtp priority コマンドを使用します。フレームリレー IP RTP プライオリティの詳細については、この章のセクション「フレームリレー IP RTP プライオリティ」を参照してください。

フレームリレー PVC インターフェイス プライオリティ キューイングでは、 frame-relay interface-queue priority コマンドを使用します。フレームリレー PIPQ RTP の詳細については、この章のセクション「フレームリレー PVC インターフェイス プライオリティ キューイング」を参照してください。

これらのコマンドを設定する際は、帯域幅制限に注意して、ネットワークの要件に応じて帯域幅を設定してください。すべての帯域幅の合計が、最大予約帯域幅を超えないように留意してください。デフォルトの最大帯域幅は、インターフェイスの使用可能帯域幅合計の 75 パーセントです。帯域幅の残りの 25 パーセントは、レイヤ 2 オーバーヘッド、ルーティング トラフィック、およびベストエフォート トラフィックなどのオーバーヘッドに使用されます。

最大予約帯域幅を変更する必要があることがわかった場合は、 max-reserved-bandwidth コマンドを使用して最大帯域幅を変更できます。 max-reserved-bandwidth コマンドは、インターフェイス上でのみ使用できます。VC では使用できません。ATM VC では、ATM セル タックス オーバーヘッドは、この 75 パーセントの最大予約帯域幅には含まれません。