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

235

第 1章マルチキャスト 通信

1.1

MBone

は 、IP マルチキャストを用いた実験のため Internet 上に仮想的に作られたネットワークである。当初 1992 年 3 月に San Diego で行なわれた IETF においてその会議の模様を Internet 上に放送するために始められた [?]。その後も継続的な IP マルチキャストの実験基盤としてメーリングリスト mbone@isi.edu などを通して協調的に実験運営されている。その後の IETF 会議などの中継を重ねるごとに参加組織数、参加国数とも増加しており、現在は 40 以上の国々に広がって 3000 以上のサブネットが接続されている。また、従来は非マルチキャストルータを越すために多くの部分がトンネルを用いて構成されていたが、主な専用ルータがマルチキャストをサポートしつつあり、隣接ルータ同士がユニキャストと同様、マルチキャストを直接やりとりするリンクが増えているため、もはや仮想ネットワークという名はふさわしくなくなってきている。
このような中で、MBone は IETF 会議やその他会議の中継だけでなく、そのスケーラビリティや双方向にインタラクティブ利用できる特徴を生かし 、各種イベントの中継やセミナーや私的な会合などの運営に利用されている。そして、その利用者も従来のネットワー
ク研究者中心から一般のユーザへと広がっている。また、ネットワーク関係のハード ウェ
ア及びソフトウェア会社などど 16 社が集まり、1996 年 9 月に IP Multicast Initiative というマーケッティングと教育に関するフォーラムが結成されるなど 、商用的な動きも盛んになってきている。
MBone

1.2

関連する主な IETF ワーキンググループを支える技術の多くは IETF の各ワーキンググループで開発されてきている。ここでは、密接に関連するワーキンググループうちから主なものとして MBONED, IDMR,AVT, MMUSIC の四つについて述べる．
MBONED (MBONE Deployment) ワーキンググループは、主にインターネットにおけるマルチキャスト経路制御プロトコルの開発・技術・運用を行ない調整していくことを目的としている。1996 年 6 月に Montreal で行なわれた IETF 会議において BOF が開かれ、MBone237

238

1996 年度 WIDE 報告書

月にワーキンググループになった。活動として種々のガイド ラインの作成や文書化なども進めており、pruning できない古いルータを 10/31 までに MBone からなくすことを定めたインターネットド ラフト [?] を出している。これにより、mrouted 3.3 以前の実装 (およびそれに相当する実装) を MBone では現在使ってはいけないので注意が必要である。
IDMR (Inter-Domain Multicast Routing) ワーキンググループは、広大な MBone 空間上にグループメンバーがちらばっていたり、大規模なグループ数においても適用できるようなド メイン間マルチキャスト経路制御プロトコルについて議論し 、標準を提案することを目的として活動している。そして、新しく PIM (Protocol Independent Multicast) [?] や CBT(Core Based Tree)[?] などのプロトコルを開発して成果として出している。また、IGMP(Internet Group Management Protocol)[?] についても現在使われている version2[?] の仕様や、現時点でまだもっとも多く使われている DVMRP (Distance Vector Multicast RoutingProtocol)[?] についても現在使われている version3[?] の仕様を定め、それに従った実装である mrouted などの開発が ISI などで行われている。
AVT (Audio/Video Transport) ワーキンググループは 、MBone 上のリアルタイムオー
ディオおよびビデオコミュニケーションすべてについての問題を扱っている。リアルタイム性を持った通信を支援するトランスポート層のプロトコルである RTP (Realtime Protocol)[?]を開発し 、実際にこれを用いたアプリケーションが MBone 上では標準となっている。このグループのメーリングリスト (参加方法は rem-conf-request@es.net) ではそれらアプリケーションを用いたマルチメディアリモート会議などについての使用方法や問題点などが話し合われており、MBone を用いて放送する時の事前のアナウンスやその日時が重なった時の調整なども以前はここで行なわれていた。現在は、sdr などによって事前にアナウンスすることが一般的であり、その結果日時が重なった場合の調整などがここで行われることもある。
MMUSIC (Multiparty Multimedia Session Control) ワーキンググループは、MBone 上で行なわれる、遠隔会議のように複数のメディアを使った複数の参加者のセッションについて、そのセッション情報の告知や会議の管理 [?] などをするプロトコルの開発を行なっている。セッションアナウンスのための SAP (Session Announce Protocol) [?] や、どんなメディアでどの IP アドレ スでセッションを行なうかなどの様々な情報を記述するためのSDP (Session Description Protocol) [?] や、他の人をセッションに呼んだりする機構のための SIP (Session Invitation Protocol)[?] などを提案するとともにそれらを用いたアプリ
ケーション sdr を開発し 、MBone 上での標準として使われている。
8

