4.3 IP マルチキャスト

イーサネットのような多元接続ネットワークはマルチキャストをハードウェアで実装する。しかし、一部のアプリケーションはインターネットのスケールで効率的に行えるマルチキャストを必要とする。例えばラジオ放送局がインターネットを通じてラジオを放送するとき、その放送局に耳を傾けている全てのホストに同じデータを送信しなければならない。この例では通信が一対多となる。この他にも一対多の通信を行うアプリケーションの例としてニュース、現在株価、ソフトウェアアップデート、テレビ映像の送信が考えられる。インターネットを通じたテレビ映像の送信は IPTV と呼ばれる。

通信が多対多のアプリケーションも存在する。例えばマルチメディア通信会議、オンラインの多人数ゲーム、分散シミュレーションなどである。こういったケースでは、何らかのグループに属するメンバーが複数の送信元からデータを受け取り、たいていは受け取った側も複数のメンバーに向けてデータを送り返す。特定の送信元から送られるデータはどのメンバーに対しても同一となる。

パケットを単一のホストに宛てて送信しなければならない通常の IP 通信は、こういったアプリケーションに適していない。ホストのグループにデータを送信したいなら、同一のデータが入った個別のパケットをグループのメンバーそれぞれに送信しなければならない。この結果、重複したデータによって帯域が必要以上に消費される。さらに、重複したデータが消費する帯域は公平ではなく、負担は送信元ホストに集中する。送信されるデータ量は送信元ホストおよびその近くのネットワークとルーターが扱える量を容易に上回ってしまう。

多対多通信と一対多通信のサポートを向上させるため、イーサネットのような多元接続ネットワークが提供するリンクレベルのマルチキャストと同様の IP レベルのマルチキャストを IP は提供する。IP におけるマルチキャストの概念が紹介されたので、これまでに説明してきた古典的な一対一の通信サービスに対する言葉も必要になる: このサービスはユニキャスト (unicast) と呼ばれる。

基本的な IP マルチキャストのモデルでは、マルチキャストのグループ (group) という概念が登場する。グループはホストの集まりであり、一つのマルチキャストアドレスが関連付く。グループに関連付くマルチキャストアドレスに宛てられたパケットは、グループのメンバーである全てのホストに送信される。ホストは複数のグループに所属でき、グループの入退出は後述されるプロトコルでローカルのルーターと通信することで行う。そのため、ユニキャストアドレスはノードまたはインターフェースに関連付くと考えてきたのに対して、マルチキャストアドレスは抽象的なグループに関連付く。さらに、オリジナルの IP マルチキャストのサービスモデルでは任意のホストがマルチキャストトラフィックをグループに送信できる: グループのメンバーである必要はなく、グループに対してパケットを送信できるホストの数に制限はない。

IP マルチキャストを使って同一のパケットを特定のグループの各メンバーに送信するとき、送信元ホストはそのグループのマルチキャストアドレスを宛先としたパケットを一度だけ送信する。送信元はグループに属する各ホストの個別のユニキャストアドレスを知っておく必要はない。なぜなら、これから見るように、その知識はインターネットワークのルーターの間で共有されるからである。同様に、ルーターは複数のリンクにパケットを転送するときパケットをコピーするので、送信元がパケットのコピーを何度も送信する必要はない。IP ユニキャストで同じパケットを多くの宛先に何度も送る方法と比べると、IP マルチキャストはスケーラビリティが高い。同じリンクを何度も通過する冗長なトラフィックが (特に送信元ホストの近くで) 減るためである。

IP そのものが持つ多対多マルチキャストを補強する別形式のマルチキャストとして、SSM (Source-Specific Multicast) と呼ばれる一対多のマルチキャストが存在する。SSM では、受信ホストがマルチキャストグループと特定の送信元ホストの両方を指定し、指定したグループに宛てられたマルチキャストであって指定した送信元から送られたものだけを受け取る。インターネットのマルチキャストアプリケーションの多く (例えばラジオ放送) は SSM のモデルに当てはまる。SSM と対照的に、IP そのものが持つマルチキャストの多対多モデルは ASM (Any Source Multicast) と呼ばれることがある。

