オペレーティング システム

要約
このホワイト ペーパーでは、PIM-SM マルチキャスト ルーティング プロトコル Version 2 について説明します。すでにマルチキャスティングに関する知識があり、PIM-SM RFC について読む前にその概要を知りたいと考えている IT 管理者を対象に書かれています。PIM-SM は、グループが各地に散在している WAN 上で効率的に運用できるように設計されています。さらに、従来の受信者開始型メンバシップの IP マルチキャスト モデルを使用し、共有ツリーと最短パス ツリーの両方をサポートし、特定のユニキャスト ルーティング プロトコルには依存せず、変化するネットワーク状態に適応するため、ソフト状態メカニズムを採用しています。

トピック

 はじめに
 PIM-SM プロトコル
 PIM-SM プロトコルの詳細
 未解決の問題
 PIM-SM コントロール メッセージ
 まとめ

はじめに

PIM-SM (Protocol Independent Multicast-Sparse Mode) は、マルチキャスト パケットをマルチキャスト グループにルーティングし、WAN (wide area network) 上で配布ツリーを効率的に確立します。PIM-SM は、"プロトコル非依存型" と呼ばれ、任意のルーティング プロトコルが "マルチキャスト RIB (Routing Information Base)"、つまり Windows 用語でいう "マルチキャスト ビュー" にあるルート情報を使用できます。ルーティング プロトコルの例としては、RIP (Routing Information Protocol)、OSPF (Open Shortest Path First) などのユニキャスト プロトコルがあります。しかし、ルーティング テーブルの生成に使用する、DVMRP (Distance Vector Multicast Routing Protocol) などのマルチキャスト プロトコルも使用できます。"スパース モード" とは、広い領域でマルチキャスト グループがまばらに散在している環境用に設計されているプロトコルです。スパース モード プロトコルは、LAN 環境でも使用できますが、WAN に最適なプロトコルです。

スパース グループは以下の特色を持つグループと定義できます。a) グループ メンバが入っているネットワークまたはドメインの数が、インターネットのネットワーク/ドメイン数に比べて非常に少ない。b) グループ メンバが存在する地域は、ホップ数制限、その他のマルチキャスト パケット伝達範囲を制限する形式に依存するには大きすぎる (広すぎる)。c) インターネットワークには、現在の [デンス モード] スキームのオーバーヘッドを無視できるほど十分なリソースがない。1

その逆に、DVMRP と Multicast OSPF (MOSPF) などのデンス モード プロトコルは、マルチキャスト グループが多く、帯域幅が十分に大きい場合に使用します。これらのスキームでは、データ パケットやメンバシップ レポート情報が、マルチキャスト発信元や対象受信者とは無関係のインターフェイスに不必要に送信されることがあります。また、ルーターが無関係なノードの状態を格納しますが、これも無駄な活動です。このオーバーヘッドは、ほとんどのホストがデータの配信先で、制御メッセージのフローを維持できる十分な帯域幅がある場合は問題ありませんが、そうでなければ非効率的です。PIM-SM は、ホストは明示的に要求したデータ以外のデータは必要としないものと見なします。しかし、PIM にもスパース モードとの相互運用が可能なデンス モードに相当するモード (PIM-DM) があります。

PIM-SM には以下の特長があります。

• 従来の、受信者開始型マルチキャスト グループ メンバシップの IP マルチキャスト サービス モデルを維持します。このモデルでは、発信元は最初のホップ イーサネットにパケットを置くだけで、信号は送らず、受信者が、マルチキャスト グループに参加してデータを受信するために、ルーターに信号を送ります。

• ホストのモデルは変更しません。PIM-SM はルーター間プロトコルです。つまり、ホストをアップグレードする必要がない代わりに、PIM-SM 対応ルーターをネットワークに展開する必要があります。

• 共有ツリーとソース配布ツリーの両方をサポートします。PIM-SM は、共有ツリーでは RP (Rendezvous Point) という名前の中央ルーターを共有ツリーのルートとして使用します。ソース ホストはすべてマルチキャスト トラフィックを RP に送り、そこから共通ツリーを介して、グループのすべてのメンバにパケットを転送します。ソース ツリーは、発信元と受信者を直接接続し、各発信元が個別のツリーを持ちます。ソース ツリーは、ユニキャスト ルーティング テーブルの側から見ると、最短パス ツリーとなります。PIM-SM は、どちらかのツリーを使用することも、両方を同時に使用することも可能です。

• 特定のユニキャスト ルーティング プロトコル (上記参照) にも依存しない独立性を維持します。

• ソフト状態メカニズムを使用して、変化するネットワーク状態とマルチキャスト グループに動的に対応します。"ソフト状態" とは、リフレッシュしない限りルーターの状態設定有効期間が短く、一定時間が経過すると無効となることを意味します。

以下では、これらの点について詳細に説明し、また PIM-SM の運用例を示します。説明は、1998 年 6 月に RFC 2362 で指定された PIM-SM Version 2 (試験段階) を中心に行い、Version 1 と異なる部分については、その旨を明記します。

PIM-SM プロトコル

PIM-SM プロトコルは、以下の部分から構成されます。

• Hello メッセージング

• マルチキャスト パケットの転送

• 共有ツリーへの参加

• RP への登録

• 最短パス ツリー (SPT) スイッチング

• プルーニング インターフェイス

• Assert (アサート) メッセージング

• RP の決定

これらの各項目について詳しく説明していきます。安定した、つまり RP がすでに選択されている状態のシステムを前提とし、その選択方法については、最後のセクションで説明します。

はじめに、以下の項目を説明します。

• Flooding と reverse path forwarding (RPF)

• 最短パス ツリー

• 共有ツリー

これらの用語を理解すると、PIM-SM プロトコルを理解しやすくなります。

Flooding と Reverse Path Forwarding

