Cisco IP テレフォニー QoS デザイン ガイド
ワイドエリア ネットワークの 実装
ワイドエリア ネットワークの実装
発行日;2012/01/07 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

ワイドエリア ネットワークの実装

WAN QoS の概要

分類

キューイング

Link Fragmentation and Interleaving

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

ネットワーク プロビジョニング

コール アドミッション制御

その他の WAN QoS ツール

VoIP 制御トラフィック

TX リング サイジング

圧縮音声コーデック

圧縮 RTP

VAD

ポイントツーポイント WAN

ポイントツーポイント WAN 上での LFI

MLP 接続上の cRTP

MLP を介した VoIP のための LLQ

MLP 接続でのキューイング、フラグメント化、およびインターリーブの検証

フレーム リレー WAN

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

認定情報レート

認定バースト レート

超過バースト レート

最小 CIR

フレーム リレー WAN 上の LFI 用の FRF.12

フレーム リレー接続上の cRTP

フレーム リレーを介した VoIP のための LLQ

フレーム リレー キューイング、フラグメント化、およびインターリーブの検証

ATM WAN

低速 ATM WAN 上の 2 つの PVC または LFI

ATM 接続上の cRTP

MLP を介した VoIP のための LLQ

フレーム リレー ATM 間インターワーキング WAN

低速 ATM フレーム リレー間インターワーキング WAN 上の LFI

セントラル サイトの ATM 設定

リモート サイトのフレーム リレー設定

ATM フレーム リレー間接続上の cRTP

ATM およびフレーム リレーを介した音声のための LLQ

要約

ワイドエリア ネットワークの実装

この章では、お使いの Cisco AVVID ソリューションを WAN と統合するための設計に関する考慮事項および推奨事項を説明します。

WAN QoS の概要

データ、音声、およびビデオ ネットワークの集約化を進める最大の理由の 1 つは、これらを維持するのにかかる総コストが低いことです。ネットワーク集約化は企業通信インフラストラクチャの全体的なコストを軽減できますが、正常な Cisco AVVID 配置のためには、確実な計画および設計が必要です。このことは、ワイドエリア ネットワーク(WAN)を介して VoIP を実行したときに特に明白になります。

第 1 章「概要」で説明しているとおり、ネットワーク全体で音声品質を確保できる環境を提供するには、IP ネットワークの各部分で 3 つの基本ツールを使用する必要があります。

分類

キューイング

ネットワーク プロビジョニング

WAN の低帯域幅および低速リンク速度を Cisco AVVID 設計に採用する場合、その他いくつかの QoS ツールも使用する必要があります。

Link Fragmentation および Interleaving(LFI)

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

コール アドミッション制御

これらのすべてのツールのほか、いくつかのツールについて、これ以降の項で説明します。

分類

分類とは、特定のトラフィック タイプが分類されること、つまり、固有の処理要件をもつものとしてマーキングされる方式です。これらの処理要件には、必要最少限の量の帯域幅であることや、遅延に対して許容度を低くすることなどがあります。この分類は、タグによってネットワーク要素に通知されます。このタグは、IP Precedence または Differentiated Services Code Point(DSCP)、802.1p などのレイヤ 2 方式、発信元および宛先の IP アドレス、あるいは Real-time Transport Protocol(RTP)および定義済みポート範囲を使用するトラフィック タイプなどのデータ自体の暗黙特性に含まれています。

推奨 Cisco AVVID QoS 設計モデルでは、分類は、IP 電話上のレイヤ 2 およびレイヤ 3 の両方で行われます。このモデルでは、電話は管理対象ネットワークの「エッジ」であり、この電話によりレイヤ 2の 802.1p CoS 値が 5、かつレイヤ 3 の IP Precedence 値が 5 に設定されるか、あるいは DSCP 値が EF に設定されます。分類の詳細は、第 2 章「IP 電話の接続」を参照してください。

キューイング

ここまでの章で説明されているとおり、インターフェイス キューイングは、データ ネットワーク内で音声品質を確保するための最も重要なメカニズムの 1 つです。ごく限られた量のネットワーク リソースを求めて多くのトラフィック フローが競うため、キューイングは、WAN 内ではさらに重要になります。トラフィックが分類されると、トラフィック フローを、その処理要件に適合するインターフェイス出口キューに入れられます。Voice over IP は、パケット喪失および遅延に対しての許容度がきわめて低いため、優先度キュー(PQ)に入れられる必要があります。ただし、他のトラフィック タイプも、特定の帯域幅と遅延特性をもっている場合もあります。これらの要件には、Cisco IOS の Low-Latency Queuing(LLQ)機能を使用して対処します。

LLQ により、PQ とクラス ベースの均等化キューイング方式の同時使用が可能になります。クラスは、分類アドミッション方式で定義されます。トラフィック フローは、PQ、クラス ベース キューのうちの 1 つ、またはデフォルトの均等化キューのいずれかにアクセスできます。LLQ は、すべての低速リンク用の推奨キューイング方式ですが、音声についての優先度キューイング動作などのパラメータを指定する能力を持つ最高 64 個までのトラフィック クラス、システム ネットワーク アーキテクチャ(SNA)データ、他のトラフィック タイプについての Cisco AVVID 制御プロトコルおよび均等化キューイングに対応できます。

図 5-1 に示されているとおり、優先度キューイング クラスが設定された場合、PQ は送信(TX)リングに直接アクセスできます。これは、もちろん、インターリーブが設定されないかぎり、インターリーブが設定された場合、PQ トラフィックを TX リングに置く前にインターリーブが発生します。

図 5-1 優先度キューイングをもつパケット フロー

 

PQ およびクラス ベース キュー内の最大設定済み帯域幅は、WAN 接続上の最小使用可能量の帯域幅を超えることはできません。実際の例として、128 kbps という認定情報レート(CIR)をもつフレーム リレー LLQ が挙げられます。VoIP に対する PQ が 64 kbps 用に設定され、SNA および Cisco AVVID 制御プロトコル クラス ベース キューがそれぞれ 20 kbps および 10 kbps 用に設定されている場合、設定済みの合計キュー帯域幅は 94 kbps です。Cisco IOS のデフォルトでは、CIR/2 という 最小 CIR( mincir )値が取られます。逆方向明示的輻輳通知(BECN)を受信すると、フレーム リレー ルータは mincir 値まで「レート ダウン」します。この例では、 mincir 値は 64 kbps で、結合されたキューの設定済み帯域幅よりも小さい値です。この例で LLQ が有効になるには、128 kbps という mincir 値を設定する必要があります。

Link Fragmentation and Interleaving

低速 WAN 接続(実際には、768 kbps 以下のクロッキング速度をもつもの)の場合、LFI(Link Fragmentation and Interleaving)用にメカニズムを提供することが必要です。物理ワイヤでは、そのインターフェイスのシリアライゼーション レートでのみデータ フレームを送信できます。このシリアライゼーション レートは、フレームのサイズをそのインターフェイスのクロッキング速度で除したものです。たとえば、1500 バイトのフレームは、56 kbp 回線上でのシリアライゼーションに 214 ms かかります。遅延に影響されやすい音声パケットが出力インターフェイス内で大きなデータ パケットの後ろにある場合、150 ~ 200 ms のエンドツーエンド遅延バジェットを超えることがあります。さらに、相対的に小さなフレームは、受信側の適応できるジッタ バッファのサイズよりも大きな値までジッタを単純に増やすことによって、全体的な音声品質に悪影響を及ぼす可能性があります。

 

表 5-1 シリアライゼーション遅延

リンク速度
フレーム サイズ(バイト単位)
64
128
256
512
1024
1500

56 kbps

9 ms

18 ms

36 ms

75 ms

144 ms

214 ms

64 kbps

8 ms

16 ms

32 ms

64 ms

128 ms

187 ms

128 kbps

4 ms

8 ms

16 ms

32 ms

64 ms

93 ms

256 kbps

2 ms

4 ms

8 ms

16 ms

32 ms

46 ms

512 kbps

1 ms

2 ms

4 ms

8 ms

16 ms

23 ms

768 kbps