第 2章

JP MBONE
2.1

JP MBone の現状

日本においては 1992 年 7 月に Boston で行なわれた IETF 会議の 2 回目の中継の時より MBone への実験参加が始まった。同年 11 月に Washington DC で行なわれた 3 回目のIETF 会議の中継を機会に、WIDE プロジェクトのバックボーンを用いて東京から九州までの国内のマルチキャストバックボーンが構築された。そして、翌 1993 年 1 月、この JP
MBone の運用管理のためにメーリングリスト mbone-jp@wide.ad.jp が作られ、現在、この参加者による JP MBone 運用グループによって以下のような活動が行なわれている。

 JP MBone の円滑な運用に必要な「ガ イド ライン等の作成」
 適切な JP MBone の構成のために必要な「トンネル設定の調整」
 TTL と threshold 及び boundary によるパケットの「伝播範囲の調整」
 JP MBone を利用した「マルチキャスト実験の相互調整」
 JP MBone での活動の「 インターネットへの広報」
この JP MBone メーリングリストは、MBone メーリングリスト mbone@isi.edu の日本における再配布先と兼用で用いられており、特に国内においての情報交換や協調的な運用のために使われている。現在、150 以上の組織から参加があり、参加希望のメールの宛先は mbone-jp-request@wide.ad.jp となっている。
また、JP MBone には約 100 の組織がつながり、約 200 のマルチキャストルータが常時接続されている。このため、各地に JP MBone におけるいくつかの拠点を設け、Mbone のトラフィックが適切な経路を流れるよう調整しながら各組織をそこに接続することによって実際の IP ネットワークに沿った効率的な接続を協調的に行なっている。
JP MBone と国外の MBone とのリンクは、当初 WIDE の海外リンクを利用して WIDE
藤沢 NOC と NASA の間を結んでいたが、現在は図 2.1のように IIJ と UUNET 、TokyoNetと MCI 、そして WIDE と AI3 の 3 本によって結ばれている。
239

1996 年度 WIDE 報告書

240----- dec3800-2-fddi-0.Washington.mci.net/ 1/64| 1/1
mbone1.uu.net
dec3800-1-fddi-0.LosAngeles.mci.net| 1/16| 1/1
mr.ai3.net
mbone2.uu.net ---- dec3800-2-fddi-0.SanFrancisco.mci.net| 1/64| 1/64
1/64| 1/64######################################################## boundary 239.133/16 ###||||mroute00.iij.ad.jp --- sw01.tokyonet.ad.jp|| 1/32/ 1/32| mbone.otemachi.wide.ad.jp ---- mbone.inoc.imnet.ad.jp ---- totoro.sinet.ad.jp|| 1/32
1/32| 1/32
1/32||
sun1.tokyo.wide.ad.jp ---- ftp.cfi.waseda.ac.jp||| 4/32|\ 4/32|
mr.nara.wide.ad.jp | 1/32--- mbone.nc.u-tokyo.ac.jp ------------------|
|
|
1/32
1/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

図 2.1: JP MBone 主要ルータ接続トポロジー (1997 年 4 月 2 日)
また、1997 年 3 月大手町にある NSPIXP2 の隣接にmbone.otemachi.wide.ad.jp というマルチキャストルータを設置し 、NSPIXP2 経由で各プロバイダとの接続をするようにトポロジーを整理した。現在は tokyonet, iij, imnet, mesh,sinfony, ibmnet の 6 箇所と接続している。

2.2

JP MBone の運用方針の初期の段階では、参加組織間を結ぶ回線のバンド 幅の制約と、pruning が未実装であったという運用面における問題から、各リンクにおいて MBone として使えるバンド 幅に応じて threshold を設定し 、流す側が送出バンド 幅に応じて初期 TTL を変えることによって、細いリンクへ大きなトラフィックが流れないように運用していた。
JP MBone

また、JP MBone の中だけにも流すこともできるようにするため国外との境界ルータにおいて boundary 239.133.0.0/16 を設定し 、国内向けにはこの中のアドレス (administratively scoped IP multicast) [?] を使うとともに、同時に国内向けのセッション情報のアナ第 9部

マルチキャスト 通信

241

ウンスについても LBL 作成のツール sd にパッチを当てたバージョンである sd.jp を用いて 239.133.0.0/16 の中で独自にアナウンスをしていた。しかしながら、次のような状況の変化と問題が徐々に生じてきた。

 pruning がかなりうまく動作するようになり、初期 TTL と threshold の組合せによる配布範囲の制限をする必要がなくなった rate_limit の設定により、バンド 幅の小さなリンク上を大量のトラフィックが通るのを避けることができるようになった UNIX プラットフォーム以外の sd などに対して、従来のようにバイナリパッチを当てて sd.jp を作成するのが困難になってきている
