経路表を見れば、次にどの隣へ渡すかは分かる。
けれど、経路表で届くことが分かっている通信でも、運用者の意図はそれだけで終わらない。混みやすいリンクを避けたい。重要な通信だけ、余裕のある通り道に寄せたい。ある拠点間の通信は、最短ではなくても決めた経路を通したい。
届くことと、狙った通り道に載せることは同じではない。
MPLS は label を見て provider backbone の中を進む仕組みを持った。LDP は label の意味を隣同士でそろえた。MPLS L3VPN では、顧客ごとの経路を PE が扱い、P は backbone の転送へ寄る形も見えた。
最後に残るのは、帯域の通り道だ。
RSVP-TE は、MPLS の中に明示的な通り道と帯域予約を観測する面を作る。ただし、その通り道ごとの状態を保つ重さも一緒に見える。
最短で届くことと、狙った道を通すことは違う
普通の routing は、宛先へ届くための次の隣を選ぶ。IGP の metric があり、各ルータが自分の見える情報から次の一手を決める。これは到達性を作るうえでは自然な形だ。
provider backbone では「届く」だけでは足りない場面がある。ある区間のリンクが混みやすい。別のリンクには余裕がある。重要な顧客の通信を、混みやすいところへ寄せたくない。障害ではないが、普段から通信を分けておきたい。こういうとき、単に metric を変えるだけだと、関係のない通信までまとめて動いてしまうことがある。
欲しいのは、経路表全体を乱暴に動かす力ではない。入口から出口まで、どの通り道を使うかを先に決め、その通り道に通信の束を載せる見方だ。RSVP-TE は、そのために MPLS の上にシグナリングされた通り道を作る。
入口のルータは、通したい通り道を持って「この通り道に label を割り当てたい」と要求する。途中のルータは、その通り道に沿って必要な情報を持つ。出口へ向かって通り道が作られ、戻り側で label の情報がそろう。
こうして作られる道が、LSP tunnel だ。中のルータは、顧客の宛先 prefix を毎回全部読み直すのではなく、その tunnel に属する通信として label を見て進める。経路表の自然な最短経路とは別に、運用者が意図した通り道を持たせられる。
RSVP-TE が変えるのは、到達性そのものではない。届く通信に対して、どの通り道を使わせるかを MPLS の tunnel として観測できるようにする点だ。
LSP tunnel は道、TE tunnel は通信の束を載せる面
LSP tunnel は、入口から出口まで label でつながった通り道として見る。
運用で見たいのは、道そのものだけではない。その道にどの通信の束を載せるのか、どのくらいの帯域を意識するのか、別の道とどう使い分けるのかも見たい。それを扱うのが TE tunnel だ。
TE tunnel は、1つまたは複数の LSP tunnel を、通信の束を運ぶためのまとまりとして見る。1本の通り道に通信を載せることもあれば、複数の通り道を使い分けることもある。LSP tunnel が「どの道を通るか」なら、TE tunnel は「どの通信をその道に載せ、どう使い分けるか」を持つ。単に通信が進むだけではなく、「この通信をこの tunnel に載せる」という運用上の観測面ができる。
帯域予約も、この面で読める。RSVP-TE では、通り道に資源の予約を持たせられる。すべての LSP が必ず帯域予約を持つわけではない。予約なしで使う LSP もあり得る。けれど、帯域を意識したい通信に対して、tunnel ごとに予約を見られる。
経路表だけを見ていると、確認は「次に渡す先はどこか」で止まりやすい。TE tunnel として見ると、「どの通り道か」「どの通信の束を載せるか」「予約を持っているか」「状態は上がっているか」へ変わる。
見えるものが増えるほど、保つものも増える
RSVP-TE が作った面は便利だ。混みやすいリンクを避ける通り道を作れる。特定の通信を別の tunnel へ寄せられる。tunnel ごとに通り道や予約、状態を確認できる。運用者は、ただ経路表を眺めるだけでなく、「この通信はこの tunnel に載せる」と説明しやすくなる。
その見え方は、状態管理と一体だ。通り道を作るなら、その通り道の状態を持つ必要がある。label を割り当て、予約を扱い、途中のルータと情報をそろえ、隣との状態も見続ける。tunnel が増えれば、見るべき通り道も増える。障害や変更が起きたとき、どの tunnel が影響を受け、どの予約が残り、どこでシグナリングが止まったのかを追う必要が出る。
しかも MPLS の制御面は、ここで重なって見える。IGP は backbone の地図を持つ。LDP は label の意味を配る。BGP は VPN route を PE 間へ運ぶ。そこへ RSVP-TE が加わり、明示的な通り道と予約を tunnel として持つ。
それぞれは理由があって存在する。だから「多いから悪い」とは言えない。けれど、運用者の目には重さとして見える。到達性を見る面、label の意味を見る面、顧客ごとの経路を見る面、TE tunnel の状態を見る面。それぞれを切り分けないと、通信が流れない理由を一つに絞れない。明示経路を持てる価値と、その通り道を網の中で状態として持ち続ける重さは、同じ tunnel の表と裏にある。
通り道の意図を、tunnel の state ではなく入口側へ寄せる
RSVP-TE は、MPLS に大事な観測面を作った。最短経路に任せるだけではなく、入口から出口までの通り道を決める。必要なら帯域予約を持たせる。通信の束を TE tunnel として見て、通り道と状態を確認する。provider backbone で帯域を扱うときに強い考え方だ。
その強さは状態を伴う。通り道ごとにシグナリングし、label と予約をそろえ、途中のルータもその tunnel を知る。MPLS は、顧客の通信を provider backbone で分けて運ぶ入口から始まり、label で進み、label の意味を配り、PE が顧客ごとの経路を扱い、最後に通り道と帯域を tunnel として見るところまで来た。その最後に残ったのは、明示的な通り道を作る力と、その通り道を保つ状態の重さの両方だった。
次に残る問いは、その重さの置き場所だ。通り道の意図は持たせたい。けれど、その意図を tunnel ごとの状態として網の中に広く持たせ続ける以外の形はないのか。通り道の意図を、入口側へ寄せる発想がこの先にある。Segment Routing / SR-MPLS という名前は、この問いの先で出てくる。