ホストがマルチキャストグループに対する入退室を行うときは、この用途でだけ使われる特別なプロトコルでローカルのルーターと通信を行う。このプロトコルは IPv4 では IGMP (Internet Group Management Protocol) と呼ばれ、IPv6 では MLD (Multicast Listener Discovery) と呼ばれる。ルーターは新しくグループに参加したホストに対してマルチキャストパケットを正しく転送する責務を負う。ホストがグループからの離脱をルーターに伝えることを (クラッシュしたときなどに) 忘れる場合があるので、ルーターは定期的にネットワークを調査して接続されたホストを持たないグループがないかどうかを確認する。

4.3.1 マルチキャストアドレス

IP のアドレス空間は一部がマルチキャスト用に予約されている。IPv4 ではクラス D のアドレス空間がマルチキャスト用であり、IPv6 では 1111 1111 で始まるアドレスがマルチキャスト用である。マルチキャストアドレスの一部はドメイン内マルチキャスト用と定められており、異なるドメインが独立して利用して構わない。

よって IPv4 では、マルチキャストアドレスの長さは共通のプレフィックスを除くと 28 ビットとなる。このため、LAN (local area network) 上でハードウェアが持つ情報を活用してマルチキャストを行おうとすると問題が発生する。例としてイーサネットを考えよう。イーサネットのマルチキャストアドレスは共通のプレフィックスを除くと 23 ビットしかない。言い換えれば、イーサネットのマルチキャストを利用するには、IP は 28 ビットの IP マルチキャストアドレスを 23 ビットのイーサネットのマルチキャストアドレスに射影しなければならない。これは IP マルチキャストアドレスの下位 23 ビットをイーサネットのマルチキャストアドレスとして使うことで実装される (このとき上位 5 ビットは無視される)。そのため、マルチキャストでは同じイーサネットアドレスに射影される IP アドレスが 32 (2⁵) 個だけ存在する。

イーサネット上のホストが IP マルチキャストグループに加わるときは、対応するイーサネットマルチキャストアドレスに宛てられた任意のパケットを受け取るようにイーサネットインターフェースを設定する。残念ながら、こうすると受信ホストは受け取りたいトラフィックの他にも同じイーサネットアドレスに射影される他の 31 個の IP マルチキャストアドレスに宛てられたトラフィックも (同じイーサネットに転送された場合は) 受け取るようになる。このため、受信ホストの IP は全てのマルチキャストパケットの IP ヘッダーを調べ、本当に自身が属するグループに宛てられたものかどうかを確認する必要がある。まとめると、IP とイーサネットでマルチキャストアドレスの長さが食い違っているために関係ないグループに宛てられたマルチキャストのトラフィックがホストに負担をかける場合がある。ただ幸いにも、一部のスイッチドネットワーク (例えばスイッチドイーサネット) ではスイッチが必要ないパケットを認識して破棄する方式でこの問題が軽減される。

さらに込み入った疑問として「そもそも送信側と受信側はどうやって利用すべきマルチキャストアドレスを学習するのか？」がある。これは通常アウトオブバンドの (マルチキャストと関係ない) 手段で行われる。グループアドレスをインターネットに広報する非常に洗練されたツールが存在する。

4.3.2 マルチキャストルーティング (DVMRP, PIM, MSDP)

ルーターのユニキャスト転送テーブルは任意のユニキャストパケットの宛先 IP アドレスに対して転送先のリンクを示す。マルチキャストをサポートするには、ルーターにマルチキャスト転送テーブルを追加する必要がある。この転送テーブルはマルチキャストパケットの宛先 IP アドレスに対して転送先のリンクを示す (転送先のリンクが複数ある可能性もある。そのときパケットはルーターによって複製される)。そのため、ユニキャスト転送テーブルが全体として路の集合を表すのと同様に、マルチキャスト転送テーブルは全体として木の集合を表す: この木をマルチキャスト配送木 (multicast distribution tree) と呼ぶ。さらに、SSM (および ASM の一種) をサポートするには、マルチキャスト転送テーブルはマルチキャストアドレスとユニキャストアドレスの組から転送すべきリンクを示せる必要がある (ここでも木が構築される)。

