要約

  • RFC 9616 は同期時計を要求せず、Hello と IHU の時刻情報から隣接ルーター間 RTT を測る。
  • 生の測定値はそのまま使わず、推奨値 0.836 の指数平滑、10/120 ms の有界コスト写像、最大ペナルティ 150、ヒステリシスを通す。
  • 低いコストが証明するのは設定された制御判断であり、FIB、実パケット、損失、帯域、アプリケーション遅延まで自動的には証明しない。

経路制御には二種類の失敗がある。変化に過敏で、並列経路の間を往復する失敗。もう一つは変化を吸収し過ぎて、古い判断を保つ失敗だ。RFC 9616 は前者を抑えるために、後者を一定範囲で受け入れる。

文書は、RTT が変わった後も数秒から数分、準最適な経路が残り得ると明記する。固定的な広域オーバーレイなら、その遅延は妥当かもしれない。移動が激しいネットワークでは、物理状態が変わった後まで過去を保持する危険がある。

したがって、経路変更が少ないという事実は安定性の証拠であって、最適性の証拠ではない。この区別を作るには、RTT がどのように採取され、どのように記憶され、どの閾値で圧縮され、どの時点で転送へ反映されたかを追跡する必要がある。

トンネルが消した距離

基礎仕様の RFC 8966 は、Babel のメトリック計算を一つに固定しない。無線で損失を利用し、その他でホップ数を使う実装は珍しくない。ところが VPN やトンネルでは、近距離と大陸間のリンクが同じ一ホップに見える。

RFC 9616 の菱形例では、パリに A、B、D、東京に C がある。A から D へ B 経由と C 経由の二経路があり、ホップ数だけなら同価だ。遠回りが約半数で選ばれても、計算は整合している。欠けているのは地理情報ではなく、実際の遅延を表す観測だ。

拡張は既存メッセージに Timestamp sub-TLV を加える。A は Hello に t1 を入れ、B は受信時刻 t1' を記録する。B が IHU と別の時刻付き Hello を返し、A が t2 で受け取ると、RTT = (t2 - t1) - (t2' - t1') を計算できる。

各差分は同一ローカル時計内で閉じる。時計の原点は一致しなくてよい。この方式は RFC 891 の Mills の手法に由来し、RFC 5905 で知られる時間処理とも接点を持つ。

IANA Babel Parameters では Timestamp は type 3 だ。Hello では四オクテット、IHU では八オクテットの本体を持つ。小さ過ぎれば無視し、余分な部分があれば先頭を処理して残りを無視する。将来拡張と旧実装の継続を両立する細い仕組みである。

測定位置は値の意味である

送信時刻はネットワークスタックへ渡す直前、受信時刻はそこから受け取った直後が望ましい。早過ぎる送信時刻はローカル待ちをリンク遅延へ混ぜる。遅過ぎる受信時刻はスケジューリングや処理負荷を隣接リンクへ帰属させる。

RFC が PadN を先に置き、送出直前に Timestamp へ置き換える実装方法を記すのはこのためだ。形式上同じ値でも、採取点が違えば観測対象が違う。監査はフィールドの存在だけでなく、打刻位置とソフトウェア版を必要とする。

時刻は任意原点からのマイクロ秒を 32 ビットで表すため、およそ 71 分で周回する。再起動も原点を変える。推奨される三分窓は、未来に見える値、古過ぎる値、再起動で矛盾した値を RTT 標本から除く。

隣接状態の更新と標本の採用は別だ。最終平均だけ保存すると、棄却率、標本の古さ、再起動後の回復が見えない。安定した線が、安定した観測ではなく標本不足を表すこともある。

平滑化は過去へ投票権を与える

生 RTT は突発で跳ねる。さらに低遅延経路へトラフィックを集めると輻輳が増え、RTT が上がって別経路へ逃げる。負荷が消えると元の経路が再び良く見える。直接選路に使えば、制御が自分自身を振動させる。

