音声 : Voice over Frame Relay(VOFR)

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

2016 年 10 月 28 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2002 年 10 月 30 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

ATM 上のマルチリンク PPP およびフレーム リレー上のマルチリンク PPP は Cisco IOS で(MLPoATM および MLPoFR)導入されましたか。 ソフトウェア リリース 12.1(5)T。 この機能は、Frame Relay/ATM Interworking(FR/ATM IW)を利用し、中~低速 WAN リンクで Voice over IP(VoIP)を導入するお客様を対象としています。 この機能前に、FR/ATM IW の ATM およびフレーム リレー 顧客両方の Cisco IOS によってレイヤ3 フラグメンテーションをさせるサポートされたよくあるレイヤ2 断片化スキームがありませんでした。

前提条件

要件

この資料は MLPoATM およびフレームリレーネットワークを含む VOIPネットワークの設計および配備に関連するネットワーキング 担当者のために意図されています。 次の項目に関する知識があることが推奨されます。

  • フレーム リレー

  • ATM

  • PPP

  • MLP

  • Frame Relay/ATM インターワーキング

  • 音声 Quality of Service (QoS) 設定

この資料はこれらのサブジェクトでテクノロジートレーニングを提供するように意図されていません。 このドキュメントの末尾に参考資料のリストがあります。 Cisco はこの資料を読む前にこれらの文書を検討し、理解することを推奨します:

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • FR/ATM IW 上の MLP のための Cisco IOS ソフトウェア リリース 12.1(5)T またはそれ以降

  • ATM 上の Compressed Real-Time Transport Protocol (cRTP)のための Cisco IOS ソフトウェア リリース 12.2(2)T またはそれ以降

  • フレーム リレー上の低遅延キューイング(LLQ)および物理インターフェイスの ATM のための Cisco IOS ソフトウェア リリース 12.0(7)T

  • LLQ over Frame Relay のための Cisco IOS ソフトウェア リリース 12.1(2)T および相手先固定接続(PVC)ごとの ATM

この資料に含まれているケーススタディはこれらのソフトウェア および ハードウェア バージョンを使用する実稼働 ネットワークに基づいています:

  • コア Cisco 3660 ルータ実行 Cisco IOS ソフトウェア リリース 12.2(5.8)T。 ATM 上の cRTP のための要件は Cisco IOS ソフトウェア リリース 12.2T.の使用を定めます この既知の問題は Cisco IOS ソフトウェア リリース 12.2(8)T1 で解決されます:

    Class-Based Weighted Fair Queueing (CBWFQ) /LLQ リンクが輻輳に達するとき Cisco バグ ID により CSCdw44216登録ユーザのみ) - cRTP 高CPU を引き起こします。

  • ブランチ Cisco 2620 ルータは Cisco IOS ソフトウェア リリース 12.2(3)から 1 2.2(6a) へアップグレードの過程においてあります。 Cisco 2620 はまたブランチ H.323 ゲートウェイとして機能します。 アップグレードはゲートウェイ関連の問題によって引き起こされます。 WAN および QoS 機能まで、Cisco IOS ソフトウェア リリース 12.2(3)表わしません重要な問題をかかわられています。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

設計

このセクションはフレーム リレーおよび ATM 上のマルチリンク PPP の設計および配備に関する複数の設計思想を論議します。

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

MLP の ATM およびフレームリレーネットワークを設計するとき、データ・リンク オーバーヘッドを理解して下さい。 オーバーヘッドは、各 VoIP コールによって消費される帯域幅の量に影響を与えます。 それはまた最適 MLP フラグメントサイズの判別を助けます。 かなりの帯域幅がセルのパディングで浪費される低速 PVC の ATM セルの整数に、特に合うためにフラグメントサイズを最適化することは重要です。 フレームリレーおよび ATM PVC での MLP におけるデータリンク オーバーヘッドは、次の要素によって決まります。

  • FRF.8 IW デバイスの動作モード(トランスペアレントまたはトランスレーション)。

  • トラフィックの方向(ATM からフレームリレー、またはフレームリレーから ATM)。

  • PVC 区間。 オーバーヘッドは、PVC の ATM 区間とフレームリレー区間で異なります。

  • トラフィック タイプ。 データパケットは 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/SSAP1 (0xfefe) 0 0 2 2 0 2 2 0