マルチキャストルーティングはマルチキャスト配送木を決定するプロセス、より正確にはマルチキャスト転送テーブルを構築するプロセスである。ユニキャストルーティングと同様に、このプロセスはマルチキャストルーティングプロトコルを「動作させる」だけでは十分でない: ネットワークが成長したときでも適切にスケールし、異なるルーティングドメインの自律性を受け入れられる必要がある。

DVMRP

ユニキャストで利用される距離ベクトル型ルーティングはマルチキャストをサポートするように拡張できる。このプロトコルは DVMRP (Distance Vector Multicast Routing Protocol) と呼ばれる。DVMRP は広く使われた最初のマルチキャストルーティングプロトコルである。

ユニキャストの距離ベクトル型ルーティングアルゴリズムでは各ルーターが (宛先, コスト, ネクストホップ) のタプルからなるテーブルを管理し、(宛先, コスト) の組を直接接続される隣接ノードと交換するのだった。マルチキャストをサポートするための拡張は二つのプロセスからなる。まず、パケットをインターネットワークの全てのネットワークに転送するブロードキャストの仕組みを作成する。次に、マルチキャストグループに属するホストを持たないネットワークを刈り込むpruneように仕組みを改良する。このような動作をするので、DVMRP はフラッド・アンド・プルーン (flood-and-prune) と呼ばれる種類のプロトコルの一つである。

まずブロードキャストを説明しよう。ユニキャスト用のルーティングテーブルがあると、各ルーターは与えられた宛先への最短路におけるネクストホップが分かる。そのため「送信元が S のマルチキャストパケットを受け取ったルーターは、そのパケットが S への最短路を通じて届いた (S が宛先のときのネクストホップから届いた) ときに限ってパケットを全ての外向きリンク (ただしパケットを受け取ったリンクは除く) に転送する」という戦略を使えば、パケットを S に向かってループさせることなく効率的にパケットのフラッディングを行える。

このアプローチには大きな欠点が二つある。一つ目の欠点として、パケットがインターネットワーク内の本当に全てのネットワークに行き渡る。つまりマルチキャストグループのメンバーを含まない LAN を避ける機構が存在しない。この問題を解決する方法は後述する。二つ目の欠点として、LAN に接続されたルーターのそれぞれにパケットが転送される。これは、転送を行うルーターがパケットを (送られてきたリンクを除く) 全てのリンクに転送するので、フラッディングに利用されるリンクが送信元を根とする最短路木の一部である確証がないためである。

二つ目の欠点を改善するには、LAN に複数のルーターが接続されているときに生成されるブロードキャストパケットの重複を避ける必要がある。これを行う方法の一つとして、送信元ごとに各リンクの親 (parent) を選択しておき、マルチキャストパケットの送信元に対して自身が親となっているリンクに対する転送だけをルーターに行わせるというものがある。送信元への最短路に含まれるルーター (複数ある場合はアドレスが最も小さいルーター) が親となる。ルーターは隣接ノードと交換する距離ベクトルメッセージから各送信元に関して自身が親であるかどうかを学習できる。

この改善を行うには、接続されているリンクと送信元の組ごとに自分が親かどうかを表す 1 ビットの記憶領域が各ルーターに必要となることが分かる。インターネットワークを考える上ではネットワーク間のパケット転送だけを考えるので、送信元はホストではなくネットワークであることに注意する必要がある。以上の仕組みは RPB (Reverse Path Broadcast, 逆方向路ブロードキャスト) あるいは RPF (Reverse Path Forwarding, 逆方向路転送) と呼ばれる。「逆方向」路と呼ばれるのは、転送の判断をするときに送信元への最短路を考えるためである。これに対してユニキャストルーティングでは宛先への最短路が探索される。

ここまでに説明した RPB の仕組みが最短路ブロードキャストを実装する。続いてグループ G に宛てられたマルチキャストパケットを受け取った各ネットワークが G のメンバーであるホストを持たないネットワークを転送先から除外する方法を考えよう。この処理は次の二つのステージを通して行われる。一つ目のステージでは、G のメンバーを持たない葉 (leaf) のネットワークが特定される。ネットワークが葉かどうかは簡単に判定できる ── 上述の「親」ルーターがネットワークに存在しないなら、そのネットワークは葉である。G のメンバーがネットワークに存在するかどうかを判断するために、G のメンバーはネットワークに向かってその事実を定期的に広報する。この広報は先述したリンク状態のマルチキャストと同じように行われる。ルーターはこの情報を受け取ったときに限って、G に宛てられたマルチキャストパケットを自身の LAN に転送する。