0.640 ms

1.28 ms

2.56 ms

5.12 ms

10.4 ms

15 ms

LFI は、エンドツーエンド遅延を正確に予測できるように、大きなデータ フレームを通常のサイズのものにフラグメント化し、音声フレームをフローにインターリーブするのに使用されます。図 5-2 に図示されているとおり、これにより、音声トラフィックが大きなデータ フレームの後ろで遅れないようにすることでジッタ上に境界が置かれます。これに使用される 2 つの技法は、フレーム リレー用の FRF.12 と、ポイントツーポイント シリアル リンク用のマルチリンク ポイントツーポイント プロトコル(MLP)です。

図 5-2 フレーム遅延を短縮するための LFI ツールの使用

 

フラグメント化サイズを設定するために使用する推奨ターゲットは、10 ms のブロッキング遅延です。推奨フラグメント サイズを計算するには、次のように、10 ms の推奨遅延を、プロビジョニングされた回線クロッキング速度でのトラフィックの 1 バイトで除します。

Fragment_Size = (Max_Allowed_Jitter * Link_Speed_in_kbps) / 8

たとえば、次のようになります。

Fragment_Size = (10 ms * 56) / 8 = 70 バイト

表 5-2 では、各種リンク速度の推奨フラグメント サイズを示します。

 

表 5-2 推奨フラグメント サイズ

リンク速度
推奨フラグメント サイズ

56 kbps

70 バイト

64 kbps

80 バイト

128 kbps

160 バイト

256 kbps

320 バイト

512 kbps

640 バイト

768 kbps

960 バイト


) Cisco IOS リリース 12.1(5)T 以降では、フレーム リレーを介した MLP が使用可能で、ATM 上での LFI および ATM またはフレーム リレー インターワーキング WAN をサポートします。


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

ATM およびフレーム リレー ネットワークでは、実際のアクセス速度は 2 つのエンドポイント間で異なりますが、トラフィック シェーピングはこれらの速度の不一致が原因で輻輳したネットワーク インターフェイス バッファから生じた過度の遅延を防止するのに使用されます。トラフィック シェーピングは、発信元ルータから宛先ルータまでのフレームの送信レートを測定するツールです。この測定は、通常、送信インターフェイスの回線または回路レートよりも小さい値で行われます。測定は、現行の複数アクセス、非ブロードキャスト ネットワークでは一般的な回路レートの不一致を示すために、この速度で行われます。

セントラル サイトにある T1 回線などの高速インターフェイスを出たトラフィックは、たいていの場合、はるかに遅いリンク速度(たとえば、56 kbps)を持つリモート サイトで終了します。これは、極めて一般的なことですが、実際には、フレーム リレーの大きな「セールス ポイント」の 1 つになっています。図 5-3 で、セントラル サイトのルータ上の T1 インターフェイスは、リモート サイトのクロック速度が 56 kbps であっても T1 のレートでデータを送出します。これにより、フレームは通信事業者のフレーム リレー ネットワーク内でバッファに入れられるため、変動遅延が増大します(図 5-3 を参照)。これと同じシナリオが、逆に適用されることがあります。たとえば、それぞれが小さな WAN 接続を持っている多くのリモート サイトがまとめて追加されると、セントラル サイトのプロビジョニングされた帯域幅または回路速度が過剰加入になる可能性があります。

図 5-3 バッファリングにより発生する変動遅延

 

ネットワーク プロビジョニング

ネットワーク帯域幅を適切にプロビジョニングすることは、正常な Cisco AVVID ネットワークを設計する上で重要な要素です。各主要アプリケーション(たとえば、音声、ビデオ、データ)の帯域幅要件を加算すると、必要な帯域幅を計算できます。この合計は、あらゆる指定リンクの最小帯域幅要件を意味するため、概算で、そのリンクに対する使用可能帯域幅の合計の 75% を超えるものであってはなりません。この 75% ルールは、帯域幅の一部は、電子メールやハイパーテキスト転送プロトコル(HTTP)などのその他のアプリケーションだけでなく、ルーティングやレイヤ 2 キープアライブなどのオーバーヘッド トラフィックに必要であることを前提としています。図 5-4 では、この帯域幅プロビジョニング プロセスを示します。

図 5-4 リンク帯域幅のプロビジョニング

 

図 5-5 に示されているとおり、VoIP パケットは、ペイロード、IP ヘッダー、UDP(User Datagram Protocol)ヘッダー、RTP(Real-time Transport Protocol)ヘッダー、およびレイヤ 2 リンク ヘッダーで構成されています。20 ms というデフォルトのパケット化レートでは、VoIP パケットは、G.711 の場合は 160 バイトのペイロード、G.729 の場合は 20 バイトのペイロードを持ちます。IP ヘッダーは 40 バイト、UDP ヘッダーは 8 バイト、RTP ヘッダーは 12 バイトです。リンク ヘッダーは、メディアによりサイズが変化します。

図 5-5 一般的な VoIP パケット

 

VoIP ストリームが消費する帯域幅の計算は、パケット ペイロードとすべてのヘッダー(ビット単位)を加算し、これに1 秒当たりのパケット レート(デフォルトは 1 秒当たり 50 パケット)を乗じます。表 5-3 では、1 秒当たり 50 パケット(pps)のデフォルト パケット レートでの VoIP フロー当たりの帯域幅を詳しく示します。ここでは、レイヤ 2 ヘッダー オーバーヘッドは含まれず、圧縮 Real-time Transport Protocol(cRTP)など、可能な圧縮方式を考慮していません。Cisco CallManager 管理のサービス パラメータ メニューを使用して、パケット レートを調整できます。


) サンプリング レートを 30 ms 以上に設定することは可能ですが、そのように設定すると、たいていの場合、音声品質は非常に悪くなります。


 

表 5-3 音声ペイロードのみの帯域幅消費

CODEC
サンプリング レート
バイト単位の
音声ペイロード
1 秒当たりのパケット数
会話当たりの帯域幅

G.711

20 ms

160

50

80 kbps

G.711

30 ms

240

33

53 kbps

G.729A

20 ms

20

50

24 kbps

G.729A

30 ms

30

33

16 kbps

プロビジョニングのためのさらに正確な方式では、帯域幅の計算にレイヤ 2 ヘッダーを含めます(表 5-4 を参照)。

 

表 5-4 ヘッダーを含む帯域幅消費

CODEC
イーサネット
14 バイトのヘッダー
PPP
6 バイトのヘッダー
ATM
48 バイトのペイロードを持つ 53 バイトのセル
フレーム リレー
4 バイトのヘッダー

50 pps での G.711

85.6 kbps

82.4 kbps

106 kbps

81.6 kbps

33 pps での G.711

56.5 kbps

54.4 kbps

70 kbps

54 kbps

50 pps での G.729

29.6 kbps

26.4 kbps

42.4 kbps

25.6 kbps

33 pps での G.729

19.5 kbps

17.4 kbps

28 kbps

17 kbps

コール アドミッション制御

コール アドミッション制御は、音声フローが音声会話に割り当てられた最大供給帯域幅を超えないようにするためのメカニズムです。

音声、データ、および可能なビデオ アプリケーションをサポートするのに必要な帯域幅を使ってネットワークをプロビジョニングするための計算を行った後、音声に割り当てられている帯域幅の部分が音声により過剰加入にならないようすることが重要です。多くの QoS メカニズムは音声をデータから保護するのに使用されますが、コール アドミッション制御は、音声を音声から保護するのに使用されます。これを、図 5-6 に示します。ここには、ネットワークが 2 つの同時音声コールをサポートするためにプロビジョニングされた環境が示されています。3 つ目の音声コールが進行を許された場合、3 つのコールすべての品質が低下します。この音声品質の低下を防ぐために、Cisco CallManager でコール アドミッション制御をプロビジョニングして、3 つ目のコールの進行を防ぐことができます。コール アドミッション制御の詳細は、『Cisco IP テレフォニー ネットワーク デザイン ガイド』を参照してください。これは、次のサイトから入手できます。

http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/index.htm

図 5-6 コール アドミッション制御

 

