PIM Sparse Mode

はじめに

これまでIP Multicastについてお話してきました。 今月からはPIM Sparse Modeを取り上げます。 参考となる過去の記事:

  • The Protocols of IP Multicast
  • PIM Dense Mode

Sparse Versus Dense Mode

PIM Dense Modeは、ほとんどの場所でマルチキャストが望まれるときに使われます(原則的に)。 したがって、初期のマルチキャストパケットは、マルチキャストのフィードを必要としない場所へのトラフィックをカットするプルーニングで、どこにでもフラッディングされます。 最近まで、PIM Dense Modeは3分ごとに定期的に再フラッディングが発生していましたが、12.1(5)Tでは、PIM Dense Mode State Refresh機能により、これが緩和されました。 この機能により、PIM Dense Modeは間違いなくマルチキャストの簡易実装に適しています。 特に、PIM Sparse Mode の追加制御が必要なく、時折の「偶然の」フラッディングがあまり有害ではない場合です。

PIM Sparse Mode では、ルーターが PIM Join メッセージでマルチキャストのフィードを要求しなければならない、明示的要求方式が使用されます。 PIMスパースモードは、より正確な制御が必要な場合、特に帯域幅と比較して大量のIPマルチキャストトラフィックがある場合に表示されます。 PIMスパースモードは、パケットが必要なところにしか行かず、必要なときにしかルータに状態を作らないので、むしろうまくスケールします。 このため、インターネット実験プロトコルとして記述されています。

この余分な制御の代償として、穏やかな複雑さが追加されました。 PIM スパースモードでは、ランデブーポイント (RP) と呼ばれる特別なルーターを使用して、フローソースまたはマルチキャストツリーを、希望する受信者の隣にあるルーターに接続します。 後述するように、RP は通常一時的にしか使用されません。

異なるマルチキャスト グループに対して異なる RP が存在することがあり、これは負荷を分散するための 1 つの方法です。 通常、マルチキャストグループごとに1つのRPが存在します。 RPの冗長化は高度なトピックであり、少し深い専門知識が必要です。

PIMのJoinメッセージは、ユニキャストルーティングに基づいて、ソースに向けて(またはPIM-SMの場合はRPに向けて)送信されることを思い出してください。 Joinメッセージは事実上 “ここにマルチキャストのコピーが必要だ “と言っています。 Joinメッセージは、「こっちのマルチキャストのコピーが必要だ」と言うもので、Joinの送信者と間にあるルーターを既存のマルチキャストツリーに接続し、必要ならJoinのターゲットに戻る。 Pruneメッセージは事実上、「こっちのマルチキャストはもう必要ない」と言う。 Pruneを受信したルーターは、マルチキャストフローを必要とする他のインターフェースがあるかどうかを確認し、ない場合はそれ自身のPruneメッセージを送信する。 1つの高度な技術として、マルチキャストのためだけにユニキャストルーティング情報の別個の、おそらく異なるコピーを手配することがあります。 これにより、Joinメッセージの「ステアリング」が可能になる。

基本ランデブーポイント(RP)

ここまで、PIM-SMが送信元と受信元を接続するためにランデブーポイント(RP)を使用することを見てきました。 RPはマルチキャストグループごとに1つだけ存在でき、最も簡単な実装では、すべてのマルチキャストグループに1つのRPを使用します。 送信元は、受信者が存在する前に送信を開始すると仮定しましょう。

