backbone の中で packet に label が付いている。

短い番号を見て次へ送ればよい、という話に見える。宛先 IP を毎回細かく読み続ける代わりに、label を見て進める。前の話で見た label forwarding の入口は、たしかにそこにあった。

けれど、その label が、隣の LSR にとっても同じ意味を持つとは限らない。手前の LSR が「この FEC にはこの label を付けて送る」と決めていても、受け取る側がその対応を知らなければ、短い番号だけでは次の処理を決められない。

label forwarding は、label の値そのものより先に、隣どうしで「この FEC にはこの label を使う」という対応づけが揃って初めて成立する。LDP は、その対応づけを隣へ知らせるために入ってくる。

label と FEC binding は、隣接関係ごとに異なる

MPLS の label は、provider backbone 全体で一つの名前帳になっているわけではない。

ある LSR が受け取った top label を見て次の LSR へ送るとき、その label は「この FEC として扱う packet だ」という短い手がかりになる。FEC は、同じ扱いで転送したい packet のまとまりだ。入口で FEC に割り当てられた packet は、backbone の中では label lookup によって次の hop へ進む。

しかし、その label value がどこでも同じ FEC を指すとは限らない。

packet が LSR A から LSR B へ進むときの label と、LSR B から LSR C へ進むときの label は、同じ FEC を運んでいても別の値になり得る。反対に、同じ値に見える label が、別の隣接関係では別の FEC に結びつくこともある。

読むべき単位は、packet が進む向きの隣どうしだ。上流の LSR がどの FEC の packet を送り、下流の LSR がその incoming label をどの FEC として解釈するのか。その対応づけ、つまり label/FEC binding がなければ、受け取った側は label を見ても次の処理を決められない。

隣どうしの binding を、向きで読む

binding は、「この FEC の packet には、この label を使う」という対応づけだ。FEC は転送上同じ扱いにしたい packet のまとまり。label は、そのまとまりを次の LSR へ渡すときに使う短い値。label/FEC binding は、この二つを隣どうしの関係で結ぶ。

packet が LSR A から LSR B へ進む場面を考える。

LSR A は、ある FEC の packet を LSR B へ送る。そのとき、LSR B が受け取って解釈できる label を使う。LSR A の中で都合よく決めた番号を勝手に貼るだけでは、LSR B はその incoming label をどの FEC として扱えばよいか分からない。

次に LSR B が LSR C へ送るときも同じだ。LSR B は、受け取った label を見て処理し、次の LSR C へ送るための label に置き換えることがある。ここでも、LSR B と LSR C の間で別の binding を持つ。

中継の LSR は、顧客の宛先 IP を毎 hop で同じ粒度に読み直すのではない。top label を見て、incoming label をどの FEC として扱い、次の hop へどの outgoing label で送るかを決める。この処理が成立するのは、前後の LSR が FEC と label の対応を共有しているからだ。

ここで面が二つに分かれる。label は packet に付いて流れていく面で、これが packet を実際に進める data-plane。binding は、その label を隣がどう読めばよいかを決める面で、こちらは control-plane で揃える。同じ label value でも、どちらの面の話かで見えるものが変わる。MPLS が「番号を貼る転送」ではなく「FEC と label の対応を hop-by-hop につないでいく転送」になるのは、この二面が組み合わさるからだ。

LDP は、対応づけを隣へ知らせる

では、その binding はどうやって隣へ伝わるのか。

ここで LDP が出てくる。LDP は、Label Distribution Protocol の名前どおり、label を配るための仕組みだ。ただし、ここでいう「配る」は、ばらばらの番号を配布するというより、label と FEC の対応づけを LSR 同士で知らせることだ。

ある LSR が、自分が扱う FEC にどの label を使うかを決める。その対応を、隣の LSR が学ぶ。隣もまた、自分の次の LSR との間で必要な binding を持つ。こうして、routing が選んだ道筋に沿って、label forwarding に必要な対応づけが hop-by-hop につながる。

このつながった道筋を LSP と呼ぶ。LSP は、最初から一本の物理的な線が引かれているというより、各 hop の label/FEC binding が連なった転送上の通り道だ。LSR は自分の場所で top label を見て、次にどの label でどこへ送るかを決める。その判断が隣ごとにそろうから、packet は backbone の中を進める。

LDP 自体は、label forwarding の data-plane そのものではない。label forwarding が使う対応づけを control-plane 側で知らせる。前もって LDP が隣へ binding を知らせておくから、packet が来たときに各 LSR は top label を見るだけで次へ送れる。この二つを分けておくと、label を貼って進める動きと、その読み方を隣へ伝える動きが混ざらない。

残るのは、顧客の経路を誰が持つのか

provider backbone の中では label forwarding を使いたい。P ルータには、顧客ごとの細かな経路を全部背負わせたくない。けれど、顧客から見れば、支社やデータセンターへ正しく届いてほしい。

label/FEC binding が隣どうしでつながり、LDP がその対応づけを知らせ、LSP として packet の通り道ができても、まだ顧客の経路そのものを誰が背負うのかは決まっていない。

次に残るのは、PE と P の役割分担で、顧客の経路を誰が背負うのかだ。