IP マルチキャスト：PIM コンフィギュレーション ガイド、Cisco IOS XE Release 3S（Cisco ASR 1000）

IP マルチキャスト アドレスは、IANA によって IPv4 クラス D アドレス空間に割り当てられています。 クラス D アドレスの上位 4 ビットは 1110 です。 したがって、ホスト グループ アドレスの範囲は 224.0.0.0 ～ 239.255.255.255 であると考えられます。 マルチキャスト アドレスがソース（送信側）でマルチキャスト グループの受信先として選択されます。

（注）	クラス D アドレス範囲は、IP マルチキャスト トラフィックのグループ アドレスまたは宛先アドレスだけに使用されます。 マルチキャスト データグラムのソース アドレスは、常にユニキャスト ソースアドレスです。

Any Source Multicast（ASM）配信モードでは、IP マルチキャストのレシーバ ホストは、任意のバージョンの IGMP を使用してマルチキャスト グループに加入できます。 ルーティング テーブル ステート表記では、このグループは G として表記されます。 レシーバ ホストは、このグループに加入することにより、任意のソースからグループ G に送信された IP マルチキャスト トラフィックを受信する意思を示します。 ネットワークは、宛先アドレス G を持つ任意のソース ホストから送信された IP マルチキャスト パケットを、グループ G に加入しているネットワーク内のすべてのレシーバ ホストに配信します。

ASM では、ネットワーク内でグループ アドレスを割り当てる必要があります。 常に、ASM グループは、1 つのアプリケーションでのみ使用される必要があります。 2 つのアプリケーションが同じ ASM グループを同時に使用する場合は、両方のアプリケーションのレシーバ ホストが両方のアプリケーション ソースからトラフィックを受信します。 その結果、ネットワーク内で予期しない過剰なトラフィックが生成される場合があります。 この状況では、ネットワーク リンクの輻輳およびアプリケーションのレシーバ ホストの誤動作が発生する可能性があります。

Source Specific Multicast（SSM）は、ブロードキャスト アプリケーションとしても知られる 1 対多アプリケーションをサポートする最善のデータグラム配信モデルです。 SSM は、オーディオおよびビデオのブロードキャスト アプリケーション環境を対象としたシスコの IP マルチキャスト実装の中核的なネットワーク テクノロジーです。

SSM 配信モードでは、IP マルチキャストのレシーバ ホストは、IGMP バージョン 3（IGMPv3）を使用してチャネル（S, G）にサブスクライブする必要があります。 レシーバ ホストは、このチャネルにサブスクライブすることにより、ソース ホスト S からグループ G に送信された IP マルチキャスト トラフィックを受信する意思を示します。 ネットワークは、ソース ホスト S からグループ G に送信された IP マルチキャスト パケットを、チャネル (S, G) にサブスクライブしているネットワーク内のすべてのホストに配信します。

SSM では、ネットワーク内でグループ アドレスを割り当てる必要はありません。各ソース ホスト内で割り当てるだけです。 同じソース ホストで実行されている異なるアプリケーションは、異なる SSM グループを使用する必要があります。 異なるソース ホストで実行されている異なるアプリケーションは、ネットワーク上で過剰なトラフィックを発生させることなく、任意に SSM グループ アドレスを再利用できます。

PIM デンス モード（PIM-DM）は、プッシュ モデルを使用してマルチキャスト トラフィックをネットワークの隅々にまでフラッディングします。 このプッシュ モデルは、データを要求するレシーバを使用せずにデータをレシーバに配信するための方式です。 この方式は、ネットワークのあらゆるサブネットにアクティブなレシーバが存在する特定の配置には効率的です。

デンス モードでは、ルータは、他のすべてのルータが特定のグループのマルチキャスト パケットの転送を求めていると想定します。 あるルータがマルチキャスト パケットを受信した場合、直接接続されたメンバまたは PIM ネイバーが存在しないときは、ソースにプルーニング メッセージが返送されます。 後続のマルチキャスト パケットは、このプルーニングされたブランチ上のこのルータにはフラッディングされません。 PIM は、ソース ベースのマルチキャスト配信ツリーを構築します。

PIM-DM は最初に、ネットワーク全体にマルチキャスト トラフィックをフラッディングします。 ダウンストリーム ネイバーを持たないルータは、不要なトラフィックをプルーニングします。 このプロセスは 3 分ごとに繰り返されます。

