■ ユニキャストとブロードキャスト

ネット君、データの送信として3種類あるのは知っているな？

3種類？ どういう基準の種類分けですか？

む。そう言われれば基準がないと答えづらいな。
宛先の数、ではどうだ？

宛先の数？ となると、ユニとマルチとブロードの3種類のキャストですか？

そうだ。その3種類のキャストだ。

1つの宛先に送るのがユニキャスト。複数の宛先に送るのがマルチキャスト。
でもって、全ホストに送るのがブロードキャストでしたね。

うむうむ。
実際今までの話の中でよく出てきたのは、ユニキャストとブロードキャストだな。

そうですねぇ、普通にデータ転送といえばユニキャストを指すことが多いですし。
あとはRIPとかDHCPとかARPとかでブロードキャストですよね。

そうだな。で、ここからが今回の話のメインになっていくわけだが。
マルチキャスト、なんていうものが何故存在しているか、という話だ。

ん？ マルチキャストってあっちゃいけないんですか？

そういうわけではないが、「複数」ではなく「全ホスト」に送ったっていいわけだし。
「複数」ではなく「単一」へ「複数」送ったっていいわけだろう？

んんん？ そう言われれば、そうかな？

では、そのように考えてみる。
ユニキャストを使って、マルチメディアアプリケーションのデータを送りつけることを考えてみよう。

まるちめでぃああぷりけーしょん？ 例えばどんなのです？

メディアコンテンツのストリーミングとか、そうだな、ビデオ会議が一番いい例かな。
大きめのデータを、ビデオ会議に参加しているホストにだけ送るのだ。

こうなりますよね。

そうだ、だが最大の問題は、使用する帯域幅だ。

使用する帯域……、最大でサーバ・ルータ間の4Mbpsですか？

それは、この例が4台しか参加ホストがいないからだ。
もし、100台いたらどうなる？

100台だと、1Mbsp × 100で、100Mbps。ファストイーサの理論最大値ですね。

逆に、転送データがもっと大きかった場合は？
このように、ユニキャストでの複数転送は消費帯域が大量に必要となるわけだ。

確かに。2Mビットのデータを100台になんていったら、ファストイーサじゃ運べませんね。

そうだろう？ さらに、ルータやスイッチのパケット転送量の問題も発生してくる。
とてもじゃないが、マルチメディアアプリケーションのような大サイズのデータを複数宛には送れない。

ん〜と、じゃあ。ブロードキャストなら？

ブロードキャストだとこうなる。

参加していないホストまで処理しなければならない…。

そうなる。ブロードキャストは全ホストが無条件で受け取り、レイヤ4までデータを渡さなければいけない。処理が大きすぎるのだよ。

でも、DHCP DISCOVERとかもそうじゃないですか？

データのサイズが違いすぎる。DHCP DISCOVERは1〜2Kビット程度だ。
それにくらべ、このようなマルチキャストアプリケーションは500K〜数Mになることもある。

う、う〜ん。

というわけで、このような問題を解決するソリューションがマルチキャストなわけだ。

お〜。

これがマルチキャストを使う利点なわけだ。
わかってもらえたかね、ネット君。

え〜、そりゃバッチリ。

■ IPアドレッシング

さてさて、このマルチキャストだが。レイヤ4ではUDPを使用し、IPマルチキャストアドレスをアドレスとして使う。

クラスDですね。

そうだな。
そして、マルチキャストのデータを受け取りたいホストは、マルチキャストグループに参加する。

ははぁ、グループ。

このグループに対応したIPマルチキャストアドレス宛に送信されたパケットは、そのグループに参加したホストが受け取る。そういう形になるわけだ。

ブロードキャストみたいに、「複数宛」の1つのアドレスを宛先として送るんですね。

そうなる。ブロードキャストは「全員宛」の1つのアドレスを宛先として送るわけだからな。
このアドレスは、先ほどネット君が言ったとおり、クラスDなわけだが。

クラスD、224.0.0.0〜239.255.255.255ですね。

クラスDは、階層化されていない、クラスA〜Cとは全く異なるアドレスだ。
まず、以下の2つの範囲は一般には使用できない。

224の最初と、239全部がダメ、と。
管理用と管理スコープ用ってどう違うんです？

管理スコープについては、RFC2365参照のこと、だな。 ▼ link

……逃げましたね。

……、さて、さらに、224.0.0.0〜224.0.0.255では、Well-Knowなアドレスがある。
一部を抜粋しよう。

あ〜、なんか見覚えあるのと、見覚えない名前が……。
って、博士。ごまかされませんよ？

ちっ。しぶとい。
……そうだ、ネット君。君がRFC2365を読んだ上での質問なら受け付けようじゃないか。

う、うぅぅぅぅ。姑息な手を……。

■ MACアドレッシング

さて、アドレスといえば、もう1つ必要なアドレスがあるな、ネット君。

MACアドレスですか？

そうだ。IPアドレスはクラスD、マルチキャストアドレスを使う。
もちろん、これに対応するMACアドレスがないとイーサ上では送れない。さてどうする？

どうするって言われても……、ARP？

ARPではダメだな。ARPを使ってマルチキャストグループのホストのMACアドレスを取得し、それを使うということは、結局、宛先MACアドレスが別のフレームをホスト分作成することになるからな。

う〜〜〜ん。

ブロードキャストの場合はどうする？

ブロードキャストの場合は、ffff.ffff.ffff.ffffの固定値ですよ。

そうだ、それと同じようにマルチキャストグループに対応したMACアドレスを宛先として使用する。
マルチキャストグループのホストは、対応したMACアドレス宛のフレームを受け取る形になる。

グループに対応したMACアドレス……。

うむ。先頭が0100.5eで始まるアドレスだ。
IPマルチキャストアドレスと対応をこのようにつける。

は〜、固定値の0100.5eの後ろに、0とIPアドレスの後半23ビットをつけるんですか〜。

そうなる。

ん。んん〜、っと。でも、博士？ クラスDだから最初の4ビット（1110）はともかくとして、上に残った部分はどうなるんです？

この5ビットの部分って、使われていないから、もし0000 0じゃなくて、0000 1でも同じ値になってしまいません？

ほら、同じ0100.5e64.0a01ですよ？

む、むむむむ。すごい、すごいぞネット君!!

へ？

あのネット君がっ!! あのネット君が、これほどの理解力を示すとはっ!!
天上のネットワークの神もご照覧あれっ!! ネット君が……、なんて奇跡だっ!!

なんか、とても褒められているとは思えないんですけど？

うむ、褒めてない。

ですよね。はぁ。

ともかく、ネット君の言う通りだ。マルチキャストの場合、IPアドレスとMACアドレスはユニークな対応にはならない。
0100.5e64.0a01は、[224〜239].[100 or 228].10.1の32個のアドレスとの対応になる。

それっていいんですか？
っていうか、なんでこんな作りなんですかね？

さて？

あれ？

それは私に聞かれてもな。0100.5eという特別なベンダコードがあって、その中から半分（先頭が0）をマルチキャスト用に割り当てたってことなんじゃないかな？ で、残った23ビットとIPアドレスをくっつけた、と。

そうなんですか？

いや、どうだろう？ ともかく、同じMACアドレスでも、マルチキャストIPアドレスや、UDPポートが異なるから、識別は可能、ということになるわけだ。

まぁ、そうですけれど。

さて、今回はこれぐらいにしておこう。
しばらくはマルチキャストの話をするぞ。

はい。

というわけで、また次回。

いぇっさ〜。
30分間ネットワーキングでした〜♪