入口で通り道を決めて、途中の点に経路ごとの合意を持たせない。前の話で、そこまでは見えた。
では、入口から送り出す packet の荷札には、具体的に何と書けばいいのだろう。途中の点に道順表を配らないなら、packet 自身が、自分の通る道を持っていなければならない。けれど、その荷札に何が書かれていれば、途中の点はそれを読んで一手だけ進めるのか。
まず思いつくのは、行き先の名前を端から並べる形だ。最初に通る点の名前、次の点の名前、と順に書いていく。経路は決めたのだから、通る点はもう全部分かっている。それを順に書けばよさそうに見える。けれど、名前を書いた荷物が途中の点に届くと、その点はまた名前を読み、そこから道順を解釈し直すことになる。それでは、経路ごとの判断を入口へ寄せた意味が薄くなる。
入口で決めた経路は、行き先の名前ではなく、通る点を指す番号の列として packet に積めばよい。


名前を並べると、途中の点は毎回読み直すことになる
行き先の名前を順に書いた荷物が、途中の点に届いたとする。その点は、書かれた名前を見て「次はどこへ出せばいいか」を自分で考えなければならない。名前はあくまで「どこへ向かうか」であって、「いまこの点からどの隣へ出すか」ではないからだ。途中の点は、自分の持っている地図と照らし合わせ、その名前へ向かうにはどの隣へ渡せばよいかを、その都度求め直すことになる。
これは、前の話で外したかった重さに似ている。入口で経路を決めたのに、途中の点がまた経路を読み直しているなら、合意を入口へ寄せた意味が薄れてしまう。
途中の点に経路ごとの合意を持たせないなら、入口で決めた経路は、packet 側にどんな形で持たせれば、途中の点が迷わず一手ずつ進めるのか。
欲しいのは、途中の点が「読み直す」のではなく「読むだけで進める」形だ。名前から経路を組み直すのではなく、いま見えているものが、そのまま「次にやる一手」を指している。そういう書き方ができれば、途中の点は重い計算を抱えずに済む。
そこで、名前ではなく番号を積む。番号と言っても、点に振った名札のことではない。一つひとつの番号が、「その場で実行する一手」を指している。「この宛先の方向へ進め」「この隣へ出せ」というような、実行する指示そのものを指す識別子だ。経路は、その番号を上から順に積んだ列として packet に載る。こうして経路を表す一つひとつの番号を Segment、その番号(識別子)を SID と呼ぶ。
番号の列は、上から読まれる。途中の点は、列の全体を持つわけではない。いま一番上に見えている番号、それだけを読む。その番号が指す一手を実行し、終わると、その番号が一枚はがれて、次の番号が一番上に出てくる。次の点は、また一番上の番号だけを読む。列全体の道順表を抱える点はどこにもなく、各点はそのとき一番上にある一手を実行するだけでいい。
なぜ名前ではなく番号なのか、ここで一歩だけ背景に触れておく。経路ごとの状態を途中の点に散らさず、入口側へ寄せたい。それを成り立たせるには、途中の点が名前から経路を組み直すのではなく、一番上の番号が指す一手を、そのまま実行できる形が要る。番号は、その「一手を指す識別子」として置かれている。実際の SR-MPLS では、この番号の列が MPLS label stack という形で packet に積まれる。ただし、その番号が実際の label そのものなのか、番号をしまう箱への目印なのかは、ここでは分けない。いまは「通る点を指す番号」までで止めておく。
そして、ここがこの仕組みの軽さの源でもある。新しい道順表を途中の点へ配り直すのではなく、入口が packet 側に番号の列を載せるだけで始められる。途中の点の振る舞いは、一番上の番号を見て、その一手を実行し、はがして次を見る、という単純な動きに保たれる。見る場所は、行き先の名前ではなく、いま一番上に見えている番号と、それが終わると見える次の番号へ移る。
宛先を指す番号だけでは、特定のリンクを通せない
番号の列で経路を表せた。では、その番号は全部が同じ性質のものなのだろうか。番号がどれも「この宛先へ向かえ」という同じ性質のものだとして、途中でどうしても通したいリンクがある経路は、それで表せるだろうか。
入口から D へ通信を送るとして、D を指す番号を一つだけ積んだとする。これを受け取った途中の各点は、それぞれが計算で求めた D への道に沿って進めていく。D へは届く。けれど、どの道を通って届くかは、各点の計算任せだ。途中の点が選ぶ道が、入口の意図した道とは限らない。
ここで、途中で必ず B から C のリンクを通したい、という意図があったとする。D を指す番号だけでは、その「B から C へ」という一手を表せない。D を指す番号は「D の方向へ進め」という意味で、網のどこから見ても同じ D を指しているからだ。それは宛先の方向であって、特定の隣への一手ではない。
そこで、別の種類の番号が要る。「いまいるこの点から、この隣へ出せ」という、局所的な一手を指す番号だ。この二つを、同じ列の中に混ぜて積む。B までは D を指す番号で進ませ、B に着いたところでその隣 C へ出す番号を実行させ、その後はまた D を指す番号で進ませる。すると入口は、「ここまでは宛先方向へ、この点ではこの隣へ、そこからまた宛先方向へ」と、通したい道筋を細かく組み立てられる。