Flooding とは、ルーティング情報の保存が必要ない、単純なルーティング スキームです。Flooding では、パケットは発信元以外のすべてのインターフェイスに転送されます。パケットが複製される回数を制限するには、ホップ数などのメトリックが使用されます。これが指定したしきい値に達すると、パケットは破棄されます。

Flooding の問題は、各パケットのコピー量が急増することです。このため、Flooding を使用すると、パケットが消失しない限り、各パケットのコピーがそれぞれのキャッシュに確実に配布されますが、一方で、Flooding 自体が混雑状態を引き起こすことがあるため、パケットが消失する確率が高くなります。

Reverse path forwarding (RPF) は、Yogen Dalal2 が開発したコンセプトで、Flooding を最適化したものです。この方法では、ルーターがソース S に到達するためのインターフェイスがインターフェイス I だけである場合に限り、ルーターは S から I 経由でパケットを受信します。インターフェイスが正しいかどうかは、ユニキャスト ルーティング テーブルで確認します。この方法を使用すると、標準 Flooding に必要なオーバーヘッドを大幅に削減できます。ルーターは 1 つの近隣ノードからしかパケットを受け付けないので、パケットの送信は 1 度だけです。つまり、ポイント ツー ポイント リンクの場合、各パケットは各リンクで各方向につき 1 度だけ転送されます。RPF の例を下の図 1 に示します。

この例では、ルーターはインターフェイス I0 経由で受信したネットワーク 172.16.0.0/20 にあるソースのパケットを破棄します。これは、ルーティング テーブルにこのインターフェイスがネットワーク 172.16.0.0/20 への最短パスとしてリストされていないためです。ルーターがそのネットワーク宛てのパケットを持っていれば、インターフェイス I1 を使用し、インターフェイス I1 を介して受信したパケットは、ルーティング テーブルにネットワークへの最短パスとしてリストされているので転送されます。ルーターのルーティング テーブルを使ってマルチキャスト パケットの最短パスを決定する点に注意してください。

最短パス ツリー

最短パス ツリー (SPT) は "ソース ベースの" ツリーとも呼ばれます。転送するパスがソースへの最短ユニキャスト パスに基づいて決められることを意味します。"ソース ツリーが、ユニキャスト ルーティング テーブルの観点から見て、最短パス ツリーである" というときには、このことを意味しています。ユニキャスト ルーティングのメトリックがホップ数の場合は、マルチキャスト SPT のブランチが最小ホップとなります。メトリックがディレイの場合は、このブランチが最小ディレイとなります。

各マルチキャスト ソースには対応するマルチキャスト ツリーがあり、直接ソースと全受信者を接続します。ソースと関連グループのツリーが構築されると、グループ メンバへのトラフィックはすべてこのツリーを使って渡されます。SPT には、送信インターフェイスのリストに (S, G) エントリがあります。S はソース アドレス、G はマルチキャスト グループです。SPT を使用するその他のプロトコルには DVMRP と MOSPF があります。これらはデンス モード プロトコルです。下の図 2 に SPT の例を示します。

この例では、ソース 1 の SPT はルーター 1 とルーター 3 の組み合わせで別のパスがあったとしても、ルーター 1のインターフェイス I0 を通ります。ソース 2 の SPT も同じように、たとえ別の (もっと長い) パスがあったとしてもインターフェイス I3 を通ります (この例では、メトリックはホップ数です)。

共有ツリー

PIM-SM の共有ツリーは、RP ツリー (RPT) と呼ばれます。ソースからすべてのトラフィックを受信し、そのトラフィックを受信者に転送する RP (rendezvous point) という中央ルーターに依存するからです。メンバは中央ノードに明示的に参加を送信するので、すべてのホストが受信するとは見なされません。その結果、ソースがいくつあっても、各マルチキャスト グループに作成されるツリーは 1 つだけです。グループを認識しているルーターだけがツリーに加わり、データはそのデータを必要とする受信者にのみ送られます。RPT には (*, G) エントリ (ワイルドカード エントリ) があります。G はマルチキャスト グループを意味します。RP には、まだソースが存在しない段階でも受信者の参加を受け付ける場所があります。

共有ツリーは 1 方向性です。つまり、データは RP から受信者へのみ送信されます。RP 以外のホストが共有ツリー上で送信する場合、データを参加者にマルチキャストする前に、まず RP にトンネリングします。これは、受信者がソースでもある場合、共有ツリーを使ってパケットを RP に送信することはできないということを意味します。このような受信者は、パケットを RP から受信する場合にのみ共有ツリーを使用できます (一般的にはこの説明どおりですが、ソースが RP とその他の受信者の間にある場合、およびそれがすでにツリーにある場合など、例外があります。この場合、データは直接ソースから受信者へ送られます)。

RPT はディレイは長くなりますが (パケットは、配布する前に RP に送る必要があるため)、維持するルーター状態は少なくなります。RPT が適したアプリケーションの例を示します。

• 低速データ ソースのネットワーク

• ディレイを許容できるアプリケーション

• グループ内のほとんどの参加者間での一貫性のあるポリシーとアクセス制御を必要とするアプリケーション

• ソース ツリーのほとんどがトポロジ的に共有ツリーと重複しているネットワーク

会議アプリケーションは、SPT と RPT の両方を使用できます (PIM-SM は同時使用をサポートしているため)。keep-alive パケットは低速送信されるので、RPT を使用できます。ソースは大量のデータを送信するので、SPT が適しています。

PIM-SM RPT の例を下の図 3 に示します。

この例では、ネットワーク構成が最短パスの例と同じでも、トラフィックのフローが異なります。ソース (1) からのマルチキャスト トラフィックは、すべてルーター 1 からルーター 3 へのインターフェイス I (1) つまり RP を通って送信されます。ソース (2) からは、ルーター 2 のインターフェイス I (2) を通って RP へ送信されます (ソースからこの中央ポイントへのパスが最短パス ルートです)。次に、RP はマルチキャスト グループに明示的に参加した受信者にデータを配布します。その際、全受信者が同じツリーを使用します。1 つのネットワークに複数の RP が存在することもありますが、各マルチキャスト グループの RP は 1 つだけです。

