マルチキャストの概要

マルチキャストとユニキャストの比較

Junos®オペレーティングシステム(Junos OS)ルーティングプロトコルプロセスは、多種多様なルーティングプロトコルをサポートしています。これらのルーティングプロトコルは、クライアントとサーバーの1ペア間に送信される ユニキャスト トラフィックストリームだけでなく、単一のサーバーソースと多数のクライアント受信者間のビデオ、オーディオ、またはその両方を含む マルチキャスト トラフィックストリームについても、ルーティングデバイス間でネットワーク情報を伝送します。マルチキャストに使用されるルーティングプロトコルは、多くの重要な点でユニキャストルーティングプロトコルとは異なります。

情報は、ユニキャスト、ブロードキャスト、マルチキャストの 3 つの基本的な方法でネットワーク経由で配信されます。

ユニキャスト、ブロードキャスト、マルチキャストの違いは、次のように要約できます。

• ユニキャスト:1つの送信元から1つの宛先への1対1。

• ブロードキャスト:1つの送信元からすべての可能な宛先まで、1対オール。

• マルチキャスト:1つの送信元から複数の宛先への1対多で、トラフィックの受信に関心を表明します。

  注:

  このリストには、オンライン ゲームやビデオ会議など、同じ受信機に多くのソースがあり、受信機がソースを兼ねていることが多い多対多アプリケーションの特別なカテゴリは含まれていません。多対多は、1 対多のマルチキャストを繰り返し採用するサービス モデルであるため、固有のプロトコルは必要ありません。元のマルチキャスト仕様であるRFC 1112は、ASM(エニーソースマルチキャスト)多対多モデルとSSM(ソース固有マルチキャスト)1対多モデルの両方をサポートしています。

ユニキャストトラフィックでは、ネットワークを移動するIPパケットの多くのストリームが、Webサイトサーバーなどの単一の送信元からクライアントPCなどの単一の宛先に流れます。ユニキャストトラフィックは、今でもネットワーク上での最も一般的な情報転送形式です。

ブロードキャストトラフィックは、単一の送信元から、ネットワーク上で到達可能なすべての宛先(通常はLAN)に流れます。ブロードキャストは、トラフィックが確実に宛先に届くようにする最も簡単な方法です。

テレビネットワークは、ブロードキャストを使用してビデオとオーディオを配信します。テレビネットワークがケーブルテレビ(CATV)システムであっても、ソース信号はすべての宛先に到達するため、一部のチャンネルのコンテンツがスクランブルされる主な理由です。インターネット上では、膨大な量の不要な情報が絶えずエンドユーザーのデバイスに届き、スクランブルの複雑さと影響、および関連するプライバシーの問題のために、インターネット上でブロードキャストは実現できません。

マルチキャストトラフィックは、ユニキャスト(1つの送信元、1つの宛先)とブロードキャスト(1つの送信元、すべての宛先)の両極の間にあります。マルチキャストは、「1つの送信元、多数の宛先」のトラフィック配信方式であり、特定の送信元から情報を受信する必要性を明示的に示している宛先のみがトラフィックストリームを受信することを意味します。

IP ネットワークでは、宛先(クライアント)が送信元(サーバー)と直接通信することはあまりないため、トラフィックが無計画にルーティングされることを避けるために、送信元と宛先の間のルーティング デバイスは、ユニキャストまたはマルチキャストの観点からネットワークのトポロジーを決定できなければなりません。マルチキャスト ルーティング デバイスは、1 つの入力インターフェイスで受信したパケットを複製し、複数の出力インターフェイスにコピーを送信します。

IPマルチキャストでは、送信元と宛先はほとんどの場合ホストであり、ルーティングデバイスではありません。マルチキャスト ルーティング デバイスは、送信元から宛先までネットワーク全体にマルチキャスト トラフィックを分散します。マルチキャスト ルーティング デバイスは、ネットワーク上のマルチキャスト ソースを見つけ、複数のインターフェイスでパケットのコピーを送信し、ルーティング ループを防ぎ、関心のある宛先を適切なソースに接続し、不要なパケットのフローを最小限に抑える必要があります。標準のマルチキャスト ルーティング プロトコルは、これらの機能のほとんどを提供しますが、一部のルーター アーキテクチャではパケットの複数のコピーを送信できないため、マルチキャストを直接サポートしていません。

