 |
||
|
Cisco 7200/7500 の QoS（Quality of Service）
- Ravi Prakash
| 概要 |
バーチャル・プライベート・ネットワーク（VPN）、Voice over IP（VoIP）、およびミッションクリティカルな（企業リソース・プランニング（ERP）などの）トラフィック向けの差別化サービスといった、新しいサービスの利用が増えるにつれ、QoS（Quality of Service）を適用する必要性が最も重要になっています。
本資料では、Cisco IOS(R) ソフトウェアのバージョン 12.0 に関連して QoS を説明しており、Cisco 7200 および 7500 ルータ向け QoS ツールの全体的な概要を把握したいと考える企業およびサービス・プロバイダのお客様を対象としています。
図 1：QoS ツールの必要性を生み出した、広範囲のメディアおよび距離を通して動作するアプリケーションの多様性
QoS ツールは、メカニズムによる以下のグループ分けで検討されるのが最適です。
- 分類
- キューイングおよびスケジューリング（輻輳管理）
- 輻輳回避
- ポリシングおよびシェーピング
- シグナリング
- リンク効率メカニズム
| 分類 |
ネットワーク・トラフィックに対して差別化の処理を行う前に、まずトラフィックを分類し、特定パケットが他のパケットとは異なる処理を受けられるよう「マーク」もしくは「カラーリング」する必要があります。今日、Cisco IOS ツールでは、各種の基準に基づいてパケットを分類した後で、IP データグラムのヘッダにある IP 優先順位情報の 3 ビットを使用して、そのパケットにマーキングできます。
図 2：IP パケット・ヘッダの IP 優先順位フィールド
トラフィック分類のために、最大 6 個のサービス・クラスを定義することができます（これには、IP ヘッダのタイプ・オブ・サービス（ToS）フィールドにある 3 つの優先順位ビットが使用されますが、この値のうちの 2 つは、他の目的に予約されています）。これにより、他の QoS 機能を用いて、各トラフィック・クラスに対し輻輳管理、帯域割り当て、遅延範囲などのトラフィックハンドリング・ポリシーを適用することが可能になります。
図 3：エッジで行われるトラフィックの分類
分類オプションの例は、次のとおりです。
- 特定の T1 で受信されるすべてのパケットは、高優先順位に分類される（ポートベースの分類）
- すべての HTTP（ハイパーテキスト転送プロトコル）トラフィックは、中優先順位に分類される（アプリケーションの分類）
- 指定された IP アドレスからのビデオ・トラフィックは、中優先順位に分類される
- 特定の宛先向けに設定されたパケットは、高優先順位トラフィック（国際間のトラフィックまたはエクストラネットのプレミアム・カスタマ向けトラフィックなど）に分類される
| キューイングおよびスケジューリング（輻輳管理） |
Cisco 7200 および 7500 ルータでは、次の種類のキューイングが使用されます。
- プライオリティ・キューイング
- カスタム・キューイング
- フローベースの WFQ（均等化キューイング）
- CB-WFQ（クラスベースの均等化キューイング）
- DWFQ（分散型均等化キューイング）
プライオリティ出力キューイングにより、ネットワーク管理者は、指定されたインターフェースに関して、高、普通、中、低の 4 つのトラフィックの優先順位を定義できます。トラフィックがルータに送られると、この 4 つの出力キューの 1 つに割り当てられます。最高の優先順位キューのパケットが、最初に伝送されます。そのキューが空になると、次に高い優先順位キューのトラフィックが伝送されるといったように順次処理されます。
このメカニズムにより、輻輳中、最高の優先順位を持つデータは、より低優先順位のトラフィックにより遅延されないことが保証されます。プライオリティ・キューイングの使用方法の例は、次のとおりです。
- バイト・カウントが 200 未満の DECnet パケットに、中優先順位のキュー・レベルを割り当てる
- 特定の TCP ポート（Telnet トラフィックのポート 23 など）を送信元または宛先とする IP パケットに、中優先順位のキュー・レベルを割り当てる
- 送信元あるいは宛先ポートが UDP（User Datagram Protocol）のポート 53 である IP パケットに、中優先順位のキュー・レベルを割り当てる
- すべての IP パケットに、高優先順位のキュー・レベルを割り当てる
図 4：プライオリティ・キューイングおよび厳密なプライオリティ・スケジューリング
プライオリティ・キューイングを使用すると、低優先順位のトラフィックがロックアウトされる場合があるという、潜在的な望ましくない副作用があります。言い換えると、絶え間のないストリームに流れ込む高優先順位のトラフィックが多すぎる場合、低速のリンク上にある低優先順位のトラフィックが放置される可能性があります。低優先順位のトラフィックがまったく重要でない場合、これにより、望ましい結果が得られる場合があります。
カスタム・キューイングすべてのトラフィックに保証されたレベルのサービスを提供することが目的なら、カスタム・キューイングを使用できます。例えば、SNA（システム・ネットワーク・アーキテクチャ）トラフィックには使用可能な帯域の 25％を、TCP トラフィックには帯域幅の 10％を、残りの 65％は他のアプリケーションに割り当てる、といった指定が可能です。
図 5：カスタム・キューイング
カスタム・キューイングには利点がいくつかありますが、欠点の 1 つとして、クラス内のサービス（遅延など）が予測できないままであることが挙げられます。
WFQ（Weighted Fair Queuing：均等化キューイング）フローベースの WFQ（均等化キューイング）1 では、輻輳時であっても、予約済みフローに対してはその必要最小限のニーズをを満たす帯域幅と遅延限度が適用されるよう試みます。標準の WFQ の場合、パケットはフローごとにキューイングされます。同一発信元 IP アドレス、宛先 IP アドレス、発信元の伝送制御プロトコル（TCP）か UDP ポート、または宛先 TCP か UDP ポートを持つパケットは、同じフローに属します。
図 6：WFQ（Weighted Fair Queuing ：均等化キューイング）
フローベース WFQ の「Fair」という語は、各フローに、使用できる帯域幅を公平に割り当てられることを意味します。このセットアップにより、帯域幅の占有による潜在的なリソース不足を予防できます。
図 7：フローベースの WFQ
図 8：クラスベースの WFQ
クラスベースの均等化キューイング（CB-WFQ）により、ユーザは、トラフィックのクラスを作成したり、そのような各クラスに重みを割り当てたりできます。たとえば、企業のお客様では、1 つは音声用、もう 1 つはミッションクリティカルな ERP トラフィック用、3 つめは Web トラフィック用に 3 つのトラフィック・クラスを作成できます。CB-WFQ により、音声に 30 パーセント、ERP に 30 パーセント、Web トラフィックに残りの 40 パーセントといったように、各トラフィック・クラスに対応して帯域割り当てを決定的または「確実に」保証できます。CB-WFQ は、クラス間の公平な配分にはあまり重点を置いていませんが、高速リンクやバックボーンにおいてはCB-WFQ は強力な QoS ツールとなります。これは高速リンクやバックボーンでは、低速リンクで一般に適用されるような帯域割り当ての公平性よりも、確実な帯域幅の保証に重点が置かれるためです。
図 9：クラス・キューに割り当てられる着信パケット
VIP DWFQ（分散型 WFQ）
VIP ベースの分散型 WFQ 2 は、WFQ のキューイングおよびスケジューリング・タスクを複数の Versatile Interface Processor（VIP）に分散することにより、Cisco 7500 の転送キャパシティの増加するために使用されます。各 VIP は、原則、独自の高速インターフェースをサービスできるため、すべてのパケットにおいて、ルート・スイッチ・プロセッサ（RSP）ベースの処理を複数ポートで共有する場合より優れた転送パフォーマンスが期待できます。
これは、VIP2-40 またはそれ以上のインターフェース・プロセッサを搭載した次のルータでサポートされます。
- RSP7000 を搭載した Cisco 7000 シリーズ
- Cisco 7500 シリーズ
VIP2-50 インターフェース・プロセッサは、VIP 上のポート・アダプタの集約ライン・レートが DS3 を超える場合に推奨されます。VIP2-50 カードは、OC-3 レートでは必須です。VIP ベースの DWFQ が有効な手段となるのは、RSP ベース WFQ のスケーラビリティ（CPU の使用状況による）が特に高速インターフェース上で問題になるような場合です。
DWFQ では、WFQ に必要なソーティングにカレンダ・キューを使用することにより、従来の自己クロック型の WFQ アルゴリズムと比較して、それほど CPU に集中しなくなりました。3
| 輻輳回避 |
ネットワークの輻輳は、パフォーマンスの低下や、LAN/WAN 帯域幅の非効率な使い方につながる場合があります。
したがって、アルゴリズム（TCP トラフィックの適応性を充分に利用し、TCP 伝送を減速する手段としてパケット廃棄を使用するランダム早期検出（RED）など）を使用することにより、可能なときはいつでも輻輳を回避することが目標です。しかし、複数の TCP ソースがある場合、すべてのソースから均一にパケットを廃棄すると、すべてのパケットがバック・オフされてから、一斉に再伝送が開始されます。これは、「グローバル同期」と呼ばれる、輻輳の波を引き起こします。下の図に見られるように、この状況により、スループットの急激な低下が発生します。
RED では、数人の TCP 発信者だけがバックオフおよび再伝送できるように、特定の TCP フローから選択してパケットを廃棄することにより、この問題が解決されます。
図 10：グローバル TCP 同期
ルータのバッファが一杯になりテール・ドロップ（着信パケットがバッファ・スペース不足のため廃棄される）を招くまで待機しないで、ルータはバッファ深度を監視し、選択されたパケット（および選択されたコネクション）を早期に廃棄します。
図 11：RED による廃棄
ネットワーク・オペレータにより、最小および最大出力バッファのキュー深度しきい値が設定されると、ルータでは、パケット転送の決定と同時に、そのしきい値が監視されます。パケット交換は、平均キュー深度をチェックして決定されます。平均キュー深度が最小しきい値未満の場合、パケットは、キューイングされてから交換されます。平均キュー深度が最小しきい値を超え、かつ最大しきい値未満の場合、ほとんどのパケットは、廃棄されます。平均キュー深度が最大しきい値を超える場合、パケットは廃棄されます。
Cisco WRED（重み付けランダム早期検出）プロトコルにより、IP 優先順位および RED が組みあわせられ、標準トラフィック（低優先順位）に対してプレミアム（高優先順位）が差別化されたドロップしきい値が提供されます。言い換えると、WRED では、IP 優先順位に基づいてパケットが廃棄されます。これにより、実際には、インターネット・サービス・プロバイダ（ISP）では、プレミアム・カスタマからのパケット（少しでも存在する場合）を廃棄する前に、標準的なカスタマからのパケットを廃棄できます。
図 12：WRED により差別化されたドロップしきい値
WRED では、ルータの平均キュー深度が監視され、キュー深度に基づいてパケットの廃棄を開始する時期が決定されます。平均キュー深度がユーザ指定の「最小しきい値」を超えると、WRED は、一定の確率でパケット（TCP および UDP の両方）の廃棄を開始します。平均キュー深度がユーザ指定の「最大しきい値」を超えると、WRED は元の「テール・ドロップ」に戻り、すべての着信パケットが廃棄される場合があります。WRED を使用する意図は、キュー深度をほぼ最小しきい値から最大しきい値の間のレベルに維持することです。
WRED は、Cisco 7500 のパフォーマンスを向上するために、VIP 分散モードでも実行できます。しかし、実行するには、VIP 分散型 Cisco Express Forwarding（DCEF）をすべてのインターフェース上でグローバルにイネーブル（enable）する必要があります。
| ポリシングおよびシェーピング |
Cisco CAR（専用アクセス・レート）ツールは、レート制限またはポリシング用のツールです（なお、分類ルールは、Cisco IOS ソフトウェア内の CAR ファシリティから設定できます）。レート制限は、企業のお客様では、たとえば、インターネットから企業ネットワークに入るポイントキャスト・トラフィックなどのレートを制限したり、サービス・プロバイダでは、SLA（Service-Level Agreement）を強化したりするために使用される場合があります。レート制限ツールは、一般に、指定のレートを超えるトラフィックを廃棄します。すなわち、レート制限ツールの目的は、トラフィックのシェーピングまたはキューイングではありません。
図 13：CAR による制限レート
CAR レート制限は、フレーム・リレーおよび ATM（非同期転送モード）サブインターフェースを含む、入力または出力のインターフェースまたはサブインターフェースに設定できます。この機能が設定され、1 つまたは複数のレートが指定されると、そのポリシング・ポリシ（すなわち CAR が指定レートを超えるトラフィックに対して実行するアクション）は、次の 1 つに設定されます。
- Transmit（基本的に、ポリシングされません）
- Drop（パケットを廃棄します）
- Set precedence and transmit（IP パケット・ヘッダにある ToS（タイプ・オブ・サービス）フィールドの優先順位ビットを優先順位の低い値に設定、すなわちその優先順位ビットに初めてマーキングまたはカラリングしてから、伝送します。これは、その時点で直ちに使用できる容量がある場合、その宛先に必ず到達できる機会を提供する、準拠しないパケットを下位の優先順位により伝送する方法です）
複数の CAR レート制限を指定することもできます。この複数指定により、一連のレート制限をパケットに適用したり、より多数の詳細なポリシを指定したりできます。たとえば、企業のお客様は、TCP トラフィックをレート制限してから、TCP ベースの Web トラフィックに対して、第二のレート制限を指定することが出来ます。
- Continue（複数のレート制限指定がある場合に、各レート制限への適合を順次評価します。）
- Set precedence and continue（複数のレート制限指定がある場合に、優先順位ビットを指定された低い値に設定したのち、各レート制限への適合を順次評価します。）
これらの最後の 2 つのオプションは、CAR 内で段階的に複数のレート制限を実行する例です。
シェーピングシェーピング（ジェネリック・トラフィック・シェーピング（GTS））は、様々な理由により使用されています。例えば、発言トラフィックをシェーピングして、サービス・プロバイダ網内で過剰トラフィックとして廃棄されるのを避けたいと考える企業ユーザへの SLA 提供などです。シェーピングの目標は、（レート制限またはポリシングの目標と比較すると）パケットを決して廃棄しないことです。一般に、下流のルータがポリシング中であると判明した場合、上流ルータではシェーピングが実行される必要があります。
図 14：トラフィック・シェーピングの必要性
Cisco GTS では、特定のインターフェース上でトラフィック・フローを制御するメカニズムを用意しています。これにより、指定されたトラフィックのバーストをキューイングしながら、指定されたトラフィックを特定のビット・レートに制約することにより、輻輳を回避するために送信トラフィック・フローが削減されます（トークン・バケット・アプローチとも呼ばれます）。したがって、特定のプロファイルに忠実なトラフィックでは、下流の要件を満たすようにシェーピングできるため、データ・レートのミスマッチによるトポロジ内のボトルネックを解消できます。インターフェース単位（またはサブインターフェース単位）に適用される GTS では、シェーピングするトラフィックの選択にアクセス・リストを使用でき、さまざまなレイヤ 2 テクノロジーと連携します。言い換えると、GTS により、レイヤ 2 に存在するインターフェースまたはカプセル化と関係なく、レイヤ 3 トラフィックがシェーピングされます。
VIP 分散型トラフィック・シェーピングVIP 分散型トラフィック・シェーピング（DTS）は、GTS およびフレーム・リレー・トラフィック・シェーピング（FRTS）の利点を組みあわせて、1 つのツールにしたものです。分散 Cisco Express Forwarding がスイッチングの優先モードであるネットワークでは、トラフィック・シェーピングの手段として、VIP 上の DTS が必然的に選択されます。
DTS では、ATM（非同期転送モード）またはフレーム・リレーの PVC（相手先固定接続）に、インターフェース・レベル、サブインターフェース・レベル、または論理インターフェース・レベルでトラフィック・シェーピングが構成されます。次の基準に基づいて、シェーピングできます。
- 物理または論理インターフェース上にあるすべてのトラフィック
- 単一および拡張 IP アクセス・コントロール・リスト（ACL）（IP アドレス、TCP/UDP ポート、IP 優先順位）により分類されたトラフィック
- QoS グループにより分類されたトラフィック（CAR または QPPB により、上流に適用される内部パケット・ラベル）
DTS では、VIP 当たり最大 200 個までのシェーピング・キューがサポートされ、平均パケット・サイズが 250 バイトまたはより大きい場合、および 8M SRAM を搭載した VIP2-50 またはそれ以上を使用している場合、最高 OC-3 までのレートがサポートされます。通常のトラフィック・シェーピング（GTS）とは異なり、DTS では、WFQ を使用可能にする必要はありません。その代わり、DTS では、シェーピング済みのキューに対し、フェア・キューイングまたは分散型 FIFO が使用されます。
| シグナリング |
図 15：エンドツーエンド QoS シグナリングのオプションの 1 つである RSVP
RSVP（Resource Reservation Protocol）は、アプリケーション（またはアプリケーションの代わりにルータ）が、ネットワークに対して指定レベルの QoS をシグナリングできる方法の 1 つです。RSVP は、アプリケーションがフローごとに QoS を要求できるレイヤ 3 シグナリング・プロトコルです。
RSVP は、2 つの終端間における PATH/RESV メッセージの定期的な交換に依存します。すなわち、特定のフローのリソース予約を開始および維持するのがそのデータ・フローの受信者であるため、「受信者主導型」プロトコルとみなされます。RSVP では、それぞれの中間ルータにより RSVP フローに関する状態情報が保持される必要があるため、メッセージが多数のルータを通過する場合があるインターネットのような基盤で使用されると、スケーラビリティおよびコスト上の問題が生じる場合があります。RSVP は、明示的な QoS および詳細設定が絶対不可欠なものである場合、たとえば低速 WAN リンク上などでは有効です。
図 16：RSVP の使用例（テレビ会議）
シスコのルータでは、RSVP をサポートしており、それ自体が RSVP シグナリングを実行できないエンドユーザ・アプリケーションの代わりに、RSVP のプロキシ・シグナリングを実行する状況において頻繁に使用されます。
ルータおよびアプリケーションに加え、RSVP シグナリングは、H.323 音声ゲートウェイによってそのクライアントの代わりに実行できます。4クライアントには、音声トラフィックを IP 優先順位といったレイヤ 3 情報付きで作成することでその音声トラフィックを区別できる、シスコ（Selsius）電話を指定できます。 5
図 17：IP 優先順位をマーキングするシスコの電話
また、Cisco IOS ソフトウェアには、非 RSVP 型サブネットワーク（IP 優先順位 または DiffServ 専用ネットワーク、IEEE 802.1q/p ネットワーク、または ATM（非同期転送モード）交換バックボーンなど）で RSVP をマッピングするためのツールも組み込まれています。このように、シスコでは、ユーザが、上記のようなデバイスで使用できる QoS の詳細な設定に必要以上に気にすることなく、さまざまな機器を配備できる機能を提供します。
| リンク効率メカニズム |
H.323 では、IP での音声トラフィックの転送用にリアルタイム・トランスポート・プロトコル（RTP）の使用が推奨されています。しかし、IP ヘッダ内部の UDP で RTP の音声パケットをカプセル化する場合、40 バイトのヘッダ（RTP ヘッダの 12 バイト、UDP ヘッダの 8 バイトおよび IP ヘッダの 20 バイトを加えた）になります。このヘッダは、RTP パケットのペイロード部分を圧縮できるオーディオ・アプリケーションでは 20～160 バイトのペイロードが発生することを考慮すると、多少大きいものです。20 バイトのペイロードに 40 バイトのヘッダでは、非効率です。
圧縮 RTP（CRTP）といったヘッダ圧縮のテクニックでは、RTP ヘッダを 40 バイトから 2～5 バイトにまで削減できます。これは、音声トラフィックが、不足している帯域幅を求めてデータと争っているような低速リンク（64 KB フレーム・リレーなど）において、特に役立ちます。
図 18：圧縮 RTP（CRTP）のヘッダ圧縮
別のリンク効率ツールに、リンク・フラグメンテーションおよびインターリービング（LFI）があります。このツールでは、実質、大きなデータ・パケットがフラグメント化され、小さめの音声パケットがこれらの多量のデータ・パケット間に挿入され、音声トラフィックによる遅延が減少されます。
図 19：低速リンクの LFI
| レイヤ 2 WAN バックボーン（フレーム・リレーおよび ATM）により相互接続される Cisco 7200 および 7500 |
エッジにある IP ネットワークが ATM またはフレーム・リレー・スイッチから成るレイヤ 2 相互接続バックボーンに接続されると、そのエッジで定義された QoS は、必ずバックボーンで認識されます。この点を考慮すると、各種 IP QoS ツールは、次のとおり、レイヤ 2 に関連づけられています。
フレーム・リレー・コアおよびトラフィック・シェーピングフレーム・リレー・サブインターフェースでは、GTS は、BECN（逆方向明示的輻輳通知）信号を統合することで、使用可能な帯域幅に動的に適合するように設定したり、単にあらかじめ指定したレートにシェーピングするように設定したりできます。FRTS は、DLCI（各データリンク接続識別子）には適用されますが、物理インターフェース全体には適用されません。
図 20：フレーム・リレー・トラフィック・シェーピング（FRTS）
ATM（非同期転送モード）CoS にマッピングされる IP QoS
IP QoS は、パケットの優先順位を示したり、次にその優先順位（IP 優先順位などによる）に基づいたトラフィック・クラスを示したりする場合に IP ネットワーク内で使用できますが、ATM コアの QoS 機能へのその優先順位のマッピングは、エンドツーエンド・サービスを保証する上で不可欠なツールです。
ATM ポート・アダプタ（PA）-A3 を装備した Cisco 7200 および 7500 では、IP クラスを、それぞれ固有の WRED ドロップしきい値により、異なる場所に向かう ATM VC（仮想回線）に一式にマッピングしたり、同じ宛先に向かう別の ATM VC に個別にマッピングしたりできます。
前者の場合、これにより、WRED ドロップは、すべてのフローではなく、輻輳した VCと宛先のペアに向かって流れるフローの場合のみ実行できます。こうしないと、輻輳していない宛先に向かって VC で伝送されるトラフィックは、以前にこれをその VC レベルではなく ATM インターフェース全体が輻輳していると検出していた WRED アルゴリズムにより、不必要に廃棄される場合があります。
図 21：インテリジェント・パケット廃棄
個々の WRED しきい値が同じ場所にある複数の固有の ATM VC にマッピングする後者では、管理者は、各 IP 優先順位レベルからトラフィックを伝送する VC に ATM サービス（VBR（可変ビット・レート）および UBR（未指定ビット・レート）、またはマルチプロトコル・ラベル・スイッチングに定義されるクラスなど）を定義できます。
Cisco IP QoS-to-ATM マッピング・ソリューションの後続フェーズでは、VC 単位の WFQ が提供され、この機能により、WFQ アルゴリズムは VC 単位で帯域幅を管理できます。GFR（Guaranteed Frame Rate）や重み付け UBR（UBRw）といった、新しく登場した ATM トラフィック・クラスは、管理オプションとして追加されます。また、WRED しきい値の完全な一式では、ATM ABR（使用可能ビットレート）メカニズムを利用する輻輳フィードバックを提供するために 1 つの VC にマッピングでき、その結果、ほぼ損失のないコア、縮小 VC カウントのオプションとなります。
今日、ATM PA-A3 を装備した Cisco 7200 および 7500 内の ATM SVC 固有の RSVP トラフィック・フローを割り当てることもできます。特に、RSVP 予約は、ATM ネットワークでのトラフィック用に、動的に作成された VBR ATM 相手先選択接続（SVC）にマッピングできます。
図 22：ATM（非同期転送モード）PVC（相手先固定接続）に対応する IP 優先順位の 1 対 1 マッピング
上記のマッピング機能を使用することで、コネクション型コアのエッジにある IP ルータに定義および設定された QoS ポリシ定義が無視されないことが保証されます。
結論として、シスコ・システムズでは、包括的な QoS ツール・ボックスが提供されます。トラフィックの分類、マーキング、カラリングが可能で、また、輻輳管理用にトラフィックのキューイングおよびスケジュールできるツールがあります。輻輳の回避が目的の場合、適応または非適応フロー向けに輻輳を回避するツールがあります。SLA の準拠が問題となる場合、企業および ISP のお客様が、合意された SLA に準拠するようにトラフィックをポリシングおよびシェーピングするツールがあります。シグナリングまたはアドミッション制御が問題となる場合、Cisco IOS ソフトウェアでは、QoS をネットワークにシグナリングするツールが提供されます。最後に、音声といったリアルタイム・トラフィック向けのリンク効率を管理するツールがあります。
必要なのはキャンパス内の QoS か WAN 内の QoS か、レイヤ 2 媒体が ATM（非同期転送モード）かフレーム・リレーかは、ユーザが気にする必要はありません。Cisco IOS ソフトウェアにより、上記すべては透過的になるため、ユーザは、下に隠されたレイヤ 2 メカニズムに関係なく、すべて透過的にエンドツーエンドに機能することがわかり、プランニングをレイヤ 3 QoS に限定できます。
1 ルート・スイッチ・プロセッサの WFQ は、1989 年の SIGCOMM における Demera、Keshev、および Shenker の論文に基づいたセルフクロック WFQ アルゴリズムに基づいています。
2VIP DWFQ アルゴリズムは、カレンダ・キューに基づいた分散型ラウンドロビン（DRR）的な実装です。これには、VIP Distributed Cisco Express Forwarding（DCEF）を使用可能にする必要があります。
31989 年の SIGCOMM における Demera、Keshev、および Shenker の論文に基づいています。
4RSVP は、RFC 2205 に基づいています。
5RFC 2207 では、VoIP のエンドツーエンド RSVP 実装の問題が処理されます。
| 更新日：2001 年 8 月 10 日 |