RP から受信者へのパスはすべて最短パスですが、ソースから受信者への最短パスは受信者から RP へのパスと同じではありません。そうすると、なぜ RPT ではなく SPT を使用しないのか、という当然の疑問が発生します。PIM-SM については、その理由が 2 つあります。まず、PIM-SM は、処理可能なトラフィック量であれば、最後のホップのルーター (受信者と直接接続されているルーター) が RPT を出て SPT に参加することを許可する手段があります。これは SPT スイッチと呼ばれるもので、後のセクションで詳しく説明します。2 つめの理由は、RPT を使用すると、ルーターはそれほど状態を維持する必要がないため、使用するメモリ量が少なくて済みます。

PIM-SM プロトコルの詳細

ここからは、PIM-SM プロトコルの各部分について、近隣ディスカバリから順に考察していきます。ここでも、RP がすでに選択されているものと見なします (選択方法は最後のセクションで説明します)。Hello および Join/Prune などのコントロール メッセージに関連して、PIM-SM Version 2 に言及しましたが、Version 2 メッセージは、プロトコル番号 103 として IP パケットにカプセル化されます。Version 1 メッセージは Internet Group Management Protocol (IGMP) パケットにカプセル化されます。IP カプセル化またはその他のコントロール メッセージのフォーマットを表示するには、このホワイト ペーパーの最後にある「PIM-SM コントロール メッセージ」セクションを参照してください。

Hello メッセージング

PIM ルーターは、定期的に、近隣 PIM ルーターを発見するための Hello メッセージを送信します。Hello メッセージはアドレス 224.0.0.13 (ALL-PIM-ROUTERS グループ) を使用するマルチキャストです。Holdtime フィールドでは、情報が有効な期間を指定します。ルーターは、Hello メッセージを受信しても受信確認の送信は行いません。また、DVMRP など他のプロトコルと異なり、Hello メッセージを受信しても、そのインターフェイスは自動的にはマルチキャスト トラフィックを転送するための送信インターフェイスには追加されません。PIM-SM は明示的な参加モデルを使用します。このため下位の受信者は、トラフィックがインターフェイスに転送される前にグループに参加する必要があります。

マルチキャスト パケットの転送

PIM-SIM ルーターは、マルチキャスト グループに明示的に参加している受信者へのすべてのインターフェイスにマルチキャスト トラフィックを転送します (受信者がグループに参加するには、所属している各グループの IGMP Host Membership Report を送ります。これらのメッセージはグループ アドレスに送信されます。メッセージの IP 生存時間 (TTL) は 1 で、ローカル サブネットワークに限られます)。ルーターは、パケットが転送される前に RPF チェックを行います。ルーターが実行する RPF チェックのタイプは、ツリーが RPT か SPT かによって異なります。RPT の場合の RPF チェックは、RP の IP アドレスを使用します。SPT の場合の RPF チェックは、ソースのアドレスを使用します。両方のケースを図 4 に示します。

ソース 162.10.4.1 からのマルチキャスト トラフィックは RPT を使用します。つまり、ソースは、マルチキャスト グループではなく RP にトラフィックを送ります (ルーターがこれを明示するには、(S, G) エントリの代わりに (*, G) エントリを使用します)。このトラフィックを送信する前に、ルーター 1 はユニキャスト ルーティング テーブルをチェックし、RP からのパケットが正しいインターフェイスに到着しているかどうかを確認します。この場合は正しいインターフェイス I1 に到着しているので、パケットは転送されます。

ソース 162.10.4.2 からのマルチキャスト トラフィックは、SPT を使用します (ルーターがこれを明示するには、ソースに (S, G) エントリを使用します)。この場合、ルーターはソースの IP アドレスを使って RPF チェックを実行し、ユニキャスト ルーティング テーブルでソースからのトラフィックが正しいインターフェイスに到着していることを確認します。例では、正しいインターフェイスに到着しているので、トラフィックは転送されます。

正しいインターフェイスに到着したトラフィックは、すべての送信インターフェイス ("oif") に送られ、以下のいずれかの条件があてはまる場合に、そこから下位受信者に送信されます。

• 下位 PIM-SM ルーターがこのルーターへの参加を送信した。

• IGMP プロトコルで明示的にグループに参加した直接接続されている受信者がいる。

• インターフェイスがグループに参加するように手動で設定されている。

各 (*, G)、(S, G) エントリに、それぞれの oif リストがあります。

共有ツリーへの参加

すでに説明したとおり、ホストがマルチキャスト グループへの参加を希望する場合は、IGMP メッセージをホストの上位ルーターに送るので、ルーターはそのグループからのトラフィックを受信できるようになります。これを行うには、ルーターは RP に対して RPT への参加を希望することを通知する信号を送る必要があります。具体的には、PIM (*, G) Join メッセージを RP 方向にある上位の PIM 近隣ノードに送ります。Join メッセージはアドレス 224.0.0.13 (ALL-PIM-ROUTERS グループ) へ 1 ホップずつマルチキャストされます。これは、マルチアクセス ネットワークでは、すべての PIM 近隣ノードが参加を認識するけれども、実際に参加を実行するのは、指定された上位の PIM 近隣ノードのみであることを意味します (参加と同じメッセージを後で説明するプルーニングにも使います)。

PIM ルーターは下位ルーターから (*, G) Join を受信すると、マルチキャスト ルーティング テーブルにグループ G の (*, G) 状態があるかどうかをチェックします。状態がすでに存在する場合、Join メッセージがすでに共有ツリーに到着し、メッセージを仲介したインターフェイスが oif リストに入力されたことを示します。状態が存在しない場合は、(*, G) エントリが作成され、インターフェイスが oif リストに入力され、再度 Join メッセージが RP 宛てに送信されます。

