図２、１、マルチキャストでのデータの流れ
インターネットの歴史は、1969年に米国防総省が開発したArpanet (Advanced Research Projects Agency Network)に始まる。米国防総省が核戦争時の通信手段を確保する目的で1969年に開発を始めた研究用ネットワークである。当初の利用者は、コンピュータ技術者や大学関係者、研究者などであった。その後、1980年代前半には、軍事目的の研究から切り離されて、全米の大学や研究所を結ぶネットワークになった。このネットワークは、利用者の草の根的な活動で発展し、ネット上には大量の情報が蓄積されていった。1990年には商業利用が開始され、米国の｢情報スーパー・ハイウエイ構想｣の中で、その基盤と位置付けられ、世界中の注目を集めることになる。
インターネットが爆発的に広がってゆく契機となった革新的なテクノロジー開発が二つある。1989年にスイスのCERN（欧州物理学研究所）で開発された WWW（ワールド・ワイド・ウエブ）と、1993年に米国イリノイ大学の学生マーク・アンドリューセンが NCSA (the National Center for Supercomputing Application) のグループと共同で開発した初のウエブ・ブラウザー 「モザイク(Mosaic)」である。「モザイク」は、簡単な操作によりHTMLで書かれたページの文字を読むことができるだけでなく、画像を取り込み表示することができた。アンドリューセンはその後、シリコングラフィックスの創業者であるジム・クラークと新会社を設立。1994年秋には「モザイク」をさらに進化させたソフトを世に出した。この新しいブラウザー「ネットスケープ」は爆発的に普及し、世界的なインターネットブームを惹起した。
インターネットが個人のライフスタイルから企業活動まで幅広い範囲をカバーするようになったのは、1990年代後半になってからである。1995年頃から、多くの企業でマーケティングのために積極的に活用されるようになり、eビジネスに特化したベンチャー企業群が台頭し始めた。インターネットが個人消費に関わるライフスタイルを変えたといわれる1998年の「eクリスマス」では、書籍や音楽、衣料品から家電、自動車といった大型の耐久消費財を含めた商品を対象にしたeコマースが飛躍的な伸びを示した。eビジネスが一気に開花し、インターネット利用者も急速な伸びを示してきた。ブラウザーの登場からわずか5，6年間で、インターネットは世の中を一変させたのである。
現在、インターネット先進国米国の株式市場における歴史的な長期上昇相場を支えているのは、インターネット経済である。それは、eビジネスの社会化現象に合わせて｢ニューエコノミー｣と言われている。ニューエコノミーとは、ITを牽引役に、物価安定と低失業率が共存し、株価が上昇し続ける1990年代後半の米国経済を描写した言葉であり、インターネットやデジタル革命がもたらす新しい経済体制の総称として使われている。ニューエコノミーで出現してきた新興企業群の価値がこれほどまでに高騰したのは、インターネットを活用して業界内の既存ビジネスのルールを変革してゆき、それがもたらす利便性を顧客に与えてゆくことへの評価であろう。斬新で低コストのビジネスモデルや、既存仲介業者を外した新たな流通機構に基づくバリューチェーンがもたらす長期的なリターンへの期待感である。
日本国内においては、インターネットの初期段階としては、1984年頃から活動が始まっている。1993年には、WWWがきっかけとなり爆発的な広がりを見せ始めた。世帯普及率が10％を超えるまでに要した時間は、電話で76年、ファクシミリで19年、PCで13年かかったのと比べると、インターネットは5年。かつてないほどの速度で普及したのが分る。インターネットの世界では、日本は先進地米国から3～4年は遅れていると言われてきたが、ネット人口が1千万人を突破した1998年後半あたりから、本格的なサイバー企業群が台頭してきた。
＜軍事用ネットワークの時代＞
初期のインターネットは「学術用ネットワーク」として活用されていましたが、実はそのルーツはベトナム戦争当時の軍事戦略用通信網にまでさかのぼります。冷戦時代（1969年）に、米国国防総省（ＤＯＤ）の高等研究計画局（ＡＲＰＡ：Advanced Reserch Projects Agency）は、有事には放送や電話などに代わる通信網として機能させる、全米中の主要機関や研究所などに設置されたコンピュータを結ぶ、ARPAnet（アーパネット）というプロジェクトを完成させました。（ARPには軍事用語で「空襲警戒」の意味があるそうです。） このARPAnetは、パケット交換やエラー回復などの新技術が基盤となっており、当時としては画期的な通信網として、軍事利用だけではなく、科学技術研究所に関係する民間研究者にも幅広く利用されたのです。幸運にもこの時代には、重要な研究には積極的な資金提供が行われ、ネットワークの整備が自然に進められたのです。
ARPAnetは、８０年代半ばに軍事用のMILNET（ミルネット）と研究用に分離され発展的に解消します。現在私たちが利用しているインターネットの一部はこの研究用のものです。もちろん軍事用ネットワークにもつながっており、たびたびクラッカーの標的になっています。
＜学術用ネットワークの時代＞
１９７０年代後半～８０年代は、学術用ネットワークの成長期にあたります。冷戦が緩和されるにつれて、さまざまな軍事技術が民間用に移転されました。同時にコンピュータの飛躍的な発展期であり、ネットワークを通じたコンピュータ利用が盛んになった時期でもあります。さまざまな研究機関が、より高速で能力の高いネットワークを求め、独自に構築を始めます。ＮＡＳＡ（航空宇宙局）のＮＳＩなど、この時代のネットワークは、当時は高額であったスーパーコンピュータの共同利用を目的として構築されていました。このため、スパコンで実行するためのプログラムのファイル転送、遠隔操作（Telnet）などの関連技術の整備も当然必要になり、これは全米科学財団（ＮＳＦ：National Science Foundation）が担当することになりました。また、１９８３年にはTCP/IPがARPAnetに正式採用され通信方式の標準となっていきます。
インターネットの本格的なスタートは、１９８９年のＮＳＦnetに始まります。NSFｎｅｔは、通信速度は当初、５６ｋｂｐｓでしたが、すぐに１.５Mｂｐｓになりました。（これは、１秒間に漢字188,000字を送ることができる速度です。）その後、さらに４５Mbpsにアップされ、映像も送ることができるようになりました。この高速ネットワークは、スパコン利用以外にも大きな魅力となり、全米の大学や研究機関の小規模コンピュータ・ネットワークが次々につながるようになりました。しかし、ＮＳＦnetの利用は、原則として学術･教育用に限定されていました。これが、インターネットが学術用ネットといわれる所以です。（現在は、ＮＳＦnetは非営利団体により管理され、他の公的なバックボーンネットワークと共に、「情報スーパーハイウェイ」（ＮＩＩ）の一環として統合されつつあります。）
日本の最初の学術インターネットはおそらく JAIN です。 文部省がひいた図書館用ファックスサービスと大型計算機間の接続(N1ネット) のための大学間の専用回線に便乗し、 X.25 というプロトコルを乗せ、その上に IP をのせたものです。 日本の学術ネットは JAIN が終了した後、地域ネット(東京地区では TRAIN)、慶應大学の WIDE プロジェクト、文部省の SINET の立ち上げとなり、ここ数年では各地の地域ネットの終了と、スーパー SINET の立ち上げたというのが始まりです。
＜商用インターネットの時代（現代）＞
高速ネットワークの便利さが広く知られるようになると、学術目的に限定されないインターネットの登場が望まれるようになりました。米国では、１９８９年頃から、自前の回線を使って接続サービスを提供するＮＳＰ（ネットワーク・サービス・プロバイダ）が次々に登場します。プロバイダは、ユーザーとの間に専用線を設置し､一端はルーターを通じてユーザーのＬＡＮやパソコンにつなぎます。もう一端をＮＯＣ（ネットワーク・オペレーションセンター）につなぎ、これがユーザーが接続するＡＰ（アクセスポイント）になります。ＡＰが全国にたくさんあれば、ユーザーは最寄のＡＰに接続すればよく安い電話料金でインターネットを利用することができます。こうして瞬く間にインターネットのユーザーは、全米中に、そして世界中に広がっていきました。
米国では、通信に関する法律も料金体系も日本と異なり、こうしたサービスを始めるにも利用するにも、大変安価に実現できます。このため、爆発的にユーザーが増加したのです。（日本でもユーザーは急激に増加していますが、米国と比較すると、プロバイダ接続料、回線使用料共に、まだまだ安くなって当然と感じます。）
しかし、今日のインターネットの人気は、このようなプロバイダの登場だけで説明できません。単に安くて便利というだけではなく、ＷＷＷ（World Wide Web）などのコンテンツが充実してきたことにより、誰でも欲しい情報を入手できる便利さと楽しさが増えてきたためです。そして、１９９０年代に入り、初のブラウザは w3 です。テキスト形式で、リンクに番号がついて、番号を入力すると次のリンク先を表示するものでした。また、初期のＭｏｓｉｃ（モザイク）、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ（ネットスケープナビゲータ）などの使いやすいブラウザ、多くのプラグインが開発され、利用環境が整備されてきたこと、加えて、ユーザーが自ら情報を発信できる道具（ホームページ・ビルダー、マルチメディア・オーサリングソフト、ＦＴＰなど）が充実し、また、買ったらすぐにインターネットに接続できるパソコン(Windows 95)の登場も非常に大きな要因の一つだと考えられます。
そして、インターネットの普及に拍車をかけた最も大きな要因は、米国人のパイオニア精神、ボランティア精神です。つまり、誰かが役に立つ情報を無償で提供する、その情報を得た誰かがお返しに有益な情報を提供しようとする、皆で協力して新しいネットの世界を構築しよう、という開拓時代に培われた精神（表現がオーバーかもしれませんが）がベースとなり、さらに良い情報を、良いサービスを、というサイクルができあがったのです。
インターネットの歴史が商用プロバイダの時代から始まる日本では、安いプロバイダはどれか、どうやっておいしい情報を得るか、どうやって一儲けするか、自分に都合のいいインターネット利用術ばかり考えているユーザーが多いように感じます。バーチャルな遊びの世界のように見えるかもしれませんが、ブラウザの向こうには常に生身の人間がいることを意識してください。そして、インターネットから何かを得たら、代わりに何かを提供するというギブ＆テイクの精神を忘れないでください。
＜インターネットのサービス＞
インターネットで何ができるか？ 初期のインターネットは科学者たちの論文の伝送などのメール的な使い方と、遠隔地からのスパコンの分散利用が中心でした。しかし、ＩＰ接続などの一般ユーザーの利用を推進する技術が導入されると、ＦＴＰでプログラムをダウンロードしたり、掲示板を発展させたネットニュースなどにも使われるようになり、メールも文字情報に加えて画像などを添付できるようになりました。誰でも自分のパソコンから利用できるようになると、さらにさまざまな欲求が生まれ、それに応えるサービス（インターネット電話、音楽配信など）が提供されるようになりました。
インターネットのサービスは、次のような基本機能がベースになっています。
＜ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）＞
ブラウザや携帯端末などを使って、Ｗｅｂサーバーに蓄積されているＷｅｂページを表示します。つまり、さまざまな情報を提供している世界中のWebページにアクセスすることができます。テキストに加えて、画像、サウンド、アニメーション、ビデオなどさまざまな表現が可能であり、リンク先に簡単にジャンプできます。ブラウザやwindowsのＡｃｔｉｖｅＸの機能が強化され、さまざまなプラグインが利用できるようになるにつれて、さらに高度な利用法が実現できるようになり、ＸＭＬなどのプログラミング技術の発展により、さらに高度な機能を持つＨＰの制作が可能になってくるでしょう。
最近のＨＰは情報を掲載するだけでなく、利用者のニーズに応じた情報配信、最近問題となっているオンラインショッピング、オークションなどを含む電子商取引のツールとしても利用されています。また、マルチキャスティングによるネット版放送局も増えています。まだまだ、さまざまな形態が増えるでしょう。
＜電子メール（Ｅ-Ｍａｉｌ）＞
インターネットが普及する以前から、パソコン通信ユーザーや外資系企業ユーザーを中心に限定ノード内で利用されていました。インターネットの普及とともに、ノード、ドメインを越えて世界中のユーザーとの送受信が可能になりました。一般的には、送信はＳＭＴＰサーバー、受信はＰＯＰサーバーを経由して行われます。プロバイダが管理するこれらのサーバーにアカウントを登録すればすぐに利用可能になります。最近では、Ｍ社の"Ｈｏｔｍａｉｌ"など、無料でアカウントを登録できるサービスも公開されています。ＷＷＷとともに、メールマガジンなど情報配信サービスの基本となる技術でもあります。
＜ネットニュース（ＮｅｔＮｅｗｓ）＞
パソコン通信の経験のあるユーザーは掲示板（ＢＢＳ）を使用したことがあるでしょう。ある情報を書き込むと、それに対する追加の情報、答え、反対意見などが次々に書き込まれます。掲示板と異なるところは、特定のプロバイダに利用が限定されていないこと、アウトルックのようなメーラーから誰でもアクセスすることができること、添付ファイル、つまり定めらたフォーマットの画像などもアップできることです。
このため、プロバイダのＦＡＱなどにもよく利用されます。世界中のインターネット・ユーザーが相手ですから、ニュースグループ（ＮＧ）の規模は、数千万人が参加するほど大きくなる可能性があります。ニュースに関心があるユーザーは、世界中から投稿（ポスト）してきます。ネット上にはさまざまなテーマ別のニュースグループが存在しており、更新度合いも激しいものが多いのです。
意外に、このサービスを知らないユーザーが多いのですが、Ｏｕｔｌｏｏｋ Ｅｘｐｒｅｓｓなら、「ツール」の「ニュースグループの購読」から見たいニュースの「購読」を設定すれば、メールと同様に登録されているニュースを読むことができます。経験の無いユーザーは一度購読してみてください。（"japan．ｘｘｘ．ｘｘｘｘ"には日本語のニュースが多い。）
＜ファイル転送（ＦＴＰ）＞
一般ユーザーは意識していないかもしれませんが、ＨＰからプログラムやＭＰ３ファイルをダウンロードしたり、ＨＰに掲載するデータをアップロードするために使用されます。ＦＴＰというプロトコル（通信規約）で行われます。「anonymous FTP」という設定にすれば、フリーソフトを配布するような使い方ができ、パスワードが必要な設定にすれば、仕事のファイルをやり取りするのに使えます。ネット上での配信量が増加し大容量のメディアファイルを扱うようになるにつれて役割が大きくなってきました。
＜遠隔操作（ｔｅｌｎｅｔ）＞
もともと遠隔地からインターネット経由で特定のホスト・コンピュータを操作するための機能であり、大手のパソコン通信サービスでは古くから使われています。Windowsにはあらかじめ、ｔelnetの機能が組み込まれており、スタートメニューの「ファイル名を指定して実行」に、「ｔelｎet」と入力して起動できます。テキストモードなのでWeｂページアクセス用には向きませんが、管理用に利用可能にしているプロバイダもあります。
その他、インターネット電話、テレビ会議など、様々な機能が開発され実用化されています。
「以上説明してきたのは、主にコンピュータ同士が一対一で通信するユニキャスト通信に基づくサービスであった。これに対し、一対多で通信する通信方式も存在し、利用されている。一対多で通信する方式には「ブロードキャスト」と「マルチキャスト」という方式がある。ブロードキャストとは、ユニキャストのいわば対極にあります。ある特定の条件下では、１つのメッセージのコピーをネットワーク上のすべてのノードに送出して、受信側のノードでそのメッセージが必要かどうか決定される方法である。一方マルチキャストとは、ユニキャストとブロードキャストの中間に位置します。単独のホストへのデータ送信（ユニキャスト）や、ネットワーク上の全ホストへのデータ送信（ブロードキャスト）ではなく、ホストグループと呼ばれる選択されたホストのグループに宛ててデータを配信することである。 普段、我々が前章で紹介したようなサービスを利用している時は、これらの通信を意識したことがない。しかし、そのような場合でも、ブロードキャストやマルチキャストはインターネットの管理などに積極的に利用され、我々をサポートしている。一般に利用されている一対多通信として名前解決(ARP)やルーティング(経路制御)がある。ARP はコンピュータのネットワークカードの番号と IP アドレスを対応づけるプロトコルで、ネットワークに接続している全てのホストに対して目的の IP アドレスを問い合わせる。また、ルーティングは、経路情報を多くのコンピュータで共有する必要があるため、 RIP と呼ばれる方式ではブロードキャスト、 OSPF という方式ではマルチキャストが利用されている。ブロードキャスト通信は、ネットワーク全体に通信するだけなので、実現は単純である。一方、マルチキャストは特定のグループに対して通信を実現するためいくつか問題点がある。まず、インターネットにおいて送信先を指定するためには IP アドレスが必要であるが、相手が複数の時にどうするかである。これは Class D と呼ばれるアドレス空間が割り当てられ……一般にチャンネルとは……、またグループとは、マルチキャストを受信することを通知したい場合、クライアントは、、マルチキャストが送信されるグループに参加する必要があります。この処理は、IGMP (Internet Group Management Protocol) によって実現します。さて、インターネット上にこのグループに属している人が分散して存在することになるが、そのグループに対して情報を送るにはユニキャストとは別の方式で送らなければならない。これがマルチキャストルーティングである。マルチキャストルーティングとしては……さて、マルチキャスト通信はまだ完全に普及しているわけではなく、利用したいと思う人も限られているため、単純に特定のマルチキャストアドレスに対して情報を送信しても相手先まで送信されるわけではない。したがって、マルチキャストを実現しているネットワーク同士をインターネットを介して結ばなければならない。そのための技術としてトンネリングがある。トンネリングとは、マルチキャスト・データグラムを、あるルータから別のルータへマルチキャストの経路制御に関連しない中間のルータを通すことである。さて、このトンネリング技術を利用すると、インターネット上に仮想のマルチキャストネットワークを構築することができる。現在実験的に構築されている仮想のマルチキャストネットワークとしてMBone がある。MBone とは、IPマルチキャストを使って世界規模でいろいろな放送の実験を行うためにインターネット上に作られた仮想ネットワークである。
ネットワークの容量が増大するにしたがって、マルチキャスト・トラフィックが必要なセグメント（ネットワークの単位を意味する）と不要なセグメントを判別する手段として、マルチキャスト・ルーティングがますます重要になります。 IPマルチキャストは、1つの送信元から多数の宛先へ、または多数の送信元から多数の宛先へ、IPトラフィック（通信回線上での通信量）に、1つのパケット（データを分割した時の単位）が送信されます。
IPマルチキャストは、BVI（ブリッジ・グループ仮想インターフェイス）上での制約付きマルチキャスト・フラッディング（データグラムをインターネットワークのすべてのルーターに配信する最も単純な手法）、およびFast EtherChannel上でのBVIをサポートします。 制約付きマルチキャスト・フラッディングを使用することにより、スイッチ・ルータはIPマルチキャスト・グループのグループ・メンバーシップを動的に判別し、グループ・メンバーが配置されているポート（送信のつど任意に動的に割り当てられるもの）だけに、マルチキャスト・パケットをフラッディングできます。
IPマルチキャストの主要コンポーネントは、IGMP（Internet Group Membership Protocol）です。 IGMPにより、クラスDアドレスでマルチキャスト・グループ内の個々のホストを動的に登録できます。 ホストはスイッチ・ルータにIGMPメッセージを送ることによって、各自のメンバーシップを認識させます。 トラフィックはマルチキャスト・グループの全メンバーに送信されます。 ホストは、同時に複数のグループに所属できます。 また、そのグループにデータを送信する送信元グループのメンバーである必要はありません。 インターフェイスでPIMをイネーブル（有効）にすると、そのインターフェイスではIGMPもイネーブルになります。
本論文では、マルチキャスト通信に焦点を当て、これを可能にする技術、プロトコル、アプリケーションなどを紹介する。2章ではマルチキャストの説明をし、3 章ではマルチキャストルーティングの説明、特に、ルーティングプロトコルのDVMRP・MOSPFを説明する。4 章では実際にマルチキャストルーティングの実験を行い、結果を報告する。5 章には全体的なまとめを行った。
世界最大規模のネットワークであるインターネットは、当初は研究手段として利用されていました。やがておびただしい数の商用アプリケーションを利用するネットワークへと発展し、その発展の過程において無類の適用性を示しました。
この空前の発展が、多くの新しいアプリケーションを生み出しました。これまでは高性能のワークステーションを使っている限られたパワーユーザーだけしか利用できなかった多くのアプリケーションが、今ではパソコンの世界で主流になりつつあります。
例えば、テレビ会議、ビデオのブロードキャスト、共同作業用アプリケーション、およびプッシュテクノロジーなどです。そしてこれらの新しいアプリケーションによって、ビデオや音声などの新種のデータ登場し、データ配信でのネットワークの責務能力に、新たな需要を生み出してきました。
そんな中、今、ネットワーク開発者は、あらゆる種類のデータ（特にリアルタイムあよびマルチメディアのデータ）を、タイムリーかつ確実にどのユーザーにも配信するという課題に取り組んでいます。
リアルタイムのデータ通信の必要性に加えて、アプリケーションも急速に発展し、これまでの１対１の通信から、１対多、または多対多の通信へと推進しています。最近のアプリケーションの多くは、共同作業者（例えば、共有ホワイトボードを用いて新製品を設計するなど）として、あるいは単に同一情報の受信者（例えば、株価情報やマルチメディア形式のコンサートなど）として、複数のユーザーを結びつけること目標としています。これらのアプリケーションが広く利用されるにつれて、従来型のネットワークでは、多数のユーザーに同じ情報を同時配信すると、容易にネットワーク容量の限界に達してしまうという問題点が浮き彫りになってきました。しかし、最近の優れた技術を駆使し最近のネットワークを利用しることで、伝達情報の不要な重複を減少させ、ネットワークの負荷を軽減させることができます。そこで、急速にその利用範囲を広げている「IPマルチキャスト」という１つの新しい技術に焦点をあてました。
マルチキャストは、多くのLANテクノロジーでサポートされています。例えばイーサネットでは、一連のマルチキャストアドレスが、ワークステーションがデータ受信のために聴取できるように定義されていて、これはブロードキャストの聴取と類似しています。
マルチキャストは、ユニキャストとブロードキャストの中間に位置します。単独のホストへのデータ送信（ユニキャスト）や、ネットワーク上の全ホストへのデータ送信（ブロードキャスト）ではなく、ホストグループと呼ばれる選択されたホストのグループに宛ててデータを配信することを目的としています。ホストグループは、指定されたマルチキャストアドレスによって定義されます。
例えば、LANでは、各ホストのネットワークインターフェースはLANを聴取して、所属するホストグループに対応するマルチキャストアドレスに宛てられたパケットを受け取ります。ブロードキャストとは異なり、マルチキャストでは、各ホスト側でマルチキャストに参加するかどうかを選択することができます。一方、WANで実行するマルチキャストでは、LANでのマルチキャストとの類似点がいくつかあります。ホストグループの概念は基本的に同一ですが、WANではホストグループに関するメンバーシップ情報を、WAN全体またはインターネットワーク全体を通じて維持する必要があります。ホストグループに参加する手順や、ホストグループを維持する手順はルーターが関与する必要があるため、LANの場合とは異なります。
ホストグループが一度セットアップされ、送信側がそのホストグループのアドレスにパケットを送信し始めると、ネットワークのインフラストラクチャーは、必要なデータストリームをグループの全メンバーに配信する責任を負います。ネットワーク上の任意のリンク（ルーターなど）を、マルチキャストメッセージの一つのコピーだけが通ります。メッセージはルーターで経路が分岐する場合のみコピーされるので、帯域幅を節約する助けになります。図２、１に、マルチキャストでのデータの流れを示します。
図２、１、マルチキャストでのデータの流れ
マルチキャストのデータグラムは、普通のユニキャストのIPデータグラムの場合と同様にベストエフォートの信頼性で、宛先のグループメンバーに配信されます。これはつまり、マルチキャストのデータグラムが、グループ全メンバーに届くことや、また、送出された順に届くことが保証されないことを意味しています。
マルチキャストでは、ブロードキャスト同様に、メッセージの送信元は、受信者やデータ配信の状態などについてまったく分からないのが普通です。通常ユニキャストトラフィックで行われいているようなフィードバックを提供するには、別の手段を講じなければなりません。これは、何らかのフロー制御やパケット受信の肯定応答を使って送受信間のセッションを制御しているTCP（Transmission Control Protocol）などのプロトコルと対照をなすものです。
IPマルチキャストは、インターネット上で見られるすべてのアプリケーションに適しているわけではありません。例えば、マルチキャスト用プロトコルは、Webページを見たり、電子メールを送信したり、またはホストコンピュータへのリモートアクセスのためのTELNETの実行をしたりする場合には何ら利点はありません。
その一方で、ウェブキャスト、ファイル転送、ソフトウェアの電子的配布など、グループ活動を主眼としたアプリケーション、あるいはテレビ会議や共有ホワイトボードなどのグループウェアアプリケーションに与える影響は少なくありません。数人以上が一つのアプリケーションでデータを共有する場合に、IPマルチキャストはネットワークで必要な帯域幅を軽減させる助けになります。
IP マルチキャストはIPマルチキャストホストグループを示すのに上位4ビットが1110で始まるクラスDインターネットアドレスを使用します。 インターネット標準のドット表記では 、ホストグループアドレスは224.0.0.0 から 239.255.255.255までの範囲です。パーマネントとテンポラリの二つのタイプのグループアドレスがサポートされます パーマネントアドレスの例はとしては、Internet Assigned Numbers Authority (IANA)によって割り当てられる224.0.0.1があり、これは直接接続されたネットワーク上の全てのIPマルチキャストホスト宛ての "all-hosts group" です。もう一つは224.0.0.2でこれはLAN上の全てのルータ宛てです。 224.0.0.0から 224.0.0.255までの範囲のアドレスはルーティングプロトコルと他のローレベルトポロジー探索やメンテナンスプロトコル用にリザーブされています。他の範囲のアドレスはアプリケーション用としてリザーブされています。例えば、224.0.13.000から224.0.13.255はNetNews用です。これらのリザーブされたIPマルチキャストアドレスには記載されています。
クライアントは、マルチキャストを受信することを通知したい場合、マルチキャストが送信されるグループに参加する必要があります。この処理は、IGMP (Internet Group Management Protocol) によって実現します。
マルチキャスト グループにはいくつかの利点があります。まずグループは動的です。つまりクライアントは、いつでも参加と脱退が可能です。グループの作成と解散には複雑な手順は必要ありません。グループにメンバーがいなくなると、グループは存在しなくなります。またグループの拡張では、スケーラビリティを容易に維持できます。これは、マルチキャストに参加するクライアントが増加するほど、マルチキャストがすでにクライアントの近くにルーティングされている可能性が高くなるためです。
クライアントがグループに参加するとき、2 つの処理が開始されます。まず IGMP メッセージがクライアントのローカルのルーターに送信され、対象グループに送信されているデータを受信することを求めるクライアントの要求をルーターに知らせます。 次にクライアントは、自身の IP プロセスとネットワーク カードを設定して、グループのアドレスおよびポート上でマルチキャストを受信します。マルチキャストのアドレスはクラス D の IP アドレスで、 224.0.0.0 から 239.255.255.255 の範囲にあります。接続しているネットワークがIEEE-802イーサネットなら、Class D の IP アドレスは自動的に IEEE-802 イーサネット マルチキャスト アドレスに対応付けられるので、イーサネット上で IP マルチキャストを簡単に実現できます。クライアントがグループから脱退し、そのクライアントが特定のサブネットワーク上でマルチキャストを受信する唯一のクライアントだった場合、ルーターはクライアントのサブネットワークにデータを送信するのを停止し、ネットワークの帯域幅を開放します。
Mboneはvirtual Multicast Backbone On the interNEtの略であり、multicastを利用してリアルタイムのインタラクティブなマルチメディアをインターネット上で配信およびアクセスできるようようにする技術です。IPmulticastは応用として、音声や画像をInternetを介して放送するApplicationsが登場したために急速に脚光を浴びました。現在Internetに関した主要な国際会議ではMboneで会場の実況中継が行われています。他にもNASAのスペースシャトルの打ち上げをMbone上で流したり、ローリングストーンズのコンサートもMboneで流れたこともあります。
1992年IETF(Internet Engineering Task Force) SanDiego の模様をインターネット上にリアルタイムで放送することがMboneの始まりでした。1992年7月のIETFの会合以降に"Mbone"の名前が決まりました。現在ではmulticast通信技術の開発ならびに新しいアプリケーションのテストを目的に構築されています。
IPマルチキャストを使用する多数のアプリケーションがすでに開発されてあり、今後もさらに登場すると思われます。これらのアプリケーションの多くは、リアルタイムアプリケーションかどうか、また使用するメディアデータが、単一かマルチメディアかによって分類できます。図２、２に示す。
| リアルタイム | 非リアルタイム | |
| マルチメディア |
|
|
| データのみ |
|
|
マルチキャストのストリーミング、特に音声、ビデオ、あるいは音声とビデオの両方をマルチキャストグループに配信することができます。マルチキャストが利用可能なときはマルチキャストと使うように設計されているProgressive Network社のRealAudioやRealvideoなどの製品を使用して、会議のセッションやコンサート、インタビューなどの録音、録画が、インターネットを通じてマルチキャストされています。
同様に、企業の年次総会やCEO（最高経営責任者）のスピーチの録画なども、普段はビデオや音声を受け取ることのない社員に、イントラネット上でマルチキャストすることができます。また、重要なスピーチのリプレイの予定を組んでイントラネット上でマルチキャストすることもできます。
教育の現場でも、クラスの講義を事前に録画しておいて、家庭や特別な教室にいる学生にマルチキャストすれば、遠隔学習もより現実性をおびます。White Pine Software社のCU-SeeMeや、Intel社のProShareを使用する対話式のテレビ会議では、学生のディスカッションに必要な帯域幅を軽減するのにマルチキャストの利点を生かしています。
近年、「プッシュテクノロジー」が、複数の受信者に同一のデータを配信する方法として、一般的になってきました。これらは、ニュースや株式相場、その他のタイムリーでしかも大多数の人々にとって有益な情報の配信です。当初のプッシュシステムの多くは、データ配信にマルチキャストを使用していませんでした。その代わりデータを受信者の個々にユニキャストし、プロキシサーバーまたはキャッシングサーバーを使用して負荷を分散していました。しかし、この手法は次第に変化してきています。例えば、重要な株式相場データを証券会社にリアルタイムにプッシュする場合、Tibco社のInformation Busシステムではマルチキャストを使って、利用可能な帯域幅が飽和するのを防いでいます。
さらに、重要なファイルの配布やソフトウェアの更新などを企業ネットワーク上で電子的に行うためにマルチキャストを利用する企業も出てきました。例えば、トイザらス社では、衛星ネットワーク上でマルチキャストを行って、250の販売店に対して、1Mバイトのソフトウェアの更新を伝送しています。こらまで6時間15分が費やされていたこの伝送が、この方法を採用することで、今ではわずか3分4秒でできます。同様にGeneral Motors社では、衛星ネットワーク上でマルチキャストを行って、在庫データやソフトウェアを全米のディーラーに配布しています。
ただし、マルチキャストは万能薬ではないことを覚えておく必要があります。マルチキャストは一対一のセッションや、複数のユーザーが別々の時刻に同じ情報やファイルにアクセス場合などには利用できません。
マルチキャストを正しく構成するには、次の４種類の処理が重要です。
マルチキャストをユニキャストとブロードキャストと区別する大きな特徴の一つが、ホストグループの選択です。これは、ユニキャストのように、ネット上のある一つにデータを送信したり、ブロードキャストのようにネット上のすべてのホストにデータを送信するのではありません。マルチキャストは、ネット上の特定のマルチキャストホストグループの参加を表明したホストだけに送られます。
IPマルチキャストおよびその他の多くのマルチキャストプロトコルで重要なのは、ホストグループに参加したホストを知る手段が、送信側にないということです。実際のところ、ホストグループに参加するホストが一つもないのに、データが送出される可能性も十分あります。
ホストグループがメンバーについて送信側が関与しないことは、送信側がグループへの参加と離脱に関するトラフィックを処理仕切れなくなるのを防ぐ妥協案になっています。送信側がグループメンバーシップを管理する必要があるとすると、送信するホストの処理能力に多大な影響を及ぼし、マルチキャストデータを送出できない事態に陥りかねません。これはリアルタイムデータ伝送では特に重大な事態です。
この他にも、マルチキャストではグループメンバーシップは動的でなければならないという問題があります。ユーザーにとってはグループに参加や離脱が自由にできるために便利ですが、アクティブ状態のメンバーを常に把握しておくのは難しい問題です。動的なグループメンバーシップという特質によって、グループメンバーシップのリストが集中管理されていないので、ルーターはどのサブネットにグループメンバがいるかを確認するために、ポーリングを定期的に行うことを余儀なくさらます。
ネットワークの帯域を節約するためのマルチキャストであるはずなのに、動的なグループメンバーシップは、そのネットワークの帯域幅にも不利に影響します。グループメンバーシップを把握するためにルーターとホストによって生成されるトラフィックが少量だとしても、ホストグループの離脱に伴う遅延のは帯域の浪費につながります。
不要なマルチキャストトラフィックの転送を止めるために、セッションから離れるホストの情報がルーターからルーターへと伝えられるには、しばらく時間がかかります。この間にも、送信元は、マルチキャストデータを配信をし続け、差のデータはツリーを構成する全ルーターに転送されます。このように、配下のサブネットのアクティブなホストメンバーがいなくなり、マルチキャストツリーなアクティブなメンバーでなくなったルーターが不要なマルチキャストトラフィックを受け取り、帯域を浪費するのです。
LANのテクノロジーによって、使い勝手の良い低コストなデータのマルチキャスト方法が確立されました。特に、１つのパケットのコピーを送出するだけ複数の受信者に到達できる点は、データの送信者にとって有益なことです。しかし、マルチキャストは受信者にとっては、そう効率の良い方法ではありません。ハードウェアで多数のアドレスを完璧にフィルタリングするのは容易ではないことら、マルチキャストアドレスの受信者は、不要なアドレスをソフトウェア割り込みで処理する羽目になります。
マルチキャストトラフィックは、共有リンクでの伝送コストを最小に抑えるという目標のもとに、自由経路ではなくツリーに沿って転送されます。
複数のメディアストリームのそれぞれに最適な符号化技術を使用したい場合は、ストリームの個別対応は欠かせません。個々で各ストリームに使用する配信ツリーを同一するか、個別に設定するかという問題が生じます。同じ配信ツリーを使用したほうがインターネットワークの制御は容易で、関連トラフィックの配信保証を助けますが、ネットワーク資源に負担がかかります。
一方、個別の配信ツリーを使用する方法は、各ストリームに必要なサービスの品質が選べ、受信者は自分のネットワークの機能に応じたストリームを一種類だけ選択して受信することができます。この手法の問題の一つは、送信元ごとに行う複数のツリーの管理が法外なコスト負担になることです。
マルチキャスト特有のスケーラビリティー上の問題は、グループ利用から派生します。ブロードキャストでは、データを受け取らないホストもあり得ます。このため、サブネット全体がデータを受信しない場合もあります。マルチキャストの大部分の方式では、各ルーターは、参加ホストがどこにいるのかをお互いに教えあう必要性があります。その結果、プロトコルはこのネットワークトポロジーを構築し、更新できるように構築されることになります。しかしながら、インターネットワーク上に分散しているホストグループメンバーの分岐は、高密度のものから散在型の低密度のものまで多岐におよんでいます。このため、ネットワークのインフラストラクチャの更新は単純ではありません。
これはグループの密度だけでなく、メンバー数にもかかわる問題となっています。受信側のメンバーが増えると、ルーターはマルチキャストネットワークのトポロジーについての情報をその分大量の保存しなければなるません。この追加された大量の情報が、ユニキャストルーティングやQoSの維持など、ルーターの他の仕事に必要な資源の枯渇につながる可能性があります。
これに関して、インターネットッサービスプロバイダやドメインの数が増え続けている商用インターネットに、マルチキャストルーティングをどのように適応させていくのかという問題があります。現在のマルチキャストの各種のルーティングプロトコルは、必ずしもすべてのルーティング情報を共有しようとしない、自律システムのため設計ではありません。インターネットのルーティングが、階層的ルーティングと、ドメイン間ルーティングプロトコルを使用するよう発展してきたように、マルチキャストのルーティングも同様に発展するでしょう。その作業もすでに進行中であり、この問題も近い将来解決されるでしょう。
すべての受信者に対して、同時にデータを配信しなければならない場合があります。なかには、株式市場情報やその他の金融関連データのように、まったく同時か、あるいは最小の時間差ですべての受信者にデータを配信しなければならないものもあります。データが同時に届かないと、ある証券業者が別の業者よりも先に行動を起こすことができ、不公平な利益がもたらされる事態が生じます。時間厳守の別のタイプには、ビデオや音声などの時系列データがあります。配信時にデータのシーケンスを維持しなければならないだけで、関連する別々の場所でデータストリームのあいだの同期をとる必要があります。ビデオと音声の両者で構成されるセッションは一般に、データ圧縮とその後の解凍にそれぞれ異なるアルゴリズムを使用し、同期化データを挿入してオリジナルのセッションの復元を支援しなければなりません。インターネットや大部分のマルチキャストプロトコルは各データストリームを独立に処理するため、二種類の関連するストリームが、送信元から受信側まで異なる経路を通ることもあり得ます。ユニキャストでも、ルーターの経路全体で関連ストリーム間のリンクを維持するという課題は、インターネットの未解決の問題として残されています。
IPマルチキャストでは、ベストエフォート型の配信を行うIPに依存しているため、通信の信頼性は高くありません。 通信の信頼性が低いということは、いかなるデータの損失も許されない金融業務トランザクションやファイル転送などのようなアプリケーションに対応するためには、IPマルチキャストの上部に信頼できるプロトコルを追加しなければならないことを意味します。現在IETFによって、高信頼性マルチキャストプロトコルに対する、多くの提案が検討されています。また、その中でいくつかはすでに商用製品で採用され始め、高信頼性マルチキャストの日常的な利用は時間の問題になってきています。
この他のマルチキャストでの未解決の問題としては、マルチキャストセッションにおける安全性の確保があります。これまで、IPネットワーク上のパケットのセキュリティを守るために開発された各種のプロトコルは、あらゆる種類のトラフィックを想定していますが、マルチキャストやブロードキャストよりもユニキャストに容易に適用できるようになっています。この理由の一つは、送受信間で交換する暗号キーを渡し、マルチキャストを行うホストグループの動的なメンバーシップに対応する適当な方法が、まだ見つかってないことがあげられます。
マルチキャストには、ネットワークのセキュリティが提起する別の問題も存在します。マルチキャストで使用するプロトコルの多くはパケットの送出にUDPを使用しますが、この方式が現在のファイアウォールの戦略の大部分に適合しないのです。UDPはコネクションレス型のプロトコルであるため、UDPコネクションのどちらかの終端がサーバーで、どちらがクライアントかという判断が難しくなります。
このため、ファイアウォールに到達した受信パケットが問い合わせに対する有効な応答であるのか、あるいはサーバーへの返信なのかを特定するのは困難です。アプリケーションゲートウェイでは、UDPトラフィックの選択的フィルターを実行するのは非常に困難を伴います。このため、多くのサイトではファイアウォールを通過しようとするすべてのUDPトラフィックを許可しないようにしています。
ルーティングは、送信元からネットワーク上のすべての宛先までの経路を検出するための手順です。インターネットを構成するルーター同士が、協調的な相互接続を形成し、１つのルーターから別のルーターへとデータグラムを受け渡していき、最終的には受信側に直接配信します。
ルーターが配信経路を決定するために、ルーティングプロトコルは、ネットワークの各部分を構成するルーターで、相互に一貫したルーティングテーブルを確立します。このルーティングテーブルは、最終的な宛先のアドレスと、この宛先までの最適な経路での次の中継地点のネットワークアドレスという、少なくとも二つの欄で構成されます。ホストまたはルーターで使用するIPルーティングソフトウェアがデータグラムを送出する場合は、このルーティングテーブルを必ず参照して、どこにデータグラムを送出するか決定します。
各ルーターは、ローカルに経路の選択を行いますが、この選択はインターネットワークのグローバルなトポロジーにもとづいています。したがって、すべてのルーティングプロトコルはインターネットワークのグローバルトポロジーについての情報を各ルーターとのやり取りしてルーターがローカルに経路の決定ができるようにしています。
メモリや帯域幅を軽減するために、ルーターはパケットのルーティング時に宛先ホストを使用しないで宛先ネットワークを使用するように設計されています。ルーターが格納する必要がある情報量は、ルーティングがホストではなくネットワークにもとづいている限り、インターネットワーク上のコンピュータの数ではなく、ネットを構成するサブネットの数で決まります。
インターネットでは、多様なルーティングプロトコルが使用されていますが、パケット交換ネットワークには二種類の基本的なルーティングアルゴリズムがあります。その二つとは、距離ベクトルアルゴリズムとリンク状態アルゴリズムです。両方ともルーターが自身が隣接するルーターのアドレスと、その地点までのコストを理解していることを前提としています。このコストは、リンクの容量や遅延、1パケットあたりの課金、あるいはさまざまなネットワーク関連の要因にもとづいて決められます。
一般に、距離ベクトルアルゴリズムでは、それぞれのノードがその隣接ノードに、ネットワークでの自分自身から他のすべ地のノードまでの距離を通知し、リンク状態アルゴリズムでは、それぞれのノードはネットワーク内の他の全ノードに対して、自分の隣接ノードまでの距離を通知します。
距離ベクトルアルゴリズムは、ノードとリンクが常にアクティブな場合は効率的に動作しますが、リンクが切れたり復元することなどリンクの状態が変化すると、多くの問題が生じることになります。距離ベクトルアルゴリズムの主な欠点は、大規模なネットワークには不向きであることです。距離ベクトルアルゴリズムでは、変化への対応が遅く、大量の帯域幅を必要とする大量のメッセージ交換が必要になるためです。ルーティングの更新メッセージには、可能なすべてのネットワークへのエントリが含まれているため、このメッセージの規模は、インターネットワーク内のネットワークの総数に比例して大きくなります。
それに対して、リンク状態アルゴリズムでは、ネットワークのトポロジーと各リンクのコストを全ルーターに配布します、各ルーターは、全宛先について最善の経路を個別に計算します。各ルーターがそれぞれのリンクについて同じコストを使い、また同じアルゴリズムを使って最善経路を計算するなら、ループが発生しないことが保証されます。
リンク状態ルーティングでは、各ルーターは、自身のそれぞれのリンクの状態をリストしたメッセージを定期的にブロードキャストし、お互いが変更箇所について常に認識できるようにします。このリンク状態メッセージは、経路を指定せず、ルーター間で通信が可能かどうかについて記述しているだけです。リンク状態メッセージが到着すると常に、ルーターはこの情報にもとずいてインターネットワークのマップを更新し、それぞれのリンクが利用可能か否かをチェックします。リンク状態に変更が生じると常に、ルーターは有名なDijkstraの最短パスアルゴリズムを適用して経路を再計算し、グラフを作成します。Dijkstraのアルゴリズムは、一箇所の送信元から全宛先への最短の経路を計算します。
リンク状態アルゴリズムの主な利点は、各ルーターが同じオリジナルのリンク状態データを使用して独立に経路の計算を行うことです。各ルーターは、他のルーターの計算結果に依存することなく計算できます。また、リンク状態メッセージでは、それぞれのルーターは直接接続しているリンクについての情報だけを伝達するため、メッセージのサイズはインターネットワークに含まれるネットワークの数には依存しません。このため、リンク状態アルゴリズムのほうが、距離ベクトルアルゴリズムよりもスケーラビリティーの点で柔軟性があります。
インターネットワーク内のサブネットの数が多くなると、ルーティングプロトコルに必要な演算能力やメモリが非常に大きくなります。これを解決するには、ルーティングコストの制御を階層ルーティングで行う方法があります。インターネットでは、ルーティングは３階層からなり、各層で異なるルーティングプロトコルを採用しています。このなかで最上層がインターネットバックボーンで、複数の自律システム（AS）の相互接続を行います。自律システム間のルーティングでは、EGP（Exterior Gateway Protocol）を使用します。ルーターが構内で対話するためのプロトコルは、IGP（Interior Gateway Protocol）と呼ばれています。
自律システムは一つの管理機関によって制御されている一群のネットワークとルーターと定義できます。ASは、インターネットバックボーンと異なるルーティングプロトコルを使用するため、AS内のルーティング情報は、バックボーンのルーティングプロトコルからは認識されません。したがって、AS内に隠れたネットワークと全インターネットとのあいだで通信ができるようにするためには、各自律 システムは、EGPを実行しているルーターによって、他のASへネットワーク接続性情報を広告しなくてはなりません。EGPとIGP間の接続における主な問題点は、リンクコストを算出するために、それぞれが異なるルーティング技術と手法を用いることです。
自律システムがインターネットを最上層で階層的に分離しているように、インテリアルーティングプロトコルも階層的に一つのASをいくつかのエリアに分けるのが一般的です。ただし、自律システムの場合とは異なり、同じインテリアルーティングプロトコルが、エリア内とエリア間の両方で使われます。
ユニキャストのルーティングプロトコルは、ある一ヶ所の送信元から単独の宛先にパケットを配信する目的で設計されました。そのため、複数の宛先に対するパケットの複製機能がないため、他のルーティングプロトコルを設計して、送信元から複数の宛先までの経路を決定し維持して、マルチキャストによるパケット転送が可能になるようにする必要がありました。
ユニキャストのルーター同様、マルチキャストのルーターも、ネットワークトラフィックの転送や、インターネットトポロジーの把握、トポロジー変更の検出、トポロジー上での配信経路の計算などを確実に行うためのデータの交換を行う必要があります。しかし、マルチキャストルーターは、この他にも解決すべきさまざまな課題を抱えています。課題は、マルチキャストの配信ツリーの構築と、動的に変化するグループメンバーシップによって派生してきました。例えば、IPマルチキャストでは、グループメンバーが、ホストグループへの参加や離脱をいつでもできるように規定していることから、グループのマルチキャスト配信ツリーのトポロジーは、通常のIPインターネットがユニキャストトラフィックを配信する際のトポリジーに比べて、すばやくしかも頻繁にに変化します。
このため、マルチキャストルーターもユニキャストルーターと同様に、テーブルの大きさや制御メッセージ用トラフィックの頻度や大きさに対処する必要がありますが、それよりもマルチキャストルーターの場合の設計上の主眼は、配信ツリーを構築、維持する方法、ホストグループメンバーの分散度合、グループメンバーがホストグループを離脱する際の遅延の問題などに置かれてきました。マルチキャストルーティングの設計者が、ユニキャストのルーティングで実地されているように、（階層構造の定義やドメイン間マルチキャストルーティングプロトコルの提唱など）マルチキャストのスケーラビリティに関する問題に取り組んだのはごく最近のことです。
マルチキャストルーティングプロトコルの基本的な仕事は、マルチキャスト配信ツリーを構築してパケット転送を可能にすることです。マルチキャストルーティングプロトコルは、個々のグループのための配信ツリーを構築、またはその支援を行って、そのグループに宛てられたパケットのマルチキャスト転送を可能にします。これはユニキャストトラフィックの場合にルーティングプロトコルが転送テーブルを作成するのと同様です。
ルーティングテーブルに記述されているユニキャストの宛先は、コストを示す数値の宛先までの経路における次ホップのルーターに関連付けられています。ユニキャスト転送とマルチキャスト転送のもっとも大きな相違点は、マルチキャストパケットは一般に、送信元から遠ざかる方向にのみ転送されなければならない、ということです。もしパケットが送信元に向かって逆方向に転送されなければならないことばあると、転送のループが発生する可能性があり、マルチキャストストームを引き起こしかねません。マルチキャストストームが発生すると、パケットは無限に（またはそれに近く）複製され、大量の超過トラフィックがネットワークに作り出されて、他のトラフィックの伝送を妨げることになります。
各種のルーティングプロトコルは、独自の方法で転送テーブルを作成します。転送テーブルは、個々の送信元と宛先グループの対ごとに、パケットがどのインターフェイスに到着し、それをどのインターフェイスに複製する必要があるかを、各ルーターに対して指示します。
マルチキャストパケットが転送される一連のサブネットとルーターは、そのパケットの送信元を根とする配信ツリーを形成します。マルチキャストパケットは、ツリーが枝を出す分岐点でのみ複製されます。
IPマルチキャストセッションのメンバーシップは動的に変化します。このため、マルチキャストルーティングプロトコルが取り組まなければならない大きな問題は、マルチキャストデータグラムの配信ツリーの様態をどうやって維持するか、ということです。ルーティングプロトコルは、プルーニング（pruning、枝きり）というメカニズムを適用してこの問題に対応します。
ツリーに関連した用語で表現すると、マルチキャストグループのメンバーを持たなくなったリーフやブランチは、ツリーから削除つまりプルーニングされます。通常、この作業は、このリーフに接続するルーターが、サービスを提供するLAN上にアクティブなグループメンバーがいないと判断した時点で行われます。このリーフルーターは、マルチキャストツリーの上流のルーターに対して、マルチキャストツリーから自分を削除するようメッセージを送信します。
この結果、上流のルーターも、削除を求めたリーフルーターにデータグラムを転送するだけのためにそのマルチキャストツリーに入っていた場合は、自身をマルチキャストツリーから削除するようになります。
マルチキャスト配信ツリーを保守する上で、プルーニングは重要な作業です。プルーニングは不要なトラフィックを、インアクティブなグループメンバーやサブネットに伝送するのを防ぐことによって、ネットワーク資源にかかる負担を減らすことができます。しかし、プルーニングは瞬時に実現可能ではないため、ブランチやリーフのプルーニングが完了するまでは、配信ツリーですでにアクティブでないサブネットやルーターがマルチキャストトラフィックを受信する場合があります。これは離脱遅延と呼ばれます。離脱遅延はツリーを構築するアルゴリズムの種類によって異なり、配信ツリーの規模や構造にも影響されます。不要なデーターの量が問題にならない場合もありますが、長いビデオストリームなどの場合は、ネットワーク資源に少なからず悪影響を与えることになります。
IPマルチキャストの進歩に伴い、マルチキャストデータを各グループメンバーに効率良く配信するために苦心しているネットワーク技術者たちは、新たな課題に直面し、たびたび指摘されている問題の１つに、多様化した広範囲のネットワークトポロジーの中で、グループメンバーいかに効率的にデータをルーティングするかという問題があります。インターネットワーク内の多くのサブネットメンバーが、最低１人以上のグループメンバーを持つ場合、すなわち、それぞれのグループメンバーが、ネットワークに密着して存在している場合があります。このような状況に対処するように設計されたプロトコルは、密集モードのルーティングプロトコルに分類されます。この対極にあるのが、散在モードのルーティングと呼ばれ、インターネット上でグループメンバーがお互い遠くはなれて分散している場合です。この状況は、グループのメンバーが少数であることを意味するわけではありません。グループメンバーを持つネットワークの数は、同じ領域内のネットワーク数に比べると全体的に見た場合、明らかに少なくなります。
密集モードのプロトコルは、データ始動型のアプローチ（フラッドとプルーニング）によってマルチキャスト配信ツリーを構築するのに対して、散在モードのプロトコルは、受信側始動型の手順を採用します。つまり、ルーターがマルチキャスト配信ツリーの構築にかかわるのは、そのサブネット内のホストの１つがどれかのマルチキャストグループに対してメンバーシップを要求した場合だけになります。
グループメンバーがネットワーク中に散在することに加えて、散在モードプルトコルは、帯域幅が広範囲に利用可能であることは限らないことを想定しています。このようなトポロジーでは、フラッドが発生すると、ネットワークの帯域幅を浪費しパフォーマンス上の障害を引き起こします。
密集モードのルーティングでは、不要なデータパケットへの応答として、明示的なプルーニングを送信、保存しますが、散在モードのルーティングでは、要求されていない場所へはデータグラムを送信しないことになっています。このため、密集モードのルーティングプロトコルを使用すると、（ツリー構築を開始するために）デフォルトで流れるブロードキャストの振る舞いとプルーニングを維持することが負担となります。一方、散在モードのルーティングでは、ランデブーポイントまたはRPと呼ばれる共有ツリーを使わなければならないことと、休憩状態のグループRPツリーを維持することが負担となります。このRPを通じて、受信側は、マルチキャスト送信元の情報を受け取ります。
この他に、インターネットサービスプロバイダ（ISP）やドメインが増え続けている商用インターネットで、マルチキャストルーティングをどのように適用していくか、というスケーラビリティー上の問題があります。
MBoneは、実験的なネットワークとして構築された点でユニークですが、その設計を現在のインターネット上にそのまま追加したとしても、一部のユーザーが日常的に利用できるようにもネット上のすべてのユーザーが利用できるようにもなりませんでした。たとえ今後もMBoneが成長したとしても、マルチキャスト用にこれまで設計されたルーティングプロトコルは充分には規模に対応していけないでしょう。現在のマルチキャストの各種ルーティングプロトコル（PIM,MOSPFおよびDVMRPなど）は、すべて経路情報を必ずしも共有する必要のない、複数の自律システムのために設定されたものではありません。ユニキャストのルーティングプロトコルである、BGP（Border Gateway Protocol）は、IPプロトコルをサポートしていますが、IPマルチキャストをサポートする同等なものはまだありません。インターネットのルーティングが発展して、階層的ルーティングや、ドメイン間ルーティングプロトコルを使用するようになったように、マルチキャストのルーティングも同様に発展するでしょう。すでにこの問題を解決するための作業は進行しています。
現在のマルチキャストルーティングプロトコルは、（ユニキャストのトラフィックでの）最短の経路のツリーにできるだけ近い配信ツリーを、正確かつ迅速に維持することを目標にしてします。これは、配信ツリーの形状が急速に変化することを意味しています。また、配信ツリーはグローバルな範囲で構成される可能性があることから、制御用トラフィックが頻繁に生じる可能性があります。これとは対照的に、ドメイン間のユニキャストルーティング環境の設計上の主題は、ルーティングトラフィックの軽減と安定性の確保です。ドメイン間のマルチキャストルーティングトラフィックをサポートするには、プロトコルとルーター制御にかかる負担を減らして、安定性を図る何らかの方策をマルチキャストツリーに導入してなければなりません。このような手法がないと、インターネット全体でマルチキャストを実施するのは難しいでしょう。
双方向マルチメディアや時間厳守型のデータ配信など、新種のネットワークアプリケーションの利用が増えるにつれて、なんらかのQoS（Quality of Service、サービス品質）のサポートが必要になっています。ST-Ⅱのようなマルチキャストプロトコルには、リンク設定の一部としてQoSの仕様が含まれています。しかし、IPマルチキャストで使用されているより一般的なプロトコルには、このようなオプションはありません。
インターネットのメディアの多様性を考えたとしてもなお、終端間のセッションに特定のQoSを提供することが可能です。しかしこの機能は、マルチキャストのようなグループメンバーシップの変更に応じて配信ツリーが再編成される、より動的な環境で厳しく試されます。QoSをマルチキャストに組み込むための１つの提案として、「経路の特定（route pinning）」があります。この場合、グループがグループへの参加を要求する際に、同時に特定の経路を要求します。（経路を特定することで適切なQoSが適用されます）。また、経路の特定には、QoSの条件を満たす複数の経路を指定するオプションも含まれており、２番目の経路も維持されて、最初の経路に障害発生した場合に容易に切り替えることが可能になります。
QoSベースのIPルーティングを行うプロトコルが提唱され、検討が進められています。このようなプルトコルが、やがてユニキャストやマルチキャストのトラフィック用に設計されるでしょう。
実際には使用されるマルチキャストルーティングプロトコルの数は多くありません。例えば、MBoneでは、DVMRPとMOSPFを使用しています。近年、新しいプロトコルの開発が最終段階に入り、複数のネットワークで試験されているので、まもなく比較的多数のマルチキャストルーティングプロトコルが同時に使われる移行時期となるでしょう。少なくともインターネットでは、ただ１つのマルチキャストルーティングプロトコルが利用されるようになるまでは、しばらく時間がかかりそうです。多くの種類のプロトコルが使用された場合は、プロトコル間の相互運用性が重要な問題となります。
PIM（Protocol-Independent Multicast）プロトコルは、その名が示すように、他のマルチキャストルーティングプロトコルとの相互運用性を実現する設計になっています。しかし、PIMルーターは、各インターフェースで複数のマルチキャストプロトコルをサポートしなければならないため仕様が複雑になり、PIMルーターの実用化が極めて困難になります。 DVMRPやMOSPFなどのいくつかのルーティングプロトコルの特徴に依存しています。これらのプロトコルを効率良く配備すれば、ユニキャストプロトコルの相互運用性を利用できます。
DVMRP（Distance Vector Multicast Routing Protocol）はネットワーク間、又はルータ間のマルチキャストデータグラムを転送をサポートする距離ベクトル型経路制御方式である。DVMRP は RPB（Reverse Path Broadcasting） アルゴリズムを使用し、source based マルチキャスト送信木を構成する。DVMRP はもと MBone が使用していたものである。今日でも MBone ルータの半数以上が色々なバージョンの DVMRP を使用している。
DVMRP はまず RFC1075 で定義された。最初の DVMRP は RIP（RoutingInformation Protocol）から派生したもので、TRPB（Turncated Reverse PathBroadcasting）の技術を使用している。RIP と DVMRP との主な違いは、RIP は目的地に向けての次のホップを計算するのに対し、DVMRP は逆に今まで来たホップをその発信元に向けて（戻りながら）計算するといったことである。最新の mrouted のバージョン３.８が DVMRP に RPM（Reverse PathMulticasting）アルゴリズムを使うようにさせて、その役割を拡張させたことは重要である。これは、最近の DVMRP の使われ方があらゆる点で当初の rfc で定義された使われ方と違ってきているということを意味している。
DVMRP のルータの口は物理インターフェースから直接サブネットワークにつなぐか、トンネルインターフェースから他の「マルチキャストの島」へつなぐかのどちらかである。全てのインターフェースはポートの重みを表すパラメータと、マルチキャストデータグラムを通過させるかどうかを判定する材料となる TTL threshold により設定される。各トンネルインターフェースは更に２つのパラメータにより設定される。その２つとはローカルルータのインターフェースのＩＰアドレスと、リモートルータインターフェースのＩＰアドレスである。 もし、IP ヘッダの TTL フィールドが、インターフェースに割り当てられた TTL threshold よりも大きいならば、マルチキャストルータは、ただ単にマルチキャストデータグラムをマルチキャストインターフェース上に送り出すことしかしない。上の表は IP マルチキャストのスコープを制限した伝統的な TTL 値を示している。例えば、TTL が１６以下のマルチキャストデータグラムの場合、同じサイトに制限され、同じエリアの違うサイトにインターフェースを通して送り出すことはできない。
TTL-based scoping はいつも役に立つというわけではないので、IETF MBone ワーキンググループは、「administratire scoping」のためのマルチキャストアドレスの定義と使用法を考えている。他の言い方をすると、そのようなアドレスは例えば企業ネットワークのようなある administrative scope 内で使用できるが、広大な MBone を渡り歩くことはできないということである。現在のところ、239.0.0.0 ～ 239.255.255.255 の範囲内は administratirelyscoped application のためにリザーブされているが、この範囲内における構造や使用法はいまだに完全にはかたちづくられてはいない。
DVMRP は RPM（Reverse Path Multicast）アルゴリズムを使用している。RPM では、（送信元、グループ）の組の最初のデータグラムはネットワーク全体に転送される。自分に直接つながったサブネット上にグループメンバが全くいないルータは刈りとりメッセージを送信元に向けて送り返す。刈りとりメッセージにより枝は刈りとられ、マルチキャスト送信木にはグループメンバを葉として抱える枝のみが残る。一定時間が過ぎると、刈りとられた枝は再生し、また新たにマルチキャストデータグラムが葉全体に行き渡り、刈りとりメッセージが送られる。このようにして、マルチキャスト送信木は更新されていく。
DVMRP はグループの刈りとられた枝を素早く「つぎ木」する仕組みも持っている。もし、あるルータが（送信元、グループ）の組に対する刈りとりメッセージを送った後に葉ネットワーク上に新しいグループメンバを発見すると、ルータはつぎ木メッセージを１ホップ前のルータに対して送る。上流ルータはつぎ木メッセージを受けとった時には、以前の刈りとりメッセージを帳消しにする。つぎ木メッセージは生きている枝にたどり着くまで送信元に向かって滝のように流れて行く。このようにして刈りとられた枝は素早くつぎ木される。
あるサブネット上で DVMRP ルータが１つ以上存在する時、dominant ルータが定期的な IGMP Host Membership Query Message の送信を行なう。最初の立上り時には、DVMRP ルータは自分よりも低いＩＰアドレスを持つ隣接ルータからの IGMP Host Membership Query Message を受けとるまでは自分自身をそのサブネットワーク内の dominant ルータとみなす。下の図は低いＩＰアドレスを持つ DVMRP ルータが Dominant Router となっている例を示している。
サブネット上に一つ以上の DVMRP ルータが存在する時に、無駄な複製をさけるために一つのルータがサブネットの dominant router となる。下の図ではルータ C は下流に存在し、ルータ B もしくはルータ A からデータグラムを受けとる可能性がある。もし、送信元への距離がルータ A の方がルータ B よりも短い場合、ルータ A がこの送信元に対する dominant router となる。
これはルータ A がこの送信元からのパケットを転送し、ルータ B はパケットを破棄するということを示している。もし、送信元への距離がルータ A とルータ B で同じ場合には子リンクの下流インターフェースのＩＰアドレスの小さい方がその送信元に対する dominant router となる。DVMRP ルータが複数存在するサブネットワーク上に色々な送信元からのマルチキャスト交通が存在する場合、送信元ごとに違ったルータが dominant router になる可能性があることに注意して欲しい。
DVMRP は定期的に近隣 DVMRP ルータと経路制御表の最新情報を交換する。これらの情報はどのユニキャスト Interior Gateway Protocol とは論理的に違うものである。
DVMRP はユニキャストではなく、マルチキャストの経路制御を行なうために開発されたものなので、ルータは実際には複数の経路制御プロセスを立ち挙げる必要があるだろう。ユニキャストの経路制御を行なうためのものとマルチキャストの経路制御を行なうためのものである。
DVMRP 経路制御表はグループメンバーシップには関与していないので、DVMRP プロセスはマルチキャスト経路制御表とともに使用され、知られているグループと受けとった刈りとりメッセージにより構成される転送表を構築する。
MBone の激しい成長はルータにきりのなく増大する要求をする。サブネットワークの規模の増大は経路制御表とそれを保持するために使用されるルータのメモリの消費を巨大化させる。このような問題に対し何もしなければ、MBone ルータ達は著しく性能が落ちるか、機能しなくなるかのどちらかである。このような問題の解決のため、hierarchical DVMRP（階層化DVMRP）が開発中である。hierarchical 経路制御では MBone はいくつかのルーティングドメインに分割される。それそれのルーティングドメインは各自「intra-domain」なマルチキャスト経路制御方式を実行する。ドメイン間の経路制御は他のプロトコル又は同じプロトコルを使用する。
Hierarchical Routing では、ルータは自分のドメイン内の状況だけを把握していれば良いので、ルータにかかる負担は大幅に減少することになる。ドメイン間の経路制御を行なうプロトコルは各ドメイン全体ではなく、ドメイン間のつながりだけを考えれば良い。
経路制御情報を減らすだけではなく、hierarchical DVMRP を使用することによる利点はいくつかある。
・違ったマルチキャスト経路制御方式を MBone の色々な地域で使用すること が可能である。これによりドメイン間で使用するための新しいプロトコルの実験と開発が可能である。 ・リンクやルータの失敗は一つのドメイン内に存在するルータにしか影響を与 えない。同様に、トポロジー内の変化はドメイン内のルータにしか影響を与えない。このようなことは距離ベクトル型のプロトコルを開発する際に非常に重要である。 ・距離ベクトル型経路制御方式に関係した無限カウント問題により MBone の規模を制限していたが、hierarchial routing により、それは MBone 全体ではなく、各ドメイン内で制限されるようになる。MOSPFルーティングアルゴリズムの主要な特徴を示します。
１、 １つのマルチキャストデータグラムについて、OSPFエリア内のすべてのルーターが同じ送信元ベース最短経路配信ツリーを計算します。ユニキャストのOSPFとは異なり、MOSPFは同一コストの複数経路のルーティングはサポートしません。 ２、 グループメンバーシップのリンク状態レコードを含む同期化されたリンク状態データベースによって、MOSPFルーターは、送信元からグループメンバーができます。これは、DVMRPとは異なり、新しいマルチキャストの最初のデータグラムを、エリア内の全ルーターにフラッドする必要がないことを意味します。 ３、 送信元ベースの配信ツリーを「オンデマンド」に構築するので、計算が一時に集中せず、ルーターの負荷を減らすことができます。もちろん、同時に新規の対が多数出現する場合や、MOSPFに転送テーブルの再構築を強いるような大量のイベントが発生する場合は、ルーターの負荷は大きくなります。しかし、マルチキャストセッションが長時間でトポロジーが安定している場合は、これからの影響は最小限ですみます。MOSPFルータの機能とは、複数のルーターを持つサブネットまたはエリアでは、ある一つのルーターをMOSPFの指定ルーターとして選択し、他のルーターの一つをバックアップ指名ルーターに選択しなければなりません。指名ルーターは、各マルチキャストグループごとに直接接続するメンバーのデータべースを維持、管理し、OSPFエリア内の他のすべてのルーターにグループメンバーシップ情報を伝達する責任を持ちます。この通信は、Group-Membership LSAをエリア内にフラッドして行います。バックアップ指名ルーターは、指名ルーターに障害が発生した場合に、MOSPFの任務に代行します。
MOSPFの指名ルーターが、接続するサブネットに新規のグループメンバーの存在を認識すると、特殊なGroup-Membership LSAをOSPFエリア内の他のすべてのMOSPFルーターに送信します。MOSPFルーターがこれらのマルチキャストLSAを受信すると自身のリンク状態データベースにこのグループメンバーシップ情報を追加します。
LSAとは、各リンクについて次の情報を持ちます。
・ リンクのIPネットワーク番号 ・ リンクのサブネットマスク ・ リンクのメトリック ・ リンクの動作状態(アップ又はダウン)LSAは各ルータで受信され、それぞれのルータのLSDBに反映されます。OSPFはルータ間でLSAを配布するのにfloodingを使用します。ルート情報の変更は、ネットワーク上の全てのルータに送られます。エリア内の全てのルータは同一のLSDBを持ちます。
どのサブネットでも、IGMPのHost Membership Queriesの送出は、指名ルーターだけが行います。しかし、IGMPのHost Membership Reportsは指名ルーターとバックアップ指名ルーターの両者が聴取しなければなりません。
最初のデータグラムが到着すると、送信元のサブネットワークがMOSPFリンク状態データベースに置かれます。MOSPFリンク状態データベースは、標準のOSPFリンク状態データベースにGroup-Membership LSAから得た情報を追加したものです。OSPFリンク状態データベース内のルーターとネットワークのリンク状態レコードを使用して、送信元べースの最短経路ツリーが構築されます。このツリーが構築されると、Group-Membership LSA（リンクステート広報）によってツリーがプルーニング（枝を削除する処理）されて、このグループのメンバーを有するサブネットネットワークに通じるブランチだけが残ることになります。
下流のグループメンバーにマルチキャストデータグラムを転送するには、各ルーターは、そのデータグラムようの最短経路ツリーでの自身の位置を知らなければなりません。図6に、ある（送信元、グループ）対について最短経路ツリーの例をあげます。ルーターEの上流のノードはルーターBで、この下流には、それぞれGとHに導く２つのインターフェースがあります。
図6,１つの（送信元、グループ）対についての最短経路ツリー
それぞれのMOSPFルーターは、転送テーブルの内容に基づいて転送先を決定します。DVMRPとは異なり、MOSPFの転送はRPFベース（リバースパス転送）ではありません。転送テーブルは、（送信元、グループ）対ごとの送信元ベース最短経路ツリーと、ルーターのローカルグループデータベースから構築されます。ルーターが自身の位置をこの最短経路ツリー内に見つけると、対、上流インターフェース、下流インターフェースの三者からなるエントリーが転送テーブル内に作られます。この後、転送テーブルエントリーは、続くすべてのデータグラムをこの送信元からこのグループに転送するためにただちに使用されます。新しい送信元が新規グループに送信を開始すると、MOSPFはまず配信ツリーを計算し、パケットを転送するために使用するテーブルエントリーを作成しなければなりません。
表2は、MOSPFルーターの転送テーブルの例を示しています。テーブル内の各項目は次のとおりです。
Dest.Group（宛先グループ）
データグラムが現在転送中か、最近（すなわち、トポロジーの変化、グループメンバーシップの変化、あるいはMOSPFの転送テーブルが初期化されて以後）トラフィックが送出されたが既知の宛先グループアドレス。
Source（送信元）
データグラムの送信元ホストアドレス。（Dest.Group,Source）対によって転送テーブルエントリーを特定できます。
Upstream（上流）
この行のDest.GroupとSourceに一致するデータグラムはこのインターフェースで受信しなければなりません。
Downstream（下流）
この行のDest.GroupとSourceに一致するデータグラムが正しいUpstreamインターフェースで受信されると、記載されたDownstreamインターフェースから転送されます。
TTL（生存時間）
Dest.Groupのメンバーに到達するまでに経由しなければならないホップの最少数。MOSPFルーターは、データグラムのTTLがもっとも近いグループメンバーに到達するのにも不十分であると判断すると、このデータグラムを破棄します。
転送テーブル内の情報は、時間で失効したり定期的にリフレッシュされることはありません。システム資源が枯渇しない限り、または次のトポロジーに変わるまでは維持されます。転送テーブルの内容は、OSPFインターネットワークのトポロジーが変化して、すべての最短経路ツリーを再計算しなければならなくなったり、個々のグループメンバーの配置が変わってGroup-Membership LSAが変化した場合に変更されます。
エリアと自律システムでのルーティングについてOSPFは、一連のネットワークをエリアと呼ばれる領域にグループ化することができます。１つのOSPFエリア内のトポロジーは、他からは見えず、結果的にルーティングトラフィックが大きく軽減されることになります。さらに、エリア内部のルーティングは、そのエリア自身のネットワークトポロジーによってのみ決定されます。このことにより、不正なルーティングデータからエリアを保護することはできます。
OSPFは、エリアと自律システム（AS）を定義して、ルーティングの簡素化を実現しています。このため、MOSPFは、エリア間およびAS間のマルチキャストトラフィックを、OSPFのユニキャストトラフィックの場合と同様の方法でルーティングできなければなりません。マルチキャストの送信元とホストグループの何人かのメンバーが別々のOSPFエリアにいる場合には（図７）、エリア間のルーティングが必要です。エリア内のルーティングと同様に、マルチキャストデータグラムの転送は、ローカルグループデータベースと送信元ベースのツリーから構築される転送テーブルの内容によって決定されます。しかし、グループメンバーシップの情報を伝播する方法とエリア間で送信元ベースのツリーが構築される方法とのあいだには相違点があります。
図7、エリア間ルーティング
MOSPFは、エリア間マルチキャスト転送装置の概念を導入しています。エリア間マルチキャスト転送装置は、グループメンバーシップ情報と、マルチキャストデータグラムのエリア間での転送を担当します。ほとんどの場合、OSPFのABR（Area Border Router）が、エリア間マルチキャスト転送装置としても機能するように設定されます。
エリア間マルチキャスト転送装置は、接続するエリアのグループメンバーシップ情報を要約し、バックボーンに送出する必要があります。しかし、MOSPFにやるグループメンバーシップの送出は非対称です。つまり、非バックボーンエリアからのグループメンバーシップ情報はバックボーンにフラッドされますが、バックボーンからのグループマンバーシップ情報は非バックボーンエリアにはフラッドされません。エリア間マルチキャスト転送装置は、新規のGroup-Membership LSAを送出することで、作成した要約情報をバックボーンエリアに送出します。
この他に、エリア間のマルチキャストトラフィックの転送用にMOSPFで導入されている装置に、ワイルドカードマルチキャスト銃身装置があります。この装置は、配置されているエリア内で生成されたすべてのマルチキャストトラフィックを受信します。非バックボーンエリアでは、すべてのエリア間マルチキャスト転送装置はワイルドカードマルチキャスト受信装置として動作します。これにより、非バックボーンエリアで発信されるすべてのマルチキャストトラフィックは、そのエリア間マルチキャスト転送装置に配信され、そして必要なら、バックボーンエリアに転送されることが保証さえrます。バックボーンは全エリアのグループのメンバーシップを把握しているので、データグラムは、送信元エリアのエリア間マルチキャスト転送装置によってバックボーンに転送される限り、OSPFの自律システム内の適切な場所に転送されます。
プルーニングについて言えば、エリアにはこの他にも問題があります。マルチキャストデータグラムの送信元が計算を行うルーターと同じエリアにある場合、プルーニングの処理は、他のエリアに達している枝がツリーから削除されないように制御する必要があります（図8）。グループメンバーとワイドカードマルチキャスト受信装置のどちらかも持たない枝だけが、プルーニングによって削除されます。ローカルルーターは、他のエリアにグループメンバーが存在するかどうか知らないため、ワイドカードマルチキャスト受信装置を持つブランチは残しておく必要があります。
図8、送信元がメンバーと同じエリア内にある場合の最短経路ツリー
マルチキャストデータグラムの送信元が、最短経路ツリーを計算しているルーターとは別のエリアにいる場合は、送信元の端末周辺のローカルなトポロジーの詳細は分かりません。このような場合に情報を推定するための1つの方法が、送信元のサブネットワークのSummary-Links LSAによって提供される情報を使用することです。この場合は、ツリーの根元は、送信元のサブネットワークをローカルエリアのエリア間マルチキャスト転送装置に直接接続する枝たちで始まっています（図9）。ローカルエリア外部の送信元から送出されたデータグラムは、これらのエリア間マルチキャスト転送装置の1つを通じてこのエリア内に入るため、これらはすべて提供される配信ツリーの一部でなければなりません。
図9、送信元エリア外にある場合の最短経路ツリー
各エリア間マルチキャスト転送装置もABRであるため、接続しているエリアごとに個別のリンク状態データベースを維持しなくてはなりません。このため、各エリア間マルチキャスト転送装置は接続する各エリアごとに個別の転送ツリーを計算する必要があります。
自律システム（AS）間でのマルチキャストも、エリア間のマルチキャストで説明した方法と非常に似かよった方法で行われます。主な相違点は、自律システムは、内部で使用するのと同一のルーティングプロトコルを自律すシステム間では使用していないことから、EGP（Exterior Gateway Protcol）を使用するルーターを選び出してマルチキャストの処理を手伝わせる必要がある点です。
ABRがエリア間のマルチキャスト転送装置として使用されたように、選出された自律システム境界ルーター（ASBR：Autonmous System Boundary Routers）は、AS間マルチキャスト転送装置として設定され、AS間で、グループメンバーシップ情報とマルチキャストトラフィックを転送します。MOSPFは、各AS間マルチキャスト転送装置がりばーすパス転送（RPF）アルゴリズムに従ってマルチキャストデータグラムを転送するようなマルチキャストルーティングプロトコルを使用すると想定します。
さらに、各AS間マルチキャスト転送装置は、各接続エリア内でワイドカードマルチキャスト受信装置であり、したがって、各AS間マルチキャスト転送装置がプルーニング後のすべての最短経路ツリーの一部であるため、すべてのマルチキャストデータグラムを受信することが保証されます。
AS間転送の詳細はエリア間の転送と非常に良く似ています。OSPFドメインの内部では、マルチキャストASBRはエリア内とエリア間の転送におけるすべての要件を満たす必要があります。OSPFドメインの中では、通常の転送経路の計算によってグループメンバーに到達することができます。外部の送信元までの経路は、マルチキャストASBRに実際の送信元を代行させたリバースパス送信元ベースのツリーで、概算できます。送信元がOSPF自律システム内部にあり、外部にグループメンバーが存在する場合は、AS間マルチキャスト転送装置がワイルドカード受信装置として機能し、OSPFドメインからデータを取得して正しい方向に送出する必要があります。
MOSPFの利点としては、OSPFのような状態ルーティングプルトコルは、距離ベクトルアルゴリズムよりも高速で優れた収束性を持つことが認識されています。これと同様に、MOSPFのリンク状態アプローチも、グループメンバーシップの変更や、ネットワーク資源の枯渇にシステムがすばやく対応することを可能とします。さらに、リンク状態プロトコルであることにより、MOSPFは、グループのメンバーシップまたはネットワークトポロジーを決定するためにパケットのフラッドに依存する必要がありません。
MOSPFはOSPFと相互運用が可能なため、マルチキャストトラフィックの処理と同時に、通常のユニキャストIPトラフィックの転送にも使用でき、配備を簡素化できます。さらに、MOSPFは、送信元ベースのツリーを構築するのに、DVMRPが使用する単純なホップカウントの代わりに、OSPFと同じ柔軟な経路メトリックを使用することもできます。このため、MOSPFはコストベースまたはQoSベースのルーティングをさらに柔軟にサポートすることができます。
欠点としては、ユーザーによっては、MOSPFがトンネリングをサポートしていないことから、MOSPFを使用するネットワークがMboneに参加するにはDVMRPに依存しなければならないことが一ついえると思います。
一方、MOSPFは、すべてのマルチキャスト送信元に関して、送信元とグループの組み合わせのそれぞれについて、ルーターが最短経路に計算を行う必要があり、計算処理に依存する度合いの高いルーティングプロトコルです。Dijkstaアルゴリズムで最短経路ツリーを計算するのに要する処理能力も、ネットワークの規模が増大するにつれて問題になります。
さらに、MOPSFは、散在タイプのトポロジーを取り扱うには不向きな点があります。
カメラ本体：ロージック Qcam Express QV－30
Linuxのカーネルを/usr/src/linuxに展開します
カーネルをmulticast対応にするため、カーネルの再構築をします
カーネルの設定
カーネル2.2では、IP:multicasting,IP:yunneling,IP:multicast routingの機能を組み込む必要があります。そのため、以下の作業を行います。
cd /usr/src/linux
make config
ここからオプションの設定の始まりです。設定のほとんどで、「y」キーと「n」キーが使えます。大文字で「Y」や「N」のように表示されているときは、現在設定されている状態が「y」または「n」であることを表わしています。そのままEnterキーを押すと、そのとき設定されているものがそのまま引き継がれます。
「Networking options」に
*
*
* Networking options
*
TCP/IP networking (CONFIG_INET) [y]
IP forwarding/gatewaying (CONFIG_IP_FORWARD) [n]
IP multicasting (CONFIG_IP_MULTICAST) [n]
IP firewalling (CONFIG_IP_FIREWALL) [n]
IP accounting (CONFIG_IP_ACCT) [n]
*
* (it is safe to leave these untouched)
*
PC/TCP compatibility mode (CONFIG_INET_PCTCP) [n]
Reverse ARP (CONFIG_INET_RARP) [n]
Assume subnets are local (CONFIG_INET_SNARL) [y]
Disable NAGLE algorithm (normally enabled) (CONFIG_TCP_NAGLE_OFF) [n]
The IPX protocol (CONFIG_IPX) [n]
*
の内、
IP: multicasting (CONFIG_IP_MULTICAST) [Y/n/?]
IP: tunneling (CONFIG_NET_IPIP) [M/n/y/?]
IP: multicast routing (CONFIG_IP_MROUTE) [N/y/?]
の３項目をチェックする。
# make-kpkg clean
# make-kpkg --revision ??.? kernel_image
を入力する。
dpkg i kernel _image_?.?.??_??_????.deb
kernel_image_～が/usr/src/にできますので
dpkg iコマンドでインストールし、再起動する
そして、次のソフトウェアをインストールします。
mrouted
sdr
vic
rat
wbd
（Debianなら、dselectにより指定するだけ）
マルチキャスト・データグラムを、そのデータグラムの発信元であるサブネットをルートとする最短の パス・ツリー (逆ツリー)により転送します。マルチキャスト送達ツリーは、宛先グループのメンバを持つサブネットワークの範囲を超えないように余分な部分が取り除かれたブロードキャスト送達ツリーであると考えられます。したがって、データグラムは、マルチキャスト・グループのリスナを持たないブランチには転 送されません。マルチキャスト・データグラムの IP 存続時間に基づいて、マルチキャスト・データグラムの範囲を限定できます。
・トンネリングをサポートする仮想 2 地点間リンクであるトンネルをサポートしています。 IP マルチキャスト・パケットは、トンネルを介して伝送するためにカプセル化されます。したがって、それらのパケットは、介在する側のルータ やサブネットからは通常のユニキャスト・データグラムに見えます。カプセル化されたパケットは、トンネルに入った時点で追加され、トンネルを抜けたときに取り除かれます。デフォルトでは、パケットは、IP-in-IP プロトコル (IP プロトコル番号 4) を使用してカプセル化されます。
mroutedは、Distance Vector Multicast Routing Protocol (DVMRP) です。DVMRPは、マルチキャストパケットを送信元ネットワークからすべてのグループメンバに配送するために，送信元を頂点とした配送ツリーを形成します。この配送ツリーはグループの全てのメンバに到達するために必要な最小の配送ツリーに保たれます。まず，送信元から各グループに対して最短パスで到達できるように，距離ベクタルーティングアルゴリズムを使用して送信元からの最短パスを決定します。これは，受信したマルチキャストパケットを中継する時，Reverse Path Forwardingチェックを行ない，送信元からの最短パス経由で受信したかの判断に使用します。グループメンバが存在しないインタフェースの場合，最初のマルチキャストパケット中継後DVMRP-Pruneで刈り込まれ，また新しいメンバがグループに参加した場合，DVMRP-Graftメッセージの送受信により，再度，配送ツリーに付加されます。
mroutedは、設定ファイルmrouted.confにより設定を行う。又、動作状況の確認は、プロセスにシグナルを送る方法による。以下では、これらについて説明する。
name local 239.255.0.0/16
name ee 239.254.0.0/16
phyint eth0 boundary ee
を記入して保存をする。
mrouted version 3.9-beta3 up 458:43:11 Thu Jan 10 15:18:57 2002
vifs_with_neighbors = 1
[This host is a leaf]
Virtual Interface Table
Vif Name Local-Address M Thr Rate Flags
0 eth0 192.168.3.254 subnet: 192.168.3/24 1 1 0 querier leaf
group host (time left): 224.0.0.2 192.168.3.254 ( 0:04:11)
224.0.0.4 192.168.3.254 ( 0:04:06)
IGMP querier: 192.168.3.254 (this system)
Nbr bitmaps: 0x0000000000000000
pkts/bytes in : 117/10495
pkts/bytes out: 0/0
1 eth1 192.168.1.1 subnet: 192.168.1/24 1 1 0 querier
peers: 192.168.1.4 (3.255) [2] have-genid up 458:43:12
192.168.1.10 (3.255) [1] have-genid up 458:43:14
192.168.1.3 (3.255) [0] have-genid up 458:43:14
group host (time left): 224.0.0.2 192.168.1.10 ( 0:04:03)
224.0.0.4 192.168.1.3 ( 0:04:09)
IGMP querier: 192.168.1.1 (this system)
Nbr bitmaps: 0x0000000000000007
pkts/bytes in : 396/20088
pkts/bytes out: 117/10495
Multicast Routing Table (4 entries)
Origin-Subnet From-Gateway Metric Tmr Fl In-Vif Out-Vifs
192.168.4/24 192.168.1.10 2 60 .. 1 0*
192.168.3/24 1 170 .. 0 1[2,1,0]
192.168.1/24 1 170 .. 1 0*
133.20.160/24 192.168.1.3 2 60 .. 1 0*
この例では、2つのサブネットで2つの vif があります。 vif 0 サブネットおよび vif 1 サブネットには、いくつかのグループがあります。トンネルにはグループはありません。mroutedのこのインスタンスは、「querier」フラグで示される vif 0 サブネットおよび vif 1 サブネットに関するグループ・メンバーシップ照会を定期的に送信する役割を担っています。 境界のリストは、そのインターフェース上の範囲指定されたアドレスを示します。また、着信パケットおよび発信パケットの no. (番号) のカウントについてもそれぞれのインターフェースで示されます。
マルチキャスト・データグラムの発信元となり得る各サブネットに関連するものとして、前のホップ・ルータのアドレス (サブネットが直接接続されない場合)、発信元に戻されるパスのメトリック、このサブネットの更新を最後に受信してから経過した時間、その発信元からのマルチキャストのための着信 vif、および発信 vif のリストがあります。アスタリスク (*) は、発信 vif が発信元をルートとするブロードキャスト・ツリーのリーフに接続されていて、そのリーフ上に宛先グループのメンバがある場合にのみその発信元からのマルチキャスト・データグラムがその発信 vif に関して転送されることを意味します。
また、mrouted はカーネル転送キャッシュ・テーブルのコピーも保持します。 エントリは mrouted によって作成され削除されます。
・キャッシュの読み方 -USR2:内部キャッシュ・テーブルを /usr/tmp/mrouted.cache にダンプします。
mrouted version 3.9-beta3 up 458:46:37 Thu Jan 10 15:22:23 2002
Multicast Routing Cache Table (0 entries)
Origin Mcast-group CTmr Age Ptmr Rx IVif Forwvifs<(prunesrc:vif[idx]/tmr) prunebitmap
>Source Lifetime SavPkt Pkts Bytes RPFf
133.20.160/24 224.0.1.24 0:03:02 0:31:13 0:47:00 0 1P
133.20.160/24 239.255.255.250 0:02:28 0:46:16 1:13:12 0 1P
133.20.160/24 239.255.255.253 0:00:41 1:14:46 1:02:24 0 1P
各エントリは、発信元サブネットの番号とマスク、宛先マルチキャスト・グループに特徴があります。CTmrフィールドは、そのエントリのライフタイムを示します。タイマがゼロに減少すると、エントリはキャッシュ・テーブルから削除されます。経過時間フィールドは、このキャッシュ・エントリが最初に作成されてから経過した時間です。トラフィックが流れているとキャッシュ・エントリがリフレッシュされるため、経路指定エントリが非常に古くなる可能性があります。Ptmr フィールドは、プルーンが上流に送られなかった場合はダッシュだけで、送られた場合は、アップストリーム・プルーンがタイムアウトになるまでに経過した時間です。 Ivif フィールドは、その着信元からのマルチキャスト・パケットの着信 vif を示します。各ルータは、特定のグループおよびソースに関して、隣接するルータから受信したプルーンの数のレコードも保持します。サブネットのマルチキャスト・ツリーのいずれかの下位リンクにマルチキャスト・グループのメンバがいない場合、プルーン・メッセージはアップストリーム・ルータに送られます。これらは、vif 番号の後ろに Pが付いて示されます。Forwvifs フィールドは、ソース・グループに属するデータグラムが転送されるインターフェースを示します。 p は、そのインターフェースを介して転送されるデータグラムがないことを示します。表示されていないインターフェースは、そのサブネット上の特定のグループのメンバでないリーフ・サブネットです。インターフェース上の b は、それが境界インターフェースであることを示しています。つまり、そのインターフェースの範囲指定されたアドレス上ではトラフィックが転送されません。先頭文字として大なり記号 (>) の付いた追加の行は、サブネット上の各ソースごとに出力されます。1 つのサブネットに多数のソースがある場合は注意してください。
・gated BGMP,PIM-SM,PIM-DM,MSDP コンソーシアムメンバーのみ配布可
・pimd PIM-SM
・zpimd
図10.sdr
``Public Sessions'' に表示されているリストは，その時点でアナウンスされている放送を示します。名前の左にあるアイコンをクリックすることにより，その放送の情報が表示されます。次はその表示の例です。
図11.セッションの詳細
講演会や遠隔会議のような内容を Mbone で放送する場合，その番組一つ一つを``セッション''と呼んで区別します。ここで「join」を選択すると、このセッションに参加することができます。
・セッションの作成とアナウンスさて、sdrでは、既存のセッションへの参加だけではなく、新たにセッションの作成ができます。
セッションを作成するためには次のような情報が必要です。これらの情報を sdr に登録し，アナウンスを行います。
１、セッション名 セッション内容の説明 セッションの配信範囲 セッションで用いるメディアの指定 セッションの開始時間等のスケジュールの指定 セッションに関する問い合わせ先これらセッション情報は， sdr が定期的に送信する IP マルチキャストパケットにより告知されるため，セッション情報を作成した sdr が何らかの理由で終了してしまうと無効となってしまいます。したがって，セッション情報を作成する sdr は，常に動作している UNIX ワークステーション上のものを利用されることをお勧めします。
まず，セッションをアナウンスする前に， ``Prefs'' というボタンをクリックし， ``You'' をクリックして自分の名前，メールアドレス，電話番号がきちんと登録されていることを確認してください。
図12.sdrのプレファレンス（個人情報の設定）
``Preference''ウインドウを閉じたら， ``New''メニューの``Create advertised session''を選択し，``Create New Session'' ウインドウを開きます。そして，セッションのタイトルを ``Session Name'' に，内容の説明を ``Description'' に入力します。
図13.セッション情報の設定
配信範囲を指定するには， ``Area Reached'' セレクタを用います。 SuperTAINS 内にのみ配信する場合には，``Local Scope'' を選択すれば，それに応じた IP マルチキャストアドレスと TTL の値が設定されます。他の ``Region''，``World'' を選択すると，大きな TTL 値が設定されるなどして，全世界や全国の Mbone に影響を及ぼしますから，この場合にはインターネット (Mbone) 全体の約束事を守る必要があります。 SuperTAINS 外へ配信する場合はまず mbone-tohoku ML に参加し，そこで設定の方法を問い合わせましょう。
次にセッションで用いるメディアを ``Media'' から選択します。 Mbone では，音声は DVI が，動画像は H.261 が一般的に用いられます。
そして，``Session will take place ...'' にセッションのスケジュールを設定し， ``Person to contact about this session'' に誤りが無いことを確認したら，``Create'' ボタンを押してセッションのアナウンスを開始します。すると， sdr の ``Public Sessions'' に作成したセッション名が表示されるでしょう。
ここで作成したセッション名をクリックし， ``Contact Details'' も表示させ，TTL の値が 15 以下かどうか，その他の項目が意図した設定になっているかどうかを確認します。(図5)
もし設定等に誤りがあった場合は，``Delete'' ボタンを押すことでセッションアナウンスを取り消し，新たにセッション情報の作成と告知を行います。
図4-4-1 sdr5
図14.セッション情報の確認
wbdとは、皆で white board を共有するための tool です. セッションで使用されていることもあります.
図15.wbd
vicとは、画像送受信のための tool です. 送信のためにはキャプチャボードが必要ですが, 受信には特 別なハードウエアは必要ありません. 小さな画像の部分を クリックすると, 新たなウィンドウが開き, 映像を見ることができます.
# /etc/init.d/mrouted start
~$ vic 239.254.0.0/2999
vic が起動されると，図 8に示すウインドウが開きます。はじめは動画像は表示されませんが，送信を開始した時点で，図のように自分が送出している画像とその情報が表示されます。
図16.vic
図17.vicの設定ウィンドウ
送信を開始する前に，動画像の品質の設定を行います。図8のウインドウで ``Menu'' ボタンを押すと，図9の様なウインドウが開きます。一般に Mbone では，動画像の送出レートは 128 [Kbit/sec] 以下を用いることが推奨されていますので， ``Rate Control'' スライドを用いて 128 [Kbit/sec] 以下に設定します。 (*1) 送信を開始するためには，図9のウィンドウで ``Transmit'' ボタンをクリックします。すると，ボタンの色が赤くなり，``f/s'' や ``kb/s'' の値が状況によって変化しますので，送信中かどうか確認することができます。
送信を停止するためには，再度 ``Transmit'' ボタンをクリックします。この時ボタンの色がもとの灰色に戻り，``f/s'' や ``kb/s'' の値も次第に 0 に近づいていきますので，送信を停止したがどうか確認することができます。
ratとは、音声会議システムのツールです。ratは狭帯域でも高品質の音声が利用できるように開発されている。
図18.rat
図19.実験ネットワーク構成図
name local 239.255.0.0/16
name ee 239.254.0.0/16
phyint eth0 boundary ee
# /etc/init.d/mrouted start
s6またはs11で
#sdr
でvic,wbdを参加させ
#vic 239,254.0.0/2997
#wbd 239.254.0.0/2997
で起動する。（ソフトの使い方は４，４を参照のこと）
＜mrinfo＞
127.0.0.1 (localhost) [DVMRPv3 compliant]:
192.168.3.254 -> 0.0.0.0 (local) [1/1/querier/leaf]
192.168.1.1 -> 192.168.1.4 (s2.net.c.dendai.ac.jp) [1/1/querier] 192.168.1.1 -> 192.168.1.10 (s10.net.c.dendai.ac.jp) [1/1/querier] 192.168.1.1 -> 192.168.1.3 (s1.net.c.dendai.ac.jp) [1/1/querier]
＜mnetsted＞
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------------------------------------------
I0 1 ALL-SYSTEMS.MCAST.NET
eth0 1 ALL-SYSTEMS.MCAST.NET
eth0 1 ALL-SYSTEMS.MCAST.NET
eth0 1 DVMRP.MCAST.NET
eth1 1 ALL-SYSTEMS.MCAST.NET
eth1 1 ALL-SYSTEMS.MCAST.NET
eth1 1 DVMRP.MCAST.NET
#tunnel 192.168.4.254 192.168.1.1
phyint 192.168.4.254
phyint 192.168.1.10
インターネットでのマルチキャストにおける問題点として、すべてのインターネット・ルータがマルチキャスト・データグラムを配送できるわけではないということが挙げられる。これを解決するために、mroutedというデーモンを使って、マルチキャスト・データグラムを、あるルータから別のルータへマルチキャストの経路制御に関連しない中間のルータを通してトンネルさせることができる。この場合は、mrouted がIPデータグラムをIPデータグラムにカプセル化して送り、受信側の mrouted がそれからもとのデータグラムを取り出すという処理を行なう時に必要になる。
IP マルチキャストとは、ネットワーク層で１対多の通信を行うものであり、発信サイトはクラスD(224.0.0.1 － 239.255.255.255)とよばれる特別なアドレスに対してデータを１つ送るだけで複数の受信サイトに配送できる。各受信サイトがひとつひとつ発信サイトにデータを要求するより大変効率的であり、WWW がそうであるように、今後発展が期待されるプロジェクトとして注目を集めている。
そして、マルチキャストパケットの経路制御はmroutedで行う。コンフィギュレーションファイルである/etc/mrouted.confを適切に設定すれば外部の組織とマルチキャスト通信を行なえるようになる。重要なことはどれだけの帯域をとるかである。細いリンクではその利用バンド幅を越えた大きなtrafficをかけることはできないが、太いリンクのところでは、大きなtrafficを使える。画像の転送もより速く行うことが可能である。
そして、テレビ会議を行うアプリケーションとしてvic、wbd、sdr、ratなどが開発されている。。vicは、画像送受信をするためのツールで、wbdは、 white board を共有するためのツールで、sdrは、放送情報管理用のアプリケーションで、ratは、音声送受信をするためのツールである。今回の実験では、時間の都合上ratは使用することができなかったが、テレビ会議などの、音声、画像を必要とする機会には、とても重要なツールとなると考えている。
今回の実験では、sdrを用いずにその他のツールをマルチキャストで行おうとしたが、それは実現しなかった。それは、sdrが、その引数として IP マルチキャストアドレスや TTL の値を指定することで，放送の送信や受信が行えるようになること。そして，このツール無しでいちいちその値をメールで通知したり，それを見てアプリケーションの起動毎に入力するのは大変であり、放送で用いられる IP マルチキャストアドレスや TTL 値の通知だけではなく，放送で用いられるアドレスの予約，放送の内容やスケジュールのアナウンスがいっぺんに行える便利な放送情報管理用のアプリケーションであるsdrがマルチキャストを行う上で重要であり、また大切な働きをしていることが改めて分かり確認することができた。
最後に、今回の実験では、使用したアプリケーションソフトは、同室内でのマルチキャストであったので、大きなtrafficを要する画像に関してはあまり鮮明ではないが、相手とコミュニケーションをとる分（表情を見る分）には問題ないことが分かった。また、wbdのようなアプリケーションは、何の遜色なく使用することができることも確認できた。動作は、マルチキャストという希望する部分にだけのデータを伝送するということは、アプリケーションソフトの前に、ルーターの存在が非常に大切になってくるこたが分かりました。その上に、グループメンバーの管理するプロトコル、ルーティングプロトコルであるIGMPやDVMRPなどが重要になっていきます。そして、今回使用した、ルーターソフトであるmroutedは、マルチキャスト通信の行う上で、非常に手軽（フリーソフトであるから）に、また簡単な操作、設定にによって実行できる便利なサービスだと思います。
このように、IPマルチキャストは経済条件が整い，広く普及すれば将来の双方向デジタルエンターテイメント／コミュニケーショへの道を切り開くものになる。そして、IPマルチキャストとは，端的に言うと，巨大なメディアファイルを公衆ネットワーク上でストリーミング再生するための非常に効率の良い手法であるということが分かると思う。しかし，これでは既に確立されている技術（つまりTV）と大差はない。本当に面白くなるのは，この組み合わせに双方向コミュニケーションの要素が加わる段階からだと，指摘されている。そして、コンシューマーがマルチキャストの可能性を完全に享受するためには，ケーブルモデム，衛星受信機，もしくはDSL回線などのインターネットへの高速回線が家庭にも普及する必要があると考えられる。
マルチキャストのインフラストラクチャの発展は、１９９７年まで公衆にインターネットでIPマルチキャストを利用する唯一の方法がMBoneの利用でした。
しかしこの状況は、１９９７年に米国内の主要なインターネットサービスプロバイダの数社が、独自のマルチキャストサービスを使用上の制約があるのは認めざるを得ませんが、これは出発点です。１９９７年にIP Multicast Initiativeによって調査された企業の多数が、音声とビデオの配信にために企業内でマルチキャストを使用していること考えれば、ISPが最初にストリーミングマルチメディアに集中して研究をしたことは当然のことと言えます。消費者市場においては、ニュースや娯楽をマルチキャストを通じて配信することが、インターネットにおけるマルチキャストの最初の主要な使用方法であることがわかる。
ただし、このような新しい商用マルチキャストネットワークは、独自の問題を引く起こします。このようなサービスは自身のISPネットワークのクライアントにのみマルチキャスト配信を提供します。特定のホストグループのメンバーになりたいが、たまたま別のISPからサービスを受けているような場合、そのセッションはユニキャストによって受信できますが、マルチキャストデータとしては受信できません。
このアプローチがISPに依存しないアプローチへと発展する前に、解決しなくてはならないさまざまな問題点があります。まずIETFが、ドメイン間マルチキャストのルーティングプロトコルを標準規格化し、ISPがそれを展開しなくてはなりません。
次に、イントラネットでの発展は、ビジネスの世界では、すでにBBN Visionなどのような商用マルチキャストサービスを、ストリーミングマルチメディアの配信以外でも使用しています。しかし、今後数年間のマルチキャストの展開において、イントラネットが重要な拠点になる可能性は非常に高いでしょう。
企業ネットワーク内にIPマルチキャストを展開することは、ある意味インターネット上で行うより簡単です。これは主に、企業がネットワークを制御していることによります。また、企業内で利用することに、ビジネス上の利点があることが明らかである限りIPマルチキャストが企業ネットワークに発展していくでしょう。
主要なアプリケーションとしてリアルタイムなテレビ会議システム程度しかない現状としては、IPマルチキャストの技術を利用する人に対して調査を行った結果、６０％以上がオーディオとビデオの配布でした。また、回答者の約４０％が、共同作業と会議用にマルチキャストを利用しています。これらマルチキャストトラフィックの多くはインターネット上というよりも、むしろ企業内のイントラネットに限定して利用されています。この理由として、1つ目は、社内に業務上の情報を配布する必要性が非常に大きいことです。２つ目は、イントラネットであれば自分たちでネットワークを制御できることです。最後に、ISPがインターネット上でマルチキャストを日常的にサポートするためのインフラストラクチャを構築し始めたのはごく最近であることからです。
また、今後予想されるのは、共同作業やワークフロー用のアプリケーションがもっとマルチキャストを使用するようになるにつれて、ストリーミングマルチメディア以上でないにしても、それと同等には重要になってくるということです。さらに、情報発行ー購読登録のシステムによる情報の流布が今後成熟するにつれて、マルチキャストの利用も増大するでしょう。
また、他のプロトコルとの連携としては、プロトコルの多くは、別々の開発グループによって設計されたものでしたが、これらを組み合わせてもうまく動作します。IPマルチキャストはこの種の努力の一環であり、その継続的な成長およびIPネットワークへの実装は、他のプロトコル、特にIPv６とRSVPの開発によって影響を受けることになるでしょう。
そして、現在のIPマルチキャストとマルチメディアとの強力な連携が意味するのは、IPマルチキャストと統合サービスアーキテクチャ、特にRSVPにおける開発が相互に影響を与えることです。実際にRSVPは、誕生当初からマルチキャストセッションに焦点を置いてきました。現在、RSVPのサポートが数種のルーターに組み込まれているにもかかわらず、その展開には制約があります。ネットワーク管理者が、RSVPがどの程度うまく動作するかということや、ルーター資源とネットーワークトラフィックへの影響を実感できるようになるまではもう少し時間がかかるでしょう。
将来に向けた挑戦としては、IPマルチキャストが、ネットワークの主要な利用に与える影響として、マルチメディアやテレビ会議に必要な帯域幅が削減できる、情報に必要な資源が簡素化できるということが上げられます。多くの場合、IPマルチキャストを利用するための技術は、登場してから比較的日が浅く、インターネットやイントラネットで徐々に主流になりつつあります。
そんな中、今後マルチキャストに依存する比率がますます高まるであろうネットワークアプリケーションは、ストリーミングマルチメディア、テレビ会議、情報発行ー購読登録のデータ配信だけではなく、いくつかのグループで研究が行われている領域の１つに分散型シュミレーションなどがあります。例えば、戦闘シュミレーション、マルチパーティゲームに関する研究なども行われ、リアルタイムまたはそれに近い通信を必要とするこのようなアプリケーションのニーズに焦点を合わせている部分もあります。
また一方では、ビジネスの世界はますますモバイルになっています。複数の場所を頻繁に移動する社員のために、ホームオフィスやサテライトオフィスを用意するというだけでなく、セルラーモデルやその他のワイヤレス技術をノートパソコンに組み合わせると、社員の場所や時間を問わずネットワークを利用できるようになります。IPネットワークの古い考え方では、IPアドレスは固定的な地理上の場所に関連付けられていました。しかし、今ではそうではありません。モバイルIPの標準規格が現在検討中であり、同時にモバイルノードへのマルチキャストトラフィックの扱いについての提案も検討中です。最終的には、ユーザーは自分の位置やネットワークリンクにかかわらず、送信側または受信側として、あるいはその両方としてマルチキャストセッションに参加できるようになるでしょう。
マスタリングTCP/IP（IPマルチキャスト編）
著者 Dave Kosiur
監訳 苅田 幸雄
企画編集 オーム社開発局
発行者 佐藤 政次
発行所 オーム社
http://www.tains.tohoku.ac.jp/news/st-news-13/3342.html
http://www.tohoku.ac.jp/TAINS/SuperTAINS/news/st-news-17/2130.html
http://www.lab1.kuis.kyoto-u.ac.jp/members/magician/network/mbone.html
http://www.soi.wide.ad.jp/iw2000/iw2000_tut/slides/13/82.html
http://iplab.aist-nara.ac.jp/member/visoo-va/mynotes/Multicast/multicast-basic.html
http://homepage1.nifty.com/masawat/sen_html/intbasic.html
http://www.sfc.wide.ad.jp/~akimichi/multicast/dvmrp.html
http://www.jal-foundation.or.jp/html/eBusiness2/b_02InternetFukyu.htm
http://efs.dpc.ehime-u.ac.jp/KOUHOU3/nitta.html
http://www.accs.or.jp/multicast/setup_sdr_unix.html
http://www.cc.kek.jp/doc_link/Ja_JP/a_doc_lib/cmds/aixcmds3/mrouted.htm
http://www.ma.kagu.sut.ac.jp/doc/LANG/ja/HOWTO/NET-2-HOWTO-8.html
http://efs.dpc.ehime-u.ac.jp/KOUHOU3/nitta.html
http://iplab.aist-nara.ac.jp/~mana-hi/rt/tunneling.html