IPマルチキャストの用途

マルチキャストにより、IPネットワークは、インターネットの初期段階で普及していたデータ配信のユニキャストモデル以上のものをサポートできます。マルチキャストは、もともと1989年のRFC 1112でホスト拡張として定義されており、1対多または多対多として特徴付けることができるトラフィックフローを配信するための効率的な方法を提供します。

ユニキャストトラフィックは、データアプリケーションに厳密に限定されるわけではありません。無線かどうかにかかわらず、電話での会話にはデジタルオーディオサンプルが含まれ、デジタル写真やビデオが含まれている場合もありますが、それでも1つのソースから1つの宛先に流れることがあります。同様に、マルチキャストトラフィックはマルチメディアアプリケーションに厳密に限定されません。一部のデータアプリケーションでは、多くのPCに配信されるニュースや株価ティッカーサービスのように、トラフィックのフローは単一の送信元からパケットを必要とする多くの宛先に行われます。このため、マルチキャスト宛先ではリスナーよりも受信者という用語が優先されますが、両方の用語が共通です。

ユニキャストでも機能できるが、マルチキャストに適したネットワークアプリケーションには、コラボレーショングループウェア、テレビ会議、定期的または「プッシュ」データ配信(株価、スポーツスコア、雑誌、新聞、広告)、サーバーまたはWebサイトのレプリケーション、戦争シミュレーションや仮想現実などの分散型インタラクティブシミュレーション(DIS)が含まれます。複数の受信機を備えた1対多または多対多のデータまたはマルチメディアアプリケーションのネットワークリソースのオーバーヘッドを削減するIPネットワークは、マルチキャストのメリットを享受できます。

ユニキャストがラジオやニュースティッカーサービスで採用されている場合、各ラジオまたはPCは、PCで各リスナーまたは視聴者に対して個別のトラフィックセッションを持つ必要があります(これは実際には一部のWebベースのサービスではこの方法です)。サーバーが消費する処理負荷と帯域幅は、サーバーに「同調」する人が増えるにつれて直線的に増加します。これは、インターネットの世界規模に対処する場合、非常に非効率的です。ユニキャストは、パケットの重複の負担をサーバーに負わせ、ユーザー数が増えるにつれてバックボーン帯域幅をますます消費します。

代わりにブロードキャストを採用した場合、送信元はブブロードキャスト宛先アドレスを使用して単一のIPパケットストリームを生成できます。ブロードキャストはサーバーのパケット重複の問題を解消しますが、IPブロードキャストは単一のサブネットワークにしか送信できず、IPルーティングデバイスは通常、別のインターフェイスでIPサブネットワークを分離するため、これはIPには適したソリューションではありません。たとえIPパケットストリームが文字通りどこにでも送信できるようにアドレス指定でき、どのソースにも「チューニング」する必要がまったくなかったとしても、帯域幅に負担がかかり、関心のないホストが大量のパケットを破棄する必要があるため、ブロードキャストは非常に非効率的です。ブロードキャストは、各ホストにパケット拒否の負担を負わせ、バックボーン帯域幅を最大限消費します。

ラジオ局やニュースティッカーのトラフィックの場合、マルチキャストは最も効率的で効果的な結果を提供します。他の方法の欠点はなく、利点もすべてあります。マルチキャストパケットの単一送信元が、 関心のある すべての受信者に到達します。ブロードキャストと同様に、送信側ホストはIPパケットのストリームを1つだけ生成するため、受信者が1つでも100万個でも負荷は一定に保たれます。ネットワーク ルーティング デバイスはパケットを複製し、適切な受信者にパケットを配信しますが、ルーティング デバイスの新しいロールはレプリケーション ロールだけです。まったく関心のない受信者で構成されるサブネットにつながるリンクは、マルチキャストトラフィックを伝送しません。マルチキャストにより、送信者、ネットワーク、受信者の負担を最小限に抑えます。

IPマルチキャストの用語

マルチキャストには、IPマルチキャストルーティングデバイスおよびネットワークに適用される独自の用語と頭字語があります。 図1 は、IPマルチキャストネットワークで一般的に使用される用語の一部を示しています。