ルータはフラッディングおよびプルーニング メカニズムを通じてデータ ストリームを受信することにより、ステート情報を蓄積します。 これらのデータ ストリームには、ダウンストリーム ルータがマルチキャスト転送テーブルを構築できるように、ソースおよびグループの情報が含まれます。 PIM-DM ではソース ツリー、つまり（S, G）エントリしかサポートされないので、共有配信ツリーは作成できません。

（注）	デンス モードはあまり使用されないため、使用は推奨されていません。 このため、関連モジュールの設定作業では指定しません。

PIM スパース モード（PIM-SM）は、プル モデルを使用してマルチキャスト トラフィックを配信します。 明示的にデータを要求したアクティブなレシーバを含むネットワーク セグメントだけがトラフィックを受信します。

デンス モードのインターフェイスと異なり、スパース モードのインターフェイスは、ダウンストリームのルータから定期的に加入メッセージを受信する場合またはインターフェイスに直接接続のメンバがある場合のみマルチキャスト ルーティング テーブルに追加されます。 LAN から転送する場合、グループが認識している RP があれば、SM 動作が行われます。 その場合、パケットはカプセル化され、その RP に送信されます。 認識している RP がなければ、パケットは DM 方式でフラッディングされます。 特定のソースからのマルチキャスト トラフィックが十分である場合、レシーバのファースト ホップ ルータは、ソース ベースのマルチキャスト配信ツリーを構築するために加入メッセージをソースに向けて送信できます。

PIM-SM は、共有ツリー上のデータ パケットを転送することによって、アクティブな送信元に関する情報を配布します。 PIM-SM は少なくとも最初は共有ツリーを使用するので、ランデブー ポイント（RP）を使用する必要があります。 RP は管理上メットワークで設定されている必要があります。 詳細については、ランデブー ポイントを参照してください。

スパース モードでは、ルータは、トラフィックに対する明示的な要求がない限り、他のルータはグループのマルチキャスト パケットを転送しないと見なします。 ホストがマルチキャスト グループに加入すると、直接接続されたルータは RP に PIM 加入メッセージを送信します。 RP はマルチキャスト グループを追跡します。 マルチキャスト パケットを送信するホストは、そのホストのファースト ホップ ルータによって RP に登録されます。 その後、RP は、ソースに加入メッセージを送信します。 この時点で、パケットが共有配信ツリー上で転送されます。 特定のソースからのマルチキャスト トラフィックが十分である場合、ホストのファースト ホップ ルータは、ソース ベースのマルチキャスト配信ツリーを構築するために加入メッセージをソースに向けて送信できます。

ソースが RP に登録すると、データは共有ツリーを下方向に転送され、レシーバに到達します。 エッジ ルータは、RP を介してソースから共有ツリーでデータ パケットを受信するときに、そのソースについて学習します。 次に、エッジ ルータは、そのソースに向けて PIM (S, G)加入メッセージを送信します。 リバース パスに沿った各ルータは、RP アドレスのユニキャスト ルーティング メトリックをソース アドレスのメトリックと比較します。 ソース アドレスのメトリックの方が良い場合は、ソースに向けて PIM（S, G）加入メッセージを転送します。 RP のメトリックと同じ、または RP のメトリックの方が良い場合は、RP と同じ方向に PIM (S, G)加入メッセージが送信されます。 この場合、共有ツリーとソース ツリーは一致すると見なされます。

共有ツリーがソースとレシーバの間の最適なパスでない場合、ルータは動的にソース ツリーを作成し、共有ツリーの下方向へのトラフィック フローを停止します。 この動作は、ソフトウェアのデフォルトの動作です。 ネットワーク管理者は、ip pim spt-threshold infinity コマンドを使用して、トラフィックを強制的に共有ツリー上で保持することができます。

PIM-SM は、WAN リンク付きのネットワークを含む、任意のサイズのネットワークに合わせて拡大または縮小します。 明示的な加入メカニズムによって、不要なトラフィックが WAN リンクでフラッディングするのを防ぎます。

インターフェイス上でスパース モードまたはデンス モードを設定すると、そのインターフェイス全体にスパース性またはデンス性が適用されます。 ただし、環境によっては、単一リージョン内の一部のグループについては PIM をスパース モードで実行し、残りのグループについてはデンス モードで実行しなければならない場合があります。