その他の WAN QoS ツール

この項では、次に示すその他の QoS ツールについて説明します。これらのツールは、WAN アプリケーションでの音声品質を確保する上で役立ちます。

VoIP 制御トラフィック

TX リング サイジング

圧縮音声コーデック

圧縮 RTP(cRTP)

VAD(Voice Activity Detection)

VoIP 制御トラフィック

帯域幅を IP WAN 用に割り当てる場合、Cisco CallManager 制御トラフィックを見落とさないでください。中央集中型コール処理設計では、IP フォンは伝送制御プロトコル(TCP)制御接続を使用して Cisco CallManager と通信します。これらの小規模な制御接続用にプロビジョニングされた帯域幅が十分でない場合、発信者に悪影響が出ることがあります。

これに対して効果を示す例は、Delay to Dial-Tone(DTT)時間のあるものです。IP フォンは、TCP ポート 2000を通じて Skinny Station プロトコルにより Cisco CallManager と通信します。IP フォンはオフフックになると、何をするかを Cisco CallManager に「尋ね」ます。すると、Cisco CallManager は、IP 電話にダイヤル トーンを再生するよう指示します。ネットワーク内でこの Skinny プロトコルの管理および制御トラフィックのドロップまたは遅延が発生すると、ユーザはダイヤル トーンを受信できません。この同じ論理が、ゲートウェイおよび電話のすべてのシグナリング トラフィックに適用されます。

この制御および管理トラフィックに「重要」(音声ほど重要ではなく)というマークが挿入されるようにするために、アクセス コントロール リスト(ACL)を使用して、中央サイトに配置の Catalyst 6000 スイッチのレイヤ 3 または 4 上でトラフィック ストリームが分類されます。トラフィックの制御設定の例は、第 3 章「キャンパスの設計」に説明があります。リモート オフィスでは、パケットは WAN に達する前に、レイヤ 3 装置または 4 装置としての Cisco ルータにまず達する場合があります。これらの制御接続が「重要」(音声として重要ではなく)として分類されるには、リモートのブランチ ルータでアクセス リストが使用されるようにします。次に設定例を示します。

class-map VoIP-RTP
match access-group 100
class-map VoIP-Control
match access-group 101
!
policy-map QoS-Policy
class VoIP-RTP
priority 100
class VoIP-Control
bandwidth 8
class class-default
fair-queue
!
access-list 100 permit ip any any precedence 5
access-list 100 permit ip any any dscp ef
!
! Skinny Control Traffic - Not required with
! Cisco CallManager Release 3.0(5) and beyond.
access-list 101 permit tcp any host 10.1.10.20 range 2000 2002
!
! MGCP Control Traffic
access-list 101 permit udp any host 10.1.10.20 2427
access-list 101 permit tcp any host 10.1.10.20 2428
!
! H.323 Control Traffic
access-list 101 permit tcp any host 10.1.10.20 1720
access-list 101 permit tcp any host 10.1.10.20 range 11000 11999
 

TX リング サイジング

TX リングは、ドライブへの送信リンク使用率が 100% になるまでフレームを保持するのに使用される優先順位を持たない FIFO バッファです。Cisco 7500 ルート/スイッチ プロセッサ(RSP) では、これは、TX キューと呼ばれており、 tx-queue-limit コマンドを使用して修正できます。RSP はかなり効率の悪い QoS プラットフォームです。特に TX キュー パラメータを修正するには、非効率的です。Cisco 7500 RSP TX キューは、MEM-D では FIFO キューと呼ばれますが、MEM-D から DRAM 内のシステム バッファにパケットをコピーした後で、システム バッファから MEM-D に戻らなければなりません。TX リングは、TX キューよりもはるかに効率がよく、Cisco 7500 VIP、7200、3600、2600、および 1750 ルータでは TX キューの代わりに使用されます。

フラグメント化とインターリーブによりジッタは少なくなりますが、TX リング値が大きいと、リンク使用率が 100% に近づくにつれて、ジッタが増える可能性があります。このため、TX リング サイジングがフラグメント化サイズに関連します(表 5-5 を参照)。


) TX リング バッファのサイジングは、ビット単位ではなく、パケット単位で測定されます。


 

表 5-5 TX リング バッファ サイジング

リンク速度(CIR)
相手先固定接続
TX リング バッファ サイジング
(パケット数)

=< 128 kbps

5

192 kbps

6

256 kbps

7

512 kbps

14

768 kbps

21

すべてのポイントツーポイント プロトコル(PPP)およびマルチリンク PPP(MLP)リンク上で、TX リング バッファ サイズは、自動的に設定されるため、これらのデフォルト バッファ値は変更できません。

フレーム リレー リンク上で、TX リング は、メイン インターフェイス用です。このリングは、すべてのサブインターフェイスにも使用されます。デフォルト TX リング バッファ サイズは 64 パケットです。サブインターフェイスが非常に小さい場合、またはサブインターフェイスの数が多い場合、この設定を変更しなければならないことがあります。

表 5-6 に、各種メディア用の TX リング バッファ サイジングを要約します。

 

表 5-6 TX リング バッファ サイジング

メディア
デフォルト TX リング バッファ サイジング
(パケット数)

PPP

6

MLP

2

ATM

8192(低速仮想回線の場合は変更する必要があります)

フレーム リレー

64(メインの T1 インターフェイス当たり)

圧縮音声コーデック

限定された WAN 帯域幅を可能な限り多く利用するために、VoIP はコーデック(符号化/逆符号化アルゴリズム)を使用して、アナログ音声サンプルをデジタル化します。G.729 など、多くのコーデックは、64-kbps のコールを 8 kbps に圧縮できます。これらのタイプのコーデックは、低ビット レート コーデックと呼ばれますが、一般的に、WAN を介した音声コール用に使用されます。

圧縮 RTP

圧縮 RTP(cRTP)は、VoIP の 40 バイトのヘッダーを約 2 ~ 4 バイトに圧縮します。圧縮 RTP は、リンク単位ベースで動作し、Cisco ルータ上では、 ip rtp header-compression コマンドでイネーブルになります。表 5-7 では cRTP の帯域幅の計算を要約します。


) cRTP は、現在のところ、専用回線およびフレーム リレーについてのみサポートされています。Cisco IOS リリース 12.1(2)T は、これらのプラットフォームに対するパフォーマンスを大幅に向上させるものですが、スケーラブル cRTP の最小推奨システム ソフトウェアです。


 

表 5-7 圧縮 RTP 帯域幅の計算

コーデック
PPP
6 バイトのヘッダー
ATM
48 バイトのペイロードを持つ 53 バイトのセル
フレーム リレー
4 バイトのヘッダー

50 pps での G.711

68 kbps

利用不能

67 kbps

33 pps での G.711

44 kbps

利用不能

44 kbps

50 pps での G.729

12 kbps

利用不能

11.2 kbps

33 pps での G.729

8 kbps

利用不能

7.4 kbps

VAD

VAD(Voice Activity Detection)は、ほとんどの会話で、一度に話せるのは 1 人だけであるという事実を利用します。VoIP ソフトウェアの VAD アルゴリズムは、音声会話内にギャップがないかを調べます。ギャップが見つかると、パケットは送信されないため、WAN 帯域幅はデータ アプリケーションで使用できるように回復できます。必ず、システム全体で VAD をオフにしてください。


) 遅延が大量に発生しやすい環境では、VAD により、回復後の帯域幅で単に正当化することはできない音声品質問題が発生する可能性があります。これらの問題は、ケースバイケースで検討する必要があります。ただし、Cisco AVVID ネットワーク内の会話の始まりでのクリッピングをトラブルシューティングする場合、最初に Silence Suppression をディセーブルにしてください。


ポイントツーポイント WAN

ポイントツーポイント WAN は、以前ほど広く使用されていませんが、今日使用されている最も一般的なタイプのネットワークの 1 つです。図 5-7 では、このガイドに記載されているポイントツーポイント WAN の一般的なモデルを示します。

図 5-7 ポイントツーポイント WAN の一般的なモデル

 

