4.4 MPLS (Multiprotocol Label Switching)

IP の拡張に関する議論をさらに続けよう。本節では非常に広く用いられているもののエンドユーザーから見えることはほぼないインターネットアーキテクチャの追加機能を紹介する。その機能は MPLS (Multiprotocol Label Switching) と呼ばれ、仮想回線の特徴とデータグラムの柔軟性と障害耐性を併せ持つ。一方では、MPLS はインターネットプロトコルのデータグラムを基礎とするアーキテクチャと深く関連付いている ── MPLS は IP アドレスと IP ルーティングプロトコルを利用する。しかしもう一方では、MPLS が有効なルーターはパケットの転送を比較的短い固定長のラベルを読むだけで行うことができ、そのラベルはローカルなスコープを持つ: この点は仮想回線と似ている。一見すると正反対に思える二つのテクノロジを合体させていることがおそらくは理由となって、インターネットエンジニアのコミュニティにおける MPLS の評価は分かれている。

MPLS の動作を見る前に、「MPLS があると何が嬉しいのか？」という自然な疑問に答えておく。MPLS の利点に関しては様々な意見が唱えられてきたものの、現在 MPLS が利用される目的は主に次の三つである:

IP データグラムを通常の方法で転送する機能を持たないデバイスで IP の機能を利用するため。
明示的な経路 ── IP ルーティングプロトコルが選択するとは限らない、事前に計算された経路 ── に IP パケットを転送するため。
特定のタイプの仮想プライベートネットワークサービスをサポートするため。

このリストに元々の設計目標 ── パフォーマンスの改善 ── が存在しない事実は指摘に値する。近年 IP ルーターの転送アルゴリズムが改善されたこと、そしてパフォーマンスを決定する要因がヘッダーの処理以外に数多く存在することが大きく関係している。

MPLS の動作を理解するには利用例を見るのが一番だろう。これから三つの項を使って、上述した三つの用途のそれぞれに対応する MPLS のアプリケーションを順に説明する。

4.4.1 宛先ベースの転送

IP パケットにラベルを付けるアイデアを示した最初期の公開出版物の一つは Chandranmenon と Varghese による論文¹であり、この論文は threaded indices (糸を通した添え字) を使ったアイデアを提案した。現在 MPLS が有効なルーターでは非常に似たアイデアが実装されている。

図 114 のネットワークを考えよう。右端の二つのルーター (R3 と R4) はそれぞれ一つのネットワークに接続され、それぞれのネットワークのプレフィックスは 18.1.1/24 と 18.3.3/24 である。それ以外のルーター (R1 と R2) の転送テーブルには、R3 と R4 に向けてパケットを転送するときに使うべき外向きインターフェースが示されている。

ルーターで MPLS が有効だと、ルーターは自身の転送テーブルに記録された各プレフィックスにラベルを割り振り、そのラベルと対応するプレフィックスの両方を隣接ルーターに広報する。この広報は LDP (Label Distribution Protocol) で伝達される。図 115 (a) では R2 がプレフィックス 18.1.1. にラベル 15 を、プレフィックス 18.3.3 にラベル 16 を割り振っている。ラベルの値はルーターが好きに選択でき、転送テーブルへの添え字とみなせる。

図 115.

(a) R2 がラベルを割り振り、対応関係を R1 に広報する。 (b) R1 が受け取ったラベルを転送テーブルに記録する。 (c) R3 が別の対応関係を広報し、それを受け取った R2 が転送テーブルに記録する。

ラベルを割り振った R2 は、ラベルの対応関係を隣接ルーターに広報する。図 115 (a) では、R2 が割り振ったプレフィックス 18.1.1 とラベル 15 の対応関係が R1 に広報されている。この広報は「プレフィックス 18.1.1 宛てのパケットを私 (R2) に送るときは、15 のラベルを付けてください」と R1 に伝えているのに等しい。R1 は転送テーブルのプレフィックス 18.1.1 のエントリーにリモートラベル (外向きラベルとも呼ばれる) として 15 記録する。プレフィックス 18.1.3 とラベル 16 に対しても同様の処理が起こり、最終的に図 115 (b) に示す状況となる。

図 115 (c) では R3 が R2 にプレフィックス 18.1.1 に対するラベル 24 を広報し、R2 は対応する転送テーブルのエントリーにリモートラベルを追加する。

