この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、企業ネットワーク全体に IP 電話ソリューションを実装するに際しての QoS 要件について説明します。 前提条件のツールを適用することにより、IP インフラストラクチャ上で、メディアに関係なく、たとえデータ レートが低い状態でも、高品質の音声、ビデオ、およびデータの伝送ができます。AVVID 配備のための QoS ネットワーク設計についてのさらに詳しい情報は、次の URL にある「Cisco AVVID QoS Design Guide」を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/index.htm
最近まで、データ トラフィックのバースト性、およびバッファのオーバーフローとパケット欠落に耐える能力によって、QoS が企業キャンパスで問題になることはあり得ないと、従来の知識では言われてきました。パケット欠落や遅延に敏感な音声、およびビデオのようなアプリケーションがデータ ネットワークを伝送され始めると、ネットワークの設計者は、帯域幅ではなく、バッファがキャンパスでの問題であることを徐々に理解し始めました。バッファは、瞬時に一杯となる可能性があります。これが発生した時、インターフェイス バッファに入れようとするとパケットがドロップする可能性があります。音声のような、ドロップに対して極端に許容度の低いアプリケーションでは、このことは音声品質の低下を招きます。QoS ツールは、これらのバッファーを管理し、欠落、遅延、および遅延変動を最少限にするために必要です。
キャンパス QoS は、次のセクションで説明する 2 つの別個の分野の設定で、実際に実現されます。
できる限りネットワークの端部近くでトラフィックを分類する、あるいはマーキングすることは、常にシスコのネットワーク設計アーキテクチャで不可欠の部分でした。トラフィックの分類は、キャンパス スイッチ、および WAN インターフェイス内で使用される、さまざまなキューイング方式にアクセスするための入り口の基準です。単一のケーブル モデルを使用して IP 電話を接続すると、その電話は管理ネットワークの端部となります。このようにして、IP 電話はトラフィック フローを分類することが可能となり、また分類する必要があります。表 8-1には、AVVID トラフィック分類のガイドラインが記載されています。
タイプ |
|
|
|
---|---|---|---|
音声の品質を保証するには、キャンパス インフラストラクチャ内で QoS を使用可能にすることが、設計要件になります。QoS をキャンパス スイッチ上で使用可能にすることで、すべての音声トラフィックを、個別のキューを使用するように設定できます。これによって、インターフェイス バッファが瞬間的に一杯になったとき、音声パケットがドロップする可能性を実質上削除します。
ネットワーク管理ツールは、キャンパス ネットワークが輻輳していないと表示するかもしれませんが、音声品質の保証には、やはり QoS ツールが必要です。現在のネットワーク管理ツールは、1 つのサンプルのタイム スパンにわたる平均輻輳だけを表示します。この平均は、役に立ちますが、キャンパス インターフェイスでの輻輳のピークは表示しません。キャンパス内の送信インターフェイス バッファは、ネットワーク トラフィックのバースト性の結果、非常に短い有限の期間に輻輳する傾向にあります。これが発生すると、その送信インターフェイスに向けられたすべてのパケットはドロップします。音声トラフィックのドロップを防ぐ唯一の方法は、キャンパス スイッチに複数のキューを設定することです。表 8-2には、拡張キューイング サービスをサポートするシスコ イーサネット スイッチが記載されています。
|
|
|
|
---|---|---|---|
企業 WAN モデルを図 8-1で示します。
音声と映像をネットワーク上に送信する前に、必要なすべてのアプリケーションに、適切な帯域幅が存在することを確認する必要があります。開始するには、主要なアプリケーション(たとえば、音声メディア ストリーム、ビデオ ストリーム、音声制御プロトコル、およびすべてのデータ トラフィック)ごとに必要最小限の帯域幅の要求を合計する必要があります。この合計は、所定のいずれかのリンクに対する必要最小限の帯域幅要求を表すとともに、この要求が、そのリンクで利用できる合計帯域幅の 75% 以上を消費しないようにする必要があります。この 75% ルールは、ルーティングやレイヤ 2 キープアライブのようなオーバーヘッド トラフィック、さらに、電子メール、HTTP トラフィック、および測定が容易ではないその他のデータ トラフィックのような追加アプリケーションに、多少の帯域幅が必要になることを想定しています。図 8-2を参照してください。
このセクションでは、企業 WAN 上の IP テレフォニー アプリケーションに対して、QoS を実装するために使用するツールについて説明します。これらのツールには、トラフィックの優先順位付け、リンク分割とインターリービーング(LFI)、およびトラフィックのシェーピングが含まれます。このセクションは、適用可能なデータ リンク プロトコルのそれぞれに対して、最善策の要約だけを説明しています。
数多くある利用可能な優先順位付け方式の中から選択する上で考慮すべき主要な要素には、ネットワーク上に送信されるトラフィックのタイプ、およびネットワークを横断する広域メディアがあります。IP WAN に送信されるマルチサービス トラフィックに対しては、シスコは、低速リンクのための低遅延キューイングを推奨します。これにより、次のようなことを 64 までのトラフィック クラスに指定できるようになります。その指定内容には、たとえば、音声と対話型映像に対する優先順位によるキューイング動作、システム ネットワーク アーキテクチャ(SNA)データ、および営業データの供給に必要となる最小限の帯域幅、およびその他のトラフィック タイプに対する均等化キューイング(WFQ)などがあります。
図 8-3は、この優先順位付け方式を次のように示します。
• 音声は、優先順位キューイング機能を使用してキューに配置され、48 Kbps の帯域幅が割り当てられます。このキューへの入り口基準は、識別サービス コード ポイント(DSCP)値が EF であるか、あるいは IP 優先順位値が 5 であることです。48 Kbps を超えるトラフィックは、インターフェイスが輻輳すると、ドロップすることになります。したがって、アドミッション制御メカニズムを使用して、この値を超えないようにする必要があります。
• ビデオ電話会議トラフィックは、優先順位キューイング機能を使用してキューに入れられ、384 Kbps の帯域幅が割り当てられます。このキューへの入り口基準は、DSCP 値が AF41 であるか、あるいは IP 優先順位値が 4 あることです。384 Kbps を超えるトラフィックは、インターフェイスが輻輳すると、ドロップすることになります。したがって、音声のような場合には、アドミッション制御メカニズムを使用して、この値を超えないようにすることが必須です。
(注) IP/TV のような 1 方向ビデオ トラフィックでは、遅延許容値が非常に高いため、クラスベースの均等化キューイング方式を使用する必要があります。
• WAN リンクが輻輳すると、音声制御信号処理プロトコルが完全に枯渇する可能性があるため、IP 電話の能力を削除して IP WAN を通過するコールを完了させます。H.323、および Skinny Client Control Protocol のような音声制御プロトコルのトラフィックは、トラフィック独自のクラスベースの均等化キューを必要とします。この均等化キューには、3 の IP 優先順位値と相関関係にある、AF31 の DSCP 値に等しい必要最小限の設定可能帯域幅が必要です。
• SNA トラフィックは、指定された 56 Kbps の帯域幅をもつキューに入れられます。このクラス内のキューイング オペレーションは、割り当てられた 56 Kbps の必要最小限の帯域幅を使用する先入れ先だし(FIFO)方式です。このクラスで 56 Kbps を超えるトラフィックは、デフォルトのキューに入れられます。このキューへの入り口基準は、TCP ポート番号、レイヤ 3 アドレス、IP 優先順位、あるいは DSCP であることもあります。
• 残りのすべてのトラフィックは、デフォルトのキューに入れることができます。帯域幅が指定された場合には、キューイング オペレーションは FIFO となります。帯域幅ではなく、キーワード fair が指定された場合は、オペレーションは均等化キューイング(WFQ)となります。
図 8-3 WAN を越える VoIP のために最適化したキューイング
低遅延キューイング(LLQ)の設定時には、以下の点を考慮する必要があります。
• 専用回線、および非同期転送モード(ATM)のための必要最低限のシステム ソフトウェアは、Cisco IOS Release 12.1(2)T です。
• フレームリレーのための必要最低限のシステム ソフトウェアは、Cisco IOS Release 12.1(2)T です。
表 8-3は、Cisco CallManager Release 3.0(5) を使用する音声、映像、およびデータのネットワークに必要な最小限の帯域幅を示しています。これらの値は必要最小限の値であり、すべてのネットワークには、適切な容量を割り当てる必要があることに留意してください。
|
|
リレー |
|
|
---|---|---|---|---|
多くの場合、広域の帯域幅は非常に高価なため、リモート サイト間を相互接続する場合、低速回線だけが利用可能、あるいはコスト効果がある可能性があります。これらの場合、できる限り多くの音声コールを低速リンクを介して転送することで、最大限の節約を行うことが重要です。G.729 のような多くの圧縮方式により、64 Kbps のコールを 8 Kbps のペイロードに圧縮できます。シスコ ゲートウェイと IP 電話は、これら低速リンクでの効率を高めることができる一連のコーデックをサポートします。
リンク効率は、圧縮 RTP(cRTP)を使用してさらに高めることができます。この技術は、40 バイトの IP + UDP + RTP ヘッダを約 2 ~ 4 バイトに圧縮します。さらに Voice Activity Detection(VAD)は、ほとんどの会話では、単一の当事者だけが一度に話しているという事実を利用します。VAD は、この空の時間を取り戻し、データがその帯域幅を使用できるようにします。
(注) cRTP をサポートしているのは、現在、専用回線とフレームリレーのメディアだけです。パフォーマンスを大幅に拡張した Cisco IOS Release 12.1(2)T を、cRTP 用システム ソフトウェアとして使用することをお勧めします。
768 Kbps より下の低速リンクには、リンク分割とインターリービング(LFI)を行う技術を使用する必要があります。この技術は、音声トラフィックが、大規模なデータ フレームの後ろに遅れることを防ぐことにより、ジッタ上にバウンドを配置します。この目的で使用する技術には、ポイントツーポイントのシリアル リンク用マルチリンク PPP(MLP)、フレームリレー用 FRF.12、そして ATM 接続用の MLP over ATM の 3 つがあり、Cisco IOS Release 12.1(5)T で使用できます。図 8-4は、LFI の一般的なオペレーションを示しています。
図 8-4 リンク分割とインターリービング(LFI)のオペレーション
物理的なアクセス速度が 2 つの終端間で異なる複数アクセス、ATM およびフレームリレーのような非ブロードキャスト メディアには、トラフィック シェーピングが必要です。トラフィック シェーピング テクノロジーは、ミスマッチのアクセス速度を調整します。FRF.12 を使用するフレーム リレーの場合、トラフィック シェーピングは、遅延変動あるいはジッタが適切にバウンドされることを許します。ATM では、データ レートは、通常、分割を必要としないものです。図 8-5は、フレームリレーおよび ATM で使用するトラフィック シェーピングを示しています。
図 8-5 フレームリレーおよび ATM で使用するトラフィック シェーピング
表 8-4には、WAN 上に実装される企業音声システムに対して、必要最低限の推奨ソフトウェアのリリース、および QoS ツールに必要な推奨パラメータが記載されています。現在推奨している Cisco IOS のバージョンは、今後のリリースで変更される予定です。
コール アドミッション制御は、ネットワーク リソースが予約過多とならないようにするために必要です。指定した帯域幅を超えるコールは、PSTN のような代替ルートを使用して再ルーティングされるか、使用中トーンが発信元に戻されるかのいずれかです。図 8-6は、実装モデルが、トール バイパス、あるいはデスクトップへの IP テレフォニーのいずれであるかに関係なく、コール アドミッション制御が必要であることを示しています。
図 8-6 WAN 帯域幅の保護に必要なコール アドミッション制御
WAN 上の音声コールに対してコール アドミッション制御を提供する方式には、次の 2 つがあります。
• ゲートキーパー コール アドミッション制御:「コール アドミッション制御」を参照してください。
• ロケーション コール アドミッション制御:「コール アドミッション制御」を参照してください。