第 10 部
マルチキャスト 通信

301

第1章

はじめにMC WG では、JP Mbone コミュニティーと連係し 、日本国内の MBONE の運用に携わり、トラフィック監視やツールの開発を行い、安定運用に貢献している。ここでは、JPMbone の現状を述べ、MC WG が提供している統計収集技術とその情報を報告する。また、
WIDE 大手町 NOC で行なっている multicast exchange project について報告する。

303

第2章

国内のMBONE の現状

まず、日本国内の MBONE アクティビティーを統計情報で示す。表 2.1は、1998 年 4 月27 日現在の、JP MBONE に接続されているルータと組織の数である。
表 2.1: JP MBONE ルータと組織数

ac.jp ad.jp co.jp go.jp gr.jp or.jp ne.jp etcJP notJP NA
82371614704012158251395040011213 116
3816704016 25121672595040056(etcJP = その他の jp 、notJP = jp 以外、 NA = DNS 未登録)

合計
組織数

(active)
ルータ数(active)

この調査は、DVMRP ASK NEIGHBORS2 の IGMP を用いて mbone.otemachi.wide.ad.jpから順に threshold が 64 未満の範囲をたどっていくことで得られるデータを元に算出した。
次に、JP Mbone で使われているマルチキャストルータの種類を表 2.2に示す。
表 2.2: JP MBONE ルータの種類 (1998 年 4 月 27 日)
ルータの種類数

11.1PM
11.2PM
11.3PM
3.255PGM
3.8PGM
not active

992505192
213

合計304

第 10 部

マルチキャスト 通信305

現在 JP MBone において使われているマルチキャストルータの種類は、大半が mrouted3.8および mrouted3.9 であり、一部の組織で cisco IOS version 11 が使われていると推測される。表 2.2中の version 3.255 は、そのルータが DVMRP version3 に従っていることを示し 、実際には、それらはほとんどが mrouted3.9 であると思われる。
JP MBone における経路問題の解決および現状の把握をするため、JP MBone 以外とのリンクや、ループ構造を持つ部分に関係する国内主要ルータについては接続トポロジ図を常に最新の状態にあわせ維持している。ここ 1 年では、新たに SINET とタイとの国際リンクが設けられたほか、国内でも一部主要ルータ間の接続が変更され経路が変わるなどの変化があった。このようすを表 2.3に示す。
表 2.3: JP MBONE のトポロジ (1998 年 4 月 27 日)

Loopback0.MB1.SJC1.Alter.Net --- Loopback0.MB1.SFO1.Alter.Net| 5,1/64
pim| 5/64maew-mbone.nsn.nasa.gov
dec3800-2-fddi-0.SanFrancisco.mci.net
mr.ai3.net||
mbone.nectec.or.th| 1/64| 5,1/64| 1/64
1/64 |%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% boundary 239.133/16 %%%%%%%%%%%|||||
mroute00.iij.ad.jp --- sw01.tokyonet.ad.jp||| 6,3/32 / 1/32|
| mbone.otemachi.wide.ad.jp ---- mbone.nc-u-tokyo.ac.jp ---- totoro.sinet.ad.jp|| 1/32\ 1/32
1/32||
sun1.tokyo.wide.ad.jp --- mbone.imnet.ad.jp -----------------------||| 1/32|\ 1/32| 1/32
1/32|
mr.nara.wide.ad.jp | 1/32---- ftp.cfi.waseda.ac.jp
|
|
|
4/32
|
1/32 | jp-gate.wide.ad.jp --- handshake.gw.kyoto-u.ac.jp --------------||| 1/32/ 3/32
1/32|
sun15.kyoto.wide.ad.jp ---- aki.csi.ad.jp ---- saijo.csi.ad.jp ------|| 9/32 8/32
1/32
1/32 |
sun1.fukuoka.wide.ad.jp ---- nic.karrn.ad.jp -------------------------|
1/32
1/32
また、MBONE 全体で調査したルータ数とルータの種類を表 2.4 と表 2.5に示す。

1997 年度 WIDE 報告書306

表 2.4: MBONE ルータと組織数
ド メイン

arpa
com
edu
gov
mil
net
org
brca
hk
id
in
jp
krru
sg
thtn
us
NA
合計

ルータ数