ここまでくれば、このネットワークでパケットが転送されるとき何が起こるかを説明できる。R1 が図の外にあるルーターから受け取ったパケットの宛先が IP アドレス 18.1.1.5 だったとしよう。このとき R1 は LER (label edge router, ラベルエッジルーター) と呼ばれる。LER は到着した IP パケットの宛先の完全な IP アドレスを使った転送テーブルの探索を行い、その結果のラベルをパケットに付加する。この例では宛先 18.1.1.5 がプレフィックス 18.1.1 にマッチし、そのエントリーには外向きインターフェースとリモートラベルの値が記されている。そのため R1 はリモートラベル 15 をパケットに付加してから R2 に向かってパケットを送信する。

そのパケットが R2 に届くと、R2 はパケットのラベルだけを確認して IP アドレスは確認しない。R2 の転送テーブルには、R3 から広報された情報を元に「ラベル 15 が付いて届いたパケットは、ラベルを 24 に付け替えてインターフェース 1 から送信せよ」と書かれている。そのため R2 はラベルを付け替えたパケットを R3 に転送する。

ラベルを用意して付けたり付け替えたりする以上の処理で何が達成されたのだろうか？この例で R2 がパケットを転送するにあたって宛先の IP アドレスを全く確認していない点に注目してほしい。R2 は宛先の IP アドレスではなくパケットに付加されたラベルだけを確認している。そのため、R2 では宛先の IP アドレスを使った通常の探索がラベルを使った探索に置き換わる。これが重要な理由を理解するには、IP アドレスは固定長であるものの、ネットワークプレフィックスは可変長である事実を思い出す必要がある。加えて、IP パケットの転送先を探索するアルゴリズムは宛先の IP アドレスとの最長一致を見つけなければならない。これに対して、ここで説明したラベルを利用する転送では完全一致のアルゴリズムが利用できる。完全マッチは非常に簡単に実装できる: 例えばラベルを配列に対する添え字として、その配列の各要素を転送テーブルの行へのポインタとすればいい。

なお、転送で使われるアルゴリズムは最長一致から完全一致に変更されたものの、ルーティングのアルゴリズムには標準的な IP ルーティングアルゴリズム (OSPF など) を好きに利用できる。この設定では、MPLS を使ったときにパケットが通過する経路は MPLS が使われない場合と全く同じになる: IP ルーティングアルゴリズムが選択する経路が使われる。変更されるのは転送アルゴリズムだけである。

以上の例で MPLS の重要な基礎概念が説明できた: 任意の MPLS ラベルは特定のルーターで同じ転送処理を受けるパケットの集合を表す。この集合を FEC (forwarding equivalence class, 転送等価クラス) と呼ぶ。ここまでの例では、転送テーブルに含まれるプレフィックスのそれぞれが一つの FEC を表すとみなせる: 例えばプレフィックス 18.1.1 にマッチするパケットは (下位ビットが何であれ) 全て同じ経路に転送される。そのため各ルーターは 18.1.1 に対して一つのラベルを割り振り、プレフィックス 18.1.1 にマッチする IP アドレスに宛てられたパケットはラベルを使って転送される。

以降の例でみるように、FEC は非常に強力かつ柔軟な概念である。EFC は任意の基準で作成できる: 例えば特定の顧客に関連する全てのパケットは同じ FEC に属すると考えることもできる。

ここまでの例に戻ると、転送アルゴリズムが通常の IP 転送からラベルの付け替えに変更されたことで、重要な特徴が生まれている: IP パケットの転送方法を知らないデバイスであっても、MPLS を利用するネットワークでなら IP トラフィックを転送できる。この事実を応用した初期のテクノロジで最も特筆に値するのは ATM スイッチで、転送ハードウェアを一切変更せずに MPLS をサポートすることが可能だった。ATM スイッチは前述したラベルの付け替えアルゴリズムをサポートするので、IP ルーティングプロトコルの実行とラベルの関連付けを行う方法を提供すれば LSR (label switching router, ラベル交換ルーター) が完成する。LSR とはラベルの交換による転送アルゴリズムを使って IP 制御プロトコルを実行するデバイスを言う。最近では、同じアイデアが光スイッチで使われている。

