要約

  • リーダーだけが停止した場合、メーターに同じフローの累積状態が残っていれば、再開後に総量の増分を求められる。ただし途中の収集を失えば、区間内の変動を細かくたどる情報も失われる。RFC 2063、2.5節
  • 回収には、規則とフローの連続性、記録の保持、メーターの稼働などの条件がある。非同期に読む複数のリーダーは、それぞれ異なる時刻の計測状態を記録する。RFC 2063、2.2〜2.5節・3.2節

仮想の場面を考えよう。リーダーが一度フロー表を収集した後に停止し、メーターは通信を数え続ける。再開したリーダーは、残っている累積パケット数やバイト数を読み取れる。規則が変わらず、同じフローの記録が維持され、カウンターの周回に曖昧さがなければ、前後の差から最後の収集と再開後の収集の間に増えた量を求められる。RFC 2063の2.5節は、こうしたリーダー単独の停止について、累積情報の回収と時間分解能の喪失を併せて説明している。リーダー停止時の設計

フローの最初・最後のパケット時刻も手掛かりとして残り得る。しかし、この例では、その二点と累積値から、空白期間の到着順序や短いピークを一意に再現することはできない。区間全体の平均を算出できても、その内側の変動は複数通りあり得る。これは欠けた中間観測から導く分析上の限界である。保持する時刻と利用量記録、3.2節・5.2節

規則、計数、収集時刻を誰が持つか

1997年1月のRFC 2063は、Nevil Brownlee（The University of Auckland）、Cyndi Mills（BBN Systems and Technologies）、Greg Ruth（GTE Laboratories, Inc.）による文書である。区分はExperimental（実験的）。IETFのインターネット標準としてではなく、必要な情報、要件、実装上の選択を整理するアーキテクチャとして提示され、プロトコル仕様そのものも定めていない。文書の位置づけと目的

ここでのフローは、独立したIPパケットの属性を規則で分類し、開始・終了と帰属先を与えた論理的な計測単位である。帰属先は利用者、ホスト、ネットワーク、集団など、選んだ粒度に応じる。記録上の帰属から契約上の支払者を認証したとはいえない。この計数方式では、一つのパケットをただ一つのフローに数える。重なり合う分析視点が必要なら、重複しない細かな分類を後処理で組み合わせる。フローの定義と計数、2.1節・3.3節

マネージャーは分類規則、粒度、サンプリング、非活動時間や表の管理を設定し、リーダーには対象メーター、収集間隔、フローと属性を指示する。メーターは観測した通信を選択的に数え、フロー表に累積値と活動時刻を保持する。リーダーは利用量記録を確実に分析側へ運ぶ役割を担い、メーター識別子、時刻、収集規則のID、フローの記述と計数値を、メーター別のディスクファイルに残す。三役は同じ機械に置いてもよい。役割分担と保存形式、2節・5.2節

累積値は収集のたびに消去せず、増やし続けることが推奨された。差分を読む際には、Rule Set IDやフロー開始時刻などの文脈が欠かせない。同じアドレスが並んでいても、新しく始まった別のフローの値を以前の値から差し引けば、連続した量という前提を失う。分析アプリケーションが速度を算出する段階では、規則の記録、メーター内の状態、リーダーが実際に取得した時刻を結び付けて解釈する必要がある。規則の識別と累積計数、3.2〜3.3節

非同期の収集が残す時刻のずれ

RFC 2063は表全体、行、属性の一部を任意の時点で読むことを許し、収集の同期を要求しない。同じ間隔でも収集時刻がずれた二つのリーダーは、増え続ける値の別の瞬間を記録する。数値の不一致だけで破損とは判断できず、重複した累積値を足せば同じ通信を再計上してしまう。同じセグメントに置く複数メーターは計測機の故障に備え、複数リーダーは収集の継続に備えるという違いもある。非同期読み取りと冗長化、2.2節・2.5節

同じ1997年1月のExperimental文書RFC 2064は、MIBの表の索引を収集者の進捗状態に依存させず、独立した走査を可能にした。TimeFilterとGetBulkは変更のある行や必要な属性を取得する手段である。登録リーダーのflowReaderLastTimeとflowReaderPreviousTimeは保持領域の再利用判断に使われ、flowReaderTimeoutは収集が遅れたリーダーの登録を削除する期限を定める。RFC 2064の収集と登録管理

ただし、LastTimeへの書き込みは走査の開始時に行う。表全体を一瞬に読み終えた証明にはならない。書き込みや認証の失敗によって、読み取りが進んでも領域の再利用が妨げられる場合がある。記録された時刻を解釈するには、それが収集のどの段階を表すかまで見る必要がある。RFC 2064の収集手順