マルチキャストネットワークでは、重要なコンポーネントは ルーティングデバイスであり、パケットを複製できるため、マルチキャスト対応です。その基になっているユニキャストネットワークとまったく同じトポロジーを持つIPマルチキャストネットワークのルーティングデバイスは、 マルチキャストルーティングプロトコル を使用して、受信者(リスナーのマルチメディアへの影響よりも優先されますが、リスナーも使用されます)をソースに接続する 配信ツリー を構築し ます。マルチキャスト用語では、ディストリビューションツリーは ソースをルートにしています (ディストリビューションツリーのルートがソースです)。送信元に向かうルーティングデバイスのインターフェイスは アップストリーム インターフェイスですが、 受信 または 受信 インターフェイスという精度の低い用語も使用されます。帯域幅の使用を最小限に抑えるには、ルーティングデバイス上のアップストリームインターフェイスを1つだけがマルチキャストパケットを受信するのが最適です。受信側に向かうルーティングデバイスのインターフェイスは ダウンストリーム インターフェイスですが、 発信 または 発信 インターフェイスという精度の低い用語も使用されます。ルーティングデバイスには0〜 N〜1のダウンストリームインターフェイスが存在する可能性があり、 N はルーティングデバイス上の論理インターフェイスの数です。ループを防ぐために、アップストリームのインターフェイスは、ダウンストリームのマルチキャストパケットのコピーを受信してはなりません。

図1:IPネットワークのマルチキャスト用語

ルーティングループは、パケットが繰り返し複製されるリスクがあるため、マルチキャストネットワークでは悲惨な問題となります。最新のマルチキャストルーティングプロトコルの複雑さの1つは、ユニキャストルーティングプロトコルよりもはるかに厳密に、パケットごとのルーティングループを回避する必要があることです。

ループ防止のためのリバースパスフォワーディング

ルーティングデバイスのマルチキャスト転送状態は、レシーバーからディストリビューションツリーのルートに戻るリバースパスに基づいて、より論理的に実行されます。RPF では、受信したすべてのマルチキャスト パケットは、インターフェイス上で複製または転送する前に RPF チェックに合格する必要があります。

ルーターがインターフェイス上でマルチキャストパケットを受信すると、ルーターは source アドレスを検証します。次に、ルーターは、同じアドレスをユニキャストルート経由で送信元に戻るための destination アドレスとして使用できるかどうかを確認します。ユニキャスト ルーティングテーブルで見つかった発信インターフェイスが、マルチキャスト パケットを受信したのと同じインターフェイスである場合、パケットは RPF チェックに合格します。

RPF チェックに失敗したマルチキャスト パケットは、受信インターフェイスが送信元に戻る最短パスではないため、破棄されます。ルーティング デバイスは、RPF の目的で個別のテーブルを構築して維持できます。

ループ防止のための最短パス ツリー

マルチキャストに使用されるディストリビューションツリーは、ソースをルートとする最短パスツリー(SPT)ですが、ソースがネットワークの周辺にある場合、このパスが長くなることがあります。ディストリビューションツリーがネットワーク内のより中央にマルチキャストソースを見つける際に、バックボーンに shared tree を提供します。コアネットワークをルーツとする共有ディストリビューションツリーは、スパースモードマルチキャストプロトコルの機能であるランデブーポイント(RP)として動作するマルチキャストルーティングデバイスによって作成および維持されます。

ループ防止のための管理スコーピング

スコープは、マルチキャストパケットを転送できるルーティングデバイスとインターフェイスを制限します。マルチキャストスコーピングは、RFC 2365、Administratively Scoped IP Multicastで説明されているように、アドレスマルチキャストの範囲がスコーピング目的で予約されるという意味でadministrativeされています。境界のルーティング デバイスは、マルチキャスト パケットをフィルタリングし、パケットが設定された制限を超えて逸脱しないようにする必要があります。

マルチキャストリーフとブランチの用語

少なくとも1つの関心のある受信者を持つルーティングデバイス上のホストを持つ各サブネットワークは、ディストリビューションツリー上の リーフ です。ルーティングデバイスは、異なるインターフェイスに複数のリーフを持つことができ、IPマルチキャストパケットのコピーをリーフのある各インターフェイスで送信する必要があります。新しいリーフサブネットワークがツリーに追加されると(つまり、以前はマルチキャストパケットのコピーを受け取っていなかったホストサブネットワークへのインターフェイス)、新しい ブランチ が構築され、リーフがツリーに結合され、レプリケートされたパケットがインターフェイス上で送信されます。特定のインターフェイスのリーフ数は、ルーティングデバイスに影響を与えません。アクションは1葉でも100葉でも同じです。

