音声 : ゲートウェイ プロトコル

フレームリレーおよび ATM でのマルチリンク PPP の設計および導入

2002 年 10 月 30 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2007 年 8 月 16 日) | フィードバック

目次


概要

Multilink PPP over ATM(MLPoATM)および Multilink PPP over Frame Relay(MLPoFR)は、Cisco IOS(R) バージョン 12.1(5)T で導入されました。この機能は、Frame Relay/ATM Interworking(FR/ATM IW)を利用し、中〜低速 WAN リンクで Voice over IP(VoIP)を展開するお客様を対象としています。この機能が登場する以前には、Cisco IOS が ATM とフレームリレーの両方でサポートする共通のレイヤ 2 フラグメンテーション方式は存在しませんでした。したがって、FR/ATM IW を使用するお客様はレイヤ 3 フラグメンテーションを使用せざるを得ませんでした。

前提条件

この文書は、ATM とフレームリレーのインターワーキング ネットワーク上で Multilink Point-to-Point Protocol(MLP; マルチリンク PPP)を使用して VoIP ネットワークを設計および導入しようとしているネットワーク担当者を対象としてします。この文書の読者は、次のことについて理解している必要があります。

     

  • フレームリレー
  • ATM
  • PPP
  • MLP
  • FR/ATM インターワーキング

この文書の目的は、これらのテーマについて技術的なトレーニングを行うことではありません。この文書の末尾に参考資料のリストがあります。

ハードウェアとソフトウェアのバージョン

この文書の情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

  • FR/ATM IW での MLP については、Cisco IOS バージョン 12.1(5)T 以降
  • ATM での Compressed Real Time Protocol(cRTP)については、Cisco IOS バージョン 12.2(2)T 以降
  • フレームリレーおよび ATM での、物理インターフェイスにおける Low Latency Queueing(LLQ; 低遅延キューイング)については、Cisco IOS バージョン 12.0(7)T
  • フレームリレーおよび ATM での、Permanent Virtual Circuit(PVC; 相手先固定接続)ごとの LLQ については、Cisco IOS バージョン 12.1(2)T

使用するコンポーネント

 

この文書のケース スタディは、次に示すソフトウェアとハードウェアのバージョンを使用する実稼動ネットワークに基づいています。

  • コア Cisco 3660 ルータでは、Cisco IOS バージョン 12.2(5.8)T が動作しています。cRTP over ATM の要件には、Cisco IOS バージョン 12.2T を使用することが明記されています。この文書の執筆時点で、未解決の問題が 1 つ残っています。
    • CSCdw44216 - Class-Based Weighted Fair Queuing(CBWFQ)/LLQ リンクが輻輳状態になると、cRTP によって CPU の使用率が非常に高くなります。
  • ブランチ Cisco 2620 ルータは、Cisco IOS バージョン 12.2(3) から 12.2(6a) へのアップグレードの段階にあります。Cisco 2620 はブランチ H.323 ゲートウェイとしても動作しており、ゲートウェイに関する問題がアップグレードの引き金となりました。WAN および Quality of Service(QoS)機能に関する限り、Cisco IOS バージョン 12.2(3) で重大な問題は発生していません。

設計

データリンク オーバーヘッド

MLP を使用する ATM およびフレームリレー ネットワークを設計する場合は、データリンク オーバーヘッドについて理解する必要があります。オーバーヘッドは、各 VoIP コールによって消費される帯域幅の量に影響を与えます。また、最適な MLP フラグメント サイズの決定にも関与します。フラグメント サイズを整数個の ATM セルが収まるように最適化することは重要です。特に低速の PVC では、セルのパディングで著しい量の帯域幅が無駄になる可能性があります。フレームリレーおよび ATM PVC での MLP におけるデータリンク オーバーヘッドは、次の要素によって決まります。

  1. FRF.8 IW デバイスの動作モード(トランスペアレントまたはトランスレーション)。
  2. トラフィックの方向(ATM からフレームリレー、またはフレームリレーから ATM)。
  3. PVC 区間。オーバーヘッドは、PVC の ATM 区間とフレームリレー区間で異なります。
  4. トラフィック タイプ。データ パケットには MLP ヘッダーがありますが、VoIP パケットにはありません。

次の表は、データ パケットのデータリンク オーバーヘッドを示しています。ここでは、すべての FRF.8 動作モード、トラフィック方向、および PVC 区間の組み合せについて、フレームリレー、ATM、LLC、PPP、および MLP の各種ヘッダーのバイト数を詳細に示しています。

FRF.8 モード トランスペアレント トランスレーション
トラフィック方向 フレームリレーから ATM ATM からフレームリレー フレームリレーから ATM ATM からフレームリレー
PVC のフレームリレー区間または ATM 区間 フレームリレー ATM ATM フレームリレー フレームリレー ATM ATM フレームリレー
                 
