この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、企業キャンパス環境で IP テレフォニー ソリューションを構築するために必要な、ネットワーク インフラストラクチャの要件について説明します。図 2-1 では、ネットワーク インフラストラクチャを形成する各種デバイスの役割を示し、 表 2-1 では、それらの役割に必要な機能を示しています。
図 2-1 一般的なキャンパス ネットワーク インフラストラクチャ
|
|
---|---|
表 2-2 では、LAN インフラストラクチャのトラフィックを分類する場合の要件をリストしています。
|
|
|
|
---|---|---|---|
表 2-3 では、WAN インフラストラクチャに必要な QoS 機能とツールをリストしています。
|
|
|
---|---|---|
• MLP(マルチリンク ポイントツーポイント プロトコル) |
||
主要なすべてのアプリケーション(音声、ビデオ、およびデータ)を合計した帯域幅必要量が、使用可能なリンク帯域幅の 75% 以下になるように、WAN リンク帯域幅のプロビジョニングを行う必要があります。
表 2-4 では、デフォルトのパケット レートである毎秒 50 パケット(pps)で、音声ペイロードのみが消費する帯域幅をリストしています。
|
レート |
|
パケット数 |
帯域幅 |
---|---|---|---|---|
表 2-5 では、レイヤ 2 ヘッダーが計算に含まれる場合に、音声トラフィックが消費する帯域幅量をリストしています。
|
14 バイトの ヘッダー |
6 バイトの ヘッダー |
53 バイトのセルと 48 バイトの ペイロード |
4 バイトの ヘッダー |
---|---|---|---|---|
この項の計算では、電話機 1 台当たりの平均毎時コール数を 10 と想定します。
公式 1 :制御トラフィックに必要な推奨帯域幅、TAPI アプリケーションなし
帯域幅(bps)= 150 ∗(事業所内の IP フォンとゲートウェイの数)
公式 2 :制御トラフィックに必要な推奨帯域幅、TAPI アプリケーションあり
TAPI を使用する場合の帯域幅(bps)= 225 ∗(事業所内の IP フォンとゲートウェイの数)
表 2-6 では、さまざまな事業所の規模に対する推奨帯域幅を示しています。
(IP フォンとゲートウェイの数) |
推奨帯域幅(TAPI なし) |
推奨帯域幅(TAPI あり) |
---|---|---|
(注) 表 2-6 の値は、レイヤ 3 帯域幅を示します。WAN リンクをプロビジョニングする場合、使用するレイヤ 2 テクノロジーに応じて、これらの数値にレイヤ 2 オーバーヘッドを加算する必要があります。
この項で示されている上記の公式は、電話機 1 台当たりの平均コール レートを毎時 10 コールと想定しています。しかし、コール パターンが大きく異なる場合(たとえば、事業所にコール センター エージェントが配置されている場合)、この想定が、実際の配置に該当しない場合があります。こうした場合のコール制御帯域幅必要量を計算するには、次の公式を使用してください。これらの公式には、電話機 1 台当たりの毎時平均コール数を表す追加変数(CH)が含まれています。
公式 3 :事業所の推奨帯域幅、TAPI アプリケーションなし
帯域幅(bps)=(39 + 10.8 ∗ CH)∗(事業所内の IP フォンとゲートウェイの数)
公式 4 :遠隔地にある事業所の推奨帯域幅、TAPI アプリケーションあり
TAPI を使用する場合の帯域幅(bps)=(39 +18.3 ∗ CH)∗(事業所内の IP フォンとゲートウェイの数)
分散型コール処理を使用したコール制御トラフィック用の帯域幅プロビジョニング
分散された Cisco CallManager クラスタを接続する WAN リンクの場合、必要な帯域幅のシグナリング コンポーネントは次のように計算できます。
平均コール所要時間を 2 分、各仮想タイ ラインの利用率を 100 % と想定すると、各タイ ラインの伝送量は毎時 30 コールであると推論することができます。この前提により、コール制御トラフィック用の推奨帯域幅を仮想タイ ライン数の関数として表す、次の公式が得られます。
Cisco IOS ルータ上のキューに割り当て可能な最小帯域幅は、8 kbps です。つまり 8 kbps の最小キュー サイズは、最高 70 の仮想タイ ラインによって生成されるコール制御トラフィックを受け入れることができると推定できます。これは、大部分の大企業での配置に十分な量です。
IP WAN を介したマルチサービス トラフィックには、低遅延キューイング(LLQ)をお勧めします。次の優先順位の基準もお勧めします。
• 音声が優先キューに入る基準は、DSCP(Differentiated Services Code Point)値 EF、または IP 優先順位値 5 です。
• ビデオ会議トラフィックが優先キューに入る基準は、DSCP 値 AF41、または IP 優先順位値 4 です。片方向ビデオ トラフィック(IP/TV など)は、遅延許容度がかなり高いので、クラス ベースの均等化キューイング方式を使用する必要があることに注意してください。
• 音声制御プロトコル(たとえば、H.323 や Skinny Client Control Protocol(SCCP))には、独自のクラス ベースの均等化キューが必要です。このキューに入る基準は、DSCP 値 AF31 です。これは、IP 優先順位値 3 に相当します。
cRTP(Compressed Real-Time Transport Protocol)
cRTP を使用すると、さらにリンク効率を高めることができます。このプロトコルは、40 バイトの IP ヘッダー、UDP(User Datagram Protocol)ヘッダー、および RTP ヘッダーを約 2 ~ 4 バイトに圧縮します。個々のリンクで cRTP を使用するのは、そのリンクが次の条件を全部満たす場合だけにしてください。
• 音声トラフィックによる負荷が、特定リンク上で 30% を超えている場合。
• リンクが低ビット レート コーデック(たとえば G.729)を使用する場合。
• 他のリアルタイム アプリケーション(たとえば、ビデオ会議)が同じリンクを使用しない場合。
音声およびビデオに対応した IPSec VPN(V3PN)で cRTP を使用する場合の追加の推奨事項については、次の Web サイトで入手可能な V3PN 資料を参照してください。
ATM とフレームリレーのサービス インターワーキング(SIW)リンクでは、cRTP を使用しないでください。
cRTP を使用する前に検討する必要がある重要なパラメータは、ルータの CPU 利用率です。これは、圧縮処理と圧縮解除処理の際に高まるので、注意が必要です。
トラフィック シェーピングは、ATM やフレームリレーなどの複数アクセスの非ブロードキャスト メディアに必要です。この場合、物理的なアクセス速度は 2 つのエンドポイント間で異なります。通常、複数の事業所サイトは、中央サイトのルータの単一インターフェイスへ集約されます。
次のシナリオでは、同一 IP WAN 上での音声とデータの転送時にトラフィック シェーピングが必要な理由を示しています。
中央サイトのインターフェイスは、一般に高速インターフェイス(たとえば、T1 以上)ですが、小規模なリモート サイトの事業所のインターフェイス回線速度はかなり遅くなります(たとえば、64 kbps)。データが中央サイトから低速リモート サイトにフル レートで送信されると、リモート サイトのインターフェイスは輻輳し、音声パフォーマンスが低下する場合があります。
• リモート サイトから中央サイトへの集約時の過剰サブスクリプション
複数のリモート サイトを 1 つの中央サイトに集約する場合、帯域幅を余分にサブスクライブするのは、フレームリレーまたは ATM ネットワークでは一般的な方法です。たとえば、T1 インターフェイスで WAN に接続するリモート サイトが複数あるにもかかわらず、中央サイトには 1 つの T1 インターフェイスしかない場合があります。この設定により、配置されたネットワークは統計多重化による恩恵を受けますが、中央サイトのルータ インターフェイスが、トラフィックのバースト時に輻輳し、音声品質が低下することがあります。
もう 1 つの一般的な設定は、CIR を超えたトラフィック バーストを許可することです。CIR は、サービス プロバイダーが、損失なく、遅延の少ないネットワークを介して転送することを保証したレートです。たとえば、T1 インターフェイスを備えたリモート サイトでは、CIR が 64 kbps に過ぎない場合があります。64 kbps 以上に相当するトラフィックが WAN を介して送信される場合、プロバイダーは、追加トラフィックに「discard eligible(廃棄適性)」のマークを付けます。プロバイダーのネットワークで輻輳が発生した場合、このトラフィックは廃棄され、音声品質に悪影響を与える場合があります。
トラフィック シェーピングは、インターフェイスから送出されるトラフィックを、回線レート未満に制限することによって問題を解決し、WAN の両端で輻輳が発生しないようにします。