二つ目のステージでは、こうして収集された「ここに G のメンバーはいない」という情報を最短路木の葉から根に向かって伝播させる。これを行うために、ルーターが隣接ノードに送信する (宛先, コスト) の組に葉ネットワークが受け取りたいと思っているマルチキャストパケットグループの集合が追加される。この情報がルーターに伝播すれば、各ルーターはそれぞれのリンクに対してどのマルチキャストパケットを転送すべきかを理解できる。

なお、この情報をルーティングの更新メッセージに全て含めるのはコストが非常に高い。そのため実際には、この情報は G に対するマルチキャストパケットが送信されたときにだけ交換される。言い換えれば、DVMRP によるマルチキャストの戦略は「普段は RPB (通常の距離ベクトル型ルーティンアルゴリズムに少量の処理を加えることで実行できる) で送信元ごとの最短路木を構築しておき、何らかのマルチキャストアドレスが送信されたら送信元を根とする最短路木の刈り込みを行う」となる。最短路木の刈り込みでは、宛先のグループに対するパケットを受け取る必要のないルーターが声を上げ、その情報が他のルーターに伝播される。

PIM-SM

PIM (Protocol Independent Multicast) は初期のマルチキャストルーティングアルゴリズムが抱えていたスケーリングの問題を解決するために開発された。特に、既存のプロトコルは特定のグループに宛てられたトラフィックを受け取るルーターの割合が比較的低い状況でスケールしないと認識されていた。例えば、全てのルーターに対するブロードキャストのトラフィックが明示的に停止を求めない限り続くというのは、そもそもトラフィックを受け取ろうと思っていないルーターからすれば優れた設計とは言えない。この状況は十分に一般的だったので、PIM では問題空間が疎モード (sparse mode) と密モード (dense mode) に分割された。ここで「疎」と「密」はマルチキャストを行うルーターの割合が低いか高いかを表す。PIM 密モード (PIM-DM) は DVMRP と同様のフラッド・アンド・プルーンを利用し、同様のスケーラビリティの問題を抱える。PIM 疎モード (PIM-SM) は現在支配的なマルチキャストルーティングプロトコルであり、これから本節で議論する。PIM の「プロトコル独立 (Protocol Independent)」は、PIM が DVMRP といった初期のプロトコルと異なり、特定のユニキャストルーティングに依存しないことを意味する ── これから見るように、PIM は任意のユニキャストルーティングプロトコルで利用できる。

PIM-SM において、ルーターは Join (参加) メッセージと呼ばれる PIM プロトコルのメッセージを使ってマルチキャストの配送木に明示的に参加する。これは「最初に全域木を作り、トラフィックを必要としないルーターを削除する」という DVMRP のアプローチと対照的な点に注目してほしい。ここでの問題は Join メッセージの送信先である。そのマルチキャストグループに対しては (一つとは限らない) 任意のホストがトラフィックを送信できる事実があるので、Join メッセージを誰に送信すべきかは明らかでない。この問題を解決するために、PIM-SM は各グループに RP (rendezvous point, ランデブーポイント) と呼ばれる特別なルーターを割り当てる。一般に、ドメイン内のいくつかのルーターが RP の候補に設定され、PIM-SM にはドメイン内の全てのルーターが特定のグループに対する RP として用いるルーターに合意するための手続きが定義されている。リンクやノードの障害が重なってドメインが分断されたり、RP の候補で障害がおきたりするといった様々なシナリオに対応しなければならないので、この合意形成の手続きは非常に複雑となる。以降の議論では、考えているグループに対する RP のユニキャスト IP アドレスをドメイン内の全てのルーターが知っていると仮定する。