最後のホップ ルーターから RP への (*, G) 状態が 1 度作成されると、G のマルチキャスト トラフィックがグループに参加したホストに到達します。このプロセスを下の図 5 に示します。

この例では、受信者は IGMP Host Membership メッセージをルーター 2 に送り、マルチキャスト グループ G への参加希望を示します。これがルーター 2 に接続されグループに参加した最初の受信者なので、ルーターに (*, G) 状態はありません。このためエントリが作成され、I4 が oif リストに追加され、Join メッセージが上位の近隣ノード、ルーター 1 に転送されます。ルーター 1 にも (*, G) 状態がないので、同じプロセスを繰り返し、また Join メッセージを RP 宛てに転送します。RP が Join メッセージを受信するまで、または (*, G) 状態を持つ上位ルーターがメッセージを受信するまで、このプロセスが続きます。どちらの場合も、結果として RPT が作成され、RP から受信者へ届けられます。はじめに受信者が IGMP メッセージを送信しないと、マルチキャストが開始されない点に注意してください。参加プロセスを開始するのは受信者です。

指定されたルーター
複数のルーターがマルチアクセス ネットワーク (イーサネットなど) に接続されている場合、そのうちの 1 つが選択されて、一定の時間、指定されたルーター (DR) としての役割を果たす必要があります。DR は Join/Prune メッセージを RP 宛てに送ります。DR を選択するには、ネットワーク上の各 PIM ルーターが受信した Hello メッセージを調べ、自分と近隣ノードとの IP アドレスを比較します。最も高いアドレスを持つルーターが DR になります。図 6 は、このプロセスを示しています。

この例では、ルーター 1 より高い IP を持つルーター 2 が DR になります。指定した時間内に DR から Hello メッセージを受信しなかった場合は、再度 DR 選択が実行され、最上位の IP アドレスを持つルーターが DR になります。

RP 登録

マルチキャスト トラフィックのソースは、必ずしもデータの送信先のグループに参加する必要はありません。最初のホップのルーター (DR) は、ソースからのトラフィック受信を、そのソースの (S, G) 状態を持たなくても開始できます。これは、マルチキャスト トラフィックがツリー上をどのように RP まで到達するかという情報はないことを意味します。ソースの DR が最初のマルチキャスト パケットを受信すると、それを Register メッセージにカプセル化し、そのグループの RP にユニキャストします。RP は各 Register メッセージを非カプセル化し、展開したデータ パケットを RPT 上の下位メンバに転送します (RP は、必要に応じてソースへの SPT を再度確立するため、(S, G) Join を DR に送り返すこともできます。通常、これはデータ レートがしきい値に達したときに実行されます)。

ソースから RP へのパスが確立すると、DR は、標準 IP マルチキャスト パケット、および Register メッセージにカプセル化した形で、RP へトラフィックを送り始めます。これは、RP が一時的にいくつかのパケットを 2 度受信することを意味します。RP が標準マルチキャスト パケットを検出すると、Register-Stop メッセージをルーター 1 に送ります。これは、レジスタ パケットの送信を中止する必要があることを意味します。

下の図 7 はレジスタ プロセスのしくみを示しています (ルーターには既存の状態がないことを前提とします)。

この図は、ソースがマルチキャスト データの転送を開始したところを示しています。ソースの DR であるルーター 1 は、(S, G) 状態を作成し、Register メッセージにカプセル化したパケットを RP にユニキャストします。RP はパケットを受信すると、Register メッセージからマルチキャスト データを抽出し、そのデータを必要とする受信者がいれば RPT に従って転送します。

SPT が確立されるまで、ルーター 1 は RP へのマルチキャスト データが入った Register メッセージをユニキャストし続けます。ツリーが確立すると、ルーター 1 は標準 IP マルチキャスト パケットとして送信したものと同じマルチキャスト トラフィックを SPT 上で転送し始めます。これは、RP が一時的にソースのデータを Register メッセージとして SPT を介して受信することを意味します。

Register-Stop メッセージ
RP が、Register メッセージと非カプセル化した IP パケットとしてソースからのトラフィックの受信を開始すると、Register-Stop メッセージを DR に送信します。これで DR に SPT 上のトラフィックを標準 IP マルチキャスト パケットとして受信したことが通知されます。DR はこのメッセージを受信すると、トラフィックを Register メッセージにカプセル化するのを中止します。図 8 は、このプロセスを示しています。

RP が Register-Stop メッセージを送信するもう 1 つのケースに、どの受信者もマルチキャスト グループに所属していない場合があります。ソースはメンバのいないグループへも転送を開始できます。RP はこれらのパケットを破棄し、Register-Stop メッセージを送り、DR に Register メッセージの送信を中止させます。

インターフェイスのプルーニング

RP が Prune メッセージを受信すると、Prune メッセージで示されたソースからのトラフィックの転送を中止します。プルーニングは、リーフ ルーター (受信者に直接接続されているルーター)、つまりここでは DR から発行されます。マルチキャスト グループの最後のメンバが DR に IGMP Version 2 Leave (離脱) メッセージ (または IGMP Version 1 では単にタイムアウト) を送ると、DR の IGMP 状態が削除され、インターフェイスがグループ G の (S, G) と (*, G) oif リストの両方から取り除かれます。oif リストにある (*, G) 状態の すべてのインターフェイスが削除されると、つまりルーターが G のメンバであるどのインターフェイスにも受信者を持たないと、Prune メッセージは上位の RP へ共有ツリーを通って送られます。

上位ルーターの oif リストも空の場合、メッセージは RP への転送を続けます。ルーターにまだ別のインターフェイス上の受信者の (*, G) 状態がある場合は、優先 Join メッセージを PIM 近隣ノードから受信しない限り、このインターフェイスも削除されます (RPT の代わりに SPT が使用された場合も、ブランチのプルーニングと同じプロセスが適用されます)。下の図 9 はプルーニング プロセスの例を示したものです。