フレーム フラグ(0x7e) 1 0 0 1 1 0 0 1
フレームリレー ヘッダー 2 0 0 2 2 0 0 2
LLC DSAP/SSAP(0xfefe) 0 0 2 2 0 2 2 0
LLC 制御(0x03) 1 1 1 1 1 1 1 1
NLPID(PPP は 0xcf) 1 1 1 1 1 1 1 1
MLP プロトコル ID(0x003d) 2 2 2 2 2 2 2 2
MLP シーケンス番号 4 4 4 4 4 4 4 4
PPP プロトコル ID(最初のフラグのみ) 2 2 2 2 2 2 2 2
ペイロード(レイヤ 3+) 0 0 0 0 0 0 0 0
ATM アダプテーション層(AAL)5 0 8 8 0 0 8 8 0
フレーム チェック シーケンス(FCS) 2 0 0 2 2 0 0 2
 
オーバーヘッド合計(バイト) 15 18 20 17 15 20 20 15

DSAP/SSAP - Destination Service Access Point(宛先アクセスポイント)/Source Service Access Point(送信元サービス アクセスポイント)
NLPID - Network Layer Protocol Identification(ネットワーク層プロトコル ID)

トランスレーション PVC は両方向でオーバーヘッドが等しいため、トランスペアレント PVC よりも理解が容易です。これは、FRF.8 デバイスが MLP over ATM(MLPoATM)形式と MLP over Frame Relay(MLPoFR)形式の変換を行うためです。その結果、フレーム形式が、フレームリレー区間では両方向とも MLPoFR、ATM 区間では両方向とも MLPoATM になります。

トランスペアレント PVC は、方向によってオーバーヘッドが異なるためやや複雑です。このように複雑になる原因は、次のような仕組みにあります。フレームリレー ルータはパケットを MLPoFR 形式で送信し、IW デバイスはこの形式を ATM 側に持ち越します。同様に、ATM ルータはパケットを MLPoATM 形式で送信し、IW デバイスはこの形式をフレームリレー側に持ち越します。その結果、各区間で方向によってフレーム形式が異なることになります。

比較として、FRF.12 を使用するエンドツーエンド フレームリレー PVC のオーバーヘッドが 11 バイトであることに注目してください。このため、エンドツーエンド フレームリレー リンクでは、Link Fragmentation and Interleaving(LFI)に MLP を使用するよりも FRF.12 を使用する方が効率的です。エンドツーエンド ATM Virtual Circuit(VC; 仮想回線)では、利用可能な標準ベースのフラグメンテーションが存在しないため、MLP が唯一の選択肢となります。ただし、エンドツーエンド ATM VC は通常は中〜高速であるため、通常は LFI は不要です。ただし、Digital Signal Link(DSL)での低速 ATM VC は、この規則の例外となります。

PPP ID は最初の MLP フラグメントのみに存在する点に注意してください。したがって、最初のフラグメントのオーバーヘッドは、それ以降のフラグメントよりも常に 2 バイト大きくなります。

次の表は、VoIP パケットのデータリンク オーバーヘッドを示しています。ここでは、すべての FRF.8 動作モード、トラフィック方向、および PVC 区間の組み合せについて、フレームリレー、ATM、LLC、および PPP の各種ヘッダーのバイト数を詳しく示しています。データ パケットと VoIP パケットの主な違いは、VoIP パケットが MLP パケットではなく PPP パケットとして送信される点です。それ以外の点はすべてデータ パケットの場合と同じです。

FRF.8 モード トランスペアレント トランスレーション フレームリレーからフレームリレー
トラフィック方向 フレームリレーから ATM ATM からフレームリレー フレームリレーから ATM ATM からフレームリレー  
PVC のフレームリレー区間または ATM 区間 フレームリレー ATM ATM フレームリレー フレームリレー ATM ATM フレームリレー  
                   
フレーム フラグ(0x7e) 1 0 0 1 1 0 0 1 1
フレームリレー ヘッダー 2 0 0 2 2 0 0 2 2
LLC DSAP/SSAP(0xfefe) 0 0 2 2 0 2 2 0 0
LLC 制御(0x03) 1 1 1 1 1 1 1 1 1
NLPID(PPP は 0xcf) 1 1 1 1 1 1 1 1 1
PPP ID 2 2 2 2 2 2 2 2 0
ペイロード(IP+User Datagram Protocol(UDP)+RTP+音声) 0 0 0 0 0 0 0 0 0
AAL5 0 8 8 0 0 8 8 0 0
FCS 2 0 0 2 2 0 0 2 2
                   
オーバーヘッド合計(バイト) 9 12 14 11 9 14 14 9 7