ATM スイッチを LSR にする利点を考える前に、解説できていない詳細を説明する。パケットにラベルを「付ける」と言ったが、具体的に何が起こるのだろうか？具体的な動作はパケットが伝送されるリンクの種類によって異なる (図 116)。IP パケットが完全なフレームとして伝送される (イーサネットや PPP を含む多くのリンクにおける状況) なら、ラベルは第 2 層のヘッダーと IP (第 3 層) ヘッダーの間に詰め物shimとして加えられる (図の下部)。しかし、ATM スイッチを MPLS LSR として動作させるには、ラベルをスイッチが利用できる場所に配置する必要がある。そのため、通常のパケットで仮想回線識別子 (VCI) と仮想路識別子 (VPI) が収まる部分がラベル用に利用される (図の上部)。

図 116.

(a) ATM にカプセル化されたパケットに付加されるラベル; (b) 完全なフレームにカプセル化されるパケットに付加されるラベル

これで ATM スイッチを LSR として機能させる方法が分かった。しかし何のためにこれを行うのだろうか？まず重要な点として、従来の IP ルーターと LER、そして LSR として機能する ATM スイッチが混ざったネットワークが構築可能であり、そのようなネットワークの全てのデバイスで同じルーティングプロトコルを使うこともできる。同じルーティングプロトコルを使う利点を理解するために、そうでない場合を考えよう。図 117 に示すのは、いくつかのルーターが ATM ネットワーク上の仮想回線で相互接続される、オーバーレイネットワーク (overlay network) と呼ばれる設定である。市販される ATM スイッチのスループットがルーターより高かった時代には、こういった種類のネットワークが構築されることがしばしばあった。しかし現代ではルーターが高速になり、ATM スイッチより高速な場合さえあるので、こういったネットワークを目にする機会は減少している。ただ、ATM スイッチはネットワークのバックボーンに大量に設置されたので、こういったネットワークは現在でも依然として存在している。この理由の一端は ATM が回線エミュレーションや仮想回線サービスといった幅広い機能をサポートできることである。

LSR を使ったルーターの直接対話 — 図 117.

(a) ルーターが仮想回線のオーバーレイを通して相互接続される。 (b) ルーターが LSR と直接対話する。

オーバーレイネットワークでは、仮想回線を使って各ルーターを他のルーターのそれぞれに接続できる (ただし図 117 (a) では図を簡潔にするために R1 から R1 のピアルーターへの回線だけを示している)。R1 はルーティングにおける隣接ノードを 5 つ持ち、その全てとルーティングプロトコルのメッセージを交換する必要がある。このとき R1 のルーティング隣接性 (routing adjacency) は 5 であると言う。これに対して ATM スイッチが LSR に置き換えられた図 117 (b) では、ルーター同士を相互接続する仮想回線は存在しない。そのため、LSR1 (元 R1) のルーティング隣接性は 1 となる。大規模ネットワークのスイッチで MPLS を使うと各ルーターのルーティング隣接性が大きく減少し、ネットワークトポロジーの変更をお互いに通知し合うために必要なルーターの仕事を大きく減らすことができる。

エッジルーターと LSR で同じルーティングプロトコルを実行する二つ目の利点は、エッジルーターがネットワーク全体のトポロジーを理解できることである。これは一部のリンクやノードで障害が起こったとしても、エッジルーターが優れた新しい路を選択できる可能性が高いことを意味する。これに対して、エッジルーターの知識を持たない ATM スイッチが障害発生時に仮想回線の経路を再構成できる可能性は低い。

ATM スイッチを LSR で「置き換える」ステップは実際にはスイッチで実行するプロトコルを変更することで行われ、普通は転送ハードウェアに変更が必要にならないことに注目してほしい。つまり、ソフトウェアのアップグレードだけで ATM スイッチを MPLS LSR にできる場合が多い。さらに、MPLS LSR が MPLS 制御プロトコルと同時に通常の ATM の機能をサポートできることもある。この設定は「ships in the night」モードと呼ばれる。

IP パケットをネイティブに転送できないデバイス上で IP 制御プロトコルを実行するアイデアは WDM (Wavelength Division Multiplexing, 周波数分割多重化) や TDM (Time Division Multiplexing, 時分割多重化) を利用するネットワーク (SONET など) で用いられており、GMPLS (Generalized MPLS, 一般化 MPLS) と呼ばれる。GMPLS が開発された動機の一つは光ネットワークのトポロジーに関する知識をルーターに与えることであり、ATM の場合と同様である。ただ、それよりも重要なこととして、光デバイスを制御する標準的なプロトコルが存在しなかったので、そこに MPLS が自然に収まったという事実がある。