Cisco AVVID ネットワークのポイントツーポイント WAN を設計する場合、次の推奨事項に留意してください。

Cisco IOS リリース 12.1(3)T は、ポイントツーポイント WAN のための最小推奨リリースです。

768 kbps 未満の速度のすべての WAN 接続で LFI(Link Fragmentation and Interleaving)技法を使用します。

VoIP ベアラ ストリーム用の優先度キューおよび VoIP 制御セッション用のクラス キューと一緒に低遅延キューイング(LLQ)を使用します。

WAN を介したコールの数により割り当てられた VoIP 帯域幅が過剰加入になる可能性がある場合は、コール アドミッション制御が必要です。

これ以降の項で、このタイプの設定の QoS 問題について説明します。

ポイントツーポイント WAN 上での LFI

接続のクロッキング速度が 768 kbps 未満の場合、LFI を使用する必要があります。LFI が必要なすべてのポイントツーポイント リンク上で、PPP の代わりにマルチリンク PPP(MLP)が必要です。ポイントツーポイント WAN 上で LFI をイネーブルにするには、MLP 用の Cisco IOS コマンドを使用します。


) MLP を使用する場合、フラグメント化サイズは、キュー内の最大許容遅延(10 ms)を使用して設定します。また、TX リングは、2 パケットの値で静的に設定されます。


次の例では、このタイプの設定に使用されるコマンドを示しています。

interface Multilink1
ip address 10.1.61.1 255.255.255.0
ip tcp header-compression iphc-format
no ip mroute-cache
load-interval 30
service-policy output QoS-Policy
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 1
ip rtp header-compression iphc-format
!
interface Serial0
bandwidth 256
no ip address
encapsulation ppp
no ip mroute-cache
load-interval 30
no fair-queue
ppp multilink
multilink-group 1
 

MLP 接続上の cRTP

圧縮 RTP(cRTP)は、各音声コールで使用される帯域幅の量に深刻な影響を及ぼすことがあります。Cisco IOS リリース 12.0(7)T より以前のリリースでは、cRTP はプロセス切り替え式でした。実際、cRTP の高速切り替えは、Cisco IOS リリース 12.0(7)T でバグ修正が実装されるまで、Catalyst 2600 および 3600 では使用できませんでした。また、それより新しいバージョンの Cisco IOS(特にリリース 12.1(2.x)T)でも、cRTP にはプロセス切り替えを使用しています。固有の機能をお使いになる前に、必ず、リリース情報をお読みください。

次の例では、このタイプの設定に使用されるコマンドを示しています。

interface Multilink1
ip address 10.1.61.1 255.255.255.0
ip tcp header-compression iphc-format
no ip mroute-cache
load-interval 30
service-policy output QoS-Policy
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 1
ip rtp header-compression iphc-format
 

MLP を介した VoIP のための LLQ

WAN を介して音声をサポートするには、低遅延キューイング(LLQ)が必要です。MLP 対応インターフェイス用に LLQ を設定する場合、マルチリンク インターフェイス設定に service-policy output を入れます。次の例では、2 つのクラスが定義されます。1 つは VoIP メディア ストリーム用で、もう 1 つは制御トラフィック用です。これらのクラス、つまりそれらが処理するキューへのアクセスは、レイヤ 3 ToS 分類または発信元および宛先の IP アドレスとポートのどちらかに一致するアクセス リストを使用して行われます。アクセス リストは、セントラル サイトでは制御トラフィックの場合と少し違って見えます。Catalyst 6000 はすでに、26 という DSCP 値(IP Precedence 3 とバックワード コンパティビリティのある AF31)を使って VoIP 制御セッションを分類しているためです。

すべての VoIP メディア トラフィックは、優先度キュー(PQ)に入れられます。この優先度キューには、100 kbps の帯域幅が与えられています。Skinny プロトコル制御トラフィックはすべて、クラス ベース キューに入れられ、10 kbps の帯域幅が与えられます。その他のすべてのトラフィックは、均等化キューイングを使用してキューに入れられます。

次の例では、このタイプの設定に使用されるコマンドを示しています。

class-map VoIP-RTP
match access-group 100
class-map VoIP-Control
match access-group 101
!
policy-map QoS-Policy-256k
class VoIP-RTP
priority 100
class VoIP-Control
bandwidth 8
class class-default
fair-queue
!
interface Multilink1
ip address 10.1.61.1 255.255.255.0
ip tcp header-compression iphc-format
no ip mroute-cache
load-interval 30
service-policy output QoS-Policy
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 1
ip rtp header-compression iphc-format
!
! ToS VoIP Media Stream Classification: either IP Prec or DSCP
! This access-list is the same at the both the remote and
! central locations
access-list 100 permit ip any any precedence 5
access-list 100 permit ip any any dscp ef
!
! Skinny, H.323 and MGCP VoIP Control Traffic
! which has already been classified using the
! route-map in section 4.5.
access-list 101 permit ip any any precedence 3
access-list 101 permit ip any any dscp 26
 

MLP 接続でのキューイング、フラグメント化、およびインターリーブの検証

設定を検証するには、次のコマンドを使用します(それぞれの関連出力と一緒に示してあります)。

1750# sh queue multilink1

Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 8288

Queueing strategy: weighted fair

Output queue: 63/1000/64/8288/1967(size/maxtotal/threshold/drops/interleaves)

Conversations 1/3/256 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

 

! All drops and interleaves are occurring on ToS=0 flows

(depth/weight/discards/tail drops/interleaves) 63/32384/8288/0/1967

Conversation 60, linktype: ip, length: 1008

source: 10.1.60.98, destination: 10.1.10.98, id: 0x0322, ttl: 63,

TOS: 0 prot: 17, source port 1024, destination port 7

 

 

1750# sh policy interface multilink1

Multilink1

output : QoS-Policy-256k

Class VoIP-RTP

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 100 (kbps)

(pkts matched/bytes matched) 28100/5675882

(pkts discards/bytes discards) 0/0

Class VoIP-Control

Weighted Fair Queueing

Output Queue: Conversation 265

Bandwidth 8 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 204/10284

(pkts discards/bytes discards/tail drops) 0/0/0

Class class-default

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

 

フレーム リレー WAN

フレーム リレー ネットワークは、関連コストが廉価であるため、今日最も広く使用されている WAN です。ただし、フレーム リレーは、コスト節減の目的から過剰加入を利用する非ブロードキャスト テクノロジであるため、必ずしも、Cisco AVVID ソリューションの実装が容易なプラットフォームではありません。この項では、フレーム リレー WAN を介して Cisco AVVID ソリューションを正常に配置するための基本要件を説明しますが、フレーム リレー認定情報レート(CIR)、認定バースト レート(Bc)、および超過バースト(Be)については詳しく説明していません。

図 5-8 では、本書に記載されているフレーム リレー WAN の一般的なモデルを示します。

図 5-8 フレーム リレー WAN の一般的なモデル

 

Cisco AVVID ネットワークのフレーム リレー WAN を設計する場合、次の推奨事項に留意してください。

Cisco IOS リリース 12.1(2)T は、フレーム リレー WAN のための最小推奨リリースです。

フレーム リレー WAN でトラフィック シェーピングを使用する必要があります。

768 kbps 未満の速度のすべての仮想回線で LFI(Link Fragmentation and Interleaving)を使用します。

VoIP ベアラ ストリーム用の優先度キューおよび VoIP 制御セッション用のクラス ベース キューと一緒に低遅延キューイング(LLQ)を使用します。

WAN を介したコールの数により割り当てられた VoIP 帯域幅が過剰加入になる可能性がある場合は、コール アドミッション制御が必要です。

これ以降の項で、このタイプの設定の QoS 問題について説明します。

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

フレーム リレー ネットワークについては、次の 3 つの理由から、トラフィック シェーピングが必要です。

サイトの過剰加入は、フレーム リレー ネットワークの性質の 1 つである。

設定が認定情報レート(CIR)を超えるバーストを許容するのは一般的なことである。

Cisco フレーム リレー装置のデフォルト インターバルにより、不要な遅延が追加される可能性がある。