マルチキャスト配送木はトラフィックの配送を望むルーターが Join メッセージを RP に送信することで構築される。PIM-SIM では二種類の木を構築できる: 全てのルーターが利用できる共有木 (shared tree) と、特定のルーターだけが利用できる送信元固定木 (source-specific tree) である。通常の運用では最初に共有木を構築し、必要になるほどのトラフィックがあれば後から送信元固定木を構築する。木を構築すると、その木に含まれるルーターの転送テーブルにエントリーが追加されるので、グループ内の全ての送信元に一つずつではなくグループ全体に対して一つずつの木を構築するのをデフォルトの動作とすることが重要となる。

図 110 に示した例を考えよう。最初ルーター R4 がグループ G に対する Join メッセージを RP に送信したとする。ここでは通常の IP ユニキャスト転送が使われる。最初の Join は「ワイルドカード」であり、RP に到達するまでに通過する全てのルーター (この例では R2) も共有木に加わる。具体的には、Join の送信元および Join を確認した途中のルーターは転送テーブルに (*, G) エントリーと呼ばれる共有木用のエントリーを作成する (* は「全ての送信元」を表す)。経路上のルーター (R2) は (*, G) エントリーを転送テーブルに追加するとき、Join を受け取ったインターフェースを G に対するパケットを転送すべきインターフェースとして記録する。さらに、Join を RP に向けて転送するときに使うべきインターフェースを決定し、そのインターフェースを G 宛てのトラフィックを受け取る唯一のインターフェースとして記録する。その後 Join は RP に転送される。こうして RP は Join を受け取り、木の枝の構築が完了する。図 110 (a) 中の青い実線が構築された共有木を表す。

他のルーターが Join を RP に送信すると、同じ要領で共有木に新しい枝が増える。図 110 (b) では R5 が Join を RP に送信している。なお、R5 が送信した Join は R2 にまで伝われば十分なことに注意してほしい。R2 は転送テーブルの G に対応するエントリーに新しい外向きインターフェースとして R5 と接続するインターフェースを追加することで共有木に枝を増やすだけであり、Join を RP に転送しない。以上のプロセスが最終的に RP を根とする木を構築することも確認してほしい。

この時点で、あるホストがグループ G にマルチキャストパケットを送信したいと思ったとする (図 111)。そのホストは G を表すマルチキャストアドレスを宛先とした IP パケットを作成し、LAN 内の DR (designated router, 代表ルーター) に送信する。DR は R1 だったとしよう。R1 はマルチキャストグループ G に対するエントリーを転送テーブルに持たない。そこで R1 はマルチキャストパケットを単に転送するのではなく、RP までトンネルする。具体的に言うと、R1 はマルチキャストパケットを PIM の Register メッセージに包み、それを IP パケットに入れて RP のユニキャスト IP アドレスに送信する。IP トンネルのエンドポイントと同じように、自身に宛てられたパケットを受け取った RP はペイロードが Register メッセージであることを確認する。Register メッセージの中には G のマルチキャストアドレスに宛てられた IP パケットがあり、RP は何をすべきかを知っている ── RP は自身が根である共有木にパケットを送信する。今の例では、RP は R2 にパケットを送信し、R2 は R4 と R5 にパケットを転送する。

このようにして、 G に宛てられたマルチキャストパケットは最初 RP のユニキャストアドレスを宛先とする追加の IP ヘッダーが付けられて R1 から RP までトンネルされ、それから元のマルチキャストパケットが共有木に沿って R4 および R5 まで配達される。

以上の仕組みを使えば全てのホストが全ての受信先に対してパケットを送信できるので、マルチキャストの問題は解決したと宣言したくなるかもしれない。しかし、R1 から RP に向かうパケットのカプセル化と脱カプセル化には帯域の非効率性と処理コストが存在する。そこで RP は、トンネルを不要にするためにマルチキャストグループ G に関する知識を自身と R1 の間にあるルーターに強制的に与える。つまり図 110 (c) に示すように、RP は Join メッセージを送信元ホストに宛てて送信する。このメッセージが R1 に伝わるまでの間に途中にあるルーター (R3) は G について学習するので、DR はマルチキャストパケットをネイティブに (トンネルを使わずに) 送信できるようになる。