宛先を指す番号は、網のどこから見ても同じ宛先へ向かう一手を指す。どの点がこの番号を見ても、向かう先は同じ宛先で、そこへ計算済みの道を進む。この、宛先への道を指す番号を Prefix-SID と呼ぶ。
特定の隣へ進む番号は、いまいる点からその隣へ出る、局所的な一手を指す。これは、その隣を広告している点に固有のもので、網のどこでも同じ意味になるわけではない。ある点で「この隣へ」という一手を指していても、別の点で同じ番号が同じ意味を持つとは限らない。この、隣への一手を指す番号を Adjacency-SID と呼ぶ。
二つは、優劣でも上下でもない。番号が大きいほど偉い、というような並びでもない。一方は「どこへ向かうか」を指し、もう一方は「ここからどの隣へ出るか」を指す。役割が違うだけだ。だから、番号の列を見たときに最初に読み分けたいのは、その番号が宛先の方向を指しているのか、特定の隣への一手を指しているのか、という点になる。
列は組み立てられた。残るのは、番号の意味を誰が知らせるのか
入口で決めた経路は、packet に何として積まれるのか。冒頭で空欄だった荷札の中身は、もう書ける。行き先の名前ではなく、通る点を指す番号の列だ。一番上の番号が、いま実行する一手で、終わると次の番号が見える。そして番号には、網全体で同じ宛先を指すものと、いまいる点から特定の隣へ進むものがある。この二種類を列に並べれば、入口は通したい経路を組み立てられる。
その荷札に、宛先を指す番号と隣へ進む番号を並べた列を置いてみる。途中の点は、一番上の番号を読み、それが宛先方向なら計算済みの道を進み、特定の隣を指すならその隣へ出す。経路ごとの合意を抱える点は、どこにもいない。前の話で入口へ寄せたかった経路の意図が、ここで packet の上の番号の列という具体的な形を持った。
ただ、一つだけ、まだ言葉にしていない前提がある。入口が番号の列で経路を指定できるのは、途中の各点が、その番号の意味を同じように知っているからこそだ。一番上に出てきた番号を見て、「これは D の方向だ」「これは隣 C への一手だ」と読めなければ、列はただの数字の並びで終わってしまう。入口が並べた番号の意味を、網の中の各点はどこかから受け取っていなければならない。
では、その番号の意味は、誰が、どうやって各点に知らせているのか。
経路を番号の列として表す形と、番号の二つの役割は、ここまでで見えた。次は、入口が並べたその番号の意味を、網の中の各点がどこから受け取るのかへ進む。