1122460
152
81391
26
1735
121183
90
372
19302
1886

ルータ数 (active)

054344
113
56283
14
10290
20110
37
16103921155

組織数19911321810421924
11179634216504組織数 (active)

03880
17779
1241901055
414103325

第 10 部

マルチキャスト 通信

表 2.5: MBONE ルータの種類
ルータの種類

数

1.0
2.2
3.3
3.6PGM
3.8PGM
3.38PGM
3.255PGM
10.2
10.3
11.0M
11.0PM
11.1PM
11.2PM
11.3PM
NG
TOTAL

62
1
7311
2136
1314153312
268
29731
1886307

3章
MBONE 上のト ラフィック収集と監視技術
第3.1

統計情報収集システムの必要性

マルチキャストネットワークを運営していくにあたって、特に注意を払わなければならないのは既存の運用ネットワークに対して過大な負荷をかけないということである。そのためには、マルチキャストトラフィックを常に監視する必要がある。
WIDE インターネット内のマルチキャストトラフィックの配送では、マルチキャストルー
タに mrouted を使用しているため、各拠点において mrouted に対してシグナル SIGUSR1を送って得られるダンプファイルを解析し 、仮想インタフェース (以下、VIF) 毎に送受信されたパケットの量、バイト数を計測できる。
ある地点のトラフィック量を計測できるが、ネットワーク全体のトラフィックの流れを計測するには、各ルータでこのようなファイルを記録する必要があり、作業が繁雑である。同時に、管理ポリシー的に受け入れられない場合も多い。
このような問題を認識し 、リモート監視を容易にするために、マルチキャストルーティ
ングソフトウェアとして、SNMP によって統計データを取得できる mrouted を利用して統計情報の収集実験を行なった。WIDE バックボーンの mrouted のすべてで SNMP 対応がなされている。
mrouted の最新バージョンである mrouted3.9beta3 では、SNMP 対応が行われていない
ため、Merit によるバージョン 3.8 の SNMP 化を参考にし 、WIDE 内で SNMP 化を行った。(ftp://ftp.kyoto.wide.ad.jp/multicast/mrouted/snmp-mrouted/)
当初は perl で作成したスクリプトによって、トラフィック監視を行っていたが、次のような三つの要求が出てきた．

 トラヒックの履歴を残したい 問題点がより明瞭になる形で表現したい 情報を公開することで、分散トラブルシューティングを促したい
これらの要求に対応するため、World Wide Web によって、統計情報の履歴をリアルタイムで公開するとともに、JP-MBone におけるトラヒックの流れの概略のフロー図を作成、提示することした。

308

第 10 部

3.2

マルチキャスト 通信

309

システム構成各拠点における統計情報のグラフ化はスイス工科大学 Tobias Oetiker 氏によって製作された MRTG という可視化ソフトウェアを使用した。(http://ee-staff.ethz.ch/~oetiker/

webtools/mrtg/mrtg.html)

JP-MBone におけるトラヒックのフロー図の作成にあたっては、小野秀貴氏 (京都大学工学部電子工学科) によって製作された makefeedmap を使用した。(http://www.tamaru.kuee.

kyoto-u.ac.jp/ ono/tools/makefeedmap/)
リンクの生成、消滅に関しては、定期的ポーリングによって自動的に対応が行われるようになっている。

3.3

統計情報の収集例

3.3.1

大手町 NOC におけるト ラフィック

mbone.otemachi.wide.ad.jp における 1998 年 4 月 27 日の統計情報を図 3.1から示す。

図 3.1: 大手町 MEX 間

図 3.2: 大手町 IBMNET 間

310

1997 年度 WIDE 報告書

図 3.3: 大手町 IMNET 間

図 3.4: 大手町東京大学間図 3.5: 大手町 MESH 間

第 10 部

マルチキャスト 通信

図 3.6: 大手町 INFOSPHERE 間

図 3.7: 大手町 IIJ 間

図 3.8: 大手町青梅間

311

312

1997 年度 WIDE 報告書

図 3.9: 大手町 SINFONY 間図 3.10: 大手町東京 NOC 間

図 3.11: 大手町 TOKYONET 間

3.3.2

海外リンクのト ラフィック

東京ネットと MCI の間の JP Mbone のトラフィックを図 3.12から図 3.13に示す。

第 10 部

マルチキャスト 通信

図 3.12: 海外トラフィック (1 日の変化)

図 3.13: 海外トラフィック (1 週間の変化)

図 3.14: 海外トラフィック (1 か月の変化)

313

1997 年度 WIDE 報告書314

図 3.15: 海外トラフィック (1 年間の変化)

3.3.3

流量図

MBONE のトラフィックのフロー解析を行ったものを図 3.16 および図 3.17に示す。

3.4

考察

本システムによって、non prunning router の早期発見と、World Wide Web を用いた分散監視を行えるようになった。
また、統計情報を継続的に記録することによって、正しく運用がなされたマルチキャス
トネットワークのサービスクオリティはロスレートなどの点において、非常に高いことが改めて確認された。
しかしながら、現システムには次のような問題点がある。

 統計情報の記録単位が VIF であるということ- グループ毎の情報が有効である場合が多い o 統計情報データベース形式- 現状では MRTG 固有のデータベースであるが、再利用性を考慮した形式を用意すべきである

 SNMP 対応の mrouted のみしか対応していない- SNMP 対応がなされていない mroutedや、専用ルータの扱いが考慮されていない
これらに関しては、今後の課題としたい。

第 10 部

マルチキャスト 通信

図 3.16: 1998 年 4 月 27 日 03:50 における流量図

315

316

1997 年度 WIDE 報告書

図 3.17: 1998 年 4 月 27 日 16:52 における流量図

4章
multicast exchange project
第ISP 間の接続の整理および商用 ISP の新規接続を促すため、1997 年 3 月に WIDE 大手町
NOC に mbone.otemachi.wide.ad.jp を設置し 、主に NSPIXP2 を経由して各 ISP との間を順次トンネルにより接続を行なってきた。これを、multicast exchange project phase I と呼ぶ。
しかし 、この方法は、mbone.otemachi.wide.ad.jp を中心とした放射型の接続トポロジとなっているため、次のような構造上の基本的な問題があった。

 各 ISP 同士のやりとりが必ず WIDE 経由の間接やりとりになっている。
 常に mbone.otemachi.wide.ad.jp を通過するため、そこが過負荷になる。
 もしも mbone.otemachi.wide.ad.jp が落ちると、すべて切断されてしまう。
 すべての接続がトンネル利用であり、また、mbone.otemachi.wide.ad.jp はユニキャ
スト的には各 ISP に対してルータでないため、すべてのトンネリングのパケットが出入り口である１つの物理インタフェースに集中し 、トンネル数が増えるとともに比例する形で通過するトラフィックが増えてしまう。

そこで、これらの問題を解決するため multicast exchange project phase II として 100BaseTXのセグメントを新規に設置し 、そこへ各 ISP のマルチキャストルータを接続することでそれらが直接マルチキャストパケットをやりとりできるようにする新たな研究実験計画を打ち出した。JP MBone コミュニティへ以下の文書を提案し 、現時点で 12 の ISP より実験参加の希望が出ている。
『 multicast exchange project phase II について』目的:
国内における複数 ISP 間での IP マルチキャスト接続交換の研究のため接続実験運用を行なう。
期間:

317

1997 年度 WIDE 報告書

318

特に厳密な期間は定めず臨機応変に対応するが、およそ一年後をめどに大きく見直すとともに、必要であれば更に継続するものとする。
経緯:
国内の MBone トポロジの整理を目的に、1997 年 3 月、おもに当時増えてきた商用 ISP のマルチキャストルータを接続するための基幹ルータとしてmbone.otemachi.wide.ad.jp を NSPIXP2 近傍に設置し 、これと複数のISP のルータ間をそれぞれトンネリングにて接続してきた。これを、multicast exchange project の phase I とする。今回のものはそれを改善発展させて行なう phase II として位置づける。

phase I での問題点:
接続のトポロジ的に mbone.otemachi.wide.ad.jp を中心とした放射型となっているため、・各 ISP のルータが直接パケットをやりとりする形になっていない。
・必ず mbone.otemachi.wide.ad.jp を通るため、そこが過負荷になる。
・万が一 mbone.otemachi.wide.ad.jp が落ちると、すべて切れてしまう。
・すべてがトンネリングであり、また、mbone.otemachi.wide.ad.jp はユニキャスト的にはルータでないため、すべてのトンネリングのパケットが１つの物理インタフェースに集中し 、トンネル数が増えるとともに通過するトラフィックが増えてしまう。などといった、構造上の基本的な問題があった。
その他の問題点:
phase I での問題を解決するには、たとえば 、NSPIXP2 などにおいて各接続ルータが同時にマルチキャストルータとしてもふるまい、NSPIXP2 上においてマルチキャストの交換もしてしまえばよい。
しかし 、現在の状況では NSPIXP2 に各 ISP が接続している専用ルータ、たとえば 、cisco などにおいて同時にマルチキャストのルーティングをやらせるには負荷的に問題ありと判断している管理者が多い。また、
各 ISP が実際に対外接続マルチキャストルータとして用意している物はPC やワークステーションでの mrouted ベースの物が多い。
今回の接続構成:
マルチアクセスのメディアのセグメントを 1 つ新たに用意し 、各 ISP のマルチキャストルータをそのセグメントにすべて接続する。
そして、そのセグメントにおいてそれら複数のマルチキャストルータが

第 10 部

マルチキャスト 通信直接マルチキャストパケットをやりとりするようにする。ただし 、このセグメントを越えてのユニキャストの交換は一切行なわない。
今回の構成は、現在国内の MBone に接続している ISP の多くがたまたまNSPIXP2 などがある KDD 大手町ビル内にハウジングしており、同時に対外マルチキャストルータもそこに設置している例が多かったため、その特殊な環境を利用して上記のセグメントを NSPIXP2 近傍に設置する。
セグメントを構成するマルチアクセスのメディアとして、今回は100BaseTX を採用する。これは、多くの ISP のマルチキャストルータを接続して本格的利用が始まると 10Base ではすぐに飽和が予想されることと、現在において PC などで 100Mbps 級を構成するのにもっとも安価なものは100BaseTX と思われるためである。また、これに伴い、ここに接続される各 ISP のマルチキャストルータ間については rate limit を撤廃する。

NSPIXP プロジェクトとの関係:今回必要となるセグメントの設置場所および機材などについてはNSPIXP プロジェクトが提供し 、今回のは NSPIXP 関連プロジェクトとしても位置づけられる。
（現在調整中）ただし 、この multicast exchange project への参加についてはオープンとし 、NSPIXP プロジェクトに参加しているかど うかに関わらず、自由に参加できる。

JP MBone コミュニティとの関係:
今回の実験運用において出てくる諸問題および議論や成果などはJP MBone コミュニティ内（実際には mbone-jp メーリングリスト ）においてオープンに行なう。つまり、今までと同様に JP MBone の一部としてみんなで運用管理の調整を協調的に行なっていくものとする。
物理的接続について:
今回の接続参加にあたっては、その物理的制約により、設置する 100BaseTXセグメントの HUB の所までカテゴ リ 5 ケーブルなどを延ばしてこれることが事実上参加に必要な条件となる。ただし 、光ファイバなどで HUB の近くまで延ばしてきて小さな変換器などで変換するなどの方法は交渉次第で可能。
各参加 ISP のマルチキャストルータから HUB へのケーブル敷設など 、現場での作業についてはみんなで調整して行なう方が効率がよいことも多いため、物理的な接続などについてのみ調整や話し合いを行なうメーリングリストを新たに設置する。それ以外の、マルチキャストルータ

319

320

1997 年度 WIDE 報告書
間のやりとりや設定、その他 MBone 諸問題についての議論は、mbone-jp メーリングリスト上においてオープンに行なう。
なお、今回の物理的接続による制限のために参加できない ISP については
今まで通り mbone.otemachi.wide.ad.jp にてトンネリングによる接続を行なうため、JP MBone への接続は引き続き保たれる。新規接続も受け付ける。

参加費用について:今回の phase II において必要となる費用は分担を必要とするほど 高額ではないため、NSPIXP および WIDE プロジェクトが場所や HUB などを用意する。
そのため、参加をする各 ISP は HUB までの接続だけ用意すれだけでよい。
ただし 、今後の運用実験を進めていく上で、費用のかかる、より高度な実験環境を構築することになった場合については、別途決めることとする。