比較のため、一番右の列に、エンドツーエンド フレームリレー PVC における VoIP パケットのデータ リンク オーバーヘッドを示します。

VoIP の帯域幅要件

VoIP の帯域幅をプロビジョニングする際は、帯域幅の計算にデータリンク オーバーヘッドを含める必要があります。次の表は、PVC の特性に応じた、各種 VoIP の 1 コールあたりの帯域幅要件を示しています。この表の計算では、cRTP について最良のケースのシナリオが想定されています(UDP チェックサムも伝送エラーも存在しないなど)。この場合、ヘッダーは常に 40 バイトから 2 バイトに圧縮されます。

FRF.8 モード トランスペアレント トランスレーション フレームリレーからフレームリレー
トラフィック方向 フレームリレーから ATM ATM からフレームリレー フレームリレーから ATM ATM からフレームリレー
PVC のフレームリレー区間または ATM 区間 フレームリレー ATM ATM フレームリレー フレームリレー ATM ATM フレームリレー
                   
G729 - 20 ミリ秒 サンプル - cRTP なし 27.6 42.4 42.4 28.4 27.6 42.4 42.4 27.6 26.8
G729 - 20 ミリ秒 サンプル - cRTP 12.4 21.2 21.2 13.2 12.4 21.2 21.2 12.4 11.6
G729 - 30 ミリ秒 サンプル - cRTP なし 20.9 28.0 28.0 21.4 20.9 28.0 28.0 20.9 20.3
G729 - 30 ミリ秒 サンプル - cRTP 10.8 14.0 14.0 11.4 10.8 14.0 14.0 10.8 10.3
G711 - 20 ミリ秒 サンプル - cRTP なし 83.6 106.0 106.0 84.4 83.6 106.0 106.0 83.6 82.8
G711 - 20 ミリ秒 サンプル - cRTP 68.4 84.8 84.8 69.2 68.4 84.8 84.8 68.4 67.6
G711 - 30 ミリ秒 サンプル - cRTP なし 76.3 97.9 97.9 76.8 76.3 97.9 97.9 76.3 75.8
G711 - 30 ミリ秒 サンプル - cRTP 66.3 84.0 84.0 66.8 66.3 84.0 84.0 66.3 65.7

オーバーヘッドは PVC の区間によって異なるため、最悪のケースのシナリオ向けに設定する必要があります。たとえば、トランスペアレント PVC で 20 ミリ秒サンプリングと cRTP を使用する G729 について考えてみます。フレームリレー区間におけるこのシナリオの帯域幅要件は、一方の方向では 12.4 Kbps、もう一方の方向では 13.2 Kbps です。したがって、1 コールあたり 13.2 Kbps を想定してプロビジョニングを行う必要があります。

比較のため、上記の表の一番右の列に、エンドツーエンド フレームリレー PVC における VoIP の帯域幅要件も示してあります。ネイティブのフレームリレー カプセル化と比べ、PPP のオーバーヘッドが追加される結果、帯域幅の消費量が 1 コールあたり 0.5 Kbps から 0.8 Kbps 多くなります。したがって、エンドツーエンド フレームリレー VC では、フレームリレー カプセル化に MLP を使用するよりも FRF.12 を使用する方が理にかなっています。

:cRTP over ATM には Cisco IOS バージョン 12.2(2)T 以降が必要です。

フラグメンテーション サイズの最適化

フレームリレー/ATM PVC で MLP を使用する理由は、大きなデータ パケットを小さなチャンクに分割できるようにするためです。これによりルータは、データ フラグメントの間に VoIP パケットをインターリーブすることで、VoIP パケットを高速に転送できます。Cisco IOS では、フラグメンテーション サイズを直接設定するのではなく、ppp multilink fragment-delay コマンドを使用して必要な遅延を設定します。これによって、対応するフラグメント サイズが次の公式に従って計算されます。

fragment size = delay x bandwidth/8

ATM 上で MLP を実行するときは、整数個のセルが収まるようにフラグメント サイズが最適化される必要があります。この最適化が行われなければ、パディングのために約 2 倍の帯域幅が必要となります。各フラグメントが 49 バイト長である場合を例にとると、1 つのフラグメントを伝送するために 2 つの ATM セルが必要となり、その結果 49 バイトのペイロードを伝送するために 106 バイトが使用されます。

現在、MLPoATM および MLPoFR を実行する際に整数個の ATM セルが収まるようフラグメント サイズが自動的に最適化される機能を、Cisco IOS に追加する作業が進行しています。この機能については、バグ ID CSCdu47933 で説明されています。この改良が実現すれば、計算されたフラグメント サイズが ATM セルの次の整数倍に自動的に切り上げられます。新たに追加される CLI コマンドはありません。Cisco IOS は、この最適化を MLPoFR/ATM PVC のフレームリレー側と ATM 側の両方で実行します。MLP PVC がエンドツーエンド フレームリレーの場合もあります。この場合は、ATM 用の最適化は不要です。しかし、Cisco IOS では、リモート エンドが ATM とフレームリレーのいずれであるかを知る手段がないため、この場合も ATM 用の最適化が実行されます。