LLC 制御(0x03) 1 1 1 1 1 1 1 1
NLPID2 (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

1DSAP/SSAP — 送信先アクセスポイント/送信元サービス アクセス ポイント。

2NLPID — Network Layer Protocol Identification。

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

トランスペアレント PVC は、方向によってオーバーヘッドが異なるためやや複雑です。 この複雑な状況はフレームリレールータが MLPoFR 形式のパケットを送信するので起こります。 この形式は ATM 側に IW デバイスによって運ばれます。 同様に、ATMルータは MLPoATM 形式のパケットを送信します。 この形式はフレームリレー側に IW デバイスによって運ばれます。 その結果、各区間で方向によってフレーム形式が異なることになります。

相対的に、FRF.12 を使用するエンドツーエンドフレームリレー PVC のオーバーヘッドは 11 バイトです。 従って、エンドツーエンドフレームリレー リンクで、FRF.12 は MLP より Link Fragmentation and Interleaving (LFI)のための効率的選択です。 エンドツーエンド ATM Virtual Circuit(VC; 仮想回線)では、利用可能な標準ベースのフラグメンテーションが存在しないため、MLP が唯一の選択肢となります。 ただし、エンドツーエンド ATM VC は高速に中間です。 従って、LFI が必要となりません。 このルールへの例外は Digital Subscriber Line (dsl)上の低速 ATM VC です。

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

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

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 のための帯域幅を提供するとき、データ・リンク オーバーヘッドは帯域幅計算に含んでいる必要があります。 この表は VoIP のさまざまなフレーバーのためのコール帯域幅必要条件ごとの示したものです。 それは PVC の特性に基づいています。 この表の計算は cRTP のための最高の状態 シナリオを想定します(たとえば、UDP チェックサム無しおよび伝送エラー無し。) この場合、ヘッダーは常に 40 バイトから 2 バイトに圧縮されます。

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

オーバーヘッドは PVC の区間によって異なるため、最悪のケースのシナリオ向けに設定する必要があります。 たとえば、透過的な PVC を渡る 20 ミリ秒(ミリ秒)サンプリングおよび cRTP との G.729 を考慮して下さい。 フレームリレー区間におけるこのシナリオの帯域幅要件は、一方の方向では 12.4 Kbps、もう一方の方向では 13.2 Kbps です。 コール毎に 13.2 キロビット/秒を考慮してされるプロビジョニング必要。

相対的に、エンドツーエンドフレームリレー PVC の VOIP帯域幅要件はまた上の表の右端 カラムで示されています。 ネイティブのフレームリレー カプセル化と比べ、PPP のオーバーヘッドが追加される結果、帯域幅の消費量が 1 コールあたり 0.5 Kbps から 0.8 Kbps 多くなります。 従って、FRF.12 のフレーム リレー エンカプセレーションはエンドツーエンドフレームリレー VC で MLP よりより多くの理にかなっています。

ATM 上の cRTP は Cisco IOS ソフトウェア リリース 12.2(2)T またはそれ以降を必要とします。

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

フレームリレー/ATM PVC の MLP を使用する原因はより小さいチャンクにフラグメント化することを大きいデータパケットを可能にすることです。 ルータはデータの フラグメントの間にそれらを入れ込むことによってそれから VOIPパケットを促進します。 Cisco IOS では、フラグメンテーションサイズは直接設定されません。 その代り、望ましい 遅延は ppp multilink fragment-delay コマンドの助けによって設定されます。 Cisco IOS はそれから適切なフラグメントサイズを計算するのにこの数式を使用します:

fragment size = delay x bandwidth/8

ATM を渡る MLP をするとき、フラグメントサイズはセルの整数に合うように最適化される必要があります。 この最適化が行われない場合、必要な帯域幅がほとんどパッディングが原因で倍増できます。 たとえば各フラグメントが長く 49 バイトなら、2 人の ATM セルが各フラグメントを運ぶために必要となります。 従って 49 バイトだけのペイロードを伝送するのに、106 バイトが使用されています。

Cisco IOS は自動的に MLPoATM および MLPoFR を行うとき ATM セルの整数を使用するためにフラグメントサイズを最適化します。 Cisco IOS は ATM セルの次の整数に自動的に計算されたフラグメントサイズを四捨五入します。 新たに追加される CLI コマンドはありません。 Cisco IOS は MLPoFR/ATM PVC のフレーム リレーおよび ATM 終わり両方のこの最適化を行います。 MLP PVC がエンドツーエンドフレームリレーである場合もあることは可能性のあるです。 この場合、ATM のためにそれを最適化することが必要となりません。 ただし、Cisco IOS はリモート エンドは ATM またはフレーム リレーであるかどうか検出する方法がないので ATM のためのこのシナリオを最適化します。

四捨五入が原因で、生じる遅延は設定されるそれよりわずかに高い場合もあります。 この丸 めの 誤差は低速 PVC でより重要です。

また最適化を手動で設定することができます。 フラグメントサイズが Cisco IOS で直接規定 され、最適フラグメントサイズを計算し、遅延に変換できないので。 フラグメントサイズを計算するとき、各リンクはハイレベル データ リンク コントロール(HDLC)である仮定し、2 バイトのデータ・リンク オーバーヘッドがあると MLP コードはように、データ・リンク オーバーヘッドを調節して下さい。 HDLC データ・リンク オーバーヘッドに加えて、MLP コードは 8 バイトが MLP ID より構成した計算、MLP シーケンス番号および上で最初の表にある PPP ID に含んでいます。

Cisco IOS で設定されるべき遅延を計算するためにこのプロシージャを使用して下さい:

  1. 必要な遅延と PVC の帯域幅に基づいて、理論的なフラグメント サイズを計算します。

    fragment = bandwidth * delay / 8
  2. フラグメントは、整数個の ATM セルが収まるように 48 バイトの倍数にします。

    セルが割り当てたフラグメントサイズを計算する数式は次のとおりです:

    fragment_aligned = (int(fragment/48)+1)*48
  3. MLP によって考慮されないデータリンク オーバーヘッド分を補正します。

    先に見られるように、このオーバーヘッドは PVC 特性に基づいて異なります。 これが最適化する側であるので PVC の ATM 側を考慮して下さい。 この表は ATM 側のデータ・リンク オーバーヘッドのバイト数を示したものです。

    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
  4. 対応したへの結果がこの数式と遅らせるフラグメントサイズを変換して下さい:

    delay = fragment_mlp/bandwidth x 8bits/byte
  5. ほとんどの場合、計算される遅延はミリ秒の整数ではないです。 Cisco IOS は整数値のみを受け入れるため、端数を切り捨てる必要があります。 従って、ppp multilink fragment-delay コマンドの助けによって Cisco IOS で設定する遅延値は次のとおりです:

    fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)
  6. 上記の丸 めの 誤差を補正するために、遅延からフラグメント化するために変換するのに MLP によって使われる帯域幅を避けて下さい。 bandwidth コマンドの助けによって Cisco IOS で設定する避けられた帯域幅は次のとおりです:

    bandwidth = fragment_mlp/fragment_delay * 8