この例では、リーフ ルーターであるルーター 2 が、受信者から IGMP Leave メッセージを受け取ります。メッセージを処理し、ほかにグループ メンバがいないので、(*, G) とすべての (S, G) oif リストから I4 を削除します。これで、ルーターの oif list は空になるので、I3 経由で、RP 宛て (*, G) Prune メッセージを RPTに送ります。

Prune メッセージはルーター 1 が受信します。これにより、I3 インターフェイスがマルチキャスト ルーティング テーブルの (*, G) エントリの oif リストから削除されます。排除が実行されるまでに待ち時間があることに注意してください。マルチアクセス ネットワークでは、優先 Join メッセージが近隣の PIM ノードから到着するかもしれないので、待つことが重要です。この場合、何も受信されなかったので、インターフェイスはプルーニングされます。

(*, G) oif リストが空になったので、(*, G) Prune は RP を通って RPT へ転送されます。このプロセスは、RP がメッセージを受信するか、プルーニングの結果 (*, G) oif リストが空ではないルーターが見つかるまで続きます。

Assert メッセージング

マルチアクセス ネットワークでは、ソースまたは RP へのパスが並列して複数存在すしるため、グループ メンバが複数のルーターから重複パケットを受信することがあります。この問題を回避するには、PIM-SM は Assert メッセージを使用して、指定した転送者を決定します。下の図 10 は、このような状況を表しています。

この例では、ルーター 1 (RP) が、近隣ルーターであるルーター 2 とルーター 3 にマルチキャスト トラフィックを転送します。これらのルーターは、LAN 上で交互にトラフィックを転送します。ルーター 3 が最初に転送すると仮定します。ルーター 2 は、このグループが oif リストに入っているインターフェイスからマルチキャスト パケットを受信します。次に、ルーター 2 はルーター 3 にパケットを転送します。これはルーター 3 も、発信インターフェイス上のデータを受信することを意味します。発信インターフェイス上に入ってくるパケットを受信すると、LAN 上のほかの PIM-SM 近隣ノードもグループにトラフィックを送信していることがルーターに警告されます。これは、グループ メンバが重複メッセージを受信することを意味します。

この問題を回避するために、ルーターは、トラフィックを転送するための単一のルーターを選択するための Assert メッセージを発信します。下位のルーターは、Assert メッセージをリッスンし、どのルーターが選択され、後続の Join メッセージをどこに送ればいいかを確認します。ここでは、ルーター 4 が最初 Join メッセージをルーター 2 に送り、ルーター 5 が最初 Join メッセージをルーター 3 に送るものとします。アサートの後、すべての Join メッセージが指定転送者になったルーター 2 またはルーター 3 に送られます。

Assert の獲得
すべてのルーターが同じユニキャスト プロトコルを実行している場合、最良のメトリックのルーターが Assert を獲得します。たとえば、すべてのルーターが RIP を使用している場合、最もホップ数の小さいルーターが選択されます。メトリックが同じ場合は、IP アドレスが最も大きいルーターが選択されます。

ルーターが異なるユニキャスト プロトコルを実行している場合はメトリックの比較ができません。たとえば、RIP はメトリックとしてホップ数を使用していますが、OSPF メトリックはインターフェイスの速度を使用します。この場合、メトリック優先順位の値により、トラフィックを転送するルーターとインターフェイスを排除するルーターを決定します。メトリックの優先順位は、ネットワークで実行しているユニキャスト プロトコルごとに設定できます。ルーターがあるグループの Assert メッセージを受け取ると、パケットにあるメトリックの優先順位の値とルーター自体の持つ値が比較されます。2 つの値が同じ場合、メトリックを比較すればトラフィックの転送に使用するルーターを決定できます。メトリックの優先順位が異なる場合は、最もメトリックの優先順位の低いものが選択されます。

SPT スイッチング

最後のホップのルーターに対して、グループのしきい値を超えたらルーターを RPT から SPT へ切り替えるように、トラフィックのしきい値 (キロビット単位) を設定できます。このしきい値に達すると、DR は (S, G) Join をパケットのソース宛てに送信します。これで、ソース S からルーターまでの SPT が確立します。SPT への切り替えとは、マルチキャスト トラフィックの配信に最短パスが使用されることを意味します。RP に対するソースの相対的位置によっては、このスイッチを使用するとネットワークの遅延期間を大幅に短縮できます。欠点は、ルーターに保持しなければならない状態が増加することです。

スイッチを使用するかどうかを決定するために、RPT へのグループ トラフィックの総計レートが指定した間隔で計算されます。通常、このレートを超えると、そのグループが次のパケットを受信したときにスイッチが使用されます (このしくみの実際の動きと、総計レートが計算される間隔は、プロトコルではなく、実装方法によります)。

RP の決定

PIM-SM Version 1 では、RP を決定する方法が 2 つありました。1 つは静的な方法で、1 つのグループまたはグループ セットに対して、RP のアドレスを各リーフ ルーターに設定する必要がありました。もう 1 つは動的方法で、Auto-RP と呼ばれます。

PIM-SM Version 2 は Version 1 とは異なり、ブートストラップ ルーター (BSR) を使用して Bootstrap メッセージを作成する方法のみを用います。これらのメッセージを使って必要ならば BSR を選択し、RP 情報を発します。メッセージは、各リンクの ALL-PIM-ROUTERS グループへマルチキャストされます。

1 つまたは複数のルーターを BSR の候補として指定できます。どのルーターを BSR にすべきか判断しにくい場合は、候補がアドバタイズをドメインに大量に送信します (RPF を使用すると、一斉送信のコストを抑えられます)。最も優先順位の高いルーターが選択されます。すべての優先順位が同じ場合は、IP アドレスが最も高い候補が BSR になります (この場合、ドメインとは、PIM-SM Version 2 と PIM マルチキャスト境界ルーター (PMBR) で定義した共通境界内で運用するように設定した互いに隣接する一連のルーターを意味します。簡単にいうと、PMBR は各 PIM ドメインを外部インターネットに接続します。詳細については、RFC 2362 を参照してください)。