4.4.2 明示的ルーティング

IP はソースルーティング用のオプションを持つものの、指定できるホップ数が限られていたり、「ファストパス」から外れるためにルーターでの処理が遅い場合が多かったりするために広くは使われていない。

MPLS はソースルーティングに似た機能を IP ネットワークに追加する簡単な手段を提供する。ただし MPLS が関係するとき、この機能は明示的ルーティング (explicit routing) と呼ばれる場合が多い。この機能が異なる名前で呼ばれる理由の一つは、多くの場合で経路を指定するのがパケットの本当の送信元ではないためである。MPLS を使った経路の明示的選択は ISP のネットワークに含まれるルーターによって行われる場合が多い。図 118 に MPLS による明示的ルーティングの動作例を示す。この種のネットワークはその形からしばしばフィッシュネットワーク (fish network) と呼ばれる (R1 と R2 が尾、R7 が頭に見える)。

図 118 に示したネットワークの運用者が「R1 から R7 に向かうトラフィックは R1-R3-R6-R7 の経路を通り、R2 から R7 に向かうトラフィックは R2-R3-R4-R5-R7 の経路を通るのが望ましい」と考えたとする。このように考える理由の一つとして、R3 から R7 へ向かう二つの経路を効率良く利用することが考えられる。このとき、R1 から R7 へ向かうトラフィックが一つの FEC (forwarding equivalence class, 転送等価クラス) を構成し、R2 から R7 へ向かうトラフィックが別の FEC を構成するとみなせる。通常の IP ルーティングだと R3 はトラフィックがどこから送られてきたかを確認しないで転送先を判断するので、これら二つの FEC を異なる経路に転送するのは難しい。

MPLS はパケットの転送にラベルの付け替えを用いるので、ネットワークのルーターが MPLS に対応していれば望ましいルーティングを簡単に達成できる。R1 と R2 が R3 に送信するパケットにそれぞれ異なるラベル ── 異なる FEC に属することを示すラベル ── を付ければ、R3 は R1 からのパケットと R2 からのパケットを異なる経路に転送できる。ここで「ネットワーク内のルーターは利用されるラベル、そしてラベルの転送方法にどうやって合意するのか？」という疑問が生じる。明らかに、前項で説明したラベルの広報による方法は使えない: この方法を使うとパケットは通常の IP ルーティングが選択するのと同じ経路で転送されてしまう。今はこれを何としても避けたいのだった。そのため新しい仕組みが必要になり、現在では RSVP (Resource Reservation Protocol) と呼ばれるプロトコルが利用される。今のところは、RSVP メッセージを明示的に指定した経路 (例えば R1-R3-R6-R7) に沿って送ることができ、そのとき経由するルーターの転送テーブルのエントリーにラベルを追加できることを知っておけば十分である。これは仮想回線の構築と非常によく似たプロセスと言える。

明示的ルーティングの応用の一つにトラフィックエンジニアリング (traffic engineering) がある。ネットワークに対する需要に応えられるだけの十分なリソースが利用可能なことを保証するタスクをトラフィックエンジニアリングと呼ぶ。トラフィックが流れる経路を正確に制御できることはトラフィックエンジニアリングの重要な要素である。明示的ルーティングにはネットワークの障害耐性を高める効果もある。このとき使われる機能は高速再ルーティング (fast reroute) と呼ばれる。例えば、ルーター A とルーター B を結ぶ経路であって特定のリンク L を使わない経路を事前に計算しておくことができる。このバックアップ用の経路を事前に計算しておけば、L で障害が起きてもパケットの明示的ルーティングでその経路に切り替えるだけで済む。このとき A はルーティングプロトコルパケットがネットワーク中に伝達され、ルーティングアルゴリズムがネットワーク上の各ノードで実行されるのを待つ必要がない。特定の状況では、この仕組みによって障害発生点を迂回する再ルーティングにかかる時間が格段に減少する。

明示的ルーティングに関して最後に、上記の例のようにネットワーク運用者が明示的な経路を計算する必要はないことを指摘しておく。実際にはルーターが様々なアルゴリズムを使って明示的な経路を自動的に計算する。最もよく使われるアルゴリズムは CSPF (constrained shortest path first, 制約付き最短路優先) と呼ばれる。CSPF はリンク状態型のアルゴリズムであるものの、様々な制約 (constraint) を考慮する。例えば「R1 と R7 を結ぶ経路であって 100 Mbps の負荷に耐えられるもの」を見つけることができる。この条件は制約として「経路上の各リンクが最低でも 100 Mbps の容量を持つ」と言い換えることができる。CSPF はこの種の問題を解決する。