ここで重要な点として、RP がマルチキャストパケットの送信ホストに送信する Join メッセージでは送信元が固定される (以前に R4 と R5 が送信した Join メッセージは全ての送信元に適用されていた)。つまり、R1 に送られる Join メッセージは R1 および途中のルーターに送信元固定 (sender-specific) の状態を作成する。この状態は (S, G) エントリーと呼ばれ、送信元と宛先グループの両方が一致したときに使われる。一方、G に属するルーターと RP に追加される (*, G) エントリーはグループが一致すれば送信元に関係なく使われる。そのため、図 110 (c) では R1 から RP への路からなる送信元固定木 (破線) と共有木 (青い実線) の両方が存在する。

次に可能な最適化として、共有木全体を送信元固定木に置き換えるというものがある。この最適化が望ましいのは、送信元から受信者への RP を経由する路が最短路より格段に長くなる可能性があるためである。この最適化は送信元から高いデータレートが観測されたときなどに有効化される。最初のステップとして、共有木の下流にあるルーター (例えば R4) が送信元固定の メッセージを送信元に宛てて送信する。このメッセージは送信元への最短路を伝って送信され、その間に通ったルーターでは転送テーブルに (S, G) エントリーが作成される。この結果、RP ではなく送信元を根とする送信元固定木が構成される。R4 と R5 が送信元固定木への切り替えを行ったとすれば、図 110 (d) に示す状況となる。このとき送信元固定木に RP が含まれていないことに注目してほしい。なお、図では共有木は省略されているものの、実際には受信を待機するルーターは新しい送信元が現れたときのために共有木に留まる。

PIM が「プロトコル独立」である理由がこれで理解できただろう。木を構築・管理する仕組みはユニキャストルーティングを利用しているだけであり、特定のユニキャストルーティングプロトコルが持つ機能は使っていない。木の形は Join メッセージが伝わる路によって完全に決定され、その路はユニキャストルーティングが選択する最短路である。そのため、PIM は正確に言えば「ユニキャストルーティングプロトコル独立」であり、DVMRP などとは異なる。一方で、PIM はインターネットプロトコルとは非常に強く結びついている ── PIM はネットワーク層プロトコルに関して独立ではない。

PIM-SM の設計がまたしても示すのは、スケーラブルなネットワークを構築する上での課題、そしてスケーラビリティを達成する上でしばしば何らかの最適性が失われるという事実である。共有木を使うとルーターに保存されるエントリーの数が送信元の数とグループの数の積のオーダーではなくグループの数のオーダーとなるので、共有木は送信元固定木よりスケーラビリティに優れる。しかし一方で、送信元固定木は効率的なルーティングと高いリンク帯域利用率を達成する。

ドメイン間マルチキャスト (MSDP)

ドメイン間マルチキャストプロトコルとしての PIM-SM には重大な欠点がいくつかある。特に、各グループに対して RP が存在する仮定はドメインが自律的であるという原則に反する。特定のマルチキャストグループに参加するドメインは RP が位置するドメインに依存することになる。加えて、送信元と受信者が単一のドメインに収まっている場合でも、マルチキャストトラフィックは最初に送信者から RP を持つドメインにルーティングされる必要がある。このため、PIM-SM はドメイン間で使われることは通常なく、ドメイン内でのみ使われる。

PIM-SM を使ってマルチキャストをドメイン間に拡張するために、MSDP (Multicast Source Discovery Protocol) が考案された。MSDP は内部で PIM-SM を実行する複数のドメインを ── 各ドメインの RP を接続することで ── 接続するために利用される。各 RP は他のドメインに属する MSDP ピア (MSDP peer) と呼ばれる RP を一つ以上持つ。MDSP ピア RP の組は TCP で接続され、その接続の上で MSDP プロトコルは実行される。特定のマルチキャストグループの MSDP ピアの集合は全体としてブロードキャストネットワーク用の緩いメッシュとして機能する。MSDP メッセージのブロードキャストは、この RP のメッシュ上で DVMRP を紹介したときに説明した逆方向路ブロードキャストアルゴリズム (RPB) を実行することで行われる。

