要約

  • IGMPv3とMLDv2は隣接ルータへグループ参加と送信元フィルタを伝えるが、エンドツーエンドの受信確認ではない。
  • PIM-SMはDR、RPF情報、RPまたはSSMを使い、共有木や送信元木を別途構築しなければならない。
  • 配信判定には正しい(S,G)、ツリー状態、転送カウンタ、受信アプリが見たパケットを結び付ける必要がある。

Joinは見えるのに画面は黒い

正しいアクセス回線から新しいIGMPv3報告が届き、グループもタイマーも正常に見える。それでも映像は出ない。この二つは両立する。報告は端末が受信を要求したことを示すだけで、期待する送信元が送信中か、PIM Joinが上流へ届いたか、RPFが正しい隣接を選んだか、複製が転送面に入ったかまでは示さない。

リスナー状態は最初のルータまで

RFC 3376のIGMPv3は、IPv4端末が隣接するマルチキャストルータへ所属グループを通知する仕組みである。INCLUDEは列挙した送信元だけを、EXCLUDEは列挙した送信元以外を要求する。状態はソケット、インターフェース、グループ、モード、送信元一覧の組合せで決まる。

インターフェースの集約状態と各ソケットの状態は同一ではない。パケットがインターフェースに到達しても、ポートやアプリ側の条件で特定ソケットへ渡らない場合がある。RFC 3810のMLDv2はIPv6で同様の役割を担う。

PIMは別の状態連鎖を作る

RFC 7761では、指定ルータが受信意思を受け、RPまたは送信元へPIM Joinをホップごとに送る。そこで(*,G)、(S,G)、(S,G,rpt)状態が形成される。MRIBは逆方向の情報を与え、TIBは配信木を保持し、実装は通常、実転送向けのMFIBを生成する。

RP対応の誤り、RPF隣接の変化、Joinの期限切れ、共有木から最短経路木への移行、PIM Assert前の重複など、判定を変える要素は多い。IGMP/MLD報告が残っていても、これらの成功は保証されない。

RFC 4607のSSMでは、対象は単なるグループGではなく特定の送信元Sとの組(S,G)である。Gだけが正常に見える監視は、送信元の不一致を隠し得る。

参照資料