以下の項では、フレーム リレー ネットワークのトラフィック シェーピングの特徴をいくつか説明します。

認定情報レート

ほとんどのフレーム リレー ネットワークにおいて、セントラル サイトは、T1 リンクまたはそれより高速のものを使用して、多数のリモート オフィスからの WAN 接続を終了します。セントラル サイトは 1.536 Mbps でデータを送出しますが、リモート サイトには 56-kbps の回線しかない場合があります。また、一般的に、リモート オフィス対セントラル ハブの比率は、多数のリモート オフィスに対して 1 つのセントラル ハブとなっています。すべてのリモート サイトが、ハブの T1 を圧倒するレートでトラフィックを送信することは大いにあり得ることです。これらのシナリオは両方とも、遅延、ジッタ、およびドロップが存在するプロバイダ ネットワークにおけるフレーム バッファリングの原因となる可能性があります。唯一のソリューションは、セントラル ルータおよびリモート ルータの両方でトラフィック シェーピングを使用することです。

認定バースト レート

フレーム リレー ネットワークに関するもう 1 つの問題は、任意の指定時間にノードが送信できるデータの量です。56-kbps の相手先固定接続(PVC)は、1 秒間で最高 56 k ビットのトラフィックを送信できます。この秒の除算方法をインターバルといいます。このインターバル間にノードが送信できるトラフィックの量を、認定バースト(Bc)レートといいます。デフォルトでは、すべての Cisco ルータでは Bc は CIR/8 に設定されます。インターバルの計算式は、次のとおりです。

インターバル = Bc/CIR

たとえば、56 kbps の CIR を使用した場合は、次のようになります。

インターバル = 7000 / 56,000 = 125 ms

前述の例では、ルータは、その割り当てられた 7000 ビットを送信してから、その次のトラフィックを送信するまでに 125 ms 待機する必要があります。これは、データにとっては適切なデフォルト値ですが、音声にとっては極めて不適切な選択です。Bc 値をはるかに小さい数値に設定することにより、インターバルを短縮できますが、それは、ルータがトラフィックをさらに頻繁に送信することを意味します。Bc の最適な設定値は 1000 です。

超過バースト レート

ルータがそのすべての Bc(たとえば、1000 ビット)を送信するのに十分なトラフィックを持っていない場合、そのアカウントを「貸方記入」し、後のインターバルでさらに多くのトラフィックを送信できます。超過バースト(Be)レートは、ルータのトラフィック アカウントに貸方記入できる最大量を定義します。Cisco AVVID ネットワークでの Be に関する問題は、受信側は、Bc + Be ではなく、Bc というレートでのみ回線からトラフィックを「引き出す」ことができるため、これによりフレーム リレー ネットワーク内でのバッファリング遅延の可能性が生じることです。

最小 CIR

Cisco IOS のデフォルトは、CIR/2 という 最小 CIR( mincir )値に設定されています。最小 CIR は、BECN を受信したときにフレーム リレー ルータが「レート ダウン」する送信値です。


) 優先度キュー(PQ)およびクラス ベース キュー内の最大設定済み帯域幅は、WAN 接続上の最小使用可能量の帯域幅を超えることはできません。


次の例では、256-kbps フレーム リレー回線に接続されているリモート サイト ルータのための設定を示します。

interface Serial1
no ip address
encapsulation frame-relay
load-interval 30
frame-relay traffic-shaping
!
interface Serial1.71 point-to-point
bandwidth 256
ip address 10.1.71.1 255.255.255.0
frame-relay interface-dlci 71
class VoIP-256kbs
!
map-class frame-relay VoIP-256kbs
frame-relay cir 256000
frame-relay bc 1000
frame-relay be 0
frame-relay mincir 256000
no frame-relay adaptive-shaping
service-policy output QoS-Policy-256k
frame-relay fragment 320
 

フレーム リレー WAN 上の LFI 用の FRF.12

フレーム リレー WAN 上で LFI(Link Fragmentation and Interleaving)をイネーブルにするには、トラフィック シェーピングも使用する必要があります。MLP と異なり、実際のフラグメント サイズは、フレーム リレー上で LFI を使用する場合に設定する必要があります。フレーム リレー ネットワークにおいて、フラグメント化サイズは、インターフェイスの実際のシリアライゼーション レート(クロッキング速度)ではなく、相手先固定接続(PVC)に基づきます。フレーム リレー トラフィック シェーピング ポリシーにより、認定情報レート(CIR)内の指定のビット レートはインターフェイス 送信バッファに入ることができるため、この方式が使用されます。すなわち、PVC CIR のレートとは、フレーム リレー環境におけるフラグメント化要件を見積もるときに参照するクロック レートです。

次の例では、このタイプの設定に使用されるコマンドを示しています。

map-class frame-relay VoIP-256kbs
frame-relay cir 256000
frame-relay bc 1000
frame-relay be 0
frame-relay mincir 256000
no frame-relay adaptive-shaping
service-policy output QoS-Policy-256k
frame-relay fragment 320
 

フレーム リレー接続上の cRTP

圧縮 RTP(cRTP)は、各音声コールが使用する帯域幅の量に深刻な影響を及ぼすことがあります。cRTP 高速切り替えは Cisco IOS リリース 12.0(7)T を使用してイネーブルにされましたが、それより新しい Cisco IOS のリリース(特にリリース 12.1(2.x)T)は、今でも、cRTP のプロセス切り替えを使用しています。固有の機能をお使いになる前に、必ず、リリース情報をお読みください。

次の例では、このタイプの設定に使用されるコマンドを示しています。

interface Serial1
no ip address
encapsulation frame-relay
load-interval 30
frame-relay traffic-shaping
ip rtp header-compression iphc-format

フレーム リレーを介した VoIP のための LLQ

WAN を介して音声をサポートするには、低遅延キューイング(LLQ)が必要です。フレーム リレー インターフェイス用に LLQ を設定する場合は、 map-class frame-relay 設定セクションに service-policy output を入れます。次の例では、2 つのクラスが定義されます。1 つは VoIP メディア ストリーム用で、もう 1 つは制御トラフィック用です。これらのクラス、つまりそれらが処理するキューへのアクセスは、レイヤ 3 ToS 分類または発信元および宛先の IP アドレスとポートのどちらかに一致するアクセス リストを使用して行われます。アクセス リストは、セントラル サイトでは制御トラフィックの場合と少し違って見えます。Catalyst 6000 はすでに、26 という DSCP 値(IP Precedence 3 とバックワード コンパティビリティのある AF31)を使って VoIP 制御セッションを分類しているためです。

すべての VoIP メディア トラフィックは、優先度キュー(PQ)に入れられます。この優先キューは、100 kbps の帯域幅が与えられています。Skinny プロトコル制御トラフィックはすべて、クラス ベース キューに入れられ、10 kbps の帯域幅が与えられます。その他のすべてのトラフィックは、均等化キューイングを使用してキューに入れられます。

次の例では、このタイプの設定に使用されるコマンドを示します。

class-map VoIP-RTP
match access-group 100
class-map VoIP-Control
match access-group 101
!
policy-map QoS-Policy-256k
class VoIP-RTP
priority 100
class VoIP-Control
bandwidth 8
class class-default
fair-queue
!
interface Serial1
no ip address
encapsulation frame-relay
load-interval 30
frame-relay traffic-shaping
!
interface Serial1.71 point-to-point
bandwidth 256
ip address 10.1.71.1 255.255.255.0
frame-relay interface-dlci 71
class VoIP-256kbs
!
map-class frame-relay VoIP-256kbs
frame-relay cir 256000
frame-relay bc 1000
frame-relay be 0
frame-relay mincir 256000
no frame-relay adaptive-shaping
service-policy output QoS-Policy-256k
frame-relay fragment 160
!
! ToS VoIP Media Stream Classification: either IP Prec or DSCP
! This access-list is the same at the both the remote and
! central locations
access-list 100 permit ip any any precedence 5
access-list 100 permit ip any any dscp ef
!
! Skinny, H.323 and MGCP VoIP Control Traffic
! which has already been classified using the
! route-map in section 4.5.
access-list 101 permit ip any any precedence 3
access-list 101 permit ip any any dscp 26
 