この表は ppp multilink fragment-delay の最適値およびもっとも一般的な PVC 速度のための帯域幅を示したものです。 ターゲットの遅延には 10 ミリ秒を想定します。 表を簡素化するために、計算は透過的な、翻訳 PVC、または場周 飛行 方向を区別しません。 データリンク オーバーヘッドの差異は最大でも 2 バイトにすぎません。 したがって、最悪のケースを考慮した 12 バイトのペナルティも大きなものではありません。 またフラグメントがセルの整数に合うようにフラグメントサイズを増加するというファクトが見つけられた原因である「実質」遅延は表で示されています。

PVC 速度 フラグメントサイズ ppp multi-link fragment-delay 帯域幅 実際の遅延
(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)が認定情報レート (CIR)に匹敵すること仮定することができません。 最悪 の 場合は各フレームリレーフレームが 1 バイトのペイロードが含まれていると実行されます。 これらのバイトのそれぞれは ATM 側の完全な 53 バイト セルを消費します。 この概念の一例として、この極度で、非現実的なシナリオは CIR 53 倍のである SCR を定めます。 次に、より現実的な例を 2 つ示します

  • G.729 VOIPパケットは(MLP およびフレーム リレー オーバーヘッドが含まれているとき) 60 バイト長く、または 69 バイトです。 ATM レグで、それは 2 人のセルか 106 バイトを消費します。 従って運ばれるすべてのトラフィックが VoIP なら、そして適切なマッピングは SCR = 106/69 = 1.5 x CIR あります。

  • Telnet パケットは単一 キーストロークを運ぶ 40 バイトの TCP/IP ヘッダーおよび 1 バイトのデータが含まれています。 フレームリレー側では、これはオーバーヘッドを含めて合計 56 バイトになります。 ただし、ATM 側でこのパケットは 2 人のセルに拡張します。 この場合、SCR = 106/56 = 1.9 x CIR。