デンス モードだけ、またはスパース モードだけをイネーブルにする代わりに、スパース-デンス モードをイネーブルにできます。 この場合、グループがデンス モードであればインターフェイスはデンス モードとして処理され、グループがスパース モードであればインターフェイスはスパース モードとして処理されます。 インターフェイスがスパース-デンス モードである場合にグループをスパース グループとして処理するには、RP が必要です。

スパース-デンス モードを設定すると、ルータがメンバになっているグループにスパース性またはデンス性の概念が適用されます。

スパース-デンス モードのもう 1 つの利点は、Auto-RP 情報をデンス モードで配信しながら、ユーザ グループのマルチキャスト グループをスパース モード方式で使用できることです。 したがって、リーフ ルータ上にデフォルト RP を設定する必要はありません。

インターフェイスがデンス モードで処理される場合、次のいずれかの条件が満たされると、そのインターフェイスはマルチキャスト ルーティング テーブルの発信インターフェイス リストに追加されます。

• インターフェイス上にメンバまたは DVMRP ネイバーが存在する。
• PIM ネイバーが存在し、グループがプルーニングされていない。

インターフェイスがスパース モードで処理される場合、次のいずれかの条件が満たされると、そのインターフェイスはマルチキャスト ルーティング テーブルの発信インターフェイス リストに追加されます。

• インターフェイス上にメンバまたは DVMRP ネイバーが存在する。
• インターフェイス上の PIM ネイバーが明示的な加入メッセージを受信した。

双方向 PIM（Bidir-PIM）は、個々の PIM ドメイン内での効率的な多対多通信用に設計された PIM プロトコルの拡張機能です。 双方向モードのマルチキャスト グループは、追加オーバーヘッドを最小限に抑えながら、任意の数のソースに対応できます。

PIM スパース モードで作成される共有ツリーは単方向性です。 これは、データ ストリームが RP（共有ツリーのルート）にもたらされるようにソース ツリーを作成する必要があることを意味します。これにより、データ ストリームはブランチを下方向に転送され、レシーバに到達できます。 ソースのデータは、共有ツリーの上方向にある RP に向かって流れることはできません。これは、双方向共有ツリーと見なされます。

双方向モードでは、トラフィックは、グループの RP をルートとする双方向共有ツリーに沿ってのみ、ルーティングされます。 Bidir-PIM では、RP の IP アドレスは、すべてのルータがその IP アドレスをルートとするループフリーのスパニングツリー トポロジを確立するうえで重要な役割を果たします。 この IP アドレスはルータ アドレスである必要はなく、PIM ドメイン内のどこからでも到達可能なネットワーク上の任意の未割り当て IP アドレスを使用できます。

Bidir-PIM は PIM スパース モード（PIM-SM）のメカニズムから派生しており、共有ツリー動作の多くを共有します。 Bidir-PIM にも、共有ツリーのアップストリームにある RP に向けてソース トラフィックを無条件に転送する機能がありますが、PIM-SM のようなソースの登録プロセスはありません。 これらの変更は、すべてのルータで (*, G) マルチキャスト ルーティング エントリだけに基づいてトラフィックを転送できるようにするには、必要にして十分なものです。 この機能では、ソース固有のステートは不要であり、スケーリング機能を使用して任意の数のソースに対応できます。

双方向モードでは、トラフィックは、グループのランデブー ポイント（RP）をルートとする双方向共有ツリーに沿ってのみ、ルーティングされます。 Bidir-PIM では、RP の IP アドレスは、すべてのルータがその IP アドレスをルートとするループフリーのスパニングツリー トポロジを確立するうえで重要な役割を果たします。 この IP アドレスはルータである必要はなく、PIM ドメイン内のどこからでも到達可能なネットワーク上の任意の未割り当て IP アドレスを使用できます。 この技術は、Bidir-PIM の冗長 RP 設定を確立するための優先設定方式です。

双方向グループに対するメンバーシップは、明示的な加入メッセージを通じて伝えられます。 ソースからのトラフィックは、無条件で、共有ツリーの上方向にある RP に向けて送信され、ツリーの下方向にある各ブランチ上のレシーバに渡されます。

