要約

  • RFC 3423 では、トランスポート ACK はパケット損失や応答しないサーバーの検出に使われ、CRANE の DATA ACK は受信側が連続した記録を正しく処理し、会計情報を永続ストレージへ置いた後にだけ進んだ。
  • その ACK も最終判定ではない。DSN の欠落、冗長サーバー間の切替、重複排除、テンプレート構成、通信保護、請求結果は、それぞれ別の証拠を必要とした。

到着音のあとに残る仕事

ネットワーク装置が利用記録を送る。信頼できるトランスポートが受領を返す。ところが遠隔プロセスは、記録を解釈し、処理し、ディスクへ確定する直前に停止する。このとき配送成功は事実でも、記録の安全はまだ事実ではない。

2002 年 11 月の RFC 3423 は、XACCT Technologies の Common Reliable Accounting for Network Element、CRANE を Informational 文書として記録した。テキスト版、RFC Editor 情報ページ、IETF 文書ページ、履歴、参照関係、エラッタ検索は、その位置を固定する。これは Internet Standard ではなく、現在の普及率を示す資料でもない。

対象は、ネットワーク要素からメディエーション、BSS、OSS へ大量の会計データを運ぶことだった。その設計は「信頼性」という一語を、異なる責任を持つ二つの確認へ分解した。

ネットワークの ACK は台帳を書かない

CRANE の下には、接続型で順序を保つ信頼できるトランスポートが必要だった。TCP を利用でき、文書はメッセージ指向、認証能力、速い障害検出などを理由に当時の RFC 2960 の SCTP を選好した。これは仕様上の選好であり、実装数の観測ではない。

トランスポート確認は、失われたパケットと反応しないサーバーを早く検出する。CRANE 確認は、メッセージが処理され、会計情報が永続ストレージへ置かれた後に返る。この順番によって、通信スタックは配送だけを語り、アプリケーションは処理と保存だけを語る。

RFC 2975 は会計管理全体の中で、不揮発保存や重複排除の問題を整理していた。RFC 3423 は、その一部をプロトコル上の観測点にした。下位層の成功を上位層の成功へ自動昇格させない設計である。

DSN は「見た最大値」ではなく連続境界だった

各 DATA メッセージには Data Sequence Number がある。起動時やサーバー移行後の最初の DATA は S、DSN Synchronize ビットを立て、出発点を示す。新しく生成するたびに DSN は一つ増える。受信側は順序どおりの記録を受け、先走ったものを捨てる。

DATA ACK が示すのは、正しく処理済みの連続列の末尾である。3122 が欠けたまま 3123 を見ても、境界を 3123 へ進めてはならない。受信側は現在の ACK を返し、未確認部分の再送を促す。

この境界にも射程がある。正しい加入者への関連付け、正しい料金計算、請求、決済、永久保存までは証明しない。特定のセッションと構成の下で、受信側がどこまで処理・永続化したと宣言したかを示す。

一つの列が複数サーバーを通る

CRANE セッションには優先順位を持つ複数サーバーを置けた。クライアントは稼働中と認識した中で最優先の相手へ送り、全てが利用不能ならローカルに待たせる。キューが尽きる場合は警報が必要だった。

移行の根拠は一つではない。トランスポートがポート無応答を通知する、未確認バイトが設定閾値を設定時間だけ超える、稼働サーバーが STOP を送る、または高優先度サーバーが復帰する。プロトコルは材料を用意したが、移行アルゴリズム自体は実装事項とした。

文書の例では、サーバー 1 が 3042〜3095、サーバー 2 が 3096〜3122、再びサーバー 1 が 3123 以降を受ける。単独サーバーに全列はない。それでも送信側は、メディエーションまたは課金システムへ全記録を届ける責任を負う。

別サーバーへの再送には Duplicate ビットを付け、下流は DSN で重複を除く。ビットは「重複かもしれない」と伝えるだけで、二つのコピーの存在も、排除の成功も証明しない。冗長化は停止を減らす一方で、重複候補を増やし得る。

保存されたバイトには解釈用の構成が要る

帯域を節約するため、CRANE は各記録に説明を付けず、先にテンプレートを交渉した。テンプレートはキーの順序、型、意味を定め、キーごとに有効・無効を選べた。同じセッションの全サーバーは同じ集合と状態を使うことになっていた。

記録は Template ID と Configuration ID の両方を運ぶ。古い構成の遅延記録を読むため、サーバーは短い履歴を保持できた。未来の構成が先に届かないようにし、前の構成の DATA を確認してからテンプレートを変えるのが望ましいとされた。

交渉では、各サーバーが変更を提案できるのは一度だけだった。クライアントが最終集合を決めて FINAL TMPL DATA を配ると、サーバーは再変更せず受け入れる。無限の往復を止める規則であり、最終決定権の所在も示している。

したがって、バイトが完全に永続化されても、構成情報を失えば意味を誤る。保存の完全性とスキーマの一致は別の受領証である。

近接するプロトコルを同一視しない

RFC 3423 は RADIUS と Diameter を比較対象にした。RFC 2865 は RADIUS アクセス、RFC 2866 は RADIUS Accounting を定義する。Diameter は RFC 3588 を経て RFC 6733 に更新された。RFC 3334 はポリシー型会計の要件を論じる。

後年の IPFIX には、プロトコル、情報モデル、実装上の考慮がある。これらは大量記録とテンプレートが繰り返し現れることを示すが、CRANE の採用、直接の系譜、相互運用を証明しない。

大文字の MUST や SHOULD は RFC 2119 の規範語である。文書が要求したことは示すが、実行中コードの適合は示さない。

セキュリティは別料金だった

RFC 3423 自身は、強い機密性と完全性を提供しないと述べた。クライアントとサーバーのアドレスを静的に設定して信頼関係を組めても、追加保護なしではアドレス詐称に弱い。環境に応じ、IPsec や TLS など下位層の保護を推奨した。

DATA ACK が届いても、送信者の真正性、メッセージの完全性、会計判断の権限は自動的に付かない。チャネル、相手、スキーマ、保存、業務処理は別々に確認する必要がある。

出典と限界

分析方法は Heng Lu の現実の層と稼働コードを一次資料とする議論に従う。仕様、実装、設定、観測、保存状態、業務結果を交換可能にしない。

資料が支えるのは 2002 年の設計と意味である。現在の配備数、実測性能、特定事件、現行製品、個別システムの適合は支えない。歴史的な機構から現在形の市場事実を作ってはならない。