一次研究 A delay-based routing metric は、素朴な遅延利用が永続的振動を招くこと、実環境試験では振動が見られず、人工的な厳しい条件では分単位の周期が生じたことを報告する。適用範囲を持つ実験結果であり、全実装への保証ではない。

指数平滑は RTT := α RTT + (1 - α) RTTn。alpha は 0.8 から 0.9、既定推奨は 0.836 だ。新しい標本より既存状態へ大きな重みを与える。外れ値に強くなる一方、恒久的変化の認識は遅くなる。

次に平滑値を有界コストへ写す。rtt-min より下では名目コスト C のまま。rtt-min と rtt-max の間だけ線形に増加し、上限を超えると C + max-rtt-penalty で止まる。推奨値は 10 ms、120 ms、150 だ。

最後にヒステリシスが中間領域の小変動を抑える。選択が動かないことは設計目標である。その代価として、現実が変わっても判断が動かない時間が生まれる。

二つの平坦部は価値判断である

10 ms 未満を全て同じと扱うのは、低遅延リンク間の微差より経路安定を優先する判断だ。1 ms と 9 ms を区別する必要がある用途では、この前提が崩れる。

120 ms 超を同じと扱うのは、極端な値による不安定を防ぎ、遅いリンクを最後の手段へまとめる判断だ。全候補が上限を超える局面では、130 ms と 600 ms の重要な差を失う。

rtt-max を下げるほど安定しやすいが、高遅延経路の識別力は減る。上げれば情報を残すが変動も取り込む。最大ペナルティは遅延成分の重さを決めるが、帯域、損失、料金、アプリケーション損害を表す単位ではない。

既定値を使う場合でも、責任主体は消えない。何をローカルとみなし、どこから回避し、どれだけ古い選択を許すかを運用者が説明しなければならない。

混在は安全性と意味を分ける

未対応実装は未知の sub-TLV を無視するため、新旧ルーターは共存できる。RFC は、その混在がループなどの病理を生まず、ただし準最適な選路は起こり得るとする。

これは段階導入を可能にする優れた性質だ。ただし同一意味を保証しない。ある隣接は RTT、別の隣接はホップ数、無線区間は損失を使うかもしれない。経路全体のコストは異なる観測を合成する。

導入率ではなく隣接単位の能力表が要る。未対応ノードが transit になる、対応ノードが時刻送信をやめる、境界を跨ぐ経路が切り替わる、といった試験が必要だ。「後方互換」は稼働継続の回执であり、最適性の回执ではない。

RFC 9647 が扱う YANG 状態とも区別すべきだ。管理データが見えることと、その RTT 採取、パラメータ、転送結果が正しいことは別である。

時刻を出さない選択

任意原点により、Timestamp は起動時刻やタイムゾーンを直接漏らさない。それでも精密なローカル時計は、攻撃者の物理位置推定を助ける可能性がある。ノードは Timestamp sub-TLV を送らず、隣接にホップ数へ戻らせることができる。

プライバシー判断は経路入力を変える。信号を出さなければ精度が落ちるかもしれず、出せば観測面が増える。どのインターフェースが送信し、どの脅威を想定し、代替メトリックが何で、経路とサービスがどう変わったかを記録すべきだ。

拒否できることは欠陥ではない。共通仕様は互換性に必要な部分へ留まり、将来選択はローカルに残る。採用の正当性は公開文書ではなく稼働証拠から生まれる。

証拠台帳を五層に分ける

第一層は時刻の来歴：実装、打刻位置、時計、周回、再起動、採用・棄却標本。第二層は変換：alpha、閾値、ペナルティ、名目コスト、ヒステリシス。

第三層は制御の時系列：候補、計算コスト、選択理由、変更原因、収束時間。第四層は実行：RIB、FIB、次ホップ、実パケット、損失。第五層はサービス：アプリケーション遅延分布、スループット、完了率、利用者が見た失敗。

この台帳が閉じたときだけ、「この設定がこの条件でサービスを改善した」と言える。低コストだけなら、設定アルゴリズムの局所判断までが証明範囲だ。

情報源