ATMフォーラム規格の付録 A は、BISDN 内側キャリア インターフェイス(BICI)仕様 バージョン 2.0、SCR と CIR 間のマッピングの 2 つのメソッドを記述します。 両方とも CIR から SCR を得る科学的な方法を提供する間、どちらも適用するデータよりもう正確です。 数式によって必要な数の 1 つが典型的なフレームサイズ、実質ネットワークで判別しにくいの数です。 また、新規アプリケーションが既存の ATM/Frame リレー ネットワークで転送されると同時に可能性としては変更できる数。 この問題を解決するために推奨される方法は、キャリアと緊密に協力することです。これは、キャリアのポリシング ポリシーがきわめて重要であるためです。 キャリアの支援によって、このフェイル・セイフ アプローチは可能性のあるです:

  • ATM 方向へのフレーム リレー- ATM 方向へのフレーム リレーでは、キャリアはフレームリレー の 入力点だけで受信 トラフィックのポリシングを行なう必要があります。 たとえば、フレーム リレーによって接続される Customer Premises Equipment (CPE) デバイスに接続されるフレームリレースイッチでキャリアは引き締められた CIR に従ってトラフィックのポリシングを行ないます。 このポリシング ポリシーは図でここに説明されます。 それ以上のポリシングはトラフィックが入力点のネットワークに許可されれば起こるはずではないです。 このポリシング ポリシーで注意すべき点は、フレームリレー側で受信されたデータを、ネットワークの ATM 区間を通じて伝送するために、セル タックス、AAL オーバーヘッド、およびパディングの収容に必要な分だけ帯域幅を拡張し、消費できる点です。 ほとんどの場合、必要な ATM 帯域幅が使われるフレーム リレー 帯域幅より二度小さいです。

    http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-ingress-policing.gif

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

    その一方で、シェーピングが厳しすぎる場合はスループットが低下します。 ATM セル タックスのため、AAL オーバーヘッドおよびパディングが FRF.8 デバイスによって除去されます。 これにより、フレームリレー リンクではその分の帯域幅が消費されなくなります。 従って、PVC の ATM 側をわずかにオーバーサブスクライブできます。 パディングおよび AAL オーバーヘッドの量は、平均フレーム サイズや、フラグメンテーションがどれだけ積極的に行われているかに応じて異なります。 正確にこのオーバーヘッドを修飾できないのでそれのために最適化することをどちらにしても試みないことです。 一方では、セルタックスは完全に決定論的です。 それは 48 バイトのペイロード毎に 5 バイトです。 セルタックスのために 53/48 の x SCR に ATMルータのシェーピング ターゲットの設定によって最適化できます。 キャリア側のポリシングはこのわずかな加入超過を可能にするために設定 する必要があります。