注:丸めの結果、算出される遅延の値が設定よりやや高くなる場合があります。この丸め誤差は低速 PVC でより顕著になります。

上記の改良が実現するまでは、最適化を手動で行う必要があります。Cisco IOS ではフラグメント サイズを直接指定できないため、最適なフラグメント サイズを計算し、これを遅延に変換する必要があります。この計算を行う際はデータリンク オーバーヘッドを考慮する必要があります。これは、MLP コードではすべてのリンクが High-Level Data Link Control(HDLC; 高レベル データリンク制御)であり、2 バイトのデータリンク オーバーヘッドを持つものと想定されているためです。MLP コードの計算には、HDLC データリンク オーバーヘッドに加え、MLP ID、MLP シーケンス番号、および PPP ID からなる 8 バイトが含まれます(上記の最初の表を参照)。

Cisco IOS で設定する遅延を計算するには、次の手順に従います。

  1. 必要な遅延と PVC の帯域幅に基づいて、理論的なフラグメント サイズを計算します。
    fragment = bandwidth * delay / 8
  2. フラグメントは、整数個の ATM セルが収まるように 48 バイトの倍数にします。セルに合わせてフラグメント サイズを計算する公式は、次のとおりです。
    fragment_aligned = (int(fragment/48)+1)*48
  3. MLP によって考慮されないデータリンク オーバーヘッド分を補正します。前述したように、このオーバーヘッドは PVC の特性に応じて異なります。最適化の対象は PVC の ATM 側であるため、考慮する必要があるのは ATM 側のみです。次の表に、ATM 側のデータリンク オーバーヘッドのバイト数を示します。
  4. FRF.8 モード トランスペアレント トランスレーション
    トラフィック方向 フレームリレーから ATM ATM からフレームリレー フレームリレーから ATM ATM からフレームリレー
    PVC のフレームリレー区間または ATM 区間 ATM ATM ATM ATM
             
    LLC DSAP/SSAP(0xfefe) 0 2 2 2
    LLC 制御(0x03) 1 1 1 1
    NLPID(PPP は 0xcf) 1 1 1 1
    AAL5 8 8 8 8
             
    非 MLP オーバーヘッド(バイト) 10 12 12 12

    MLP での計算の基礎になるフラグメント サイズを算出するには、セルに合わせた必要なフラグメント サイズからデータリンク オーバーヘッドを差し引き、MLP で常に前提とされる HDLC カプセル化を補正するために 2 バイトを加えます。したがって、MLP コードの対象となるフラグメント サイズを計算する公式は次のようになります。

    fragment_mlp = fragment_aligned - datalink_overhead + 2
  5. 算出されたフラグメント サイズを、次の公式を使用して対応する遅延に変換します。
    delay = fragment_mlp/bandwidth x 8bits/byte
  6. ほとんどの場合、計算された遅延は整数のミリ秒になりません。Cisco IOS は整数値のみを受け入れるため、端数を切り捨てる必要があります。したがって、Cisco IOS で ppp multilink fragment-delay コマンドを使用して設定する遅延値は、次のようになります。
    fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)
  7. 上記の丸め誤差を補正するため、遅延からフラグメントに変換する際に MLP で使用される帯域幅に誤差を持たせます。誤差を持たせた帯域幅は次の公式で計算します。この公式で計算された帯域幅を、Cisco IOS で bandwidth コマンドを使用して設定します。
    bandwidth = fragment_mlp/fragment_delay * 8

参考資料として、一般的な PVC 速度での ppp multilink fragment-delay および bandwidth の最適値を次の表に示します。ターゲットの遅延には 10 ミリ秒を想定します。表を簡素化するため、トランスペアレント PVC とトランスレーション PVC の区別、およびトラフック方向による区別は行っていません。データリンク オーバーヘッドの差異は最大でも 2 バイトにすぎません。したがって、最悪のケースを考慮した 12 バイトのペナルティも大きなものではありません。この表には、整数個のセルが収まるようにフラグメント サイズを増やした場合の、「実際の」遅延も示されています。

PVC 速度 フラグメント サイズ ppp multi-link fragment-delay bandwidth 実際の遅延
(Kbps) (セル数) (ミリ秒) (Kbps) (ミリ秒)
56 2 12 57 13.7
64 2 10 68 12.0
128 4 11 132 12.0
192 6 11 202 12.0
256 7 10 260 10.5
320 9 10 337 10.8
384 11 10 414 11.0
448 12 10 452 10.3
512 14 10 529 10.5
576 16 10 606 10.7
640 17 10 644 10.2
704 19 10 721 10.4
768 21 10 798 10.5