RP 候補として設定されたルーターは、この情報を BSR にユニキャストします (ほとんどの場合、BSR の候補として設定されたルーターは RP としても設定されます)。RP 候補のアドバタイズには、アドバタイズ ルーターと、サービス対象となるマルチキャスト グループのアドレスが入っています。

BSR が定期的に作成する Bootstrap メッセージには、RP の候補セット (RP-Set)、および対応するグループ アドレスが入っています。Bootstrap メッセージは、1 ホップごとに配信され、ドメイン全体に行き渡ります。

ルーターは、BSR が作成した Bootstrap メッセージを受信し、保管します。DR が、直接接続されているホストの (または、そのホストからのデータ パケットの) IGMP からエントリを持たないグループに対するメンバシップ指定を取得すると、DR はハッシュ関数を使用して、そのグループ アドレスを、そのグループにサービスを提供できる RP 候補の 1 つにマッピングします。次に、DR は Join/Prune メッセージをその RP 宛てに送ります (または Register メッセージをユニキャストします)。

未解決の問題

公式にはまだ "試験段階" ですが、PIM-SM Version 2 はすでにマルチキャスト ルーティング プロトコルのデファクト スタンダードとみなされています。しかし、まだ未解決の問題がいくつかあります。最初に説明したとおり、これはルーター間プロトコルのため、このプロトコルをサポートするには、ネットワークのルーターをすべてアップグレードする必要があります。2 つめの問題は、RP 候補の数は、ドメインのサイズに比例して増えるので、このプロトコルをグローバルに拡大できない点です。RP への G マッピングでも BSR アナウンスが大量に発生するため、スケーリングの問題が起こります。もう 1 つ、RP の場所の問題があります。世界には数多くの ISP がありますが、どの ISP も顧客間でのマルチキャスト サービスに、ほかの ISP のドメインにある RP を使用するのを嫌います。

PIM-SM コントロール メッセージ

このセクションでは、PIM-SM のエンコードされたアドレス フィールドとコントロール メッセージの形式について説明します。また、コントロール メッセージが IP パケット内でカプセル化される方法およびすべての PIM メッセージの標準ヘッダーについても示します。これらのメッセージのその他の詳しい説明については、RFC 2362 を参照してください。

ここでは、以下の項目について説明します。

• PIM-SM コントロール メッセージのカプセル化

• PIM-SM パケット ヘッダー

• エンコードされたユニキャスト アドレス フィールド

• エンコードされたグループ アドレス フィールド

• エンコードされたソース アドレス フィールド

• Assert メッセージ

• Bootstrap メッセージ

• RP 候補アドバタイズ

• Hello メッセージ

• Join/Prune メッセージ

• Register メッセージ

• Register-Stop メッセージ

PIM Control-Message のカプセル化

図 11 は、PIM-SM コントロール メッセージの IP パケット内での配置を示しています。

PIM-SM Version 2 メッセージは、プロトコル番号を 103 として、IP パケットにカプセル化されます。

PIM-SM パケット ヘッダー

図 12 は、PIM-SM Version 2 パケットのヘッダーを示しています。

ヘッダー フィールドの値は以下のとおりです。

• Ver は、PIM のバージョン番号です。Version 2 の場合、値は 2 になります。

• Type は、特定のコントロール メッセージに関連付けられた値です (下の表 1 参照)。

• Reserved は、0 として転送され、受信時には無視されます。

• Checksum は、PIM メッセージ全体 (Register メッセージのデータ部分を除く) の和の 16 ビットの補数です。

コントロール メッセージは種類により異なるタイプ値を持ちます。表 1 を参照してください。

表 1 PIM-SM Version 2 メッセージタイプ

タイプ	説明
0	Hello
1	Register
2	Register-Stop
3	Join/Prune
4	Bootstrap
5	Assert
8	RP 候補アドバタイズ

エンコードされたユニキャスト アドレス

エンコードされたユニキャスト アドレス フィールドのフォーマットについては下の図 13 を参照してください。

サブフィールドの値は以下のとおりです。

• Address Family は、ユニキャスト アドレスが所属するファミリです。Address Family 番号と関連値は、下の表 2 のとおりです。

• Encoding Type は、特定のアドレス ファミリ内で使用されるエンコードのタイプです。このフィールド用に予約されている値 0 は、アドレス ファミリのネイティブ エンコーディングを表します。

• Unicast Address は、Address Family と Encoding Type フィールドで指定したユニキャスト アドレスです。

表 2 は、IP Version 4 と 6 のアドレス ファミリ番号を表します。ほかの番号も割り当てられていますが、ほとんど使用されません。ICANN (Internet Corporation for Assigned Names and Numbers) が割り当てた一覧は、http://www.icann.org/ から入手できます。

表 2 IP Version 4 と 6 のアドレス番号

番号	説明
0	予約済み
1	IP Version 4
2	IP Version 6

エンコードされたグループ アドレス

エンコードされたグループ アドレス フィールドのフォーマットについては下の図 14 を参照してください。

サブフィールドの値は以下のとおりです。

• Address Family と Encoding Type については、上記の「エンコードされたユニキャスト アドレス」セクションの定義を参照してください。

• Reserved は 0 として転送され、受信時には無視されます。

• Mask Length は、アドレスを表すマスクとして使用される左揃えした連続するビットです。マスク長は、指定したアドレス ファミリとエンコード タイプのアドレス ビット長と同じか、それ以下でなければなりません。PIM-SM Version 2 では、IP Version 4 のネイティブ エンコーディング用に、このフィールドを 32 に設定することをお勧めします。

• Group Multicast Address は、マルチキャスト グループのアドレスです。

エンコードされたソース アドレス