メーターに残る状態にも寿命がある

1997年のアーキテクチャは、休止フローの領域を再利用する前に、少なくとも一つのリーダーによる収集を求める。一方、複数リーダーの収集時刻の最小値や一覧を使う保持方針は、なお検討が必要としていた。別のリーダーが読んだだけでは、停止中のリーダーにも後で同じ状態が残るとは限らない。表の使用量がしきい値へ近づいた場合には、収集間隔の短縮や粒度の粗い待機用規則への切り替えを挙げ、稼働維持のための短い計測損失も想定する。カウンターの幅に対して通信量が多く、周回が曖昧になることも、差分回収の限界となる。保持と過負荷への対応、3.2節・4.5〜4.6節・5.3節

停止した役割によっても復旧の意味は変わる。マネージャーの停止中もメーターとリーダーは仕事を続ける設計であり、計画的なメーター停止には最終収集を要求できる。不意の再起動は通知やリーダーの定期照会で検知し、正しい規則を再投入する想定だった。だが、設定が戻っても、測られなかった通信や失われた状態をそこから復元することはできない。トラップも、到達や真正性を保証する証拠ではなく、通知手段として提案されている。障害と再起動、6.3節

1999年の明確化を、1997年へ戻さない

RFC 2063を置き換えたのは、1999年10月のInformational（情報提供）文書RFC 2722である。リーダー停止による時間分解能の喪失は維持しつつ、登録された全リーダーが読むまでの保持と、停止したリーダーのタイムアウトによる登録解除を明確化した。RFC 2722、2.5節・4.5節

同一メーター上の規則セット切り替えによるスナップショットの近似は、既にRFC 2064にもある。RFC 2722は、同一内容の二つの規則セットを交互に使い、旧セットの同じ記録を各リーダーへ渡す方法を明示する。ただし複数メーターの同時切り替えまでは保証しない。管理モデルにも違いがある。RFC 2063は、メーターとリーダーのそれぞれについて、その時点で制御するマネージャーを一つとする。RFC 2064には主たる管理者の区別があり、RFC 2722は複数の規則セットとマネージャーの併存を扱う。後年の記述を1997年の全実装の能力へ遡及させる根拠はない。1997年のアーキテクチャ、同時期のMIB、1999年の改訂

転送にはSNMPを使えるが、アーキテクチャは方式を固定せず、完全性と機密性を管理・収集プロトコルに委ねる。料金や費用回収の方針は範囲外で、計数値だけでは、料金が承認されたか、請求が有効か、通信がアプリケーションに役立ったか、支払いが済んだかまでは示せない。ここで問えるのは、どの条件なら利用量とその時間的な広がりを説明できるかである。適用範囲と保護、1節・5.3節・10節

出典と解釈の範囲

資料 この稿での位置づけ
RFC 2063：1997年のトラフィックフロー計測アーキテクチャ 非同期収集、累積値、保持と障害対応の一次資料。実際の普及や製品互換性まで示すものではない。
RFC 2063：公式の文書情報 Experimentalという区分と、RFC 2722による置き換えを示す公式記録。
RFC 2063：公式の正誤表検索 該当項目なしという検索結果。訂正の不在は設計の完全性を証明しない。
RFC 2064：1997年1月のメーターMIB 同時期の実験的仕様として、独立した表走査、収集時刻、リーダー登録を説明する。
RFC 2722：1999年10月のアーキテクチャ改訂 情報提供文書としてRFC 2063を置き換える。保持と規則切り替えの記述は後年の明確化として読む。
RFC 2720：1999年10月のメーターMIB 後継MIBの文脈を与える資料。1997年の実装や現在の稼働を証明する用途には用いない。
RFC 1272：1991年11月のトラフィックフロー計測の背景 計測の設計理由と費用回収方針を分ける、先行する議論を示す。
Lu Heng：動作するコードと文書公表の関係を論じる後年の視点 公刊された設計と、採用され実際に観測された動作を区別する解釈上の視点として扱う。
Lu Heng：最小限の共通規則、現場の判断、任意の採用を論じる後年の視点 共通の計測上の意味と、保持・収集負荷や事業上の取り決めを選ぶ現場の裁量を分けて読むために用いる。
Lu Heng：提唱より現実の記述を重んじるBTW.Mediaの役割 構造と前提を記述し、特定の解決策の支持へ飛躍しないという、後年の編集上の視点として扱う。

Lu Hengの三つの論考は、以上の狭い解釈に用いるものである。1997年の著者や所属機関の政治的意図、当時の導入実績を示す歴史的証拠とは位置づけない。