スパース モード動作は 1 つの単方向共有ツリーを中心としており、そのルート ノードは Rendezvous Point（RP）と呼ばれます。 マルチキャスト トラフィックが RP 経由で共有ツリーを下方向に流れるためには、ソースが RP に登録する必要があります。 この登録プロセスでは、ネットワーク内のグループにアクティブなレシーバが存在すると、実際に RP によって最短パス ツリー（SPT）加入がソースに向けてトリガーされます。

スパース モード グループは、明示的な相互運用加入モデルを使用します。 レシーバ ホストは、ランデブー ポイント（RP）でグループに加入します。 異なるグループは、異なる RP を持つ可能性があります。

マルチキャスト トラフィック パケットは、共有ツリーを下方向へ流れ、トラフィックの受信を明示的に求めたレシーバだけに到達します。

デンス モードは、ブロードキャスト（フラッディング）およびプルーニング モデルを使用して動作します。

マルチキャスト ルーティング テーブルに値を入力する際には、デンス モード インターフェイスが常にテーブルに追加されます。 マルチキャスト トラフィックは、発信インターフェイス リスト内のすべてのインターフェイスからすべてのレシーバへ転送されます。 インターフェイスは、プルーニングと呼ばれるプロセスで発信インターフェイス リストから削除されます。 デンス モードでは、直接接続されたレシーバが存在しないなど、さまざまな理由でインターフェイスがプルーニングされます。

プルーニングされたインターフェイスは再構築が可能です。つまり、マルチキャスト トラフィックのフローを最小限の遅延で再開できるように再接合できます。

PIM-SM の最初のバージョンでは、すべてのリーフ ルータ（ソースまたはレシーバに直接接続されたルータ）は、RP の IP アドレスを使用して手動で設定する必要がありました。 このような設定は、スタティック RP 設定とも呼ばれます。 スタティック RP の設定は、小規模のネットワークでは比較的容易ですが、大規模で複雑なネットワークでは困難を伴う可能性があります。

PIM-SM バージョン 1 の導入に続き、シスコは、Auto-RP 機能を備えた PIM-SM のバージョンを実装しました。 Auto-RP は、PIM ネットワークにおけるグループから RP へのマッピングの配信を自動化します。 Auto-RP には、次の利点があります。

• さまざまなグループにサービスを提供するために、ネットワーク内で複数の RP を設定することが比較的容易です。
• Auto-RP を使用すると、複数の RP 間で負荷を分散し、グループに加入するホストの場所に従って RP を配置できます。
• Auto-RP により、接続の問題の原因となる、矛盾した手動 RP 設定を回避できます。

複数の RP を使用して、異なるグループ範囲にサービスを提供したり、互いにバックアップとしての役割を果たしたりできます。 Auto-RP が機能するためには、RP 通知メッセージを RP から受信して競合を解決する RP マッピング エージェントとしてルータが指定されている必要があります。 その後、RP マッピング エージェントは、グループから RP への一貫したマッピングを他のすべてのルータに送信するようになります。 これにより、すべてのルータは、サポート対象のグループに使用する RP を自動的に検出します。

（注）	PIM をスパース モードまたはデンス モードに設定し、Auto-RP を設定しない場合は、RP を静的に設定する必要があります。

（注）	ルータ インターフェイスがスパース モードに設定されている場合、Auto-RP グループに対してすべてのルータが 1 つのスタティック アドレスで設定されているときは、引き続き Auto-RP グループを使用できます。

Auto-RP が機能するためには、RP 通知メッセージを RP から受信して競合を解決する RP マッピング エージェントとしてルータが指定されている必要があります。 その後、RP マッピング エージェントは、デンス モード フラッディングにより、グループから RP への一貫したマッピングを他のすべてのルータに送信するようになります。 これにより、すべてのルータは、サポート対象のグループに使用する RP を自動的に検出します。 インターネット割り当て番号局（IANA）は、224.0.1.39 と 224.0.1.40 という 2 つのグループ アドレスを Auto-RP 用に割り当てています。 Auto-RP の利点の 1 つは、指定した RP に対するすべての変更は、RP であるルータ上で設定するだけで、リーフ ルータ上で設定する必要がないことです。 Auto-RP のもう 1 つの利点は、ドメイン内で RP アドレスのスコープを設定する機能を提供することです。 スコーピングを設定するには、Auto-RP アドバタイズメントに許容されている存続可能時間（TTL）値を定義します。

