IGMPその4

IGMPv2によるマルチキャストグループの管理

IGMPv1と同様にIGMPv2は、マルチキャストグループの管理を行います。マルチキャストグループの管理とは、

• マルチキャストグループへの加入
• マルチキャストグループの維持
• マルチキャストグループからの脱退

です。

それぞれについて、v1と異なる点がありますが、特に「マルチキャストグループからの脱退」は、大きく違っています。v1では、ホストが黙って脱退していたため、不要なマルチキャストトラフィックが流れてしまう時間がありましたが、v2ではその点が改善されています。

では、順番に見ていきましょう。

IGMPv2によるマルチキャストグループへの加入

マルチキャストグループへの加入は、IGMPv1と同じです。マルチキャストグループに入るためには、ホストはマルチキャストメンバーシップレポート(IGMP Join)を送信します。

IGMP JoinメッセージのIPヘッダの送信先IPアドレスは加入したいグループアドレスを指定します。IGMPが有効になっているルータは、この加入メッセージを受け取ると、受け取ったインタフェースの先にマルチキャストグループのメンバーがいるということがわかるようになり、該当のマルチキャストグループへのパケットを転送するようになります。そして、このときレポートしてきたホストを記録します。レポートしてきたホストを記録する理由は、マルチキャストグループからの脱退を効率よく行うためです。

IGMP Joinメッセージによって、「マルチキャストグループに入りたいんです！」ということをルータに知らせているわけですね。

たとえば、あるコンピュータAが224.10.10.10のグループに加入したいときは、次の図のようになります。

※図をクリックすると拡大します

IGMPv2によるマルチキャストグループの維持

マルチキャストグループの維持は、IGMPv1と同じくルータが定期的にクエリーを送信することによって行います。

※図をクリックすると拡大します

クエリーを受けたマルチキャストグループのメンバーは、返事を返します。返事を返すのもv1と同じく、ひとりだけでいいです。ひとりでもメンバーがいればマルチキャストを送る必要があるからですね。
ただ、v1では返事を返すメンバーを決めるタイマーの値の最大値が10秒で決まっていましたが、v2ではこのタイマーの値を設定で決めることができるようになっています。

※図をクリックすると拡大します

また、IGMPv2では「クエリア」という概念も導入されています。クエリアとは、同じネットワークに複数のルータがいる場合に、クエリを送信するルータを指しています。複数のルータがクエリを送信しても意味がないので、ネットワークを代表して、１台のルータだけがクエリを送信するように決めています。IGMPv1にはクエリアの概念はなく、PIM(Protocol Independent Multicast)によって、クエリを送信するルータを決定しています。

クエリアの選定基準は、ネットワークに接続されているインタフェースのIPアドレスがもっとも小さいルータがクエリアとなります。

IGMPv2によるマルチキャストグループからの脱退

IGMPv1とIGMPv2で大きく違うのが、マルチキャストグループからの脱退です。v1では、マルチキャストのメンバーは黙ってグループから抜けていって、ルータはクエリーの返事がなくなることによって、グループがいなくなったことを判断していました。

v2では、マルチキャストのメンバーは脱退するときにルータに知らせます。脱退時に出すメッセージが「リーブグループ」というメッセージです。

IGMPv2は、このリーブグループメッセージとルータがラストレポータを記録していること、それとグループスペシフィッククエリーによって、マルチキャストグループからの脱退を効率よく行い、無駄なマルチキャストパケットをネットワーク上に送らないようにしています。

順を追って、IGMPv2のグループからの脱退の様子をみていきましょう。

まず、以下の図のようにA、B、Cがマルチキャストグループ224.10.10.10のメンバーでラストレポータがAとします。

そして、Aが224.10.10.10のグループから脱退したいとき、リーブグループメッセージを送信します。
リーブグループメッセージのあて先IPアドレスは、脱退したいグループに対するマルチキャストとなっています。そして、送信元IPアドレスにはもちろんAのIPアドレスが入っています。

※図をクリックすると拡大します

リーブメッセージを受け取ると、ルータはそのリーブメッセージの送信元がラストレポータと同じかどうかでこのあとの処理が違ってきます。つまり、以下の2つの場合でわかれてきます。

• リーブメッセージの送信元≠ラストレポータ
• リーブメッセージの送信元＝ラストレポータ

リーブメッセージの送信元≠ラストレポータのときは、まだ、マルチキャストグループのメンバー(ラストレポータ)がいるはずなので、そのままマルチキャストパケットを転送しなくてはいけません。

リーブメッセージの送信元＝ラストレポータのときは、もしかすると、もうマルチキャストグループのメンバーがいなくなったかもしれないので、まだマルチキャストパケットを転送する必要があるかどうかを決めなければいけません。そのために、リーブメッセージのマルチキャストグループあてのグループスペシフィッククエリーを送信します。グループスペシフィッククエリーは、特定のグループのメンバーに対するクエリーです。
グループスペシフィッククエリーに対するレポートメッセージ(返事)が返ってこなければ、もうメンバーがひとりもいないということになるので、マルチキャストパケットを転送しなくなります。

例でいうと、Aは224.10.10.10のラストレポータです。すると、ルータは、224.10.10.10のメンバーがもういないかもしれないと思い、「224.10.10.10のメンバーの人、他にいますか～？」と聞くために、グループスペシフィッククエリーを送信するのです。

まだ、BとCがいるので、BかCのどちらかが返事(メンバーシップレポート)を返します。例として、Bが返したときの様子が次の図です。

で、Bが脱退するときも同じようにリーブグループメッセージを出し、ルータは、ラストレポータからのリーブグループなので、グループスペシフィッククエリーを送信すると、最後のメンバーのCが応答します。

そして、Cも脱退しました。ルータは、グループスペシフィッククエリーを送信しても返事が返ってこないことから、もうグループのメンバーがいないので、マルチキャストパケットの転送を止めます。

v1では、ジェネラルクエリーに対する返事が何回か返ってこなければ、グループがいないと判断していました。その間、無駄なマルチキャストパケットを流していることになるのですが、v2ではその点が改善されていることがわかります。