この RP のメッシュを通じて MSDP がブロードキャストするのはどのような情報だろうか？ グループに属するホストではない: ホストがグループに加わるとき、その情報は伝わる最も遠い地点はホストが属するドメインの RP である。そうではなく、送信元 ── マルチキャストパケットを送信しているホスト ── の情報を MDSP はブロードキャストする。同じドメイン内に新しい送信元が現れると最初に Register メッセージが RP に届くので、RP は自身と同じドメインに属する送信元を知ることができる。各 RP は MSDP を使って Source Active メッセージを自身のピアへ定期的にブロードキャストし、送信元の IP アドレス、宛先のマルチキャストグループアドレス、そして送信元が属するドメインの RP の IP アドレスを伝える。

Source Active メッセージのブロードキャストを受け取った MSDP ピア RP が宛先のマルチキャストグループに属するホストを持つなら、その RP は送信元固定の Join メッセージを自身のドメインを代表して送信元ホストに送信する (図 112 (a))。この Join メッセージによって、その RP まで伸びる送信元固定木の枝が構築される (図 112 (b))。この結果として、MSDP ネットワークに属する RP でマルチキャストグループに属するホストを持つものが全て新しい送信元を根とする送信元固定木に加えられる。送信元からマルチキャストパケットを受け取った他ドメインの RP は、自身の共有木を使ってマルチキャストパケットを宛先マルチキャストグループに属する同じドメイン内の受信を望むホストに転送する。

送信元固定マルチキャスト (PIM-SSM)

PIM のオリジナルのサービスモデルは、初期の様々なマルチキャストプロトコルと同様、多対多のマルチキャストを仮定していた: マルチキャストパケットの受信を望むホストがグループに参加し、グループに対しては任意のホストがパケットを送信できる。しかし 1990 年代の後半には、一対多モデルを用いるマルチキャストの可能性が探られるようになった。カンファレンスの発表をインターネットで中継する場合など、実際のマルチキャストアプリケーションの多くは送信元を一つしか持たないからである。PIM-SM では最初に共有木が構築され、その後に最適化として最短路から構成される送信元固定木が構築されることはこれまでに見た。オリジナルの PIM の設計では、この最適化はホストから見えなかった ── 送信元固定木に参加するのはルーターだけだった。しかし一対多モデルのサービスの必要性が認識されると、PIM-SM が持つ送信元固定木によるルーティング機能をホストからも利用可能にする判断が下された。このために必要となったのは、主に PIM ではなく IPv4 の IGMP と IPv6 の MLD への変更だった。この新しい機能は現在 PIM-SSM (PIM Source-Specific Multicast) と呼ばれている。

PIM-SSM は新しくチャンネルの概念を導入する。チャンネルは送信元アドレス S とグループアドレス G の組み合わせを表す。グループアドレス G は通常の IP マルチキャストアドレスであり、IPv4 と IPv6 はどちらもマルチキャストアドレス空間の一部を SSM を使ったマルチキャストのために割り振っている。PIM-SSM を使うとき、ホストはグループと送信元の両方を指定した IGMP の Membership Report メッセージをローカルのルーターに送信する。これを受けてルーターは PIM-SM 特有の Join メッセージを送信元に向かって送信し、前述した「通常の」PIM-SM と同じ手順で送信元固定木に新しい枝が加わる (共有木の構築は飛ばされる)。こうして構築されるのは送信元固定木なので、指定された送信元だけが木にパケットを送信する。

一対多マルチキャストへの比較的大きな需要が存在したことが主な理由となり、PIM-SSM は大きな利益をもたらした。PIM-SSM が持つ利点の一部を次に示す:

• マルチキャストのトラフィックが受信を望むホストへさらに直接的に届くようになった。

• チャンネルのアドレスは事実上マルチキャストグループアドレスと送信元アドレスからなる。そのため、マルチキャストグループアドレスの特定の範囲を SSM だけに使うと定めておけば、同じドメイン内の送信元と同時に使う限り、複数のドメインが同じマルチキャストグループアドレスを衝突することなく独立して利用できるようになった。

• 指定された送信元だけが SSM グループにトラフィックを送信できるので、偽造されたマルチキャストトラフィックを大量に送り付けてルーターあるいは受信を望むホストに大きな負荷をかける攻撃のリスクが減少した。