エンコードされたソース アドレス フィールドのフォーマットについては図 15 を参照してください。

サブフィールドの値は以下のとおりです。

• Address Family、Encoding Type、および Reserved については、上記の「エンコードされたユニキャスト アドレス」と「エンコードされたグループ アドレス」セクションの定義を参照してください。

• S フィールドは Sparse ビットです。PIM-SM の場合は 1 に設定します。これは、PIM Version 1 との互換性を保つために使用します。

• WC ビットはワイルドカード ビットです。1 にセットすると、(*, G) または (*, *, RP) エントリに参加または排除が適用されます。値が 0 の場合は、(S, G) エントリに JOIN または PRUNE が適用されます。S はソース アドレスです。Join または Prune を RP に送信するには、このビットを 1 に設定する必要があります((*, *, RP) エントリにリストされている RP へのパケット マップで、より限定的なエントリ [(S, G) または (*, G) など] と宛先グループ アドレスがない場合、データ パケットは (*, *, RP) エントリと一致します。この特別なエントリの詳細、および PIM-SM とデンス モード プロトコル間の相互運用性との関係については、RFC 2362 を参照してください)。

• R ビットは RPT ビットです。1 にセットすると、(S, G) の情報が RP に送信されます。0 にセットすると、情報は S (ソース アドレス) に送信されます。

• Mask Length については、上記の「エンコードされたグループ アドレス」セクションの定義を参照してください。

Assert メッセージ

Assert メッセージのフォーマットについては、図 16 を参照してください。

フィールドの値は以下のとおりです。

• Version、Type、Reserved、および Checksum については、上記の「PIM-SM パケット ヘッダー」セクションを参照してください。

• Encoded Group Address は、パケットのアドレス指定先で Assert をトリガしたグループ アドレスです。フォーマットは、上記の「エンコードされたグループ アドレス」セクションの定義を参照してください。

• Encoded Unicast Source Address は、Assert をトリガしたマルチキャスト パケットに含まれるソース アドレスです。フォーマットは、上記の「エンコードされたユニキャスト アドレス」セクションの定義を参照してください。

• R は RPT ビットです。これは 1 ビット値です。Assert をトリガしたマルチキャスト パケットが、RPT ツリーを通って転送される場合、RPT ビットは 1 です。パケットが SPT ツリーを転送される場合の RPT ビットは 0 です。

• Metric Preference は、ホスト アドレスへのルートを決めるユニキャスト ルーティング プロトコルに関連する参照値です。

• Metric は、ユニキャスト ルーティング テーブルのメトリックです。ユニキャスト ルーティング プロトコルに適した単位となります。

Bootstrap メッセージ

Bootstrap メッセージは、オリジナルのメッセージが最大パケット サイズを超えると、"意味上のフラグメント" に分割されます。下の図 17 は、1 つのフラグメントのフォーマットを示しています。

フィールドの値は以下のとおりです。

• Version、Type、Reserved、および Checksum については、上記の「PIM-SM パケット ヘッダー」セクションを参照してください。

• Fragment Tag は、異なる Bootstrap メッセージに属するフラグメントと区別するためにランダムに生成される番号です。同じ Bootstrap メッセージに属すフラグメントには、同じフラグメント タグがつきます。

• Hash Mask Length は、ハッシュ関数で使用するマスク長 (ビット) です。IP Version 4 では、値 30 とすることをお勧めします。IP Version 6 の推奨値は 126 です。

• BSR Priority は、含まれる BSR の BSR 優先値です。このフィールドは、BSR アドレスの比較では、上位バイトとみなされます。

• Encoded Unicast BSR Address は、ドメインのブートストラップ ルーター アドレスです。このフォーマットは、Encoded Unicast Address フィールド フォーマットと同じです。

• Encoded Group Address は、RP 候補に関連付けられているグループ プレフィックスです (アドレスとマスク)。このフォーマットについては、上記の「エンコードされたグループ アドレス」セクションの定義を参照してください。

• RP Count 1Un は、対応するグループ プレフィックスの Bootstrap メッセージ全体の中に含まれる RP 候補アドレスの数です。

• Fragment RP Count 1Um は、対応するグループ プレフィックスの Bootstrap メッセージのこのフラグメントに含まれる RP 候補アドレスの数です。

• Encoded Unicast RP Address 1Um は、対応するグループ プレフィックスの RP 候補のアドレスです。フォーマットは、上記の「エンコードされたユニキャスト アドレス」セクションの定義を参照してください。

• RP1Um Holdtime は、対応する RP の保留時間です。このフィールドは、BSR に格納されている関連 RP の Holdtime フィールドからコピーされます。

• RP1Um Priority は、対応する RP と Encoded Group Address の優先順位です。このフィールドは、RP 候補のアドバタイズを受信するとき、BSR に格納されている Priority フィールドからコピーされます。最高位は 0 です (Priority フィールドの値が小さいほど、優先順位が高くなります)。この優先順位は、エンコードされたグループ アドレスごとの RP 単位のものです。

RP 候補メッセージ

RP 候補メッセージのフォーマットについては、図 18 を参照してください。

フィールドの値は以下のとおりです。

• Version、Type、Reserved、および Checksum については、上記の「PIM-SM パケット ヘッダー」セクションの定義を参照してください。

• Prefix Count は、メッセージに含まれるエンコードされたグループ アドレスの数です。値 0 は、すべてのマルチキャスト グループが入っていることを表します。

• Priority は、そのグループ アドレスに対応する RP 候補の優先順位です。最高位は 0 です。つまり、値が低いほど、優先順位が高くなります。BSR は、RP アドレスと対応するエンコードされたグループ アドレスとともに、この値を格納します。

• Holdtime は、アドバタイズが有効な期間です。

• Encoded Unicast RP Address は、RP 候補としてアドバタイズするインターフェイスのアドレスです。

• Encoded Group Address 1Un は、RP 候補がアドバタイズする対象のグループ アドレスです。

