前のシリーズで、距離(hop)で経路を選ぶ素朴な解と、その素朴さの裏にあった 2 つの壁を見た。3 動詞(観察・伝播・限界)で振り返ったとき、最後の動詞「限界」には現状の整理と、次の物語を呼ぶ伏線という 2 つの顔があった。
距離以外の何で測れば、この限界の先へ行けるのか。
物差しを変えたのではない。共有する内容そのものを変えた。
距離ベクタは隣に自分の辞書(距離値)だけを渡す世界だ。リンクの生死・帯域・遅延は辞書に書けず、隣どうしのやり取りにも乗らない。限界を越えるには、経路選択の指標を 1 本足すのではなく、ルータ間で渡す情報の種類そのものを変える必要がある。
考えてみよう
もし、距離以外の物差しを 1 本追加するとしたら、あなたは何を物差しにしたいだろうか。帯域? 遅延? それ以外? その物差しを 1 本追加すれば、距離ベクタの限界の先へ行けるだろうか。
1. 距離 1 本の物差しで動いていた世界
RIP は、隣に自分の辞書のうち隣に伝える分を update として送り、受け取った側は +1 して自分の辞書に書く動作で動いていた。3 台のルータ(R-α / R-β / R-γ)で距離が 0 → 1 → 2 と積み上がる。隣に聞くだけで、知らない宛先まで距離が積み上がっていく素朴さがある。
その素朴さの裏には、2 つの壁があった。hop 上限 15(16 = infinity)と count-to-infinity。どちらも「距離だけで測る」発想の構造的な帰結で、素朴さと限界は同じ「距離」という 1 本の物差しの裏表だった。
RIP の素朴さは、距離(hop count)という 1 本の物差ししか使っていなかった。
リンクが今生きているか、落ちているか。リンクの帯域はどれくらいか。リンクの遅延はどれくらいか。こうした「リンクそのものの状態」は、距離の数字には溶けない。隣に距離を伝えるだけでは、リンクの状態そのものは伝わらない。
距離ベクタの世界では、各ルータが保持するのは「隣からの +1 で書いた辞書」だけだ。その辞書の中身は、距離値だけだった。
2. 「物差しを変える」では足りない
距離以外の物差し — リンクの帯域やリンクの遅延 — を、距離に加えて 1 本追加すれば、限界の先へ行けるのではないか。
その予想は、半分は当たっている。たしかに、現代のルーティングプロトコルでは、距離以外の物差しが使われている。けれど、もう半分はずれている。
物差しを 1 本追加するだけでは足りない。
距離ベクタは「隣に自分の辞書を渡す」という形で動いていた。隣に渡せるものは、辞書の中身だけだ。辞書の中身は、距離値しか書いていない。リンクが今生きているかどうか、リンクの帯域がどれくらいか — そういう「リンクの状態そのもの」は、辞書には書かれていなかった。書かれていないものは、隣には渡せない。
つまり、距離ベクタの世界では、各ルータが「リンクの状態そのもの」を共有する手段を初めから持っていなかった。物差しを 1 本追加したくても、その物差しのための情報そのものが、隣どうしのやり取りに乗っていなかった。
距離ベクタの限界の正体は、「物差しの数」の問題ではなかった。「共有している内容そのもの」の問題だった。
物差しを増やすのではない。共有する内容そのものを変える。
3. リンクの状態を全員で共有する世界
もし、隣に聞くのをやめて、各ルータが「自分の周りのリンクの状態」を全員に配ったらどうなるだろう。
ステップ 1: 配る
各ルータが、自分の周りのリンクの状態 — このリンクは生きているか / 落ちているか、帯域はどれくらいか、遅延はどれくらいか — を、断片として全員に配る。
距離ベクタでは隣にだけ自分の辞書を渡していた。本話の世界では、自分の周りのリンクの状態を、隣だけでなく網内のほかのルータ全員に向けて配る。
ステップ 2: 集める
受け取った側は、ほかのルータから配られてくる断片を集めていく。
集まってくる断片を 1 枚ずつ並べると、断片どうしが噛み合って、1 枚の地図として組み上がる。その地図は、網全体のリンクの状態を描いている。
各ルータが保持するのは、「隣からの +1 で書いた辞書」ではなく「自分で組み上げた、網全体のリンクの状態を集めた地図」だ。辞書から、地図へ。
ステップ 3: 計算する
地図ができれば、地図から最短経路を計算できる。
距離は、隣に聞くのではない。地図から計算する。
各ルータには、計算された最短経路が、ルーティングテーブル(辞書)として書き込まれる。最終的に残る形は距離ベクタの世界と同じ「経路を引ける辞書」だが、そこに至るまでの道のりが根本的に違う。
距離ベクタの世界と並べると、5 つの観点で見える景色がはっきり違う。
- 物差し: 距離ベクタは hop count の 1 本。本話の世界は、リンクの状態そのもの(生死・帯域・遅延)を集めた地図
- やり取りするもの: 距離ベクタは隣に自分の辞書を渡す。本話の世界は、自分が見ているリンクの状態を全員に配る
- 各ルータが持つもの: 距離ベクタは隣からの +1 で書いた辞書。本話の世界は、網全体のリンクの状態を集めた地図
- 経路の決め方: 距離ベクタは隣に聞いて +1 で受け取る。本話の世界は、地図から最短経路を計算する
- 経路が消えたとき: 距離ベクタは距離の数字でしか伝えられない。本話の世界は、「このリンクが消えた」という事実を、リンクの状態そのものとして直接配れる
距離ベクタが「測れない」と言ったもの(リンクの状態そのもの)を、本話の世界では「直接共有するもの」として扱う。物差しが先にあるのではない。共有する内容を変えたことが先にあって、その結果として距離以外の物差しが自然に使える世界が成立する。
この解の名前を、ここで初めて与える。
リンクステート と呼ばれる、動的ルーティングの一族だ。代表例のプロトコルを、OSPF と呼ぶ。本シリーズで、これから本格的に扱う。
隣はどう見つけるのか、断片はどんな単位で配られるのか、地図はどう組み上がるのか、地図からどう最短を計算するのか — こうした動作の細部は、本シリーズの後続話で順に扱う。
4. 距離ベクタとリンクステートは、共有する内容が違う別の世界の解
距離ベクタとリンクステートは、「物差しが少ない素朴な解」と「物差しが多い高度な解」ではない。物差しの数で区別されるものではなく、共有する内容で区別される、別の世界の解だ。
距離ベクタは、隣からの距離を辞書として共有する世界。各ルータが保持するのは辞書だけで、辞書の中身は距離値だけ。やり取りする情報が少なくて、シンプルに動く。
リンクステートは、自分の周りのリンクの状態そのものを断片として全員に配り、各ルータが網全体の地図を組み上げる世界。各ルータが保持するのは地図で、地図から最短を計算する。やり取りする情報は、隣だけでなく全員に向かう。
RIP は「使えない技術」ではなく「適用範囲がある道具」で、小さく閉じた網では今でも素朴に動く。優劣の話ではなく、適用範囲の話だ。
距離ベクタの世界で見えるのは、隣からの距離の連鎖。シンプルで予測可能で、小さく閉じた網では十分に動く。リンクステートの世界で見えるのは、網全体のリンクの状態を集めた地図。中〜大規模網で、リンクが頻繁に変わる運用にも対応できる。けれど、各ルータが網全体の地図を持つ分、地図のメモリ使用量と計算量が網規模に応じて増える。
どちらが上か、ではない。どちらが共有する内容がこの網の運用に合うかだ。
距離以外の何で測れば、この限界の先へ行けるのか。答えは、経路選択の指標を 1 本追加することではなく、共有する内容そのものを変えることだった。隣からの距離をルーティングテーブルに書き続けるのをやめて、自分の周りのリンクの状態そのものを断片として全員に配り、受け取った断片を 1 枚の地図に組み上げ、その地図から最短経路を計算する。
誰かが「OSPF って距離以外の物差しで動くプロトコルでしょ?」と口にしたときには、物差しの数ではなく、ルータ間で何を共有しているかから説明できる。
けれど、配る相手は誰なのか。「全員」とは、具体的に誰のことなのか。共有する内容を変えた世界では、距離ベクタのように「隣」が固定的な辞書交換の相手として最初から決まっているわけではない。共有相手そのものを、どうやって見つけるのか。
この問いに、次の話で正面から向き合う。リンクの状態を共有するという旅の、最初の実装上の問いだ。