Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン ガイド Cisco CallManager Release 3.3
ネットワーク インフラストラクチャ
ネットワーク インフラストラクチャ
発行日;2012/01/09 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

ネットワーク インフラストラクチャ

LAN インフラストラクチャ

WAN インフラストラクチャ

帯域幅のプロビジョニング

トラフィックの優先順位

リンク効率化手法

トラフィック シェーピング

ネットワーク インフラストラクチャ

この章では、企業キャンパス環境で IP テレフォニー ソリューションを構築するために必要な、ネットワーク インフラストラクチャの要件について説明します。図 2-1 では、ネットワーク インフラストラクチャを形成する各種デバイスの役割を示し、 表 2-1 では、それらの役割に必要な機能を示しています。

図 2-1 一般的なキャンパス ネットワーク インフラストラクチャ

 

 

表 2-1 ネットワーク インフラストラクチャ内の役割に必要な機能

インフラストラクチャの役割
必要な機能

キャンパス アクセス スイッチ

インライン電源

複数キュー サポート

802.1p および 802.1Q

高速リンク コンバージェンス

キャンパス ディストリビューション スイッチまたはコア スイッチ

複数キュー サポート

802.1p および 802.1Q

トラフィック分類

トラフィック再分類

WAN アグリゲーション ルータ

(ネットワークのハブ サイト)

複数キュー サポート

トラフィック シェーピング

LFI(Link Fragmentation and Interleaving)

リンク効率

トラフィック分類

トラフィック再分類

802.1p および 802.1Q

事業所ルータ

(スポーク サイト)

複数キュー サポート

LFI

リンク効率

トラフィック分類

トラフィック再分類

802.1p および 802.1Q

事業所または小規模サイトのスイッチ

インライン電源

複数キュー サポート

802.1p および 802.1Q

LAN インフラストラクチャ

表 2-2 では、LAN インフラストラクチャのトラフィックを分類する場合の要件をリストしています。

 

表 2-2 各種タイプの AVVID ネットワーク トラフィックのトラフィック分類ガイドライン

トラフィックのタイプ
レイヤ 2 サービス クラス(CoS)
レイヤ 3 IP 優先順位
レイヤ 3 Differentiated Services Code Point(DSCP)

音声 Real-Time Transport Protocol(RTP)

5

5

EF

音声制御信号

3

3

AF31

ビデオ

4

4

AF41

データ

0、1、2

0、1、2

0 ~ AF23

WAN インフラストラクチャ

表 2-3 では、WAN インフラストラクチャに必要な QoS 機能とツールをリストしています。

 

表 2-3 WAN テクノロジーとリンク速度ごとの IP テレフォニー サポートに必要な QoS 機能とツール

WAN テクノロジー
リンク速度:56 kbps ~ 768 kbps
リンク速度:768 kbps 以上

専用回線

MLP(マルチリンク ポイントツーポイント プロトコル)

MLP LFI(Link Fragmentation and Interleaving)

LLQ(低遅延キューイング)

オプション:cRTP(Compressed Real-Time Transport Protocol)

LLQ

フレームリレー(FR)

トラフィック シェーピング

LFI(FRF.12)

LLQ

オプション:cRTP

トラフィック シェーピング

LLQ

非同期転送モード(ATM)

TX-ring バッファ変更

MLP over ATM

MLP LFI

LLQ

オプション:cRTP(MLP が必要)

TX-ring バッファ変更

LLQ

フレームリレーと ATM のサービス インターワーキング(SIW)

TX-ring バッファ変更

MLP over ATM と FR

MLP LFI

LLQ

オプション:cRTP(MLP が必要)

TX-ring バッファ変更

MLP over ATM と FR

LLQ

マルチプロトコル ラベル スイッチング(MPLS)

インターフェイス テクノロジーに応じて、上記と同じ

一般に、サービス プロバイダーの仕様に応じて、フローをリマークするにはクラスベースのマーキングが必要

インターフェイス テクノロジーに応じて、上記と同じ

一般に、サービス プロバイダーの仕様に応じて、フローをリマークするにはクラスベースのマーキングが必要

帯域幅のプロビジョニング

主要なすべてのアプリケーション(音声、ビデオ、およびデータ)を合計した帯域幅必要量が、使用可能なリンク帯域幅の 75% 以下になるように、WAN リンク帯域幅のプロビジョニングを行う必要があります。

表 2-4 では、デフォルトのパケット レートである毎秒 50 パケット(pps)で、音声ペイロードのみが消費する帯域幅をリストしています。

 

表 2-4 音声ペイロードと IP ヘッダーのみの帯域幅使用量

コーデック
サンプリング
レート
音声ペイロード(バイト数)
1 秒当たりの
パケット数
1 会話当たりの
帯域幅

G.711

20 ms

160

50.0

80.0 kbps

G.711

30 ms

240

33.3

74.7 kbps

G.729A

20 ms

20

50.0

24.0 kbps

G.729A

30 ms

30

33.3

18.7 kbps

表 2-5 では、レイヤ 2 ヘッダーが計算に含まれる場合に、音声トラフィックが消費する帯域幅量をリストしています。

 

表 2-5 レイヤ 2 ヘッダーが含まれた帯域幅使用量