IPサブネットワークにつながるルーティングデバイスインターフェイス上に関心のあるホストがないため、ブランチにリーフが含まれていない場合、ブランチは配信ツリーから 除外 され、そのインターフェイスからマルチキャストパケットは送信されません。パケットは、ルーティングデバイスでディストリビューションツリーが分岐する場所でのみ、複数のインターフェースに複製および送信され、パケットの重複したフローを伝送するリンクはありません。

通常、同じマルチキャストソースから同じIPパケットのストリームを受信するホストの集合を グループと呼びます。IPマルチキャストネットワークでは、IPマルチキャストアドレスまたは グループアドレスに基づいて、トラフィックがマルチキャストグループに配信されます。グループはリーフの場所を決定し、リーフはマルチキャストネットワーク上のブランチを決定します。

IPマルチキャストアドレッシング

マルチキャストは、クラスD IPアドレス範囲(224.0.0.0〜239.255.255.255)を使用します。クラスDアドレスは、クラスフルアドレスの概念全体が古くなっているため、一般に マルチキャストアドレス と呼ばれます。マルチキャストアドレスは、IPパケットの送信元アドレスとして表示することは決してなく、パケットの宛先にのみなります。

マルチキャストアドレスのプレフィックス長は通常/32ですが、他のプレフィックス長も使用できます。マルチキャストアドレスは、デバイスの物理的なコレクションではなく、受信者の論理グループを表します。マルチキャストアドレスのブロックは、従来の表記法ではプレフィックス長で記述できますが、あくまでも便宜上です。例えば、232.0.0.0から232.255.255.255までのマルチキャストアドレス範囲は、232.0.0.0/8または232/8と記述できます。

インターネットサービスプロバイダ(ISP)は、通常、マルチキャストアドレスが物理デバイスではなくコンテンツに関連するため、顧客にマルチキャストアドレスを割り当てません。受信者には独自のマルチキャストアドレスは割り当てられませんが、コンテンツのマルチキャストアドレスを知っている必要があります。ソースにマルチキャストアドレスを割り当てる必要があるのは、コンテンツを作成するためだけであって、ネットワーク内でのソースの場所を特定するためではありません。すべての送信元と受信者は、依然として通常のユニキャストIPアドレスを必要とします。

マルチキャストアドレッシングは受信者を参照することがほとんどであり、マルチキャストコンテンツのソースは通常、コンテンツを生成するマルチキャストグループのメンバーでもありません。送信元が生成するパケットを監視する必要がある場合、監視はローカルで行うことができ、パケットをネットワークを通過させる必要はありません。

多くのアプリケーションには、独自の使用のためにさまざまなマルチキャストアドレスが割り当てられています。これらのアプリケーションは、そのアプリケーションによって作成されたセッションにマルチキャストアドレスを割り当てます。通常、マルチキャストアドレスを静的に割り当てる必要はありませんが、割り当てることは可能です。

マルチキャストアドレス

マルチキャストホストグループのアドレスは、上位4ビットが1110のIPアドレスとして定義され、アドレスの範囲は224.0.0.0から239.255.255.255、または単に224.0.0.0/4です。(これらのアドレスは、クラスDアドレスとも呼ばれます。)

IANA(IANA)は、登録済みの IPマルチキャスト グループのリストを管理しています。ベース アドレス 224.0.0.0 は予約済みであり、どのグループにも割り当てることができません。224.0.0.1から224.0.0.255までのマルチキャストアドレスのブロックは、ローカルワイヤー用に予約されています。この範囲のグループは、ルーティングプロトコルやローカルディスカバリーメカニズムなど、さまざまな用途に割り当てられます。

239.0.0.0〜239.255.255.255の範囲は、管理者スコープのアドレス用に予約されています。管理スコープのマルチキャストアドレス宛てのパケットは設定された管理境界を越えず、管理スコープのマルチキャストアドレスはローカルに割り当てられるため、これらのアドレスは管理境界を越えて一意である必要はありません。

