Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン Cisco CallManager Release 4.0 および 4.1
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月18日
章のタイトル： コール アドミッション制御
コール アドミッション制御
コール アドミッション制御機能は、IP WAN 経由で接続された複数のサイトで構成されるすべての Cisco IP Communications システムに不可欠なコンポーネントです。コール アドミッション制御の機能と必要性をわかりやすく説明するために、図9-1 の例について考えます。
図9-1 の左側で示すように、従来の TDM ベースの PBX は、回線交換ネットワークの一部として動作します。このネットワークでは、回線はコールがセットアップされるたびに確立されます。このため、レガシー PBX が公衆網または他の PBX に接続されている場合は、一定数の物理トランクを設定する必要があります。公衆網または他の PBX 宛てのコールをセットアップする必要があるとき、PBX は、使用可能なトランクの中からトランクを選択します。使用可能なトランクがない場合、コールは PBX によって拒否され、発信者にはネットワーク ビジー信号が聞こえます。
次に、図9-1 の右側に示している Cisco IP Communications システムについて考えます。このシステムは、パケット交換ネットワーク（IP ネットワーク）を基盤としているため、IP Communications コールをセットアップするために回線を確立する必要はありません。サンプリング音声を含んでいる IP パケットが、他のタイプのデータ パケットとともに、IP ネットワーク経由でルーティングされるだけです。音声パケットは、QoS（Quality Of Service）を使用してデータ パケットと区別されますが、帯域幅リソースは、特に IP WAN リンクでは無限ではありません。このため、ネットワークの管理者が、一定量の「優先」帯域幅を各 IP WAN リンク上の音声トラフィック専用として割り当ててください。ただし、設定した帯域幅がすべて使用される状態になった場合は、Cisco IP Communications システムで以後のコールを拒否して、IP WAN リンク上のプライオリティ キューのオーバーサブスクリプションを防止する必要があります。オーバーサブスクリプションが発生すると、すべての音声コールで品質が低下します。この機能はコール アドミッション制御と呼ばれ、マルチサイト配置で良好な音声品質を保証するために不可欠なものです。
この章では、コール アドミッション制御の主な側面について、次の項目を説明します。
ここでは、Cisco IP Communications システムのさまざまなコンポーネント、たとえば Cisco CallManager ロケーション、Cisco IOS ゲートキーパー、RSVP、IP-to-IP ゲートウェイなどで使用できる、各種のコール アドミッション制御メカニズムについて説明します。
ここでは、上の項で説明したメカニズムを適用し、組み合せる方法について、IP WAN のトポロジ（単純なハブアンドスポーク、2 層ハブアンドスポーク、MPLS、複合トポロジ）に基づいて、および採用する Cisco CallManager 配置モデル（集中型、分散型、集中型および分散型複合）に基づいて示します。
コール アドミッション制御の要素
この項では、Cisco IP Communications システムに含まれている次のコール アドミッション制御要素について、設計と設定のガイドラインを示します。
•
「RSVP」
Cisco CallManager ロケーション
Cisco CallManager では、集中型コール処理配置において、コール アドミッション制御を実装するために、「ロケーション（location）」と呼ばれている単純なメカニズムを取り入れています。Cisco CallManager でデバイスを設定するときは、デバイスをロケーションに割り当てて、各ロケーションが宛先または発信元となるコールに一定量の帯域幅を割り当てます（図9-2 を参照）。Cisco CallManager で設定するロケーションは、仮想ロケーションであり、実際の物理ロケーションではありません。Cisco CallManager は、デバイスの物理的なロケーションを認識しません。このため、デバイスをある物理ロケーションから別のロケーションに移動する場合は、システム管理者がロケーション情報を手動でアップデートして、Cisco CallManager がそのデバイスの帯域幅割り当てを正しく計算できるようにする必要があります。各デバイスは、デフォルトでは <None> ロケーションに配置されます。ロケーション <None> は、無限の音声帯域幅とビデオ帯域幅を持った、特殊な名称未設定ロケーションです。支店サイトにあるデバイスが <None> ロケーションに設定されている場合、その支店デバイスが宛先または発信元となっている電話コールは、すべてコール アドミッション制御メカニズムによって受け付けられます。
Cisco CallManager は、ロケーションで使用可能になっている音声帯域幅とビデオ帯域幅を使用して、そのロケーションが宛先または発信元となる音声コールとビデオ コールの数を制御します。ロケーションの音声帯域幅とビデオ帯域幅が Unlimited に設定されている場合、そのロケーションでは帯域幅を無限に使用できるため、そのロケーションが宛先または発信元となる音声コールとビデオ コールは、Cisco CallManager ではすべて許可されます。帯域幅の値が特定のキロビット/秒（Kbps）に設定されている場合は、アクティブになっているすべてのコールで使用されている合計帯域幅が、その設定値以下になっている場合に限り、Cisco CallManager は、そのロケーションで入出力されるコールを許可します。ロケーションのビデオ帯域幅を None に設定して、このロケーションが宛先または発信元となるビデオ コールをすべて拒否することもできます。ただし、このロケーションの内部でやり取りされるビデオ コールには影響しません。
ビデオ コールの場合、ビデオ ロケーションの帯域幅については、コールのビデオ部分と音声部分の両方を考慮に入れる必要があります。つまり、ビデオ コールの場合、帯域幅が音声帯域幅プールから差し引かれることは一切ありません。
ロケーション ベースのコール アドミッション制御メカニズムでは、通話中のコール タイプ変更も考慮に入れる必要があります。たとえば、サイト間でビデオ コールを確立する場合、Cisco CallManager は、それぞれのロケーションから適切な量のビデオ帯域幅を差し引きます。このビデオ コールが、ビデオ非対応のデバイスに転送する過程で音声コールに変更された場合、Cisco CallManager は割り当てた帯域幅をビデオ プールに戻し、適切な量の帯域幅を音声プールから割り当てます。音声からビデオに変更されるコールについては、これとは逆の帯域幅割り当て変更が発生します。
（注） Cisco CallManager Release 3.1 より前は、ロケーションに基づくコール アドミッション制御を使用する場合、クラスタ内には 1 つのプライマリ（アクティブ）CiscoCallManager サーバしかありませんでした。Cisco CallManager Release 3.1 以降では、ロケーションの帯域幅は、クラスタ内のすべての Cisco CallManager サブスクライバ間で共有されるので、任意のサイズのクラスタでロケーション メカニズムを使用できるようになりました。
図9-2 Cisco CallManager におけるロケーションの定義
図9-2 では、使用可能な音声帯域幅 256 Kbps およびビデオ帯域幅 384 Kbps を指定した、ロケーション Branch_1 の設定を示しています。このロケーションは、最高 3 つの G.711 音声コール（コールごとに 80 Kbps）、または 10 個の G.729 音声コール（コールごとに 24 Kbps）、または両方のコールの組み合せ（256 Kbps を超えないこと）をサポートできます。このロケーションでは、使用されているビデオ コーデックおよび音声コーデックに応じて、さまざまな数のビデオ コールをサポートすることもきます。たとえば、G.711 音声コーデックと H.261 または H.263 ビデオ コーデックを使用する 1 つのビデオ コールで 320 Kbps のレートが必要な場合は、帯域幅を 384 Kbps 消費します。G.729 音声コーデックと H.261 または H.263 ビデオ コーデックを使用する 3 つのコールで 120 Kbps のレートが必要な場合も、同じ帯域幅を消費します。
（注） Cisco CallManager Release 4.0 以降では、Cisco IP Phone で暗号化電話コールを発信できます。暗号化コールのペイロードは、暗号化されていないコールのペイロードよりもわずかに大きくなります。このため、ネットワーク経由での暗号化コールの送信を計画している場合は、この追加の帯域幅に対応するように IP WAN ルータの帯域幅設定を調整する必要があります。IP WAN ルータのキューを設定するときに考慮するその他の要素は、レイヤ 2 ヘッダーによって発生するオーバーヘッドです。暗号化コールの帯域幅の計算、およびさまざまなレイヤ 2 テクノロジーの詳細については、「帯域幅のプロビジョニング」を参照してください。
CTI ルート ポイントに対して設定されているロケーションが Cisco CallManager で考慮されるのは、そのルート ポイントにメディアを処理するアプリケーションが登録されている場合のみです。CTI ルート ポイントがコールのルーティングにのみ使用されていて、メディアの終端とならない場合、設定されているロケーションは、Cisco CallManager では無視されます。
（注） トランスコーダと MTP は、ロケーションに割り当てることはできません。したがって、これらは通常は中央サイトに配置します。ただし、Cisco CallManager Release 3.2(3)、3.3(3)、4.0(1) 以降では、G.711 専用デバイスとともに配置される場合に限り、トランスコーダをリモート サイトに配置することもできます。基本的には、Cisco CallManager はトランスコーダに関係するコールは常に G.729 コールであると見なし、24 Kbps の帯域幅を関連ロケーションから差し引きます。
コール アドミッション制御は、同じロケーション内にあるデバイス間でのコールには適用されません。Cisco CallManager は、これらのデバイスが同一 LAN 上にあり、使用可能な帯域幅が無限にあると見なすためです。
あるロケーションから別のロケーションにコールが発信されると、Cisco CallManager は、両方のロケーションで適切な量の帯域幅を差し引きます。たとえば、Branch_1 内のデバイスが、Branch_2 内のデバイスに G.711 コールを発信する場合、Cisco CallManager は、両方のロケーションの使用可能な帯域幅から 80 Kbps を差し引きます。コールが完了すると、Cisco CallManager は、帯域幅を差し引かれたロケーションに帯域幅を戻します。Branch_1 ロケーションまたは Branch_2 ロケーションのいずれかで十分な帯域幅がない場合、コールは Cisco CallManager によって拒否され、発信者にはネットワーク ビジー トーンが聞こえます。発信側デバイスが、ディスプレイを備えた IP Phone である場合、そのデバイスには、「Not Enough Bandwidth」というメッセージも表示されます。
Cisco CallManager Release 3.3 以降では、発信者または着信側のどちらかで帯域幅が不足しているためにクラスタ内コールが拒否された場合、Cisco CallManager は Automated Alternate Routing（AAR）機能を使用して、コールを公衆網を通じて自動的に宛先に再ルーティングできます。Cisco CallManager は、着信番号および着信側の外線電話番号マスクを使用して、完全な E.164 宛先番号を取得します。発信者の回線に設定されている AAR グループによって、E.164 番号の前に付けられるアクセス コードが決定し、発信デバイスの AAR コーリング サーチ スペースによって、ローカル出口公衆網ゲートウェイを選択する方法が決定します。
（注） AAR が呼び出されるのは、帯域幅が不足しているために、ロケーション ベースのコール アドミッション制御によってコールが拒否される場合のみです。IP WAN が使用不可の場合や、接続に関するその他の問題によって着信側デバイスが Cisco CallManager に登録されない状態になった場合には、AAR は呼び出されません。このような場合、コールは着信側デバイスの Call Forward Busy フィールドで指定されている宛先に転送されます。AAR の詳細については、「IP テレフォニー配置モデル」および 「Automated Alternate Routing」を参照してください。
Cisco CallManager クラスタ内で、あるロケーションが宛先または発信元となって外部コールが発生すると、Cisco CallManager はロケーション ベースのコール アドミッション制御計算も実行します。コールをサポートするための帯域幅が十分にある場合、Cisco CallManager はコールを許可して、ロケーションにある適切な量の帯域幅を割り当てます。ロケーションに十分な帯域幅がない場合、コールは Cisco CallManager によって拒否されます。
図9-3 では、ロケーション Branch_1 に割り当てられた IP Phone の設定を示しています。Cisco CallManager は、コールをサポートする十分な帯域幅が Branch_1 にある場合、この IP Phone に出入りする各コールを受け入れます。IP Phone が発信コールを実行したときに Branch_1 に十分な帯域幅がない場合、Cisco CallManager は、AAR を通じてコールを再ルーティングし、Branch_1 の公衆網ゲートウェイに発信します。
表9-1 に、さまざまなコール速度において Cisco CallManager ロケーション アルゴリズムが要求する帯域幅の量を示します。
|
|
|
|---|---|
ゲートキーパー
Cisco IOS ゲートキーパーは、Cisco CallManager、Cisco CallManager Express、レガシー PBX に接続されている H.323 ゲートウェイなどのデバイス間で、コール ルーティングとコール アドミッション制御を提供できます。H.323 Registration Admission Status （RAS）プロトコルを使用してこれらのデバイスと通信し、コールをネットワークにルーティングします。
ゲートキーパーのコール アドミッション制御は、ポリシーベースの方式であり、使用可能なリソースの静的設定を必要とします。ゲートキーパーは、ネットワーク トポロジを認識しないので、単純なハブアンドスポーク トポロジに制限されます。複数のゲートキーパーを配置している場合は、2 層ハブアンドスポーク トポロジをサポートできることもあります。トポロジの詳細な例については、「コール アドミッション制御の設計」の項を参照してください。
Cisco 2600、3600、3700、2800、3800、および 7200 シリーズのルータはすべて、ゲートキーパー機能をサポートします。冗長性、ロード バランシング、および階層コール ルーティング用に、さまざまな方法で Cisco IOS ゲートキーパーを設定できます。ここでは、ゲートキーパー機能のコール アドミッション制御の面を中心に説明します。冗長性とスケーラビリティに関する考慮事項については、「コール処理」の章の「ゲートキーパー」の項を参照してください。コール ルーティングに関する考慮事項については、「ゲートキーパーを使用する Cisco IOS でのコール ルーティング」を参照してください。
Cisco IOS ゲートキーパーのコール アドミッション制御機能について理解するには、ゲートキーパーの「ゾーン」の概念を再確認すると役立ちます。ゾーンは、エンドポイント、ゲートウェイ、マルチポイント コントロール ユニット（MCU）などの、ゲートキーパーに登録される H.323 デバイスの集合です。アクティブになることができるゲートキーパーは、ゾーンごとに 1 つのみです。1 つのゲートキーパーには、ローカル ゾーンを 100 個まで定義できます。
ローカル ゾーンは、当該のゲートキーパーがアクティブに処理しているゾーンです。つまり、このゾーンに割り当てられている H.323 デバイスは、すべて当該ゲートキーパーに登録されます。
複数のゲートキーパーを同一ネットワークに配置している場合、ゾーンがローカル ゾーンとして設定されるのは、1 つのゲートキーパー上のみです。他のゲートキーパーでは、このゾーンはリモート ゾーンとして設定されます。この設定によって、あるゾーンが宛先になっているコールを、そのゾーンを「所有」しているゲートキーパー（つまり、そのゾーンがローカル ゾーンとして設定されているゲートキーパー）に転送するようにゲートキーパーに指示しています。
ゲートキーパーで許可されるコールの数を管理する、つまりコール アドミッション制御機能を利用するには、 bandwidth コマンドを使用します。このコマンドにはいくつかのオプションがありますが、この機能と密接に関連するのは次のオプションです。
• interzone オプションによって、特定のローカル ゾーンで送受信されるすべてのコールの帯域幅の量を制御します。
• session オプションによって、特定のローカル ゾーンのコール 1 件あたりの帯域幅の量を制御します。
• remote オプションによって、すべてのリモート ゾーンで送受信される帯域幅の総量を制御します。
たとえば、ネットワーク上に、DS-3 WAN リンクを通じて本社に接続されている 2 つの Cisco CallManager クラスタがあるとします。また、リンクごとに 20 の G.711 音声コールと 5 つの 384 Kbps ビデオ コールを許可し、どのビデオ コールの帯域幅も 384 Kbps に制限するとします。この場合は、 bandwidth interzone コマンドを使用して、各ゾーンの帯域幅を 20 の G.711 コールと 5 つの 384 Kbps ビデオ コールの合計値に制限し、 bandwidth session コマンドを使用して、各コールの最大帯域幅を 384 Kbps に制限します。次に例を示します。
ゲートキーパーの使用する帯域幅の値は、レイヤ 2、IP、および RTP のオーバーヘッドを除いた、コールのビットレートの倍です。たとえば、64 Kbps を使用する G.711 音声コールは、ゲートキーパーでは 128 Kbps と認識され、384 Kbps のビデオ コールは 768 Kbps と認識されます。 表9-2 に、一般に利用されているいくつかのコール速度において、ゲートキーパーが使用する帯域幅の値を示します。
|
|
|
|---|---|
RSVP
リソース予約プロトコル（RSVP）は、異種ネットワークにわたってエンドツーエンドの QoS を動的にセットアップするための、実質上最初の業界標準プロトコルです。RSVP は、IP を基盤として機能し、アプリケーションがネットワーク帯域幅を動的に予約することを可能にします。RSVP を使用すると、ネットワークを流れるデータ フローに関して、アプリケーションが一定レベルの QoS を要求できます。分散型ネットワークに対応し、動的に機能する性質を持っているため、RSVP はあらゆるネットワーク トポロジにわたって帯域幅を予約できます。つまり、本格的なトポロジ対応コール アドミッション制御メカニズムを提供します。
Cisco IOS ルータのほとんどは RSVP をサポートしており、「IP-to-IP ゲートウェイ」の項で説明する Cisco マルチサービス IP-to-IP ゲートウェイ機能を使用すると、Cisco IP Communications ネットワークに RSVP を導入することができます。
RSVP のプロトコルについて詳細に説明することは、このマニュアルの対象範囲外です。詳細については、インターネット技術特別調査委員会（IETF）が発行する関連 Request For Comments（RFC）ドキュメントを参照してください。このドキュメントは、次の Web サイトにあります。
ここでは、RSVP の全般的な動作原理、Cisco IOS におけるさまざまな RSVP 運用モデル、企業ネットワークにおいて音声とビデオのアプリケーションに RSVP を使用する場合の設計上のベスト プラクティスを中心に説明します。
RSVP の原理
RSVP がネットワークでコール アドミッション制御と帯域幅予約を実行する方法について、基本的な原理を理解するために、図9-4 に示す簡単な例について考えます。この例では、メッセージ交換とプロトコルの動作自体については説明しません。機能によってもたらされる結果を中心に説明します。
図9-4 に示すネットワークの各ルータ インターフェイスで、RSVP が有効になっているとします。円で囲まれた数値は、各インターフェイス上に残っている使用可能な RSVP 帯域幅の量を表しています。
図9-4 RSVP の原理を示すためのサンプル ネットワーク
ここで、RSVP 対応のアプリケーションが、2 つのデバイス間でのデータ ストリーム用に一定量の帯域幅を予約するとします。このシナリオを図9-5 に示します。この図では、デバイス 1 からデバイス 2 への個々のデータ ストリームで、24 Kbps の帯域幅を要求することを示しています。
ここでは、図9-5 について説明します。
• RSVP は、自身ではルーティングを実行しません。代わりに、下層で機能しているルーティング プロトコルを使用して、予約要求の宛先を決定します。トポロジの変更に対応するためにルーティングのパスが変化すると、RSVP は、自身の予約を予約が存在する新しいパスに合せて調整します。
• RSVP プロトコルは、デバイス 1 からデバイス 2 へのパスにあるすべての RSVP 対応ルータ上で、使用可能な帯域幅リソースを確認することによって、エンドツーエンドの予約を確立しようとします。図9-5 に示すように、RSVP メッセージがネットワークを進んでいくとき、関係するルータ インターフェイスでは、使用可能な RSVP 帯域幅が 24 Kbps ずつ減分されます。
• 使用可能な帯域幅がすべてのインターフェイスで十分にあり、この新しいデータ ストリームを受け付けることができる場合は、予約が成功し、アプリケーションに通知されます。
• RSVP 予約は単方向です。この例では、予約はデバイス 1 からデバイス 2 に向かって確立され、逆方向については確立されません。音声会議やビデオ会議などの双方向アプリケーションがある場合は、各方向について 1 つずつ、2 つの予約を確立する必要があります。
• RSVP は、RSVP をサポートしないルータ ノードでは透過的に動作します。RSVP に対応しないルータがパスに存在していても、それらのルータは単に RSVP メッセージを無視するだけであり、予約を確立することは可能です。ただし、エンドツーエンドでの QoS を確保するには、この RSVP 非対応のルータが制御するリンク上で、帯域幅の輻輳が発生しないようにする必要があります。
デバイス 1 とデバイス 2 の間で予約が正常に確立された後に、別のアプリケーションがデバイス 3 とデバイス 4 の間で 24 Kbps を要求したとします（図9-6 を参照）。
ここでは、図9-6 について説明します。
• RSVP プロトコルは、デバイス 3 からデバイス 4 へのパスにあるすべての RSVP 対応ルータ上で、使用可能な帯域幅リソースを確認することによって、エンドツーエンドの予約を確立しようとします。図9-6 に示すように、RSVP メッセージがネットワークを進んでいくとき、関係するルータ インターフェイスでは、使用可能な RSVP 帯域幅が 24 Kbps ずつ減分されます。
• この例では、ルータ R5 と R6 の間にあるリンク上に、この新しいデータ ストリームを受け付けるための使用可能な帯域幅が十分にありません。このため、予約は失敗し、アプリケーションに通知されます。パスに含まれている各インターフェイス上の使用可能な RSVP 帯域幅は、以前の値に戻されます。
• 次にどのように処理するかは、アプリケーションが決定します。データの転送を放棄することも、何らかの方法で QoS 保証のないベストエフォート型トラフィックとして送信することもできます。
RSVP 運用モデル
各 Cisco IOS ルータ インターフェイス上で、次の Cisco IOS コマンドをインターフェイス設定モードで発行すると、RSVP を有効にし、RSVP で制御できる帯域幅の最大量を定義することができます。
interface-kbps パラメータには、RSVP が所定のインターフェイス上で予約できる帯域幅の上限を指定します。 single-flow-kbps パラメータには、予約 1 つあたりの帯域幅の上限を指定します（要求している帯域幅がこれより大きいフローは、インターフェイス上に使用可能な帯域幅がある場合でも拒否されます）。
Cisco IOS では、2 つの異なるモデルに従って運用するように RSVP を設定できます。RFC 2210 で記述されている統合サービス（IntServ）モデル、および RFC 2998 で記述されている統合サービス/ディファレンシエーテッド サービス（IntServ/DiffServ）モデルです。どちらの RFC ドキュメントも、次の IETF Web サイトで入手できます。
図9-7 に、Cisco IOS ルータから見た、これらの 2 つのアプローチの相違点を示します。
図9-7 2 つの RSVP 運用モデル：IntServ と IntServ/DiffServ
IntServ モデル
図9-7 の左側に示すように、IntServ モデルの RSVP には、コントロール プレーンとデータ プレーンの両方が関係します。コントロール プレーンでは、RSVP が予約要求を許可または拒否します。データ プレーンでは、データ パケットを分類し、RSVP メッセージに含まれているトラフィック記述に基づいてポリシングし、適切なキューに入れます。RSVP が実行する分類は、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、およびプロトコル番号を構成している、5 つのタプルに基づいています。
このモデルでは、ルータを通過するすべてのデータ パケットを RSVP で代行受信して、RSVP でこの 5 タプルを検査し、確立済みの予約と一致するかどうかを検索できるようにする必要があります。一致が見つかった場合は、その予約のトラフィック仕様に従って、パケットが RSVP によってスケジューリングされ、ポリシングされます。
Cisco IOS ルータで IntServ 運用モデルを使用するには、インターフェイス設定モードで次のコマンドを使用します。
これらのコマンドがアクティブになっている場合、RSVP は、新しい予約を許可または拒否するとき、 ip rsvp bandwidth コマンドで定義した帯域幅上限に加えて、使用可能な実際の帯域幅リソースも基準にします。たとえば、bandwidth ステートメントを持つ LLQ クラスが存在する場合は、RSVP 予約に割り当てることのできる帯域幅プールから、それらの量が減分されます。LLQ クラスは、設定すると帯域幅を静的に割り当てます。これに対して、RSVP は、予約要求を受信するまでは帯域幅を一切割り当てません。このため、LLQ クラスに割り当てられることがない使用可能インターフェイス帯域幅を適度に確保して、予約要求を受信したときに RSVP が使用できるようにしておくことが重要です。
このモデルでは、各種キューへのパケットの割り当てを RSVP が制御します。このため、次の Cisco IOS コマンドをインターフェイス設定モードで使用すると、フローをプライオリティ キュー（PQ）に配置するかどうかを RSVP に通知するメカニズムを定義できます。
RSVP は、パラメータ r 、 b 、および p-to-r を使用して、シグナリングの対象になっているフローが PQ 処理を必要とする音声フローかどうかを判定します。これらのパラメータは、次の値を表しています。
• p-to-r = ピーク レートと平均レートの比率（単位：%）
特定のフローに関して RSVP メッセージで指定されているトラフィック特性が、このコマンドのパラメータ以下である場合、RSVP はフローを PQ に入れます。このコマンドにパラメータを指定しない場合は、一般に利用されている音声コーデック（G.711）の最大値である、次の値がデフォルトとして使用されます。
IntServ/DiffServ モデル
図9-7 の右側に示すように、IntServ/DiffServ モデルの RSVP では、アドミッション制御を実行するコントロール プレーンのみが関係し、データ プレーンは関係しません。つまり、コール アドミッション制御機能は、スケジューリング機能およびポリシング機能とは独立しています。スケジューリングとポリシングは、事前定義済みのクラス マップ、ポリシー マップ、およびサービス ポリシーに従って、低遅延キュー（LLQ）アルゴリズムによって実行できます。
このため、IntServ/DiffServ モデルでは、すでに QoS にディファレンシエーテッド サービス アプローチを使用しているネットワークに対して、RSVP コール アドミッション制御を追加することができます。RSVP は、事前に設定された帯域幅量に基づいてコールを許可または拒否しますが、実際のスケジューリングは、各パケットの DSCP 値など、既存の LLQ 基準に基づいています。
Cisco IOS ルータで IntServ/DiffServ 運用モデルを使用するには、インターフェイス設定モードで次のコマンドを使用します。
これらのコマンドがアクティブになっている場合、RSVP は、 ip rsvp bandwidth コマンドで定義された帯域幅上限のみに基づいて新しい予約を許可または拒否します。インターフェイス上で使用可能な実際の帯域幅リソースは考慮されません。許可された RSVP フローは、RSVP 以外の他のすべてのトラフィックと同じスケジューリング規則（たとえば、LLQ クラスとポリシー マップ）に従います。このため、RSVP 対応トラフィックを適切な DSCP 値を使用してマーキングし、対応する PQ または CBWFQ キューの帯域幅は、RSVP 対応トラフィックと他のすべてのトラフィックの両方に対応できるように設定することが重要です。
この運用モデルでは、RSVP はスケジューリング機能を制御しないため、 ip rsvp pq-profile コマンドは非アクティブです。
設計上のベスト プラクティス
Cisco IP Communications ネットワークでは、すべてのデバイスが適切な DSCP 値を使用して自身のベアラ トラフィックとシグナリング トラフィックをマーキングし、QoS アプローチは、現時点では ディファレンシエーテッド サービス モデルに基づいています。このため、RSVP を IP WAN に追加するときは、IntServ モデルと IntServ/DiffServ モデルという 2 つの設計方式を選択できます。
次のいずれかの条件に該当する場合は、IntServ/DiffServ モデルを採用することをお勧めします。
• IP WAN インターフェイスのプライオリティ キューに入るトラフィックは、RSVP 対応トラフィックのみである。
• プライオリティ キューに入る RSVP 未使用トラフィックは、アウトバンドのコール アドミッション制御メカニズム（Cisco CallManager ロケーションや Cisco IOS ゲートキーパーなど）によって、すべて確定的に一定量に制限される。
このような条件下では、ルータを設定するときに、LLQ の priority コマンドで指定した帯域幅値を超えないようにし、プライオリティ キューがオーバーサブスクリプションにならないようにする必要があります。
すべての PQ トラフィックが RSVP 対応の場合は、単に ip rsvp bandwidth コマンドと priority コマンドに同じ値を指定するだけで済みます。一部の PQ トラフィックが RSVP 非対応の場合は、 ip rsvp bandwidth コマンドとアウトバンド コール アドミッション制御メカニズムで指定した値の合計が、 priority コマンドで指定した帯域幅値を超えないようにする必要があります。
一方、この他のタイプのトラフィックは、自身の DSCP 値に基づいて引き続きクラスベース WFQ（CBWFQ）にアクセスできます。このアプローチでは、RSVP によって発生する処理オーバーヘッドが最も小さくなります。RSVP シグナリング メッセージを分析するだけで済み、データ パケットのスケジューリングが関係しないためです。ただし、PQ を宛先とする RSVP 未使用トラフィックが、事前設定済みの帯域幅値を超えないようにすることが重要です。トラフィックが過剰になると、不正なアプリケーションと RSVP 対応アプリケーションの両方に影響があります。
IP WAN インターフェイスのプライオリティ キューで、RSVP トラフィックと RSVP 未使用トラフィックの両方に対応する必要がある場合、RSVP 未使用トラフィックの最大量を見極めることが難しい場合は、IntServ モデルを採用することをお勧めします。
この場合、RSVP 未使用トラフィックは、 priority キーワードによって、LLQ クラスを通じて一定量の PQ 帯域幅を与えられます。また、インターフェイス上で十分な帯域幅を未割り当てのまま残して、RSVP がその帯域幅をフローに使用できるようにしておく必要があります。さらに、 ip rsvp pq-profile コマンドも使用して、どの RSVP フローを PQ に割り当てるかを定義する必要があります。このアプローチでは、すべてのデータ パケットを個々に分析する必要があるため、IP WAN ルータ上で RSVP によって発生する処理オーバーヘッドが大きくなります。ただし、RSVP 未使用 PQ トラフィックが不正な状態になって、LLQ に設定されている帯域幅値を超えた場合に、LLQ プライオリティ クラスに対して実行されるポリシングの影響を RSVP トラフィックが受けないという利点があります。
どのアプローチを選択したかにかかわらず、次のコマンドを使用して、シスコのベースライン QoS 推奨事項に従って RSVP シグナリング パケットをマーキングすること、およびこれらのパケットが他のタイプのシグナリング トラフィックと同様に扱われるようにすることが必要です。
各種のトラフィックに対する推奨 DSCP 値の詳細については、「ネットワーク インフラストラクチャ」を参照してください。
IP-to-IP ゲートウェイ
シスコのマルチサービス IP-to-IP ゲートウェイ（IP-IP ゲートウェイまたは IPIPGW とも呼ばれます）を使用すると、Cisco CallManager クラスタ間、H.323 ゲートウェイ間、またはこれらの 2 者間の IP WAN 接続に関して、ハブアンドスポーク トポロジにおける制約を緩和できます。
Cisco IOS 機能が、IP ネットワーク間で H.323 Voice over IP（VoIP）コールおよびビデオ会議コールを使用するためのメカニズムを提供します。IP-IP ゲートウェイの主な目的は、管理ドメインを通過する VoIP コールとビデオ コールにコントロール ポイントと境界を提供することです。このゲートウェイは、PSTN-to-IP ゲートウェイとほぼ同じ機能を実行しますが、公衆網レッグと IP コール レッグの代わりに、通常は 2 つの IP コール レッグに加入します。
企業の IP Communications 環境において、IP-IP ゲートウェイが備える最も興味深い機能は、このゲートウェイを通過する各コールのための RSVP 予約を生成できることです。「RSVP」の項で説明しているように、RSVP は、トポロジ対応型のコール アドミッション制御メカニズムを提供するためのネットワーク ベース シグナリング プロトコルです。トポロジがハブアンドスポークである必要はなく、任意のネットワーク トポロジで機能します。
結果として、コール フローに 2 つの IP-IP ゲートウェイを挿入し、両者間で RSVP を有効にすることで、任意の IP WAN トポロジ上でコール アドミッション制御を実行できます。図9-8 に、2 つのサイト A と B による基本的な例を示します。それぞれ Cisco CallManager クラスタがあり、任意のトポロジを持つ IP WAN を通じて接続されています。各サイトには IP-IP ゲートウェイも配置されており、2 つの Cisco CallManager クラスタは、すべてのサイト間コールを、ローカル IP-IP ゲートウェイを指しているトランクを通じてルーティングするように設定されています。サイト A とサイト B の間でコールがセットアップされると、次のイベントが発生します。
• サイト A の Cisco CallManager が、サイト A の IP-IP ゲートウェイに向かう H.323 トランク（図中のコール レッグ 1）を通じてコールをセットアップします。
• サイト A の IP-IP ゲートウェイが、サイト B の IP-IP ゲートウェイに向かう別のコールを確立しようとしますが、まず RSVP を使用して、IP WAN パスに沿って帯域幅リソースを確保します。
• RSVP 予約が成功すると、2 つの IP-IP ゲートウェイ間にコール レッグ 2 が確立されます。
• サイト B の IP-IP ゲートウェイが、サイト B の Cisco CallManager クラスタに向かう別のコール（図中のコール レッグ 3）を生成します。
図9-8 RSVP コール アドミッション制御のための IP-to-IP ゲートウェイの簡単な例
図9-8 の例は、Cisco CallManager クラスタ間のすべてのコールが、IP-IP ゲートウェイ ペアを通じてルーティングされる単純なシナリオです。しかし、多くの実稼働環境では、このアプローチは十分にスケーラブルで柔軟なものとは言えません。これらの場合は、Cisco IOS ゲートキーパーを使用することで、Cisco CallManager クラスタ、H.323 ゲートウェイ、H.323 ビデオ会議エンドポイント、IP-IP ゲートウェイの間に幅広い通信オプションを配置できるようになります。
次の各項では、IP-IP ゲートウェイを中継ゾーン ゲートキーパーと連携して使用する方法について詳しく説明し、設計上のベスト プラクティス、スケーラビリティと冗長性に関する考慮事項、および設定ガイドラインも示します。
（注） この項で説明した IP-IP ゲートウェイ関係のシナリオは、すべて複数の Cisco CallManager クラスタ間のコールに関するものです。同じ Cisco CallManager クラスタに登録されているエンドポイント間で、コールに IP-IP ゲートウェイを挿入することはお勧めしません。
中継ゾーン（Via-Zone）ゲートキーパー
従来の Cisco IOS ゲートキーパー機能は、「中継ゾーン」ゲートキーパーという概念を通じて、IP-IP ゲートウェイに対応するように拡張されました。中継ゾーン ゲートキーパーがレガシー ゲートキーパーと異なっている点は、コール ルーティングでの LRQ メッセージと ARQ メッセージの使用方法です。中継ゾーン ゲートキーパーを使用しても、通常のクラスタおよび機能はそのまま使用できます。レガシー ゲートキーパーは、着信する LRQ を着信番号に基づいて検査します。具体的には、LRQ の destinationInfo 部分にある dialedDigits フィールドを検査します。中継ゾーン ゲートキーパーは、着信番号を検査する前に LRQ の発信地点を検査します。LRQ が、中継ゾーン ゲートキーパーのリモート ゾーン設定にリストされているゲートキーパーから送信されている場合、ゲートキーパーは、ゾーンのリモート設定に invia キーワードまたは outvia キーワードが含まれているかどうかを確認します。設定にこれらのキーワードが含まれている場合、ゲートキーパーは新しい中継ゾーン処理を使用します。含まれていない場合は、従来の処理を使用します。
ARQ メッセージの場合、ゲートキーパーは宛先ゾーンに outvia キーワードが設定されているかどうかを調べます。 outvia キーワードが設定されていて、 outvia キーワードを使用して命名されているゾーンがゲートキーパーに対してローカルである場合は、そのゾーンの IP-IP ゲートウェイに ACF ポインティングが返され、コールが IP-IP ゲートウェイに転送されます。 outvia キーワードを使用して命名されているゾーンがリモートである場合、ゲートキーパーは、ロケーション要求をリモート ゾーンのゲートキーパーではなく outvia ゲートキーパーに送信します。 invia キーワードは、ARQ の処理では使用されません。
図9-9 に、IP-IP ゲートウェイと中継ゾーン ゲートキーパーを Cisco CallManager クラスタおよびレガシー ゲートキーパーと連携するように使用して、コール ルーティングとコール アドミッション制御を提供する方法の例を示します。このシナリオには、次の考慮事項が適用されます。
• サイト A の Cisco CallManager クラスタは、サイト A のゲートキーパーを使用して、コールをクラスタ間で直接ルーティングする。
• サイト A のゲートキーパーは、サイト B の E.164 番号に転送されるすべてのコールを、サイト A の中継ゾーン ゲートキーパーに送信する。
• サイト A の中継ゾーン ゲートキーパーは、サイト A のゲートキーパーを発信元または宛先とするすべてのコールに対して、IP-IP ゲートウェイを挿入する。
• サイト A の IP-IP ゲートウェイは、コールをサイト B の IP-IP ゲートウェイに送信する前に、RSVP 予約を試行する。
• サイト B の Cisco CallManager クラスタ、ゲートキーパー、および IP-IP ゲートウェイは、サイト A のそれぞれと同様の方法で設定されている。
図9-9 中継ゾーン ゲートキーパーを使用した RSVP のための IP-to-IP ゲートウェイ
設計上のベスト プラクティス
IP-IP ゲートウェイを Cisco CallManager と連携するように配置して、IP WAN で RSVP コール アドミッション制御を使用できるようにする場合は、次に示す設計上のベスト プラクティスに従ってください。
• 1 つまたはそれ以上の IP-IP ゲートウェイを通じて他の Cisco CallManager クラスタと音声専用通信を行うために、Cisco CallManager にトランクを設定する場合は、クラスタ間トランクを使用し、トランク設定ページの Media Termination Point required チェックボックスをオンにして、IP-IP ゲートウェイを介して補足サービスを使用できるようにします。
• クラスタ間トランクを介してコールするときに IP WAN 帯域幅の使用が増大するのを避けるために、IP-IP ゲートウェイと同じサイトに MTP リソースを配置することをお勧めします。これらの MTP リソースは、ソフトウェア ベース（Cisco MCS サーバや Cisco IOS ルータなど）でも、ハードウェア ベース（Cisco コミュニケーション メディア モジュールを備えた Catalyst 6500 や、NM-HDV ネットワーク モジュールを備えた Cisco IOS ルータなど）でもかまいません。使用できる MTP リソースの完全なリストについては、「メディア リソース」を参照してください。
• 保留と保留解除、転送、会議などの Cisco CallManager 補足サービスは、IP-IP ゲートウェイを介してサポートされます。ただし、MTP を使用するため、コールが持続しているすべての期間にわたって、メディア パケットは最初の MTP リソースを通じて転送されます。以後にコール転送が発生した場合は、ヘアピンが発生する可能性があります。
• クラスタ間に IP-IP ゲートウェイを通じてビデオ コールを確立する必要がある場合は、ビデオ コール専用のクラスタ間トランクを定義します。このとき、Media Termination Point required チェックボックスはオフにします（これは、MTP がビデオ コールをサポートしていないためです）。これらのトランクでは、補足サービスは一切使用できません。
• すべてのクラスタ間コールで IP-IP ゲートウェイを使用する場合に限り、Cisco CallManager から IP-IP ゲートウェイに向かう直接クラスタ間トランク（ゲートキーパーが制御しないトランク）を設定します。この場合でも、IP-IP ゲートウェイはゲートキーパーを使用してリモートの宛先を解決することができます。
• クラスタ間コールの解決、およびクラスタ間コールを IP-IP ゲートウェイを通じてルーティングするか、直接ルーティングするかの判定にゲートキーパーを使用する場合は、Cisco CallManager にゲートキーパー制御のクラスタ間トランクを設定します。このアプローチでは、より柔軟でスケーラビリティのある配置になります。
• IP-IP ゲートウェイ上の Cisco CallManager との互換性があるのは、Cisco IOS Release 12.3(1) 以降です。Cisco IOS Release 12.3(7)T 以降を使用することをお勧めします。
• ゲートキーパーと中継ゾーン ゲートキーパーの機能は、それぞれ別のルータ プラットフォーム上で実行して、分離します。各 IP-IP ゲートウェイに対して、専用の中継ゾーン ゲートキーパーを配置する必要があります。
• IP-IP ゲートウェイは、遅延保証付きの RSVP 予約を要求するように設定します。また、コールを正常に運用するために、予約を必須にします（詳細については、「設定のガイドライン」の項を参照）。
• 中継ゾーン ゲートキーパー機能と IP-IP ゲートウェイ機能は、同じルータ プラットフォーム上で実行（共存）することができます。ただし、「冗長性」の項で説明しているスケーラビリティの要件に注意してください。
• 同じ Cisco CallManager クラスタに制御されているエンドポイント間では、コールに IP-IP ゲートウェイを使用しないでください。
冗長性
冗長性とスケーラビリティを実現するには、複数の IP-IP ゲートウェイを同じ中継ゾーン ゲートキーパーおよび同じ中継ゾーンに登録します。中継ゾーン ゲートキーパーは、ラウンドロビン アルゴリズムを使用して、同じ中継ゾーンに含まれているすべての IP-IP ゲートウェイに着信コールを自動的に分配します。
IP-IP ゲートウェイに障害が発生すると、そのゲートウェイは中継ゾーン ゲートキーパーへの登録を失います。ゲートキーパーは、使用可能リソースのリストからそのゲートウェイを削除します。
IP-IP ゲートウェイに対して、最大負荷しきい値を手動で設定することもできます。ある IP-IP ゲートウェイで回線の使用率が一定の割合を超えると、そのゲートウェイは新しいコールの処理用としては選択されなくなり、回線の使用率が一定の割合を下回ると、再び使用可能になります。このように設定するには、次の Cisco IOS コマンドを使用します。
これらのコマンドの詳細については、次の Web サイトで入手できる Cisco IOS コマンド解説資料を参照してください。
設定のガイドライン
ここでは、図9-10 に示したネットワーク ダイアグラムに基づく簡単な設定例を示します。この項は、詳細なコマンド リファレンス ガイドを意図したものではなく、一般的な配置シナリオに役立つガイドラインをまとめたものです。IP-IP ゲートウェイおよび中継ゾーン ゲートキーパーを設定する方法の詳細については、次の Web サイトで入手可能な、シスコ マルチサービス IP-to-IP ゲートウェイのオンライン ドキュメントで説明しています。
図9-10 中継ゾーン ゲートキーパーを使用した IP-IP ゲートウェイの設定例
図9-10 に示すネットワークで、サイト A に、電話内線番号 1 xxx を持つクラスタ A1、および電話内線番号 2 xxx を持つクラスタ A2 という 2 つの Cisco CallManager クラスタがあるとします。サイト B にも、電話内線番号 3 xxx を持つクラスタ B1、および電話内線番号 4 xxx を持つクラスタ B2 という 2 つの Cisco CallManager クラスタがあります。
次の各項に、サイト A にあるデバイスに関連する設定を示します。サイト A の内部でやり取りされるコールは、（サイト A のレガシー ゲートキーパーを使用して）Cisco CallManager クラスタ間で直接ルーティングされるのに対して、サイト B に向かうコールは、2 つの IP-IP ゲートウェイを通じて（それぞれのレガシー ゲートキーパーと中継ゾーン ゲートキーパーを使用して）ルーティングされます。
Cisco CallManager
クラスタ A1 とクラスタ A2 は、ゲートキーパー制御の 2 つのクラスタ間トランクを使用します。最初のトランク T1 は、必要となる MTP を使用して設定され、サイト A のレガシー ゲートキーパーを指しています。2 番目のトランク T2 もサイト A のレガシー ゲートキーパーを指していますが、MTP を必要としません。
[34]XXX ルート パターンは、ゲートキーパーおよび IP-IP ゲートウェイを通じてサイト B のクラスタに到達するために、ルート リストおよびルート グループを通じてトランク T1 を指しています。
他のルート パターン（クラスタ A1 の 2XXX とクラスタ A2 の 1XXX）は、ルート リストおよびルート グループを通じて トランク T2 を指すことで、クラスタ A1 と A2 がゲートキーパーを通じて互いに通信できるようにしています。
レガシー ゲートキーパー
サイト A のレガシー ゲートキーパーは、クラスタ A1 と A2 の間ではコールを直接ルーティングし、サイト B に向かうコール（内線番号 3 xxx と 4 xxx ）については、すべてサイト A の中継ゾーン ゲートキーパーに送信します。例9-1 に、関連する設定を示します。
中継ゾーン ゲートキーパー
サイト A の中継ゾーン ゲートキーパーは、サイト B の Cisco CallManager クラスタ（内線番号 3 xxx と 4 xxx ）に向かうコールをサイト B の中継ゾーン ゲートキーパーに送信し、サイト B で発着信されるコールに使用される IP-IP ゲートウェイを呼び出します。サイト A のクラスタに向かうコールは、サイト A のレガシー ゲートキーパーにルーティングされ、IP-IP ゲートウェイは呼び出されません。例9-2 に、関連する設定を示します。
例9-2 に示す設定には、次の考慮事項が適用されます。
• B-VIAGK リモート ゾーンに関連するコマンドラインに invia キーワードと outvia キーワードが存在しているため、このゾーンの中継ゾーン ゲートキーパーの処理がアクティブになります。つまり、B-VIAGK リモート ゾーンが宛先また発信元となるすべてのコールについて、中継ゾーン ゲートキーパーは、A-VIAGK ローカル ゾーンに登録されている IP-IP ゲートウェイ リソースを呼び出します。
• CCM-A1 リモート ゾーンおよび CCM-A2 リモート ゾーンに関連するコマンドラインには、 invia キーワードと outvia キーワードがありません。このため、標準のゲートキーパー処理が適用され、これらのゾーンで発着信されるコールに対しては、IP-IP ゲートウェイは呼び出されません。
IP-IP ゲートウェイ
サイト A の IP-IP ゲートウェイは、サイト B の Cisco CallManager クラスタ（内線番号 3 xxx と 4 xxx ）に向かう音声コールとビデオ コールについては、RSVP 予約を要求します。一方で、サイト A の Cisco CallManager クラスタ（内線番号 1 xxx と 2 xxx ）に向かうコールについては要求しません。例9-3 に、関連する設定を示します。
例9-3 に示す設定には、次の考慮事項が適用されます。
• Cisco IOS Release 12.3(7)T 以降では、IP-IP ゲートウェイ上で、Cisco CallManager 互換モードがデフォルトでは有効になっていません。このため、 h225 h245-address コマンドと ccm-compatible コマンドが必要になります。
• call sync-rsvp slow-start コマンドで、H.323 スロースタート音声コールおよびビデオ コールと RSVP シグナリングの同期を有効にします。この機能は、通常はデフォルトで有効になっています。音声コールとビデオ コールで RSVP 予約を必須にする場合は、このコマンドが無効になっていないことを確認してください。
• req-qos guaranteed-delay [ audio | video ] コマンドで、ダイヤルピア 10（サイト B の内線に到達するためのダイヤルピア）を使用する音声コールとビデオ コールについて、IP-IP ゲートウェイが遅延保証付きの RSVP 予約を要求することを指定します。
• acc-qos guaranteed-delay [ audio | video ] コマンドで、音声コールとビデオ コールに関して許容可能な最小限の QoS レベルも、遅延保証付き RSVP 予約であることを指定します。これは、RSVP 要求が失敗した場合はコールも失敗するので、RSVP 予約を必須にすることを意味します。RSVP 予約がオプションになるように（予約が失敗した場合でもコールが通過できるように）IP-IP ゲートウェイを設定するには、代わりに acc-qos best-effort [ audio | video ] コマンドを使用します。
コール アドミッション制御の設計
ここでは、各種の Cisco CallManager 配置モデルおよび次の IP WAN トポロジに対して、コール アドミッション制御メカニズムを適用する方法について説明します。
• 「複合トポロジ」
採用する Cisco CallManager 配置モデルに基づいて、トポロジごとにそれぞれ別の設計考慮事項を示します。
（注） この項で説明するコール アドミッション制御ソリューションは、RSVP に基づくものを除いて、すべて各サイトの使用可能帯域幅を静的に設定することで成り立っています。このコール アドミッション制御メカニズムは、トポロジの変更やリンク障害に動的に対応することはできません。サイトが IP WAN に 2 系統で接続している場合、計算時には帯域幅が最も小さいリンクを選択して、最悪のシナリオを見越しておく必要があります。
単純なハブアンドスポーク トポロジ
図9-11 に、スター トポロジとも呼ばれる単純なハブアンドスポーク トポロジを示します。このタイプのネットワーク トポロジでは、すべてのサイト（「スポーク サイト」と呼ばれる）が 1 つの中央サイト（「ハブ サイト」と呼ばれる）に接続されます。スポーク サイト間には直接のリンクが存在しないため、スポーク サイト間の通信は、すべてハブ サイトを経由する必要があります。
単純なハブアンドスポーク トポロジに関する設計上の考慮事項は、次のような従来のレイヤ 2 IP WAN テクノロジーに適用されます。
• フレーム リレー/ATM 間サービス インターワーキング
MPLS テクノロジーに基づいた IP WAN 配置については、「MPLS ベースのトポロジ」の項を参照してください。
以降では、採用する Cisco CallManager 配置モデルごとに、単純なハブアンドスポーク トポロジに関する設計上のベスト プラクティスを示します。
1 つまたはそれ以上の Cisco CallManager クラスタをハブ サイトに配置し、スポーク サイトには電話とゲートウェイのみを配置します。
Cisco CallManager クラスタを各サイトに配置します。
Cisco CallManager クラスタをハブ サイトと一部のスポーク サイトに配置し、それ以外のスポーク サイトには電話とゲートウェイのみを配置します。
単純集中型配置
単純なハブアンドスポーク トポロジ上にあり、集中型コール処理を使用するマルチサイト WAN 配置では、Cisco CallManager の「ロケーション」を使用してコール アドミッション制御を実装します。コール アドミッション制御に対してロケーションを使用する場合は、次のガイドラインに従ってください。
• 各スポーク サイトの Cisco CallManager に対しては、個別にロケーション設定が必要です。
• 各サイトの帯域幅の上限を、そのサイトに使用されているコーデックのタイプに応じて、適切に設定します（帯域幅の推奨設定については、 表9-1 を参照してください）。
• 各スポーク サイトのすべてのデバイスを適切なロケーションに割り当てます。
• ハブ サイトのデバイスは、<None> ロケーションのままにします。
• あるデバイスを別のロケーションに移した場合、ロケーションの設定も変更します。
• Cisco CallManager は、ロケーションを 500 個所までサポートします。
• WAN の帯域幅が十分にない場合に、公衆網を介した自動ルーティングを実行する必要があるときは、Cisco CallManager 上で Automated Alternate Routing（AAR）機能を設定します（「Automated Alternate Routing」を参照）。
• 中央サイトに複数の Cisco CallManager クラスタを配置する場合は、クラスタ間トランク デバイスを <None> ロケーションのままにします。ダイヤル プランの解決には、ゲートキーパーを使用できます。ただし、この場合、ゲートキーパーのコール アドミッション制御は必要ありません。これは、すべての IP WAN リンクがロケーション アルゴリズムによって制御されるためです。
（注） Cisco CallManager Release 3.1 以前のリリースでは、コール アドミッション制御用にロケーションを使用する場合には、クラスタはプライマリ（アクティブ）Cisco CallManager サーバを 1 つのみサポートしていました。Cisco CallManager Release 3.1 およびそれ以降では、ロケーションの帯域幅は、クラスタ内のすべての Cisco CallManager サブスクライバ サーバ間で共有されるので、ロケーション メカニズムには任意のサイズのクラスタを使用できるようになりました。
単純分散型配置
単純なハブアンドスポーク トポロジの分散型コール処理配置では、Cisco IOS ゲートキーパーを使用してコール アドミッション制御を実装できます。この設計では、コール処理エージェントは Cisco IOS ゲートキーパーに登録し、IP WAN コールを発信しようとするたびに、エージェントがゲートキーパーに照会します。Cisco IOS ゲートキーパーは、各コール処理エージェントを、特定の帯域幅制限があるゾーンに関連付けます。したがって、Cisco IOS ゲートキーパーは、ゾーンに出入りする IP WAN 音声コールが消費する最大帯域幅量を制限することができます。
図9-12 では、ゲートキーパーを使用したコール アドミッション制御を示しています。つまり、コール処理エージェントは、IP WAN コールを発信するときに、まずゲートキーパーに許可を要求します。ゲートキーパーが許可を与えると、コール処理エージェントは、IP WAN を介してコールを発信します。ゲートキーパーが要求を拒否する場合、コール処理エージェントは別のパス（たとえば、公衆網）を試行するか、単にコールを廃棄させることができます。この設計は、本来、アドミッション制御を提供するためのコール アカウンティング方式から構成されます。この方式では、ゲートキーパーは、IP WAN コールによって消費される帯域幅をトラッキングします。ゾーンに最大帯域幅を設定する場合は、音声トラフィックの消費量が通常は WAN リンクの 33% を超えてはならないという制限事項を考慮してください。
図9-12 ゲートキーパーを使用したコール アドミッション制御
要約すると、ゲートキーパーによるコール アドミッション制御の主な設計上の意味は、次のとおりです。
• ゲートキーパーは、マルチサイト分散型コール処理環境で数百のサイトをサポートする。
• ゲートキーパーは、ゾーンに出入りする使用済み帯域幅をトラッキングする。各コールによって消費される帯域幅量は、コール処理エージェントからのコール要求の総数、およびコールに使用されるコーデックのタイプに依存します。
• コール ARQ（アドミッション要求）に対する帯域幅計算には、cRTP（Compressed Real-time Transport Protocol）やその他のトランスポートのオーバーヘッドは含まれない。
• トポロジは、ゲートキーパーのゾーン概念に基づいた、論理ハブアンドスポークである。
H.225 ゲートキーパー制御トランクは、Cisco CallManager が Cisco CallManager クラスタおよび H.323 ゲートキーパーに登録済みの他の H.323 デバイスと通信できるようにします。H.225 ゲートキーパー制御トランクは、Cisco CallManager のみの環境ではお勧めしませんが、Cisco CallManager と Cisco CallManager Express（または H.323 ゲートウェイ）の混合環境では必要です。H.225 トランクは、コールごとに他の H.323 デバイスを検出しようとします。クラスタ間トランク プロトコルを認識できるデバイスを検出した場合は、自動的にそのプロトコルを使用します。トランクが他のデバイスを検出できない場合、Cisco CallManager は標準の H.225 プロトコルを使用します。
クラスタ間トランク プロトコルの検出は、Cisco CallManager Release 3.2 で追加された機能です。これより前のリリースと併用する場合は、Cisco CallManager クラスタと通信するために、クラスタ間トランクを使用する必要があります。使用しない場合は、すべてのクラスタを Release 3.2 以降にアップグレードして、H.225 トランクと H.323 トランクを正しく操作できるようにします。クラスタ間トランクと H.225 トランクのどちらか一方でも使用しない場合、H.323 デバイスと Cisco CallManager の両方をすべてゲートキーパーに登録して、正常に運用することはできません。
コール アドミッション制御に H.225 ゲートキーパー制御トランクを使用する場合は、次に示すガイドラインに従ってください。
• 各 Cisco CallManager クラスタのゲートウェイは、同じ方法で設定します。
• Cisco CallManager クラスタに H.225 ゲートキーパー制御トランクを設定して、ゾーンをサイトの適切なゲートキーパー ゾーンに対応付けます。
• デバイス プールの Cisco CallManager 冗長性グループにリストされている各 Cisco CallManager サブスクライバは、H.225 ゲートキーパー制御トランクをゲートキーパーに登録します（最大で 3 つまで）。
• コールは、Cisco CallManager クラスタ内に登録済みのトランク間にロードバランスされます。
• Cisco CallManager は、複数のゲートキーパーおよびトランクをサポートします。
• トランクをルート グループとルート リスト コンストラクトに配置すると、自動公衆網フェールオーバーを提供できます。詳細については、「ダイヤル プラン」を参照してください。
• Cisco CallManager、Cisco CallManager Express、または音声ゲートウェイをサポートしている各サイトに対するゲートキーパーのゾーンは、個別に設定します。
• bandwidth interzone コマンドをゲートキーパーに使用して、そのゲートキーパーに直接登録済みの Cisco CallManager クラスタ、Cisco CallManager Express サーバ、および H.323 デバイス間の帯域幅の制御を行います（コーデック タイプ別の帯域幅の設定については、 表9-2 を参照してください）。
• 1 つの Cisco IOS ゲートキーパーで、100 までのゾーンまたはサイトをサポートできます。例9-4 では、一般的なゲートキーパー設定を示しています。
• ゲートキーパーの冗長性は、ゲートキーパー クラスタリング（代替ゲートキーパー）または Cisco ホットスタンバイ ルータ プロトコル（HSRP）を使用すると実装することができます。HSRP は、ソフトウェア機能セットにゲートキーパー クラスタリングが利用可能ではない場合に限り使用します。
例9-4 H.225 ゲートキーパー制御トランクに対する一般的なゲートウェイ設定
ここでは、例9-4 について説明します。
• zone local コマンドを使用して、ゲートキーパー ゾーンを作成しています。設定済みのゾーンには、各 Cisco CallManager およびゲートウェイが登録されます。
• ゾーン間のコール ルーティングには、 zone prefix が使用されています。
• bandwidth interzone コマンドは、ゾーン間で利用できる帯域幅の量を割り当てます。
• gw-type-prefix 1# default technology コマンドは、ゾーン内で解決されないコールを登録済みテクノロジー プレフィックス 1# を持つデバイスにルーティングします。この設定例では、Cisco CallManager トランクが該当します。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
（注） クラスタ間ゲートキーパー制御トランクは、Cisco CallManager が H.323 ゲートキーパーに登録済みの他の Cisco CallManager クラスタとの通信を行えるようにします。ゲートキーパー制御のクラスタ間トランクは、全面的に Cisco CallManager を基盤としている配置でのみ使用することをお勧めします。
集中型および分散型複合配置
集中型および分散型のコール処理を単純なハブアンドスポーク トポロジ上で組み合せた複合配置では、Cisco IOS ゲートキーパーと Cisco CallManager ロケーションの両方を使用してコール アドミッション制御を提供できます。図9-13 では、スポーク サイト 1 ～ n がハブ サイトの Cisco CallManager クラスタ 1 によって集中制御されるトポロジを示しています。スポーク サイト (n+1) と (n+2) は、それぞれが専用のオンサイト Cisco CallManager クラスタ（クラスタ 2 と 3）を持っています。
• スポーク サイト 1 ～ n にコール アドミッション制御を提供するには、Cisco CallManager ロケーションを使用します。各スポーク サイトは、それぞれ別のロケーションに割り当てます。この他の考慮事項については、「単純集中型配置」の項を参照してください。
• スポーク サイト (n+1) と (n+2) にコール アドミッション制御を提供するには、ハブ サイトにある Cisco IOS ゲートキーパーを使用します。各 Cisco CallManager クラスタは、それぞれ別のゲートキーパー ゾーンに割り当てます。この他の考慮事項については、「単純分散型配置」の項を参照してください。
• ゲートキーパー制御のクラスタ間トランク（または H.225 トランク）は、<None> ロケーションのままにします。これは、クラスタ間のコール アドミッション制御はゲートキーパーが実行するためです。
図9-13 単純なハブアンドスポーク トポロジの集中型および分散型複合配置
2 層ハブアンドスポーク トポロジ
図9-14 では、2 層ハブアンドスポーク トポロジを示しています。このタイプのネットワーク トポロジは、ハブアンドスポーク トポロジを「2 乗」したものと見なすことができ、3 階層のサイトで構成されています。第 1 層ハブ サイト、第 2 層ハブサイト、およびスポーク サイトです。スポーク サイトのグループが 1 つの第 2 層ハブ サイトに接続され、各第 2 層ハブ サイトは 1 つの第 1 層ハブ サイトに接続されます。単純なハブアンドスポーク トポロジであるため、スポーク サイト間には直接のリンクが存在しません。したがって、スポーク サイト間の通信は、すべて第 2 層ハブ サイトを経由する必要があります。同様に、第 2 層ハブ サイト間には直接のリンクが存在しないため、これらのハブ サイト間の通信は、すべて第 1 層ハブ サイトを経由する必要があります。
2 層ハブアンドスポーク トポロジに関する設計上の考慮事項は、次のような従来のレイヤ 2 IP WAN テクノロジーに適用されます。
• フレーム リレー/ATM 間サービス インターワーキング
MPLS テクノロジーに基づいた IP WAN 配置については、「MPLS ベースのトポロジ」の項を参照してください。
以降では、採用する Cisco CallManager 配置モデルごとに、2 層ハブアンドスポーク トポロジに関する設計上のベスト プラクティスを示します。
1 つまたはそれ以上の Cisco CallManager クラスタを第 1 層ハブ サイトに配置し、第 2 層ハブ サイトとスポーク サイトには電話とゲートウェイのみを配置します。
Cisco CallManager クラスタを各サイトに配置します。
Cisco CallManager クラスタを第 1 層ハブ サイトと第 2 層ハブ サイトに配置し、スポーク サイトには電話とゲートウェイのみを配置します。
単純集中型配置
2 層ハブアンドスポーク トポロジを使用する集中型コール処理配置は、コール アドミッション制御に関しては問題が生じます。Cisco CallManager の「ロケーション」アルゴリズムは、集中型コール処理配置でコール アドミッション制御に使用できる唯一のメカニズムであり、単純なハブアンドスポーク トポロジで機能するように設計されています。
ここでは、このようなトポロジで生じる問題点を緩和する方法について説明します。ただし、この回避策には制約があるため、この問題を解決するには、Cisco CallManager クラスタの分布を変更するか、トポロジを単純なハブアンドスポークに変更する方法をお勧めします。この方法については、この項の最後で説明します。
図9-15 では、集中型コール処理配置の Cisco CallManager クラスタで 2 層ハブアンドスポーク トポロジをサポートする方法を示しています。
この方法を使用する場合は、次のガイドラインに従ってください。
• 第 1 層ハブ サイト（中央サイト）のデバイスは、<None> ロケーションのままにします。
• 各スポーク サイトのデバイスは、独自のロケーションに配置します。ロケーションの帯域幅は、それぞれのサイトで発着信を許可するコール数に従って定義します。図9-15 の例では、3 つのスポーク サイト（支店 1、2、3）のロケーションの帯域幅を 48 Kbps に設定しています。これは、 G.729 コーデックを使用するコール 2 つに対応できる値です。
• 第 2 層ハブ サイトとスポーク サイト間のリンクについて、プライオリティ キューの帯域幅を LLQ 設定で設定します。この帯域幅が、スポーク サイトのロケーションの帯域幅と一致するようにします。ここでは、この帯域幅設定は 48 Kbps です。
• 各第 2 層ハブ サイトのデバイスは、独自のロケーションに配置します。ロケーションの帯域幅は、それぞれのサイトで発着信を許可するコール数に従って定義します。この帯域幅については、第 2 層ハブ サイトで発着信されるすべてのコールを考慮に入れてください。第 1 層ハブ サイトに向かうコールに加えて、下位のスポーク サイトに向かうコールも含めます。図9-15 の例では、第 2 層ハブ サイト（リージョン サイト）のロケーションの帯域幅を 192 Kbps に設定しています。これは、 G.729 コーデックを使用するコール 8 つに対応できる値です。
• 第 1 層ハブ サイトと各第 2 層ハブ サイト間のリンクについて、プライオリティ キューの帯域幅を LLQ 設定で設定します。この帯域幅が、第 2 層ハブ サイト自体のロケーション帯域幅と、その第 2 層ハブ サイトに接続されているスポーク サイトのすべてのロケーション帯域幅を合計した値と一致するようにします。ここでは、この帯域幅設定は 192 + 48 + 48 + 48 = 336 Kbps です。
（注） この例では、説明を簡潔にするために、レイヤ 3 の値（つまり、G.729 コールの 24 Kpbs）に基づいた LLQ 帯域幅設定を示しています。LLQ キューを設定するときは、実際にはレイヤ 2 オーバーヘッドも考慮する必要があります。各種のレイヤ 2 WAN テクノロジーの帯域幅値の完全なリストについては、「帯域幅のプロビジョニング」の項の表3-5 を参照してください。
図9-15 の例に示したように、この方法は、第 1 層ハブと第 2 層ハブ間のプライオリティ キュー帯域幅を多めに設定することで成り立っています。この設定によって、Cisco CallManager ロケーションが、一連のスポーク サイトが実際には特定の第 2 層ハブ サイトを通じて接続されているという事実を認識しない点を補っています。したがって、設定では、任意の 2 サイトが通信するときは必ず第 1 層ハブ サイトを経由する、と見なして帯域幅を考慮する必要があります。
この方法では、どのような状況でも音声品質が維持されますが、次の設計上の考慮事項と警告事項も適用されるようになります。
• 第 2 層ハブ サイト 1 つあたりのスポーク サイト数が大きくなると、第 2 層サイトと第 1 層ハブ サイトの間に設定する必要のあるプライオリティ キュー帯域幅の量も大幅に増加します。
• 計算は最悪のシナリオに基づいて行うため、帯域幅の使用率は、限界値よりは低くなります。たとえば、図9-15 の 3 つの支店それぞれで、リージョン サイトに向かう 2 つのアクティブなコールが発生しているとします。この場合、プライオリティ キューで実際に使用可能な帯域幅を見ると、さらに 14 のコールを許可できますが、Cisco CallManager は、これ以上はリージョン サイトから中央サイトに向かう 2 つのコールしか許可しません。
• IP WAN を介してコールを確立できるかどうかは、実際の帯域幅リソースに余裕がある場合でも保証されません。たとえば、図9-15 のリージョン サイトで、中央サイトに向かう 8 つのアクティブなコールが発生しているとします。この場合、使用可能な実際の帯域幅を見ると、各支店からの 2 つのコールを許可できますが、Cisco CallManager は支店がリージョン サイトにコールすることを許可しません。一方、同じ状況で支店が中央サイトにコールすることは許可されます。
（注） 第 2 層ハブ サイトに接続されているスポーク サイトを、その第 2 層ハブ サイトと同じロケーションにすべて配置することはお勧めしません。このようなソリューションは、すべてのシナリオで音声品質を保証できるとは限らず、シスコではサポートしません。
この項で今までに説明したように、この項で示した回避策にはいくつかの制約があります。これよりも優れたソリューションとしては、次のいずれかの変更を実施して、配置の特性を変更することをお勧めします。
• 第 2 層ハブ サイトとスポーク サイトにある電話の数に基づいて、第 2 層ハブ サイトと第 1 層ハブ サイト間のリンク速度およびプライオリティ キュー帯域幅を十分に増強し、オーバーサブスクリプションの状態にならないようにします。この状況では、第 2 層ハブ サイトは第 1 層ハブ サイトと論理上同じ場所にあるものと見なすことができ、第 2 層ハブ サイトのデバイスを <None> ロケーションのままにすることができます。したがって、ロケーションを、スポーク サイトと第 2 層ハブ サイト間にあるリンクの帯域幅使用を制御するためにのみ使用できます。
• すべてのスポーク サイトを第 1 層ハブ サイトに直接接続して、ネットワーク トポロジを単純なハブアンドスポークに変更します。「単純なハブアンドスポーク トポロジ」の項の説明に従って、Cisco CallManager ロケーションを使用してコール アドミッション制御を実行します。
• ネットワーク トポロジを MPLS ベース ネットワークに変更します。「MPLS ベースのトポロジ」の項の説明に従って、Cisco CallManager ロケーションを使用してコール アドミッション制御を実行します。
• 第 1 層ハブ サイトに加えて、第 2 層ハブ サイトにも Cisco CallManager クラスタを配置して、集中型および分散型複合 Cisco CallManager 配置にします。第 1 層ハブ サイトと第 2 層ハブ サイトの間にあるリンクに対してコール アドミッション制御を実行するには、Cisco IOS ゲートキーパーを使用します。第 2 層ハブ サイトとスポーク サイト間のリンクに対しては、Cisco CallManager ロケーションを使用します。詳細については、「集中型および分散型複合配置」の項を参照してください。
単純分散型配置
2 層ハブアンドスポーク トポロジを使用する分散型のコール処理配置では、Cisco IOS ゲートキーパーを使用することで、すべての IP WAN リンクに対してコール アドミッション制御を実行できます。図9-16 では、このような配置の例を示しています。Cisco CallManager を各サイトに配置し、Cisco IOS ゲートキーパーを第 1 層ハブ サイトと第 2 層ハブ サイトに配置し、ディレクトリ ゲートキーパーを第 1 層ハブ サイトに配置しています。
図9-16 の例には、次の設計上の推奨事項が適用されます。
• 第 2 層ハブ サイトにあるゲートキーパー上で、第 2 層ハブ サイト自体のローカル ゾーンとともに、各スポーク サイトのローカル ゾーンも定義します。スポーク サイトと第 2 層ハブ サイトの間にあるリンクに対してコール アドミッション制御を実行するには、このゲートキーパー上で bandwidth interzone コマンドを使用します。この例では、Dallas にある US ゲートキーパーに 3 つのローカル ゾーンが設定されています。Dallas サイトの USHub、Los Angeles サイトの USWest、Boston サイトの USEast です。 bandwidth interzone コマンドは、スポーク サイト（USWest と USEast）に割り当てられているゾーンに適用されます。
• 第 2 層ハブ サイトにあるゲートキーパー上で、第 1 層ハブ サイトにあるディレクトリ ゲートキーパーを指すリモート ゾーンを定義します。コール ルーティングは、ローカル ゾーンで処理できないすべてのコールがこのリモート ゾーンに送信されるように設定します。第 1 層ハブ サイトに向かうリンクに対してコール アドミッション制御を実行するには、各第 2 層ハブ サイトのゲートキーパー上で、 bandwidth remote コマンドを使用します。この例では、Dallas にある US ゲートキーパー上に、ディレクトリ ゲートキーパー（AMER-DGK）に接続するためのリモート ゾーンが設定されています。このゲートキーパーでは、 bandwidth remote コマンドを使用して、Chicago に向かうリンクで使用される帯域幅の量を制限しています。
• 第 1 層ハブ サイトにあるゲートキーパー上で、同じ場所にある Cisco CallManager クラスタのローカル ゾーンを定義し、同じ場所にあるディレクトリ ゲートキーパーのリモート ゾーンを定義します。このゲートキーパー上では、コール アドミッション制御は必要ありません。
• 第 1 層ハブ サイトにあるディレクトリ ゲートキーパー上で、ディレクトリ ゲートキーパー自体のローカル ゾーンを定義し、各 Cisco CallManager クラスタ（つまり、このトポロジに含まれている各サイト）のリモート ゾーンを定義します。コール ルーティングは、コールが着信番号に従って適切なゲートキーパーに送信されるように設定します。
（注） この配置モデルでは、bandwidth remote コマンドを使用できます。第 2 層ハブ サイトの各ゲートキーパーで、トポロジの性質上、宛先がいずれかのローカル ゾーンではないコールは、すべて第 1 層ハブ サイトに向かうリンクを通過することが保証されるためです。第 2 層ハブ サイト間にピアツーピアのリンクがある場合では、第 1 層ハブ サイトに向かうリンクと同様に、それらのリンク上の帯域幅を制御することはできません。これは、bandwidth remote コマンドは 1 つの帯域幅値しか受け付けないためです。
集中型および分散型複合配置
2 層ハブアンドスポーク トポロジを採用していて、第 1 層ハブ サイトと第 2 層ハブ サイトに Cisco CallManager がある配置にコール アドミッション制御を提供するには、図9-17 に示されているようにロケーションとゲートキーパー メカニズムを組み合せて対応します。
図9-17 コール アドミッション制御にロケーションおよびゲートキーパー メカニズムを組み合せる方式
H.323 トランクをロケーションと組み合せてコール アドミッション制御を実行する場合は、次の推奨事項に従ってください。
• ローカル Cisco CallManager を使用していないサイト（つまり、スポーク サイト）には、ロケーション ベースのコール アドミッション制御を使用します。
• Cisco CallManager クラスタ間（つまり、第 1 層ハブ サイトと第 2 層ハブ サイト間）には、ゲートキーパー ベースのコール アドミッション制御を使用します。
• ローカル Cisco CallManager を使用していない各サイトには、そのサイトをサポートしている Cisco CallManager クラスタ内にロケーションを設定します。
• 各サイトの帯域幅の上限を、そのサイトに使用されているコーデックのタイプに応じて、適切に設定します（帯域幅の設定については、 表9-1 と 表9-2 を参照してください）。
• Cisco CallManager に設定された各デバイスをロケーションに割り当てます。あるデバイスを別のロケーションに移した場合、ロケーションの設定も変更します。
• Cisco CallManager は、ロケーションを 500 個所までサポートします。
• 各 Cisco CallManager クラスタは、ゲートキーパー制御の H.323 トランクをゲートキーパーに登録します。
• ゾーン間の帯域幅を設定して、クラスタ間のコールの数を制御します。
例9-5 では、一般的なゲートキーパーの設定を示しています。
例9-5 ロケーションを使用するゲートキーパー制御クラスタ間トランクに対する一般的なゲートキーパー設定
ここでは、例9-5 について説明します。
• zone local コマンドを使用して、ゲートキーパー ゾーンを作成しています。各 Cisco CallManager は、ゲートキーパー制御のクラスタ間トランクをその設定済みゾーンに登録しています。
• ゾーン間のコール ルーティングには、 zone prefix が使用されています。必要な場合は、同一ゾーンに対して複数のゾーン プレフィックスを設定します。
• bandwidth interzone コマンドは、ゾーン間で利用できる帯域幅の量を割り当てます。
• gw-type-prefix 1# default technology コマンドは、ゾーン内で解決されないコールを登録済みテクノロジー プレフィックス 1# を持つデバイスにルーティングします。この設定例では、Cisco CallManager トランクが該当します。
• arq reject-unknown-prefix コマンドは、冗長 Cisco CallManager トランク上にできるコール ルーティング ループを回避します。
MPLS ベースのトポロジ
図9-18 では、Multiprotocol Label Switching（MPLS）テクノロジー ベースの（サービス プロバイダーからの）IP WAN を示しています。サービス プロバイダーの提供する従来のレイヤ 2 WAN サービスと MPLS ベースのサービスのデザイン上の大きな違いは、MPLS を使用すると、IP WAN のトポロジはハブアンドスポークに準拠していないということです。すべてのサイト間の接続にはフルメッシュ接続方式を採用します。
このトポロジの違いは、ネットワークを企業側での IP ルーティングという観点から見たとき、各サイトが、他のどのサイトからも IP ホップ 1 つ分しか離れていないことを意味します。したがって、他のサイトに到達するためにハブ サイトを経由する必要はありません。事実上、「ハブ サイト」という概念が存在しません。すべてのサイトが対等と見なされ、各サイトで異なっているのは、IP WAN を介して使用することのできる帯域幅の量のみです。
図9-18 サービス プロバイダーからの MPLS IP WAN、およびこれに相当するトポロジ
これまでに検討した内容に基づくと、コール アドミッション制御という観点から見たとき、MPLS に基づくサービス プロバイダー IP WAN サービスは、実質的には、ハブ サイトのないハブアンドスポーク トポロジに相当することが簡単にわかります（図9-18 を参照）。事実上、ネットワーク自体をハブ サイトと見なすことができます。企業サイトは、いずれも（本社、つまり中央サイトを含めて）スポーク サイトに相当します。このように見方を変えると、コール アドミッション制御の実行方法も異なってきます。この方法については、以降で説明します。
上で検討した内容の中で、ここで例外として言及する価値があるのは、マルチサイト配置において、MPLS ベースの WAN がフレーム リレーや ATM などの従来のレイヤ 2 テクノロジー ベースの IP WAN と共存している場合です。このようなシナリオは、実際に発生する可能性があります。たとえば、ネットワークが移行の途中段階にある場合や、企業合併などの状況が発生した場合です。
図9-19 に示すように、従来のレイヤ 2 テクノロジー（フレーム リレーなど）ベースのハブアンドスポーク IP WAN を MPLS ベースの IP WAN と統合すると、ネットワーク トポロジは単純なハブアンドスポークやフルメッシュではなく、2 層ハブアンドスポークになります。
この場合、MPLS ネットワークが第 1 層ハブ サイトを表し、MPLS 対応のフレーム リレー ハブ サイト、および MPLS ベースのサイトが第 2 層ハブ サイトを表し、フレーム リレー スポーク サイトがスポーク サイトを表します。したがって、このような配置での設計上の考慮事項については、「2 層ハブアンドスポーク トポロジ」の項を参照してください。
図9-19 MPLS サイトとフレーム リレー サイトの共存、およびこれに相当するトポロジ
以降では、採用する Cisco CallManager 配置モデルごとに、MPLS ベースのトポロジに関する設計上のベスト プラクティスを示します。
1 つのサイトに Cisco CallManager クラスタを 1 つのみ配置し、それ以外のすべてのサイトには、電話とゲートウェイのみを配置します。
Cisco CallManager クラスタを各サイトに配置します。
Cisco CallManager クラスタを一部のサイトに配置し、それ以外のサイトには、電話とゲートウェイのみを配置します。
（注） ここでは、サービス プロバイダーによって MPLS サービスが提供されている企業の配置を中心に説明します。MPLS ネットワークを企業が独自に配置している場合は、ある 2 つの条件のうちいずれかを満たしていると、実質的にコール アドミッション制御を実行できます。最初の条件は、MPLS ネットワークでのルーティングが、ネットワークがハブアンドスポークになるように設定されていること、2 番目の条件は、輻輳が末端部分でしか発生しないように、MPLS ネットワークの核の部分の帯域幅を非常に大きく設定していることです。
単純集中型配置
単一クラスタ集中コール処理配置では、コール アドミッション制御機能は Cisco CallManager 内のロケーション構成により実行されます。
ハブアンドスポーク WAN トポロジ（フレーム リレー、ATM など）では、支店サイトとのリンクはすべて、中央サイトで終端します。フレーム リレーを例にすると、支店ルータからのすべての PVC（Permanent Virtual Circuits; 相手先固定接続）は、中央サイトのヘッドエンド ルータに集約されています。この例では、帯域幅に対する課金は WAN リンクの支店エンドで行われているので、中央サイドではデバイスにコール アドミッション制御を適用する必要はありません。したがって、Cisco CallManager ロケーションの設定では中央サイトのデバイスのロケーションは <None> のままにしておきます。一方、各支店のデバイスは適切なコール アドミッション制御を受けるために各支店のロケーションに指定される必要があります。
MPLS WAN ネットワークでは、すべての支店はレイヤ 3 で隣接していると見なされるため、中央サイトに接続する必要はありません。図9-20 では、スポークツースポーク配置による 2 つの支店間のコールを説明しています。
図9-20 MPLS 配置におけるスポークツースポーク コール
また、MPLS WAN では、中央サイト WAN に接続しているリンクは支店の WAN リンクに集約していません。中央サイトに存在するすべてのデバイスは、個々のデバイスに対応するコール アドミッション制御ロケーション（したがって、<None> ロケーションではありません）に指定されています。したがって、このスポークツースポーク設定では支店のリンクとは無関係に、コール アドミッション制御は中央サイト リンク上で実行される必要があります（図9-21 を参照）。
特定サイトに許されている帯域幅がすべて消費されてしまっている場合は、Cisco CallManager が備えている Automated Alternate Routing（AAR）機能を使用して、公衆網へ自動的にフェールオーバーさせることができます。AAR の詳細については、「Automated Alternate Routing」を参照してください。
単純分散型配置
各サイトに Cisco CallManager クラスタが設定されていて、どのサイト間も MPLS WAN でリンクされているマルチ サイト配置の場合は、ゲートキーパーがサイト間のコール アドミッション制御を行い、個々のサイトを異なるゲートキーパー ゾーンに格納します。この同様のメカニズムは、レイヤ 2 WAN テクノロジーをべースにしたハブアンドスポークトポロジにも適用されています（図9-22 を参照）。
図9-22 MPLS を使用した分散型配置におけるゲートキーパー コール アドミッション制御
特定サイトに許されている帯域幅がすべて消費されてしまっている場合は、各クラスタからゲートキーパーへ接続する際のルート パターンが指定されているルート リストおよびルート グループを使用して、公衆網へ自動的にフェールオーバーさせることができます。
集中型および分散型複合配置
集中型および分散型コール処理を複合的に配置しているマルチ サイト モデルでは、MPLS WAN はクラスタ間のコールに対して新しい展開を意味します。異なるクラスタに属している支店間にコールが発生した場合は、音声パスはその支店間で直接確立できるので、支店のクラスタから中央サイトへメディアを転送する必要はありません。したがって、コール アドミッション制御は各支店の WAN リンクに必要なだけです（図9-23 を参照）。
図9-23 クラスタ間トランク（ICT）によるマルチ クラスタ接続
単純集中配置で見られるように、メディアを各サイトで終端するデバイス（各クラスタに対する中央サイトを含む） は、適切に設定されているロケーションに指定されている必要があります。
クラスタ間トランクで重要なことは、これは単なるシグナリング デバイスであって、クラスタ間トランクのメディアを転送する役目をもたないということです。したがって、クラスタ間トランクのロケーションの指定は、<None>のままにしておきます。
この方式の配置では、クラスタ間のダイヤル プランの解決にゲートキーパーを使用することもできますが、コール アドミッション制御にはゲートキーパーを使用しないことをお勧めします。
特定のサイトに許されている帯域幅を消費してしまっている場合は、次の 2 つの方式を組み合せて、公衆網へ自動的にフェールオーバーすることができます。
• マルチ Cisco CallManager クラスタに対するコールには、ルート リストおよびルートグループで対応
• Cisco CallManager クラスタ内のコールには、Automated Alternate Routing（AAR）機能で対応（AAR の詳細については、「Automated Alternate Routing」を参照）
複合トポロジ
このドキュメントにおける「複合トポロジ」とは、この章でこれまでに説明した、どのトポロジ タイプにも単純化できないネットワーク トポロジです。
図9-24 の例に示すように、複合ネットワーク トポロジでは、フルメッシュの機能、ハブアンドスポークの機能、部分メッシュの機能、またはこれらのすべての組み合せを 1 つのネットワーク内で実現できます。
一般的に言うと、あらゆるトポロジをサポートできる唯一のコール アドミッション制御メカニズムは、RSVP です。RSVP は、ネットワーク トポロジとは完全に独立した、動的な分散型シグナリング プロトコルです。このため、ハブアンドスポークへと論理的に単純化できないトポロジで利用するのに最適です。
RSVP ベースのコール アドミッション制御サポートを Cisco IP Communications ネットワークに追加するには、「IP-to-IP ゲートウェイ」の項で説明しているように、中継ゾーン ゲートキーパーと Cisco IP-to-IP ゲートウェイを使用します。
ただし、IP-IP ゲートウェイ機能を大規模ネットワークのすべてのサイトに追加することは、不可能な場合もあります。（ネットワーク接続を変更するか、使用可能な帯域幅に基づいて仮定することで）ネットワークの特定の部分をハブアンドスポーク トポロジへと単純化できる場合には、Cisco CallManager ロケーションや Cisco IOS ゲートキーパーなどの「静的な」コール アドミッション制御メカニズムを、RSVP の提供する動的なコール アドミッション制御と同一ネットワーク内で組み合せることができます。
以降では、ハブアンドスポークへと単純化できない架空の大規模顧客ネットワークに基づいて、詳細なケース スタディを示します。この例では、次のコール アドミッション制御メカニズムを組み合せて、エンドツーエンドのソリューションを提供します。
ケース スタディ
図9-25 では、架空の大規模顧客ネットワークの概略的なトポロジを示しています。この顧客サイトは、3 つの主要リージョンに分かれています。南/北/中央アメリカ（AMER）、欧州/中東/アフリカ（EMEA）、およびアジア太平洋（AP）です。これらの各リージョンの内部では、ネットワーク トポロジは 3 層のハブアンドスポークです。リージョン ハブといくつかの国ハブがあり、それぞれは 1 つまたは 2 つの小さな下位サイトを保持していることがあります。コア ネットワークによって、3 つのリージョンが任意のネットワーク トポロジで相互接続され、どの 2 つの宛先間にも、等コストのパスが複数用意されています。
この複合トポロジは、各種のコール アドミッション制御メカニズムをどこに適用するか、およびどのように組み合せるかを示しています。ソリューション全体をわかりやすく説明するために、ここではネットワークの各部分を個別に分析していきます。
まず、AMER リージョンについて検討します。図9-25 に示すように、リージョン ハブに接続されている 2 つの国ハブがあります。Dallas にある US ハブ サイトと、Toronto にある CND ハブ サイトです。図9-26 では、ネットワークの US 部分にコール アドミッション制御を実装する方法を示しています。
図9-26 顧客ネットワークの最初の 2 レベルに対するコール アドミッション制御（米国）
Cisco IOS ゲートキーパーが、Dallas の US ハブ サイトに配置されています。このハブ サイトには、数多くの第 1 レベル スポーク サイト（ゲートキーパーごとに 100 まで）を接続できます。図9-26 の例では、第 1 レベル スポーク サイトは Los Angeles（LAX）と Boston（BOS）です。各サイトのローカル ゾーン（この例では、USHub、USWest、USEast）をゲートキーパー内に定義すると、第 1 レベル スポーク サイトと US ハブ サイトの間にあるリンクに対してコール アドミッション制御を実行できます。このためには、Cisco IOS ゲートキーパー コマンドの bandwidth interzone zone zone-name bandwidth-value を使用します。このコマンドによって、各ゾーンで発着信される音声コールとビデオ コールの使用する帯域幅が、設定した値を超えないことが保証されます。
この図にある第 1 レベル スポーク サイト（LAX と BOS）は、それぞれ Cisco CallManager クラスタをホストしています。Cisco CallManager は、独自にコール アドミッション制御メカニズム（ロケーション制御による）を使用しているため、数多くの第 2 レベル スポーク サイト（クラスタごとに 500 まで）をそれぞれの第 1 レベル スポーク サイトに追加することができます。この例では、各 Cisco CallManager クラスタがそれぞれ 2 つの追加サイトを制御しています。Los Angeles クラスタの San Francisco（SFO）と Seattle（SEA）、Boston クラスタの New York（JFK）と Washington D.C.（IAD）です。したがって、これらの第 2 レベル スポーク サイトとそれぞれの第 1 レベル サイト間にあるリンクの帯域幅は、Cisco CallManager ロケーションによって制御されます。
（注） ゲートキーパーに関しては、第 2 レベル スポーク サイトは「親」である第 1 レベル スポーク サイトと同じ Cisco CallManager クラスタによって制御されるため、第 1 レベル スポーク サイトと同じゾーンに属するものと見なされます。Cisco CallManager によって制御されないオンネット宛先に向かうコールが、いずれかの第 2 レベル スポーク サイトから発信された場合、そのコールは、「親」である第 1 レベル スポーク サイトと国ハブ サイト間にあるリンクを経由する必要があるため、この分析は適切です。
図9-27 では、カナダ（CND）サイトを示しています。このサイトは、ネットワークのこのレベルにコール アドミッション制御を実装する方法のもう 1 つの例です。
図9-27 顧客ネットワークの第 1 レベルに対するコール アドミッション制御（カナダ）
Toronto にあるカナダ ハブ サイトには、もう 1 つの Cisco IOS ゲートキーパーが配置され、多数のスポーク サイトがこのハブ サイトに接続されています。この例では、2 つのスポーク サイトが Vancouver と Montreal にあります。これらのスポーク サイトには、Cisco CallManager クラスタは含まれていませんが、音声ゲートウェイ、ビデオ エンドポイント、マルチポイント コントロール ユニット（MCU）、H.320 ビデオ ゲートウェイなど、H.323 ベースのさまざまなデバイスが含まれています。サイトごとに、ゲートキーパー内にローカル ゾーンが定義されています（この例では、CNDHub、CNDWest、CNDEast）。カナダ ハブ サイトとスポーク サイトの間にあるリンクの帯域幅も、Cisco IOS のゲートキーパー コマンド bandwidth interzone zone zone-name bandwidth-value を使用して制御することができます。このコマンドによって、各ゾーンで発着信される音声コールとビデオ コールの使用する帯域幅が、設定した値を超えないことが保証されます。
スポーク サイトにある H.323 デバイスは、コール アドミッション制御を実行できません。したがって、ここに第 2 レベルのスポーク サイトを追加することはできません。ただし、これらのどのデバイスも Cisco CallManager で制御できるため、Cisco CallManager クラスタを第 1 レベル スポーク サイトに追加して、これらの H.323 デバイスを複数の第 2 レベル スポーク サイトに分散させることは可能です。
また、同じゲートキーパーの制御する複数のサイト内で、Cisco CallManager スポーク サイトと H.323 スポーク サイトを混在させることはできます。
ここで、ネットワーク階層の 1 つ上のレベルについて考えます。図9-28 では、Chicago にある AMER リージョン ハブ サイトと、Dallas および Toronto にある 2 つの国ハブ サイト（米国とカナダ）の間でそれぞれ使用されているコール アドミッション制御メカニズムを示しています。
図9-28 顧客ネットワークの第 2 レベル（リージョン ハブ）に対するコール アドミッション制御
ネットワークのこの部分もハブアンドスポークですが、ここでは、コール アドミッション制御の実行に使用されるアプローチが、国ハブ サイトと第 1 レベル スポーク サイト間で使用されるものとは異なります。
これまでに説明したように、国ハブ サイトには Cisco IOS ゲートキーパーが含まれています。このゲートキーパーが、ローカル ゲートキーパー ゾーンと bandwidth interzone Cisco IOS コマンドを使用して、第 1 レベル スポーク サイトに向かう帯域幅を制御しています。AMER リージョン ハブ サイトには、ディレクトリ ゲートキーパーとして使用されるゲートキーパーが含まれています。このゲートキーパーの主な目的は、国ゲートキーパー間のコール ルーティングを処理することです。
国ハブ サイトとリージョン ハブ サイトの間にあるリンクの帯域幅使用を制御するには、国ハブ サイトにある 2 つのゲートキーパー上で、 bandwidth remote bandwidth-value Cisco IOS コマンドを使用します。このコマンドによって、すべてのローカル ゾーンとすべての非ローカル ゾーン間で発着信される音声コールとビデオ コールの使用する帯域幅が、設定した値を超えないことが保証されます。ローカル ゾーンに属していない宛先へのコールは、すべて国ハブ サイトとリージョン ハブ サイトの間にあるリンクを通過する必要があります。このため、 bandwidth remote コマンドを使用することで、実質上このリンクに対してコール アドミッション制御を実行できます。
図9-28 で、AMER リージョン ハブ サイトに中継ゾーン ゲートキーパーがあることにも注目してください。他のリージョン（AP や EMEA など）内の宛先へのコールを AMER 中継ゾーン ゲートキーパーにルーティングするために、ディレクトリ ゲートキーパーが設定されています（この設定は、図9-28 には示していません）。
次に、ネットワークのコア セクションについて考えます。このセクションは、3 つのリージョン ハブ サイトを接続しています。図9-29 と図9-30 では、コール ルーティングとコール アドミッション制御がコア ネットワークにわたってどのように実行されるかを示しています。
図9-29 中継ゾーン ゲートキーパーを使用した顧客ネットワークのコア部分でのコール ルーティング
図9-29 では、3 つのリージョン ハブ サイトそれぞれにある 3 つの中継ゾーン ゲートキーパーの設定の抜粋を示しています。各リージョンの中継ゾーン ゲートキーパーは、他の 2 つのリージョンが宛先または発信元となるコールが発生すると、コールに IP-to-IP ゲートウェイを挿入するように設定されています。
たとえば、AMER リージョンの中継ゾーン ゲートキーパーの設定では、次のゾーンが定義されています。
• AMER ディレクトリ ゲートキーパーに（つまり、AMER リージョン内のすべての宛先に）到達するためのリモート ゾーン AMER-DGK
• EMEA リージョン内の宛先に到達するためのリモート ゾーン EMEA-DGK
• AP リージョン内の宛先に到達するためのリモート ゾーン AP-DGK
EMEA-DGK リモート ゾーンと AP-DGK リモート ゾーンの定義では、ローカル ゾーン AMER-ViaGK が、これらの宛先に到達するための invia ゾーンおよび outvia ゾーンとして使用されることも指定しています。つまり、これらのリモート ゾーンが宛先または発信元となるコールが発生すると、AMER 中継ゾーン ゲートキーパーがコールに IP-to-IP ゲートウェイを挿入します。ローカル ゾーン AMER-ViaGK のゲートキーパーに登録されているすべての IP-to-IP ゲートウェイ リソースの中から、特定の IP-to-IP ゲートウェイ リソースが選択されます。
（注） IP-to-IP ゲートウェイをコールに挿入すると、コールは実質上 2 つのコール レッグに分割されます。この例では、IP-to-IP ゲートウェイが各リージョン ハブ サイトに挿入されるため、AMER リージョンのエンドポイントと EMEA リージョンのエンドポイント間のコールは、3 つのコール レッグで構成されることになります。最初のレッグは AMER エンドポイントから AMER IP-to-IP ゲートウェイまで、2 番目のレッグは AMER IP-to-IP ゲートウェイから EMEA IP-to-IP ゲートウェイの間、3 番目のレッグは EMEA IP-to-IP ゲートウェイと EMEA エンドポイントの間です。
図9-30 では、コア ネットワークで使用されるコール アドミッション制御メカニズムを示しています。
図9-30 顧客ネットワークのコア部分にわたる RSVP ベース コール アドミッション制御
コールがコア ネットワークを通過する必要がある場合は、中継ゾーン ゲートキーパーによって、コール フローに IP-to-IP ゲートウェイが挿入されます。各 IP-to-IP ゲートウェイも、コールのルーティングに中継ゾーン ゲートキーパーを使用し、コア ネットワークにわたって自身が発信または終端するコールに RSVP コール アドミッション制御を使用するように設定されています。RSVP 予約は単方向であるため、音声コールごとに、それぞれの方向に 1 つずつ、2 つの RSVP 予約が生成されます。
図9-30 では、AMER IP-to-IP ゲートウェイと EMEA IP-to-IP ゲートウェイ間のコールを示しています。コア ネットワークの 2 つのリージョン ハブの間には、複数のパスがあるものとします。取得したルートが非対称である場合は、2 つの RSVP 予約がそれぞれ別のパスに沿って流れていきます。ただし、個々の予約に注目すると、RSVP メッセージは常に同じパスに沿って流れます。これは、RSVP ではリバース ホップバイホップ ルーティングを使用して予約を確立しているためです。RSVP によって、コア ネットワークで音声コールとビデオ コールの使用する帯域幅が、各ルータ インターフェイス上で設定されている値を超えないことが保証されます。
要約すると、エンドツーエンドのコール アドミッション制御は、ネットワークの各部分でそれぞれ別の手法を組み合せて達成されています。
図9-25 に示したネットワークについて説明すると、たとえば、米国の San Francisco と英国の Liverpool にある 2 つの IP Phone 間のコールでは、次のメカニズムが使用されます。
• San Francisco と Los Angeles 間にあるリンクでは、Cisco CallManager ロケーション
• Los Angeles と Dallas 間にあるリンクでは、Cisco IOS ゲートキーパーの bandwidth inter-zone コマンド
• Dallas と Chicago 間にあるリンクでは、Cisco IOS ゲートキーパーの bandwidth remote コマンド
• Chicago と Amsterdam（2 つのリージョン ハブ サイト）間では、RSVP
• Amsterdam と London（英国の国ハブ サイト）間では、Cisco IOS ゲートキーパーの bandwidth remote コマンド
• London と Manchester（英国のハブ サイト）間では、Cisco IOS ゲートキーパーの bandwidth inter-zone コマンド
フィードバック