RP の各設定方式には、それぞれの長所、短所、および複雑度のレベルがあります。 従来の IP マルチキャスト ネットワーク シナリオにおいては、Auto-RP を使用して RP を設定することを推奨します。Auto-RP は、設定が容易で、十分にテストされており、安定しているためです。 代わりの方法として、スタティック RP、Auto-RP、およびブートストラップ ルータを使用して RP を設定することもできます。

Auto-RP の前提条件は、ip pim sparse-dense-mode インターフェイス コンフィギュレーション コマンドを使用して、すべてのインターフェイスをスパース - デンス モードで設定する必要があることです。 スパース-デンス モードで設定されたインターフェイスは、マルチキャスト グループの動作モードに応じてスパース モードまたはデンス モードで処理されます。 マルチキャスト グループ内に既知の RP が存在する場合、インターフェイスはスパース モードで処理されます。 グループ内に既知の RP が存在しない場合、デフォルトでは、インターフェイスはデンス モードで処理され、このインターフェイス上にデータがフラッディングされます （デンス モード フォールバックを回避することもできます。「基本的な IP マルチキャスト設定」モジュールを参照してください）。

Auto-RP を正常に実装し、224.0.1.39 および 224.0.1.40 以外のグループがデンス モードで動作することを回避するには、「シンク RP」（「ラスト リゾート RP」とも呼ばれます）を設定することを推奨します。 シンク RP は、ネットワーク内に実際に存在するかどうかわからない静的に設定された RP です。 デフォルトでは、Auto-RP メッセージはスタティック RP 設定よりも優先されるため、シンク RP の設定は Auto-RP の動作と干渉しません。 未知のソースや予期しないソースをアクティブにできるため、ネットワーク内の可能なすべてのマルチキャスト グループにシンク RP を設定することを推奨します。 ソースの登録を制限するように設定された RP がない場合は、グループがデンス モードに戻り、データがフラッディングされる可能性があります。

PIM-SM バージョン 2 では、Auto-RP に続いてブートストラップ ルータ（BSP）と呼ばれるもう 1 つの RP 選択モデルが導入されました。 BSR は、RP 機能およびグループの RP 情報のリレーに候補ルータを使用するという点において Auto-RP と同様に動作します。 RP 情報は、PIM メッセージ内で伝送される BSR メッセージを通じて配信されます。 PIM メッセージは、PIM ルータから PIM ルータに送信されるリンクローカル マルチキャスト メッセージです。 RP 情報を広めるこのシングル ホップ方式のために、TTL スコーピングは BSR と一緒に使用できません。 デンス モード動作に戻るというリスクを冒さないこと、およびドメイン内でスコープ設定機能を提供しないことを除いて、BSR は RP と同様に動作します。

PIM スパース モード モデルでは、マルチキャスト ソースおよびレシーバはローカルのランデブー ポイント（RP）に登録する必要があります。 実際には、ソースまたはレシーバに最も近いルータが RP に登録しますが、注目すべき重要点は、RP が特定のグループのすべてのソースおよびレシーバを認識していることです。 他のドメインの RP が他のドメインに存在するソースについて知る方法はありません。 Multicast Source Discovery Protocol（MSDP）は、この問題を解決するための洗練された手段です。

MSDP は、アクティブなソースに関する情報を RP が共有できるようにするメカニズムです。 RP は、ローカル ドメイン内のレシーバを認識しています。 リモート ドメインの RP は、アクティブなソースについてヒアリングすると、その情報をそれぞれのローカル レシーバに渡すことができます。 その後、ドメイン間でマルチキャスト データを転送できるようになります。 MSDP の便利な機能は、他のドメインに依存しない独自の RP を各ドメインが維持することは許可するが、RP がドメイン間でトラフィックを転送することは許可しないことです。 マルチキャスト ドメイン間でのトラフィックの転送には、PIM-SM が使用されます。