トラフィック シェーピングおよびポリシングに関する注意事項

フレームリレー/ATM IW 環境におけるトラフィック シェーピングおよびポリシングには、特別な注意が必要です。フレームリレーから ATM の方向での問題は、ATM からフレームリレーの方向での問題と異なります。したがって、それぞれについて別個に説明します。

フレームリレーから ATM の方向での主な問題は、フレームからセルに移行する際に帯域幅消費が増大する可能性があることです。たとえば、フレームリレー側で 49 バイトのフレームは、ATM 側では 2 つのセル、すなわち 106 バイトを消費します。したがって、Sustainable Cell Rate(SCR; 平均セルレート)と Committed Information Rate(CIR; 認定情報レート)が等しいと見なすことはできません。最悪のケースは各フレームリレー フレームに 1 バイトのみのペイロードが含まれる場合で、この場合はこれらの 1 バイトごとに ATM 側で 53 バイトのセルが消費されます。これは概念を説明するための極端で非現実的なシナリオに過ぎませんが、このシナリオでは SCR が CIR の 53 倍になります。次に、より現実的な例を 2 つ示します。

  1. G729 VoIP パケットは 60 バイト長、MLP およびフレームリレー オーバーヘッドを含めて 69 バイトです。ATM 区間では、このパケットは 2 つのセル、つまり 106 バイトを消費します。したがって、伝送されるすべてのトラフィックが VoIP である場合、適切なマッピングは SCR = 106/69 = 1.5 x CIR です。
  2. 1 回のキーストロークを伝送する Telnet パケットには、40 バイトの TCP/IP ヘッダーと 1 バイトのデータが含まれます。フレームリレー側では、これはオーバーヘッドを含めて合計 56 バイトになります。しかし、ATM 側ではこのパケットが 2 つのセルに拡張されるため、このケースでは、SCR = 106/56 = 1.9 x CIR になります。

ATM フォーラム標準「BISDN Inter Carrier Interface (B-ICI) Specification Version 2.0」の Appendix A には、SCR と CIR 間のマッピング方法が 2 種類示されています。どちらも CIR から SCR を科学的に導く方法ですが、いずれの方法を適用しても、対象となるデータよりも正確であるわけではありません。これらの公式には一般的なフレーム サイズが必要ですが、実際のネットワークでこれを決定するのは難しく、また既存の ATM/フレームリレー ネットワークに新規アプリケーションが展開されれば、当然この数値は変化します。この問題を解決するために推奨される方法は、キャリアと緊密に協力することです。これは、キャリアのポリシング ポリシーがきわめて重要であるためです。キャリアの支援を得ることにより、次のフェールセーフ アプローチが可能になります。

  • フレームリレーから ATM の方向 - フレームリレーから ATM の方向では、キャリアはフレームリレー入力点のみで着信トラフィックをポリシングする必要があります。たとえば、フレームリレー接続の Customer Premises Equipment(CPE; 顧客宅内機器)デバイスに接続されたフレームリレー スイッチで、キャリアは契約 CIR に従ってトラフィックをポリシングできます。このポリシング ポリシーを次の図に示します。入力点でトラフィックのネットワークへの流入が許可された後は、それ以上のポリシングは行われません。このポリシング ポリシーで注意すべき点は、フレームリレー側で受信されたデータを、ネットワークの ATM 区間を通じて伝送するために、セル タックス、AAL オーバーヘッド、およびパディングの収容に必要な分だけ帯域幅を拡張し、消費できる点です。ほとんどの場合、必要な ATM 帯域幅は、使用されるフレームリレー帯域幅の 2 倍よりも少なくなります。

  • ATM からフレームリレーの方向 - ATM からフレームリレーの方向では逆のことが起こります。ATM セルがフレームに変換される場合は、セル タックス、AAL オーバーヘッド、およびパディングが除去されるため、帯域幅使用量が減少します。ただし、ATM 側で想定される送信レートはフレームリレー リンクよりはるかに高いため、音声の完全性を維持するためには、ATM ルータでトラフィック シェーピングを正確に設定することが不可欠です。シェーピングが緩やか過ぎる場合、ATM ルータによるデータ供給の速度が、フレームリレー リンクのもう一方の端における物理的な速度を上回る可能性があります。結果として、FRF.8 スイッチでパケットのキューイングが開始されます。その後、ある時点でパケットの廃棄が始まり、ATM/フレームリレー ネットワークでは音声とデータを区別できないことから、VoIP パケットも廃棄されます。

    その一方で、シェーピングが厳しすぎる場合はスループットが低下します。ATM セル タックスのため、AAL オーバーヘッドおよびパディングが FRF.8 デバイスによって除去されます。これにより、フレームリレー リンクではその分の帯域幅が消費されなくなります。したがって、実際には PVC の ATM 側では若干の加入過多が許容されます。パディングおよび AAL オーバーヘッドの量は、平均フレーム サイズや、フラグメンテーションがどれだけ積極的に行われているかに応じて異なります。このオーバーヘッドを正確に判断することは不可能なため、これについては最適化しようと考えない方が賢明です。これに対してセル タックスは完全に決定されていて、ペイロード 48 バイトごとに 5 バイトと決まっています。したがって、ATM ルータでシェーピング ターゲットを 53/48 x SCR に設定すれば、セル タックスに関する最適化が可能になります。当然、キャリア側のポリシングが、この若干の加入過多を許容するように設定されていることが必要です。