ヒントおよび注意事項

  • MLPoATM/フレームリレーは現在テスト中であり、仮想テンプレートまたはダイヤラ インターフェイスに適用されたサービスポリシーでのみサポートされます。 サービス ポリシーを省略するにより機能は動作します場合があります。 これの 1 つの例は Cisco バグ ID CSCdu19313登録ユーザのみ)で文書化されています。

  • MLPoATM/フレームリレーでは、PVC ごとに 2 つの仮想アクセス インターフェイスをコピーします。 これらの 1 つは PPP リンクを表します。 他は MLP バンドルを表します。 show ppp multilink コマンドがどれはかであるかどれ告げるのに使用されています。 バンドルごとの PPPoFR 複数のリンクはサポートされません。 1 バンドル トラフィックに 2 つの PPPOFR 回線を入れることは PPPOFR ドライバが実質シリアル ドライバがフロー制御 シグナリングを提供しないので回線を渡ってよくバランスをとられたロードではないです。 ATM またはフレーム リレー上の MLPPP ロード バランシングは物理インターフェイス上の同じロード バランシングよりより少ない効果を著しく示すかもしれません。

  • 各 PVC は 4 つの異なるインターフェイス、つまり物理インターフェイス、サブインターフェイス、および 2 つの仮想アクセス インターフェイスに関連付けられます。 MLP 仮想アクセスインターフェイスだけ有効に なる 高度 な キューイングがあります。 他の 3 つのインターフェイスでは、First In First Out(FIFO; 先入れ先出し)キューイングを行う必要があります。

  • バーチャル テンプレートに service-policy コマンドを適用するとき、Cisco IOS はこの正常な警告メッセージを表示する:

    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 interfaces virtual-accessshow queue および show policy-map interface コマンドの助けによってキューイング機構をチェックする確認されます。

  • PVC は専用回線と同じようなものであるため、厳密な PPP 認証は不要です。 ただし、PPP認証は show ppp multilink コマンドが PVC の反対側でルータの名前を判別するのに使用されているので便利です。

  • フレームリレー ルータでは、MLPoFR PVC に対してフレームリレー トラフィック シェーピングを有効にする必要があります。

  • Cisco IOS ソフトウェア リリース 12.2 は最初に最大ルータ毎に25のバーチャルテンプレートをサポートしました。 すべての PVC が一意の IP アドレスを持つ必要がある場合、この制限が ATM ディストリビューション ルータのスケールに影響を与える可能性があります。 該当するバージョンでは、回避策として IP 非番号制を使用するか、または仮想テンプレートの代わりにダイヤラ インターフェイスを使用できます。 Cisco IOS ソフトウェア リリース 12.2(8)T では、サポートは 200 のバーチャルテンプレートに増加します。

  • サービス プロバイダーの中には、まだ自社の FRF.8 デバイスで PPP 変換をサポートしていないところがあります。 この制限が課される時はいつでも、プロバイダは透過モードのための PVC を設定する必要があります。

  • Cisco IOS ドキュメントのほとんどの例では、フレームリレーまたは ATM サブインターフェイスを含む構成が示されています。 このサブインターフェイスは目的を機能しません。 バーチャルテンプレートは物理インターフェイスにちょうど接続する必要があります。 結果はコンパクトで管理しやすい設定です。 これは多数の PVC がある場合特に重要です。

  • キャリア側にセル/フレーム ドロップがあったかどうか確認するきわめて簡単な方法として show ppp multilink コマンドを使用して下さい。 許容されるフラグメント損失は、Cyclic Redundancy Check(CRC; 巡回冗長検査)エラーが原因のものに限られます。

  • MLPoATM/フレーム リレーが Cisco IOS ソフトウェア リリース 12.1(5)T で導入されたが、Cisco IOS ソフトウェア リリースを選択するときこののバグおよび後続のリリースはその心配を奪取 されます定めます。 Cisco は Cisco IOS 12.2 主流のメンテナンスリリースを使用するために推奨します。 ただし、他の VoIP 機能要件は Survivable Remote Site Telephony (SRST)が必要となる場合 12.2(2)XT のような別の Cisco IOS ソフトウェア リリースの使用を、定めることができます。 この表はいくつかの既知の問題をリストしたものです。 『Cisco IOS』 を選択 するとき、各 Cisco バグ ID は選択された IOS に対して評価する必要があります。

