Cisco テクニカル ソリューション シリーズ：IP テレフォニー ソリューション ガイド
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月13日
章のタイトル： IP テレフォニー ネットワークの計画
IP テレフォニー ネットワークの計画
この章の構成
関連情報
•
Cisco IP テレフォニー ネットワーク デザイン ガイド
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/ipts/citndg/index.html
• Westbay Engineers Limited のホーム ページ
• Cisco IP Telephony Power Protection Page
http://www.cisco.com/warp/public/779/largeent/avvid/solutions/powerpro.html
既存のデータ インフラストラクチャの評価と文書化
各企業、組織では、IP テレフォニー ソリューションのアップグレード要件を決定するために、既存のデータ インフラストラクチャを評価する必要があります。集中環境に必要な追加の帯域幅、一貫したパフォーマンス、またはより高いアベイラビリティを確保するためのインフラストラクチャの提供が必要な場合があります。ここでは、LAN と WAN の両方の要件について説明します。
以下の項目について、既存のデータ インフラストラクチャを文書化し、評価する必要があります。
上記の項目には、ネットワーク マップ、デバイス インベントリ情報、およびネットワーク ベースラインの情報が必要です。これらの項目を分析することにより、IP テレフォニー、および基本的なネットワークのアベイラビリティ、パフォーマンス、および機能の要件をサポートするのに必要な、データ ネットワークのアップグレード要件を理解できます。
音声パフォーマンスの要件を評価するには、デバイス インベントリ、ネットワーク設計、およびベースライン情報を確認してください。リンクとデバイスには、追加の音声トラフィックに十分なキャパシティが必要です。リンクは、ピーク時すなわち混雑時の使用率に合わせてアップグレードが必要な場合があります。また、ターゲット デバイスは、高い CPU 使用率、高いバックプレーン使用率、高いメモリ使用率、キュー除去、またはバッファ ミスがあるときは、追加の検査とアップグレードが必要です。平常時のピーク使用率の特性は、音声品質の潜在的な問題を判別する際に重要です。
IP テレフォニー ネットワークのアベイラビリティ要件を評価するには、ネットワーク トポロジ、機能、およびプロトコルの実装を確認してください。IP テレフォニーに推奨されるアベイラビリティの目標を、現在のネットワーク設計（または新しい設計）で達成できるように、ネットワークの冗長性機能を再確認してください。
ネットワークの現在の機能を評価するには、シャーシ、モジュール、およびソフトウェア インベントリなどのデバイスの特性を評価します。この評価は、既存の環境における IP テレフォニー機能を判別する際に役立ちます。
また、ネットワークが全体的なキャパシティ要件を満たすこと、および既存のネットワークとアプリケーションの要件に影響がないことを確認するために、全体的なネットワークのキャパシティと影響も評価する必要があります。IP テレフォニー要件からの影響について、ネットワーク ベースラインを評価する必要があります。IP テレフォニーと既存ネットワークの両方の要件を満たすために、CPU、メモリ、帯域幅、または機能の追加が必要な場合があります。
（注） シスコでは、推奨ベースライン情報を提供する、IP テレフォニー準備状態監査を提供できます。
LAN/キャンパス環境
次の 4 つの IP テレフォニー配置モデルを伴うすべての LAN 環境に対して、LAN/キャンパス分析をお勧めします。
LAN/キャンパス インフラストラクチャ分析により、IP テレフォニーの音声品質とアベイラビリティに影響を与える、インフラストラクチャと帯域幅の問題が判別されます。LAN/キャンパス インフラストラクチャの分析には、次の情報が必要です。
• TFTP サーバ、DNS サーバ、DHCP サーバ、ファイアウォール、NAT（Network Address Translation）ゲートウェイ、および PAT（Port Address Translation）ゲートウェイのロケーション
• ゲートウェイと CallManager クラスタのロケーション候補
• IP ルーティング、スパニングツリー、VTP、IPX、および IBM プロトコルを含むプロトコル実装
LAN/キャンパス トポロジ
LAN/キャンパス インフラストラクチャは、通常、アクセス、ディストリビューション、およびコアの階層モデルを使用して構築します。これらの層の内 1 つまたは 2 つは、より小さい複数の LAN/キャンパス環境に分けられる場合があります。しかし、一般に、ディストリビューションとコアの標準構成を備えた、標準の配置モデルを使用します。『Campus Network Design』を参照して、ハイ アベイラビリティを備えたキャンパス設計に対する推奨事項を確認してください。この資料は、次の Web サイトから入手できます。
http://www.cisco.com/warp/public/779/largeent/design/campus_index.html
のような、層、デバイス、メディア、およびポート速度を示す簡単な図を作成する必要があります。このトポロジ マップは、TFTP サーバ、DNS サーバ、DHCP サーバ、ファイアウォール、およびゲートウェイの位置も示す必要があります。
次の LAN/キャンパス トポロジの項目を確認してください。
• バッファ、メモリ、CPU、およびキュー数を含む、パフォーマンスに影響を与える可能性があるリソース項目
• ユーザとスイッチ間のデスクトップ、および電話上の QoS
• トラフィック、IP サブネット、および機能の増加に伴うネットワークのスケーラビリティ
IP アドレッシング計画
次の IP アドレッシング計画と実装の特性を確認してください。
• キャンパスに使用する平均ユーザ IP サブネット サイズ
• DHCP サーバ プラン（固定アドレッシングと可変アドレッシング）
サーバとゲートウェイのロケーション
実装の前に、サーバとゲートウェイのロケーション（またはロケーションの候補）を考慮し、できるだけ LAN インフラストラクチャの計画段階でそれらのロケーションを特定してください。LAN インフラストラクチャ全体で、また複数のサイトに対して、一貫したサービスのアベイラビリティを確保するために、その他の項目は後で確認します。次の項目について、ゲートウェイとサーバのネットワーク ロケーションを特定する必要があります。
プロトコルの実装
IP テレフォニーのスケーラビリティ、および IP テレフォニーのアベイラビリティ項目、または追加のプロトコル サービス項目を判別するには、全体的なプロトコルの使用を確認してください。プロトコルの実装分析のために、次の項目を確認します。
• プロトコル、要約方式、NBMA（non-broadcast media access）設定、およびルーティング プロトコルの保護を含む IP ルーティング
• ドメイン サイズ、ルート指定、uplink fast、backbone fast、およびデフォルト ゲートウェイに関連した優先順位を含むスパニングツリー設定
• IPX、DLSW、または設定とリソースの使用状況を含む、その他の必須プロトコル サービス
デバイスの分析
IP テレフォニーの配置に関連したハードウェアとソフトウェアの項目を特定するために、既存のネットワーク デバイスを分析してください。多くのデバイスには、適切なコントロール プレーン リソース、インターフェイス帯域幅、QoS 機能、または電源管理機能がない場合があります。重要なデバイス属性は、次のとおりです。
ネットワーク ベースライン
IP テレフォニーのキャパシティ計画に、既存のキャンパス、または LAN インフラストラクチャのネットワーク ベースラインを使用できます。これは、音声品質の項目、および既存環境への影響を判別するのに役立ちます。ベースラインの一部として、次の特性を測定してください。
• 平均のリンク使用率（キャパシティ計画には、ピーク時間平均が望ましい）
• ピーク時のリンク使用率（5 分以下の平均インターバルが望ましい）
• 平均と最大の音声コール応答時間（IP テレフォニー実装前）
多くの個人やサポート機関は、上記の測定ベースライン項目に対して異なる許容可能しきい値を推奨しています。IP テレフォニーには、一貫したパフォーマンスと品質が必要であることに留意してください。したがって、すべての領域において、安全な推奨しきい値以下でなければなりません。しきい値には、次の一般的なガイドラインを使用してください。
• CPU ：一部のトラフィック処理要件に加えて、すべてのバックグラウンド処理に対する要件。バックグラウンド処理には、ルート更新、キープアライブ、ネットワーク管理、およびネットワークを安定して稼働させておくためのその他の重要なプロセスが含まれます。ルート コンバージェンスやリンク フラッピングなどの、負荷が大きいネットワーク時間には、かなりの CPU がネットワークを安定状態を保つために使用されます。負荷状態では相当量の CPU が使用されるので、一般的には、ピーク CPU 使用率 50%、および平均 CPU 使用率 30% をお勧めします。
• メモリ ： CPU のように、バックグラウンド処理とトラフィック処理にメイン メモリが使用されます。さらに CPU と同様、リンク フラップ状態、ルーティング変更、およびキャッシュ変更時に、相当量のメモリが処理に使用されます。メモリ所要量が大幅に変わるので、一般的には、ピーク使用率 50%、および平均使用率 30% です。
• バックプレーン使用率 ：ポートの速度と密度が、使用可能なバックプレーン能力より高い場合、一部のデバイスでは重大な問題になります。また、50% を超えるバックプレーン使用率は、すべてのダウンストリーム帯域幅の合計よりも帯域幅が少ないトランクに対する、ポート キューイングまたはトラフィックのドロップを示すことがあります。
• リンク使用率 ：VoIP パフォーマンスとジッタの要件があるので、IP テレフォニー配置には非常に重要です。まず、ピーク使用率の SNMP しきい値が、5 分間隔で実行されることに注意してください。一般的な目安として、5 分間の平均に対するピーク使用率の真の指標値を決定するには、5 分間の値より 40%、帯域幅使用率を増やしてください。ピーク特性をもつトラフィックが、1 時間より短い間隔で発生する場合、平均のリンク使用率は、時間が経つと無意味になる可能性もあります。通信事業者は、「混雑時」のトラフィックを考慮します。この混雑時の使用率を使用してキャパシティ計画を実施する場合、ネットワーク マネージャは、音声とデータの両方の要件を一貫して満たすことができます。
レベル II とレベル III の QoS 機能は、ある程度まで、帯域幅ヘッドルームの必要性を最小限に抑えるのに役立ちます。しかし音声は、かなりのボリュームをネットワークに追加するので、データ トラフィック用の帯域幅が不足しないように注意が必要です。ネットワーク設計者は、重大な輻輳の問題を最小限に抑えたり、解消するために、コアに対して使用可能な帯域幅を増やす傾向があります。したがって、50% を超えるピーク使用率、および 30% を超える平均使用率をもつ、すべてのコア ネットワーク リンクには注意が必要です。VoIP は、通常、さらに高い使用率であっても機能しますが、重要な音声トラフィックに最初に影響を与える、断続的な帯域幅の問題が起きる可能性が高くなります。
• キュー数 ：リンクの輻輳を示します。トラフィック量を検出する任意の送信キューは、トラフィックが待機中であることを示します。これは、音声のジッタや遅延に直接影響を与え、リンク使用率が推奨ピーク値を超えていることを示します。
• バッファ障害 ：デバイスにおける制御処理が一時的に実行できないことを示します。全体的なネットワークの稼働状況の観点から、調べる必要があります。一部のバッファ障害項目は、VoIP 品質に影響を与える可能性があり、調査が必要です。
WAN 環境
分散型コール処理を使用するマルチサイト WAN、および集中型コール処理を使用するマルチサイト IP WAN を構成する場合は、WAN インフラストラクチャ分析をお勧めします。WAN 分析により、IP テレフォニーの品質と信頼性に影響を与える、インフラストラクチャと帯域幅の項目が決まります。WAN 環境の分析には、次の情報が必要です。
• ソフトウェア バージョン、モジュール、ポート、速度、およびインターフェイスを含むデバイス分析
（注） ゲートウェイのロケーション、IP アドレッシング計画、およびプロトコル実装については、「LAN/キャンパス環境」を参照してください。IP テレフォニーをサポートするすべての WAN サイトに対して、なんらかの LAN 分析をお勧めします。
WAN トポロジ
WAN トポロジ インフラストラクチャは、通常、ハブアンドスポーク モデル、メッシュ マルチサイト モデル、またはこの両方の組み合せを使用して構築します。IP テレフォニー サイト、WAN デバイス、リモート LAN デバイス、インターフェイス タイプ、および帯域幅を示す ネットワーク 図を作成する必要があります。この図は、DNS サーバ、DHCP サーバ、ファイアウォール、ゲートウェイ、および CallManager のロケーションを示す必要があります。WAN トポロジの例については、 図 3-2 を参照してください。
• 帯域幅の冗長性と復元力を含む、WAN のアベイラビリティ
• IP テレフォニーの品質またはパフォーマンスに影響を与える可能性がある、WAN 設計またはトポロジの項目
（注） 『Cisco IP テレフォニー ネットワーク デザイン ガイド』では、現在、RSVP（リソース予約プロトコル）を使用したコール アドミッション制御が完全に使用可能になるまで、ハブアンドスポーク トポロジを使用することを推奨しています。この資料は、次の Web サイトから入手できます。
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/ipts/citndg/index.html
• トラフィック、IP サブネット、および機能の増加に伴う WAN スケーラビリティ
• 既存の QoS 要件（詳細については、 「LAN/WAN QoS の設計」 を参照）
サーバとゲートウェイのロケーション
実装の前に、WAN におけるサーバとゲートウェイのロケーション（またはロケーションの候補）を考慮し、できるだけ WAN インフラストラクチャの計画段階でそれらのロケーションを特定してください。次のゲートウェイとサーバのネットワーク ロケーションを特定してください。
WAN プロトコル
IP テレフォニーの品質に影響を与える項目、または追加の音声サービスによる影響を受ける項目について、WAN プロトコルを調べる必要があります。多くの場合、WAN には、IP テレフォニー トラフィックのサポートを改善するためにより一層の最適化が必要です。NBMA（non-broadcast multiaccess）環境も、プロトコル項目や、音声品質に影響を与える全体的な信頼性の影響を受けやすい場合があります。次の特定の項目を確認してください。
• WAN IP プロトコルの実装、およびプロトコルのオーバーヘッド
• ポート速度、認定情報レート、および予想パフォーマンスを含む Carrier Service 登録率
• 音声品質とパフォーマンスに影響を与える NBMA プロトコル項目
• IPX と SNA を含む、その他のプロトコル オーバーヘッド
WAN プロトコル項目の確認後、次の項目を分析してください。
既存の QoS 要件
既存の WAN QoS 要件を評価して、Voice QoS 要件との両立性を判別する必要があります。アプリケーションのパフォーマンス、バースト要件、およびバッチ要件を含む、アプリケーションとパフォーマンスの要件を特定する必要があります。次の項目を調べてください。
デバイスの分析
ネットワーク内の既存のネットワーク デバイスを分析すると、IP テレフォニーの配置に関連したハードウェアとソフトウェアの項目を特定できます。QoS 要件の両立性を判別するには、ソフトウェアのバージョンが重要です。また、この情報を使用すると、ネットワークの潜在的なアベイラビリティを判別するために、ネットワーク信頼性パス分析を作成することもできます。重要なデバイス属性は、次のとおりです。
WAN ベースライン
IP テレフォニーのキャパシティ計画に、既存の WAN および WAN サイト インフラストラクチャの WAN ベースラインを使用できます。これは、音声品質の項目、および既存環境への影響を判別するのに役立ちます。ベースラインの一部として、次の特性を測定してください。
• 平均のリンク使用率（キャパシティ計画には、ピーク時間平均が望ましい）
• ピーク時のリンク使用率（5 分以下の平均インターバルが望ましい）
• 平均と最大の音声コール応答時間（IP テレフォニー実装前）
これらの特性の測定に対する各ガイドラインは、 「ネットワーク ベースライン」 を参照してください。
既存の通信インフラストラクチャの評価と文書化
IP テレフォニーの要件を判別するために、既存の通信インフラストラクチャを評価する必要があります。適切な配置モデルを判別するために、VoIP テクノロジーを実装するすべてのサイトに対してこの分析を実行してください。IP テレフォニーでは、次の配置モデルをサポートしています。
• 集中型コール処理を使用する分散 IP テレフォニー サイト
• 分散型コール処理を使用する分散 IP テレフォニー サイト
通信インフラストラクチャの分析では、次の項目を含む、既存の通信環境で使用される製品、サービス、および機能を調べます。
この分析は、IP テレフォニーの設計基準を決定するのに役立ちます。次の項目を調べる必要があります。
既存の通信トポロジの調査
既存の通信トポロジには、PBX システム、キー システム、および音声メール サーバの各ロケーション、およびインターネットワーキング接続が含まれます。このトポロジには、これらのデバイスのロケーション、および接続に使用される、システム間のトランクが含まれなければなりません。トランキングには、サイト間トランク、PSTN トランク、および音声メール トランクが含まれることがあります。ここでは、次の既存の通信トポロジ項目について確認します。
PBX システム、キー システム、および音声メール システムを示す通信トポロジの例については、 図 3-3 を参照してください。
PBX とキー システムの調査
現在の音声機能を理解するには、PBX とキー システムの情報が必要です。次の情報は、必要な機能、および PBX と IP テレフォニー間の接続要件を判別するのに役立ちます。
• IP テレフォニーが干渉する可能性がある PBX の数量とロケーション
• 現在配置されているソフトウェア機能。この機能には、コールのセットアップ、会議、コール転送、コール保留、コール パーク、発信者番号識別、および発信者名が含まれることがあります。
• PBX ごとの既存のアナログ接続の数、および配置後も引き続き使用する予定の 3 つの接続
音声メール システムの調査
IP テレフォニーの両立性と機能を判別するには、次の情報が必要です。
• 音声メール システムのカードのハードウェア モデルとリビジョン
• 音声メール システムと一緒に現在配置されているソフトウェア機能リスト
• 音声メール システムに SMDI インターフェイスがあるかどうか
音声トランキングの調査
IP テレフォニーのゲートウェイ要件を決定するには、既存の音声トランキングを使用します。一般に、音声メール用のトランク、PSTN 接続、およびサイト間トランキング要件を特定する必要があります。さらに、起こり得るキャパシティ項目に対して、既存のブロッキング係数も定義します。IP テレフォニー トランキングに対して、1 パーセントのブロッキング係数をお勧めします。各種トランキング アプリケーションの混雑時のトランキングを理解するには、トラフィック分析を実行できます。その後、アーラン B カルキュレータ（ http://www.erlang.com ）を使用して、新しいトランキング要件を判別できます。PBX ベンダーでは、通常、サポート サービスとして混雑時の統計を提供しています。全体的なトランキングを確認するには、 表 3-1 を使用してください。
|
またはアナログ |
|
|
|
|
|---|---|---|---|---|
また、ゲートウェイ トランクの計画と設定には、次の表も使用できます。場合によっては、これらのトランク分界点ロケーションを移動して、IP テレフォニー機器と共存させることもできます。さらに、物理的設計資料で使用するために、WAN キャリア サービスに対するサポート責任を文書化する必要があります。
|
|
||||||||
|---|---|---|---|---|---|---|---|---|
|
|
||||||||
|---|---|---|---|---|---|---|---|---|
（注） DID を発注する際には、デバイス（電話機、仮想電話機、および NetMeeting などの H.323 デバイス）数以上の電話（DID）番号のブロックを取得してください。
|
|
||||||
|---|---|---|---|---|---|---|
ISDN PRI は、一般的な PBX WAN トランク タイプです。次のパラメータは、通常、T-1 または E-1 PRI スパンのプロビジョニング時に使用されます。
• インターフェイス: ISDN PRI（一次群速度インターフェイス）
• フレーム形式: ESF（Extended Super Frame）
• D チャネル: 24 番目のチャネル、または Euro PRI の場合は 16 番目のチャネル
ISDN PRI のプロビジョニングでは、スイッチ タイプがレイヤ 3 プロトコル用に設定される必要もあります。PRI のプロビジョニングには、次の 4 つのファミリーのスイッチ タイプ プロトコルがあります。
• AT&T、4ESS、5ESS、NII Called NI2（National Protocols）
• DMS100 および DMS 250（National Protocols）
既知の PBX システムの場合、一般的なスイッチ タイプとレイヤ 3 プロトコルには、次のスイッチ タイプが含まれます。
• Nortel（Meridian）： 5ESS Custom（注: ゲートウェイは NETWORK に設定されなければなりません）
• Lucent（Definity）： 4ESS または 5ESS
• Madge（Teleos）BOX: 5ESS Custom
IXC および中継キャリアの場合、一般的なスイッチ タイプとレイヤ 3 プロトコルには、次のものが含まれます。
• ローカル CO スイッチに接続する場合は、次のものを使用してください。
サイトごとの電話機数と電話機能
CallManager プラットフォームを適切な規模に調整するには、現在サポートされている電話機の数が必要です。VoIP に変換される電話機、および緊急時と FAX のバックアップ用の数台のアナログ電話機を特定する必要があります。また、次に示す必要な電話機能も理解しておく必要があります。
既存のダイヤル プランの調査
IP テレフォニーへの移行に必要なコール ルーティング、短縮ダイヤリング、およびルート グループ機能を理解するには、既存のダイヤル プラン アーキテクチャを調べてください。コール ルーティングは、PSTN またはオフネット アクセスに使用されます。コール ルーティングに関連した機能は、次のとおりです。
• 個々のグループまたは番号のオフネット アクセスを制限する、コール ブロッキング
自動コール分散により、1 つの公開番号からのコールに、複数のエージェントが応答できるようになります。コール ブロッキングは、0990 番の有料番号などの特定の番号へのアクセスや、建物のロビーにある電話機からの長距離 PSTN アクセスを制限するのに使用します。短縮ダイヤリングは、内線コールに必要な桁数を減らすのに使用します。多くの場合、ローカル内線ダイヤルは、4 桁の番号に短縮されています。
• 既存のダイヤル プランを使用するか、複数のサイト間に分散されるダイヤル プランを使用するか。
• PBX 用に予約されている番号の範囲があるか。ある場合は、その番号の範囲は何か。
• アナログ電話機用に予約されている番号の範囲があるか。ある場合は、その番号の範囲は何か。
既存のダイヤル プランを文書化するには、次の表を使用してください。
|
|
|
|
|
|||
|---|---|---|---|---|---|---|
• ローカル PSTN アクセスの他に、セルラー ネットワークが配置に含まれるか。
• PSTN へのローカル オフネット コールのルート指定には、各サイトでどのアクセス コードが使用されるか。
これらの質問に答えるために、サイトごとのすべてのローカル PSTN コール パターン、およびコール パターンごとのルート オプション（このパターンをルート指定するか、ブロックするか）を、次の表形式でリストできます。
（注） 北米以外のダイヤル プラン区域には、ローカル PSTN アクセス用に複数のダイヤル パターンが存在する場合があります。
|
|
ダイヤル パターン |
アクセス コード |
|
|
|---|---|---|---|---|
• PSTN の他に、セルラー ネットワークが配置に含まれるか。
• IP テレフォニー配置サイト内に、長距離 PSTN コールのトール バイパスを配置する（つまり、コールが PSTN ではなく、VoIP を介するように、宛先都市内の PSTN ゲートウェイに、長距離 PSTN コールをルート指定する）ことが必要か。または、すべての長距離オフネット コールを PSTN にルート指定することだけが必要か。
これらの質問に答えるために、すべてのアクセス コード、各都市の長距離コール パターン（セルラー ネット（ある場合）、および国内コールと国際コールの両方のパターンを含む）、およびコール パターンごとのルート オプション（このパターンをルート指定するか、ブロックするか）を、次の表形式でリストできます。
|
|
|
|
アクセス コード |
|
|
|---|---|---|---|---|---|
また、次のような、特殊なコール ルーティングとコール分散の要件をすべてリストする必要があります。
• ACD（Automatic Call Distribution）
サイトごとに、PSTN ユーザが IP Phone ユーザに到達するための、着信番号をリストしてください。
|
|
|
|
|
|---|---|---|---|
FAX の要件
CallManager バージョン 3.0.1 以降では、所定のゲートウェイ上での FAX リレー、およびモデム パススルーをサポートします。FAX マシン、ロケーション、および FAX 番号を特定して、FAX リレー要件とモデム パススルー要件を指定する必要があります。モデム パススルー ソリューション用のモデムの特定も必要な場合があります。次の表を使用して、FAX マシン、モデム、およびこの領域での IP テレフォニー ベース VoIP ソリューションを設計するのに必要な情報を特定することができます。
|
|
|
|
|
|---|---|---|---|
既存の電源またはケーブル配線インフラストラクチャの評価と文書化
適切な IP テレフォニー配置とハイ アベイラビリティ音声ソリューションのもう 1 つの特徴は、電源とケーブル配線のインフラストラクチャです。一般に、従来の音声環境は、UPS 電源バックアップと、PBX で稼働する電話機を使用した、入念に計画された電源システムとケーブル配線システムを備えています。このソリューションは、より可用性が高い音声の実装を行うのに役立ちます。同様のハイ アベイラビリティ ソリューションを提供するには、データ装置用に可用性が高いケーブル配線と電源のインフラストラクチャを周到に計画する必要があります。
UPS 電源がない場合、電源だけが原因で、約 1.66 時間使用不可になることが予想されます。詳細については、次の APC Web サイトを参照してください。
http://www.apcc.com/go/machine/cisco/
不完全なインストール方法、パッチ コードの管理、非階層構造のインストール、および非標準ベースのインストールにより、ケーブル配線インフラストラクチャに関する事項も、アベイラビリティの問題を起こすことがあります。アベイラビリティ要件を満たすことを確認するために、ケーブル配線インフラストラクチャを理解し、可能なアップグレードを計画する必要があります。
最初のステップは、既存のケーブル配線と電源のインフラストラクチャを調べて、電源とケーブル配線のインフラストラクチャが、IP テレフォニー要件に対応できることを確認することです。電源の詳細については、次のロケーションを参照してください。
• Cisco IP Telephony Voice and Video Solutions
http://www.cisco.com/warp/public/779/largeent/avvid/solutions/powerpro.html
現在のインフラストラクチャの完全性を判別するのに役立つ基本的な質問事項は、次のとおりです。
• 屋内配線が EIA/TIA-568A に準拠しているか。Technical Services Bulletin 40（TSB-40）では、カテゴリ 5 の配線システムの設置を指定しています。TSB-67 では、準拠性を確認するためのテスト基準を指定しています。配線が準拠していない場合は、テストと可能なアップグレードについて、配線請負業者に相談してください。
• 機器の設置場所が、電源と接地の影響を受けやすい機器に対する電気工事規定に準拠しているか。準拠していない場合、または準拠しているかどうかが不明な場合は、電源の監査について APCC に相談し、設置環境の準拠性とアベイラビリティの特性を判断してください。
• 機器の設置場所が、接地と電源の影響を受けやすい機器の推奨手順について、さらに厳しい IEEE 1100-1992 標準に準拠しているか。準拠していない場合、または準拠しているかどうかが不明な場合は、電源の監査について APCC に相談し、設置環境の準拠性とアベイラビリティの特性を判断してください。
• 回路分岐、実施できる電源検査、冗長電源回路の多様性、および回路識別を含む、データ センターと配線室の電源用の標準があるか。
• データ センター、配線室、電話システム、およびインターネットワーキング デバイスに、UPS 電源および発電機の電源を使用しているか。
• SNMP 管理を行うプロセス、または定期的にバックアップ電源を検証し、テストするプロセスがあるか。
• 十分な電源、順調なインストール、および適切な電源バックアップを確認するために、インストール前に、IP テレフォニー依存機器の消費電力、プラグ タイプ、および発熱量を判断するか。
詳細については、次の電力サイジング ガイドを参照してください。
http://www.cisco.com/warp/public/779/largeent/avvid/solutions/powerpro.html
データ センターの電源要件
データ センター環境では、CallManager とゲートウェイ デバイスが使用されます。使用される可能性のある IP テレフォニー機器に使用可能な主電源、UPS 電源、電源プラグの互換性、および熱放散について、既存のデータ センターを評価してください。次の表を使用すると、全体的な IP テレフォニーの電源要件、およびデータ センターの電源と冷却要件を決定するのに役立ちます。次の APC Web サイトで、消費電力（ワット数）、動作電圧、およびプラグ タイプを調べることができます。
http://www.apcc.com/template/size/apc/cisco_int/index.cfm
Cisco IP テレフォニーのデータ シートで、熱放散、線間電圧、およびその他の環境情報を見付けることができます。これらの資料は、次のロケーションにあります。
http://www.cisco.com/en/US/products/hw/phones/ps379/products_data_sheets_list.html
|
|
（ワット数） |
|
|
|
|
|---|---|---|---|---|---|
配線室の電源
配線室の電源には、Cisco Inline Power™ を使用し、配線室 UPS システムを追加するので、慎重な計画が必要です。慎重な計画によって、端末電話機のハイ アベイラビリティが確保されます。インライン パワーには、電源パッチパネル用のスペースを用意する必要があります。電源、UPS、および冷却の要件を指定するために、データ センター用のワークシートと同じような、配線室用のワークシートに記入する必要があります。
|
|
（ワット数） |
|
|
|
|
|---|---|---|---|---|---|
IP テレフォニーのアベイラビリティ要件
目標とするアベイラビリティ要件を基準にして、IP テレフォニーのネットワーク、インフラストラクチャ、およびサポート サービスを設計する必要があります。アベイラビリティの計画は、次の理由で便利です。
• 音声またはデータ サービス用の全体的な SLA として、アベイラビリティを使用できる。
• ダウンタイムのコスト、可能性分析、および単純な ROI（投資回収率）計算に基づいて、最善のアベイラビリティ レベルを決定するために、アベイラビリティのモデルまたは測定を使用できる。
• サービスのレベルを向上させるために、品質アベイラビリティ改善プロセスでアベイラビリティの測定値を使用できる。
シスコシステムズでは、アベイラビリティを、次の 6 つの主要要素の組み合せと見なしています。
これらの要素のそれぞれは、ネットワークの異なる部分に、異なる方法で影響を与えることがあります。したがって、ネットワークの別々の領域に対してアベイラビリティの要件とモデルを定義すると便利です。これらの領域は一般に、LAN、WAN、データ センター、およびネットワーク コアです。シスコは現在、ビジネス要件、および企業、組織が経験するダウンタイムのコストに対応した、一般的なアベイラビリティ分類をもっています。この一般的な分類は次のとおりです。
• 高信頼性ネットワーク：アベイラビリティの目標は、約 99.5% です（教育および行政）。
• ハイ アベイラビリティ ネットワーク：アベイラビリティの目標は 99.99% です（ハイテク産業、製造業、およびサービス業）。
• ノンストップ ネットワーク：アベイラビリティの目標は、通常 99.999% 以上です（金融または医療環境）。
信頼性のブロック図は、企業、組織のモデル アベイラビリティ要件の検討に役立ちます。各アベイラビリティ要素は、他の要素とは無関係であるので、これらの要素を掛け合わせて最終結果を得ます。この結果、1 つの領域が弱い場合、全体的なアベイラビリティは、さらに厳しい影響を受けます。次の例を参照してください。
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|
たとえば、ハードウェアの信頼性は、通常、mean time between failure（MTBF;平均故障間隔）分析を、mean time to repair（MTTR;平均修理時間）と組み合わせて使用して、理論的なハードウェア信頼性モデルを作成します。それ以外の場合、正確なモデル化は可能ではありませんが、「ベスト プラクティス」の一般的な総合特性が特定されています。次の項では、アベイラビリティ要素ごとに、3 つのアベイラビリティ タイプのそれぞれの中で、ベスト プラクティスに関する詳細を説明します。
ハードウェアの信頼性
ネットワーク内のハードウェアの信頼性は、提供されるネットワーク トポロジ、冗長性の程度、および損傷したハードウェアの修理に要する予想時間を使用して計算する必要があります。各デバイス（およびデバイス モジュール）の MTBF、およびハードウェア交換の MTTR を使用して、ハードウェアの信頼性を計算できます。IP テレフォニー ソリューションのハードウェアの信頼性には、IP Phoneと CallManager との間のパス、および IP Phoneと着信側との間のパスも含まれます。
シスコのアカウント チームは、予想 MTTR を使用する正確なハードウェア モデルを提供できます。アカウント チームは、さらにケースバイケースでパス分析を実行できるように、製造品質部門と連絡を取って、各デバイスとモジュールの MTBF を決定します。MTBF 情報は、コンポーネントの品質に対する BellCore 標準に基づきます。BellCore は、シスコのモジュールとシャーシの製造に使用される、500,000 個以上のコンポーネントの予想耐用年数を特定しています。
MTTR は、全体的なハードウェアの信頼性において重要です。標準の Cisco SmartNET ハードウェア交換を使用する企業、組織では、ハードウェア交換に平均 24～48 時間が予想されます。これにより、ソリューション全体のアベイラビリティが低下します。
次の表は、ネットワークのさまざまな領域において、交換時間、およびハードウェア冗長性の程度が与えられたときに、IP テレフォニー ソリューションのアベイラビリティの特性を検討するのに役立ちます。
|
|
|
|
|
|---|---|---|---|
ソフトウェアの信頼性
ソフトウェアの品質は主にベンダーの責任であるので、企業、組織は簡単にソフトウェアの信頼性をコントロールできません。シスコは、99.999% 以上の信頼性で高品質のソフトウェアだけをリリースするように努めています。しかし、多くの場合、早期配置のソフトウェアや早期リリースのソフトウェアでは、予期しない、テスト済みでないトラフィック パターンや、負荷関連の問題があるので、この目標に達しません。
Cisco IOS にも、予想される信頼性に対応したソフトウェアの分類があります。これらの分類には、GD（一般配置）、LD（限定配置）、および ED（早期配置）があります。さらに IOS は、暫定的なリリースや、実験的なリリースではテストされていない場合もあります。GD コードは、信頼性が高いと見なされ、一般に 99.999% のアベイラビリティを示すトラック レコードが実証されています。
企業、組織の一部のプロセスは、企業、組織内のソフトウェアの信頼性とアベイラビリティを向上させるのに役立ちます。1 つは、ソフトウェア バージョンのコントロールです。この手法では、立証済みのトラック レコードを持ち、信頼性を提供するためにネットワーク内でテストまたは試用されている、ごくわずかのバージョンのソフトウェアだけを保持します。
もう 1 つのベスト プラクティスは、ソフトウェアのテストです。ソフトウェアのテストには、機能テスト、および既存の環境に対するソフトウェアの影響を判別するための「what-if」テストが含まれます。シスコが提供する、Network Verification Services（NVS）と呼ばれるテスト サービスは、ソフトウェア、ハードウェア、およびネットワーク設計を広くテストするのに役立ちます。NVS サービスの詳細については、『Network Verification Service Option』を参照してください。この資料は、次のロケーションにあります。
http://www.cisco.com/warp/public/cc/serv/mkt/sup/ent/nsa/welcome/nsan_ov.htm
NVS は現在、ANS または BES のお客様にしか提供されていません。これ以外のテスト ツールおよびモデリング ツールも使用可能です。これらのツールは、パケットの取り込み、トラフィックの生成、および遅延の挿入さえも行うことができます。配置の前に、製品と機能を十分にテストできる実験室を作成することが、特に重要です。よく知られているテスト デバイスは、SmarBits トラフィック ジェネレータです。この詳細については、次の Spirent Communications SmartBits Web サイトを参照してください。
http://www.netcomsystems.com/
またトポロジ、ソフトウェア バージョン、設定、および機能を含めて、全体的なネットワークの一貫性を管理するプロセスも必要です。ソフトウェア設定における一貫性があると、使用されるコードが少なくなり、問題が発生する可能性が減るので、常にアベイラビリティに貢献します。
表 3-12 は、さまざまなレベルで全体的なソフトウェアの信頼性に関わる要素を特定するのに役立ちます。
|
|
|
|
|---|---|---|
リンクおよびキャリアのアベイラビリティ
次の要素は、リンクおよびキャリアのアベイラビリティに貢献します。
• キャンパスのファイバ設置の品質、冗長性、および地理的な分散
• ローカル ループ キャリアの復元力、冗長性、および多様性
これらの要素の多くは、ローカル ループ キャリアと長距離キャリアの復元力、冗長性、および多様性を除き、企業、組織内でコントロール可能です。第三世界の国々やアジアの一部の地域では、一般に多くのキャリア インフラストラクチャには、復元力に制限があり、冗長性も多様性もほとんどありません。インフラストラクチャの修理には、数時間とか数分ではなく、数日を要する場合があります。先進諸国では、企業、組織は、多くの場合、パスの多様性、複数のキャリア、および全体的なハイ アベイラビリティを備えることができますが、それでも冗長構成に影響を与える障害が発生する可能性があります。これは、回線パス全体にわたる多様性や冗長性がないからです。多くの場合、完全な冗長性と多様性は、今でも選択できません。企業、組織は、ローカル ループ システムおよびキャリア インフラストラクチャ内で、ケーブル パスとシングル ポイント障害を理解して、起こりうるアベイラビリティの問題をすべて理解するように努める必要があります。
次の表は、3 つのアベイラビリティ レベルで、リンクおよびキャリアのインフラストラクチャ要件の特性を検討するのに役立ちます。
電源および環境
次の要素は、電源および環境に関連したアベイラビリティに影響を与えます。
• UPS と環境条件のモニタに使用されるネットワーク管理システム
次の要素は、電源および環境に関連したアベイラビリティの向上に寄与します。
• 機器と電源装置の冗長性のために回路のワット数アベイラビリティ、および回路の冗長性を確保する電源プロビジョニング プロセス
• UPS システム用の SNMP またはその他のリモート管理プロセス
• 落雷、洪水、地震、悪天候、竜巻、または吹雪、氷雨、雹が電源の信頼性に影響を与える可能性がある、機器の地理的なロケーション
• 安全管理、および接地管理のための NEC および IEEE の配線標準に対する、電源ケーブル インフラストラクチャの準拠
次の情報は、さまざまな機器タイプに対する 3 つのアベイラビリティ レベルでのアベイラビリティに関連し、APC 社（ http://www.apcc.com ）によって実行された調査に対応するものです。
|
|
ネットワーク |
|
|
|---|---|---|---|
• |
|||
• |
|||
• |
ネットワーク設計
ネットワーク設計のアベイラビリティと信頼性に貢献する要素には、次のものがあります。
• IP ルート集約をサポートする階層状 IP ルーティング インフラストラクチャ
• 一貫性のあるハードウェア、ソフトウェア、およびデバイスの設定
• ハイ アベイラビリティ、ハイ パフォーマンスのメディアおよびデバイス
• レベル II およびレベル III でのハイ アベイラビリティ コンバージェンス機能
• 低い音声遅延とジッタをサポートする、LAN/WAN における QoS 機能
• ネットワークの一貫性と、リスクが高い変更に対する変更検証を推進する、ネットワーク変更管理
• IP ルーティングを使用したスパニングツリーを最小限にするか、排除する
次の表は、定義された 3 つのアベイラビリティ レベルで必要な、基本的なネットワーク設計特性を示しています。
ユーザ エラーとプロセス
ユーザ エラーとプロセスは、非アベイラビリティの主な原因です。Gartner Group は、すべてのアベイラビリティ問題の約 40% が、ユーザ エラーとプロセスに関連していると断言しています。より高いレベルのアベイラビリティを実現するには、ネットワークを管理するためのより高いレベルの専門技術とプロセスが必要です。ネットワーク管理プロセスには、次の 4 つの目標があります。
• 一貫したバージョンと設定をもつ、一貫したモジュラで階層状のアーキテクチャ
これらの目標を実現するために、大企業では、ネットワークの計画、設計の実装、および稼働に関連した、十分に考察して定義されたプロセスが必要です。ネットワーク インフラストラクチャと IP テレフォニー ソリューションの障害、設定、アカウンティング、パフォーマンス、およびセキュリティに関して、アベイラビリティに影響を与えるプロセスには、人材、プロセス、および専門技術も適用する必要があります。
IP インフラストラクチャと IP テレフォニー ソリューションの管理に必要な専門技術には、次のものがあります。
• VoIP テクノロジー：H.323、VoIP の概念とプロトコル、RTP
• ネットワーク アーキテクチャ：TCP/IP、IP サブネット化、ルーティング プロトコル（EIGRP、OSPF、RIP、BGP を含む）
• サービス/周辺装置：DNS、DHCP、TFTP、WEB サーバ、QoS
• アクセス：シグナリング（ISDN-PRI、EIR2、CCS および CAS）、FXS、FXO、およびグラウンド スタートまたはループ スタート
• IP テレフォニー：Windows 2000サーバ管理、Cisco IOS、コーデック（G.711、G.729 を含む）
• 一般的なスキル：プロジェクト管理、トラブルシューティング、セキュリティ、ネットワーク管理、サーバ管理
• 推奨される経験：Cisco VoIP 設定、Catalyst イーサネット スイッチ、Cisco IOS、QoS 技法、音声ダイヤル プランの知識と理解、従来の PBX の経験
ネットワーク インフラストラクチャと IP テレフォニー ソリューションに対して、次のプロセスをお勧めします。
• テストと検証を含む、十分に考察して定義されたアーキテクチャと設計プロセス
• 標準接続、ハードウェア デバイスまたはモジュール、設定、ソフトウェア バージョン、アウトオブバンド管理手法、およびネットワーク管理ツールの更新要件を定義する、ソリューション実装テンプレート
• 訓練要件、問題タイプ、問題の優先順位、解決の目標、エスカレーション パス、およびサポート担当責任者を指定する、新しいテクノロジー用の稼働サポート プラン
• 一貫性のある配置を保証する、一貫した実装プロセス。プロセスには、段階的実施、物理設計、資料と承認、現況資料、および段階ごとの実装ガイドが含まれます。
• リンク ダウンやデバイス ダウンの状態を検出する障害管理プロセス
• 重大な Syslog メッセージまたは例外条件を検出し、迅速な解決を提供する、障害管理プロセス
• 一貫性のある迅速なハードウェア交換を保証する、ハードウェア 予備品供給プラン
• ベースライン、傾向、例外条件の特定、および解決を提供する、パフォーマンスとキャパシティ計画のプロセス。さらにネットワークの変更によるキャパシティ、またはパフォーマンスの影響をテスト、または検証するための what-if 分析。
• すべての問題に対する Help Desk システム、およびチケット生成または説明能力
WAN 配置の計画
IP テレフォニーの WAN 配置には、十分な計画が必要です。ここでは、中央集中型コール処理を使用する IP テレフォニー WAN 配置に必要な付随事項とチェックリストを含む、詳細なプロセスを説明します。ここでは、WAN 接続の計画要件だけを説明します。一般的な中央集中型CallManager設計の手順、ゲートウェイ設計の手順、稼働計画の要件は含みません。WAN アナリストは、この項を参照して、音声要件を分析し、IP テレフォニーに適した WAN 環境を構築する必要があります。
このプロセスは、WAN 環境に対する WAN キャパシティ計画と現在のネットワーク分析、音声キャパシティ計画、アップグレード計画、配置、および検証を含みます。これらの分野ごとに、重要な成功要因を記述するチェックリストが、必要な計画の付随事項および参照項目と一緒に提示されています。
現在の WAN 環境についての情報の収集
WAN 配置を計画する最初のステップは、WAN および WAN デバイスから情報を収集することです。この情報を使用して、帯域幅とデバイス要件の決定後にギャップを分析してください。次のものを含む、複数のカテゴリの情報を収集します。
• 既存の WAN トポロジ。論理設計情報と帯域幅のサブスクリプション率を含みます。
• デバイス情報。ルータのモデル、メモリ、CPU、インターフェイス カード モジュールおよびバージョン、ならびにソフトウェア バージョンを含みます。
• リソースの使用率。ピーク使用率、および WAN リンク上の平均使用率（重要性が低い）を含みます。また、遅延とジッタの予定量を計算するための、WAN リンクごとの遅延、パケット損失、およびジッタの情報も含みます。
WAN トポロジ
トポロジ情報は、IP テレフォニーを実装する中央サイトとリモート サイトに必要です。また、（フレームリレーの中央ロケーションによくある）1 つの物理インターフェイス上で複数の共有回線が実装される場合、他のサイトのトポロジ情報も必要な場合があります。中央ロケーション、および IP Phoneの接続を実装するすべての WAN サイトを示す、正確なマップを作成してください。このトポロジ マップには、プライマリとバックアップの WAN 接続をサポートする WAN ルータ、サービス プロバイダー、インターフェイス、およびメディアがすべて含まれていなければなりません。また、メディア、エンドポイント、デバイス、デバイス インターフェイス、WAN プロバイダー、WAN サブスクリプション率、および冗長接続オプションなどの情報も含まれます。WAN サブスクリプション率は重要であり、ポート速度、認定情報レート、サービス クラス、および他の仮想回線とポートを共有する方法を含みます。次の表を使用して、必要な WAN トポロジ情報を収集してください。
|
ロケーション |
|
|
|
|
デバイス情報
デバイスのハードウェアとソフトウェアのアップグレード要件を評価する必要があります。IP テレフォニーに関連するデバイス項目には、ソフトウェア機能、ハードウェア サポート項目、CPU 能力、およびメモリが含まれます。次の表は、WAN ルータ機器に可能なアップグレードの必須情報を示しています。
（注） この章では、LAN 機器について評価していません。すべてのリモート IP Phoneと中央の IP テレフォニー リソースに対して、基本的なスイッチ型 10/100 接続を前提としています。
|
|
|
バージョン |
|
リソース使用率
リソース使用率には、帯域幅使用率、CPU 使用率、およびメモリ使用率のような項目が含まれ、IP テレフォニー配置の一番の問題は、帯域幅です。CPU とメモリも調べる必要があります。この情報を使用して、IP テレフォニー要件の見積もり後に全体のリソース要件を決定してください。
候補の IP テレフォニー WAN リンク上でベースラインを実行して、帯域幅使用率を決定します。上記の例において、リンクには、San Jose から Denver と、San Jose から Los Angels との間のフレームリレー リンク、San Jose と Los Angels 間の ATM リンク、および San Jose と Seattle 間の T-1 リンクが含まれます。ベースラインには、ピーク帯域幅使用率と混雑時間の使用率が含まれます。ピーク使用率は、ベースライン期間において、ピークの 5 分間の平均使用率です。混雑時間の使用率は、ベースライン期間におけるピーク 1 時間の使用率です。ベースライン期間は、2 ～ 7 日です。通常、1 週間以上をお勧めします。3 週間が理想的です。混雑時間の使用率が重要なのは、通信キャパシティ計画の時間枠を模倣し、混雑時の 1 時間当たりのピーク使用率要件を理解するのに役立つからです。平均使用率は、一般に、週末または深夜の使用率が含まれ、営業時間の使用率を誤って表示するので、あまり役立ちません。
複数の要素がベースラインの結果を誤って示す可能性があるので、ピーク リンク使用率の値を収集し、分析する際には、細部まで細心の注意を払ってください。まず、リンク使用率は、着信と発信の両方の使用率で表示する必要があります。WAN リンクは、一般に、着信と発信に同じ量のキャパシティが使用可能な全二重送信です。たとえば、SDLC リンク層プロトコルを使用するポイントツーポイント T-1 シリアル リンクは、各方向に、おおよそ 1.54 Mb /秒を提供します。一方、イーサネットは共有メディアです。一部のネットワーク管理ツールでは、これが問題になることがあります。これらのツールは、着信と発信のデルタ トラフィック量を平均化するか、単に 2 つの内どちらか大きい方の量として使用率を計算するからです。WAN リンク使用率は、方向ごとに提示されるのが最適です。ご使用のツールが方向ごとに使用率を提示しない場合、使用率の計算方法を調べてください。WAN リンク上では、大部分の使用率がリモート ロケーションへの発信で発生するのが普通です。これは、リモート オフィスに使用可能なサーバと情報のプライマリ ロケーションであるからです。音声トラフィックは両方向で影響を受けることに注意してください。重要なのは、特に、（フレームリレーによくあるように）さまざまなサブスクリプション率が回線に適用される場合、着信と発信の両方のトラフィックに対して、ピーク使用率または 1 時間当たりの平均使用率を収集することが理想的であることです。これは、特に、ATM またはフレームリレーのポイントツーマルチポイント ネットワーク トポロジで重要です。トラフィックの大部分が発信であるからです。
もう 1 つの項目は、リンクに使用可能な合計帯域幅を判定することです。たとえば、SNMP またはパフォーマンス管理ツールは、使用可能な帯域幅をどのようにして認識するのでしょうか。SNMP ツールは、場合によっては、単に MIB II IfSpeed 値をポーリングして、帯域幅を判定します。 IfSpeed 値は物理インターフェイスの帯域幅を表すので、これが WAN リンクで問題になることがあります。ATM またはフレームリレーでは、レートの制限があるか、または 1 つの物理インターフェイス上で複数の仮想回線が設定されるので、実際の帯域幅が大きく異なる可能性があります。その結果、ツールが IfSpeed MIB II 変数を使用して、使用可能な帯域幅を計算する場合、 bandwidth コマンドを使用して再設定して、デフォルトの IfSpeed 変数に含まれる物理インターフェイスの帯域幅を上書きする必要がある場合があります。ATM では、登録された帯域幅に設定してください。フレームリレーでは、CIR 値に設定してください。IP テレフォニーとのフレームリレー リンクには、CIR に対するフレームリレー トラフィック シェーピングが推奨されるからです。着信トラフィックと発信トラフィックに異なる CIR 値が存在する場合、これが問題になる可能性があります。また、 bandwidth コマンドは、ルーティング メトリックにも使用されることに注意してください。CiscoWorks 2000 TrafficDirector などの多くのツールでは、帯域幅はツールに直接入力され、 IfSpeed MIB II 変数は使用率計算で使用されません。この場合、ATM リンクまたはレートが制限されたリンクの場合は、登録される帯域幅を入力し、フレームリレー リンクの場合は、CIR 帯域幅を入力してください。
もう 1 つの重要な考慮事項は、5 分のポーリング インターバル間に SNMP によって測定されるピーク使用率が、実際にはピークでないことです。一般に、データ トラフィックは、非常にバースト性が高いものです。下記のグラフは、戻された 5 分のポーリング値（緑色で表示）が、5 分間の平均である状態を示しています。赤い線は、問題が起きる可能性があるしきい値を示しています。青い線は、2 つのポーリング インターバルでしきい値を超えたことを示す、理論的な使用率曲線です。しかし、5 分の平均は、しきい値以下でした。したがって、5 分のピーク値を解釈する際には、注意してください。プロトコル アナライザによるテストは、一般に、ポーリング期間中のある時点で、戻された 5 分の値を 40% 超えてデータがバーストすることを示しています。
ベースライン ネットワークの使用率を収集しようとする企業、組織には、さまざまな選択肢があります。パフォーマンス管理ツールは、通常、企業、組織内で使用可能です。使用可能でない場合、CiscoWorks 2000 TrafficDirector、または Cisco WAN SwitchProbe などのツールを検討できます。また、ネットワーク ベースラインを、さまざまなネットワーク サービス会社、またはコンサルティング会社に外注することもできます。シスコには、WAN リンクのピーク使用率および 1 時間当たりの平均使用率を提示する VoIP 監査もあります。
企業、組織は、ネットワークに対する CPU とメモリのベースラインも考慮する必要があります。これが重要なのは、QoS、レート制限、および Link-Fragmentation Interleaving などの設定に、追加の CPU およびメモリが必要になる場合があるからです。また、実験環境で CPU およびメモリの要件をテストして、所定のプラットフォームとメモリ割り当てに、適切なリソースが使用可能であることを確認することもできます。
ベースライン使用率情報は、データと IP テレフォニーの帯域幅要件を決定するのに使用されます。デバイス情報は、全体的な要件が特定された後でアップグレード要件を決定する際に使用されます。
パフォーマンス情報
遅延、ジッタ、およびパケット損失を含めた、現在のパフォーマンス情報のベースラインは、WAN リンクの現在のジッタおよび遅延の計画を立てるのに重要です。これは、潜在的な遅延またはジッタの問題を特定し、ネットワークのアップグレード後に予想される遅延とジッタを見積もるのに役立ちます。
• 遅延は、パケットが WAN リンクを通過するのに要する時間（ミリ秒）です。
• ジッタは、WAN リンクを通過するパケットに発生する遅延の範囲です。
• パケット損失は、キューイングのオーバーフローまたはエラーが原因で、ネットワーク内で失われるパケットの数またはパーセントです。
遅延、ジッタ、およびパケット損失の測定には、複数の方法があります。ping スクリプトを使用して、最小と最大の遅延、ジッタ、およびパケット損失を判定できます。この場合、送信されるパケットは、音声パケットのサイズ（約 60 バイト）に近いものです。
また、CiscoWorks 2000 の WAN 管理スイートに含まれる Internet Performance Manager（IPM）などのツールも使用できます。このツールを使って、音声タイプのパケットを送信して、遅延、ジッタ、およびパケット損失を判別できます。次の表は、WAN リンクのパフォーマンス ベースラインの例です。
|
|
|
|
ジッタ |
|
音声帯域幅要件の決定
音声帯域幅要件は、サンプリング レート、コーデック、リンク タイプ、ヘッダー圧縮手法、および同時音声コール数を始めとする、いくつかのパラメータによって決まります。ここでは、WAN リンクの音声帯域幅要件を特定します。
最も重要な項目は、WAN リンクを介して許可される同時コール数です。企業、組織は、コール アドミッション制御を使用して、コール数を制限できます。しかし、中央集中型コール処理モデルでは、コール キャパシティで試行すると、単にビジーアウトします。これは、外線が使用不能であるときに Centrex ソリューションで予想される動作と同じです。さらに、電話機に対する回線数のパーセントは、ビジネス要件に応じて異なるので、これに対する厳密な規則はありません。リモート ロケーションに現在実装されている外線と電話機の数を判別することから始めることができます。また、現在のソリューションで発生するビジーアウトの頻度に関する統計を収集して、追加のニーズを判断することもできます。新しいソリューションを実装しようとしているので、この際に、リモート ロケーションで使用可能な回線数が、そのリモート ロケーションに十分な数であるかどうかを調べることをお勧めします。
WAN リンクを介して許される最大コール数を判断すると、そのリンクの追加帯域幅要件を一層よく理解できます。次のステップは、1 つの音声コールに必要な帯域幅量を理解することです。残念ながら、音声コールの帯域幅所要量を尋ねると、おそらく、さまざまな答えが得られます。それらの答えはすべて、所定の状況においては正しいものでしょう。したがって、VoIP パケットのコンポーネント、および全体的な使用率に影響を与えるさまざまな変数を理解することが重要です。次の図は、VoIP パケット内のコンポーネントを示しています。パケット サイズに加えて、サンプリング レートも帯域幅要件に影響を与えます。VAD（voice activity detection）の設定も、帯域幅要件に影響を与えます。VAD は、所定のいずれの音声コールでも、一度に 1 人の通話者だけが会話するという理論を使用して、帯域幅所要量を減らします。この理論を使用すると、非活動期間はリンク上で送信されません。VAD は、全体的な帯域幅を 50% 節約すると予想されます。しかし、任意の時点で、1 つの音声ストリームに予想帯域幅の 100% が必要になることがあるので、プランナは注意が必要です。
企業、組織は、ペイロード要件の理解から始めることができます。現在、2 つのエンコーディング方式（G.711 と G.729A）が使用可能です。一般に、LAN 環境には G.711 エンコーディング、WAN を介する場合は G.729A をお勧めします。音声品質について両方の方式をテストすると、追加のペイロード情報があるので、G.711 が G.729 よりわずかに優れています。もっと重要な要素はサンプリング レートです。サンプリング レートは、パケットの送信前に、情報のエンコーディングに割り当てられる時間です。20 ms のタイムスロットに必要な音声情報が少ないので、20 ms のサンプリング レートで高い品質が得られます。30 ms のサンプリング レートの音声品質は、20 ms より低くなります。30 ms を超えるサンプリング レートを設定することは可能ですが、通常、音声品質が非常に低下するので、お勧めしません。
表3-19、パート1 では、20 ms と 30 ms サンプリング レートの場合の G.711 と G.729A のペイロード所要量を示しています。サンプリング レートは、ペイロードの帯域幅にはあまり影響を与えないことに注目してください。しかし、オーバーヘッドが追加されると、33 パケット/秒ではなく、50 パケット/秒の場合に大幅に増加します。帯域幅の使用量は、VoIP ストリームごとにも必要です。任意の会話で、各方向に 1 つずつ、2 つのストリームが必要です。
|
|
|
|
パケット数 |
|
332 |
||||
332 |
表3-19、パート2 では、RTP ヘッダー、UDP ヘッダー、IP ヘッダー、およびリンク ヘッダーを含む、ヘッダーの追加オーバーヘッドを考慮しています。下記のすべてのメディア タイプには、40 バイト/パケットで RTP、UDP、および IP のヘッダーが含まれています。
|
|
14 バイトの ヘッダー |
6 バイトの ヘッダー |
|
4 バイトの ヘッダー |
RTP ヘッダー圧縮および VAD を使用して、帯域幅割り当てを改善できます。RTP ヘッダー圧縮は、IP/UDP/RTP ヘッダーのサイズを 40 バイトから 2 バイトに減らします。VAD は、帯域幅が話し手側のみに割り当てられるので、帯域幅所要量を約 2 分の 1 に減らします。
通話時間の 50 パーセントでメディア ストリーミングの中断が起きることは、確実ではないので、下記の VAD の値は、誤解を招く恐れがあります。VAD 制御のメディア ストリーミングは、送信側で測定されるオーディオ レベルの関数であり、背景のノイズを始めとするいくつかの要素の影響を受けます。この理由から、帯域幅割り当てを減らす場合は注意してください。
表3-19、パート3 では、ストリーム単位で、RTP ヘッダー圧縮と VAD がある場合とない場合について、すべての主要メディア タイプの帯域幅所要量を示しています。任意の会話には、各方向に 1 つずつ、2 つのストリームがあることに注意してください。
|
|
14 バイトの ヘッダー |
6 バイトの ヘッダー |
53 バイトのセル |
4 バイトの ヘッダー |
84.83 Kbps |
||||
| 3.cRTP を使用するかどうかにかかわらず、1 つの音声パケットの転送には、53 バイトの 6 つの ATM セルが必要であるので、この場合、帯域幅は減りません。 |
ネットワーク プランナは、上記の情報を使用して、WAN サイトごとに必要な帯域幅を見積もることができます。WAN リンクは、一般に全二重であるので、1 つの音声コールの各方向に同じ量の帯域幅が割り当てられることに注意してください。VAD を使用する場合の帯域幅を見積もる際には、注意してください。上記の値は、特定の時点の一方向で実際に必要な帯域幅を表していないからです。
たとえば、Acme Corporation のリモート フィールド サイトに、20 人の正社員がいるとします。現在、このサイトには 3 つの Centrex 回線があり、ユーザは、外線が使用できないという理由で時々ビジーアウトします。ネットワーク プランナは、プロバイダーに連絡して、ビジーアウト状態が 1 日約 10 回起きていたことを知りました。これは、このオフィスでは受容できないと見なされたので、ネットワーク プランナは、4 つの同時音声コール用の帯域幅を提供することを承諾しました。このサイトは、現在、フレームリレー経由で接続されています。また、ネットワーク プランナは、さまざまな圧縮技法をテストし、cRTP と VAD を使用して、50 pps でフレームリレーを介した G.729 エンコーディングを使用することを決定しました。ネットワーク プランナは、入手可能な情報を使用して、各コールが、ストリームごとに約 10.8 Kbps を使用することを知りました。しかし、VAD は、帯域幅所要量が一度に各方向でこれほど低くなることを保証しないので、プランナは、各方向で 43.2 Kbps のみではやや不安でした。プランナは、音声品質の保証を強化するために、フレームリレー全体で 64 Kbps を割り当てる必要があると判断しました。現在、このサイトには、フレームリレーを介して 64 Kbps CIR があります。したがって、プランナは、CIR を 2 倍して 128 Kbps にし、適切な QoS、トラフィック シェーピング、および Link Fragmentation Interleaving を設定して、受容可能な音声品質を提供する予定です。
アップグレード要件の分析
WAN を介した IP テレフォニーを成功させるために、次に、ハードウェア、ソフトウェア、および WAN 接続のアップグレード要件を考慮する必要があります。IP テレフォニー機能の十分な処理能力を確保するために、ハードウェアのアップグレードが推奨される場合があります。ソフトウェアのアップグレードは、IP テレフォニー機能をサポートするために必要な場合があります。WAN のアップグレードは、追加されるトラフィック ロードをサポートするために必要な場合があります。まず、必要なソフトウェア機能、および使用可能なソフトウェア イメージを特定することから始めてください。これにより、メモリ フラッシュや CPU を含めて、ハードウェア要件が決まることがあります。また、帯域幅所要量により、ATM や HSSI などの広帯域幅 WAN メディアをサポートするための、特定のハードウェア機能が決まることもあります。
IOS ソフトウェア要件を調べて、使用予定のリリースに、WAN ベースの IP テレフォニーに必要な機能セットが含まれていることを確認してください。このマニュアルの設計の章では、WAN ベースの IP テレフォニー用の推奨 IOS 機能が記述されています。Class Based Weighted Fair Queuing（CBWFQ）、Link Fragmentation Interleaving（LFI）、トラフィック シェーピング、compressed RTP（cRTP）、およびロケーション ベースのコール アドミッション制御に対する IOS ゲートウェイ サポートは、中央集中型コール処理をサポートするために、使用予定の IOS バージョンで必要な機能の一部です。これらの機能を特定した後、http://www.cisco.com/warp/public/732/releases/、および http://www.cisco.com/warp/public/732/Tech/voice/index.html の Cisco.com で、使用可能なバージョンを調べてください。Cisco IOS ソフトウェア機能ナビゲータ
（http://www.cisco.com/cgi-bin/Support/FeatureNav/FN.pl）が便利なツールです。特定のリリースをターゲットにする前に、http://www.cisco.com/support/bugtools/ で、潜在的なバグも調べてください。また、ソフトウェア機能の分析とイメージの選択について、シスコ社代理店の販売担当者とサポート担当者に確認することもできます。調査の結果、IP テレフォニーをサポートする WAN ルータのターゲット ソフトウェア リリースが決まります。
ハードウェア プラットフォームを調べる場合は、事前に、メディア サポート要件が満たされることを確認するために、WAN アップグレード要件を決定しておく必要があります。大部分の場合、予想されるピーク音声要件に、現在のデータ要件を単に追加してください。ピーク期間にデータ トラフィックの一部を停止させることを選択する場合は、慎重に調査して、データ要件が継続して満たされることを確認してください。帯域幅所要量に加えて、これ以外の次の WAN メディアの考慮事項も調べます。
• キャリアまたは WAN 接続が、IP テレフォニーに必要なアベイラビリティをサポートするか。
• ハイ アベイラビリティ音声をサポートするために、WAN 全体の冗長性が必要か。
• 必要なアベイラビリティ レベルをサポートするために、WAN 接続に必要なハードウェア、ローカル ループ、および長距離の冗長性と多様性があるか。
中央集中型コール処理モデルの場合、WAN 接続の喪失は、リモート ロケーションの IP Phoneがダウンすることを意味します。この問題は、IOSルータによるSurvivable Remote Site Telephony（SRST） 機能を導入することで解決可能です。導入しない場合は、リモート ロケーションにおけるハイ アベイラビリティ IP テレフォニー サービスをサポートするために、WAN 接続において冗長性と多様性を保持してください。現在の WAN データのアベイラビリティが、IP Phone サービスに受け入れ可能であるかどうかを、慎重に考慮してください。
• キャリア ネットワーク内で輻輳が発生する可能性があるか。それはどのサブスクリプション レベルか。これがジッタに影響を与えるか。一貫したパフォーマンスを実現するために、トラフィック シェーピングが必要か。
WAN キャリア接続を分析して、キャリア ネットワークからどのくらいのパフォーマンスが期待できるかを判断します。ポイントツーポイントの T1、E1、または T3 リンクでは、最小遅延要件を満たすかどうかだけを判断してください。QoS 機能は、IP テレフォニーに対する要件が一貫して満たされることを確認するのに役立ちます。ATM またはフレームリレーの場合、キャリアが異なれば、提供されるサービス レベルも異なります。一部のネットワークでは、認定情報レートだけが、一貫したパフォーマンス レベルを満たすことが期待できます。他のネットワークでは、ポート速度までバーストしても、結果として適切な遅延とジッタになります。パフォーマンスについて何が、どのサブスクリプション レベルで期待できるかを知るには、キャリアにお問い合せください。これにより、キャリア ネットワークのトラフィック シェーピング、およびおそらく帯域幅所要量が決まります。
WAN 帯域幅、冗長性、多様性、キャリア、およびメディアの要件を分析したのち、IP テレフォニー用のキャリア サービスを調べるか、現在のサービスをアップグレードする必要がある場合があります。可能なサービスには、WAN ポイントツーポイント サービス（T1、E1、T3、および E3）、ATM サービス、フレームリレー サービス、および HSSI、POS、またはフレームリレー リンク レベル プロトコルをサポートする部分 T3 サービスがあります。
次に、ハードウェア ルータのプラットフォームとサイジングを調べます。WAN 内の 2500 ルータは、QoS およびその他の IP テレフォニー サービスをサポートするのに必要な、新しいイメージ サイズ要件、新しいメディア、または CPU をサポートしない場合があります。一般に、中央集中型コール処理モデルには、2600 および 3600 のルータ プラットフォームをお勧めします。これ以外のプラットフォームでも要件を満たす場合がありますが、リソース要件が満たされることを確認するために十分なテストが必要です。ハードウェアのサイジングにおける主な項目は、次のとおりです。
• WAN ルータは、負荷が存在するときの QoS、LFI、およびトラフィック シェーピングのプロセス用に、追加の CPU を必要とすることがある。
• WAN ルータは、H.323 ロケーション ベースのコール アドミッション制御をサポートするために、追加の CPU とメモリを必要とすることがある（VoIP Gateway）。
• WAN ルータは、新たに特定されるルーティング プロトコル、またはハイ アベイラビリティに必要な冗長性要件をサポートするために、追加の CPU を必要とすることがある。
• WAN ルータは、特定されたイメージ サイズをサポートするために、追加の DRAM またはフラッシュ メモリを必要とすることがある。
• WAN ルータは、冗長性とコンバージェンスをサポートするために実装される、ルーティング プロトコルまたは機能をサポートするために、追加のメモリを必要とすることがある。
• WAN ルータは、データと音声の帯域幅要件に必要な、新たに特定されたポート モジュールをサポートする必要がある。
ソフトウェア、ハードウェア、および WAN の要件を決定したら、次のステップは、音声トラフィックなしでソリューションを実装し、実動前にソリューションをテストすることです。
アップグレードの実行と調整の実施
この時点で、IP テレフォニー サービスに必要なアップグレードの発注、スケジューリング、および実装を行います。生の音声トラフィックの前にソリューションを検証できるように、必要な中央集中型コール処理、WAN、および LAN のアップグレードをすべて、音声を導入する前に行うことをお勧めします。アップグレードの変更はすべて、中程度のリスクから高リスクまでのガイドラインに従って実装する必要があります。可能な場合、実験環境でアップグレードをセットアップし、階段的に実施して、実動ネットワークでの成功を確実にしてください。
VoIP WAN ルータの設定については、http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/voice_c/vcprt1/vcvoip.htm にある設定ガイドラインを参照してください。http://www.cisco.com/en/US/tech/tk652/tk692/tech_protocol_family_home.html には、フレームリレー設定用のその他の設定資料があります。
また、Cisco ルータ上でのポリシー ベースの QoS の設定と管理に役立つ、QoS Policy Manager を CiscoWorks 2000 上で調べることもできます。
結果の評価
音声トラフィックを WAN ネットワークに追加する前に、WAN リンク上での音声トラフィックのパフォーマンスを確認してください。これを確認すると、存在する可能性がある設定またはパフォーマンスの問題を見付け、目標とする設計を検証し、実動での成功を保証することができます。次のように複数の評価方法があります。
• Internet Performance Manager（CiscoWorks 2000 にバンドル）
• Cisco VoIP Readiness Net Audit（バージョン II）
最初の方法では、WAN サイトと中央サイト間の音声品質とパフォーマンスを、物理的にテストし、評価します。この方法は、最も単純です。しかし、品質が適切なレベル以下である場合、ユーザが品質に満足せず、問題の特定やソリューション実施の続行に消極的になるという危険性があります。この理由により、潜在的な問題を客観的に識別し、解析する時間が与えられている、もっと専門的なチームでソリューションをテストすることをお勧めします。
もう 1 つの方法は、CiscoWorks 2000 の Internet Performance Manager を使用するものです。IPM は、サービス保証エージェント（SAA）と呼ばれる、Cisco ソフトウェア内の「模擬トラフィック生成」テクノロジーに基づいて、ネットワーク パフォーマンスを測定します。これらのエージェントは、ルータおよびその他のコンピュータ プラットフォーム上で、「コレクタ」と呼ばれるパフォーマンス エージェント上に設定できます。模擬トラフィックは、SAA デバイスから生成され、パフォーマンスの遅延とジッタの情報は、SAA コレクタから SNMP を介して収集されます。このツールを使用してテストする利点は、このツールが、IP テレフォニーのパフォーマンスの問題をトラブルシューティングするために、実動後に役立つことです。追加情報については、
http://www.cisco.com/warp/public/cc/pd/wr2k/nemo/ を参照してください。
Cisco VoIP Readiness Net Audit は、1 回限りのネットワークの監査であり、潜在的なパフォーマンスの問題を示します。LAN または WAN 上の VoIP に影響を与える項目をすばやく正確に指摘するので、この段階でこの監査をお勧めします。この監査には、Net Audit コレクタ デバイスを使用して、ネットワークから 1 回限りの情報収集が必要です。
オペレーションの交替と実稼働
稼働する前に、WAN サイトのオペレーションの交替、および IP テレフォニーの実稼働およびサポートを定義してください。
• マップおよび設定から稼働までを含む、詳細なネットワーク資料
• オペレーションのトラブルシューティング ガイドとサポート ツール
• IP テレフォニー サポート用のサービス レベルの目標、またはサービス レベル契約
（注） これらの項目は、このマニュアルのオペレーションと実装の項で詳しく説明しています。
オペレーションと実装の計画
設計の計画の他に、順調な実装に役立つ実装プロセスとオペレーション プロセスを計画する必要があります。これを計画するには、業務を継続しながらソリューションを成功させるために必要な、設計、実装、およびオペレーションのプロセスを特定します。これには、キャパシティ計画、ネットワーク管理計画、人材の配置、およびオペレーション計画などのプロセスが含まれます。
IP テレフォニーは、大部分の企業、組織にとって大幅なテクノロジーの変更になるので、設計段階から十分なオペレーション計画を開始する必要があります。これによって、ソリューションのオペレーション要件を満たすこと、および企業、組織のオペレーション グループが、ソリューションの管理に必要なリソースと専門技術レベルを備えていることを確認できます。次のタイプのオペレーションと管理の計画が必要になることがあります。
IP テレフォニーのキャパシティ計画
キャパシティ計画は、企業、組織の VoIP 移行および全体的な成功に重要なプロセスです。従来のデータ環境では、キャパシティ計画は、リンク使用率、および CPU とメモリを含む、ネットワーク デバイス用のコントロール プレーン リソースを中心にしていました。IP テレフォニー VoIP ネットワークには、次の 3 つの異なるキャパシティ計画プロセスが必要です。
CallManager 処理要件によって、通常のコール処理、音声会議、およびその他の IP テレフォニー サービス用に十分なリソースが、CallManager サーバにあることを確認できます。一般に、この計画と設計のプロセスにより、ネットワーク設計が改善され、企業、組織の要件のサポートが改善されます。
ネットワーク キャパシティおよびパフォーマンスの計画は、ネットワークが追加の VoIP とトラフィックをサポートすること、およびさらに重要なのは、トラフィックが VoIP ネットワークにとって重要な遅延とジッタの要件を満たすことを保証します。このプロセスにより、全体的な設計が改善され、VoIP 要件のサポートが改善されます。
トランキング キャパシティでは、通常の PSTN トランキング、音声メール サーバ トランキング、およびオフネットのドメイン間トランキングとドメイン間オーバーフローをサポートすることが必要なサイト間トランキングを含む、PSTN トランキング要件を調べます。
企業、組織が十分なキャパシティとパフォーマンスを確保できるのは、これらのプロセスのそれぞれを調査し、完了した場合だけです。この項の目的は、キャパシティ計画のベスト プラクティスを提示することです。これらのプロセスは、IP テレフォニー実装のネットワーク計画および設計の段階で実行する必要があります。
また、この項では、設計と設定のガイドラインと共に、これらのプロセスで役に立つキャパシティ計画ツール、および Cisco IP テレフォニー サポート サービスについても説明します。
CallManager 処理
CallManager 処理では、CPU とメモリの要件、およびサポートされている設定が調べられます。CallManager 3.0 以降を使用する大規模なアプリケーションでは、サーバはクラスタで設定されます。クラスタ化のガイドラインには、データベース複製またはパブリッシング用の専用サーバの使用、および目的数の IP Phone用のバックアップ CallManager 能力の使用が含まれます。また、CallManager サービスには、各 CallManager 設定内の CPU とメモリの要件に与える影響に対して、重みも割り当てられます。
サーバ モデル、およびクラスタ内で設定されるサーバ数を含む設定を適切に設計するために、設定内の望ましい IP Phone数、および望ましいサービスの重みを調べる必要があります。TFTP サービスの専用サーバに対して 2500 台以上の IP Phoneを設定するためには、データベース パブリッシングをお勧めします。
CallManager のリソース要件の詳細については、『Cisco IP テレフォニー ネットワーク デザイン ガイド』の表を参照してください。これらの表は、次のロケーションにあります。
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/ipts/citndg/chapter03/03_dgclustr.HTML
ネットワーク キャパシティとパフォーマンスの計画
ネットワーク パフォーマンスとキャパシティの計画は、データ トラフィックおよび VoIP トラフィックに使用可能な帯域幅が、一貫してネットワークにあること、および VoIP パケットが、遅延とジッタの要件を一貫して満たすことを保証します。ネットワーク キャパシティとパフォーマンスの計画に対して、次の 6 つのステップで構成されるプロセスをお勧めします。
1. 既存のネットワーク使用率とピーク負荷要件のベースラインを作成する。
2. 混雑時の見積もり、ゲートウェイのキャパシティ、および CallManager キャパシティに基づいて、ネットワークの必要なセクションにおける VoIP トラフィックのオーバーヘッドを決定する。
4. IP テレフォニーの設計推奨事項、および帯域幅要件（可能な場合は、オーバー プロビジョン）に基づいて、必要な設計の変更および QoS 要件を決定する。
ステップ 1 既存のネットワーク使用率のベースラインを作成する
ネットワーク使用率のベースラインを作成すると、VoIP とデータを混合したアーキテクチャに対する現在のトラフィック負荷、およびデータ トラフィック要件を決定するのに役立ちます。このステップは、主なディストリビューション、バックボーン、および必須の WAN リンクに対して実行する必要があります。相対的に等質な環境である場合、ネットワーク全体の大量のデータを収集するのではなく、代表的なリンクからサンプル ベースラインを実行することができます。リンクの使用率を記述するには、通常、2 つのタイプの使用率統計（ピーク使用率と平均使用率）を使用します。これらの測定方法のどちらにも限界があるので、これらの使用率を慎重に評価する必要があります。
ピーク使用率データを収集するには、通常、短い時間間隔で「平均」使用率の SNMP ポーリングを行います。大部分の場合、この時間間隔は 5 分ですが、最高 15 分にすることができます。この情報の問題点は、指定された期間の使用率の平均であることです。5 分の期間で、実際のピーク使用率は、報告された結果より 40% 高いことが調査によって明らかになっています。つまり、70% のピーク使用率が報告された場合、その 5 分間の間に、使用率が 98% である時点があることを示しています。VoIP 環境では、これは、音声パケットの遅延とジッタにすでに影響を与えている可能性があります。もう一つの問題は、各方向で使用率が非常に異なる可能性がある二重リンクを、情報が表していない可能性があることです。
前記以外の理由で、平均使用率は完全な情報を提示しない場合があります。たとえば、データ トラフィックは、午前と午後のピーク時にかなり高くなる可能性があります。24 時間の平均使用率が報告される場合、報告された結果は、使用率が高い日中の時間帯を表していない可能性があります。
もっと有効な値にするには、ピークおよび平均の使用率と、実際のピーク時間帯との関連性をもっと密接にする必要があります。平均使用率が、日中の最も混雑する時間帯の「混雑時」使用率を表している場合、もっと重要な値になります。ピーク使用率が実際のピーク期間（おそらく、秒単位またはミリ秒の範囲）を判別できれば、ピーク使用率はもっと重要な値になります。残念ながら、ピーク使用率は、ネットワークの多くの領域で収集するのが簡単でなく、適切な計測が行えません。このためピーク使用率の値は、40% ルールを使用して、5 分間の SNMP 収集間隔の実際のピーク要件を見積もる必要があります。LAN と WAN の両方で QoS を使用する場合は、ピーク使用率が必要ない場合があります。しかし、混雑時使用率は貴重な情報であり、この情報を使用すると、データと音声の混合トラフィックに十分な帯域幅があるかどうかを判断できます。
混雑時使用率を収集するには、音声トラフィックを伝送するディストリビューション、バックボーン、および WAN の各リンクをすべて 1 時間単位でポーリングし、約 1 週間データを収集した後、各リンク上の混雑時使用率を報告する必要があります。Concorde NetHealth などのツールは、多数のリンクについてこの情報を提供できます。または SNMP コレクタを使用して、代表の LAN リンク上でデータを収集することもできます。一般に、VoIP に使用されるすべての WAN リンクを調べる必要があります。その後、予想される混雑時音声トラフィックと組み合わせてこの情報を使用して、帯域幅要件を決定します。このプロセスは、QoS によって制御された環境で VoIP の実装を計画する任意のネットワークに適しています。LAN 環境に対して QoS が計画されない場合、ピーク使用率をさらに詳しく調査することが必要な場合があります。多くの場合、現在または将来のリンク使用率の問題を避けるために、LAN 帯域幅を多めに登録することも選択できます。
データを収集し、そのデータを音声要件と比較した後、望ましい QoS 要件、予想されるネットワークの拡張、およびアップグレード要件を定義するための全体的な要件を調べる必要があります。予想される混雑時の組み合わせ使用率が、LAN リンクで 50% を超え、WAN リンクで 75% を超えるものを注意深く調べてください。これにより、データと音声の要件を満たすことが保証されます。
建物ごと、または WAN サイトごとに、VoIP オーバーヘッドを判定する必要があります。しかし、ネットワーク プランナは一般に、LAN 環境における VoIP オーバーヘッドの量が低いことに関心をもっていません。トラフィック要件を決定するための特定のルールはありません。しかし、社内の通信部門は、現在の音声ネットワークのさまざまな領域に対して、混雑時トラフィックの統計を提供できます。音声トラフィックの必要量が多い、または少ない建物またはサイトを区別するには、特に注意が必要です。たとえばある企業には、電話を通常あまり使用しない技術者がいる建物と、常に電話を使用するサポート センターの社員がいる建物があります。
混雑時のコール ボリュームを見積もり、アーラン カルキュレータを使用して混雑時のコール要件を決定することをお勧めします。その後、これに VoIP エンコーディング方式を掛けると、混雑時の帯域幅要件を決定できます。たとえば、通信部門が、100 名の社員がいる建物で、混雑時コール ボリューム 100 コールと平均コール時間 10 分に基づいて、この建物の混雑時トラフィックが 16.66 時間であると見なすとします。次に、16.66 時間とブロック係数 1 パーセントに基づいて、アーラン B 計算を実行できます。ブロック係数は、見積もられた帯域幅が音声要件を満たす信頼水準です。アーラン B カルキュレータ（アーランのWeb サイト： http://www.erlang.com で入手可能）により、99% の信頼水準をサポートために、26 回線が必要であることが算出されます。カプセル化方式を 26 倍すると、混雑時トラフィック ボリュームを決定できます。80 KB パケットと固定双方向音声トラフィックで G.711 エンコーディングが使用されると仮定すると、適切な帯域幅を提供するには、2 Mb /秒が必要であると見積れます。一般に音声トラフィックは一定でないので、これは、音声トラフィック要件の許容見積もり値と見なされます。
通信部門が混雑時トラフィック ボリュームを提供できない場合、建物内の音声使用状況を、おそらく目視の手段でも調べる必要があります。これは、LAN 環境ではあまり重大な問題ではありません。500 名のユーザが常時電話を使用しても、40 Mb /秒のデータ帯域幅しか使用しないからです。
WAN 帯域幅要件については、『Cisco IP テレフォニー ネットワーク デザイン ガイド』を参照してください。この資料は、次のロケーションにあります。
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/ipts/citndg/chapter03/03_dgclustr.HTML
WAN リンク上では、混雑時データ トラフィックと混雑時音声トラフィックを組み合わせて、リンク帯域幅要件を決定する必要があります。この値には拡大の余地がないことに注意してください。時間の経過による拡大の必要性を判断し、リンクの傾向分析を実行して、データと音声の実装後の全体的な帯域幅要件を決定するのは、企業の責任です。リンク使用率のベースラインを作成し、時間の経過による傾向を分析して、ネットワークがデータと音声の両方の要件を一貫して満たすことを確認するようにお勧めします。
設計の変更では、まず、LAN と WAN のトポロジ用の IP テレフォニー配置ガイドラインに従う必要があります。
（注） 詳細については、次の Web サイトの『Cisco IP テレフォニー ネットワーク デザイン ガイド』を参照してください。
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/ipts/citndg/index.html
これらの要件が満たされた後、全体的なスケーラビリティと共にデータの拡張と音声トラフィックの要件を調べて、IP テレフォニー用の全体的なネットワーク インフラストラクチャ ソリューションを定義する必要があります。全体的なネットワーク設計に加えて、LAN と WAN の両方の環境に対して QoS を設定して、パフォーマンス ベースラインを使用してネットワーク設計を検証する必要があります。
ステップ 5 IP テレフォニーのパフォーマンス ベースラインを検証する
次に、実装の前にパフォーマンスのベースラインを使用して、VoIP のパフォーマンスを検証し、音声の準備状態を判断する必要があります。シスコシステムズは、特定された主なパス上での遅延とジッタを測定する、音声準備状態監査を実行できます。この監査は、主なネットワーク パス上での潜在的なネットワーク問題も調べます。この問題には、キューイング遅延、CPU 使用率、リンク使用率、バッファ使用率、およびエラー率が含まれることがあります。また、現用ソリューションのベースラインを作成し、追加のトラフィック負荷やパフォーマンス要件を使用して潜在的な問題を判断するために、完全な IP テレフォニー実装後にもこのステップを考慮する必要があります。
CallManager キャパシティ問題やネットワーク キャパシティ問題に加えて、音声メール接続、PSTN 接続、およびオフネット トランキング、またはオフネット オーバーフロー用のサイト間接続に対する、トランキング要件も決定する必要があります。音声トランキング用のトランクのキャパシティ計画は、すでに音声の分野では確立されたキャパシティ計画プロセスです。これと同じプロセスが、IP テレフォニーのトランキング キャパシティに適用されます。
このプロセスを実行するには、通常、必要なトランキング アプリケーションの混雑時トラフィック統計を判定します。一般的なトランキング アプリケーションは、次のとおりです。
• 専用回線またはデータ/音声 TDM システムを介したサイト間トランク
• コール アドミッション制御で使用されるオフネット オーバーフロー用のサイト間トランク
通常、既存の通信スイッチ ベンダーから提供されるアプリケーション タイプごとに、混雑時トラフィックを判定できます。これは、追加サービスになる場合があります。混雑時トラフィックは、最も混雑する時間のコール時間数として定義できます。混雑時間は、1 ヶ月の内、最も混雑する時間になる場合があります。たとえば、コール時間が平均 10 分の 200 コールがある場合、混雑時トラフィックは 2000 分または 33.33 時間です。混雑時トラフィックが入手できない場合、既存の通信ソリューションとほぼ同じ（またはやや大きい）トランク数を IP テレフォニーに実装することを選択できます。
必要なアプリケーションの混雑時トラフィックを判定した後、アーラン B カルキュレータ（ http://www.erlang.com ）を使用して、適切なブロック係数に基づいて、十分なトランキング数量を得ることができます。大部分の通信企業は現在、ブロック係数 1 パーセントを使用しています。これは、混雑時の時間の 1 パーセントで、トランクが使用不能であるためユーザが待機、またはビジーアウトすることが予想されるという意味です。この計算では、2000 分で 45 トランクが必要であることを示します。これは、23 個ずつの音声チャネルを使用する 2 つの T-1 にほぼ相当します。
各アプリケーションを定義し、混雑時トラフィックを判定または見積もり、アーラン カルキュレータを使用した後、特定の要件に最も適したゲートウェイ製品、または製品の組み合せを決定する必要があります。
ソリューション管理要件
今日のデータと音声のネットワークには、一貫したサービスを確保するための固有の管理要件が必ずあります。IP テレフォニー ソリューションの管理プランを作成する際には、データまたは音声に対する既存の要件、および VoIP ソリューションに必要な固有の管理要件を考慮する必要があります。このソリューション管理プランは、計画段階で重要です。それは、管理容易性が、製品の選択、ネットワークの設計、およびネットワーク管理アーキテクチャに影響を与える可能性があるからです。
ソリューション管理要件を調べる場合、標準のネットワーク管理モデルを参照すると便利です。最も一般的な参照モデルは、ISO ネットワーク管理モデルです。このモデルは、ネットワーク インフラストラクチャを管理するさまざまな分野を取り扱う際に、5 つの機能領域を示しています。「FCAPS」と呼ばれるこのモデルには、次のものが含まれます。
このモデルとその機能領域を使用すると、ネットワーク管理要件の評価における範囲と目的を明確に定義することができます。IP テレフォニー管理用の FCAPS モデルと要件の詳細については、 第 6 章「IP テレフォニー ネットワークの運用」 を参照してください。
ネットワーク管理の機能領域
障害管理の目的は、IP テレフォニー インフラストラクチャ内のネットワーク要素の問題を検出することです。ハードウェア、ソフトウェア、またはリンク接続の問題により、ネットワーク サービスの中断または低下が生じる可能性があります。これらの問題は、要素の機能性、適切なエレメント管理設定、管理システムへの転送、および画面上のアラートまたはポケットベル呼び出し/電子メールを使用した問題の通知により、検出できます。要素によって報告される障害の重大度に基づいて、ネットワークのアベイラビリティおよびパフォーマンスに与える影響を最小限に抑えるために、適切な処置を講じることができます。障害検出、すべての要素の継続したモニタリング、およびタイムリーな問題解決を有効にするために、障害管理を慎重に実装する必要があります。
設定管理には、コンフィギュレーション ファイル、ソフトウェア、アドレス、ダイヤル プラン、ネットワーク マップ、およびネットワーク要素の詳細なインベントリの管理が含まれます。最新の設定管理システムは、トラブルシューティングに要する時間を短縮するのに役立ち、障害が起きる前に潜在的な問題を特定するのに役立ちます。
大規模な企業、組織やサービス プロバイダーでは、場合によっては、予算作成または課金の目的で、ユーザまたは機能グループによるアプリケーション、およびネットワーク リソースの使用状況を追跡する必要があります。音声システム上の不正検出などの監査プロセスやセキュリティ プロセスにも、アカウンティング情報が非常に重要な場合があります。
パフォーマンス管理には、一貫したアベイラビリティを確保するために、ネットワーク内のリソースの使用状況の測定と割り当てが含まれます。例外レポート、ベースライン レポート、または傾向分析によって、パフォーマンスを測定できます。測定には、デバイス リソース使用率、リンク使用率、またはエンドツーエンドのパフォーマンス測定が含まれる場合があります。
セキュリティ管理には、データの盗難、データの損失、および不正侵入を防ぐために、インフラストラクチャ内のリソースへのアクセスを制御するさまざまな分野が含まれます。
IP テレフォニー インフラストラクチャの管理
既存のデータ要件、既存の通信要件を調査し、新しい要件を評価することによって、データと音声の混合インフラストラクチャの管理要件を決定する必要があります。次の表は、主な管理要件を理解するのに役立ちます。ソリューションの正確な要件を特定した後、管理容易性の観点から、製品とツールの要件を定義できます。
人材と専門技術の要件
追加の人材や訓練要件を計画できるように、計画段階から人材と専門技術の要件を考慮する必要があります。また、大規模な企業、組織には、実装の前に、十分に定義されたプロビジョニングと管理プロセスも必要です。
多くの企業、組織は、単に IP テレフォニー ネットワークの管理に必要な人員数を考慮します。必要な人員は、企業、組織の規模、企業、組織のアベイラビリティ要件、自動化機能、および企業、組織の効率性によって異なります。ここでは、必要な人員数を指定するのではなく、次のことをお勧めします。
2. 個々の要件を満たすのに必要な専門技術と人材のレベルを特定する。専門技術と人材の配置を最も適切に特定するには、要件を PDIO（計画、設計、実装、稼働）モデルに分けます。
次の表は、正常な IP テレフォニー実装の計画、設計、実装、稼働、およびリソース要件の特定に役立ちます。一部の環境では、これ以外のプロセスが必要な場合があります。
（注） 次の表に含まれているのは例であり、各企業、組織に正確に適合するものではありません。
オペレーション サポート プラン
ネットワークのサポート方法を理解することは、ネットワークのライフサイクルの設計とオペレーション段階に非常に重要です。企業、組織内で必要なサービス レベル、およびこれらのサービス レベルをサポートするプランを理解することが、IP テレフォニーの計画に含まれていなければなりません。これにはまず、ネットワークのアベイラビリティとパフォーマンスの要件を定義することから始めます。設計グループは、これらの要件を満たすネットワークを構築し、オペレーション グループは、これらのアベイラビリティとパフォーマンスの目標を達成するのに必要なプロセスを定義できます。
オペレーション サポート計画、およびアベイラビリティとパフォーマンスの標準を定義し、ネットワーク サービス レベルを定義し、対処的または予防的なサービス定義を作成するプロセスの詳細については、 第 6 章「IP テレフォニー ネットワークの運用」 を参照してください。
フィードバック