フレーム リレー キューイング、フラグメント化、およびインターリーブの検証

設定を検証するには、次のコマンドを使用します(それぞれの関連出力と一緒に示してあります)。

3600# sh policy interface s 0/1.73

Remote Branch 3600

Serial0/1.73: DLCI 73 -

 

Service-policy output: QoS-Policy-256k (1117)

 

Class-map: VoIP-RTP (match-all) (1118/2)

5008 packets, 964953 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: ip precedence 5 (1120)

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 40

Bandwidth 100 (kbps)

(pkts matched/bytes matched) 4976/955161

(pkts discards/bytes discards) 0/204

 

Class-map: VoIP-Control (match-all) (1122/3)

53 packets, 3296 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: ip precedence 3 (1124)

Weighted Fair Queueing

Output Queue: Conversation 41

Bandwidth 8 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 53/3296

(pkts discards/bytes discards/tail drops) 0/0/0

 

Class-map: class-default (match-any) (1126/0)

5329 packets, 985755 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: any (1128)

5329 packets, 985755 bytes

30 second rate 0 bps

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 32

 

 

HQ_7200# sh frame-relay pvc int s6/0 73

Headquarters 7200

 

PVC Statistics for interface Serial6/0 (Frame Relay DTE)

 

DLCI = 73, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial6/0.73

 

input pkts 114 output pkts 103 in bytes 8537

out bytes 10633 dropped pkts 0 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 62 out bcast bytes 5203

pvc create time 00:04:22, last time pvc status changed 00:04:22

service policy QoS-Policy-256k

 

Service-policy output: QoS-Policy-256k (1099)

 

Class-map: VoIP-RTP (match-all) (1100/2)

0 packets, 0 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: ip dscp 46 (1102)

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 72

Bandwidth 100 (kbps)

(pkts matched/bytes matched) 0/0

(pkts discards/bytes discards) 0/0

 

Class-map: VoIP-Control (match-all) (1104/3)

25 packets, 3780 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: ip dscp 26 (1106)

Weighted Fair Queueing

Output Queue: Conversation 73

Bandwidth 8 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 25/3780

(pkts discards/bytes discards/tail drops) 0/0/0

 

Class-map: class-default (match-any) (1108/0)

163 packets, 15708 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: any (1110)

163 packets, 15708 bytes

30 second rate 0 bps

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 64

Output queue size 0/max total 600/drops 0

fragment type end-to-end fragment size 160

cir 768000 bc 7680 be 0 limit 960 interval 10

mincir 768000 byte increment 960 BECN response no

frags 125 bytes 10913 frags delayed 125 bytes delayed 10913

 

shaping inactive

traffic shaping drops 0

 

ATM WAN

非同期転送モード(ATM)は、多くのサービス プロバイダがこのテクノロジを採用しているため、WAN の一般的な媒体となりつつあります。図 5-9 では、このガイドに記載されている ATM WAN の一般的なモデルを示します。

図 5-9 ATM WAN の一般的なモデル

 

WAN での ATM 使用に関する難しさの 1 つに、それが、低速ではなく、高速用に設計されているということがあります。多くの企業は、低速 ATM 接続を介して Cisco AVVID ソリューションを配置しようとしています。このことが一般的に複雑な問題を生み出します。Cisco IOS QoS ツールの多くは現在 ATM インターフェイス上でサポートされておらず、インターフェイス デフォルトの多くは、高速 ATM 回路に合うよう自動的に設定されるためです。

このことは、ATM TX リング バッファのデフォルト サイジングで明白になります。たとえば、デフォルトでは、Cisco 7200 ルータ OC-3 インターフェイス(PA-A3)は、TX リング バッファを 8192 バイトに設定します。これは、OC-3 については正しい設定ですが、インターフェイス上で設定された 256-kbps 相手先固定接続(PVC)に対しては、非常に大きな TX リング バッファ遅延が発生する可能性があります。このため、TX リングを、サブインターフェイス レベルではるかに小さい値に設定する必要があります。たとえば、次の設定は、256-kbps ATM PVC に接続されたリモート サイト ルータ用です。

interface ATM2/0
no ip address
no ip mroute-cache
atm pvc 1 0 16 ilmi
no atm ilmi-keepalive
!
interface ATM2/0.37 point-to-point
pvc cisco37 0/37
tx-ring-limit 7
abr 256 256
service-policy output QoS-Policy-256k
protocol ppp Virtual-Template2
!
!
 

Cisco AVVID ネットワークの ATM WAN を設計する場合、次の推奨事項に留意してください。

ATM を介した MLP 用の Cisco IOS リリース 12.1(5)T は、ATM WAN の最小推奨リリースです。

DS-3 速度未満のすべての ATM 接続について、TX リング バッファ サイズを調整する必要があります。

相手先固定接続(PVC)速度が 768 kbps 未満の場合は、2 つの PVC を使用してください。

768 kbps 未満の PVC を 1 つ使用している場合は、LFI 用の ATM を介して MLP を使用します。

VoIP ベアラ ストリーム用の優先度キューおよび VoIP 制御セッション用のクラス ベース キューと一緒に低遅延キューイング(LLQ)を使用します。

WAN を介したコールの数により割り当てられた VoIP 帯域幅が過剰加入になる可能性がある場合は、コール アドミッション制御が必要です。

これ以降の項で、このタイプの設定の QoS 問題について説明します。

低速 ATM WAN 上の 2 つの PVC または LFI

768 kbps 未満で PVC を使用する場合、ATM ネットワーク用に VoIP を設計する最良の方式は、音声とデータに対して別々の PVC を使用することです。次の例では、このタイプの設定を示します。

interface ATM2/0.38 point-to-point
bandwidth 256
ip address 10.1.38.52 255.255.255.0
pvc cisco38 0/38
service-policy output Data-Policy-128k
vbr-nrt 128 128
encapsulation aal5snap
interface ATM2/0.39 point-to-point
bandwidth 256
ip address 10.1.39.52 255.255.255.0
pvc cisco39 0/39
tx-ring-limit 7
service-policy output VoIP-Policy-128k
vbr-nrt 128 128
encapsulation aal5snap
 

2 つの PVC が許容可能な設計の代わりにならない場合、もう 1 つのオプションとして、LFI(link fragmentation and interleaving)用に AMT を介して新しい MLP ツールを使用することが挙げられます。ATM は固定ペイロード サイズを使用するセル テクノロジであるため、固有の LFI ツールはありません。新しい標準は、ATM を介して MLP を使用するもので、Cisco IOS リリース 12.1(5)T に入っています。ATM を介した MLP は、低速 ATM リンクにレイヤ 2 フラグメント化およびインターリーブ方式を提供します。

ATM を介した MLP のフラグメント サイズが理想的なものであると、フラグメントは ATM セルの正確な倍数になります。すべてのフラグメント化計算に MLP および ATM アダプテーション レイヤ 5(AAL5)オーバーヘッドを含めることが重要です。ATM を介した MLP のヘッダーは 10 バイトで、AAL5 パケット オーバーヘッドは 8 バイトです。

ATM を介した MLP のフラグメント サイズは、次のように計算できます。

Fragment_Size = (48 * Number_of_Cells) - 10 - 8

たとえば、フラグメント当たり 7 つのセルが必要な場合、フラグメント サイズは、次のものでなければなりません。

Fragment_Size = (48 * Number_of_Cells) - 10 - 8

マルチリンク インターフェイスの代わりに仮想テンプレートを使用することを含め、ATM を介した MLP については、興味深いフィーチャがいくつかあります。(仮想テンプレート設定は、ATM を介した、以降の MLP のリリースではマルチリンク インターフェイスで置き換えられます。マルチリンク インターフェイスでは、スケーラビリティが向上し、既存の MLP インストレーションへの統合が容易になるためです。) さらに、リモート サイトが ATM を介した MLP を使用して通信する場合、PPP CHAP(Challenge Handshake Authentication Protocol)の設定が必要です。