各ドメインの RP は、TCP 接続を使用して、他のドメインの RP または他のドメインに接続する境界ルータとの MSDP ピアリング セッションを確立します。 RP は、（正規の PIM 登録メカニズムを通じて）自身のドメイン内にある新しいマルチキャスト ソースについて知ると、Source-Active（SA）メッセージの最初のデータ パケットをカプセル化し、その SA をすべての MSDP ピアに送信します。 各受信側ピアは、相互接続されたネットワーク（理論的には、マルチキャスト インターネット全体）内のすべての MSDP ルータに SA が到達するまで、修正されたリバース パス転送（RPF）チェックを使用して SA を転送します。 受信側の MSDP ピアが RP であり、その RP に SA 内のグループに対する (*, G) エントリがある（該当する受信先が存在する）場合、RP はソースに対して (S, G) ステートを作成し、ソースの最短パス ツリーに加入します。 このカプセル化されたデータはカプセル化解除され、その RP の共有ツリーを下方向に転送されます。 ラスト ホップ ルータ（レシーバに最も近いルータ）は、マルチキャスト パケットを受信すると、ソースへの最短パス ツリーに加入できるようになります。 MSDP スピーカーは、その RP のドメイン内のすべてのソースを含む SA を定期的に送信します。

MSDP は、インターネット サービス プロバイダー（ISP）間のピアリングを実現するために開発されました。 ISP は、競合する ISP によって管理された RP に依存して顧客にサービスを提供することを望んでいませんでした。 MSDP により、各 ISP は独自のローカル RP を持ちながら、インターネットに対してマルチキャスト トラフィックを送受信できます。

エニーキャスト RP は、MSDP の有益な応用です。 本来、MSDP は、ドメイン間マルチキャスト アプリケーション用に開発されたものですが、冗長性および負荷分散機能を提供するドメイン間機能としてエニーキャスト RP にも使用されます。 エンタープライズ カスタマーは、通常、単一のマルチキャスト ドメイン内の耐障害性要件を満たすために、エニーキャスト RP を使用して Protocol Independent Multicast スパース モード（PIM-SM）ネットワークを設定します。

エニーキャスト RP では、ループバック インターフェイス上で同じ IP アドレスを使用して複数の RP を設定します。 エニーキャスト RP ループバック アドレスは、32 ビット マスクを使用して設定し、ホスト アドレスにする必要があります。 すべてのダウンストリーム ルータは、このエニーキャスト RP ループバック アドレスがローカル RP の IP アドレスであることを認識するように設定する必要があります。 IP ルーティングでは、トポロジ的に最も近い RP が各ソースおよびレシーバに自動的に選択されます。 ソースはネットワークの周囲に等間隔に配置されていると仮定すると、各 RP には同数のソースが登録されます。 つまり、ソースを登録するプロセスは、ネットワーク内のすべての RP によって均等に共有されます。

ソースは 1 つの RP に登録でき、レシーバは異なる RP に加入できるため、RP にはアクティブなソースに関する情報を交換するための手段が必要です。 この情報の交換は、MSDP を使用して行われます。

エニーキャスト RP では、すべての RP が互いに MSDP ピアになるように設定されます。 ソースが 1 つの RP に登録すると、特定のマルチキャスト グループにアクティブなソースが存在することを通知する SA メッセージが他の RP に送信されます。 その結果、各 RP は、他の RP のエリア内に存在するアクティブなソースを認識します。 いずれかの RP で障害が発生すると、IP ルーティングが収束し、他の RP のいずれかが複数のエリアのアクティブ RP になります。 新しいソースは、バックアップ RP に登録します。 レシーバはこれらの新しい RP に加入し、接続が維持されます。

（注）	RP は、通常、ソースおよびレシーバとの新しいセッションを開始するためだけに必要になります。 RP は、ソースとレシーバがマルチキャスト データ フローを直接確立できるように、共有ツリーを支援します。 すでにソースとレシーバの間にマルチキャスト データ フローが確立されている場合、そのセッションは RP 障害による影響を受けません。 エニーキャスト RP を使用すると、いつでもソースおよびレシーバとの新しいセッションを開始できます。

マルチキャスト配信ツリーの最も単純な形式は、ソース ツリーです。 ソース ツリーは、ソース ホストをルートとし、ネットワークを介してレシーバに接続するスパニングツリーを形成するブランチを持ちます。 このツリーはネットワーク上での最短パスを使用するため、最短パス ツリー（SPT）とも呼ばれます。

図に、ソース（ホスト A）をルートとし、2 つのレシーバ（ホスト B およびホスト C）に接続するグループ 224.1.1.1 の SPT の例を示します。