レイヤー 2 フレームと IPv4 マルチキャスト アドレス

LAN でのマルチキャストは、レイヤー 2 でのマルチキャストの調査を開始するのに適した場所です。レイヤー2 では、マルチキャストはIPv4またはIPv6のパケットとアドレスではなく、MAC(メディアアクセス制御)のフレームとアドレスを処理します。ルーティングデバイスのない単一のLANで、マルチキャストソースが特定のグループに送信しているとします。残りのホストは、マルチキャストグループのコンテンツに関心のある受信者です。そのため、マルチキャスト送信元ホストは、送信元としてユニキャストIPアドレス、宛先としてマルチキャストグループアドレスを持つパケットを生成します。

このパケットを含むフレームで使用されているMACアドレスはどれですか?パケット送信元アドレス(マルチキャストコンテンツを発信するホストのユニキャストIPアドレス)は、送信元のMACアドレスに簡単かつ直接変換されます。では、パケットの宛先アドレスはどうでしょうか?これは、IPマルチキャストグループのアドレスです。フレームのどの宛先 MACアドレスがパケットのマルチキャスト グループ アドレスに対応していますか?

1 つのオプションは、LAN が単純に LAN ブロードキャスト MACアドレスを使用することです。これにより、フレームが LAN 上のすべてのステーションで処理されることが保証されます。しかし、この手順は、関心のあるホストへのパケットとフレームの循環を制限するというマルチキャストの目的全体を無効にします。また、ホストが多くのマルチキャスト グループにアクセスできる場合があり、これにより関心のない宛先へのトラフィック量が倍増します。マルチキャスト グループをサポートするために LAN レベルでフレームをブロードキャストするのは意味がありません。

ただし、レイヤー2 フレームをマルチキャスト目的で効果的に使用する簡単な方法があります。MACアドレスには、ユニキャストの場合は0に設定され(LAN用語は 個々のアドレス)、マルチキャストアドレスであることを示すために1に設定されているビットがあります。これらのアドレスの一部は、特定のベンダーまたはMACレベルプロトコルのマルチキャストグループ用に予約されています。インターネットマルチキャストアプリケーションは、0x01-00-5E-00-00-00から0x01-00-5E-FF-FF-FFの範囲を使用します。マルチキャストレシーバー(TCP/IPを実行しているホスト)は、アプリケーションがマルチキャストグループに参加するときに、これらのアドレスのいずれかを持つフレームをリッスンします。アプリケーションが終了するか、ホストがパケット層(レイヤー3 )でグループを離れると、ホストはリスニングを停止します。

つまり、3バイト(24ビット)を使用して、レイヤー3 のIPv4マルチキャストアドレスをレイヤー2 のMACマルチキャストアドレスにマッピングできます。ただし、マルチキャストアドレスを含むすべてのIPv4アドレスの長さは32ビットで、8つのIPアドレスビットが残っています。IPv4 マルチキャスト アドレスを MAC マルチキャスト アドレスにマッピングするどの方法が「コリジョン」(つまり、パケット層の 2 つの異なる IPマルチキャスト グループがフレーム層の同じ MAC マルチキャストアドレスにマッピングされる)の可能性を最小限に抑えるか?

まず、すべてのIPv4マルチキャストアドレスは同じ4ビット(1110)で始まるため、実際には8ビットではなく4ビットしかないことを認識することが重要です。サブネットマスクによっては、IPv4アドレスの最後のビットがホストビットであることがほぼ保証されるため、LANはドロップしてはなりません。しかし、上位ビット、つまり左端のアドレス ビットは、ほとんどの場合ネットワーク ビットであり、(今のところ) LAN は 1 つだけです。

残りの 24 個の MACアドレス ビットのうち、もう 1 ビットが予約されているため(最初の 0 はインターネット マルチキャストアドレスを示す)、IPv4 アドレスの最初の 1110 に続く 5 ビットは削除されます。残りの 23 ビットは、MACアドレスの最後の 23 ビットに 1 対 1 でマッピングされます。このプロセスの例を 図2に示します。

図2:MACアドレスからマルチキャストアドレスへの変換

