マルチキャストは１０年前からカッティングエッジと言い続けている。 10年経っても、いつまでも実際のISPで広まらない。 ゼブラのBGPの話で、かつて石黒さんがBGPの経路の複雑さの話をして、最 後に”これにましてマルチキャストなんてぬかしてんじゃねー”と言った。 これを解決したいのが、今回の新しいマルチキャストの開発のモチベーショ ンとなっています。 まず、なぜ“なめてんじゃねー”というほど複雑なのかを説明したいと思います。 ”Multicast　Mechanism”ClassDタイプ、インターネットスタンダードマ ルチキャストのメカニズムを説明します。ジョインしてくる人に、ダイナ ミックにマルチキャストをしてあげようというコンセプト。ひとつの配送 木ごとに経路エントリーをひとつ。配送木が通っているところには、すべ てルータの上にエントリがなくてはいけないのが、難しい原因となってい る。配信をやっている間中、KeepAliveをしてくるし、送信者が変わると 配信経路エントリは別に必要になり全体として膨大な情報が必要。しかも それぞれが頻繁に変更を起こす。”なめてんじゃねー”というのが納得で きる。 ”グループ数スケーラビリティ問題” スケーラビリティをざっくりいうと、100万グループを持つとなると、 １００万経路を保持しないといけないし、それらにKeep　Aliveをしないといけない。。。 それをさばけるルータはほんとうに実現可能なのか？ マジでできるのか、できると思って良いのか？ ”トンネルによるMulticast展開” では、マルチキャストの展開をどうしていくか。 充分ひろいネイティブなMulticast backboneは残念ながら存在しないので、nativeな小さいネットをユニキャストで結ぶ。トンネリングなので、 構造が複雑になってしまう。 オペレーションも複雑になり、それが、アカデミックにしか広がっていかない 理由になっている。 ”コンシューマ向けマルチキャスト” では、僕等が本当にやりたいマルチキャストアプリケーションとはなんだろうか？ 放送・TVのコンテンツだったら、電波は相当安い。 インターネット通信は、プライベートな複数の、特定された仲間 ゲーム仲間などという、コンスーマ：そういうグループを作りたい。 しかし、オペレータから見ると、たくさんのメンバーが存在し、それぞれが いろんなコンテンツをばらまいているのを、どうサポートするかを考えたくなる。 ”アプリケーションの再分類” もう一度言い直すと、ブロードキャストタイプのようなものとは、例えば、デジタルTVとかだ。 それとは別に、ナローキャストライクのグループがある。これをサポートするのが、 Small　Group　Maulticastであり、XCASTのコンセプトである。 ”Explicit　Multicast” アイデアはシンプル。どことどこに送りたいのかがわかっているので、 グループ代表アドレスの代わりに、それのユニキャストアドレスを拡張ヘッダに入れる。 パケットは全部のアドレスに対して行くと定義する。 ”MDO6パケットの転送” そうすると東京からNY、ロンドンに行けとなると、それらをパケットにつめて 送ってやると、ルータ側で、NY,ロンドン、Parisの行き先に書き換えて送ってやる。 ルータはNexthopが同じ宛先はひとつのパケットで送ってやる、別のNexthopなら、別のパケットを作って送ってやる。 そうするとマルチキャストに配信が可能となる。 ”特徴” ルータの中にはマルチキャストグループの情報はないので、ルータへの負担がない。 クライアントからしてみると、オペレータ、ISPに関係なく、End-to-Endで 送ることができる。ただし、ルーティングヘッダにあて先を入れるので、 １０２４いれろとなると困る。プロトコルのSpecification上は１２６までが IPｖ６版の制限で、これに従ってイーサのフレームにいれてやると、 フレームのサイズを超えてしまう.。実用上はどうしたらいいか？ 例えば、VIDEO会議の標準プロトコルでは、１０２４のペイロードにRTP,UDP, IPヘッダーを差し引いて、 逆算すると、１６宛先まで可能になる。 実際そんなに大きな会議は人間にとって運営は大変なので、16人可能であれば十分用途に達していると思う。 ”トンネルによるMulticast展開” 基本はそうであるが、マルチキャスト・ルーティングを行うルータが インターネット中に広まり、行き渡らせないと、Multicastできない！＝＞ 実はこれには次のトリックがある。 ”半透過トンネルによる段階的な展開” 半透過トンネルによるMulticastと呼んでいるものがる。 IPｖ６のオプションヘッダを活用する案である。 先頭2ビット、IPｖ６では新しいものを格納できるように拡張できるので、それを利用する。 ルータがオプションタイプ値を理解不能なら、そのタイプのヘッダーを無視して普通のユニキャストパケットと同じように 処理するようになっている。IPｖ６ヘッダの宛先にまだ行っていない宛先のひとつを入れている。 ”半透過トンネルによる段階的な展開” ルータが対応していない最悪の場合でも、セッションに参加してるノードににユニキャストで送られ、 デージーチェーンで到達性は保証される。 送信者が勝手に送信、受け取ることができる。これができると、オペレータに とっては、無駄な処理がネットワーク上に流れてしまい、そのような通信が 増えてしまうという状況なる.。しかし、XCAST対応ルータが増えれば、 徐々にネットワークが効率化がされていくと考えている。 ”IETF　Standardization” 言ってるだけでは実験室の中だけなので、現在標準化の活動を進めている。 １９９９秋、われわれがインターネットドラフトを出したら、同じことをやっているところ、 3社と話し合いを始めることになった.。IETFはルーティングエリアの管轄で、 BOFを開催したが、その際の議論は保留。現在二回目開催を待っている状況である。 またマルチキャストをアピールするために、統一されたXCASTグループ（アルカテル主催）が 発足され、Internet Draftを書いている。現在はバージョンが-01にアップデートされている。 透過的なトンネリングはIPｖ６だけ。IPｖ４でのマルチキャストの実現は、 ネットワーク上の全でのルータが対応していないといけない。 ”IETF　Standardization　（Cont'd) その仕様を元に、実装を作ろう！と 新しい仲間で手分けして標準を作成中である。富士通としては、 IPｖ６をNetBSDで実装を行なった。韓国のJAISTとETRIが共同し、 LINUXで実装を考えている。ロンドンの後、相互接続の話が進んでいる。 ”MDO6-kit” 富士通案MDO６に沿った実装と実績はすでに持っている。 これを使って、ビデオカンファレンス、VoIPのフリーソフトなどで遊んでいる。 FreeBSD,NetBSD対応。WIDE6Boneにワーキンググループがあるので、 みんなで利用している。 ”INET2000　Demo” ちょうど1年前にINET2000　DemoでVoIPとビデオカンファレンスをやった。 WIDE6Boneを利用した。 ”ビデオ会議運用実験” 昨年私がアメリカに赴任中に、UC Irvineなどを結んで、7地点のビデオ会議を 毎週一度2時間のペースではじめ、今もやっているが、最初のころは始めの1時間は なかなかマルチキャストが安定せずに、対処に時間をとられたりして苦労したが、 今も週一のペースでやっている。ここで強調したいのは、基幹ルータのオペレータは、 汗をかかなくてすむ、ということ。従来のマルチキャストなら、ルータの設定など いろいろ苦労するものだが、XCASTでは使用帯域をオペレーションに知らせるだけで、 WIDEのオペレータを泣かすようなことがなかった。 また、クライアントはエンド−エンドで自分の判断ですぐできる。 ”まとめ” 現在グループキャストを進めている。オペレータに痛みの少ない ＸＣＡＳＴになっている。クライアントからは気軽にできる。 現在実験しているし、ＩＥＴＦにも働きかけている。 "今後の課題” 今日の課題はＪAＮＯＧ８に来た大きな意味がある。 マルチキャストに関してはいろんな提案があとからあとから出てきているが、 IETF, IESGはこれ以上マルチキャスト関連のＷｏｒｋｉｎｇＧｒｏｕｐ作りたくない、という状況のなか、 Ｓｍａｌｌ　ＭｕｌｔｉＣａｓｔが有用だといわれてきている。 ＢＳＤ，LINUX，Ｗｉｄｅをたきつけて、みんなで使ってキャンペーン中。 オペレータの人は多忙なので、できないかもしれないが、 ネットワークでも受け入れてほしい。というのが本音。 ”携帯でのMulticast：Smooth　Handover” ”Mobile　IP瞬断問題” マルチキャストといっても、複数のノードに対してばかりでなく、 実際にはひとつのノードに対して送るのにマルチキャストが意味がある例がある。 携帯電話をAll IPで実現しようという話があるが、瞬断が大きな問題となっている. ”Handover　by　Preceeding” 携帯が右から左の基地局に移るとき、CoAの変更のリクエストが携帯から発信元に到着して、CoAが切り替わるまで Ｒｅａｃｈaｂｉｌｉｔｙが 失われ、ノイズが大きく出て困る。瞬断の時間がInternational だと長くなる。現在議論されている。ＸＣＡＳＴが使えるとなると、 両方の基地局を経由した複数のCoAにＸＣＡＳＴで 送ってあげれば解決できる。この辺を携帯の キャリアやベンダーに紹介するのも私のミッションにもなっている。 さいごに。。。 どうぞＸＣＡＳＴをよろしくお願いいたします。 ありがとうございました。 （（質問）） １．Rendezvous　Point不要といっていたが、新規の人がグループに参加するのは どうするのか？ Ａ１．すべての参加者がコマンドラインから入れる。グループ管理はトランスポート、 ネットワークレイヤから独立し、アプリケーションが持つべきと考えている。 Ｌ７でピリオディカリに見に行くなどの対応が考えられる。研究が慶応で行われていた。 アプリケーションごとの要請に応じたメンバ管理のバリエーションがあると考えている。