要約

  • RFC 3353 は、トラフィック駆動のマルチキャスト LSP に起動上の循環があることを示した。下流はパケットを見て枝を要求したいが、L2 の枝がなければそのパケットを受け取れない。
  • L2/L3 混在転送、または上流側から始めるラベル交換が循環を解く。ただし、パケット観測、ルーティング状態、ラベル信号、複製設定、受信確認は別々の証拠である。

すでに一つの受信点へ流れているマルチキャストを考える。別の下流 LSR の先に新しい受信点が現れた。無通信のグループまでラベル状態を持ちたくないため、実装はデータが到着したときだけ新しい LSP を作ろうとする。

ところが、新しい下流 LSR が L2 でデータを観測するには、その LSR までの LSP が必要である。LSP を作る契機がデータであり、データを運ぶ条件が LSP なら、双方が相手を待つ。RFC 3353 はこれを chicken-and-egg problem と呼んだ。自動化という一語では、最初に誰が何を観測し、誰が設定を始めるかは決まらない。

RFC 3353 は 2002 年 8 月の Informational 文書で、特定のプロトコルを標準化したものではない。IP マルチキャストの木を MPLS に載せるとき、どの特徴が衝突するかを分類した。ユニキャストは一つの宛先方向へ進むが、マルチキャストは一つの入力から複数の出力へ分かれる。受信者の参加と離脱に応じて木も変わる。

共有木の状態は (*,G)、送信元木は (S,G) で表される。共有木はグループごとの状態をまとめてラベル数を減らせる一方、multipoint-to-multipoint の動作や合流が必要になる。送信元木は合流を単純化できても、送信元とグループの組ごとに状態が増える。RFC は一つの木を普遍的な正解にしなかった。

Flood-and-Prune 型では時間変化がさらに大きい。最初のデータで状態を作り、不要な枝を刈り、無通信タイマーで消す。そのたびに L2 の木を追従させれば信号量とラベル消費が増える。先にすべて作れば、使われない木が資源を占める。データが来るまで待てば、最初のパケットが制御手順の一部になる。

文書は LSP の起動契機を三つに分けた。request-driven は Join、Prune、予約メッセージなどを利用する。topology-driven はマルチキャスト経路表の木を、通信がなくても L2 に写す。traffic-driven は実データが来た木だけを作る。これは単なる実装方式の違いではない。制御プロトコルへの結合、休眠時の状態、初動時間のどこに費用を置くかという選択である。

循環を解く第一の方法は、上流 LSR が先に動くことだった。すでにデータを見ている上流が、下流へラベルを要求するか、上流割当てのラベルを通知する。これなら観測点と起動点が同じ側にある。RFC 3353 の組合せ表が、traffic-driven と label distribution の向きを条件付きで結んだ理由である。

もう一つが mixed L2/L3 forwarding である。同じノードが、既存の枝は L2 でラベル交換し、新しい枝だけを一時的に L3 で送る。最初のパケットは IP 経路で届き、その観測からラベル交換とハードウェア設定を始められる。確認後に枝を L2 へ移せばよい。二層の併存は中途半端な設計ではなく、切替えを戻せるようにする起動面だった。

ただし、L3 は L2 がすでに処理する出力インターフェースを除外しなければならない。そうしないと同じパケットが重複する。混在転送を使えないノードでは、下流側がデータを見てからラベルを要求する方式は成立しない。RFC の表では、その組合せに混在転送という条件が付く。設定画面で二つを独立項目として見せるだけでは、到着不能な起動条件を作り得る。

ここから証拠の階層が見える。上流でパケットを一つ見たことは、その地点への一回の到達を示す。MFC の cache miss はローカル項目がなかったことを示す。MRT の行は制御面のローカル判断である。ラベル要求と応答は信号処理の進行を示す。転送 ASIC のエントリーは一台での設定を示す。どれも、全受信点への配信を単独では証明しない。

Unix の Multicast Forwarding Cache を用いた例は、実行場所が変わると観測の意味も変わることを示す。最初のパケットがカーネルで cache miss を起こし、マルチキャストデーモンが経路を返す。その後 L2 がパケットを交換すると、L3 は通信を直接見なくなる。L3 のカウンターだけで無通信タイマーを動かせば、実際には流れている項目が失効する。

そこで RFC は L2 の測定値から L3 カウンターを更新する案を挙げた。必要な調整だが、カウンターは別層からの投影になる。「L3 が何個転送したか」ではなく、「L2 の対応枝が活動を報告したか」を含む。測定元、時間窓、リセット時点、対象エントリーの結び付きを保存しなければ、数字は増えても監査できない。

PIM-SM の共有木から送信元木への移行も、二重状態を生む。(*,G) と (S,G) が同時に存在し、一時的に同じ送信元のパケットが二つの入力から届くことがある。L3 は送信元固有状態に基づいて不適切なコピーを止められる。L2 だけなら短時間の重複を許すか、送信元別ラベルを追加するか、処理を L3 に戻す必要がある。ラベルは意味判断を代行しない。

カプセル化では境界がさらに明確になる。共有木の送信元は根へトンネルし、根でデカプセル化されることがある。これらは L3 処理であり、その地点を何もなかったかのように一つの L2 LSP が貫通することはできない。トンネル自体や他の枝を MPLS に載せることはできても、解釈点は残る。

ラベル情報をマルチキャスト制御メッセージに同乗させる方法も、同期の代償を持つ。経路とラベルを近い時刻に配布でき、別メッセージを減らせる。その一方、各マルチキャストプロトコルに拡張が必要になり、選べない起動方式が生じ、LDP の TCP による信頼性を周期的な soft state に置き換える場合がある。通知がそろっても、データ面複製の受領証にはならない。

共有リンクでは権限が一段複雑になる。一つのマルチキャスト流に複数の下流 LSR があり、同じラベルを受け入れなければならない。全員が割当てを記憶する、ラベル範囲を分ける、割当て役を選ぶ、といった方法が検討された。上流割当ては木に一つの上流しかない点を利用できるが、経路変化で上流が替わる。下流割当てはその変化に強い一方、複数下流の提案を調停しなければならない。

後続文書は木の部品を明示した。RFC 4461 は P2MP TE LSP の枝分かれ、葉の追加削除、障害報告、拡張性を要件化した。RFC 4875 は複数の source-to-leaf sub-LSP を branch LSR で組み合わせる RSVP-TE 手順を定めた。そして重要な限定を置いた。信号状態が枝分かれしても、データ面が同じ場所で複製するとは限らない。制御木は配送記録ではない。

RFC 5332 は 2002 年の想定を一つ訂正した。RFC 3032 にあった MPLS ユニキャスト用とマルチキャスト用のリンク層 codepoint の使い分けは配備されなかったため、後者は共有媒体での上流割当てラベルを示す意味へ変更された。初期文書の設計空間と、後に確認された配備事実は分けて読む必要がある。

RFC 6513 の MVPN でも、マルチキャスト配布木とユニキャストトンネルによる ingress replication の間に、最適性と規模の交換が残った。木を共有すれば制御状態が増え、入口で複製すれば帯域を余分に使う。複製場所を変えても、その費用は消えない。

RFC 3353 の歴史的価値は、完全自動のように見える図の手前を残したことにある。ラベル枝の前には、最初のパケット、暫定的な L3 経路、または上流の決定があった。信号の後にも、設定、複製、受信確認が残る。順序を保存して初めて、システムが何を実行したかを説明できる。

出典