このプロセスは、同じMACマルチキャストアドレスにマッピングできるIPv4マルチキャストアドレスが32(2、⁵)あることを意味します。例えば、IPv4アドレス 224.8.7.6 と 229.136.7.6 マルチキャスト同じMACアドレス(0x01-00-5E-08-07-06)に変換されます。これは非常に懸念される点であり、ホストはこれらのマルチキャスト グループの両方に送信されたフレームに関心を持つ可能性があるため、IP ソフトウェアはどちらか一方を拒否する必要があります。

マルチキャストグループの MACアドレスが決定されると、ホストのオペレーティングシステムは、基本的にLANインターフェイスカードにマルチキャストグループへの参加または退出を命じます。マルチキャストグループに参加すると、ホストはマルチキャストアドレスとホストのユニキャストアドレスに送信されたフレームを受け入れ、他のマルチキャストグループのフレームを無視します。もちろん、ホストが複数のグループに参加して、同時にマルチキャストコンテンツを受信することは可能です。

マルチキャストインターフェイスリスト

マルチキャスト ルーティング ループを回避するために、すべてのマルチキャスト ルーティング デバイスは、最短パスでそのマルチキャスト グループ コンテンツのソースにつながるインターフェイスを常に認識する必要があります。これはアップストリーム(受信)インターフェイスであり、パケットがマルチキャスト ソースに転送されることはありません。その他のすべてのインターフェイスは、ディストリビューションツリー上のブランチ数に応じて、潜在的なダウンストリーム(発信)インターフェイスです。

ルーティング デバイスは、 マルチキャスト転送状態を決定するプロセスで、着信および発信インターフェイスの状態を注意深く監視します。特定のマルチキャストグループに対してマルチキャスト転送状態を持つルーティングデバイスは、基本的にそのグループのコンテンツに対して「オン」になっています。ルーティングデバイスの発信インターフェイスリスト上のインターフェイスは、そのグループの着信インターフェイスリストで受信したグループのパケットのコピーを送信します。受信インターフェイスと発信インターフェイスのリストは、マルチキャストグループによって異なる場合があります。

ルーティングデバイスにおけるマルチキャスト転送状態は、通常、(S,G) または (*,G) のいずれかの表記で記述されます。これらはそれぞれ「ess comma gee」と「star comma gee」と発音されます。(S,G)において、Sはマルチキャストトラフィックの送信元のユニキャストIPアドレスを指し、GはSが送信元である特定のマルチキャストグループのIPアドレスを指します。この送信元から送信されるすべてのマルチキャストパケットには、送信元アドレスとしてS、宛先アドレスとしてGがあります。

(*,G)表記のアスタリスク(*)は、グループGに送信するすべてのマルチキャストアプリケーションソースに状態が適用されることを示すワイルドカードです。そのため、2 つのソースがマルチキャスト グループ 224.1.1.2 のまったく同じコンテンツを発信している場合、ルーティング デバイスは (*,224.1.1.2) を使用して、両方のソースからグループにトラフィックを転送するルーティング デバイスの状態を表すことができます。

マルチキャストルーティングプロトコル

マルチキャストルーティングプロトコルは、直接接続されたサブネット(通常はLAN)上のホストが特定のマルチキャストグループからのトラフィックを受信し、ブランチをプルーニングし、送信元とグループを見つけ、ルーティングループを防止したい場合に、マルチキャストルーティングデバイスの集合で配信ツリーを構築(参加)することができます。

いくつかのマルチキャストルーティングプロトコルがあります。

• DVMRP(ディスタンスベクトルマルチキャストルーティングプロトコル)—最初のマルチキャストルーティングプロトコルであり、多くの制限によって妨げられ、この方法は大規模なインターネット使用には魅力的ではありません。DVMRP は、デンス モードのみのプロトコルであり、フラッド アンド プルーニングまたは暗黙の結合方式を使用して、あらゆる場所にトラフィックを配信し、関心のない受信者がどこにいるかを判別します。DVMRP は、(S,G) 形式のソースベースのディストリビューション ツリーを使用し、RPF チェック用に独自のマルチキャスト ルーティング テーブルを構築します。

• マルチキャスト OSPF(MOSPF)—マルチキャスト用に OSPF を拡張しますが、デンスモード用に限られます。ただし、MOSPFには明示的なジョインメッセージがあるため、ルーティングデバイスは、すべてのソースからのマルチキャストトラフィックでドメイン全体をフラッディングする必要はありません。MOSPFでは、(S,G)形式のソースベースの配布ツリーを使用します。