ヒントおよび注意事項

  1. MLPoATM/フレームリレーは現在テスト中であり、仮想テンプレートまたはダイヤラ インターフェイスに適用されたサービスポリシーでのみサポートされます。サービスポリシーを省略すると、機能が働かない可能性があります。CSCdu19313 に、この一例が示されています。
  2. MLPoATM/フレームリレーでは、PVC ごとに 2 つの仮想アクセス インターフェイスをコピーします。これらの一方は PPP リンクに対応し、もう一方は MLP バンドルに対応します。どちらがどちらに対応するかを調べるには、show ppp multilink コマンドを使用します。現在は、バンドルごとに 1 つのリンクのみがサポートされています。
  3. 各 PVC は 4 つの異なるインターフェイス、つまり物理インターフェイス、サブインターフェイス、および 2 つの仮想アクセス インターフェイスに関連付けられます。高度なキューイングを有効にできるのは、MLP 仮想アクセス インターフェイスのみです。他の 3 つのインターフェイスでは、First In First Out(FIFO; 先入れ先出し)キューイングを行う必要があります。
  4. service-policy コマンドを仮想テンプレートに適用すると、Cisco IOS によって次の通常警告メッセージが表示されます。
  5. cr7200(config)#interface virtual-template 1 cr7200(config-if)#service-policy output Gromit Class Based Weighted Fair Queueing (CBWFQ) not supported on interface Virtual-Access1 Note CBWFQ supported on MLP bundle interface only.

    これらのメッセージは異常を表すものではありません。最初のメッセージは、サービスポリシーは PPP 仮想アクセス インターフェイスではサポートされないことを警告しています。2 番目のメッセージは、MLP バンドル仮想アクセス インターフェイスでサービスポリシーが有効になったことを確認の意味で表示しています。このことは、show interface virtual-accessshow queue virtual-access、および show policy-map interface virtual-access コマンドを使用してキューイング メカニズムを確認することによっても確認できます。

  6. PVC は専用回線と同じようなものであるため、厳密な PPP 認証は不要です。ただし、PPP 認証には、show ppp multilink コマンドを使用して PVC のもう一方の端のルータ名を確認できるという便利な点があります。
  7. フレームリレー ルータでは、MLPoFR PVC に対してフレームリレー トラフィック シェーピングを有効にする必要があります。
  8. Cisco IOS バージョン 12.2 は、最初はルータ 1 台あたり最大 25 の仮想テンプレートをサポートしていました。すべての PVC が一意の IP アドレスを持つ必要がある場合、この制限が ATM ディストリビューション ルータのスケールに影響を与える可能性があります。該当するバージョンでは、回避策として IP 非番号制を使用するか、または仮想テンプレートの代わりにダイヤラ インターフェイスを使用できます。Cisco IOS バージョン 12.2(8)T 以降では、200 テンプレートまでサポートが増えています。
  9. サービス プロバイダーの中には、まだ自社の FRF.8 デバイスで PPP 変換をサポートしていないところがあります。この制限がある場合、プロバイダーは自社の PVC をトランスペアレント モードに設定する必要があります。
  10. Cisco IOS 文書のほとんどの例では、フレームリレーまたは ATM サブインターフェイスを含む構成が示されています。このサブインターフェイスは何の役割も果たしません。物理インターフェイスに仮想テンプレートを適用することをお勧めします。この方がよりコンパクトで管理が容易な構成になります。多数の PVC が存在する場合には、このことは特に重要です。
  11. キャリア側でセルまたはフレームの廃棄がないかどうかを確実に判別する方法は、show ppp multilink コマンドを使用することです。許容されるフラグメント損失は、Cyclic Redundancy Check(CRC; 巡回冗長検査)エラーが原因のものに限られます。
  12. MLPoATM/フレームリレーは Cisco IOS バージョン 12.1(5)T で導入されましたが、このリリースおよびその後のリリースにバグがあるため、Cisco IOS バージョンを選択するときには注意が必要です。原則として、Cisco IOS 12.2 メインストリームの最新のメンテナンス リリースを使用することをお勧めします。ただし、他の VoIP 機能の要件から、異なる Cisco IOS バージョンが必要となることがあります。たとえば、Survivable Remote Site Telephony(SRST)が必要な場合は 12.2(2)XT を使用する必要があります。次の表に、既知の問題の一部を示します。Cisco IOS を選択する際は、選択した IOS に対して各 DDTS を評価してください。