4.4.3 VPN とトンネル

VPN (virtual private network, 仮想プライベートネットワーク) を構築する方法の一つにトンネルを使うものがある。MPLS はトンネルを構築する手段とみなすことができ、様々なタイプの VPN を構築するのに適していることが判明している。

最も単純な形式の MPLS VPN は第 2 層 VPN である。この形式の VPN では、MPLS は第 2 層のデータ (例えばイーサネットフレームや ATM セル) を MPLS が有効なルーターからなるネットワーク上でトンネルする。トンネルを作る理由の一つにネットワーク内のルーターがサポートしないネットワークサービス (マルチキャストなど) の提供があると以前に説明した。ここでも同じことが言える: IP ルーターは ATM スイッチではないので、通常の IP ルーターからなるネットワークでは ATM 仮想回線のサービスを構築できない。しかし、トンネルで結ばれた二つのルーターを用意すれば、その間で ATM セルをやり取りすることで ATM 回線をエミュレートできる。このテクニックは IETF 内で疑似回線エミュレーション (pseudowire emulation) と呼ばれる。図 119 に疑似回線エミュレーションのアイデアを示す。

IP トンネルの構築方法は以前に説明した: トンネルの入口にあるルーターはトンネルを通して送りたいデータを IP ヘッダー (トンネルヘッダー) で包み、そのヘッダーの宛先はトンネルの出口にあるルーターのアドレスとする。そのトンネルヘッダーのついたデータは通常の IP パケットと同じように扱われ、いずれトンネルの出口のルーターに到着する。自身に宛てられたパケットを受け取った出口のルーターはトンネルヘッダーを取り除き、トンネルを通ってきたデータに対する処理を行う。具体的な処理はトンネルの用途によって異なる。例えばトンネルを通して送られたのが IP パケットなら、そのパケットは通常の IP パケットと同様に転送される。しかし IP パケットである必要はなく、出口のルーターが処理方法を分かっていれば何でも構わない。IP でないデータの処理方法は以降で説明される。

MPLS トンネルは IP トンネルとそれほど違わない。唯一異なるのは、トンネルヘッダーが IP ヘッダーではなく MPLS ヘッダーとなる点である。図 115 の例をもう一度考えよう。ルーター R1 はプレフィックス 18.1.1 に宛てられた全てのパケットにラベル 15 を付けると前に見た。そのパケットは R1-R2-R3 の経路で転送され、経路上の各ルーターは MPLS ラベルだけを確認する。このため、R1 の送るデータが IP パケットでなければならない要件は存在しない ── MPLS ヘッダーの中には任意のデータを入れることができ、そうした場合でも中間のルーターは MPLS ヘッダーより内側のデータを見ないのでデータは同じ経路を通って転送される。こう考えると、MPLS ヘッダーは IP トンネルヘッダーと同じだとみなせる (長さが 20 バイトではなく 4 バイトである点だけが異なる)。非 IP トラフィックを (MPLS あるいは IP の) トンネルに流すときは、トンネルの出口での処理が唯一の問題となる。一般的な解決法は「逆多重化のための識別子をトンネルペイロードに仕込んでおき、それを使って出口のルーターに何をすべきかを伝える」というものである。MPLS ラベルはそういった識別子として完璧なことが判明している。

図 119 のように、MPLS が有効なルーターからなるネットワークで ATM セルをトンネルしたいとする。さらに、ここでの目標は ATM 仮想回線をエミュレートすることだとする: つまり、ATM セルはトンネルの入口に到着するとき特定の VCI を持って特定のポートに到着するので、出口では正しい (最初の値とは異なる可能性のある) VCI を持った ATM セルを特定のポートに出力しなければならない。これは入口と出口のルーターを次のように設定することで行える:

入口のルーターには内向きポート、内向き VCI、エミュレートされる仮想回線を表す逆多重化ラベル、そして出口のルーターのアドレスを設定する。
出口のルーターには外向きポート、外向き VCI、そして逆多重化ラベルを設定する。