• PIM-SSM はドメイン内で利用するのと全く同じようにドメイン間でも利用できる。そのとき MSDP のようなプロトコルに依存することもない。

このため、PIM-SSM はマルチキャストサービスモデルに対する非常に有用な追加と言える。

双方向木 (BIDIR-PIM)

マルチキャストに関する議論の最後に、BIDIR-PIM (Bidirectional PIM, 双方向 PIM) と呼ばれる PIM-SSM と異なる PIM の拡張を紹介する。BIDIR-PIM は PIM-SM の最近登場した変種であり、ドメイン内の多対多マルチキャストに適している。例えば多人数ビデオ会議といったグループの送信元と受信者が同じになる状況で BIDIR-PIM は特に力を発揮する。

PIM-SM と同様に、マルチキャストトラフィックの受信を望むホストは IGMP の Membership Report メッセージを RP に送信することでグループに参加し、RP を根とする共有木がマルチキャストパケットを受信者に転送する。しかし PIM-SM と異なり、BIDIR-PIM では共有木が送信元にも枝を伸ばす。これは共有木が一方向の辺から構成される PIM-SM では意味がないものの、BIDIR-PIM では共有木が双方向の辺から構成される ── そのため、マルチキャストパケットを下流の枝から受け取ったルーターは自分の上流にあるルーターと下流にあるルーターの両方にパケットを転送できる。このため、パケットが任意の受信者に達するまでに経由する経路は共有木の枝を必要なだけしか上らない。例えば、図 113 の R1 が送信したマルチキャストパケットが R2 に届くまでに経由するルーターは R4 だけである。R4 は受け取ったマルチキャストパケットを下流の R2 と上流の R5 の両方に転送するので、その時点で R2 にパケットが到着する。

BIDIR-PIM の驚くべき特徴として、RP が必ずしも必要とならないことがある。必要なのは RP アドレス (RP address) と呼ばれるルーティング可能なアドレスだけで、それが RP のアドレスであることはおろか実在するインターフェースのアドレスであることさえ要求されない。 どうなっているのだろうか？ 受信を望むホストからの Join メッセージは RP アドレスに向かって転送され、RP アドレスが存在するはずのリンクが接続されたインターフェースを持つルーターに到達すると消滅する。例えば図 113 (a) において、R2 が送信した Join メッセージは R5 でストップし、R3 が送信した Join メッセージは R6 でストップする。マルチキャストパケットの上流に向けた転送も同様に RP アドレスに向けて行われ、RP アドレスが存在するはずのリンクが接続されたインターフェースを持つルーターに到着すると終了する。ただしマルチキャストパケットの転送では最後にマルチキャストパケットがそのリンクを通して転送され、そのリンクに接続された他の全てのルーターがパケットを受け取ることが保証される。図 113 (b) に R1 が送信したマルチキャストパケットの流れを示す。

この仕組みがあるので、BIDIR-PIM はドメインをまたいで利用できない。一方で、ドメイン内の多対多マルチキャストでは BIDIR-PIM が PIM-SM より優れる点がいくつかある:

• 各ルーターはマルチキャストパケットを RP アドレスに転送する方法を最初から知っているので、送信元を登録するプロセスが必要ない。

• 頂上の RP まで登らなくても必要な分だけ登った時点で枝分かれできるので、PIM-SM の共有木を使う場合より経路が直接的になる。

• 双方向木は送信元を固定するための情報を持たないので、PIM-SM の送信元固定木よりずっと小さい (一方で、経路は送信元固定木を使うよりも長くなる)。

• RP がボトルネックになることはない。そもそも RP が実在する必要がない。

PIM の変種を見ていくだけでマルチキャストに対する多種多様なアプローチを見つけられる事実から得られる一つの結論は、マルチキャストは最適な解決法を見つけるのが難しい問題空間だということである。タスクを行う上で「ベスト」なマルチキャストモードを選択するには、最適化したい値は何か (リンク帯域の利用率、ルーターの状態数、経路の長さなど)、そしてサポートしたいアプリケーションはどのタイプか (一対多、多対多など) を決める必要がある。