標準表記を使用すると、図の例の SPT は（192.168.1.1, 224.1.1.1）となります。

（S, G）という表記は、各グループに送信する個々のソースに個別の SPT が存在することを意味します。

ソースをルートとするソース ツリーとは異なり、共有ツリーはネットワーク内の選択されたポイントに配置された単一の共通ルートを使用します。 この共有されたルートは、ランデブー ポイント（RP）と呼ばれます。

図 5 に、ルータ D にルートが配置されたグループ 224.2.2.2 の共有ツリーを示します。 この共有ツリーは一方向です。 ソース トラフィックは、ソース ツリー上の RP に向けて送信されます。 このトラフィックは、次に RP から共有ツリーを下方向に転送され、すべてのレシーバに到達します（レシーバがソースと RP の間に配置されていない場合は、直接サービスが提供されます）。

この例では、ソース（ホスト A およびホスト D）からのマルチキャスト トラフィックは、ルート（ルータ D）に送信された後、共有ツリーを下方向に転送され、2 つのレシーバ（ホスト B およびホスト C）に到達します。 マルチキャスト グループ内のすべてのソースが同じ共有ツリーを使用するため、このツリーは、（*, G）というワイルドカード表記（「スター カンマ G」と読みます）を使用して表されます。 この場合、* はすべてのソースを意味し、G はマルチキャスト グループを表します。 したがって、図 5 の共有ツリーは（*, 224.2.2.2）と表記します。

ソース ツリーと共有ツリーは、どちらもループフリーです。 ツリーが分岐する場所でのみ、メッセージが複製されます。 マルチキャスト グループのメンバは常に加入または脱退する可能性があるため、配信ツリーを動的に更新する必要があります。 特定のブランチに存在するすべてのアクティブ レシーバが特定のマルチキャスト グループに対してトラフィックを要求しなくなると、ルータは配信ツリーからそのブランチをプルーニングし、そのブランチから下方向へのトラフィック転送を停止します。 そのブランチの特定のレシーバがアクティブになり、マルチキャスト トラフィックを要求すると、ルータは配信ツリーを動的に変更し、トラフィック転送を再開します。

ソース ツリーには、ソースとレシーバの間に最適なパスを作成するという利点があります。 この利点により、マルチキャスト トラフィックの転送におけるネットワーク遅延を最小限に抑えることができます。 ただし、この最適化は代償を伴います。 ルータがソースごとにパス情報を維持する必要があるのです。 何千ものソース、何千ものグループが存在するネットワークでは、このオーバーヘッドがすぐにルータ上でのリソースの問題につながる可能性があります。 ネットワーク設計者は、マルチキャスト ルーティング テーブルのサイズによるメモリ消費について考慮する必要があります。

共有ツリーには、各ルータにおいて要求されるステートの量が最小限に抑えられるという利点があります。 この利点により、共有ツリーだけが許容されるネットワークの全体的なメモリ要件が緩和されます。 共有ツリーの欠点は、特定の状況でソースとレシーバの間のパスが最適パスではなくなり、パケット配信に遅延を生じる可能性があることです。 たとえば、上の図の場合、ホスト A（ソース 1）とホスト B（レシーバ）の間の最短パスは、ルータ A およびルータ C であると考えられます。 ここでは、ルータ D を共有ツリーのルートとして使用しているため、トラフィックは、ルータ A、ルータ B、ルータ D、ルータ C の順に通過する必要があります。 共有ツリーだけの環境を実装する場合、ネットワーク設計者は、Rendezvous Point（RP）の配置を慎重に検討する必要があります。

ユニキャスト ルーティングでは、トラフィックは、ネットワーク上でソースから宛先ホストまでの単一パスに沿ってルーティングされます。 ユニキャスト ルータは、ソース アドレスを考慮せず、宛先アドレスおよびその宛先へのトラフィックの転送方法だけを考慮します。 ルータは、ルーティング テーブル全体をスキャンして宛先アドレスを取得し、適正なインターフェイスから宛先の方向へユニキャスト パケットのコピーを転送します。