• 双方向 PIM モード - PIM のバリエーション。双方向PIMは、ランデブーポイント(RP)アドレスをルートとする双方向共有ツリーを構築します。双方向トラフィックは、PIM-SMのように最短パスツリーに切り替わることはありません。そのため、パスの長さではなく、ルーティング状態のサイズに合わせて最適化されます。つまり、エンドツーエンドの遅延は、PIM スパース モードに比べて長くなる可能性があります。双方向 PIM ルートは、常にワイルドカード ソース(*,G)ルートです。このプロトコルにより、(S,G)ルートやデータトリガーイベントが不要になります。双方向(*,G)グループ ツリーは、送信側から RP に向かうアップストリームと、RP から受信側へのダウンストリームの両方でトラフィックを伝送します。その結果、他の PIM モードにある厳密なリバース パス フォワーディング(RPF)ベースのルールは、双方向 PIM には適用されません。代わりに、双方向PIM(*,G)がすべてのソースとRPからのトラフィックを転送します。双方向 PIM ルーティング デバイスは、多くの潜在的な着信インターフェイスでトラフィックを受け入れる機能を備えている必要があります。双方向PIMは、ソース固有の(S,G)状態を必要としないため、スケーリング性に優れています。双方向PIMは、多くの分散したソースと多くの分散した受信機がある導入環境に推奨されます。

• PIM デンスモード - PIM のこのモードでは、ほとんどすべてのサブネットに、送信元からのマルチキャストトラフィックの受信を希望する受信者が少なくとも 1 ついることが前提となります。そのため、ネットワークはすべての可能なブランチのトラフィックで 殺到 し、ブランチがパケットの受信に関心を示さない場合、明示的(メッセージによる)または暗黙的(タイムアウトサイレンス)でプルーバックされます。これは、マルチキャスト操作の デンスモード です。LAN は、デンスモード運用に適したネットワークです。一部のマルチキャストルーティングプロトコル、特に古いプロトコルは、デンスモード動作のみをサポートしているため、インターネットでの使用には適していません。DVMRP や MOSPF とは異なり、PIM デンスモード では、ルーティングデバイスが任意のユニキャストルーティングプロトコルを使用できるようにし、ユニキャスト ルーティングテーブルを使用して RPF チェックを実行します。PIM デンスモードには暗黙のジョイン メッセージがあるため、ルーティング デバイスはフラッド アンド プルーニング方式を使用してあらゆる場所にトラフィックを配信し、関心のない受信者がどこにいるかを判断します。PIM デンスモードは、すべてのデンスモードプロトコルと同様に、(S,G)形式のソースベースのディストリビューションツリーを使用します。PIM は、スパース グループと密なグループが混在するスパース-デンスモードもサポートしますが、その動作モードに特別な表記はありません。 スパース-デンスモード がサポートされている場合、マルチキャストルーティングプロトコルでは、一部のマルチキャストグループをスパースにし、他のグループを高密度にすることができます。

• PIM スパースモード—このPIMモードでは、各ソースからのパケットを必要とする可能性のある受信者はほとんどいないことが前提となります。そのため、ネットワークは、トラフィックへの関心を(メッセージによって)示すリーフが少なくとも1つあるブランチでのみパケットを確立および送信します。このマルチキャストプロトコルにより、ルーティングデバイスは任意のユニキャストルーティングプロトコルを使用できるようになり、ユニキャストルーティングテーブルを使用してリバースパスフォワーディング(RPF)チェックが実行されます。PIM スパース モードには 明示的な ジョイン メッセージがあるため、ルーティング デバイスは関心のある受信者の場所を特定し、ジョイン メッセージをネイバーにアップストリームに送信して、レシーバーからランデブー ポイント(RP)にツリーを構築します。PIMスパースモードは、マルチキャストグループトラフィックの初期ソースとしてRPルーティングデバイスを使用するため、すべてのスパースモードプロトコルと同様に、(*,G)形式で配信ツリーを構築します。PIMスパースモードは、特定のマルチキャストグループのトラフィックに対して、そのパスがRPを介するよりも短い場合、(S,G)ソースベースのツリーに移行します。WANはスパースモードの運用に適したネットワークであり、実際、いかなる状況においてもWAN上でデンスモードを実行しないことが一般的なマルチキャストのガイドラインです。