DDTS 説明
CSCdt09293 LFI- 7200 でのファースト スイッチングにより単方向音声コールが発生する
CSCdt25586 PPPoA アクセス フラッピングまたは Switched Virtual Circuit(SVC; 相手先選択接続)がアイドル タイムアウトでティアダウンしない
CSCdt29661 MLP- ファースト スイッチング中の ATM インターフェイスのシャットダウンによりルータがクラッシュする
CSCdt53065 ATM LFI 機能に関する atm_lfi コードのパフォーマンス改善
CSCdt59038 MLPoATM:PA-A3 で大きなパケットによる ping が失敗する
CSCdu18344 MLPoATM/フレームリレー PVC のスループットが SCR/CIR の半分に満たない
CSCdu19297 サービス ポリシーを使用しない場合、MLPoATM PVC でエラーが生成される
CSCdu41056 MLPoATM:ドライバ vc_soutput ルーチンが 2 回コールされる
CSCdu44491 MLPoFR で VirtualAccess カウンタが正しくない
CSCdu51306 PPPoX でキープアライブが途絶える
CSCdu57004 MLP 使用時に CEF が動作しない
CSCdu84437 MLP と tx-ring が調整されたドライバ間でのフロー制御の実装
CSCdv03443 Cisco IOS 12.2 での u76585 に関する修正のコミット - 着信 MLP パケットがプロセス交換される
CSCdv10629 MLPoATM:音声パケットが LLQ でキューイングされない
CSCdv20977 着信 MLP パケットがプロセス交換される
CSCdw44216 CBWFQ/LLQ リンクが輻輳状態になると、cRTP によって CPU の使用率が非常に高くなる

ケース スタディ

概要

この項では、MLPoATM/フレームリレー機能を最初にお客様に展開したときの一例について説明します。このお客様を、仮に Techno Ltd と呼びます。2001 年、Techno Ltd は自社の PBX を IP テレフォニー ソリューションに交換しました。このプロジェクトの一環として新しい IP ネットワークが構築され、WAN にはフレームリレー/ATM インターワーキングが選択されました。WAN サービスを提供するキャリアは、Newbridge スイッチを使用して ATM およびフレームリレー サービスを提供しています。

ネットワークの概要

Techno Ltd のネットワークは、26 のブランチを 2 つのコア サイトで接続するハブアンドスポーク ネットワークです。各コア サイトでは、E3 ATM が接続された Cisco 3660 ルータを使用します。26 のブランチのうち 18 は中程度の規模でデュアル フレームリレー PVC を持ち、ATM/フレームリレー IW を経由して 2 つのコア サイトの 3660 に接続します。残りの 8 つのブランチはごく小規模で、単一フレームリレー PVC を経由して最も近い中規模ブランチに接続します。ブランチ ルータはすべて Cisco 2620 です。エンドツーエンド ATM PVC はそれぞれ 2 つのハブ サイトの 2 台の 3660 ルータに接続します。次の図にトポロジを示します。

次の表は、フレームリレーのアクセス速度と CIR を示しています。CIR は 32 kbps から 256 kbps までさまざまです。また、各 PVC が伝送する同時 VoIP コールの最大数も示しています。

サイト リモート サイト アクセス(kbps) CIR(kbps) コール数
ブランチ 1 コア 1 320 192 6
ブランチ 2 ブランチ 22 128 64 2.0
ブランチ 3 コア 1 576 256 8.0
ブランチ 4 ブランチ 16 64 32 2.0
ブランチ 5 コア 1 128 64 2.0
ブランチ 6 ブランチ 3 64 32 2.0
ブランチ 7 コア 1 512 256 8.0
ブランチ 8 コア 1 512 256 8.0
ブランチ 9 ブランチ 13 128 64 2.0
ブランチ 10 コア 1 256 128 4.0
ブランチ 11 コア 2 128 96 2.0
ブランチ 12 コア 1 128 64 2.0
ブランチ 13 コア 1 768 256 12.0
ブランチ 14 コア 1 192 96 4.0
ブランチ 15 コア 1 192 96 4
ブランチ 16 コア 1 448 192 8
ブランチ 17 ブランチ 13 128 64 2
ブランチ 18 コア 1 128 96 2
ブランチ 19 ブランチ 16 128 64 2
ブランチ 20 コア 1 64 32 2
コア 2 コア 1 34000 256 12
ブランチ 21 ブランチ 13 128 64 2
ブランチ 22 コア 1 384 192 6
ブランチ 23 コア 1 512 256 8
ブランチ 24 コア 1 192 96 2
ブランチ 25 コア 1 128 96 4
ブランチ 26 ブランチ 1 64 32 2