これらの情報がルーターに提供されれば、ATM 仮想回線のエミュレートが可能になる。図 120 にその様子を示す。トンネル処理の各ステップは次の通りである:

適切な VCI の値 (この例では 101) を持った ATM セルが指定された入力ポートに到着する。
入口のルーターがエミュレートされる仮想回線を識別する逆多重化ラベルを取り付ける。
続いて入口のルーターは二つ目のラベルを取り付ける。このラベルはパケットを出口のルーターまで到達させるためのトンネルラベルである。本節の前半で説明したように、入口のルーターに隣接するルーターはこのラベルの意味を学習している。
入口と出口の間にあるルーターはトンネルラベルだけを使ってパケットを転送する。
出口のルーターはトンネルラベルを取り除き、逆多重化ラベルを確認し、エミュレートされている仮想回線を認識する。
出口のルーターは ATM セルの VCI の値を正しい値 (この例では 202) に変更し、正しいポートから送信する。

この例でパケットに二つのラベルが加えられることに驚いたかもしれない。これは MPLS が持つ興味深い特徴の一つである ── パケットに取り付けるラベルを任意に高く積み上げることができる。この特徴はスケーリングに関する有用な機能をいくつか提供することが判明している。この例では、この特徴により一つのトンネルが大量の種類のエミュレートされた回線を扱える。

ここで説明したテクニックを使えば、フレームリレーやイーサネットといった様々な第 2 層サービスをエミュレートできる。なお、事実上同じ機能は IP トンネルを使った場合でも提供できることは注目に値する。この用途で MPLS が持つ主な利点はヘッダーが短くなることである。

MPLS が第 2 層サービスをトンネルするのに利用されるのに先立って、MPLS は第 3 層 VPN をサポートするために利用されていた。第 3 層 VPN は非常に複雑なので詳細には立ち入らないが、現在 MPLS の用途として最も多いのが第 3 層 VPN であることは指摘しておく。

第 3 層 VPN も大量の MPLS ラベルを利用して IP ネットワーク内にパケットのトンネルを構築する。ただし、トンネルされるパケットも IP パケットとなる。第 3 層 VPN では、単一のサービスプロバイダが MPLS の有効なルーターのネットワークを運用し、「仮想プライベート IP ネットワーク」を提供する。つまり、サービスプロバイダは拠点をいくつか持つ顧客に対して、独占的に利用できるかのように錯覚できるネットワークを提供する。顧客は仮想プライベート IP ネットワークを自身の拠点だけを相互接続した IP ネットワークとして扱える。これは各顧客が他の顧客とルーティングとアドレスの意味で切り離されることを意味する: 図 121 の顧客 A は顧客 B に直接パケットを送信できず、逆方向にも行えない。顧客 A の使う IP アドレスが顧客 B によっても利用される可能性さえある。第 2 層 VPN と同様、第 3 層 VPN で MPLS はパケットをトンネルするために利用される。ただし、トンネルの設定は非常に手の込んだ形で BGP を用いることで自動的に行われる。この詳細は本書の範囲を超える。

図 121.

第 3 層 VPN の例: 単一のプロバイダが顧客 A, B に仮想プライベート IP サービスを提供する。

なお、実際には顧客 A が顧客 B に (いくらか制限された形で) パケットを送れる場合が多い。顧客 A と顧客 B の両方がグローバルインターネットへの接続を持つ可能性が非常に高いので、例えば顧客 B のネットワークにあるメールサーバーに向けて顧客 A が送信したメールはおそらく問題なく届く。VPN が提供する「プライバシー」は顧客 A が顧客 B のネットワーク内の全てのマシンおよびサブネットに対する無制限のアクセスを持たないことを意味する。

まとめると、MPLS は非常に高機能なツールであり、種類の異なる幅広いネットワークの問題で利用されてきた。仮想回線と関連付けられることが多いラベル付け替えによる転送メカニズムを IP データグラムネットワークの制御プロトコルと組み合わせることで、これらの従来のテクノロジの中間に位置するネットワークのクラスが生み出されている。MPLS によって IP ネットワークの機能はルーティングのより細かな制御や様々な VPN サービスのサポートが可能になるまでに拡張される。

訳注: Girish P. Chandranmenon and George Varghese. 1995. Trading packet headers for packet processing. SIGCOMM Comput. Commun. Rev. 25, 4 (Oct. 1995), 162–173. https://doi.org/10.1145/217391.217427. ↩︎