要約

  • RFC 3970 では、少なくとも一つの経路が動けば TE トンネルは稼働中だった。トンネル全体と主経路の稼働時間を別々に持つため、集約状態から主経路利用は導けない。
  • 設定ルート、計算ルート、信号記録ルート、実転送は別であり、任意かつ抑制される通知、断続するカウンター、周回する TimeTicks は完全な履歴ではなかった。

運用者が欲しい答えは短い。トンネルは動いているか。RFC 3970 は 2005 年 1 月、その答えを管理オブジェクトにした。同時に、答えの縮約を追跡できる構造も作った。トンネルは論理実体で、一つ以上の経路が実体化する。どれか一つが上がれば全体は上がる。主経路が止まり、代替経路が全体を維持することは矛盾ではない。

そのため、トンネルの総稼働時間と主経路の稼働時間は別オブジェクトになった。前者は到達可能性を保った時間、後者は意図した経路に留まった時間を測り得る。一つの緑色表示は有用だが、二つ目の問いへの回答ではない。

この MIB は RFC 2119 の規範語、RFC 2578、RFC 2579、RFC 2580 の SMIv2、RFC 3411 と RFC 3410 の SNMP 管理枠組みに立つ。管理情報は観測可能な投影であり、ネットワークそのものではない。

意図、計算、信号記録を一列に畳まない

モデルはトンネル、経路、ホップを分けた。各経路には設定ルート、計算ルート、記録ルートがあった。設定は管理者が指定した制約や順序である。計算は実装依存の制約ルーティング結果である。記録は信号プロトコルが実際に使用したと報告したホップ列である。ゼロなら、計算済みまたは記録済みルートは存在しない。

三つが一致する保証はない。緩いホップ指定を計算器が具体化し、信号処理が別の結果に至ることも失敗することもある。RFC 2702 の MPLS TE 要件、RFC 3209 の RSVP-TE、RFC 3212 の CR-LDP は隣接する仕組みを示すが、各層の受領証を統合しない。

経路状態にも中間段階がある。down は信号失敗、dormant は未信号のバックアップ、ready は信号済みだがトラフィック未搬送、operational は信号済みで搬送中を表す。制御面の成立とデータ面の活動は、明示的に別だった。

さらに RFC 3970 の対象は入口での設定と監視に限られた。入口が RSVP-TE などで他ルーターに必要情報を伝え、他地点への拡張は将来研究とされた。入口の完全な表は中継点や出口の完全性を証明しない。

数値は連続性を伴って初めて履歴になる

パケットとオクテットのカウンターは、管理系の再初期化などで不連続になり得る。最終断点を示す専用タイムスタンプが置かれたのは、二つの値だけでは差分が正しいか分からないからだ。

トンネル年齢、総稼働時間、主経路稼働時間は TimeTicks で、約十六か月後に周回する。仕様は区間測定を例示し、管理局に周回処理を求めた。観測時刻、sysUpTime、断点、計算方法を保存して初めて可用率の根拠になる。

通知も全イベントを保存しない。up、down、活動経路変更、再ルーティングは、急変時にそれぞれ一分間に一回までに抑える必要があった。通知グループは任意で、生成は既定で無効だった。通知がないことには、安定以外にも未実装、無効化、配送損失、抑制がある。

経路変更と再ルーティングも別である。前者は活動する経路そのものが替わり、後者は同じ経路の中身が替わる。名前が同じでも、通ったホップは変わり得た。

次の番号を読んでも所有権は生まれない

トンネル作成では、アプリケーションが空き候補の索引を読む。二つの管理アプリが同じ値を同時に得られるため、SET 時にエージェントが再確認し、一方が失敗する場合がある。読取値は候補で、予約ではない。

一部の変更には行を notInService にして編集し、active に戻して再信号する手順が要る。行の活動状態は管理上のライフサイクルで、パケット到達の観測ではない。

最小適合では必須オブジェクトがすべて読取専用でもよい。完全適合で規定の書込能力を持ち、通知はなお任意だった。RFC 3970 適合という一語から遠隔設定やイベント配送能力は分からない。

TE トンネルは Interfaces MIB と索引を対応させ、条件付きで IP Tunnel MIB にも接続できた。MPLS の型は RFC 3811 から導入した。共通識別子はモデルを結ぶが、インターフェース、カプセル化、信号経路、サービス結果を同一化しない。

GET も SET も権力だった

管理グループの変更は制約の意味を変え、帯域、状態、ホップの変更はトラフィックを別経路へ動かし、フラップや停止を生み得る。読むだけでも端点、流量、経路特性を明かす。仕様が SNMPv3 の認証とプライバシーを勧め、旧版を避けた理由である。

それでも認証は接続主体を示すにすぎない。どの主体がどのオブジェクトを GET、変更、作成、削除できるかは別の認可判断である。身元確認から操作権限や転送成功を推論してはならない。

RFC Editor 情報、正誤表検索、IETF Datatracker は文書状態を示す。RFC 9141 は後に古い作業部会アーカイブ参照を更新しただけで、導入率や障害実績を追加していない。

RFC 3970 の設計は、一つの真実を作ることではなく、狭い真実を混ぜずに並べることだった。集約、経路、信号、転送、時系列の境界を守るとき、管理画面は初めて監査可能になる。

出典