シスコ バグ ID 説明
CSCdt09293登録ユーザのみ LFI- 7200 の原因 1 方法音声コールのファースト スイッチング。
CSCdt25586登録ユーザのみ アイドルタイムアウトで中断 されない PPPoA アクセス フラッピングか相手先選択接続 (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 ルーチン。
CSCdu44491登録ユーザのみ VirtualAccess は MLPoFR の不正確に逆らいます。
CSCdu51306登録ユーザのみ PPPoX で壊れるキープアライブ。
CSCdu57004登録ユーザのみ CEF は MLP を使用しません。
CSCdu84437登録ユーザのみ MLP と Tx リング間のフロー制御 実装はドライバを調整しました。
CSCdv03443登録ユーザのみ Cisco IOS の u76585 のための修正を託して下さいか。 ソフトウェア リリース 12.2 -着信 MLP パケットは切り替えられるプロセスです。
CSCdv10629登録ユーザのみ MLPoATM: 音声パケットは LLQ でキューに入りません。
CSCdv20977登録ユーザのみ 着信 MLP パケットはプロセスを切り替えられて得ています。
CSCdw44216登録ユーザのみ CBWFQ/LLQ リンクが輻輳に達するとき cRTP により高CPU を引き起こします。
CSCdy70337登録ユーザのみ QoS サービス ポリシーの MLP バンドルが使用中である時。
CSCdx71203登録ユーザのみ MLP バンドルは時折少数の非アクティブ リンクがあるかもしれません。

ケース スタディ

概要

この項では、MLPoATM/フレームリレー機能を最初にお客様に展開したときの一例について説明します。 顧客は架空名義 XYZ Ltd.によって参照されます 2001 年に、XYZ Ltd は IPテレフォニーソリューションと PBX を取り替えました。 このプロジェクトの一部として、新しい IPネットワークは構築されました。 そして Frame Relay/ATM インターワーキングは WAN のために選択されました。 WAN サービスを提供するキャリアは ATM およびフレームリレー サービスを提供するのに Newbridge スイッチを使用します。

ネットワークの概要

XYZ Ltd ネットワークは 2 つのコアサイトと 26 のブランチを接続するハブ・アンド・スポーク ネットワークです。 各コア サイトでは、E3 ATM が接続された Cisco 3660 ルータを使用します。 26 のブランチの 18 は中規模です。 ATM/Frame リレー IW によって 2 つのコアサイトで 3660s に戻って接続するそれらに二重フレーム リレー PVC があります。 残りの 8 つのブランチは非常に小さいです。 それらはシングルフレームリレー PVC を通って最も密接で中規模 な ブランチに戻って接続します。 すべてのブランチルータは Cisco 2620 です。 ンドツーエンド ATM PVC はそれぞれ 2 つのハブ サイトの 2 台の 3660 ルータに接続します。 この図はトポロジーを説明します。

http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-network.gif

この表はフレームリレーアクセス速度および CIR を示したものです。 CIR は 32 キロビット/秒から 256 キロビット/秒をから変えます。 また、各 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 256 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.0
ブランチ 16 コア 1 448 192 8.0
ブランチ 17 ブランチ 13 128 64 2.0
ブランチ 18 コア 1 128 96 2.0
ブランチ 19 ブランチ 16 128 64 2.0
ブランチ 20 コア 1 64 32 2.0
コア 2 コア 1 34000 256 12.0
ブランチ 21 ブランチ 13 128 64 2.0
ブランチ 22 コア 1 384 192 6.0
ブランチ 23 コア 1 512 256 8.0
ブランチ 24 コア 1 192 96 2.0
ブランチ 25 コア 1 128 96 4.0
ブランチ 26 ブランチ 1 64 32 2.0

フレームリレー トラフィック シェーピングはブランチ ルータによって実行されます。 CIR を超えるバーストは許容されます。 Cisco IOS トラフィックシェーピングは CIR と等しい mincir とのアクセス 速度に、形づくために設定 されます。 逆方向明示的輻輳通知(BECN)がキャリアから受信される場合、ルータは mincir に戻って絞ります。 このアプローチは Cisco推奨に対して VoIP over Frame Relay をするときあります。 音声はトラブルにルータが輻輳通知に対応したまでに既にあっています。 しかし、このケースでは、ネットワークで十分な帯域が提供されているためフレームやセルが廃棄されることはなく、したがって BECN が発生することはないとキャリアが確信しています。

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

cRTP は WAN 全体を通じて使用されます。 CPU に関する限りではホットスポットはコアサイト 1.に Cisco 3660 ディストリビューションルータです。 上の表の数の追加によって、VOIPコールの数理論上の最高値がこのルータを横断する 102 の呼び出しであることが判別されます。 (ファースト交換である)このグラフからのパフォーマンス 番号はのための Cisco 3660 CPU負荷が 100 cRTP セッションおよそ 50%であることを示します。

http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-3660-performance.gif

IP 番号制 WAN リンクでは仮想テンプレートが使用されます。 各 Cisco 3660 で終端させる PVC の総数が25より小さいので可能性のあるである PVC ごとに 1 つのバーチャルテンプレートが必要となります。

設定

このドキュメントでは、次の設定を使用します。

コア ATM ルータ

!--- Note: This section shows the parts of a core Cisco 3660 router 
!--- configuration that is relevant to 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 loopback0
 ip address 10.16.0.105 255.255.255.252

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 unnumbered loopback0
 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


!--- Note:  Do not configure 
!--- IP addresses directly on any configuration source, 
!--- such as a virtual template, whenever the possibility 
!--- exists that this information  is cloned to multiple 
!--- active interfaces. The exception to this rule is the 
!--- rare case where the intent is to define multiple parallel 
!--- IP routes and have IP do load balancing between them. 
!--- If an IP address is present on the configuration source, 
!--- this IP address  is copied to all the cloned interfaces.
!---  IP  installs a route to each of these interfaces.
 

ブランチ フレームリレー ルータ

!--- Note: This section shows the parts of a branch Cisco 2600 router 
!--- configurations that is relevant to 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 loopback0
 ip address 10.16.0.106 255.255.255.252

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 unnumbered loopback0
 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


関連情報


Document ID: 25084