コーデック
イーサネット
14 バイトの
ヘッダー
PPP
6 バイトの
ヘッダー
ATM
53 バイトのセルと 48 バイトの
ペイロード
フレームリレー
4 バイトの
ヘッダー

G.711(50.0 pps)

85.6 kbps

82.4 kbps

106.0 kbps

81.6 kbps

G.711(33.3 pps)

78.4 kbps

76.3 kbps

84.8 kbps

75.7 kbps

G.729A(50.0 pps)

29.6 kbps

26.4 kbps

42.4 kbps

25.6 kbps

G.729A(33.3 pps)

22.4 kbps

20.3 kbps

28.3 kbps

19.7 kbps

この項の計算では、電話機 1 台当たりの平均毎時コール数を 10 と想定します。

公式 1 :制御トラフィックに必要な推奨帯域幅、TAPI アプリケーションなし

帯域幅(bps)= 150 ∗(事業所内の IP フォンとゲートウェイの数)

公式 2 :制御トラフィックに必要な推奨帯域幅、TAPI アプリケーションあり

TAPI を使用する場合の帯域幅(bps)= 225 ∗(事業所内の IP フォンとゲートウェイの数)

表 2-6 では、さまざまな事業所の規模に対する推奨帯域幅を示しています。

 

表 2-6 コール制御トラフィック用の推奨帯域幅(TAPI アプリケーションの有無別)

事業所の規模
(IP フォンとゲートウェイの数)
制御トラフィック用の
推奨帯域幅(TAPI なし)
制御トラフィック用の
推奨帯域幅(TAPI あり)

1 ~ 30

8 kbps

8 kbps

40

8 kbps

9 kbps

50

8 kbps

11 kbps

60

9 kbps

14 kbps

70

11 kbps

16 kbps

80

12 kbps

18 kbps

90

14 kbps

21 kbps

100

15 kbps

23 kbps

110

17 kbps

25 kbps

120

18 kbps

27 kbps

130

20 kbps

30 kbps

140

21 kbps

32 kbps

150

23 kbps

34 kbps


表 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 コールであると推論することができます。この前提により、コール制御トラフィック用の推奨帯域幅を仮想タイ ライン数の関数として表す、次の公式が得られます。

公式 5 :仮想タイ ライン数に基づく推奨帯域幅

推奨帯域幅(bps)= 116 ∗(仮想タイ ライン数)

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 資料を参照してください。

http://cisco.com/go/srnd

ATM とフレームリレーのサービス インターワーキング(SIW)リンクでは、cRTP を使用しないでください。

cRTP を使用する前に検討する必要がある重要なパラメータは、ルータの CPU 利用率です。これは、圧縮処理と圧縮解除処理の際に高まるので、注意が必要です。

LFI(Link Fragmentation and Interleaving)

低速リンク(768 kbps 未満)の場合、LFI を使用してください。

トラフィック シェーピング

トラフィック シェーピングは、ATM やフレームリレーなどの複数アクセスの非ブロードキャスト メディアに必要です。この場合、物理的なアクセス速度は 2 つのエンドポイント間で異なります。通常、複数の事業所サイトは、中央サイトのルータの単一インターフェイスへ集約されます。

次のシナリオでは、同一 IP WAN 上での音声とデータの転送時にトラフィック シェーピングが必要な理由を示しています。

ライン スピード ミスマッチ

中央サイトのインターフェイスは、一般に高速インターフェイス(たとえば、T1 以上)ですが、小規模なリモート サイトの事業所のインターフェイス回線速度はかなり遅くなります(たとえば、64 kbps)。データが中央サイトから低速リモート サイトにフル レートで送信されると、リモート サイトのインターフェイスは輻輳し、音声パフォーマンスが低下する場合があります。

リモート サイトから中央サイトへの集約時の過剰サブスクリプション

複数のリモート サイトを 1 つの中央サイトに集約する場合、帯域幅を余分にサブスクライブするのは、フレームリレーまたは ATM ネットワークでは一般的な方法です。たとえば、T1 インターフェイスで WAN に接続するリモート サイトが複数あるにもかかわらず、中央サイトには 1 つの T1 インターフェイスしかない場合があります。この設定により、配置されたネットワークは統計多重化による恩恵を受けますが、中央サイトのルータ インターフェイスが、トラフィックのバースト時に輻輳し、音声品質が低下することがあります。

CIR(認定情報レート)を超えたバースト

もう 1 つの一般的な設定は、CIR を超えたトラフィック バーストを許可することです。CIR は、サービス プロバイダーが、損失なく、遅延の少ないネットワークを介して転送することを保証したレートです。たとえば、T1 インターフェイスを備えたリモート サイトでは、CIR が 64 kbps に過ぎない場合があります。64 kbps 以上に相当するトラフィックが WAN を介して送信される場合、プロバイダーは、追加トラフィックに「discard eligible(廃棄適性)」のマークを付けます。プロバイダーのネットワークで輻輳が発生した場合、このトラフィックは廃棄され、音声品質に悪影響を与える場合があります。

トラフィック シェーピングは、インターフェイスから送出されるトラフィックを、回線レート未満に制限することによって問題を解決し、WAN の両端で輻輳が発生しないようにします。