Meeting Log - 11/21
--- ここから ---
(22B)九州ギガポッププロジェクト 21日15:00-16:30
チェア： 平原 正樹 (九州システム情報技術研究所)
-------------------------------------------------------------------------
・九州ギガポッププロジェクト紹介
- いつものミーティングををopenにすることで連携を取ろう
- 研究開発用のネットワーク
- 商用NETで出来ないこと
- SINETで出来ないこと
- インフラとして色々な企業や大学を繋げる → 共同研究
- 国際インターネット測定
- QOSプロジェクト(インターネットTVとVODシステム、IPA、後藤)
- 天秤、DNSを用いた負荷分散
- リングサーバ
・九州ギガポッププロジェクトupdate
- 天神(堀)
- 11月に開設、順次接続
- 福岡市の繁華街
- NTTCOMにハウジング
ラック一本(定価月130000円)
福岡のインターネットの拠点ビル
2階にJGN、IMNETの福岡NOC
- 天神、ISIT、九大を高速回線で結ぶ
- JGN、その他のプロジェクトとの接続
- ルーティング
QGPOPでフルルートのAS
- 九大
- IIJ - 九大 - ISIT(ATM)
|
天神(ATM)
- 小倉、八幡 (ATM)
- 香川大と接続予定
- kisho 九大NOCのルータ
- ben 九大のルータ
- v6は?
福岡 WIDE NOC のルータ、 まだどこからもらうか考えてない
九大内は ben
- 佐賀大はまだ繋がっていない
- ISIT & 無線
- 無線LAN
周りに色々な会社
福岡タワー(2.4GHz)
会社にも133.69.0.0を割り当てる
- ルーティング
IBGPを使っている(zebra)
IIJからフルルート
マルチキャストはPCルータでmrouted
IMNETとトンネルで繋がる予定
kishoでフルルート
天神GRからも外にいくことができる
何故DVMRP?
実装が無い、gatedを買いたい
MRTにはOSPFが無い
どういう箱があるといいのか?
CISCO?
Mboneでオンラインカンファレンスを早急にやりたい
二重化の話し
九大でkishoとPCとでフルメッシュ
24時間落ちないもの(GR) →
ルーティングを保証しない(PC) →研究として(RSVP、IPv6等)
IMとピアリング?
できると思う
zebraでフルルート
vmstat -m
カーネルのルーティングテーブルメモリ
128Mであふれて256Mで大丈夫
GRは25万経路まで大丈夫
現在は7万経路
kishoは9万経路
3台全部で受けるの?
IIJからは一台
PVCを増やしてBGPを喋るマシンのリブートを防ぐため
- 北九州(岡村)
- 佐賀、熊本、大分、長崎
・ITRCインフラグループ
- 133.69.0.0/16
/16でIIJ、IMNET、APANへアナウンス
現在QGPOPで/16の1/4を使っている
- 富山(中川)、 京都(岡部) MDX
富山
JGM上で繋がっていこう
externalは使ってもいいのでしょうか?
京都
技術的な調整が必要(ルーティング)
WCNには流すつもり
IBGPで頑張る
----------------
ITRC.NETを133.69に戻すのは?
いいと思います
133.69の逆引きのサーバは今はQGPOPにある
富山(RIBB)用のJGNのリンクは11/24にあがる
JGN上のVCがセットアップ
----発表-----------------------------------------------------------------
タイトル：H.323多地点制御装置とスパースモードマルチキャストの融合による
規模適応性に優れたマルチキャストネットワーク会議の実現
氏名 ：焼山 康礼
所属 ：九州大学大学院システム情報科学府 情報工学専攻
□ 内容
H.323 多地点制御装置とスパースモードマルチキャストの融合による
規模的旺盛に優れたマルチキャストネットワーク会議の実現
1.背景
・IPネットワーク会議の普及
- インターネットにおけるネットワーク会議
* Mbone マルチキャストネットワーク会議
* H.323
* SIP
- アプリケーション
* vic/vat(Mbone Tools)
* NetMeeting(H.323)
* CU-SeeMee(独自仕様)
・H.323によるネットワーク会議
- H.323プロトコル
* ITU-T勧告
* 1対1コネクションレス型電話プロトコル
H.323 端末
/ \
/ \
H.323 端末------------ H.323 端末
- 例: NetMeeting IP電話
・H.323 + MCU
- H.323多地点ネットワーク会議-MCUの導入
・MCUの概要
- H.323プロトコルにた地点会議の機能を追加
- 機能
* MC
多地点会議におけるコール制御調整機能を提供
* MP
オーディオストリームのミキシング
ビデオストリームのミキシングと選択
- 実装例
* MeetingPoing(White PIne Software Inc.)
* H.323プロと個kるスタック(RADVision Inc)
* OpenMCU
・H.323会議における問題点
- MCUの規模適応性における問題
* H.323端末-MCUは1対1接続
* 大部分のMCUはユニキャスト通信のみサポート
↓
ユーザ数の２乗に比例して使用帯域が増加
2.目的
- MCU + スパースモードマルチキャスト
* MCU コアとスパースモードマルチキャストRPの組合せ
3.スパースモードマルチキャスト
- 送信持とからのマルチキャストデータグラムをRPに集約
- RP から各メンバにマルチキャストデータグラムを送信
- メンバが存在するネットワークセグメントのみに、マル
チキャスト経路木の枝を作成
* ルータの経路情報の削減
↓
マルチキャストの規模適応性の拡大
- プロトコル
* PIM-SM←本研究では PIM-SM を使う
* CBT
4.MCU+PIM-SM RP組合せ方式
- 結合型
* MCU と RP を１つのノードに結合
H.323端末
\
ルータ
\
RP
/ \
/ \
ルータ ルータ
/ \
H.323端末 H.323端末
- 分離型
* MCU と RPを２つのノードに分離
H.323端末
\
ルータ
\
MCU-----RP
/ \
/ \
ルータ ルータ
/ \
H.323端末 H.323端末
5.考察
- 結合型
* 管理が容易
* 特定ノードへの付加集中(MCU+RP)
→ネットワーク全体に障害発生
- 分離型
特定ノードへの負荷を分散
MCU-RP間のデータストリームが重複
→MCU-RP間ネットワークの広帯域化(２倍)にすれば解決
6.まとめ
- H.323-MCU と PIM-SM RPの組合せ方式を提案
- MCU と RP の分離が適切であると考察
・今後の課題
- PIM-SMのH.323多地点会議ネットワークへの組み込み
結論
分離型がよい
今後
開発、評価実験
・Q&A
Q: 図においてRPを通る必要は無いなら2倍にならない
A: そうですね
Q: データを受け取って配送するのはMCUなのでデータ量は同じなのでは?
Q: 負荷も増えないのでは?
Q: 分離するメリットは?
Q: マルチキャストのインフラがあって何故H.323?
A: IP電話など色々なソフトから使える
Q: 全部ユニキャストでやっても高々2倍なのでは?
c: 規模が大きいときは誰が発言者を決めるのが大切
c: 問題設定をきちんと行う
-------------------------------------------------------------------------
