図-1: World Wide IDMR トポロジ
IP Multicastは一対多のIP通信を効率的に行うための通信手法であり、将来に おける広帯域かつ大多数の受信者を想定した放送型サービスをインターネット 上で実現するための必要不可欠な技術として注目されている。しかし、現状は、 その経路制御プロトコルの複雑性のため、広域インターネット上でMulticast は利用されていない。ここでの問題は広域Multicastの運用経験が不足してい るだけでなく、実運用に有効なMulticast網の監視手法が確立されていない点 がその技術普及の障壁となっている。
本研究では、大規模なMulticastネットワーク構築と運用を目的として、国際 通信網を利用した、米国Internet2や仏国Renater向けのnative接続を行い、ト ンネルを用いないInter-domain Multicast通信基盤の日本国内への展開を実現 する。またこの基盤を利用して、広域IP Multicast経路の監視機構を構築し、 海外 AS におけるトポロジおよびMulticastのパスツリーを可視化し、IP Multicastの問題点である監視手法に対しての解を提案する。 この際、関連するプロトコルの標準化活動も実施する。
| 楠本博之 | 環境情報学部 准教授 | 研究代表 |
| 朝枝仁 | 政策・メディア研究科 助教 | プロトコル設計 |
| 堀場勝広 | 政策・メディア研究科 博士2年 | ソフトウェア設 計、ネットワーク設定 |
SIGCOMMはACMが主催している通信とコンピュータネットワークに関して議論を 行う国際会議である。2007年のSIGCOMM [1] は京都で開催され、そのホストとして、 WIDE Projectは来場者へのネットワーク接続性とワークショップおよびカンファ レンスの模様をIPv6マルチキャスト技術によって全世界へライブ配信した。 以下ではその時に用いたnativeなIP Multicast接続のトポロジ情報や、実運用 時の監視手法に関して論じる。
WIDE（AS2500）はIPv4マルチキャストをAPAN-JP（AS7660）からMBGPとMSDP を用いて接続し、IPv6マルチキャストをAPAN-JPとRENATER-FR（AS1717）から MBGPとPIMを用いて接続している。IPv6に関しては、RENATER-FRを経由した接 続性はIPv6 over IPv4トンネルを用いてM6BONEに接続している。M6BONEはIPv6 マルチキャストのテスト用バックボーンネットワークであり、IPv6マルチキャ ストが学術ネットワークにおいても実験段階であった時期に広く接続性を提供 するためにRENATER-FRが中心となって活動しているプロジェクトである。しか し広大な接続性と引き替えにトンネル接続による帯域に関するパフォーマンス が問題視されており、広帯域を必要とする高解像度ビデオ等のアプリケーショ ン利用に適していなかった。図-1に各地域における主要な学術ASのマルチキャ スト接続トポロジを示す。
近年APAN-JP・GEANT2・TEIN2・Internet2・AARNETをはじめとした各大陸の 大規模な学術ネットワークがIPv6に対応することで、トンネル接続を必要とし ない広域なAS間マルチキャストネットワークが整備され、定常的にサービスと して広帯域なマルチキャストアプリケーションの利用が可能となった。また各 主要ASが複数のASと接続することでASパスが冗長化され、M6BONEがIPv6マルチ キャスト接続の主流だった時期と比較して、単一ASの障害による接続性の喪失 被害の可能性は、格段に減少している。
WIDE Projectは2006年からAPAN-JPとのAS境界においてIPv6マルチキャストの 接続をMBGPによる経路交換および、PIMによるマルチキャスト配送木構築によっ て実現した。これによりトンネル接続による帯域制限を緩和し、1Gbpsまでの マルチキャストトラフィックをAS外と交換可能な環境にすることに成功してい る。
SIGCOMM2007では後述するDVTSを用いてMPEG2-TSによるライブ配信を行った。 MPEG2-TSは単一ストリームで約30Mbpsの帯域幅を使用する。SIGCOMM2007では IPv4とIPv6のデュアルスタックでの配信を行ったため、約60Mbpsのトラフィッ クをWIDE外に送信した。これは、従来のトンネル技術を用いた場合には実現で きなかった帯域幅である。 このように現状の学術ASによって展開されているIPv6マルチキャストネット ワークはトンネル技術を用いることなく、広域な配送木構築・冗長性・広帯域 トラフィックの配送を実現している。
IPマルチキャストにはIPv4・IPv6を問わず、ユニキャストにおける送信者か ら受信者へのパスを特定するTracerouteに該当するプロトコル・アプリケーショ ンが存在しないため、送信者から自AS以外での受信ノードを特定する手法が存 在しない。そのためSIGCOMM2007では他ASが提供するいくつかの経路情報を用い て、受信ASの特定を試みた。
図-2にUNINETT（AS224）が持つMBGP address-family IPv6 Multicast Table を図示した。UNINETTはNORDNET（AS8362）を経由しGEANT2（AS）に接続してい るASである。この図よりUNINETTからWIDEに到達する MRIB-Path（PIM Joinが 送信されるAS-Path）を把握することができた。 なお、図-1は図-2の一部をもとに作成したものである。しかし、MBGP address-family IPv6 Multicastはルータベンダおよびルータソフトウェアに おいて普及しているとは言い難く、一部のASではstaticにMRIBを設定している ため、図-2のようなMBGP Tableからは確認されない場合が存在する。そのため 次の手段として、一部の主要ASが提供するRouter Proxy（Router Looking Glass）を活用し、明示的にRPF Checkを行うことで、図-1を作成した。
図-3、4に受信ASを示す。Router Proxyを用いることで、各所からWIDEへの MRIB-Pathだけでなく、実際に受信しているASおよび拠点の検索を行った。そ の結果とInternet2のmulticast working groupのメーリングリストにおいて受 信AS情報の開示を求めることで受信ASを収集した。
データ受信者主導で経路が形成／削除されるIPマルチキャストでは、そのデー タ配信網はダイナミックに変動するため、そのためアクティブなIPマルチキャ スト経路を調査するなどの経路状態監視は困難である。特に、経路状態監視を 行うために膨大な制御メッセージを送信してしまい、ネットワーク負荷を高め てしまうことは避けるべきである。 ユニキャスト通信の経路調査ツールとして、従来から "traceroute" というプ ログラムが利用されている。これは ICMP TTL exceeded メッセージを利用し、 宛先までの経路(ルーター)を認識していくというプログラムである。このアイ デアをIPマルチキャストの経路調査にも適応するという研究もなされてきたが、 標準的なプロトコル定義が無かったため、ツールの互換性やIPバージョン6に 対応できないなどの問題が生じていた。
我々は、新しい multicast traceroute プログラムとして、"mtrace Version 2 (mtrace2)" をIETFのMBONEDワーキンググループに提案 [2] し、標準化活動 を開始した。 69th IETF (July 22-27 2007, Chicago, IL, USA)では mtrace2 の概念となる 部分の説明を行い、その必要性と今後の標準化活動の指針などを示した。技術 的な内容に関し、ベンダー、プロバイダーや大学関係者から多くの同意を得た。 70th IETF (December 2-7 2007, Vancouver, Canada)では、新しい mtrace2 で用いられるプロトコル非依存となるデータフォーマットを定義し、UDP メッ セージにより全ての query/request/response がエンコードされることの説明 などを行った。
以下、簡単にメッセージ処理に関して説明する。query メッセージにはデータ 受信者が指定するデータ送信者や mtrace2 の返信先などが含まれる。mtrace2 query を受け取ったルーターは、自らの経路表を検索し、上位ルーターに mtrace2 request を転送する。これが最終的にデータ送信者が収容されている ルーターまで hop-by-hop で到達し、そのルーターは経路上の全ルーター情報 を保持したまま mtrace2 query で指定された宛先に向けて mtrace2 response を送出し query に対する返答をする。 この mtrace2 を利用すれば、データ送信者までの経路がわかるだけでなく経 路上のルーターの状況、例えばどのルーターのどのインターフェースに負荷が 掛かっているかなどの検査も可能となる。
今後、mtrace2 メッセージと処理内容に関して更に議論して行き、セキュリティ 的な案件も考慮しながら、各ルーターベンダーが互換性ある実装を行うことが できるように、そして学術団体やプロバイダーがIPマルチキャストを利用する 上で効果的にトラブルシューティングできるように積極的に標準化活動を行う。
2007年11月27日から29日の3日間、プーケット (タイ) で Asian Internet Engineering Conference (AINTEC) 2007 [3] が開催された。このカンファレ ンスの最終日、朝枝が「Gap Analysis in IP Multicast Dissemination [4]」 という招待論文の発表を行った。この論文では、IPマルチキャストの有効性や 効果に反して、その経路制御技術が複雑であることを説明し、それを回避する ための SSM アーキテクチャ [5] がもたらす利点と、そこから派生する新たな 課題について述べた。
この論文では、多くのマルチキャストサービスとして想定される１対多通信の 現実性を統計的に評価し、１対多通信に有効な SSM をベースにこれから普及 するであろうIPマルチキャスト通信モデルの説明を行った。ここで、SSM では 従来のマルチキャスト通信モデルでは想定されなかった様々な課題が存在する が、本論文では、それらの課題や問題点を明らかにし、それらを解決するため の技術的手法の提示、そしてこれらが解決されることで新たなIPマルチキャス トの普及段階に入るための指針を提示した。 特に重要な課題として、マルチキャストセッション情報の広報やルーティング 基盤に対する攻撃からの防御などは、SSM では、従来のマルチキャスト通信アー キテクチャよりも問題が複雑化されてしまうことを説明した。この課題に関し、 今後、国内外のマルチキャスト研究者や組織と協力しながら、具体的な解決策 が得られるように活動していくことが期待される。
また、この論文では、オペレーターに対する技術内容だけでなく、アプリケー ションプログラマーが SSM アプリケーション開発を行うためのヒントとして、 Multicast Source Filtering (MSF) API [6] の利用方法なども紹介した。
[1] ACM SIGCOMM 2007, http://www.sigcomm.org/sigcomm2007/.
[2] Hitoshi Asaeda, Tatsuya Jinmei, Bill Fenner, and Steve Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", Internet Draft, draft-ietf-mboned-mtrace-v2-00.txt, November 2007.
[3] Asian Internet Engineering Conference (AINTEC) 2007, http://www.interlab.ait.ac.th/aintec07/.
[4] H. Asaeda and B. Manning, "Gap Analysis in IP Multicast Dissemination", Springer LNCS 4866 (AINTEC2007)", pp. 199-212, November 2007, Phuket, Tahiland.
[5] H. Holbrook and B. Cain, "Source-Specific Multicast for IP", RFC4607, August 2006.
[6] D. Thaler, B. Fenner, and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC3678, January 2004.