ATM を介した MLP では、発信パケットが ATM 仮想回線に送信される前に MLP バンドルがそれらの発信パケットを分類する必要があります。FIFO キューイングが ATM VC の VC 単位のキューイング ストラテジとして使用されることも必要です。すべての VoIP WAN インストレーションに対して推奨される、拡張低遅延キューイング(LLQ)を使用するために、LLQ 論理を仮想テンプレート インターフェイスに付加します。

VC ごとのトラフィック シェーピングをサポートするのは、一定の拡張 ATM ハードウェアだけです(たとえば、Cisco 7200 ルータ上の ATM Deluxe PA と、Cisco 3600 シリーズ上の OC-3 NM)。トラフィック シェーピングはこの設計の基本要件であるため、ATM を介した MLP は、この ATM ハードウェアをサポートするプラットフォーム上でのみサポートされます。次の例では、このタイプの設定を示しています。

interface ATM2/0
no ip address
no ip mroute-cache
atm pvc 1 0 16 ilmi
no atm ilmi-keepalive
!
interface ATM2/0.37 point-to-point
pvc cisco37 0/37
tx-ring-limit 7
abr 256 256
protocol ppp Virtual-Template2
!
!
interface Virtual-Template2
bandwidth 254
ip address 10.1.37.52 255.255.255.0
service-policy output QoS-Policy-256k
ppp authentication chap
ppp chap hostname HQ_7200
ppp chap password 7 05080F1C2243
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
 

ATM 接続上の cRTP

圧縮 TMP(cRTP)は、現在のところ、ATM インターフェイス上ではサポートされていません。

MLP を介した VoIP のための LLQ

低遅延キューイング(LLQ)は、単一の PVC を使用する場合に ATM WAN を介した音声をサポートするのに必要です。ATM 対応インターフェイス用に LLQ を設定する場合、 subinterface PVC 構成セクションの下に service-policy output を置きます。次の例では、2 つのクラスが定義されます。1 つは VoIP メディア ストリーム用で、もう 1 つは制御トラフィック用です。これらのクラス、つまりそれらが処理するキューへのアクセスは、レイヤ 3 ToS 分類または発信元および宛先の IP アドレスとポートのどちらかに一致するアクセス リストを使用して行われます。アクセス リストは、セントラル サイトでは制御トラフィックの場合と少し違って見えます。Catalyst 6000 はすでに、26 という DSCP 値(IP Precedence 3 とバックワード コンパティビリティのある AF31)を使って VoIP 制御セッションを分類しているためです。

すべての VoIP メディア トラフィックは、優先度キュー(PQ)に入れられます。この優先度キューには、100 kbps の帯域幅が与えられています。Skinny プロトコル制御トラフィックはすべて、クラス ベース キューに入れられ、10 kbps の帯域幅が与えられます。その他のすべてのトラフィックは、均等化キューイングを使用してキューに入れられます。

次の例では、このタイプの設定を示します。

class-map VoIP-RTP
match access-group 100
class-map VoIP-Control
match access-group 101
!
policy-map QoS-Policy-256k
class VoIP-RTP
priority 100
class VoIP-Control
bandwidth 8
class class-default
fair-queue
!
interface ATM2/0
no ip address
no ip mroute-cache
atm pvc 1 0 16 ilmi
no atm ilmi-keepalive
!
interface ATM2/0.37 point-to-point
pvc cisco37 0/37
tx-ring-limit 7
abr 256 256
protocol ppp Virtual-Template2
!
!
interface Virtual-Template2
bandwidth 256
ip address 10.1.37.52 255.255.255.0
service-policy output QoS-Policy-256k
ppp authentication chap
ppp chap hostname HQ_7200
ppp chap password 7 05080F1C2243
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
!
!
!
! ToS VoIP Media Stream Classification: either IP Prec or DSCP
! This access-list is the same at the both the remote and
! central locations
access-list 100 permit ip any any precedence 5
access-list 100 permit ip any any dscp ef
!
! Skinny, H.323 and MGCP VoIP Control Traffic
! which has already been classified using the
! route-map in Chapter 4.
access-list 101 permit ip any any precedence 3
access-list 101 permit ip any any dscp 26
 

フレーム リレー ATM 間インターワーキング WAN

多くの企業が、リモート サイトでフレーム リレーを、また中央位置で ATM を使用する Cisco AVVID ネットワークを配置しています。変換は、キャリア ネットワーク内で ATM フレーム リレー間サービス インターワーキング(FRF.8)を通じて行われます。


) LFI 用に ATM およびフレーム リレーを介して MLP を使用する場合、サポートされるのは、透過モード FRF.8 だけです。


図 5-10 では、セントラル サイトで ATM およびリモート サイトでフレーム リレーを使用する WAN の一般的なモデルを示します。

図 5-10 ATM とフレーム リレーを結合する WAN の一般的なモデル

 

Cisco AVVID ネットワーク用のフレーム リレー ATM 間インターワーキング WAN を設計する場合、次の推奨事項に留意してください。

ATM を介した MLP およびフレーム リレーを介した MLP の Cisco IOS リリース 12.1(5)T は、この設定の最小推奨リリースです。

FRF.8 透過モードは、ATM およびフレーム リレー サービス インターワーキングを介した MLP の唯一のサポート方式です。

DS-3 速度未満のすべての ATM 接続について、TX リング バッファ サイズを調整する必要があります。

ATM およびフレーム リレー PVC 速度が 768 kbps 未満の場合は、2 つの相手先固定接続を使用します。

768 kbps 未満の PVC を 1 つ使用している場合は、LFI 用の ATM およびフレーム リレーを介して MLP を使用します。

VoIP ベアラ ストリーム用の優先度キューおよび VoIP 制御セッション用のクラス ベース キューと一緒に低遅延キューイング(LLQ)を使用します。

WAN を介したコールの数により割り当てられた VoIP 帯域幅が過剰加入になる可能性がある場合は、コール アドミッション制御が必要です。

これ以降の項で、このタイプの設定の QoS 問題について説明します。

低速 ATM フレーム リレー間インターワーキング WAN 上の LFI

現在、FRF.12 をサポートするサービス プロバイダがないため、FRF.12 は使用できません。実際、FRF.12 をサポートする Cisco WAN スイッチング ギアはありません。ATM 側に FRF.12 標準がないため、サービス プロバイダ ネットワークを通じた FRF.12 のトンネル伝送は動作しません。リモート フレーム リレー サイトのいずれかが 768 kbps 以下の回線を使用する場合、フラグメント化は必須であるため、このことが問題となります。768 kbps 未満で PVC を使用する場合、ATM ネットワーク用の最良の VoIP 設計は、音声とデータに別々の PVC を使用する設計です。

2 つの PVC が許容可能な設計の代わりにならない場合、もう 1 つのオプションとして、Cisco IOS Release 12.1(5)T で使用可能な LFI(Link Fragmentation and Interleaving)用に AMT およびフレーム リレー ツールを介して新しい MLP を使用することが挙げられます。ATM およびフレーム リレーを介した MLP は、低速 ATM フレーム リレー間 FRF.8 サービス インターワーキング リンクにエンドツーエンド レイヤ 2 フラグメント化およびインターリーブ方式を提供します。

FRF.8 サービス インターワーキングは、フレーム リレー ネットワークを ATM ネットワークと接続するためのフレーム リレー フォーラム(FRF)標準です。サービス インターワーキングは、サービス プロバイダ、企業、およびエンド ユーザに標準ベースのソリューションを提供します。サービス インターワーキング変換モードでは、フレーム リレー PVC は、対称トポロジを必要とせずに ATM PVC にマップされます。パスが ATM 側で終端できるためです。FRF.8 は、上位レイヤ ユーザ プロトコル カプセル化についてインターワーキング フレーム リレー(IWF)の動作の 2 つのモードをサポートします。この 2 つのモードは、次のように異なります。

変換モードは、ATM とフレーム リレー カプセル化間でマップします。ルーティング対象プロトコルまたはブリッジ プロトコルのインターワーキングもサポートします。