フレームリレー トラフィック シェーピングはブランチ ルータによって実行されます。CIR を超えるバーストは許容されます。Cisco IOS トラフィック シェーピングでは、mincir を CIR と同じ値とし、アクセス速度にシェーピングするように設定されています。Backward Explicit Congestion Notification(BECN; 逆方向明示的輻輳通知)がキャリアから送信された場合、ルータによって mincir が抑制されます。この方法は、VoIP over Frame Relay を実行する場合のシスコの推奨事項に反します。これは、ルータが輻輳通知に応答したときには、すでに音声に問題が生じているためです。しかし、このケースでは、ネットワークで十分な帯域が提供されているためフレームやセルが廃棄されることはなく、したがって BECN が発生することはないとキャリアが確信しています。

ATM トラフィック シェーピングは、セル タックスを加えたリモート エンドのフレーム アクセス速度でシェーピングするように設定されています。たとえば、アクセス速度が 512 Kbps であれば、SCR は 512x53/48 = 565 Kbps に設定されます。このシェーピング レートは、スループットを最大化するために使用されます。セル タックスは IW ポイントで除去されるため、このシェーピング レートは安全と考えられます。キャリア側のポリシングは、若干の加入過多が許容されるように余裕をもって設定されています。

cRTP は WAN 全体を通じて使用されます。CPU 使用率の最も高い箇所は、コア サイト 1 の Cisco 3660 ディストリビューション ルータです。上記の表のコール数を合計すると、このルータを通過する VoIP コールの理論的な最大数が 102 コールであることがわかります。次のグラフのパフォーマンス値から、(ファースト スイッチングされる)100 の cRTP セッションに対する Cisco 3660 の CPU 負荷は約 50 % です。

IP 番号制 WAN リンクでは仮想テンプレートが使用されます。各 PVC に 1 つの仮想テンプレートが必要ですが、個々の Cisco 3660 で終端する PVC の総数は 25 未満であるため、これは可能です。

設定

この文書では次に示す設定を使用しています。

コア ATM ルータ
!--- 注:このセクションでは、コア Cisco 3660 ルータの設定のうち、
  !--- MLPoATM に関係のある部分のみを示します。
  
  class-map match-all Voice_Stream
  match access-group 100
  class-map match-all Voice_Control
  match access-group 101
  
  policy-map toortr01
  class Voice_Stream
  priority 175
  class Voice_Control
 bandwidth 18
 random-detect
  
  interface ATM2/0
 description To Carrier E3 ATM Service
 no ip address
  
  interface ATM2/0.15 point-to-point
 pvc toortr01 0/58
  vbr-nrt 406 406
  tx-ring-limit 8
  protocol ppp Virtual-Template15
  
  interface Virtual-Template15
 bandwidth 320
 ip address 10.16.0.105 255.255.255.252
 ip tcp header-compression iphc-format
 service-policy output toortr01
 ppp multilink
 ppp multilink fragment-delay 14
 ppp multilink interleave
 ip rtp header-compression iphc-format
  

ブランチ フレームリレー ルータ
!--- 注:このセクションでは、ブランチ Cisco 2600 ルータの設定のうち、
  MLPoFR に関係のある部分のみを示します。
  
  class-map match-all Voice_Stream
  match access-group 100
  class-map match-all Voice_Control
  match access-group 101
  
  policy-map dhartr21
  class Voice_Stream
  priority 240
  class Voice_Control
 bandwidth 18
 random-detect
  
  interface Serial0/0
 description To Carrier Frame Relay Service
 encapsulation frame-relay IETF
 frame-relay traffic-shaping
  
  interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 38 ppp Virtual-Template1
  class dhartr21
  
  interface Virtual-Template1
 bandwidth 320
 ip address 10.16.0.106 255.255.255.252
 max-reserved-bandwidth 85
 service-policy output dhartr21
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave
  
  map-class frame-relay dhartr21
 frame-relay adaptive-shaping becn
 frame-relay cir 320000
 frame-relay bc 3200
 frame-relay mincir 320000
  
  

ツール情報

その他のリソースについては、シスコの「ボイス、テレフォニー、およびメッセージング テクノロジー用の TAC ツール」を参照してください。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報

関連トピック

その他の文書


Document ID: 25084