• CBT(コアベースツリー)—PIM スパースモードの特性(スパースモード、明示的結合、共有(*,G)ツリー)をすべて共有しますが、PIM スパースモードよりもソースの検索効率が高いと言われています。CBT は、学術的な議論以外で遭遇することはめったにありません。商業的であろうとなかろうと、CBTの大規模な展開はありません。

• PIMソース固有のマルチキャスト(SSM)—クライアントがRPの助けを借りずにソースから直接マルチキャストトラフィックを受信できるようにするPIMスパースモードの拡張。IGMPv3 で使用し、受信側と送信側の間に最短パス ツリーを作成します。

• IGMPv1—RFC 1112、 IPマルチキャスト用のホスト拡張で定義された元のプロトコル。IGMPv1は、ルーティングデバイスに明示的な参加メッセージを送信しますが、ホストがグループを離れるタイミングを判断するためにタイムアウトを使用します。3つのバージョンのインターネットグループ管理プロトコル(IGMP)が、受信ホストとルーティングデバイスの間で実行されます。

• IGMPv2—RFC 2236、 インターネットグループ管理プロトコル、バージョン2で定義されています。IGMPv2 は、他の機能の中でも、ジョイン メッセージに明示的な離開メッセージを追加します。

• IGMPv3—RFC 3376、 インターネットグループ管理プロトコル、バージョン3 で定義されています。IGMPv3は、他の機能の中でも特に、マルチキャストグループまたはソース固有のマルチキャスト(SSM)の単一のコンテンツソースのサポートを最適化します。PIM SSMと併用し、受信側と送信元間の最短パスツリーを作成します。

• ブートストラップルーター(BSR)と自動ランデブーポイント(RP)—スパースモードルーティングプロトコルがルーティングドメイン(自律システム、またはAS)内のRPを検索できるようにします。RPアドレスは静的に設定することもできます。

• MSDP(マルチキャストソースディスカバリープロトコル)—1つのマルチキャストルーティングドメインにあるグループが、他のルーティングドメインにあるRPを見つけることを許可します。すべての受信者と送信元が同じルーティングドメインにある場合、MSDPはRPでは使用されません。通常、PIM スパース モード RP と同じルーティング デバイスで実行されます。すべての受信者と送信元が同じルーティングドメインにある場合は適切ではありません。

• SAP(Session Announcement Protocol)およびSDP(Session Description Protocol)—マルチキャストセッション名を表示し、その名前をマルチキャストトラフィックと関連付けます。SDPは、マルチメディア会議セッションをアドバタイズし、セッションに参加したい参加者に設定情報を伝達するセッションディレクトリプロトコルです。クライアントは一般に、SAPを使用して既知のマルチキャストアドレスとポートにアナウンスパケットを定期的にマルチキャストすることで、会議セッションをマルチキャストアドレスにアナウンスします。

• 実用的な汎用マルチキャスト(PGM)—IP層とマルチキャストアプリケーションの間で使用することでマルチキャストトラフィックの信頼性を高めることができるマルチキャストトラフィック用の特別なプロトコル層。PGM を使用すると、受信側はすべてのケースで欠落情報を検出し、受信側アプリケーションが要求する場合に交換情報を要求できます。

マルチキャストルーティングプロトコル間の違いを 表1にまとめます。

リンクや過負荷のルーティング デバイスの高いビット エラー レートによる再送信は、繰り返しのユニキャストと同じくらいマルチキャストを非効率にする可能性があることを認識することが重要です。そのため、多くのマルチキャスト アプリケーションでは、伝送制御プロトコル (TCP) によって提供されるセッション サポート (ただし、TCP は常に欠落しているセグメントを再送します)、またはユーザー データグラム プロトコル (UDP) データグラム サービスの単純なドロップ アンド コンティネンス戦略 (ただし、並べ替えが問題になる可能性があります) に関してトレードオフがあります。最新のマルチキャストは、UDPをほぼ排他的に使用します。

プラットフォーム固有のマルチキャスト動作

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

プラットフォーム固有の動作を確認するには、以下の表を使用して下さい。