要約

  • RFC 2443はATM上の複数のマルチキャスト・アドレス解決サーバー間でクライアントとグループの状態を共有したが、各クライアントの登録先は一台のままだった。
  • 生存通知を二回続けて受け取れないと、他のサーバーはその発信元から学んだ状態を破棄する。クライアントはバックアップへ再登録し、以前のグループに入り直さなければならなかった。

三台の表示はそろっている。だが、元の一台は沈黙した

三台のMARSサーバーに同じ行が表示されている。あるクライアントがマルチキャストグループに参加している、という行だ。共有キャッシュは正常に見える。ところが、そのクライアントを最初に登録したサーバーから、定期的なリダイレクト更新が届かなくなる。残る二台は同じ記録を持っているが、RFC 2443はその一致を、元のサーバーやクライアントがまだ稼働している証拠とはみなさない。更新を連続二回受信できなければ、両者はそのサーバー由来の会員状態を消去する。

この区別が設計の要だった。RFC 2022が定義したMARS（Multicast Address Resolution Server）は、ATM網上のレイヤー3マルチキャストについて、アドレスと接続の情報を配布する。分散モデルでは、同じLogical IP Subnet（LIS）内のどのMARSサーバーも、その中のあらゆるグループについて答えられなければならない。1998年11月にExperimental RFCとして公表されたRFC 2443は、Server Cache Synchronization Protocol（SCSP）を使い、サーバー間で記録を複製した。

共有されたのは記録であり、登録の持ち主ではない

SCSPは、サーバー間の関係を確立し、キャッシュを照合し、その後の変更を伝える枠組みを提供する。RFC 2443はMARS用のプロトコルIDを0x0003とし、LISをサーバーグループの境界とした。クライアントが一台に登録すると、そのサーバーは登録や後続のグループ変更を仲間に伝える。それでも、各クライアントが登録するMARSは一台だけであり、クライアントはそのサーバーのCluster Control Virtual CircuitまたはServer Control Virtual Circuitに接続する。複製で広がるのはグループの可視性であって、一つの登録関係が複数のサーバーに移るわけではない。

識別子の割り当て権限も、同期だけでは生まれない。MARSクライアントのCluster Member IDはLIS全体で一意でなければならない。RFC 2443は各サーバーに重ならないID範囲が設定されていることを前提にした。外部の割り当て方式も可能だが、文書の対象外である。衝突した値をすべてのキャッシュに同じように複製しても、一意性を保証する主体にはならない。

ハートビートは古い状態を無効化する境界

各サーバーはMARS Server Redirect Entryを少なくとも二分ごとに更新する必要があり、一分ごとが推奨された。ある発信元から更新を連続二回受け取れなければ、仲間のサーバーはその発信元から学んだクライアントおよびグループの情報をすべてフラッシュする。この規則はバックアップ一覧を新しく保つだけではない。情報の鮮度を特定の発信元に結び付け、その根拠を失った情報だけを捨てる。

その後の回復操作はクライアントに残される。自分のMARS障害を検知すると、クライアントはバックアップを選び、登録を試みる。登録できて初めて、以前のグループに再参加する。失敗すれば次の候補へ進む。リダイレクトマップは接続先の候補を示すが、そのクライアントが移行、再登録、グループ復帰を完了したことや、マルチキャストを再び受信できることまでは示さない。

会員情報の行が戻っても、ATMのポイント・ツー・マルチポイント回線が再構成されたとは限らない。パケットがアプリケーションに届いた証拠でもない。制御面の記録は次の処理に必要な入力であり、その処理が成功したという受領証ではない。

認証は入口を絞る一方、信頼の波及範囲を広げた

RFC 2443はMARS固有のキャッシュ状態フィールドを暗号化しない。SCSPの共通部分が提供するセキュリティ機能を利用する構成だ。認証を使えば、未認証の偽パケットを拒否できる。しかしRFCは、正しく認証されたサーバーから受け取った状態を信頼してグループ全体に伝播させる、とも記している。認証済みサーバー一台の侵害が、共有データベース全体の改ざんにつながりうる。認証は発言者を絞っても、その発言内容の正しさや侵害時の封じ込めまでは保証しない。

2004年のRFC 3790は、RFC 2443がIPv4向けの既定値を与えつつ、適切なIANA定義を用意すればIPv6にも拡張できると評価した。これは設計上の拡張性が文書化されていた証拠であって、実装や運用の実績を示すものではない。RFCは要求事項と注意点を記録するが、どれほど導入され、各実装がどう動いたかまでは証明しない。

したがって教訓は「複製すれば可用性が上がる」にとどまらない。各レコードの発信元、最後に生存を確かめた時刻、その証拠が切れた際に消すべき範囲、次の行動を担う主体を分けて追う必要がある。登録、グループ再参加、回線再構成、パケット転送、アプリケーションの受信も別々に測る。三つのキャッシュは過去について一致できる。マルチキャストが戻ったと示せるのは、稼働中のクライアントとデータ経路だけだ。

出典