MPLS のバックボーン図を開く。通したい道は一本だ。ある入口から、ある出口まで、この通信をこう通したい。それだけのはずなのに、通信が流れない理由を一つに絞ろうとした途端、手元の構成メモで手が止まる。図の上に、確かめるべき面がいくつも重なって見えるからだ。
ラベルの対応を確かめる面がある。通り道ごとの状態を確かめる面がある。網の地図を配る面がある。顧客の経路を配る面がある。
どれも理由があって置かれている。けれど、道そのものを追いたいだけなのに、合意の置き場所が一つずつ増えていく。
通り道は一本でも、その道を支える合意は途中のルータに散らばっている。重いのは仕組みの多さではなく、通り道ごとの状態が網の中に散らばっていることだ。
道そのものを追いたいのに、合意の置き場所が混ざる
MPLS は label だけを見て孤立して動く仕組みではない。label が何を指すのかは勝手に網全体でそろうわけではなく、ラベルと FEC の対応を隣どうしで揃える面と一緒に動く。網の到達性を保つ地図があり、顧客ごとの経路を運ぶ仕組みがあり、通り道を明示して帯域も扱いたいときは、通り道を予約する仕組みが重なる。
ここで見たいのは、どれが悪いかではない。ラベルの対応を隣どうしで揃えるから、MPLS の転送は成立する。地図があるから、バックボーンの向きが分かる。顧客の経路を運ぶ仕組みがあるから、VPN の通信を分けて扱える。それぞれの面が、それぞれの役割を果たしている。
ただ、いざバックボーン図を開いて「この通信はどう通っているか」を読もうとすると、手が止まる。ラベルの対応を見る面、通り道ごとの状態を見る面、地図を配る面、顧客の経路を見る面。道そのものを追っているのか、道を支える合意を追っているのか、すぐには切り分けられない。通信が流れない理由を一つに絞りたいとき、この切り分けの手間がそのまま重さになる。冒頭で手が止まったのは、プロトコル名を忘れたからだけではない。道そのものと、道を支える合意の置き場所が混ざって見えるからだ。
明示経路を扱える強さと引き換えに、状態が網に散らばる
重なった面のうち、明示経路を扱える仕組みをもう少し近くで見る。
普通の転送なら、各ルータが自分の見える情報から次の隣を選ぶ。届くことはそれで足りる。けれどバックボーンでは、届くだけでは足りない場面がある。混みやすいリンクを避けたい。重要な通信を、決めた通り道に載せたい。最短ではなくても、意図した道を通したい。
そこで、入口から出口までの通り道を先に決めて、その道に通信を載せる仕組みが効いてくる。入口のルータが通したい道を要求し、その道に沿って各ルータが必要な情報を持つ。明示経路を扱えるのは、確かに強い。
ただし、その強さは状態を伴う。決めた通り道の上にあるルータ一つひとつに、その通り道のための状態が残る。どの道を、どこまで作ったか。戻り側の情報は、行き側が作った状態を逆向きにたどる。通り道を一本作るたびに、それを覚えているルータが網の中に増える。
ここで踏み外しやすい一歩がある。状態が重いから悪い仕組みだ、と切り捨ててしまう一歩だ。けれどそうではない。明示経路を扱えること、帯域を予約できることには、確かに価値がある。狙った道を作れるのは、この仕組みがあるからだ。見ているのは良し悪しではなく、その便利さの代わりに、状態が通り道ごとに各ルータへ残る、という置き場所のほうだ。だから「MPLS は複雑」とひとまとめに言うより、「どの状態が、どこに置かれているのか」と見た方がいい。重さの正体は、名前の多さではなく、通り道ごとの状態が網の中に散らばることにある。
ここで一度、手を止めたい。途中のルータが、この通り道のための状態を持たなくて済むようにするには、その合意は誰が、どこで持てばいいのか。今ある仕組みの中に、似た選び方をした例はなかったか。
顧客の経路では、すでに置き場所を選んでいた
思い出したいのは、顧客の経路の扱い方だ。
MPLS L3VPN では、顧客ごとの経路を PE 間で配り、その経路に対応するラベルも一緒に配る。このとき、バックボーンの真ん中にいるルータ、つまり途中の P ルータは、顧客ごとの経路を知らなくてよかった。顧客の経路は PE 側に寄せ、途中のルータには背負わせない。真ん中のルータが知っているのは、入口から入口へ届けるための地図と印までだ。
これは、状態を持つ場所をあらかじめ選んでいた、ということだ。全部のルータが全部の顧客経路を覚える必要はない。覚えてほしい場所を端に決め、真ん中からは外す。顧客の経路では、その選び方がすでにできていた。
状態の置き場所は、選べていた。なら、同じ選び方を通り道そのものにも広げられないか。
通り道ごとの状態は、いま、通り道の上の各ルータに散らばっている。途中のルータが経路ごとの合意を持たなくて済むようにするには、その合意を誰が持てばよいのか。答えは、道に入る入口へ寄せることだ。入口のルータが通したい道を決め、その指示を、運ぶ通信に荷札のように積んで持たせる。途中のルータは、経路ごとの合意を自分で抱え続けるのではなく、見えている指示を処理して進める。
MPLS のバックボーンでは、入口が道を決めれば途中の合意を外せる
この、入口で通り道を決めて、途中のルータに経路ごとの合意を持たせない考え方を Source Routing と呼ぶ。
経路を決める「入口」は、通信を最初に作り出した端末のことではない。バックボーンの中へ通信を入れる入口のルータ、通信を網へ受け入れる側のルータが、ここで通したい道を決める点になる。入口で道を決め、経路ごとの状態を入口側へ寄せる。途中のルータは、その通り道のための合意を自分で保たなくてよくなる。経路ごとの取り決めは、途中で一台ずつ作り続けるのではなく、入口側に保つ。
ここで一つ、向きを間違えないようにしたい。途中のルータが経路ごとの合意を持たなくてよくなる、というのは、途中のルータから状態がすべて消える、という意味ではない。寄せられるのは経路ごとの合意、通り道ごとの状態のほうだ。網の地図、どのルータからどこへ届くか、や、通信を実際に次へ送るために要る状態は、途中にそのまま残る。地図がなければ道も決められないのだから、地図まで消えては道が通らない。減らせる状態と、残る状態がある。Source Routing が外しに行くのは、前者のほうだ。
もう一つ、既存の仕組みを悪者にしないことも大事だ。通り道を予約する仕組みは、明示経路や帯域予約を扱うために役割を持つ。ラベルの対応を配る仕組みも、MPLS の転送を成立させるために役割を持つ。Source Routing で読み替えているのは、良し悪しの判定ではなく、状態の置き場所だ。そしてこの寄せ方は、MPLS をまるごと作り替える話ではない。通信に印を付けて転送するという MPLS の土台は、そのまま使われる。状態の置き場所を、途中から入口側へ移す。その一点だけを読み替える発想だ。
最初に開いたバックボーン図へ、戻ってみる。ラベルの対応、通り道ごとの状態、地図、顧客の経路。さっきまで別々に見えていた確かめる面は、いまは一つの問いに畳まれて見える。この状態は、途中に散らばっているのか、それとも入口に寄っているのか。バックボーンを読むときに最初に立てられる問いは、それだ。これで、MPLS の上に重なった仕組みを一気に暗記し直す必要はなくなる。道そのものを読む前に、状態の置き場所を見る。やめたいのは全部ではない。途中に経路ごとの取り決めを抱え続けることだ。
残るのは、もう一つだけ。入口で道を決めると言ったが、その決めた道を、運ぶ通信の側にどう持たせるのか。経路を、何として運ぶのか。ここでは形を決めない。まずは、途中の合意をやめるために、道の決定を入口へ寄せる。その出発点だけを、最初の図の上に置いておけばいい。