透過モードは、カプセル化をマップするのではなく、それらを未変更のまま送信します。このモードは、カプセル化方式がサービス インターワーキングについてサポートされている標準に適合しないために変換が実行不可能な場合に使用されます。


ATM およびフレーム リレー サービス インターワーキング ネットワーク上の LFI に対する MLP は、透過モードが使用される場合にのみサポートされます。


フレーム リレー インターワーキングを介した MLP および ATM インターワーキングを介した MLP を可能にするには、インターワーキング スイッチを透過モードで設定し、エンド ルータがフレーム リレーを介した MLP と AMT を介した MLP の両方についてヘッダーを認識できる必要があります。これらのオプションは、フレーム リレーおよび ATM に対してそれぞれ、 frame-relay interface-dlci <dlci> ppp コマンドと protocol ppp コマンドでイネーブルにすることができます。

ATM フレーム リレー間サービス インターワーキング接続のフレーム リレー側からフレームが送信される場合、インターワーキングを可能にするために、次のアクションが発生します。

1. 発信側ルータによって、フレーム リレーを介した MLP ヘッダー内でパケットがカプセル化されます。

2. キャリア スイッチは、透過モードで、2 バイトのフレーム リレー データ リンク接続識別子(DLCI)フィールドを取り除き、パケットの残りの部分をその ATM インターフェイスに送信します。

3. 受信側ルータは、受信したパケットのヘッダーを調べます。受信パケットの最初の 2 バイトが 0x03cf であると、ルータはそれを正当な ATM を介した MLP パケットとして扱い、MLP レイヤに送信して、さらに処理を行います。

ATM フレーム リレー間サービス インターワーキング接続の ATM 側から ATM セルが送信される場合、インターワーキングを可能にするために、次のアクションが発生します。

1. 発信側ルータによって、ATM を介した MLP ヘッダー内でパケットがカプセル化されます。

2. キャリア スイッチは、透過モードでは、受信パケットの先頭に 2 バイトのフレーム リレー DLCI フィールドを付加し、パケットをそのフレーム リレー インターフェイスに送信します。

3. 受信側ルータは、受信したパケットのヘッダーを調べます。受信パケットの 2 バイトのデータ リンク接続識別子(DLCI)フィールドの後の最初の 4 バイトが 0xfefe03cf, であると、ルータはそれを正当なフレーム リレーを介した MLP パケットとして扱い、MLP レイヤに送信して、さらに処理を行います。

新しい ATM フレーム リレー間サービス インターワーキング標準 FRF.8.1 は、ATM を介した MLP およびフレーム リレー サービス インターワーキングをサポートします。ただし、すべてのスイッチがこの新しい標準に更新されるまでには、まだ数年を要します。

ATM を介した MLP のフラグメント サイズが理想的なものであると、フラグメントは ATM セルの正確な倍数になります。すべてのフラグメント化計算に MLP およびアダプテーション レイヤ 5(AAL5)オーバーヘッドを含めることが重要です。ATM を介した MLP のヘッダーは 10 バイトで、AAL5 パケット オーバーヘッドは 8 バイトです。

ATM を介した MLP のフラグメント サイズは、次のように計算できます。

Fragment_Size = (48 * Number_of_Cells) - 10 - 8

たとえば、フラグメント当たり 7 つのセルが必要な場合、フラグメント サイズは、次のものでなければなりません。

Fragment_Size = (48 * 7) - 10 - 8 = 318 bytes

マルチリンク インターフェイスの代わりに仮想テンプレートを使用することを含め、ATM を介した MLP については、興味深いフィーチャがいくつかあります。(仮想テンプレート設定は、ATM を介した、以降の MLP のリリースではマルチリンク インターフェイスで置き換えられます。マルチリンク インターフェイスでは、スケーラビリティが向上し、既存の MLP インストレーションへの統合が容易になるためです。) さらに、リモート サイトが ATM を介した MLP を使用して通信する場合、PPP CHAP(Challenge Handshake Authentication Protocol)の設定が必要です。

ATM を介した MLP では、発信パケットが ATM 仮想回線に送信される前に MLP バンドルがそれらを分類する必要があります。FIFO キューイングが ATM VC の VC 単位のキューイング ストラテジとして使用されることも必要です。すべての VoIP WAN インストレーションついてに推奨される、拡張低遅延キューイング(LLQ)を使用するために、LLQ 論理を仮想テンプレート インターフェイスに付加します。

VC ごとのトラフィック シェーピングをサポートするのは、一定の拡張 ATM ハードウェアだけです(たとえば、Cisco 7200 ルータ上の ATM Deluxe PA と、Cisco 3600 シリーズ上の OC-3 NM)。トラフィック シェーピングはこの設計の基本要件であるため、ATM を介した MLP は、この ATM ハードウェアをサポートするプラットフォーム上でのみサポートされます。

フレーム リレーを介した MLP にも、フレーム リレー トラフィック シェーピング(FRTS)エンジンに依存して MLP バンドルからフレーム リレー仮想回線(VC)へのパケットのフローを制御するなど、興味深いフィーチャがいくつかあります。

これ以降の項では、セントラル サイトの ATM およびリモート サイトのフレーム リレーの設定例を示します。

セントラル サイトの ATM 設定

次の例では、セントラル サイトでの ATM 設定を示します。

interface ATM2/0
no ip address
no ip mroute-cache
atm pvc 1 0 16 ilmi
no atm ilmi-keepalive
!
interface ATM2/0.37 point-to-point
pvc cisco37 0/37
tx-ring-limit 7
abr 256 256
protocol ppp Virtual-Template2
!
!
interface Virtual-Template2
bandwidth 254
ip address 10.1.37.52 255.255.255.0
service-policy output QoS-Policy-256k
ppp authentication chap
ppp chap hostname HQ_7200
ppp chap password 7 05080F1C2243
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
 

リモート サイトのフレーム リレー設定

次の例では、リモート サイトでのフレーム リレー設定を示します。

interface Serial6/0
description T1 to Frame Relay switch
no ip address
encapsulation frame-relay
load-interval 30
no arp frame-relay
frame-relay traffic-shaping
!
interface Serial6/0.73 point-to-point
description 3640
no arp frame-relay
frame-relay interface-dlci 73 ppp Virtual-Template2
class VoIP-256kbs
!
interface Virtual-Template2
bandwidth 254
ip address 10.1.37.51 255.255.255.0
service-policy output QoS-Policy-256k
ppp authentication chap
ppp chap hostname R72HQ
ppp chap password 7 05080F1C2243
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
 

ATM フレーム リレー間接続上の cRTP

圧縮 TMP(cRTP)は、現在のところ、ATM インターフェイス上ではサポートされていません。

ATM およびフレーム リレーを介した音声のための LLQ

サービス インターワーキングを使用した場合のフレーム リレー リンクおよび ATM リンクの LLQ 設定は、ATM を介したエンドツーエンド MLP を使用した場合とまったく同じです。詳細は、「MLP を介した VoIP のための LLQ」を参照してください。

要約

この章で説明しているとおり、Cisco AVVID ソリューションで使用するために WAN を設定する際には、次の一般的なガイドラインおよび推奨事項が適用されます。

768 kbps 未満の速度のすべての WAN 接続で LFI(Link Fragmentation and Interleaving)技法を使用します。

すべての WAN VoIP 接続上で低遅延キューイング(LLQ)を使用します。

トラフィック シェーピングは、すべてのフレーム リレー配置および ATM 配置に必要です。

可能な場合は、圧縮 RTP(cRTP)を使用します。

768 kbps 未満の速度で動作する ATM WAN は、ATM を介した MLP を使用してフレーム サイズを減らす必要があります。ATM を介した MLP は、Cisco IOS リリース 12.1(5)T でサポートされます。

フレーム リレー ATM 間インターワーキング環境では、低速接続上でフレーム サイズを小さくするために、ATM およびフレーム リレーを介した MLP が必要です。ATM およびフレーム リレーを介した MLP は、Cisco IOS リリース 12.1(5)T でサポートされます。

WAN を介したコールの数によりプロビジョニングされた VoIP 帯域幅が過剰加入になる可能性がある場合は、コール アドミッション制御が必要です。