では、マルチキャストの送信元が送信を開始します。 すでに述べたように、IPマルチキャストには送信元を登録するためのプロトコルなどはありません。 送信元が送信し、近隣のルータが正しい処理を行うかどうかは、そのルータに任されています。 PIM-SMでは、近隣のルータはRPについて知っています。 (近隣のルーターはマルチキャストデータをユニキャストの登録メッセージでカプセル化してRPに転送します。 通常のルーティングはレジスタをRPに届けます。 RPはマルチキャストのカプセル化を解除し、コピーを共有ツリー(送信元が送信を開始する前に加入していた受信機があれば、事前に構築されている)に転送する。 受信者(Shared Tree状態の送信インターフェース)がある場合、RPはソースに向けてPIM Joinを送り返す。 これにより、SourceとRPはSource Treeである(S, G) Shortest Path Tree(SPT)で接続される。 RPはこのSPTに沿ってマルチキャストを受信すると、Register-Stopを送信してSourceのそばにあるルーターにRegisterパケットの送信を停止するように指示します。 この動作の理由は、すでにレシーバが存在する場合は、マルチキャストパケットを損失しないためです。

ちなみに、レシーバが存在しない場合は、Register-Stopメッセージが送信されます。

ちなみに,受信者がいない場合はRegister-Stopメッセージを送信し,その後,受信者が現れたら(IGMP to neighbor router,PIM Join from neighbor router back to RP),そのときにRPからSourceにPIM Joinを送信します。 図の受信機はルータDにIGMP Reportを送信し、ルータDはRPに向けてPIM Joinを送信します。 他にも受信者がいるため、RPはすでにソースツリー(青色で表示)に参加し、マルチキャストフローを受信しています。

さて、ソースツリー(最短パスツリー、SPT)に沿ってソースからRPへ、そして共有ツリーに沿ってRPから受信者へパケットが送られるようになりました。 すべてのソースからの)アグリゲート(*、G)パケットビットレートがKbpsの閾値を超えると、受信者に最も近いルーターがソースツリーに参加しようとするトリガーになります。 これはマルチキャストフローのソースに向けてJoinを送信する。 先に送ったJoinはRPに向けたものであったことに注意。 ソースに向けたJoinは、ソースツリーにすでに存在するルーターに遭遇するまで、ソースに向けてルーターごとに進む。 これによって、受信者の近くにあるルーターがソースツリーに追加される。 そのツリーに沿って実際にパケットを受信すると、RPに向けてPruneが送信される。 このプロセスでは、RP が途中で切り捨てられるため、事実上、「ありがとう、でも今は小売ではなく卸売でマルチキャストを入手しています」ということになります。 左上の赤い矢印は、ソースに向かうジョインを示しています。 これは、ソースツリーに沿ってパケットが転送される、一番上の青いフローを進行させます。 右下の赤い矢印は、共有ツリーフローが不要になったため、削除されたものです(緑の破線で示されています)。 ソース ツリーのパケットは、より直接的な経路で受信側に到着し、一般に低遅延であることに注意してください。 これは設定可能です。 デフォルトは0Kbpsで、1つのパケットを受信すると、ソースツリーに切り替わります。 特定のマルチキャストグループに多くのソースがある場合 (電話会議やVoIPを想定)、それぞれのソースに (S, G) ソースツリーのエントリが存在することになります。 もし、しきい値を「起動しない」に設定すると、すべてのパケットはRPを経由し(電話会議のブリッジのようなもの)、(*, G)共有ツリーのみを使用するようになります。 また、閾値はスイッチバックだけでなく、スイッチオーバーにも使用されます。 低レートの (S, G) ソースツリーは Shared Tree にスイッチバックされます。 トラフィック量は1分ごとにチェックされます。

受信者が参加を希望し、その近隣ルータがSPT(Source Tree)上にある場合、発信インターフェースのShared TreeエントリはSource Treeエントリにコピーされ、RPにトラフィックを送り、SPT上のルータに「戻る」必要がないように保護します。

ところで、あなたは、ここにRPがある意味は何なのだろうかと思っているかもしれません。

Shared Versus Source Trees

PIM Sparse Mode (PIM-SM) では、Shared Trees (RP を通過) と Source Trees (送信元から受信先への「最短」経路を効率的に直接配送) の両方を使用することが可能です。 一般的には、両方を使うことができます。

PIM-SMルータがマルチキャストパケットを受信すると、その特定の送信元アドレスとマルチキャストグループ (宛先) アドレスについてソースツリーをチェックします。 エントリが存在しない場合,そのマルチキャストグループのShared Tree(*,G)エントリを確認します。 両方のツリーのエントリが存在する場合、受信インターフェースはどちらのツリーを使用するかをルーターに伝えます。

少なくとも 1 つのアクティブな受信機を持つマルチキャストフローでは、ソースと RP の間のパスはソースツリーの一部となります。 (「間のパス」はここでは少し曖昧であることに注意してください。)

Shared Tree エントリは、RP をいくつかの受信者に接続します。 (*, G) Shared TreeのRPFインタフェースは,マルチキャストグループのソースではなくRPの方向のインタフェースになります。 そのため,(S, G) Source Treeと(*, G) Shared TreeでRPFインタフェースが異なる可能性があります。

Shared Tree (*, G) エントリはRPへの参加を受信したインタフェース,またはグループメンバーが直接接続しているインタフェース(設定済みまたはIGMP受信)を示しています。 Source Tree (S, G)のエントリは,JoinまたはPruneまたはRegisterを受信したインタフェースを示します。

Configuring PIM Sparse Mode

The basic part of what you need is:

ip multicast-routing

interface ethernet 0
ip address 10.1.1.1 255.255.255.255.0
ip pim sparse-mode
interface ethernet 1
ip address 10.1.2.1 255.255.0
ip pim sparse-mode

また、すべてのグループまたは選択したグループのRPを各ルーターに教える必要があります(アクセスリストを使用してどのグループに対してのRPか指定します)。

ip pim rp-address 1.2.3.4

RP を管理する他のオプションについては、次回の記事で見ていきます。 また、より高度な IP マルチキャストのトピックにも軽く触れる予定です。

コメントを残す

メールアドレスが公開されることはありません。