要約

  • RFC 2386 は資源の空き状況とフローの要求から有望な経路を探したが、経路計算そのものは帯域やキューを予約しないと明記した。
  • 詳細で速い判断は自律システム内に残し、ドメイン間では比較的安定した情報だけを交換する。フロー設定時の最終的な受付権限は各ノードに残った。

「通れそう」と「通れる」の間

当時のベストエフォート型ルーティングは、到達性と一つの尺度を中心に最適な道を選んだ。QoS を持つフローでは問いが変わる。必要な帯域が残っているか。遅延や揺らぎは許容範囲か。最短経路が満杯でも、別の経路なら要求を収容できるかもしれない。

RFC 2386 は、資源可用性についての知識とフローの要求を使う仕組みを QoS ベースルーティングと呼んだ。重要なのは「要求を収容できる可能性が高い経路」を求めるという限定である。計算は資源を押さえない。RSVP のような予約プロトコルは経路上で資源を要求できるが、十分な資源を持つ経路を自動的に発見するわけではない。互いに必要だが、同じ仕事ではなかった。

実行までには複数の証拠が要る。リンクが状態を測る。ルーティング系が値を表現し、更新し、場合によっては集約する。経路計算は、すでに遅延や損失を含むその地図から候補を選ぶ。設定時には各ノードが現在のローカル資源でフロー受付制御を行う。全ノードに容量があっても、上位の方針が公平性、費用、優先度を理由に拒否できる。予約、整合した転送、実測を経て、ようやく提供品質を語れる。

地図は探索を助ける。受付印を押すことはできない。

使われるほど古くなる指標

可用帯域は消費される。空いていると報告された経路にフローが集まれば、その報告を根拠にした行動が報告を古くする。わずかに良い経路が見つかるたびに移動すれば、トラフィックは往復し、遅延やジッターが増える。元の経路が要求を満たし続けていても起こり得る。

新鮮さには代価がある。頻繁な更新は通信量とCPUを使い、短い変動まで制御面へ持ち込む。更新を遅らせれば、経路計算は古い値に頼る。量子化を粗くすれば更新は減るが、受付に必要な差まで消える。平滑化はノイズと本当の過負荷を同時に丸めることがある。

そのため RFC は、更新を起こす閾値を安定性の設計として扱った。さらに経路ピン留めを定義した。受け付け済みフローを一定期間同じ経路に置き、地図の小変動で動かさない。ピン留めは保証の永久化ではない。フローの連続性と、周囲の状態更新を別の時計で扱う方法だった。

細粒度化は、失われ得る状態を増やした

判断単位は宛先、送信元と宛先の組、個別フローへと細かくできる。個別フローなら要求に合う経路を選びやすい。その代わり、保持すべき状態が大幅に増える。

問題は表の大きさだけではない。途中のノードがフロー固有状態を失い、通常の宛先ルーティングへ戻る一方、手前のノードが特別経路を覚えていれば、パケットが両者の間でループし得る。二つのノードが別の現実を実行するからである。

詳細状態は情報資産であると同時に運用上の負債だった。計算できることと、フローの寿命中ずっと転送判断を整合させられることは違う。

集約は規模を得て、確実性を失う

階層化は、多数の内部リンクや経路を小さな表現にまとめる。大規模ネットワークを扱うには不可欠で、内部構造をむやみに公開しない利点もある。しかし要約は細部を落とす。

RFC 2386 は、集約情報では収容可能に見えたフローが、実際の下位経路では要求を満たせない事態を想定した。要約が虚偽なのではない。要約の精度を超える判断に使われたのである。

そこでクランクバックが登場する。設定が途中で失敗したら、別経路を選べる以前のノードまで戻る。予測の誤差を、制御された探索へ変える仕組みだった。ただし設定時間を延ばし、高負荷では性能を悪化させる場合もある。無限の再試行ではなく、受付制御と組み合わせて慎重に使う必要があった。

失敗を許す順序こそ重要だった。集約状態で探索範囲を絞り、候補を出し、ローカル現実に照らし、だめなら拒否または限定的に戻る。最初の計算を保証と呼べば、この誠実な失敗処理ができなくなる。

自律システムの内側と外側に別の速度を置く

RFC の核心的選択は、一つの万能アルゴリズムではなかった。自律システム内部では、リンク状態、プローブ、静的な供給、オンデマンド計算など異なる方式を試せる。システム間では、単純で一貫し、安定した相互作用を目指した。

瞬間的な内部状態をドメイン間で配ると拡張しにくい。運用者が秘匿したい情報を漏らし、遠隔の計算者に集約済みで検証不能な像を与える。そこで域間指標は、瞬間的な残余ではなく、設計・供給された容量を基礎にする。通常の到着ごとには変えず、障害や集中的な過負荷のような例外で更新する。

内部は短い時計で動き、外部への声明は長い時計で動く。共通層は内部現実の複製ではなく、到達性、設計能力、方針を調整する薄い境界になった。

この分離は権限も守った。外部への告知は条件付きの能力表明であり、資源の譲渡ではない。入口ルーターは集約需要を数え、設計限度を超えれば拒否、ベストエフォート化、別方針を選べる。資源の近くにいる主体が最後に決めた。

価格を付けると、最後の証明不足が見えた

RFC は金銭的コストも経路方針になり得ると考えた。複数ドメインがサービス能力と費用を組み合わせれば、利用者は価格を含めて経路を選べる。しかし、約束した QoS が実際には届かなかった場合、何を請求するのかという問題が生じる。

告知は能力を表し、予約は割り当てを表す。どちらも、端から端までの遅延、ジッター、損失、スループットを自動的に測定しない。価格の証拠と提供の証拠は別だった。

セキュリティ節は逆方向から同じ境界を示した。フローが要求を書くだけで資源を得られるなら、任意の要求が枯渇攻撃になる。要求の検証、方針、課金、ポリシングは、申告を権限へ変換しないための制御だった。

後続仕様が示した機能分担

RFC 2205 は受信側から始まる RSVP の予約設定を定義した。RFC 2210、2211、2212 は統合サービス、制御負荷、保証サービスを説明した。RFC 2676 は QoS ルーティング機構と OSPF 拡張を記録し、RFC 3272 は測定・モデル化・制御・評価を含むトラフィックエンジニアリングの全体像を示した。RFC 3630 は OSPF で追加リンク属性を配る方法を定めた。

これらは RFC 2386 が普遍的に実装された証拠ではない。むしろ、分担が後にも必要だったことを示す。属性は計算の入力になり、計算は提案し、信号は要求し、受付は判断し、予約は状態を変え、測定は結果を確かめる。一つが他を代用できないからこそ連携する。

RFC 2386 は適応ルーティングを、状態を測定・収集することと、その情報から経路を計算することの二つに整理した。歴史的に重要なのは、その間と後に置いた境界である。状態には時刻があり、告知には範囲があり、計算は候補であり、受付は現在を見て、予約は資源を変え、観測が結果を決める。

地図が命令できない場所で、経路は一つずつ許可を得なければならなかった。

情報源