このため、1996 年 3 月 27 日に東京大学で開催された JP MBone ミーティング (午前中は JEPG/IP との合同) およびその後のメーリングリストでの議論により、次のような新運用方針が合意された。

 国内の組織間の threshold は 32 とする
 国外との間の threshold は 64 とし 、boundary 239.133.0.0/16 の設定を行なう
 国内だけに到達させたい場合には、初期 TTL を 64 とし、アドレスは 239.133.0.0/16内から使用する
 セッション情報アナウンスは sdr などのデフォルトのアドレス (224.2.127.254) をそのまま用いる (アナウンスアドレスに 239.133.127.255 を用いた) sd.jp の使用は中止する
なお、boundary 設定を残して 239.133.0.0/16 を用いる理由は、たとえ threshold 設定によって forwarding されないように設定をしても、そのためにパケットが飛んでいかな
い国外方向からの pruning が行なわれず、結果として国際境界のルータのところまでパケットが無駄に必ず到達してしまうことを避けるためである。現在、JP MBone ではこの新しい運用方針に従って設定され、運用されている。
なお、JP MBone への新たな接続にあたっては、適切なところに接続されるようにするためにメーリングリストでの調整や接続のアナウンスがされることが望まれる。また、既存の接続組織同士が新たに別経路で接続する場合、接続トポロジー的にそこを含むループ構造が発生するため、経路制御上なんらかの metric 調整が必要となりうる。例えば 、図2.1における 4/32 というのは metric が 4 で threshold が 32 であることを示す。特に国外との接続にあたっては、それらに加えて threshold 及び boundary の適切な設定に注意が必要である。

242

2.3

1996 年度 WIDE 報告書
SNMP によるマルチキャストト ラフィックの監視

主要なマルチキャストルータからトラフィック情報を SNMP によって収集し 、正しくpruning が行なわれているかど うかの観測、監視の実験を開始した。rate limit の制限である 500kbps がそのままあるインタフェースから入って別のインタフェースに出ていくルータは、その先に pruning せずにすべてのマルチキャストグループへのトラフィックを不必要に受け取っているルータがいる可能性が高い。この観測，監視はまだ始まったばかりであるが、いくつか古いルータソフトウェアや不適切なルータの設定による pruning を行なわないルータが発見された。詳しい定量的な解析は 1997 年度の報告書で報告する予定である。

2.4

JP MBONE を利用した会議等の活動

表 2.1に、JP MBONE を使ってここ 1 年間に行なわれたイベントの一覧を示す。

第 9部

マルチキャスト 通信

表 2.1: JP MBone 利用で行なわれた会議・イベント一覧
日付

内容

96

年5月1日

情報通信学会 情報通信倫理研究会
千葉大学 けやき会館

96

年 6 月 4 日〜5 日

GOIN Japan-US Joint Technical Workshop
NTT Data Communication Center, Tokyo96

年 6 月 21 日

96

年 7 月 3 日〜5 日

96

年 9 月 18 日〜20 日

96

年 9 月 24 日

96

年 10 月 2 日

96

年 10 月 9 日

年 10 月 26 日
96 年 11 月 9 日
96 年 11 月 10 日〜13 日
96

96

年 12 月 2 日〜4 日

96

年 12 月 4 日〜6 日

高校と博物館の間の遠隔授業実験
兵庫県立人と自然の博物館、
神戸市立摩耶兵庫高等学校
JAIN Consortium 第 7 回 総会・研究会
高知県立青少年の家
電子情報通信学会 ソサイエティ大会
金沢大学
第 2 回 千葉地域 インターネット連絡会
千葉大学 けやき会館
第 9 回 日本大学総合科学研究所モーハ博士講演会
日本大学
コンピュータオセロ大会
広島市立大学知能情報システム工学科'96 山梨マルチメディアエキスポ講演'96 PC Conference 講演
JAIN Consortium 第 8 回 総会・研究会
蔵王ハイツ
IP Meeting '96 セッションおよびチュートリアルの中継
広島国際会議場
International Symposium on Educational
Revolution

アクロス福岡
年 2 月 4 日〜5 日
97 年 2 月 18 日
97

97

年 4 月 7 日〜11 日

シンポジウム
小学校と社会施設間の遠隔授業実験の中継
長崎市立シーボルト記念館、神戸市立湊小学校 他
JC/OLU/ITRC

Infocom '97

神戸国際会議場

243

244

1996 年度 WIDE 報告書