前の話で、同じ 10.0.0.0/8 でも顧客が違えば別の意味になる、というところまで見た。

では、その packet が provider backbone の中へ入ったあと、中のルータは毎回その顧客の宛先を同じ粒度で読み直すのだろうか。

顧客側から来た packet は、入口で「同じように進めてよいまとまり」に置かれる。そのまとまりを表す短い印が packet に付き、backbone の中ではその印を見て進む。IP 宛先を毎 hop で同じように読み続ける世界から、label lookup で進む世界へ視線が移る。

MPLS label は、顧客分離そのものではない。入口で決めた FEC を、中の LSR が転送判断に使うための局所的な識別子だ。

provider backbone の中では、同じ宛先を同じ粒度で見続けない

IP forwarding の感覚では、ルータは packet の宛先 IP を見て、routing table から次の hop を選ぶ。

その読み方は、企業ネットワークを追うときには自然だ。宛先 prefix を見て、どの next hop へ送るかを考える。次のルータでも、また宛先を見て判断する。packet が進むたびに、各 hop が自分の表で宛先を読み直す。

MPLS では、ここに別の見方が入る。

入口の LSR（MPLS を扱うルータ）は、packet を FEC に割り当てる。FEC は、同じように転送してよい packet のまとまりだ。転送上は同じ扱いでよい、同じ方向へ進めてよい、と入口で判断された束だ。

その FEC が、MPLS label として packet に付く。

ここで大事なのは、label を顧客名の代わりにしないことだ。顧客ごとの経路や policy は、PE 側の文脈で扱う話として別にある。

今回見る label は、provider backbone の中で転送するための印だ。入口で決めた FEC を表し、中の LSR が次にどこへ渡すかを短く読むために使う。

だから、backbone の中にいる LSR の視線は、顧客側の宛先 prefix を毎回同じ粒度で読むところから少し離れる。

「この packet はどの顧客のどの宛先か」をずっと細かく読み続けるのではなく、「今いちばん上にある label は何か」を見る。そこから次の hop と、label をどう扱うかへ進む。

label stack は、IP header の手前で見える

MPLS label は、packet のどこかに雰囲気として付いているわけではない。

packet 図で見るなら、label stack は data link header の後ろ、IP header の前に置かれる。つまり、IP header を読む前に、MPLS の印を見る場所がある。

中の LSR は、label stack のいちばん上を見る。ここを top label と呼ぶ。

top label を lookup すると、LSR は次の相手を知る。同時に、label stack をどう扱うかも知る。

概念としては、入口では label を付ける。中継では、受け取った label を別の label に入れ替えることがある。出口に近づくと、label を外して IP header へ戻すことがある。

この操作を、push、swap、pop と読む。

ここでは名前を暗記するより、見る順番を押さえればいい。label を付ける。top label を見る。次の hop と操作を決める。必要なら入れ替え、外すべき場所では外す。

この図で見たいのは、label の細かい欄ではなく、LSR の判断材料が top label に寄っていることだ。IP header の宛先を毎回同じ粒度で読み直すのではなく、label lookup から next hop と操作へ進む。

ここで、転送の観測面が変わる。

label は、全員に同じ意味で見える番号ではない

label は短い番号に見える。だから、つい「この番号は provider backbone 全体で同じ意味を持つ」と思いたくなる。

しかし、その読み方は危ない。

MPLS label の意味は、隣どうしの関係の中で決まる。ある LSR が受け取る top label を、どの FEC と見なすか。そこからどの next hop へ送り、次の label をどうするか。その対応は、全世界で固定された番号表ではない。

同じ label の値でも、どの相手から来たか、どの label space で扱っているかによって意味が変わり得る。

顧客を分けるには、入口の PE がどの顧客の文脈で経路を読むか、どの route をどの顧客へ見せるか、という別の仕事がある。

今回の label は、provider backbone の中で「この FEC として進める」と読むための転送上の識別子だ。

そう分けると、P ルータの見え方も変わる。

P ルータは、顧客のすべての route を細かく持つ装置ではなく、provider backbone の中で label lookup によって packet を進める装置だ。

もちろん、現実の MPLS L3VPN では、顧客側の分離と provider backbone の転送が重なって動く。けれど今は、そこを二段で厳密に分解しない。先に必要なのは、label forwarding だけを取り出して見えるようにすることだ。

label lookup で見るものが変わる——毎 hop の IP 宛先再判定から外れる

同じ packet を、二つの見方で読んでみる。

IP forwarding の読み方では、各 hop が宛先 IP を見て、自分の routing table から next hop を選ぶ。packet が進むたびに宛先を見直すので、顧客ごとの prefix が provider backbone の中でも同じ粒度で見える、という想像に寄りやすい。

MPLS label forwarding の読み方では、入口で packet が FEC に割り当てられ、label が付く。中の LSR は top label を lookup し、next hop と label stack operation を決める。

この違いが分かると、MPLS を「速そうな番号」や「顧客を分ける番号」とだけ読まずに済む。

label は、見るものを変える。顧客側の宛先 prefix を毎 hop で同じように読み続けるのではなく、入口で決めた FEC を label として持たせ、provider backbone の中ではその label を lookup する。

「中の LSR は、top label から next hop と操作を決める」

まだ言っていないこともある。label stack の細かい欄、label を配る手順、顧客 VPN の route と label がどう重なるかは、まだ分解していない。

provider backbone の中では、見るものが変わる。

入口で FEC が決まり、label が付く。中の LSR は top label を見て、次の相手と label の扱いを決める。

ここまで来ると、次の問いが残る。

label と FEC の対応を、隣どうしでどう揃えるか。