- - PR -
メッシュ型ネットワークの帯域制御について
1
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2005-04-13 14:57
度々お世話になります。
ＱｏＳについて教えてください。 フルメッシュ型ネットワーク（具体的には広域イーサネット）で接続する複数 拠点で一般データ（Ｗｅｂアクセスなど）と音声データを帯域制御しながら 流したいと思っています。 データの流れは、一般データは本社中心の論理的スター型、音声データは拠点間 通信もあるため、フルメッシュ型となります。 ネットワーク網側では何もＱｏＳがない仕様のため、ルータでＱｏＳを設定 するしかないのですが、どのようなＱｏＳにすればよいか悩んでおります。 これまでの本社中心のスター型ネットワークであれば、本社、拠点ともに相手 毎（１：１）にデータ用帯域64k、音声用帯域64kのような形で帯域設定 できたと思いますが、メッシュ型の場合どのように設計したらよいでしょう？ 例えば、８拠点のネットワークの場合、全拠点の送出側で音声用帯域64kを 確保、データ用帯域をベストエフォートといったＱｏＳにしたとしても、受信側 では、音声だけでも最大64k×７＝448kが流れ込み、もし契約帯域が128k の場合、網内（キャリア網→アクセス回線に入る部分）でパケット廃棄が発生 し、音声品質に影響が出ると思われます。 何とかルータのＱｏＳ設定のみで音声品質を確保したいのですが何か良い 方法はないでしょうか？ どなたか良きアドバイスをお願いします。 |
|
投稿日時: 2005-04-14 10:16
おはよう御座います。
広域Ethernetでは完全な帯域制御は出来ません。 各拠点にあるルータで設定を行うぐらいしか出来ないと思います。 そこで、出てくるのが客先との折衝です。つまり、８拠点あるからといって、 他の７拠点が同時に１つの拠点に対して音声を流す事があるかと言う事です。 同時にせいぜい３拠点ぐらいとなれば、必要となる帯域は１９２Kとなります。 これを超える場合については音声品質に歪が出る事を了承してもらいます。 また、同時にデータも流すようですが、このデータで使用する帯域と音声の 帯域を併せた帯域をその拠点に必要となる帯域となりますので、それに併せた 回線を選択する必要があります。 選択可能な回線が必要帯域以下の場合はどうあがいても音声品質等を確保する ことは出来ないので、選択した回線速度によって発生する弊害についても 了承してもらう必要があります。 このケースの場合、ネットワーク側の設定だけでは限界があるので、実際の運用面 で、回避してもらう必要があるので、客先との折衝しだいになると思います。 |
|
投稿日時: 2005-04-14 14:20
お世話になっております。mi8といいます。
よろしくお願いいたします。 ---くおんさん引用--- 広域Ethernetでは完全な帯域制御は出来ません。 各拠点にあるルータで設定を行うぐらいしか出来ないと思います。 ---引用終わり--- 一部キャリアからはCoSを利用した網内からの帯域制御機能がありますね。 http://www.ntt-vpn.com/e-vlan/service/opt_qps.html ---nori77さん引用--- 例えば、８拠点のネットワークの場合、全拠点の送出側で音声用帯域64kを 確保、データ用帯域をベストエフォートといったＱｏＳにしたとしても、受信側 では、音声だけでも最大64k×７＝448kが流れ込み、もし契約帯域が128k の場合、網内（キャリア網→アクセス回線に入る部分）でパケット廃棄が発生 し、音声品質に影響が出ると思われます。 ---引用終わり--- 128Kの回線に448Kのトラヒックが流れ込む場合、どんなＱｏＳを設定しても、フレーム（パケット）破棄は発生しますよね。 音声の1chあたりの帯域を何Kに設定しているか分かりませんが、PBX等で、拠点間のchを絞り込む形になるのではないかと思います。 認識間違い等ございましたら、ご指摘頂きたくお願いいたします。 よろしくお願いいたします。 |
|
投稿日時: 2005-04-20 16:40
いろいろ教えていただき、ありがとうございます。
広域イーサネット網内での帯域制御は難しそうですね。 さて、広域イーサネット網自体はフルメッシュ型構成ですが、音声、データ共に 論理的スター型構成にするという案はどうでしょう？ 具体的には、拠点間ネットワークは広域イーサネットのままで、PBX（SIPサーバ）を センター拠点のみに配置し、センター拠点で7拠点分の総帯域（各拠点128kなら、 センター帯域896k以上）を確保、センター側のルータで対地毎の帯域制御を行う という形を検討してみたのですが、どうでしょう？ この構成が可能なら、網内（キャリア網→アクセス回線に入る部分）でパケット廃棄も 発生せず、音声品質も確保できると思います。 素人考えなので、音声パケットも全てセンター拠点（センター拠点のルータ）経由で 流すというのが、技術的に可能かどうか等々不安な点も多々あるのですが・・・ （構成案） ・各拠点のルータで拠点間通信のルーティングは設定せず、センター拠点向け のルーティングだけを設定。 ・センター拠点では各拠点向けのルーティングを設定。 ・本社ルータから各拠点（７対地）向けに、送出側のシェーピング＋WFQを設定。 シェーピングは各拠点（７対地）向けに128k設定。 WFQ制御はPBX（SIPサーバ）からの音声パケットを最優先、他のパケットは ベストエフォート扱いとする。 |
|
投稿日時: 2005-04-21 18:29
本筋の議論と関係ないのですが、音声帯域を64kで計算するのは間違いです。
G.711と仮定します。 音声データは10msごとに80バイト生成されます。 80バイトを1RTPパケットにするとそれごとに40バイトのIPヘッダがつきますから、1パケットは120バイトになります。結果96Kぐらいに膨らみます。100K ぐらい見ておいた方がよいかもしれません。 80バイトのデータを２つ、３つまとめ、それぞれ、20msごと、30msごとに送出することもでき、この場合RTPは200バイトを20msごと、280バイトを30msごとに送出されることになります。 G.729などは８Kですが、これもIPヘッダによるオーバヘッドはあり、IPヘッダのサイズの方が大きかったりします。 _________________ 目が、目が......... かゆいよー 帯域制御といったらあとはRTPを生成する機器とルータをすべてdiffserv対応のものにするとかですかね。 [ メッセージ編集済み 編集者: 帰ってきた・元祖・真･冬の妖精 ほろりん 編集日時 2005-04-21 18:38 ] |
|
投稿日時: 2005-04-21 22:50
こんばんわ。
G.711の６４Kbps、G.729aの８Kbpsは伝送帯域で、実行伝送帯域は送出間隔を元に 計算する必要がありますね。 さらにいうと、広域Ethernetなどの帯域はL2レベルの帯域になるのでEtherフレーム の部分（確か１４バイトだったと思う）を加算して計算した方がよいかもしれません。 送出間隔はEtherRealなんかで見れば判ると思います。 nori77さんの案 経路についてはそれで問題ありません。それ以外についてはいけそうな気はしますが、使用するVoIP GWを含めそれなりに検証が必要と思います。 場合によってはVPNを張った方がより確実かもしれません。 |
|
投稿日時: 2005-04-21 23:40
あ、確か、L2ヘッダとIPヘッダを入れて40バイトだと思った。＞未確認
あと、もうひとつ重要なのが、パケットの遅延というかパケット間隔の揺らぎです。受信側の音声機器ではジッタバッファというのがあって一定時間、たとえば300msとかの時間分のRTPを溜め込みます。これはパケットが一定間隔でこないときに備えるためです。もし、このバッファを越える時間間隔でパケットくれば、音声が切れるし、バッファに吸収しきれないほど間隔がつまってくるとパケットが落ちる。ジッタバッファを大きく取れば問題ないかと言うと、たとえば、10秒分とると、｢もしもし｣と話したのが相手に10秒後に聞こえる。 誰かが回線に大きなデータを流せば、当然遅延は起きるし、そうなれば、回線上はパケットが落ちてないのに、間隔があいて相手が受けきれないことがおきる。 ルータとかが溜め込んだりすることもあるし。 ------- EtherealでL2ヘッダ＋IPヘッダをみると34バイトみたい。 なんで40バイトと思ってたんだ。>自分。 ＃何か根拠があるはずだが。。 [ メッセージ編集済み 編集者: 新世紀真最終無敵爆裂万能機動妖精ほろりん 編集日時 2005-04-25 12:11 ] |
|
投稿日時: 2005-05-17 19:19
かなり昔のスレへの回答ですいませんが、RTPの「ヘッダが40バイト」の根拠はここを見てください。
http://www.atmarkit.co.jp/fnetwork/rensai/voip02/01.html TCPヘッダ＝20バイト UDPヘッダ＝8バイト RTPヘッダ＝12バイト 合計40バイト いじょ |
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。