Cisco IP テレフォニー QoS デザイン ガイド

分類

分類とは、特定のトラフィック タイプが分類されること、つまり、固有の処理要件をもつものとしてマーキングされる方式です。これらの処理要件には、必要最少限の量の帯域幅であることや、遅延に対して許容度を低くすることなどがあります。この分類は、タグによってネットワーク要素に通知されます。このタグは、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 のエンドツーエンド遅延バジェットを超えることがあります。さらに、相対的に小さなフレームは、受信側の適応できるジッタ バッファのサイズよりも大きな値までジッタを単純に増やすことによって、全体的な音声品質に悪影響を及ぼす可能性があります。

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 では、各種リンク速度の推奨フラグメント サイズを示します。

（注） 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 以上に設定することは可能ですが、そのように設定すると、たいていの場合、音声品質は非常に悪くなります。

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

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

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

音声、データ、および可能なビデオ アプリケーションをサポートするのに必要な帯域幅を使ってネットワークをプロビジョニングするための計算を行った後、音声に割り当てられている帯域幅の部分が音声により過剰加入にならないようすることが重要です。多くの 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 ルータにまず達する場合があります。これらの制御接続が「重要」（音声として重要ではなく）として分類されるには、リモートのブランチ ルータでアクセス リストが使用されるようにします。次に設定例を示します。

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 リング バッファのサイジングは、ビット単位ではなく、パケット単位で測定されます。

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

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

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

圧縮音声コーデック

限定された 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 の最小推奨システム ソフトウェアです。

VAD

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

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

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

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

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

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

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 にはプロセス切り替えを使用しています。固有の機能をお使いになる前に、必ず、リリース情報をお読みください。

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

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 の帯域幅が与えられます。その他のすべてのトラフィックは、均等化キューイングを使用してキューに入れられます。

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

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

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

フレーム リレー ネットワークについては、次の 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 フレーム リレー回線に接続されているリモート サイト ルータのための設定を示します。

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

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

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

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

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

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

フレーム リレーを介した 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 の帯域幅が与えられます。その他のすべてのトラフィックは、均等化キューイングを使用してキューに入れられます。

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

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

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

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 上の 2 つの PVC または LFI

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

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 ハードウェアをサポートするプラットフォーム上でのみサポートされます。次の例では、このタイプの設定を示しています。

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 の帯域幅が与えられます。その他のすべてのトラフィックは、均等化キューイングを使用してキューに入れられます。

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

低速 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 設定を示します。

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

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

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

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

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

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