Hello メッセージ

Hello メッセージのフォーマットについては、図 19 を参照してください。

フィールドの値は以下のとおりです。

• Ver、Type、Reserved、および Checksum については、上記の「PIM-SM パケット ヘッダー」セクションの定義を参照してください。

• Option Type は、オプションの値 フィールドのオプション値です。

• Option Length は、オプションの値 フィールド長 (バイト) です。

• Option Value は、オプションの値を示す可変長フイールドです。

表 3 は、各 Option フィールドの値を示しています。

表 3 各 Option フィールドの値

Option Type	Option Length	Option Value
1	2	Holdtime
2 ～ 16	予約済み	予約済み

表 4 は、Holdtime (保留時間) パラメータの値を示しています。

表 4 Holdtime パラメータ値

値	説明
0xFFFF	タイムアウトなし
0	即時タイムアウト
その他の値	近隣ノードのタイムアウト値

タイムアウト値 0xFFFF とは、近隣ノードが期限切れにならないことを意味します。この値は、Hello メッセージが定期的に送信されないようにします。これは、ISDN などで使用する有料接続の場合に便利です。定期的 Hello メッセージを行うと、ユーザー データ トラフィックがない場合でも、リンクをアクティブに保持するので、顧客への課金が継続してしまいます。

Join/Prune メッセージ

Join/Prune メッセージのフォーマットについては、図 20 を参照してください。

フィールドの値は以下のとおりです。

• Version、Type、Reserved、および Checksum については、上記の「PIM-SM パケット ヘッダー」セクションの定義を参照してください。

• Encoded Unicast Upstream Neighbor Address は、上位近隣ノード (RPF インターフェイス経由) のアドレスです。フォーマットは、上記の「エンコードされたユニキャスト アドレス」セクションの定義を参照してください。

• Holdtime は、受信者が Join/Prune 状態を保持しなければならない時間 (秒単位) です。Holdtime を 0xFFFF にセットすると、このメッセージの受信者の oif がタイムアウトになることはありません。この値は、ISDN 回線で使用すれば、定期的な Join/Prune メッセージにより回線の接続を維持する必要がありません。Holdtime を 0 にセットすると、情報はすぐにタイムアウトになります。

• Number of Groups は、メッセージに入っているマルチキャスト グループ セットの数です。

• Encoded Multicast Group Address は、マルチキャスト グループのアドレスです。フォーマットは、上記の「エンコードされたグループ アドレス」セクションの定義を参照してください。

• Number of Joined Sources は、リストされている、対象となるグループの join-source アドレス数です。

• Encoded Join Source Address 1...n は、マルチキャスト パケットが正しいインターフェイスで受信されていれば、それを送信側ルーターが転送する対象のソース リストです。このフォーマットについては、上記の「エンコードされたソース アドレス」セクションの定義を参照してください。

• Number of Pruned Sources は、リストされている、対象となるグループの prune-source アドレス数です。

• Encoded Prune Source Address 1...n は、プルーニングする対象のソースが入ったリストです。

Register メッセージ

Register メッセージのフォーマットについては、下の図 21 を参照してください。

フィールドの値は以下のとおりです。

• Ver、Type、Reserved、および Checksum については、上記の「PIM-SM パケット ヘッダー」セクションの定義を参照してください。

• B は Border ビットです。ルーターが、ルーターが直接接続されているソースの DR の場合は、B ビットを 0 に設定します。ルーターが、直接接続されているクラウド内のソースの PMBR の場合は、B ビットを 1 に設定します。

• N は Null-Register ビットです。ローカルの Register-Suppression タイマが期限切れになる前に RP を探査する DR は、このビットを 1 に設定します。それ以外は 0 に設定します。

• Multicast Data Packet は、ソースが送信したオリジナルのパケットです。

Register-Stop メッセージ

Register-Stop メッセージのフォーマットについては、図 22 を参照してください。

フィールドの値は以下のとおりです。

• Ver、Type、Reserved、および Checksum については、上記の「PIM-SM パケット ヘッダー」セクションの定義を参照してください。

• Encoded Group Address については、上記の「エンコードされたグループ アドレス」セクションを参照してください。

• Encoded Unicast Address は、Register メッセージにカプセル化されたマルチキャスト パケットに含まれるソース アドレスです。Encoded Unicast Source Address は Encoded Source Address (上記参照) と同じフォーマットを使用します。

まとめ

現在、PIM-SM はマルチキャスト ルーティング プロトコルのデファクト スタンダードとなっています。これは、マルチキャスト グループがまばらに散在している WAN で効率的な接続を行うためのプロトコルです。従来の、受信者開始型メンバシップの IP マルチキャスト モデルを維持しつつ、共有ツリーと最短パス ツリーの両方をサポートしています。PIM-SM は特定のユニキャスト ルーティング プロトコルには依存しません。また、PIM-SM はルーター間プロトコルのため、このプロトコルをサポートするには、ネットワークのルーターをすべてアップグレードして、PIM-SIM Version 2 をサポートする必要があります。

追加情報

Windows® 2000 Server の最新情報は、http://www.microsoft.com/japan/windows2000/default.mspxをご確認ください。

© 1999 Microsoft Corporation. All rights reserved.

本書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。

本書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証を致しません。

Microsoft、Windows、Windows NT は米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

その他、記載されている会社名および製品名は、各社の商標および登録商標です。

Microsoft Corporation. One Microsoft Way. Redmond, WA 98052-6399 USA

1. S. Deering, D. Estrin, D. Farinacci, V. Jacobsen, C. Liu, and L.Wei、「The PIM Architecture for Wide-Area Multicast Routing」、『IEEE/ACM Transactions on Networking』4.2 (April 1996): 153
2. Yogen Dalal、『Broadcast Protocols in Packet Switched Computer Networks』 (Digital Systems Laboratory, Dept. of Electrical Engineering, Stanford University, 1977)