要約

  • MARSが管理したのは、レイヤー3のグループとクラスタ内ATM端点の対応表であり、RFCはMARSが実際のマルチキャスト転送に関与しないと明記した。
  • グループのメンバーではない送信者も、完全なMARS_MULTI応答を取得してから自分のVCを構築できた。MCSが返された場合、その先の配信は送信者から見えなかった。
  • 登録、完全な応答、追加済みleaf、連続したCSN、送信呼び出しの成功は別々の状態を示すだけで、稼働、到達、本人性、権限、QoS、安全性を単独では証明しない。

RFC 2022の設計を最も短く表すのは、「MARSは実際のレイヤー3マルチキャストには参加しない」という一節だ。MARSはIPグループアドレスとATMアドレスの対応を記録し、問い合わせと変更通知に応じた。パケットが通るのは、端点がその後に作る接続だった。

IPマルチキャストは接続を意識させず、ATM UNIは接続先を要求する。この食い違いを埋めるため、送信側はまずMARSに現在の端点集合を問い合わせ、次にATMシグナリングへpoint-to-multipoint VCの作成と各leafの追加を依頼した。

RFC 1112では、送信者がそのグループの受信メンバーである必要はない。したがって、MARSへの問い合わせ成功は送信者の所属を意味しないし、送信操作も受信者の存在を意味しない。

最後の断片が届くまで名簿は完成しない

端点が多い場合、回答は複数のMARS_MULTIに分割された。xが最終メッセージを示し、yが欠落を検出する順序番号になった。終端がなく、順序にも穴があれば、送信側は途中の一覧を捨てて再試行する。最初の一件を見ただけでは回答にならない。

完全性が保証するのは、MARSの一時点のスナップショットを受け取ったことまでだ。次のVC構築ではleafごとに失敗し得る。RFCは追加の再試行を認め、未追加のleafが残る間にもデータ送信を始められるとした。VCが稼働中でも、全受信者が接続済みとは限らない。

MCSは経路の後半を隠した

Multicast Serverを使う構成では、MARSは個々のメンバーではなくMCSのATMアドレスを返せた。送信側はそれがメンバーかMCSかを区別せず、同じ手順でVCを張る。実際にデータを受け取り再配信するのはMCSである。

この透明性は実装を簡単にする一方、観測範囲を狭める。MCSのアドレスは中継先を示すが、その背後の受信者一覧や到達結果を示さない。複数MCSなどの構成はRFC 2149が後に論じた課題であり、RFC 2022が既に保証していたものではない。

制御通知は端点ごとの回線状態を修復する

登録メンバーはClusterControlVCでMARS_JOINとMARS_LEAVEを非同期に受け取り、自分が持つ送信VCのleafを増減した。最後のleafが抜ければVCを閉じ、次のパケットが来た時点で問い合わせからやり直した。

各通知のCluster Sequence Numberは、通知を取りこぼした可能性を見つける手掛かりだった。MARSはデータベースを変更しない送信でもCSNを増やす。そのため番号の飛びは、失った出来事の内容までは教えない。端点は開いている全グループVCを新しい問い合わせで再検証し、しかもその間データは流れ続け得た。

連番は制御メッセージ列の観測記録であって、シグナリング成功や受信者の生存、配信の記録ではない。

仕様の外側を証拠にしない

RFC 2022の範囲は一つのMARS Cluster内に限られた。クラスタ間ルーティングとQoSのATM属性への対応付けは対象外で、予備MARSの協調、死んだメンバーの除去、複数MCSの協調も完結していない。セキュリティは議論されていない。

だから、名簿登録、完全応答、leaf、MCS、CSN、送信の各記録は、それぞれの処理だけを示す。現在の稼働、エンドツーエンドの所属、アプリケーション受信、実在の本人性、権限、安全性へ自動的に広げてはならない。

RFC 2022が残した教訓は、名簿と経路を同じものにしなかったことにある。両者は同期できても、別の主体が管理する別の状態だった。

出典