マルチキャスト転送では、ソースは、マルチキャスト グループ アドレスによって表される任意のホスト グループにトラフィックを送信します。 マルチキャスト ルータは、どの方向が（ソースへ向かう）アップストリーム方向で、どの方向（1 方向または複数の方向）が（レシーバへ向かう）ダウンストリーム方向であるかを決定する必要があります。 複数のダウンストリーム パスがある場合、ルータはパケットを複製し、それを適切なダウンストリーム パス（最善のユニキャスト ルート メトリック）で下方向に転送します。これらのパスがすべてであるとは限りません。 レシーバの方向ではなく、ソースから遠ざかる方向へのマルチキャスト トラフィック転送は、リバース パス転送（RPF）と呼ばれます。 RPF については、次の項を参照してください。

ユニキャスト ルーティングでは、トラフィックは、ネットワーク上でソースから宛先ホストまでの単一パスに沿ってルーティングされます。 ユニキャスト ルータは、ソース アドレスを考慮せず、宛先アドレスおよびその宛先へのトラフィックの転送方法だけを考慮します。 ルータは、ルーティング テーブル全体をスキャンして宛先ネットワークを取得し、適正なインターフェイスから宛先の方向へユニキャスト パケットのコピーを転送します。

マルチキャスト転送では、ソースは、マルチキャスト グループ アドレスによって表される任意のホスト グループにトラフィックを送信します。 マルチキャスト ルータは、どの方向が（ソースへ向かう）アップストリーム方向で、どの方向（1 方向または複数の方向）が（レシーバへ向かう）ダウンストリーム方向であるかを決定する必要があります。 複数のダウンストリーム パスがある場合、ルータはパケットを複製し、それを適切なダウンストリーム パス（最善のユニキャスト ルート メトリック）で下方向に転送します。これらのパスがすべてであるとは限りません。 レシーバの方向ではなく、ソースから遠ざかる方向へのマルチキャスト トラフィック転送は、リバース パス転送（RPF）と呼ばれます。 RPF は、マルチキャスト データグラムの転送に使用されるアルゴリズムです。

Protocol Independent Multicast（PIM）は、ユニキャスト ルーティング情報を使用して、レシーバからソースへ向かうリバース パスに沿って配信ツリーを作成します。 その後、マルチキャスト ルータは、その配信ツリーに沿ってソースからレシーバにパケットを転送します。 RPF は、マルチキャスト転送における重要な概念です。 RPF により、ルータは、配信ツリーの下方向へ正しくマルチキャスト トラフィックを転送できます。 RPF は、既存のユニキャスト ルーティング テーブルを使用して、アップストリーム ネイバーとダウンストリーム ネイバーを決定します。 ルータは、アップストリーム インターフェイスで受信した場合にのみ、マルチキャスト パケットを転送します。 この RPF チェックにより、配信ツリーがループフリーであることを保証できます。

マルチキャスト パケットがルータに到達すると、ルータはそのパケットに対して RPF チェックを実行します。 RPF チェックが成功すると、パケットが転送されます。 そうでない場合、パケットはドロップされます。

ソース ツリーを下方向へ流れるトラフィックに対する RPF チェック手順は次のとおりです。

1. ルータは、ユニキャスト ルーティング テーブルでソース アドレスを検索して、ソースへのリバース パス上にあるインターフェイスにパケットが到達したかどうかを判定します。
2. ソースに戻すインターフェイスにパケットが到達した場合、RPF チェックは成功し、マルチキャスト ルーティング テーブル エントリの発信インターフェイス リストに示されているインターフェイスからパケットが転送されます。
3. ステップ 2 で RPF チェックに失敗した場合は、パケットがドロップされます。

図に、RPF チェックの失敗例を示します。

図 2. RPF チェックの失敗

図では、ソース 151.10.3.21 からのマルチキャスト パケットはシリアル インターフェイス 0（S0）上で受信されています。 ユニキャスト ルート テーブルのチェック結果は、このルータが 151.10.3.21 にユニキャスト データを転送するために使用するインターフェイスは S1 であることを示しています。 パケットはインターフェイス S0 に到達しているため、このパケットは廃棄されます。

図に、RPF チェックの成功例を示します。

図 3. RPF チェックの成功

この例では、マルチキャスト パケットはインターフェイス S1 に到達しています。 ルータはユニキャスト ルーティング テーブルを参照し、S1 が適正なインターフェイスであることを知ります。 RPF チェックが成功し、パケットが転送されます。